W3C home > Mailing lists > Public > public-html@w3.org > September 2014

Re: After 5

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 18 Sep 2014 18:42:30 +1000
Message-ID: <CAHp8n2=2+OBt2ompqnSLdqJgGj4b323c+UVuHwu0Yp6nY0YYjQ@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, public-html <public-html@w3.org>
On Thu, Sep 18, 2014 at 6:19 AM, Shane McCarron <shane@aptest.com> wrote:
> Daniel said:
>> I would like to add something about modularization we rarely think of,
>> being spec authors: a collection of lightweight specs is better for
>> Web authors than a single huge document. And I suppose implementors
>> don't really care as soon as the specs are well written.
> I agree...  but it is obviously incumbent upon the spec authors, even if
> they are in disparate subgroups focused upon different modules, to ensure
> that when the modules are assembled they form a cohesive whole.
> So, if we are going to "modularize", someone(s) need to be the architect(s).
> We don't do anyone any good if at the end of the day there is some new,
> awesome feature that no one can actually support in a consistent fashion
> because the way it integrates isn't obvious and each implementor does it
> differently.
> Fortunately, one of the things the W3C brings to the table is process.
> Sometimes heavyweight, but still.  And part of that process is the document
> life cycle.  The transition from CR to PR helps us ensure that the spec is
> implementable.  But even that *check* is only as good as the underlying
> spec, it's relationship to the other specs it requires, and the tests.
> I know, I am rambling a little.  My point is that it is very very important
> that, as modules are developed, they fit well into the puzzle. The more
> puzzle pieces, the harder it is to make that certain.

I agree.

I would actually go further than just modularisation. I would got to
test-driven specification development.

When a new features is proposed and specified, the test cases for that
feature need to be developed as part of the new spec. Then, when the
browsers implement the spec, they have some examples to go by and can
complete the tests as they go. Once a sufficient number of browsers
pass the tests, the feature is ready to move on. Maybe with 2 browsers
supporting it, it could move to CR, with three browsers supporting it,
to PR and onto REC when a permanent snapshot of the spec is supposed
to be created. This would be my preferred way of working and I can see
much of this already evolve through the webplatform work, which is

Received on Thursday, 18 September 2014 08:43:17 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:10 UTC