Camel-cased viewBox on SVG in HTML document matched case sensitively [Deviation from Specification]

[Ahmad-S792]

Hi Team,

Just wanted to flag this to track and get input.

Blink Commit - https://chromium.googlesource.com/chromium/src.git/+/b946c5d62ca51dff877a5a1947c62e78756bb38e

Test Case - https://jsfiddle.net/4crbzp38/

*** Chrome Canary 144 ***

Passes all

*** Firefox Nightly 147 and Safari 26.1 ***

Fails below:

Camel-cased viewBox on svg in html document should match case-sensitively. Intentional deviation from the spec.

Normalized camel-cased viewBox on svg in html document should match case-sensitively. Intentional deviation from the spec.

---

I am not sure whether it has any web compatibility impact or whether it is something up to UA but if it something we can standardised either matching Blink or matching Firefox & Safari (which is following spec, it looks like), it would good to clarify this difference.

Thanks!

[Ahmad-S792]

@karlcow - FYI

[Ahmad-S792]

It is also the case for foreignObject - https://chromium.googlesource.com/chromium/src/+/bab4aa7b9

@karlcow - it is same thing which I discussed with you prior to TPAC, so just raising issue now here with more details.

[karlcow]

The text from the Chromium patch is:

Match camelCased SVG attributes selectors in html documents.

Attribute names are stored lower-case in stylesheets in HTML documents.
SVG attribute names are normalized to the camelCase form in HTML
documents. That meant SVG attributes with camelCase like viewBox never
matched in HTML documents.

We had the same issue for camelCased element names in [1]. In that CL
we decided to allow insensitive matching for non-html elements in order
to avoid having to store the tag names twice in CSSSelector, even if
that is wrong according to the HTML spec. This CL does exactly the same
for attribute selectors.

The code from @Ahmad-S792

<style>
    [viewBox] { color: green }
    [VIEWBOX] { background-color: green }
</style>
<div viewBox id="t1"></div>
<div viewbox id="t2"></div>
<svg viewBox="0 0 800 10" id="t3"></svg>
<svg VIEWBOX="0 0 800 10" id="t4"></svg>

The tests failing on Safari AND Chrome in the jsfiddle from @Ahmad-S792

• <svg viewBox="0 0 800 10" id="t3"></svg> with getComputedStyle(t3).backgroundColor, "rgb(0, 128, 0). Green has not been applied (aka VIEWBOX didn't match)
• <svg VIEWBOX="0 0 800 10" id="t4"></svg> with getComputedStyle(t4).backgroundColor, "rgb(0, 128, 0). Green has not been applied (aka VIEWBOX didn't match)

[karlcow]

@nikolaszimmermann @shallawa (webkit) @longsonr (gecko) @zcorpan (html spec) for thoughts.

[karlcow]

The thing which is bothering me a bit is that it doesn't seem that Chromium deviates from the spec for compatibility reasons, but because of code engineering. Not sure that's a valid argument, specifically with Gecko and WebKit behaving as expected.

[longsonr]

This doesn't seem like a good idea since it deliberately creates browser incompatibilities.

[shepazu]

FWIW, over the years, I saw dozens of people get caught up by viewbox vs. viewBox. Case-sensitivity is not a useful distinction in SVG, because there's no instance where the only difference between 2 tokens was the case.

A bit off-topic, but it was a mistake to make SVG (and maybe XML) case-sensitive in the first place, and if there were a way to make parsing case-insensitive (an XML5), that would put the burden on the machines and not the humans.

[Crissov]

((more off-topic: I remember, when currentColor was carried over from SVG to CSS over 20 years ago, suggesting to relax CSS keyword (and property name) syntax so that they would not just be case insensitive but also hyphenation insensitive.))