TAG Review of HTML 5.2 (previously 5.1)

[travisleithead]

As the Web Platform WG nears a publication of CR, and as part of the group's request for wide-review, this is a request for TAG review of HTML 5.1.

Spec: http://w3c.github.io/html/

It may be helpful to start from the change list (so as not to necessarily review everything):

http://w3c.github.io/html/changes.html#changes

Thanks!
@adrianba, @LJWatson, @chaals, @arronei, @adanilo, @plehegar

[annevk]

Probably want to review https://html.spec.whatwg.org/multipage/ instead due to https://annevankesteren.nl/2016/01/film-at-11.

[torgo]

TAG discussed at [Stockholm F2F](Discussed at Stockholm F2f.

[hadleybeeman]

We don't want to block 5.1. And we also intend to do a more holistic view of HTML and will get back to you when we're ready to discuss that further.

[travisleithead]

Note: Leonie requested a 5.2 review:

Hello TAG,

Our plan is to begin the process of moving HTML5.2 to CR in early June, per our planned timetable [1]. We'd therefore welcome your review of the current WD [2].

To make things manageable the parts of the spec that need review are those noted in the Changes section [3]. We're not expecting the entire spec to be reviewed unless you wish to do so.

Please file issues on Github, with a reference to the TAG in the comment [4]. If you could also send a message here when your review is complete, that would be helpful.

We'd be glad of your input as soon as possible, but our cut-off for making CR would be 26th May.

Any questions, you know where to find us.

Thanks
Léonie
[1] https://lists.w3.org/Archives/Public/public-html/2016Nov/0014.html
[2] https://www.w3.org/TR/2017/WD-html52-20170406/
[3] https://www.w3.org/TR/2017/WD-html52-20170406/changes.html#changes
[4] https://github.com/w3c/html/issues/

@LeonieWatson tink.uk Carpe diem

[dbaron]

One open question Léonie raised in person was whether we have an opinion on the value of modularization (including for very small pieces).

[triblondon]

Decided to use a subgroup to split this into specific review items of interest, then we can assign smaller review tasks.

[torgo]

We reviewed the 5.2 Change Log in the TAG f2f.

Herewith out notes:

Sangwhan: about:html-kind - we think it's unclear what it's supposed to do ... We'll ask for clarifiication...

Concern expressed about whether apple-touch-icon-sizes should be in the spec - vendor specific naming... - please deprecate in favor of manifests?
Maybe switch to a non-normative or a conformance appendix? A compatibility module or companion note? (see, e.g., ECMA-262 Annex B: https://tc39.github.io/ecma262/#sec-additional-ecmascript-features-for-web-browsers or https://compat.spec.whatwg.org/)

Question on DL – why doesn't it allow all elements as children?
cf https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl
Why cant a custom element be put there? What's the protocol that a <dt> or a <div> are adhereing
too that other elements don't or can't? Why isn't that explained? Is there a data structure that gets modified when a dt/dd are added under a <dl>? These questions get to a larger question of extensibility.

Why aren't defn's allowed in a lot more places?
For example, In specs themselves, defns are often used where they are not technically allowed
Maybe this should be fixed to reflect real usage?

Make style in body confirming
The commit is missing?

rel extensions - this should go in the list of things that needs a maintenance registry rather than a wiki
Which we will take up and make recommendations about in the future.

Summary activation algorithm : Sangwhan is taking an exta look at this...

Comments, @LJWatson?

[triblondon]

@torgo shall we remove the Extra time label if you've wrapped up work on this for the F2F?

[chaals]

@torgo, can you please edit the comment to clarify it? In particular it seems you're missing backticks ( ` ) around some stuff so it disappears, in the bit about DL.

[dbaron]

backticks added

[chaals]

Some personal thoughts:
Thanks all for the review…

I'll ask Sangwhan about summary activation, although I also did a big chunk of work on that recently to bring it into line with reality - it wasn't. With any luck, we can close that out.

The current approach to rel values being in a wiki is hard to use. There are various specs that have included them, and a more pleasant registry would be great. I will propose to keep what we have for now, since it has been around for a while, and look to improve in the next year (HTML 5.3 timeframe).

I think we cleaned up style to be conforming in body with a recent commit: w3c/html@e0cf4c7

We'll look into the other points…

[chaals]

Can you please explain the "defn" issue?

I will raise it on the spec when I am clear that I understand what it is, but right now, I do not.

My guess is that you mean we should expand the model of dfn from phrasing content to flow content, allowing it to include headings, lists, etc.

But since the element is used to identify the term being defined - i.e. just the words which are being defined - I find it hard to imagine a case where the words will run across elements other than phrasing content: links, em/s/var/etc, and even things like audio.

I'm inclined to suggest that the proposed change, if I have understood it, be rejected…

How fallback content included in elements like audio works in the context of phrasing content may be poorly defined, although I haven't looked at that carefully myself.

[chaals]

Regarding apple-touch-icon-sizes
We try not to put vendor branding into our standards. On the other hand, sometimes people prefer to implement those, and we also try to specify reality. If implementors move to something else, we would happily obsolete the term. Likewise, making them obsolete is feasible, and we already have an appendix describing features that browsers need to implement but which are obsolete and should not be used, for things like appcache.

The manifest specification does not seem to have interoperable implementation, so at this stage I don't see why we would make the change for HTML 5.2 - although we will keep an eye on it, and consider the issue in the context of HTML 5.3.

[domenic]

the changes that WHATWG had made to their spec weren't either. With any luck, we can close that out.

This is not accurate; you just misunderstood the changes.

[plinss]

Yes, the "defn" issue is that dfn should be allowed in flow content, especially since the HTML spec itself uses them in headings, see https://w3c.github.io/html/infrastructure.html#section-transferable-objects for an example (there are many, many other examples in W3C and WHATWG specs).

[chaals]

@domenic:

This is not accurate; you just misunderstood the changes

OK, that's always a possibility. Edited to remove the statement.

[chaals]

@plinss:

Yes, […] dfn should be allowed in flow content, especially since the HTML spec itself uses them in headings, see https://w3c.github.io/html/infrastructure.html#section-transferable-objects for an example

dfn is used in that example as phrasing content - within the flow content. That is legitimate. What would be a violation of the current spec is

<dfn><h4>special treatment</h4></dfn>

On a separate note, the semantics I see in real use don't match what the spec says, and I will file an issue for that.

[chaals]

about:html-kind is "defined" at https://w3c.github.io/html/infrastructure.html#abouthtml-kind

That should be linked from the place it is used, at https://w3c.github.io/html/semantics-embedded-content.html#identifying-a-track-kind-through-a-url - but IMHO it should probably also be explained better...

[chaals]

about:html continued...

It's used as a vocabulary identifier by third parties, who assume (without documentation) that if this identifier is used, then any subsequent term which claims to be a "kind" for a track has the meaning given to the different potential values of the kind attribute in HTML.

I'll raise this, but I think it is effectively editorial in terms of HTML, since it's essentially providing an expansion point that others use in whatever way they define. In particular, I think it would be helpful if the definition recorded by IANA were clearer than it is today @dwsinger

[dwsinger]

On Jun 14, 2017, at 3:43 , chaals ***@***.***> wrote: about:html continued... It's used as a vocabulary identifier by third parties, who assume (without documentation)

sorry, not sure what you mean by “without documentation”; the documentation is there in both HTML5 specs and in the other specs I think, just (sadly) some don’t find it very clear. b ut that’s what the tag was invented for

that if this identifier is used, then any subsequent term which claims to be a "kind" for a track has the meaning given to the different potential values of the kind attribute in HTML. I'll raise this, but I think it is effectively editorial in terms of HTML, since it's essentially providing an expansion point that others use in whatever way they define. In particular, I think it would be helpful if the definition recorded by IANA were clearer than it is today @dwsinger

IANA says this, which I think maybe I wrote so I find it abundantly clear: "The about:html-kind URI identifies the vocabulary of kind values in HTML specifications from W3C and WhatWG." what does it leave unclear? David Singer Manager, Software Standards, Apple Inc.

[torgo]

We agreed to close this at the f2f. All follow-ups to happen in #174.