Re: Please comment: Modular HTML or monolith? (esp. regarding Web Components)

I also support a modular approach.

The reality is that web development is already 'modular', in that a single
technology alone cannot create a modern site or app. Developers are used to
using multiple sources of documentation.

Smaller, more focused specifications would, I believe, encourage more
people to read the documents, a single monolithic specification would do
the opposite.

As has been pointed out, a good index and versioning system will be
important, but that's already the case for the supporting documentation
around existing specifications.

Ian.

On 6 April 2016 at 00:11, Chaals McCathie Nevile <chaals@yandex-team.ru>
wrote:

> Hi all,
>
> TL;DR: Should we move the content of specs like Shadow DOM and Custom
> Elements into HTML, or continue with the goal of more modular
> specifications?
>
> Working group members, please express and explain your preferences for one
> or the other of these approaches, to see whether we have rough consensus or
> need to work toward a formal Call for Consensus.
>
> Some more background:
>
> The plans for the HTML spec over the last year or so have all included
> some effort to make the spec more modular, rather than increasing the size
> of the spec.
>
> The monolithic approach, with implementation requirements scattered
> through the entire spec, means that it is hard to understand how anything
> works without knowing the whole spec. In practice this has resulted in
> implementors missing some requirements and implementing something less
> interoperably than anyone wants.
>
> Likewise, for people who are looking to use a single new feature, or
> trying to understand changes to the features they rely on, reading the
> whole spec is often far too high a burden.
>
> The editors of HTML have expressed a preference for making it more
> modular, in particular that substantial new additions should be as far as
> possible in "stand-alone" extension specs, rather than being incorporated
> entirely into a growing HTML spec.
>
> And doing so makes it easier to work on features independently, instead of
> trying to hold everything to a single publishing timeline.
>
> Our current approach is therefore to work on a more modular approach for
> anything that isn't currently in the HTML spec, adding the minimum of
> necessary hooks as pointers to the relevant extension - and where resources
> are available to try and further modularise the spec we already have.
>
> It has been argued that for implementers of HTML, they need to know
> everything anyway. Our continued plan for more modularity is based on the
> premise that while this may be broadly true of browser makers, it isn't the
> case for the vast majority who implement tools or applications using HTML.
> In addition the chairs have had feedback from browser makers that the
> monolithic approach isn't really helpful - as well as from others who say
> it is.
>
> Recently people have suggested that the Web Components specs for Shadow
> DOM and Custom Elements should instead be merged into HTML and DOM, instead
> of continuing to maintain individual specifications, and the editors of the
> Web Component specs seem to look favourably at that idea.
>
> This would be a big change in particular for HTML, and a change of
> direction for the Working Group in general. So the chairs would like more
> input from the Group as we consider how we might reconcile different
> editorial approaches that would significantly impact each other.
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>