- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 16 Jun 2010 09:30:34 +0200
- 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