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

Align <main> a bit with contemporary AT #3326

Merged
merged 1 commit into from Jan 15, 2018

Conversation

6 participants
@annevk
Member

annevk commented Jan 5, 2018

The various examples changed here do not lead to a good experience in existing AT and there's no reason to believe AT will change so it seems best to give different advice.


/grouping-content.html ( diff )
/iframe-embed-object.html ( diff )
/interactive-elements.html ( diff )
/sections.html ( diff )

Align <main> a bit with contemporary AT
The various examples changed here do not lead to a good experience in existing AT and there's no reason to believe AT will change so it seems best to give different advice.
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk
Member

annevk commented Jan 5, 2018

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 5, 2018

Member

FWIW, I wrote some additional rationale here (and things to look at to further improve things here): #100 (comment).

Member

annevk commented Jan 5, 2018

FWIW, I wrote some additional rationale here (and things to look at to further improve things here): #100 (comment).

@hidde

This comment has been minimized.

Show comment
Hide comment
@hidde

hidde Jan 5, 2018

Member

This looks very good to me, it prioritises user needs. With the removal of main in examples where it was main of things other than the document, we have removed examples that potentially yield weird semantics for AT users.

Member

hidde commented Jan 5, 2018

This looks very good to me, it prioritises user needs. With the removal of main in examples where it was main of things other than the document, we have removed examples that potentially yield weird semantics for AT users.

@hidde

hidde approved these changes Jan 5, 2018

<code>main</code> elements. For example, a page with multiple <code>article</code> elements might
need to indicate the dominant contents of each such element.</p>
<p class="note">While there is no restriction as to the number of <code>main</code> elements in a
document, web developers are encouraged to stick to a single element.</p>

This comment has been minimized.

@marcysutton

marcysutton Jan 5, 2018

web developers are encouraged to stick to a single element

Should this say "single visible element" or does that add too much complexity?

One exception to recommending a single <main> could be in a layered web application where background <main> elements are properly rendered inert from AT. Blackboard has a good example of this type of UI. https://www.youtube.com/watch?v=6tmBd9USe6g

@marcysutton

marcysutton Jan 5, 2018

web developers are encouraged to stick to a single element

Should this say "single visible element" or does that add too much complexity?

One exception to recommending a single <main> could be in a layered web application where background <main> elements are properly rendered inert from AT. Blackboard has a good example of this type of UI. https://www.youtube.com/watch?v=6tmBd9USe6g

This comment has been minimized.

@foolip

foolip Jan 5, 2018

Member

Since this is just advice, leaving out the edge cases where multiple elements makes sense to me.

@foolip

foolip Jan 5, 2018

Member

Since this is just advice, leaving out the edge cases where multiple elements makes sense to me.

This comment has been minimized.

@annevk

annevk Jan 6, 2018

Member

Yeah, I was hoping to leave more detailed advice up to a future iteration, once we have more agreement on the edge cases.

@annevk

annevk Jan 6, 2018

Member

Yeah, I was hoping to leave more detailed advice up to a future iteration, once we have more agreement on the edge cases.

<p>The <code>main</code> element can be used as a container for the dominant contents of another
element. It <span>represents</span> its children.</p>
<p>The <code>main</code> element can be used as a container for the dominant contents of the
document. It <span>represents</span> its children.</p>
<p class="note">The <code>main</code> element is distinct from the <code>section</code> and

This comment has been minimized.

@marcysutton

marcysutton Jan 5, 2018

Should this mention of no effect on the document outline for <main> be removed like line 17273?

@marcysutton

marcysutton Jan 5, 2018

Should this mention of no effect on the document outline for <main> be removed like line 17273?

This comment has been minimized.

@annevk

annevk Jan 6, 2018

Member

I only removed it there because I removed main from the example. This example still uses main though.

@annevk

annevk Jan 6, 2018

Member

I only removed it there because I removed main from the example. This example still uses main though.

@foolip

foolip approved these changes Jan 5, 2018

<code>main</code> elements. For example, a page with multiple <code>article</code> elements might
need to indicate the dominant contents of each such element.</p>
<p class="note">While there is no restriction as to the number of <code>main</code> elements in a
document, web developers are encouraged to stick to a single element.</p>

