New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add accessibility role mappings to element definitions #3282

Open
LJWatson opened this Issue Dec 12, 2017 · 26 comments

Comments

9 participants
@LJWatson

LJWatson commented Dec 12, 2017

The developer's edition of HTML doesn't presently include role mapping information for elements. I think this information is helpful to authors, especially as we get closer to role parity for HTML.

It would be a positive step to add this information to this version of HTML. If there is agreement to do so, I'd be happy to work on it.

@brucelawson

This comment has been minimized.

Show comment
Hide comment
@brucelawson

brucelawson Dec 12, 2017

Happy to help, too. Anything that helps authors make more accessible sites is groovy.

brucelawson commented Dec 12, 2017

Happy to help, too. Anything that helps authors make more accessible sites is groovy.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 12, 2017

Member

I think this would be great, both in the developer's edition and the normal one. The main issue is keeping it up to date, so it's not just a source of confusion that could at times contradict the normative source in the AAM spec. So we should get this to be auto-generated from the AAM spec via the build process.

Probably the first step, then, is to have some JSON file (or similar simple-to-parse format) with the mappings, hosted and maintained by the AAM spec editor(s) and kept always updated in parallel with AAM. Does that exist yet perhaps? I'm on my phone and haven't checked the AAM spec or its repo yet.

Member

domenic commented Dec 12, 2017

I think this would be great, both in the developer's edition and the normal one. The main issue is keeping it up to date, so it's not just a source of confusion that could at times contradict the normative source in the AAM spec. So we should get this to be auto-generated from the AAM spec via the build process.

Probably the first step, then, is to have some JSON file (or similar simple-to-parse format) with the mappings, hosted and maintained by the AAM spec editor(s) and kept always updated in parallel with AAM. Does that exist yet perhaps? I'm on my phone and haven't checked the AAM spec or its repo yet.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Dec 12, 2017

I don't think there is a JSON export of the mappings data ATM, but assume one could be created.

LJWatson commented Dec 12, 2017

I don't think there is a JSON export of the mappings data ATM, but assume one could be created.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Dec 12, 2017

Worth noting that role conformance for HTML is defined in ARIA in HTML, rather than the HTML AAM (though the AAM is the source of some data within the ARIA in HTML spec).

LJWatson commented Dec 12, 2017

Worth noting that role conformance for HTML is defined in ARIA in HTML, rather than the HTML AAM (though the AAM is the source of some data within the ARIA in HTML spec).

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 12, 2017

Member

Hmm, I thought this issue was about accessibility role mappings though, not role conformance?

Member

domenic commented Dec 12, 2017

Hmm, I thought this issue was about accessibility role mappings though, not role conformance?

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Dec 12, 2017

The suggestion is to reference the implicit role for each element, but I think there's a case to be made for also referencing the explicit roles that may be applied.

LJWatson commented Dec 12, 2017

The suggestion is to reference the implicit role for each element, but I think there's a case to be made for also referencing the explicit roles that may be applied.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 12, 2017

Member

I see. So this would basically be reversing f619b0c then, right? (With much more up-to-date content, of course; I know @stevefaulkner and others have done a much more conscientious job maintaining that content over the last few years than Hixie did when it lived in HTML pre-2015.)

If that's the proposal then I'd really worry about duplicating the same information in two places which could get out of sync. So if folks have come to believe over the last two years that this is best in HTML instead of in a separate document, then perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?

Member

domenic commented Dec 12, 2017

I see. So this would basically be reversing f619b0c then, right? (With much more up-to-date content, of course; I know @stevefaulkner and others have done a much more conscientious job maintaining that content over the last few years than Hixie did when it lived in HTML pre-2015.)

If that's the proposal then I'd really worry about duplicating the same information in two places which could get out of sync. So if folks have come to believe over the last two years that this is best in HTML instead of in a separate document, then perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?

@sideshowbarker

This comment has been minimized.

Show comment
Hide comment
@sideshowbarker

sideshowbarker Dec 12, 2017

Member

So this would basically be reversing f619b0c … perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?

I don’t think that would be a good idea. There was a strong rationale for moving it out, and I believe that rationale remains as strong as it always has been. I don’t know what problems merging it back in would fix. Keeping the normative text in the ARIA in HTML spec, there’s nothing that prevents also having (repeating) the per-element-ARIA-roles information at point of use in HTML non-normatively (adding meta-language as needed to HTML to make it clear that it’s just referencing ARIA in HTML).

As mentioned in earlier comments, that just comes with the logistical need to make sure the info in the HTML spec stays in sync with what the ARIA in HTML spec has. But that’s doable.

Member

