perhaps you could give a more specific example of what you are suggesting?
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
Read-only does this case already for input.
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.
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.
Ah, I didn’t catch that looking at the computed properties for the area. Thanks for the correction.
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
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.