This comment has been minimized.

@foolip

foolip Jan 5, 2018

Member

Since this is just advice, leaving out the edge cases where multiple elements makes sense to me.

@foolip

foolip Jan 5, 2018

Member

Since this is just advice, leaving out the edge cases where multiple elements makes sense to me.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jan 6, 2018

Contributor

As mentioned in #100 (comment) developers appreciate clarity. I suggest that if devs are being encouraged to stick to one main element a normative SHOULD requirement is appropriate, which will provide a warning in conformance checkers (ping @sideshowbarker)

Contributor

stevefaulkner commented Jan 6, 2018

As mentioned in #100 (comment) developers appreciate clarity. I suggest that if devs are being encouraged to stick to one main element a normative SHOULD requirement is appropriate, which will provide a warning in conformance checkers (ping @sideshowbarker)

@taweesakteejantuk66

This comment has been minimized.

Show comment
Hide comment
@taweesakteejantuk66

taweesakteejantuk66 commented Jan 6, 2018

thanks

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 6, 2018

Member

@stevefaulkner I think that's where I want to end up as well, but I was thinking it'd be good to make these improvements first as I expect these to be less controversial.

Member

annevk commented Jan 6, 2018

@stevefaulkner I think that's where I want to end up as well, but I was thinking it'd be good to make these improvements first as I expect these to be less controversial.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jan 6, 2018

Contributor

@annevk good to hear, it is only appears controversial because a few owners of the spec have strong opinions, for almost everybody else in the community including dev's and users it is a sensible change to align the definition with expected usage and user agent expression. So i suggest that sooner rather than later would be preferable.

This would, make advice/requirements much clearer for devs to the benefit of users. I think it would then resolve #100 after 2 1/2 years and 100+ of comments.

To be clear, suggested changes:

  • define body as representing the content of a document currently "The body element represents the main content of the document."
  • define main as representing the main content of a document currently "It represents its children."
  • should requirement on single use of main

I personally can live with the remaining differences in the original definition not being reflected in the whatwg definition and this would provide an opportunity to align the 2 definitions, to reduce confusion.

Contributor

stevefaulkner commented Jan 6, 2018

@annevk good to hear, it is only appears controversial because a few owners of the spec have strong opinions, for almost everybody else in the community including dev's and users it is a sensible change to align the definition with expected usage and user agent expression. So i suggest that sooner rather than later would be preferable.

This would, make advice/requirements much clearer for devs to the benefit of users. I think it would then resolve #100 after 2 1/2 years and 100+ of comments.

To be clear, suggested changes:

  • define body as representing the content of a document currently "The body element represents the main content of the document."
  • define main as representing the main content of a document currently "It represents its children."
  • should requirement on single use of main

I personally can live with the remaining differences in the original definition not being reflected in the whatwg definition and this would provide an opportunity to align the 2 definitions, to reduce confusion.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 7, 2018

Member

@annevk, should this be prefixed with "Editorial:", or did I miss some requirement on UAs or validators changing here?

I also think it makes sense to make these changes first, leaving #100 open.

Member

foolip commented Jan 7, 2018

@annevk, should this be prefixed with "Editorial:", or did I miss some requirement on UAs or validators changing here?

I also think it makes sense to make these changes first, leaving #100 open.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 8, 2018

Member

@foolip when we correct prose we don't qualify it as "Editorial", even if it's non-normative prose. "Editorial" is for more trivial changes.

Member

annevk commented Jan 8, 2018

@foolip when we correct prose we don't qualify it as "Editorial", even if it's non-normative prose. "Editorial" is for more trivial changes.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 8, 2018

Member

@annevk, OK then :) Do you want more review/sign-off of this before merging?

Member

foolip commented Jan 8, 2018

@annevk, OK then :) Do you want more review/sign-off of this before merging?

@annevk annevk merged commit 97d8432 into master Jan 15, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@annevk annevk deleted the annevk/main branch Jan 15, 2018

sideshowbarker added a commit to validator/validator that referenced this pull request Jan 31, 2018

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