Skip to content
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

CFC: Publish HTML Review Draft as W3C CR #22

Closed
LJWatson opened this issue Jan 4, 2022 · 18 comments
Closed

CFC: Publish HTML Review Draft as W3C CR #22

LJWatson opened this issue Jan 4, 2022 · 18 comments

Comments

@LJWatson
Copy link

LJWatson commented Jan 4, 2022

This is a Call For Consensus (CFC) to publish the January 2021 HTML Review Draft as a W3C Candidate Recommendation (CR).

Wide review was requested in July 2021. There were unresolved privacy concerns from the Privacy Interest Group (PING), and so the proposal is to include this non-normative statement to the CR.

Notice: the (above / below) functionality hooks into the Reporting API, which is a not-yet-standardized work in progress at W3C and which has unresolved privacy-related discussions. Implementors are encouraged to follow these discussions and be aware that this functionality could change or be removed as those discussions progress.

Changes made after the 2020 HTML Review Draft can be found in issue #17 [2].

If you support publication of the January 2021 HTML Review Draft as a W3C CR including the non-normative notice, add a thumbs up to this comment.

If you do not support publication, add a thumbs down to this comment and post a comment to let us know why.

If you do not respond to this CFC your support for the proposal will be assumed. This is not ideal, so please take a moment to let us know if you support the proposal or not.

Please respond to this CFC by the end of your day on Friday 14 January 2022.

@stevefaulkner
Copy link

I do not support publication as The document contains out of date advice around the use of headings and the semantics of headings (e.g. https://html.spec.whatwg.org/review-drafts/2021-01/#headings-and-sections) This has been the case for too many years.

@LJWatson
Copy link
Author

LJWatson commented Jan 4, 2022

@stevefaulkner could you point to the issues on the WHATWG HTML repo where these concerns have been raised? Thanks.

@patrickhlauke
Copy link
Member

Agree with @stevefaulkner's objection - the outline algorithm is still, from what i can see, "aspirational" and lacks real-world support in browser/AT combinations, and at the very least this should be clearly signposted, rather than just stating it as if it was fact.

@MakotoUeki
Copy link

@aardrian
Copy link

aardrian commented Jan 7, 2022

For the same reason as Steve and Pat. Now is as good a time as any (except the past, of course) to not support the publication to CR.

And @MakotoUeki , I think you have to give a thumbs-down as well as the comment. I think.

@domenic
Copy link

domenic commented Jan 7, 2022

If you support publication of the January 2021 HTML Review Draft as a W3C CR including the non-normative notice, add a thumbs up to this comment.

I do not support publication including this non-normative notice because doing so has been rejected already by the WHATWG editors in whatwg/html#6933, so it will not be appearing in the Review Draft.

@stevefaulkner
Copy link

The WHATWG claims to reflect reality in it's HTML specification, it is abundantly clear that this is not the case in regards to the semantics of headings and sectioning elements. 10 years ago the false and misleading statements could have been viewed as aspirational, that views utility has long since passed.
My objection pertains to misleading statements:
4.3.3 The section element

Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.

4.3.7 The hgroup element

The hgroup element represents the heading of a section, which consists of all the h1–h6 element children of the hgroup element. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

The rank of an hgroup element is the rank of the highest-ranked h1–h6 element descendant of the hgroup element, if there are any such elements, or otherwise the same as for an h1 element (the highest rank). Other h1–h6 elements of heading content in the hgroup element indicate subheadings or subtitles or (secondary) alternative titles.

The section on headings and sections defines how hgroup elements are assigned to individual sections.

The point of using hgroup in these examples is to prevent the h2 element (which acts as a secondary title) from creating a separate section of its own in any outline and to instead cause the contents of the h2 to be shown in rendered output from the outline algorithm in some way to indicate that it is not the title of a separate section but instead just a secondary title in a group of titles.

In both cases it is important to note the use of the hgroup element to group the two titles indicates that the titles are not equivalent; instead the first h1 gives the (primary) title while the second gives the (secondary) alternative title. Even though both the title and alternative title are marked up with h1 elements, in a rendered view of output from the outline algorithm, the second h1 in the hgroup will be shown in some way that clearly indicates it is secondary; for example:

4.3.11 Headings and sections

The h1–h6 elements and the hgroup element are headings.

The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.

Code examples in the following element definitions that perpetuate the falsehoods:

Once the HTML Specification is bought into line with the implementation reality in regards to the above TPGi will happily remove our objection to publication.

@LJWatson
Copy link
Author

LJWatson commented Jan 7, 2022

@domenic wrote:

I do not support publication including this non-normative notice because doing so has been rejected already by the WHATWG editors in whatwg/html#6933, so it will not be appearing in the Review Draft.

The proposal is to add the informative note to the CR not to the Review Draft. Can you clarify if your objection is to the note being added to the Review Draft, or to the CR? Thanks.

@johnfoliot
Copy link

I will add my voice to the chorus of objections to this publication - as @stevefaulkner correctly notes, the current draft describes fantasy, not reality, with regard to headings, sectioning and hgroup.

To requote @sideshowbarker from 7 years ago, "We’re here to solve existing real problems for real users —not to hypothetically solve problems for some of them if we could somehow just get browser implementors to see things our way and implement what we’ve specced, or get AT vendors to fix their horribly broken/buggy tools."

@lauracarlson
Copy link

Agree with @stevefaulkner.

@domenic
Copy link

domenic commented Jan 7, 2022

The proposal is to add the informative note to the CR not to the Review Draft. Can you clarify if your objection is to the note being added to the Review Draft, or to the CR? Thanks.

The review draft is the CR, per the Memorandum of Understanding; they are both the same document, hosted at https://html.spec.whatwg.org/review-drafts/2021-01/ . The W3C does not publish separate CR documents.

@LJWatson
Copy link
Author

LJWatson commented Jan 7, 2022

The review draft is the CR, per the Memorandum of Understanding; they are both the same document, hosted at
https://html.spec.whatwg.org/review-drafts/2021-01/

The non-normative text is proposed based on our interpretation of clause 4.2c of the MoU:>The HTML WG shall explore techniques other than having a HTML or DOM specification with normative differences such as an extension specification; or as non-normative advice;

@domenic
Copy link

domenic commented Jan 7, 2022

Facsinating. If your interpretation of that text is that you can modify WHATWG Review Drafts without editors merging the PRs, then I think that's an issue you should take up with the WHATWG Steering Group.

@domenic
Copy link

domenic commented Jan 7, 2022

To be clear, my understanding of the intent of that clause when it was written is that the W3C is free to publish its own separate non-normative advice documents (e.g. NOTEs).

@michaelchampion
Copy link

As someone who helped negotiate https://www.w3.org/2019/04/WHATWG-W3C-MOU.html, my understanding is:

  • @domenic is right, if the WHATWG editors and the W3C HTML WG can't find agreement, the next step is to escalate to the WHATWG SG.
  • If all else fails but "the differences are not too entangled with the rest of the spec, the REC might be issued as the Review Draft plus a companion document." I don't interpret the "companion document" as a non-normative NOTE, but an integral part of the normative Recommendation that describes a delta from the Review Draft. That does take us toward the Bad Old Days of not having a single HTML standard, but does keep the vast majority of the content in sync and ensures that differences are principled rather than arbitrary.
@plehegar
Copy link
Member

plehegar commented Jan 7, 2022

4.2.b is the applicable clause then, ie asking the WHATWG SG to step in. Makes sense to me.

@LJWatson
Copy link
Author

With thanks to everyone who responded, this CFC closes with no support and two objections.

The next step will be to consider both objections with a view to finding a positive resolution in both cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
10 participants