AST Explorer link: https://astexplorer.net/#/gist/25e9a360157ab2e56a7bf14ac22daa5b/196c723e25cf99ec923c3ce0be36664817b264d2
<svg viewBox="0 0 100 100"></svg>
Given the SVG element above, the AST produces an svg element node whose attrs array has a { name: 'viewBox', value: '0 0 100 100' } object, but that name doesn't match anything in the element's own sourceCodeLocation.attrs hash. Instead, that hash has a viewbox (all lowercase) key. (See the AST Explorer screenshot below).
Is this by design? If so, is it recommended that location lookup always use .toLowerCase()? Or are SVG camelCase attributes an exception that should be handled in a special case in AST consumers? Have I missed documentation on this?
Or is this a bug? If so, there are a number of SVG camelCase attributes that should likely be handled similarly.
AST Explorer link: https://astexplorer.net/#/gist/25e9a360157ab2e56a7bf14ac22daa5b/196c723e25cf99ec923c3ce0be36664817b264d2
Given the SVG element above, the AST produces an svg element node whose
attrsarray has a{ name: 'viewBox', value: '0 0 100 100' }object, but that name doesn't match anything in the element's ownsourceCodeLocation.attrshash. Instead, that hash has aviewbox(all lowercase) key. (See the AST Explorer screenshot below).Is this by design? If so, is it recommended that location lookup always use
.toLowerCase()? Or are SVG camelCase attributes an exception that should be handled in a special case in AST consumers? Have I missed documentation on this?Or is this a bug? If so, there are a number of SVG camelCase attributes that should likely be handled similarly.