"inert" attribute


#41

perhaps you could give a more specific example of what you are suggesting?


#42

I don’t think <template> confusion will be too great. Inert makes page content skipped over in various accessibility functions by browsers and screen readers. The template element is a literal blueprint of content that is not active in any way available for developers to have a reusable segment of code. Easy enough to clear up the difference. Much better than the article vs section confusion.

Read-only does this case already for input.


#43

Another case where inert is already implemented (everywhere but MS it seems) is the <details> element. This hides the content except for the <summary> within it until selected. The internal contents unless the detail is active are not tabbable or as far as I can tell recognizable by screen readers. This is the exact use-case inert aims to provide.


#44

Actually I believe in the case of <details>, all but the <summary> is hidden from all users (similarly to display: none - e.g. getBoundingClientRect() for hidden <details> content is all 0s) - inert would allow content to be visible on screen, but not interactive.


#45

Ah, I didn’t catch that looking at the computed properties for the area. Thanks for the correction.


#46

Filed a bug for the inert concept naming collision, feel free to pile on the naming bikeshed there: https://github.com/WICG/inert/issues/39


#47

Maciej brought up in another thread that the template use is only a spec term, which most authors will be unaware of. Therefore the name overlap is unlikely to cause confusion. Internal spec terms shouldn’t constrain exposed interfaces.