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

I like the idea of it being more modular, as long as there would also be
some sort of master index page which facilitates easy location of the
required specification and is kept up-to-date every time a new version of
any underlying modular specification is released so an at a glance view of
what is the latest version would be possible,
Being modular allows each spec to have versioning of its own and I can
imagien that it would be easier to maintain rather than trying to maintain
such a huge specification.

======================================
Ian Devlin
iandevlin.com <http://www.iandevlin.com>
@iandevlin <http://www.twitter.com/iandevlin>
skype: idevlin
======================================

On 6 April 2016 at 01: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
>
>