subscribe

@tantek use the "Subscribe" button on the sidebar.

@domenic apparently by mentioning me you subscribed me! "You’re receiving notifications because you were mentioned."

Discussed at London face-to-face. Though we're likely to continue discussion to tomorrow morning.

We need to figure out how to split this up.

One meta-point that came up briefly was the value of specifying requirements for document conformance, which is something that HTML does but few other Web specs do. This might be worth future discussion.

Examples of two specs that do specify document conformance requirements in very different ways, both from the TTWG:

• TTML2 ED §3.1
• WebVTT ED §4

CSS does as well. body { background:blue works, but is not valid.

It's not common for APIs, but for declarative formats it's fairly reasonable and establishes some rough notion of forward compatibility, by having things you're not supposed to use, but won't cause a fatal error either, thereby allowing for extensions.

For this issue, we have consensus to split this up into various more specific parts of HTML for individual review. @travisleithead tasked with proposing the logical review chunks.

HTML "Sub-specs" review breakout proposal

The features enumerated below focus on areas of the spec with browser implementation requirements (such as processing models or algorithms), and mostly skip sections of conformance criteria. Also, features with little differentiation (e.g., <small>, <u>, <b>, etc.) are not included as there is not much to review for them anyway.

HTML Document and Elements Structured Serialize/Deserialize Custom Elements HTML Linking HTML Styling - david HTML Lists HTML Ruby - david HTML Images Browsing Contexts and Security HTML Media HTML Tables - david HTML Forms HTML Input HTML Option Lists - david HTML User Interaction HTML Focus HTML Scripting HTML Templates HTML Drawing Microdata Navigation and Browsing History App Cache HTML Utilities HTML Parsing HTML Timers and Timeslicing - david Server-Sent Events Web Sockets Cross-Document Messaging Web Workers Web Storage XML Infrastructure HTML Obsolete Features IANA Registries

(33 groups)

DETAILED BREAKDOWN

The "Features" are just a sample of what you will encounter as part of the listed spec sections, it's not meant to be exhaustive.

The "Sections" are all the sections of the HTML spec that would be included in the "sub spec" review. I tried to group sections of the spec that made sense together and favored each "sub-spec" with a good balance of size and complexity--though some "sub-specs" are definately bigger than others. There's still lots of entanglement, but I think this is a pretty good first attempt. Where the spec section has associated Web Platform Tests, the specific WPT path is noted.

HTML Document and Elements

Structured Serialize/Deserialize

Custom Elements

HTML Linking

HTML Styling

HTML Lists

HTML Ruby

HTML Images

Browsing Contexts and Security

HTML Media

HTML Tables

HTML Forms

HTML Input

HTML Option Lists

HTML User Interaction

HTML Focus

HTML Scripting

HTML Templates

HTML Drawing

Microdata

Navigation and Browsing History

App Cache

HTML Utilities

HTML Parsing

HTML Timers and Timeslicing

Server-Sent Events

Web Sockets

Cross-Document Messaging

Web Workers

Web Storage

XML Infrastructure

HTML Obsolete Features

IANA Registries

note: the <slot> element is not included in any group, since it seemed more like a Shadow DOM-dependent feature, which we would review as part of DOM.

Some potential TODOs for each review:

• Legacy APIs that could be 'modernized'?
• Things that could require permissions that aren't modelled in the perms API?
• Areas of the platform that are 'magic' (could use explaining in terms of extensible web manifesto)

What parts are wishful thinking, and should be written to be made more realistic also comes to mind.

• Mike Smith notes the developer portions (green boxes) are places in the spec that are focused on the developer audience. Where these are missing or could use additional detail, clarification, etc., these should be noted.
• Also how the features are meant to be used together (the integration parts)

We agreed to close this issue in favour of the new more granular issues that @travisleithead has opened up.

Also see the above list as a list of issues.

@domenic and @annevk FYI that we've sub-divided the TAG's monolithic HTML review issue into smaller, more focused issues. If there are sections (issues) you feel should get more attention/focus or have specific "features" that you'd like particular directed feedback, please let us know!

I'd love help untangling navigation/about:blank/general global and document lifecycle.

@annevk (and others): probably best to let us know in separate issues in this repo, and with a tad more detail. (On the other hand, I'm not sure if that issue is the sort that the TAG is well-suited to help with; it sounds like it might be more a matter of doing a lot of research into what the compatibility constraints are.)

Yeah, you're right.

I'm not sure there's much review to be done other than of the research kind. What we primarily need is additional resources to clear all the technical debt so we have a better foundation for the rest of the platform (pretty much all of which builds on top of HTML).