sideshowbarker commented Dec 12, 2017

So this would basically be reversing f619b0c … perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?

I don’t think that would be a good idea. There was a strong rationale for moving it out, and I believe that rationale remains as strong as it always has been. I don’t know what problems merging it back in would fix. Keeping the normative text in the ARIA in HTML spec, there’s nothing that prevents also having (repeating) the per-element-ARIA-roles information at point of use in HTML non-normatively (adding meta-language as needed to HTML to make it clear that it’s just referencing ARIA in HTML).

As mentioned in earlier comments, that just comes with the logistical need to make sure the info in the HTML spec stays in sync with what the ARIA in HTML spec has. But that’s doable.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Dec 12, 2017

<So this would basically be reversing f619b0c then, right?<

AIRC the primary reason for that PR was that the ARIA in HTML spec had been pulled out of the W3C HTML spec into its own module.

<So if folks have come to believe over the last two years that this is best in HTML instead of in a separate document, then perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?<

The HTML AAM is one of a set of closely related and co-ordinated specs maintained at W3C. Fragmenting that work makes no sense to me.

Providing information in context to help authors does make sense though.

LJWatson commented Dec 12, 2017

<So this would basically be reversing f619b0c then, right?<

AIRC the primary reason for that PR was that the ARIA in HTML spec had been pulled out of the W3C HTML spec into its own module.

<So if folks have come to believe over the last two years that this is best in HTML instead of in a separate document, then perhaps what we need to do is merge those portions of AAM/ARIA in HTML back into the HTML Standard?<

The HTML AAM is one of a set of closely related and co-ordinated specs maintained at W3C. Fragmenting that work makes no sense to me.

Providing information in context to help authors does make sense though.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 12, 2017

Member

I guess I'm still unclear on what's being proposed. If not duplicating the information from AAM/ARIA in HTML into the HTML Standard, what is the proposal?

If it is about duplicating the information, then although having everything in one document is helpful for web authors in some cases, it's unclear how much that makes sense if another document is where the work is actually being done. In all other cases we prefer to reference other documents instead of copying their contents into the spec.

Member

domenic commented Dec 12, 2017

I guess I'm still unclear on what's being proposed. If not duplicating the information from AAM/ARIA in HTML into the HTML Standard, what is the proposal?

If it is about duplicating the information, then although having everything in one document is helpful for web authors in some cases, it's unclear how much that makes sense if another document is where the work is actually being done. In all other cases we prefer to reference other documents instead of copying their contents into the spec.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 13, 2017

Member

I'm somewhat surprised at the pushback against including normative accessibility mappings in the HTML Standard. It seems that just like the APIs for elements and their rendering information, you'd want accessibility mappings to be tightly coupled so accessibility gets considered when these elements get implemented or refactored in implementations.

And furthermore, it would also ensure accessibility gets considered when adding new elements or changing existing elements. Much more so than it is today as today it is easily overlooked, which goes somewhat against the idea that you need to consider accessibility from the get go.

Member

annevk commented Dec 13, 2017

I'm somewhat surprised at the pushback against including normative accessibility mappings in the HTML Standard. It seems that just like the APIs for elements and their rendering information, you'd want accessibility mappings to be tightly coupled so accessibility gets considered when these elements get implemented or refactored in implementations.

And furthermore, it would also ensure accessibility gets considered when adding new elements or changing existing elements. Much more so than it is today as today it is easily overlooked, which goes somewhat against the idea that you need to consider accessibility from the get go.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk
Member

annevk commented Dec 13, 2017

@annevk annevk added the dev edition label Dec 13, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 13, 2017

Member

there's too much politics tied to this, but let me see: am i right in understanding that there's a question here of why there's a pushback to moving AAM/ARIA in HTML over to the WHATWG spec directly? If so, I may just quote something @jakearchibald said to me on twitter yesterday: "why should the work move to a fork?" (https://twitter.com/jaffathecake/status/940513109118251008)

It would be good if the WHATWG spec included all the accessibility mappings etc, but asking for the work which quite nicely is proceeding under W3C be moved wholesale here seems a bit of a landgrab. Unless I'm misunderstanding the point.

Member

patrickhlauke commented Dec 13, 2017

there's too much politics tied to this, but let me see: am i right in understanding that there's a question here of why there's a pushback to moving AAM/ARIA in HTML over to the WHATWG spec directly? If so, I may just quote something @jakearchibald said to me on twitter yesterday: "why should the work move to a fork?" (https://twitter.com/jaffathecake/status/940513109118251008)

It would be good if the WHATWG spec included all the accessibility mappings etc, but asking for the work which quite nicely is proceeding under W3C be moved wholesale here seems a bit of a landgrab. Unless I'm misunderstanding the point.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 13, 2017

