Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attributes are lowercased #10

Closed
svnhub opened this issue May 18, 2017 · 5 comments
Closed

Attributes are lowercased #10

svnhub opened this issue May 18, 2017 · 5 comments

Comments

@svnhub
Copy link

svnhub commented May 18, 2017

This impacts HTML5 with inline SVGs which require the viewBox attribute to be camel cased. Example:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 11.8 12.9">
    <path d="M0 0h3.2v3.5H0zm4.3 0h3.2v3.5H4.3zm4.3 0h3.2v3.5H8.6zM0 4.7h3.2v3.5H0zm4.3 0h3.2v3.5H4.3zm4.3 0h3.2v3.5H8.6zM0 9.4h3.2v3.5H0zm4.3 0h3.2v3.5H4.3zm4.3 0h3.2v3.5H8.6z"/>
</svg>
@kbadk
Copy link
Collaborator

kbadk commented May 18, 2017

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.

@svnhub
Copy link
Author

svnhub commented May 18, 2017

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).

@kbadk
Copy link
Collaborator

kbadk commented May 18, 2017

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. :-)

@svnhub
Copy link
Author

svnhub commented May 18, 2017

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.

@kbadk
Copy link
Collaborator

kbadk commented May 15, 2018

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.

@kbadk kbadk closed this as completed May 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants