Re: Proposed split of the HTML specification

Excellent work!

On 06/11/2015 05:16 AM, Robin Berjon wrote:
> Hi all,
>
> as part of the many discussion about the next steps in HTML, the
> question of splitting up the HTML spec has come up again. In order to
> make the discussion simpler, I have made:
>
>      1) A tool that makes it easy to generate splits.
>
>      2) A proposed split to get the discussion rolling.
>
> The idea isn't that my proposed split is perfect; the idea is however
> that people who want to propose alternatives ought to do so by actually
> producing one rather than arguing about it. Smaller tweaks to an
> existing split should be made as pull requests against it.
>
> The DIY breakup is up at:
>
>      https://github.com/darobin/breakup
>
> I encourage you to actually read the README.
>
> The proposed split is up at:
>
>      http://darobin.github.io/breakup/specs/
>
> Some things worth noting about it:
>
>    • I like smaller specs, it's a lot of pieces.

Indeed.

>    • The generated output is not perfect, there are notably problems
> with WebIDL and references. The goal here is to give a concrete idea,
> not to produce perfect documents.

Two things I noticed after a spot check:

"HTML Best Practices" contains normative specification text that 
probably belongs elsewhere.

"HTML Requirements Relating to the Bidirectional Algorithm" the title of 
this document

>    • The chunking at times cobbles together section that weren't
> adjacent in the monolith, which can cause strange transitions. Overall
> there are wording nits, these can be ironed out *after* (and if) a split
> has happened.
>
>    • Some content is just dropped on the floor. The list of dropped
> sections is in the JSON.
>
>    • Cross-linking *ought* to work, but I haven't extensively tested it,
> bug reports welcome.
>
> Go have fun! :)

Overall questions:

1) do you see the "breakup" tool as something that -- after the 
experimentation and discussion dies down -- is used once and discarded, 
or is part of the publishing pipeline?

1a) if it is part of the publishing pipeline, how would this work if 
responsibility for different specs falls to different Working Groups?

2) A split such as this calls out for the need for multiple indexes (in 
the computer science use of this term).

2a) I see a need for an overall table of contents indicating the 
complete set of relevant specifications.  We've talked about this 
before, but any ideas we may have explored probably need revisiting, 
particularly as different specs may be owned by different groups (or 
even different standards organizations).  As you know, one of my 
favorite examples is the URL object: something that was once part of 
HTML, but not doesn't currently appear to have any traction in the W3C. 
  It is still needed.

2b) In addition to a table of contents, I now see a need for an index 
(I'm using this term in the sense that you find in the back of many text 
books).  As an example, where would you find requirements (normative or 
informative) related to the <nav> element?  It didn't seem obvious to me 
to look in the "Sections in HTML" document for this, but that would be 
OK if there were an index that could be readily determined.

Thanks for getting this ball rolling!

- Sam Ruby

Received on Thursday, 11 June 2015 13:16:13 UTC