Re: HTML Modularisation

On 28/11/2014 08:59 , Henri Sivonen wrote:
> On Sat, Nov 1, 2014 at 10:58 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> Everybody agrees that it is hard, it is work, and that it is useful and
>> powerful.
>
> I don't agree that modularizing the topic areas that are covered by
> WHATWG HTML is useful. It looks like busy-work to me, and it seems to
> me that it would make it harder to see the differences between WHATWG
> HTML and W3C HTML.

I think that that characterises the topic in black and white, which I 
don't believe is helpful.

For me the heart of the matter (beyond the obvious goals of 
interoperability, wonderful tech for users and all that) is to enable 
contribution to specifications by doing more effectively than by talking.

So if modularisation is to take a part that is already handled somewhere 
else, paste it in a different file, and never do anything useful to it 
then I don't think anyone would dispute that that's busy-work.

The idea is rather that if there's a topic you're interested in, it 
shouldn't matter that it's already an area covered by someone else 
(anyone else for that matter). You grab it, modify it, publish it. If 
it's bad, either it'll die or you improve it. If it's good and gains 
traction, then you're gold. If someone else happens to be in charge of a 
document that covers the same topic area, and is now no longer in line 
with reality, it's their responsibility to update so as to reference 
your work.

Obviously, there are plenty of cases in which this is tricky. I don't 
think anyone is saying that you can just double-tap your wand on a spec 
and say it'll be modular. The core of the point is that this is the 
expected mode of operation and people practising it can expect support 
in doing so.

There really is no good reason why working on open standards should be 
any less convenient and friendly than working on open source. There is 
no reason to reduce would-be contributors to apes throwing bones in 
front of a monolith.

>> A comment on the contrast to XHTML modularization: a goal of XHTML
>> modularization was to enable an "a la carte" model where mobile vendors
>> could pick and chose what features they would support.  That would not be
>> the case here: the goal would remain "one web".  If (hypothetically) <form>
>> support were to be split out into a separate specification, it would be
>> normative referenced and not optional.
>
> What good would this accomplish?

If it were roughly the same content in a separate document, nothing. If 
it's a much improved version of <form> it would achieve much improvement 
on <form>. If you want a better form, don't complain about it, do it.

> When I read
> https://twitter.com/robinberjon/status/527205450400296960 , I thought
> Robin was joking.

Indeed, I didn't mean to limit that statement to just HTML.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 10 December 2014 15:42:52 UTC