Attributes are lowercased about file-system HOT 5 CLOSED

Good point - and no rush, btw, a simple workaround for now is to just have the SVG symbols in an asset and link them into the document using
<svg><use xlink:href="icons.svg#cool-svg-symbol"></use></svg>
then all the camel case sensitive stuff is in the symbols in the asset and it still acts as if it was inlined.

from file-system.

This is actually not a Webstrates or file system bug. If you try adding an attribute to any non-webstrates page using the Inspector, it will also be lowercased automatically. A workaround is to use Element.setAttribute manually.

E.g. inserting

<svg viewBox="0,0,100,100"></svg>

will change the attribute to viewbox rather than viewBox. However, if you first insert

<svg></svg>

and then do

$0.setAttribute("viewBox", "0,0,100,100");

the attribute will remain as viewBox, but only if the element is an <svg>.

It might be possible to create a workaround for this in the Webstrates code as well. I'll look into that.

from file-system.

That is interesting - the inspector doesn't lowercase svg attributes in Chromium here but most (all?) other elements have their attributes lowercased as soon as you click away from them. I guess they have hardcoded svg elements and their children as a special case.

Webstrates seemingly supports persisting the inspector-edited camelCase attribute in Chromium and can reload it in the same or other browsers as long as the filesystem script isn't running. If the script is running the attribute will be lowercased upon updating the file (even if the newly written file has the attribute camelcased when written from an external editor).

from file-system.

Indeed. Or the "hardcoding" is probably more related to the specific namespace that SVG elements use. You will notice that Element.namespaceURI is set to "http://www.w3.org/1999/xhtml" for virtually all elements, except <svg>s which use "http://www.w3.org/2000/svg".

Yes, the file system might screw around with casing then. We've ignoring casing on tag names (and possibly attributes, I don't recall), because the different browsers can't seem to agree on when the Element.tagName property should be capitalized. Again, it's something I'll look into. :-)

from file-system.

This has been fixed since switching jsonml-parse for my own parse5-based package html-to-jsonml a while back (9021b94).

parse5 adheres to the HTML5 specification, meaning HTML attributes are case-insensitive, but XML attributes are case-sensitive. As such, <div viewBox></div> (for instance) will indeed turn into <div viewbox></div>, but <svg viewBox></svg> will remain unchanged.

from file-system.