Polyglot case sensitive attributes

[AndyHood]

Hi Support,

According to the Editor's draft for Polyglot markup at the W3C:

http://dev.w3.org/html5/html-xhtml-author-guide/
section 6.3.2 Attribute Names

Polyglot markup uses lowercase letters in attribute names for all HTML elements.
Polyglot markup uses lowercase letters in attribute names for all MathML elements except the lowercase definitionurl, which polyglot markup changes to the mixed case definitionURL.
Polyglot markup uses lowercase letters in attribute names for all SVG elements except the following, for which polyglot markup uses mixed case:
...
[snip]
...
viewBox
...
[snip]
...

Using the CSE HTML Validator v12.0024 (pro) I get an Error when validating against Polyglot HTML using HTML5 with inline SVG including this line:
<svg xmlns="http://www.w3.org/2000/svg" width="50px" height="25px" viewBox="-50 -25 100 50">

The Error reads:

"viewBox" contains uppercase characters. All HTML start tags, end tags, and tag attributes must be in lowercase. NOTE: This document is assumed to be polyglot and polyglot documents are case-sensitive (because they are XML compatible).
---

I believe that this should not be an error (in fact, using "viewbox" *should* cause an error suggesting "viewBox") and wonder if this is something that might change in an upcoming version of CSE.

Thanks for your thoughts,
Andy

[Albert Wiersch]

Hi Andy,

Thanks for the report.

Can you try this new config file and let me know if it fixes the problem?
http://www.htmlvalidator.com/htmlvalV120cfg.zip

Instructions in ZIP file:

The included htmlvalV120.cfg file should replace the currently installed htmlvalV120.cfg file or files on your system.

This file should be located in the directory where you installed HTML Validator and in your Application Data directory if you have one.

This is something like
32-bit: C:\Program Files\HTMLValidator120\htmlvalV210.cfg
64-bit: C:\Program Files (x86)\HTMLValidator120\htmlvalV120.cfg
and
for Vista and Windows 7/8: C:\Users\(username)\AppData\Roaming\AI Internet Solutions\CSE HTML Validator\12.0
for Windows XP: C:\Documents and Settings\(username)\Application Data\AI Internet Solutions\CSE HTML Validator\12.0\htmlvalV120.cfg


After replacing the old configuration file (or files) with the new one, make sure that HTML Validator is using it by loading the new configuration file into HTML Validator or by restarting HTML Validator so that it rereads the new configuration at startup.

If you have problems with the new configuration file, then you may need to upgrade csevalidator.dll to use a new configuration file. csevalidator.dll contains the validation engine that reads and understands the configuration file.

You can verify exactly what configuration file is being used by loading CSE HTML Validator and going to Options->Validator Engine Options (Ctrl+F4) and then the 'Validator Engine->Config File' options page and checking to see what file is specified for the 'Config file'.

NOTE: I see that using "viewbox" does not cause an error so I will look into this, but the new config file should fix the error with "viewBox".

[AndyHood]

Hi Albert,

Thanks for the speedy response and new config file. Testing this new config, I find that:



*** THE BAD NEWS ***

This causes no error:
<svg xmlns="http://www.w3.org/2000/svg" thisattributedoesntexist=thisvaluehasnoinvertedcommas>

This causes no error:
<svg xmlns="http://www.w3.org/2000/svg" viewbox="0 0 10 10">



*** THE GOOD NEWS ***

This causes a sensible error:
<svg xmlns="http://www.w3.org/2000/svg" viewBOX="0 0 10 10">
error: The attribute "viewBOX" does not match (with case-sensitivity) "viewBox". NOTE: This appears to be an XHTML document and XHTML is case-sensitive.

This correct line doesn't cause an error:
<svg xmlns="http://www.w3.org/2000/svg" width="50px" height="25px" viewBox="-50 -25 100 50">
(except in Tidy HTML5, which doesn't recognise the SVG element but that's hardly your problem!)


Please let me know if my expectations are wrong or if there might be another new config in the pipeline,

Thanks,
Andy

[Albert Wiersch]

Please let me know if my expectations are wrong or if there might be another new config in the pipeline,

Hi Andy,

Actually I am working on an update and a new config file to go along with it. It should address the two "bad news" issues you reported, for the "svg" element at least.

However, CSE HTML Validator is not a SVG validator so it doesn't do thorough SVG checking. I'd be happy to improve it though, as long as the improvement is not too time consuming because I want to spend the most time on the HTML/CSS validators/checkers. I'll send you a link to the new build when ready. If you could try it and make other suggestions then that would be helpful and appreciated.

Do you write/create SVG by hand?

[AndyHood]

Hi Albert,
Thanks for your help in this; I'll certainly (and eagerly) test any new config.
We do create a large number of SVGs by hand but we create a larger number from graphics software and a still larger number dynamically from code. For the project that I'm tasked with for the moment, I imagine that a large proportion of the SVGs involved will be from vector graphics software... although we'll almost certainly take advantage of the wonderful facility of CSS styling SVG (which will inevitably require hand-crafting SVGs).
Thanks again,
Andy

[Albert Wiersch]

