W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: Change Proposals, objections, and the Decision Policy

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 16 Jun 2010 09:30:34 +0200
Message-ID: <4C187D9A.4050901@gmx.de>
To: Adam Barth <w3c@adambarth.com>
CC: Maciej Stachowiak <mjs@apple.com>, Henri Sivonen <hsivonen@iki.fi>, "Roy T. Fielding" <fielding@gbiv.com>, HTML WG <public-html@w3.org>
On 16.06.2010 09:16, Adam Barth wrote:
> ...
>>> 1) ISSUE-101: "Spec reference for US-ASCII."  Does this matter at all?
>>>   I think everyone reading the spec knows what ASCII is.
>>> ...
>>
>> If it doesn't matter, why can't we point to something that indeed defines
>> ASCII?
>
> Dunno.  When editing specs, I tend to accept these sorts of trivial
> comments.  Another point of view might be that accepting these changes
> encourages more objections in the same vein.
> ...

It's a good thing when reviewers point out editorial flaws instead of 
ignoring them. It's a good thing when spec editors pay attention to this 
feedback. (I know you do, and thanks for that).

> ...
>> I care, because the current text implies that HTML is super-easy, while
>> XHTML is so hard that even the Working Group can't explain it.
>
> So?  It's still micromanagement.  Are you here to defend the honor of
> XHTML or to help advance the web?
> ...

This doesn't need to be an exclusive "or", right?

>>> ...
>>> 6) ISSUE-110: "Change Control for text/html-sandboxed media type."
>>> This issue is entirely pedantic.  In some future world, there might be
>>> some confusion about who the controlling entities are for text/html
>>> and text/html-sandbox.
>>> ...
>>
>> This issue *will* surface when we do the media type registration. Pretending
>> it won't just delays a fix.
>
> Then let's deal with the issue when it actually occurs.
>
>> I agree that it's unfortunate that issues like these take so much time to
>> resolve, but please don't blame it completely on those who happen to
>> disagree with the current text.
>
> With a project as large as HTML5, we'll never dot all the is and cross
> all the ts.  It's just not feasible.  In many ways, it's like shipping
> a piece of software.  At some point you need to decide that the
> remaining bugs just aren't worth fixing and that it's time to ship it.
 > ...

I'd agree if these things were hard to fix. They aren't. Trivial things, 
once pointed out, should be fixed immediately; that's the best way to 
avoid additional work (more bug reports, more replies to bug reports) 
later on. This applies both to spec writing and software.

> We're not quite there with HTML5, but we're getting close.  These
> issues are way below the line of what matters.

If they do not matter to you, fine. They matter to others. If this is a 
bandwidth problem, let's assign a second document editor who will 
address things like these (and similar issues like vague references to 
other specs).

Best regards, Julian
Received on Wednesday, 16 June 2010 07:38:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC