HTML WG 2021

[plehegar]

New charter proposal, reviewers please take note.

Charter Review

Charter:

https://w3c.github.io/charter-drafts/html-2021.html

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing
  • [*] Existing WG recharter
  • [ ] Existing IG recharter
  • If this is a charter extension or revision, link a diff from previous charter, and any issue discussion:

Diff

This is linked to the updated MoU.

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, and security. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach:

None

Known or potential areas of concern:

None

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

in this repo.

Anything else we should think about as we review?

Nope

cc @sideshowbarker @siusin @LJWatson @hober

[plehegar]

Related to https://github.com/w3c/whatwg-coord/issues/9

[michael-n-cooper]

APA would like a liaison in addition to ARIA. A description like "For accessibility horizontal review, and to collaborate on accessibility related topics." would work.

[plehegar]

@michael-n-cooper , In dependencies, we have: [[ Accessible Rich Internet Applications (ARIA) Working Group

To collaborate on enhancing the accessibility of web content through the development of supplemental attributes, that can be applied to native host language elements and exposed via platform accessibility APIs. ]]

isn't that enough?

However, looking at https://github.com/w3c/htmlwg/issues/17 , it's not clear that we're explicitly sending a review request to ARIA, so we might be lacking on the operational side here.

[himorin]

No comment/request from i18n.

[michael-n-cooper]

@michael-n-cooper , In dependencies, we have: [[ Accessible Rich Internet Applications (ARIA) Working Group

To collaborate on enhancing the accessibility of web content through the development of supplemental attributes, that can be applied to native host language elements and exposed via platform accessibility APIs. ]]

isn't that enough?

A liaison to ARIA is good for coordination on the relationship of ARIA and HTML, but a liaison to APA is requested for general (non-ARIA) accessibility feature development.

[samuelweiler]

Why the departure from the usual "must have privacy and security considerations" requirement? The charter says:

Each specification is encouraged to contain or point to considerations detailing all known security and privacy implications for implementers, Web authors, and end users.

FWIW, I see several interleaved bits of security and privacy text in the HTML spec, but no comprehensive sections. I don't see the words "security" nor "privacy" anywhere in the DOM spec.

The charter has two links to "work mode" which are both broken.

The timeline does not make sense without years on it (or, perhaps a description of this being an annual calendar). In any case, it would make more sense to me if sorted temporally.

Although I know it's in our boilerplate, what does this line mean in the context of this WG?

The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification

I think we might need some customization of this section...

[samuelweiler]

Timing of pre-CR reviews. The current charter says:

Invitation for review must be issued during each major standards-track document transition, at least 3 months before the CR publication...

The group is not presently doing that - see https://github.com/w3cping/privacy-request/issues/49 and https://github.com/w3c/security-request/issues/8, where they asked for review about 1.3 months before (their target for) CR.

The proposed charter says:

... advised to seek a review at least 3 months before first entering CR

Emphasis added on the word first. This follows the current charter template.

Do we consider each new (annual) review snapshot to be starting that clock anew? I'm not wedded to an answer here, but these are long documents, and reviews have been slow. It might help to be starting the review clock three months out, and I wonder if we need to specifically require that - as the current charter does - even though the WG isn't following that requirement.

[plehegar]

Timing of pre-CR reviews. The current charter says:

Invitation for review must be issued during each major standards-track document transition, at least 3 months before the CR publication...

The group is not presently doing that - see w3cping/privacy-request#49 and w3c/security-request#8, where they asked for review about 1.3 months before (their target for) CR.

Sounds like a bug in the operations of the Group, ie the Group should do that.

The proposed charter says:

... advised to seek a review at least 3 months before first entering CR

Emphasis added on the word first. This follows the current charter template.

Do we consider each new (annual) review snapshot to be starting that clock anew?

Yes

I'm not wedded to an answer here, but these are long documents, and reviews have been slow. It might help to be starting the review clock three months out, and I wonder if we need to specifically require that - as the current charter does - even though the WG isn't following that requirement.

The Group ought to follow the approach imho. It is true that changes from one version to another may be small, especially on the DOM side, but I don't think we need to rush the reviews.

[plehegar]

or accessibility horizontal review, and to collaborate on accessibility related topics.

@michael-n-cooper , I added the liaison.

[plehegar]

https://github.com/w3c/charter-drafts/pull/376 fixes most of comments

[plehegar]

Why the departure from the usual "must have privacy and security considerations" requirement? The charter says:

Each specification is encouraged to contain or point to considerations detailing all known security and privacy implications for implementers, Web authors, and end users.

FWIW, I see several interleaved bits of security and privacy text in the HTML spec, but no comprehensive sections. I don't see the words "security" nor "privacy" anywhere in the DOM spec.

I believe this wording was based on conversation that happened during the preparation of the MoU. I'm reluctant to add requirements on the HTML and DOM from the WHATWG through the HTML charter. A better course of action would be to pursue these through issues raised against the specifications. @sideshowbarker , any opinion here?

The charter has two links to "work mode" which are both broken.

This was fixed in #376 btw. The section work mode from the current charter, an other unusual part, was missing.

The timeline does not make sense without years on it (or, perhaps a description of this being an annual calendar). In any case, it would make more sense to me if sorted temporally.

Fixed.

Although I know it's in our boilerplate, what does this line mean in the context of this WG?

The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification

My interpretation is that the HTML WG is meant to help the W3C community to navigate the issues in the WHATWG and recommend actions when needed. If disagreement exists in a WHAT issue, the HTML Working Group should step in and help with the conversation, more especially with the horizontal groups.

I think we might need some customization of this section...

What did you have in mind?

[samuelweiler]

Why the departure from the usual "must have privacy and security considerations" requirement? The charter says:

Each specification is encouraged to contain or point to considerations detailing all known security and privacy implications for implementers, Web authors, and end users.

FWIW, I see several interleaved bits of security and privacy text in the HTML spec, but no comprehensive sections. I don't see the words "security" nor "privacy" anywhere in the DOM spec.

I believe this wording was based on conversation that happened during the preparation of the MoU. I'm reluctant to add requirements on the HTML and DOM from the WHATWG through the HTML charter. A better course of action would be to pursue these through issues raised against the specifications. @sideshowbarker , any opinion here?

I'm happy to hear @sideshowbarker's opinion, but since I've been asked to weigh in:

There may be a conflict of expectations here, where PING and security reviewers expect a spec to have a self-analysis of issues before they'll do review. We have tried - or are trying - issues on the specs. They don't seem to be getting traction. And we've asked the HTML WG for help sorting that out. (Edited to add link: https://github.com/w3c/htmlwg/issues/19#issuecomment-911192730)

To be plain: without those sections, whether required by charter or not, the horizontal reviewers may decline to review.

The charter has two links to "work mode" which are both broken.

This was fixed in #376 btw. The section work mode from the current charter, an other unusual part, was missing.

The timeline does not make sense without years on it (or, perhaps a description of this being an annual calendar). In any case, it would make more sense to me if sorted temporally.

Fixed.

Although I know it's in our boilerplate, what does this line mean in the context of this WG?

The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification

My interpretation is that the HTML WG is meant to help the W3C community to navigate the issues in the WHATWG and recommend actions when needed. If disagreement exists in a WHAT issue, the HTML Working Group should step in and help with the conversation, more especially with the horizontal groups.

Can we just say something like that, then?

I think we might need some customization of this section...

What did you have in mind?

Your text above is a good start.

[plehegar]

Can we just say something like that, then?

I would rather not since it's part of the MoU already.

[samuelweiler]

If disagreement exists in a WHAT issue, the HTML Working Group should step in and help with the conversation, more especially with the horizontal groups.

I am concerned about the effectiveness of this WG at "attempt[ing] to work with the person and the WHATWG editors to achieve consensus" (Scope section, paragraph 2), as demonstrated by the lack of any response or engagement when I tried to get their help with the below: https://lists.w3.org/Archives/Public/public-html/2021Aug/0006.html

If W3C is going to recharter this WG, we need to do something to make sure it does the work it's chartered to do - or else not charter it to do that work.

[plehegar]

From @fantasai , consider adding https://www.w3.org/TR/html-ruby-extensions/ in the scope of the WG. cc @frivoal @LJWatson @hober

[samuelweiler]

There may be a conflict of expectations here, where PING and security reviewers expect a spec to have a self-analysis of issues before they'll do review. We have tried - or are trying - issues on the specs. They don't seem to be getting traction. And we've asked the HTML WG for help sorting that out.

Citation to that ask: https://github.com/w3c/htmlwg/issues/19#issuecomment-910556741

[plehegar]

Proposal for a sentence to add in the scope section: "The Working Group may also work on extension specifications for HTML features after coordination with the WHATWG Steering Group."

[plehegar]

The Ruby spec is under discussion in https://github.com/w3c/whatwg-coord/pull/14 . Given the generic sentence I proposed earlier, I don't think we need to block on the resolution of 14. I would also expect the HTML Working Group to do a CfC before starting the work on extension specifications.

[samuelweiler]

@plehegar The link in the proposed charter for where to raise issues is broken. Per https://github.com/w3c/strategy/issues/284#issue-963990497, it should point here.

[plehegar]

The link was fixed in https://www.w3.org/2022/02/proposed-timed-text-wg-charter.html

[samuelweiler]

The link was fixed in https://www.w3.org/2022/02/proposed-timed-text-wg-charter.html

How about https://w3c.github.io/charter-drafts/html-2021.html ?