All of WET 4.0's logo SVGs are implemented in a manner that fails HTML validation

[EricDunsworth]

A few days ago, validator/validator#422 was resolved. One of the commits that fixed it (validator/validator@1c02bc1) intentionally caused any elements containing tabindex attributes to trigger a validation error when situated within <a>/<button> elements.

Based on my research, validator/validator@1c02bc1's behaviour is in line with the W3C's HTML spec:

• Excerpt from the spec's tabindex section:
  • "An element with the tabindex attribute specified is interactive content."
• Excerpt from the spec's interactive content section:
  • "The tabindex attribute can also make any element into interactive content."
• Excerpt from the spec's content model section for the a element:
  • "Content model: Transparent, but there must be no interactive content or element descendants."

So, what does this have to do with WET? It turns out that most of WET 4.0's themes use SVG site logos that are structured as links containing an <object> element with a tabindex="-1" attribute. In other words, WET is nesting interactive content (<object tabindex="-1">) within other interactive content (<a>), which goes against the HTML spec.

As a result, the following error is now appearing when validating virtually any pages that use WET:

Error: An element with the attribute tabindex must not appear as a descendant of the <a> element.

From line 61, column 1; to line 61, column 83

<object type="image/svg+xml" tabindex="-1" data="./theme-wet-boew/assets/logo.svg">

IMO the best way of fixing this would be to replace the <object> element with <img> in WET's SVG images and remove the tabindex="-1" attributes. I believe it should work fine in all modern browsers and retain compatibility with the SVG image replacer polyfill.

@duboisp @LaurentGoderre @nschonni @pjackson28 @shawnthompson Any thoughts/concerns?

PS:
The reason a tabindex="-1" attribute was used on SVG <object> elements in the first place was because of #1432 (which was fixed by wet-boew/wet-boew-legacy@cc8b81c). Without that attribute, all browsers attempt to set keyboard tabbing focus inside the <object> element - which isn't desirable.

[duboisp]

@EricDunsworth great, thank for the background.

Do you know what browser required to load SVG via an object element?

[EricDunsworth]

@duboisp Based on https://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files, it seems like several years ago, browser support for SVGs referenced within<img> elements was somewhat inconsistent and the <object> element was considered to be more compatible across browsers. Nowadays it sounds like the <img> element is much better off than before and is now the ideal way of referencing non-interactive SVGs.

I also stumbled upon https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_Image, which states that Gecko implements several security restrictions on SVGs that are used as images (like when they're referenced via <img> elements). Those restrictions don't apply to SVGs referenced via <object> elements. But in WET's case, none of the logo images this issue covers are meant to be interactive. So I don't think the restrictions would be a show-stopper.

[duboisp]

@EricDunsworth can you submit a PR and then I would create a working example for testing.

[EricDunsworth]

@duboisp Yeah - that's my intent. Should have a PR open for this repo by COB or tomorrow depending on whether I run into any issues in my own testing.

[Bgolden67]

I was about to submit this issue this morning.. thanks for this. I will await your test before i implement your suggested fix.

[LaurentGoderre]

One thing to test is nested media queries in the SVG. We use one SVG that adapts on it's size to switch from the color to the black and white version.

With that being said, the SVG themselves can probably be updated to reflect more modern SVG patterns.

[EricDunsworth]

@LaurentGoderre Thanks for the heads up about the nested media queries. Looks like support for <img> elements referencing SVGs with embedded media queries is inconsistent in modern browsers.

IE11 honours @screen correctly, but Firefox and Opera (Blink) don't. That's going to make things a lot trickier. I was thinking of maybe trying something with a filter CSS property as a workaround, but that wouldn't work in IE11. Plus it might have unexpected side effects in browsers that support filter and honour @screen correctly (possibly Edge?).

SVGs referenced via <img> elements also seem to scale slightly differently than <object> in Firefox and Opera. So I might end up modifying the CSS properties that control the logo SVG's dimensions to try exactly matching the rendered size we were getting with the <object> element.

[EricDunsworth]

I believe I've come up with a viable way of dealing with the SVGs that have nested media queries. Adding something along the lines of @media print {filter: brightness(0%);} for the logo image will force the WET SVG logo to become black when printing in Firefox/Opera, without negatively impacting IE11/Edge.

I'll send out a PR once I figure out how best way to deal with the dimensions of <img> elements that reference the logo SVGs.

[EricDunsworth]

Just sent out #8282.

In the end, I wasn't able to figure out how to perfectly replicate the <object> logo's rendered dimensions with <img>. But the difference is so minor that it's highly unlikely to be noticeable in practice without performing head-to-head comparisons.