Member

I tried to give a perspective from an engineering standpoint as to what I think would help improve accessibility by making a larger group of people responsible for maintaining it rather than applying it as a monkey patch of sorts on top of the HTML Standard. That is, from an architecture standpoint the split does not make sense to me. (And also results in some implementation inefficiencies since there the cost is also typically being carried by a rather small team rather than the folks that maintain the implementation of the element and its API.)

I guess you're saying that's not possible for political reasons and that's too bad. I really think it could help a lot.

Member

annevk commented Dec 13, 2017

I tried to give a perspective from an engineering standpoint as to what I think would help improve accessibility by making a larger group of people responsible for maintaining it rather than applying it as a monkey patch of sorts on top of the HTML Standard. That is, from an architecture standpoint the split does not make sense to me. (And also results in some implementation inefficiencies since there the cost is also typically being carried by a rather small team rather than the folks that maintain the implementation of the element and its API.)

I guess you're saying that's not possible for political reasons and that's too bad. I really think it could help a lot.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 13, 2017

Member

of course it would be so much easier if everything was worked on just in one place. but of course the reality of the situation is that WHATWG forked HTML. saying now that it would be easier if other things worked on at W3C also moved over to WHATWG of course makes sense from an engineering point of view, but I really doubt it will find much traction.

Member

patrickhlauke commented Dec 13, 2017

of course it would be so much easier if everything was worked on just in one place. but of course the reality of the situation is that WHATWG forked HTML. saying now that it would be easier if other things worked on at W3C also moved over to WHATWG of course makes sense from an engineering point of view, but I really doubt it will find much traction.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 13, 2017

Member

