Hooks for extensions

[chaals]

There are several extensions to HTML such as RDFa and microdata that add attributes or similar extension points. These should be included in the specification, linked to the relevant spec that defines what they do.

[travisleithead]

Can you elaborate on what kind of hooks you were thinking of?

[chaals]

There are attributes (and other bits of HTML machinery like IDL attributes) that extension specs rely on, and define as HTML attributes.

The ones on my immediate list are longdesc and RDFa - which are straightforward, and microdata which might need more thinking since although it is very widely deployed and processed, the current spec is a note and includes a microdata API whose implementation status is uncertain - I think it was only ever implemented by Opera/Presto, although I'd need to test.

These attributes etc. should be listed in the right place in the spec, with pointers to the relevant extension specs for the full definitions.

[chaals]

Note that the longdesc piece has now been picked up as #258

[arronei]

I am thinking we need a new way to handle this much like CSS does. CSS publishes yearly snapshots of what documents the WG think are "stable" additions to the language. We can define what "stable" means and publish out our own yearly roll-up of documents that make HTML 2016, 2017, etc...

This would allow HTML 5.1 to be the foundation document that is just the core features that where in HTML5 and interoperable. Anything that was not in HTML5 that needs to be added should be in its own new module document. That document can then become part of the yearly HTML snapshot.

[chaals]

@arronei, that's pretty much what I was thinking, I think.

[travisleithead]

Going further (too far?) I'd like to also trim-down the HTML5.1 "foundation" spec, by removing the pieces that get spun out as modules (which is unlike what CSS does with CSS2.1). For example, if I pull out "HTML Scripting" as a module, I want to remove the related complexity from HTML5.1. In the limit, I think there is still a core part of the document that will remain and not become a module--at the very least the HTML Parsing algorithm. But a lot of other pieces can probably be split out.

The problem that this approach might have is what to do about publication. We would publish a REC of 5.1 with pointers to it's related modules and said modules would not be RECs themselves, these dependencies would ultimately block publication of the core HTML5.1 document, right?

[chaals]

I'd like to also trim-down the HTML5.1 "foundation" spec, by removing the pieces that get spun out as modules

Yes, I think that is a critical part of the task. Otherwise we leave people reading through a set of documents and trying to mentally cut and paste fragments, which is much too much work for most readers to do efficiently.

We would publish a REC of 5.1 with pointers to it's related modules and said modules would not be RECs themselves, these dependencies would ultimately block publication of the core HTML5.1 document[?]

For now, we should aim to do this with the bits that are actually Rec. Assuming that HTML will continue to develop beyond 5.1, we can do more of this in 5.2.

It is also the case that if we can show something we are pointing to is stable, implemented, and likely to get to Rec roughly as-is at least with respect to the bits we point to, the director may well let us publish with the pointers. Microdata is probably a good example of this - and it's what happened with WebIDL to publish HTML 5.

One other note from @LJWatson - it would be good to include an appendix that lists all the documents which make up "HTML 5.1", which would be more like the CSS snapshot document.

[travisleithead]

OK, well, we seem to have wandered a bit off topic. This issue is about putting in the hooks for:

• RDFa
• Microdata
• longdesc
  others?

[chaals]

We will put minimal hooks that are things in HTML, and point to relevant extensions specs, in preference to incorporating extensions completely into a monolithic spec.

[chaals]

OK, seems we have a bunch of thinking on this. Reopening as the meta, we need to figure out at least

• Sub-Resource Integrity
• longdesc (unless we change again)
• RDFa
• media capture

Things in the pipeline include

• microdata
• CSP
• Custom Elements
• the editing tf work
• Shadow DOM?

[LJWatson]

Setting aside (for the moment) the goal to separate out more content from HTML core into modules, these are the requirements I think we have in terms of managing the relationship between HTML core and its modules:

1. Maintain HTML core plus n- modules.
2. Make it easy to look up all available modules.
3. Make it easy to discover relevant modules.

To meet #1 and #2, I propose we do one of the following things:

1. Create a (stand-alone) modules index page, linked from the HTML core homepage.
2. Create a modules table within the HTML core index.
3. Both of the above.

To meet #1 and #3, I propose we introduce a new pair into the meta information for elements (categories, contexts in which this element can be used, content model etc.) - perhaps "Relevant modules" or "Associated modules".

[chaals]

To meet #1 and #2, I propose we do one of the following things:

1. Create a (stand-alone) modules index page, linked from the HTML core homepage.
2. Create a modules table within the HTML core index.
3. Both of the above.

I suggest we do 3, with number 2 as the priority - and we just copy that into the home page whenever we update the spec.

I think technically what we need to collect are "specifications that extend the HTML spec" - some of which are maintained in other groups.

[dwsinger]

I'm not sure. I think having a living directory of modules, CSS Style, may well be fine. The core CSS parsing and structure modules do not contain statements of the form "and CSS smells and bells may be used in CSS". Generally, upper layers refer to lower ones, not the other way around "parsing of elements in CSS smells and bells is standard CSS parsing as defined in CSS core syntax 45.3".

However, I think this illuminates the question: how we document what modules are available is a whole lot less interesting than developing the actual modular breakdown.

[arschmitz]

To meet #1 and #2, I propose we do one of the following things:

Create a (stand-alone) modules index page, linked from the HTML core homepage.
Create a modules table within the HTML core index.
Both of the above.
I suggest we do 3, with number 2 as the priority - and we just copy that into the home page whenever we update the spec.

I agree number 3 done this way seems the best both for maintainability and making it easy for people reading the specs.

[chaals]

We have the Note regarding "things that extend/modify HTML". @adrianba assigning to you - is there more we need to do here to document how we decide to add stuff in or leave it out, or should we just close this?

[chaals]

@LJWatson can we close this?

[LJWatson]

Closing because the note seems to have it covered.