Hi Andy,

Thanks for the added info.

I'm not all that familiar with SVG, but if you could tell me the elements you use most when hand-crafting SVG (or the elements you'd most like to check), then I can check the specification and work on improving the checking for them in CSE HTML Validator, then send you a test version to try. I've done this with "svg", but what other SVG elements do you use most? Knowing this would be a good starting place to improve SVG checking.

[AndyHood]

Hi Albert,

I can't believe that I didn't think to copy it out but I've just lost a rather large reply that I tried to post but got timed out of the BB... doh! To summarize more briefly what I'd said, though:

It'd be nice to catch unquoted attributes throughout the document as warnings, but elevate these to the status of errors when the document is being served up as XHTML or Polyglot.

Then, for SVG (which I understood to be part of the not-yet-w3c-recommended HTML5 standard)... it'd be great to warn if the version attribute wasn't included, and error if it was with any value other than 1.0 1.1 1.2 or 2.0

Then it would be great to check that the namespace was correct (as this is vital to a conformant agent)

Finally, if you were to look deeper into the contents of the SVG it'd be great if you could look at the latest full-fat version of SVG (1.1) whose W3C Recommendation lives here:
http://www.w3.org/TR/SVG11/

And if you were to look at including support incrementally, then I'd suggest the order of attack as follows:
http://www.w3.org/TR/SVG11/shapes.html
http://www.w3.org/TR/SVG11/paths.html
http://www.w3.org/TR/SVG11/text.html
http://www.w3.org/TR/SVG11/linking.html

But note that by the time we get to linking, we're in very deep waters since, for compliance, the linking has to be properly namespaced and point to valid destinations within the document fragment. Any failure of a document to comply with this or any other requirement causes the whole document fragment to be "in error" and the specification then dictates that bad things SHOULD happen (such as the immediate cessation of animation), presumably for "debugging" purposes.

Finally, I think that if you wanted to be seriously pernickety, you could probably run a test for identically valued ID elements within the same SVG fragment... two elements sharing an ID within the SVG document fragment causes that fragment to be in error.

But I'll stop now since I am expecting a reply on the lines of "Whoa! That's way out of scope, fella!"... but I'll happily drone on some more if it'd help!

Thanks again,
Andy

[Albert Wiersch]

I can't believe that I didn't think to copy it out but I've just lost a rather large reply that I tried to post but got timed out of the BB... doh!

Sorry about that. I know that is frustrating.

It'd be nice to catch unquoted attributes throughout the document as warnings, but elevate these to the status of errors when the document is being served up as XHTML or Polyglot.

There is a Validator Engine Options to require that all attribute values be quoted, although it generates errors. If you need warnings, then let me know and I may be able to make it more configurable.

Then, for SVG (which I understood to be part of the not-yet-w3c-recommended HTML5 standard)... it'd be great to warn if the version attribute wasn't included, and error if it was with any value other than 1.0 1.1 1.2 or 2.0

OK, I think I can do this.

I'll also consider your other suggestions.

Finally, I think that if you wanted to be seriously pernickety, you could probably run a test for identically valued ID elements within the same SVG fragment... two elements sharing an ID within the SVG document fragment causes that fragment to be in error.

Shouldn't all ID values in an HTML5 document be unique, whether they are for HTML elements or SVG elements? If this is the case, it may not be too hard to improve this check and do more checking for SVG.

But I'll stop now since I am expecting a reply on the lines of "Whoa! That's way out of scope, fella!"... but I'll happily drone on some more if it'd help!

It's very helpful. Let me see what I can do and get you a test version to try.

Feel free (if you have time and want to of course) to send me any sample documents with SVG in them and the details about what you want CSE HTML Validator to check and what messages to generate. That would also be helpful.

[Albert Wiersch]

Hi Andy,

I just emailed you a link to a test build to download and try. It has better SVG checking. It should also warn you if the "version" attribute for "svg" is not used and generate an error if it's not set to a valid value.

It should now make sure the "id" values are unique for the entire document (though only for the "svg" elements whose attribute names are now checked in the test build I sent you).

[AndyHood]

Hi Albert,

Thanks for your email with the test build; I do appreciate your working on this so responsively, thank you. I've started testing it but can't spend too much time on it today; I'll certainly get back to you later but, in the meanwhile, just thought I'd ask the question: have you deliberately chosen to leave out 2.0 because it's not a recommendation yet? And 1.2? Whilst 1.2 Full will probably never make it to spec, 1.2 Tiny has been around since 2008 and can validly use the version="1.2" with or without the additional baseProfile="tiny".

Kind regards,
Andy

[Albert Wiersch]

No problem. Please report back when you can.

I had not considered SVG 2.0 as it didn't come up in my searches, I suppose because it's not a standard yet. I'm using SVG 1.1 as the basis for adding better SVG checking.

I've just added "1.2" and "2.0" as a valid value for the "version" attribute.

I do want to make SVG checking in CSE HTML Validator as useful as reasonably possible, but I can't spend too much time on it as the HTML & CSS part of the program get priority. However, your assistance is quite helpful and appreciated, and I will do what I can to improve support per your feedback.