so with that said, is there a way of cross-referencing W3C stuff from WHATWG that avoids duplication? and is there a way to ensure that people working on WHATWG stuff also ensure that if their stuff has potential a11y implications, it gets properly reviewed? (and no, i don't think @whatwg/a11y alone can carry that particular burden)

Member

patrickhlauke commented Dec 13, 2017

so with that said, is there a way of cross-referencing W3C stuff from WHATWG that avoids duplication? and is there a way to ensure that people working on WHATWG stuff also ensure that if their stuff has potential a11y implications, it gets properly reviewed? (and no, i don't think @whatwg/a11y alone can carry that particular burden)

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 13, 2017

Member

The W3C i18n community has tooling that allows them to track a specific label that we apply to issues that we think concern i18n. Does the W3C a11y community have such tooling? (Of course, this still doesn't help in the case where it's forgotten due to lack of tight coupling. For that you need some ongoing monitoring and review.)

Member

annevk commented Dec 13, 2017

The W3C i18n community has tooling that allows them to track a specific label that we apply to issues that we think concern i18n. Does the W3C a11y community have such tooling? (Of course, this still doesn't help in the case where it's forgotten due to lack of tight coupling. For that you need some ongoing monitoring and review.)

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 13, 2017

Member

On the same note, is there tooling that allows WHATWG to track changes to W3C AAM etc to review any potential impact of changes there?

Member

patrickhlauke commented Dec 13, 2017

On the same note, is there tooling that allows WHATWG to track changes to W3C AAM etc to review any potential impact of changes there?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 13, 2017

Member

We could set something up if that's useful. I think for now if you ping @domenic in any relevant PR that'd be great.

Member

annevk commented Dec 13, 2017

We could set something up if that's useful. I think for now if you ping @domenic in any relevant PR that'd be great.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Dec 13, 2017

Collaborator

the reality of the situation is that WHATWG forked HTML

When the WHATWG 'forked' HTML, it was not being worked on at the W3, so it's kinda different to the W3 fork of the WHATWG HTML spec.

Collaborator

jakearchibald commented Dec 13, 2017

the reality of the situation is that WHATWG forked HTML

When the WHATWG 'forked' HTML, it was not being worked on at the W3, so it's kinda different to the W3 fork of the WHATWG HTML spec.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 13, 2017

Member

@jakearchibald thanks for the history clarification. now, back to topic here: accessibility specs (and how they tie/are closely coupled with html and various other related specs) are being actively worked on at W3C, so let's discuss how this can be moved forward.

Member

patrickhlauke commented Dec 13, 2017

@jakearchibald thanks for the history clarification. now, back to topic here: accessibility specs (and how they tie/are closely coupled with html and various other related specs) are being actively worked on at W3C, so let's discuss how this can be moved forward.

@guest271314

This comment has been minimized.

Show comment
Hide comment
@guest271314

guest271314 Dec 13, 2017

Contributor

@annevk

If we can include normative accessibility mappings in the HTML Standard can we also fork Web Speech API to HTML Standard? There is a relationship between accessibility mappings and Web Speech API in that we can, for example, convert Braille to audio, and audio to Braille, etc.; see #2823.

While HTML Standard can make efforts to stay up to date with W3 version, will W3 also remain up to date with any changes made at HTML Standard version relevant to accessibility?

//cc @domenic

Contributor

guest271314 commented Dec 13, 2017

@annevk

If we can include normative accessibility mappings in the HTML Standard can we also fork Web Speech API to HTML Standard? There is a relationship between accessibility mappings and Web Speech API in that we can, for example, convert Braille to audio, and audio to Braille, etc.; see #2823.

While HTML Standard can make efforts to stay up to date with W3 version, will W3 also remain up to date with any changes made at HTML Standard version relevant to accessibility?

//cc @domenic

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 13, 2017

Member

I think this thread is getting off-topic; @patrickhlauke I think you were not over the line but just to make things a bit more amicable perhaps you could have avoided provoking people with the fork comment; @jakearchibald and @guest271314 I think you are rather off-topic and I'd encourage you to take such conversations elsewhere. Let's please turn back to the issue opened by the OP and give that proposal the full attention it deserves.

For my part, I understand @annevk's point about the technical benefits of integrating the work. But, I think if the editors working on those mappings are more comfortable in a different venue, we definitely should be respectful of that. I don't at all think there should be a "landgrab" there; it's up to the people doing the work, and if they think it would be nice to integrate, then we'd welcome them, but if they'd rather keep it separate, that's fine too.

From my point of view that leaves us in a place where we want to address the question

is there a way of cross-referencing W3C stuff from WHATWG that avoids duplication?

And I think we can, and already do! That's the intent of https://html.spec.whatwg.org/multipage/dom.html#wai-aria. So I'm wondering if there's some way we could improve that to address the OP's point, although again, without duplication. I'd love to hear more about the ideas there.

(Note: again, I think this is a separate question from whether @patrickhlauke thinks that the folks in the @whatwg/a11y team are able to provide good review, which he mentions in his next sentence. That concern should be moved to whatwg/meta, if people want to discuss it further.)

Member

domenic commented Dec 13, 2017

I think this thread is getting off-topic; @patrickhlauke I think you were not over the line but just to make things a bit more amicable perhaps you could have avoided provoking people with the fork comment; @jakearchibald and @guest271314 I think you are rather off-topic and I'd encourage you to take such conversations elsewhere. Let's please turn back to the issue opened by the OP and give that proposal the full attention it deserves.

For my part, I understand @annevk's point about the technical benefits of integrating the work. But, I think if the editors working on those mappings are more comfortable in a different venue, we definitely should be respectful of that. I don't at all think there should be a "landgrab" there; it's up to the people doing the work, and if they think it would be nice to integrate, then we'd welcome them, but if they'd rather keep it separate, that's fine too.

From my point of view that leaves us in a place where we want to address the question

is there a way of cross-referencing W3C stuff from WHATWG that avoids duplication?

And I think we can, and already do! That's the intent of https://html.spec.whatwg.org/multipage/dom.html#wai-aria. So I'm wondering if there's some way we could improve that to address the OP's point, although again, without duplication. I'd love to hear more about the ideas there.

(Note: again, I think this is a separate question from whether @patrickhlauke thinks that the folks in the @whatwg/a11y team are able to provide good review, which he mentions in his next sentence. That concern should be moved to whatwg/meta, if people want to discuss it further.)

@othermaciej

This comment has been minimized.

Show comment
Hide comment
@othermaciej

othermaciej Dec 13, 2017

I am not entirely clear on what this issue is originally asking for. I could imagine 3 possibilities:

(1) Reference appropriate A11Y specifications for the normative accessibility implementation requirements for HTML elements, by pointing to canonical specs defining this. My understanding is that this is already the case, but perhaps we could make the reference clearer or better. If there's a specific suggestion for improving the existing references, it would be great to hear it.

(2) Move some or all of the normative accessibility requirements from other specs into HTML. There are benefits to this from the perspective of readability for browser engineers and content authors, and spec development benefits since it would be harder to forget accessibility for new elements.. And it sounds like HTML editors would be open to this. However, we would only want to do this if the contributors of the current specifications actually wanted this. There is no intent to fork or land grab here.

(3) Duplicate normative accessibility requirements by copying text from other specifications, where the official requirement would still be in that other spec. This is a risky choice. It would be hard to maintain the text in sync, and there would be a risk of mismatches. From the perspective of a browser engine implementor, I'd worry that a possibly out-of-sync copy would be a trap for me and my colleagues, more than a benefit. If this is in fact what's being proposed, then perhaps I misunderstand the details and it might work out better than I think.

Out of these, Reference is the status quo, Move has potential benefits but is ultimately up to the writers and contributors of those specs, and Duplicate is tricky to do unless very carefully thought out.

othermaciej commented Dec 13, 2017

I am not entirely clear on what this issue is originally asking for. I could imagine 3 possibilities:

(1) Reference appropriate A11Y specifications for the normative accessibility implementation requirements for HTML elements, by pointing to canonical specs defining this. My understanding is that this is already the case, but perhaps we could make the reference clearer or better. If there's a specific suggestion for improving the existing references, it would be great to hear it.

(2) Move some or all of the normative accessibility requirements from other specs into HTML. There are benefits to this from the perspective of readability for browser engineers and content authors, and spec development benefits since it would be harder to forget accessibility for new elements.. And it sounds like HTML editors would be open to this. However, we would only want to do this if the contributors of the current specifications actually wanted this. There is no intent to fork or land grab here.

(3) Duplicate normative accessibility requirements by copying text from other specifications, where the official requirement would still be in that other spec. This is a risky choice. It would be hard to maintain the text in sync, and there would be a risk of mismatches. From the perspective of a browser engine implementor, I'd worry that a possibly out-of-sync copy would be a trap for me and my colleagues, more than a benefit. If this is in fact what's being proposed, then perhaps I misunderstand the details and it might work out better than I think.

Out of these, Reference is the status quo, Move has potential benefits but is ultimately up to the writers and contributors of those specs, and Duplicate is tricky to do unless very carefully thought out.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Dec 14, 2017

The information in ARIA in HTML is intended primarily for conformance tools. It includes the implicit roles for elements (documented in the Core AAM and HTML AAM specs), plus the explicit roles that are permitted on each element.

The suggestion is to pull this information in from ARIA in HTML as an informative reference for authors. Where the characteristics of an element (categories, content model etc.) are shown for each element, the "implicit role" and "permitted roles" could be added.

Keeping the information up to date is an important consideration. The information in ARIA in HTML is very stable. Most changes to date have been the result of a new version of ARIA being released, rather than incremental/scattered alterations, so doing it manually isn't impossible.

That said, it would be easier for everyone if some tooling could be deployed to automate it. Ping @sideshowbarker for thoughts?

Discussing this idea with @stevefaulkner, he suggested attaching a particular label to commits to ARIA in HTML that would flag them for inclusion in the HTML standard.

LJWatson commented Dec 14, 2017

The information in ARIA in HTML is intended primarily for conformance tools. It includes the implicit roles for elements (documented in the Core AAM and HTML AAM specs), plus the explicit roles that are permitted on each element.

The suggestion is to pull this information in from ARIA in HTML as an informative reference for authors. Where the characteristics of an element (categories, content model etc.) are shown for each element, the "implicit role" and "permitted roles" could be added.

Keeping the information up to date is an important consideration. The information in ARIA in HTML is very stable. Most changes to date have been the result of a new version of ARIA being released, rather than incremental/scattered alterations, so doing it manually isn't impossible.

That said, it would be easier for everyone if some tooling could be deployed to automate it. Ping @sideshowbarker for thoughts?

Discussing this idea with @stevefaulkner, he suggested attaching a particular label to commits to ARIA in HTML that would flag them for inclusion in the HTML standard.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 14, 2017

Member

Hmm, so to be clear, you are proposing Duplicate, right? I am still not sure whether that is a good idea. I don't believe there are any other specs that we choose to Duplicate instead of Reference. I'd love to hear from other editors on their thoughts.

One idea is that, if the goal is to provide better guidance for developers, perhaps instead of creating duplications in specs, updating MDN might make more sense? Remember that the HTML Standard for Developers is not meant to be a reference for everything related to HTML and HTML technologies, but just a view of the HTML Standard which subsets to the developer-applicable information. MDN is better for the former role.

Member

domenic commented Dec 14, 2017

Hmm, so to be clear, you are proposing Duplicate, right? I am still not sure whether that is a good idea. I don't believe there are any other specs that we choose to Duplicate instead of Reference. I'd love to hear from other editors on their thoughts.

One idea is that, if the goal is to provide better guidance for developers, perhaps instead of creating duplications in specs, updating MDN might make more sense? Remember that the HTML Standard for Developers is not meant to be a reference for everything related to HTML and HTML technologies, but just a view of the HTML Standard which subsets to the developer-applicable information. MDN is better for the former role.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment