W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Design principles - building from justification

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 05 Feb 2009 22:21:49 -0500
Message-ID: <498BACCD.6050901@intertwingly.net>
To: Ian Hickson <ian@hixie.ch>
CC: HTML WG <public-html@w3.org>

Ian Hickson wrote:
> On Thu, 5 Feb 2009, Sam Ruby wrote:
>> An alternate way to describe the development of HTML 5 to date is that 
>> it has been developed starting from zero, includes only features that 
>> are deemed necessary to meet presented and accepted use cases, and 
>> operates under the rather significant constraint that such a spec, if 
>> followed by implementers, won't break the web.
> 
> This is indeed the way the spec has been written. One could call this 
> "building from justification". I would quite like this to be added to the 
> design principles, if we are to reopen that discussion. (The other 
> principle that I'd like added is "baby steps", which I suggested before we 
> published the last draft, though it wasn't added for some reason.)

<joke>If HTML5 is a baby step, I'd hate to see what a full step looks 
like.</joke>

I think I know what you mean, you are thinking in these terms:

http://html5.org/tools/web-apps-tracker

But frankly, the set of people with that particular perspective is 
something you could count on with just fingers and toes.  Pretty much 
everyone else in the world is starting from here:

http://dev.w3.org/html5/html4-differences/

> Incidentally, the "building from justification" design that we've used 
> with HTML5 so far explains why I disagree that anything has been 
> "dropped". It might be quibbling semantics, but (for example) summary="" 
> wasn't dropped from HTML5, it was never added. (The profile="" attribute 
> actually _was_ dropped: an early draft had detailed conformance criteria 
> for it, but it was removed in the face of solid data indicating it didn't 
> actually solve the use cases presented and convincing arguments that it 
> wasn't really necessary.)
> 
>> I don't know about others, but I think that exercise and approach has 
>> been, and continues to be, useful.  And I believe it should continue for 
>> the moment.
>>
>> I'm not convinced, however, that such an approach will prove anywhere 
>> near as useful as we progress towards Candidate Recommendation.  In 
>> fact, it probably needs to be abandoned before Last Call.
> 
> Could you elaborate on this?

The short version is here:

http://lists.w3.org/Archives/Public/public-html/2009Feb/0121.html

The longer version goes something like this: you've lived HTML5.  You've 
seen it grow up brick by brick.  It all looks like baby steps to you. 
Trust me, that's not how it looks from the outside.  Not even close.

Let's look at it from the outside for a moment.

If HTML5 is what it is, what would HTML4.5 look like?  How about HTML 
4.3?  In fact, what would a new spec look like that didn't have *any* 
new features, and "reincorporated" the features that were never in HTML5 
but are in HTML4?

Now, *that* would be a baby step.  Not on a micro scale, but on a macro 
scale.  It would have all of the predictable error recovery goodness of 
HTML5.  It would have things like <meta charset=utf-8>.  It wouldn't 
have SQL and certainly wouldn't have RDFa, but those could be deferred 
for a while.  Perhaps some longer than others.

Think about it.  It is a different perspective.  But it is something 
that could be built this year, gain consensus, and go to CR next year. 
And would blaze a trail, clear out the underbrush, and pave a path for 
the rest to to follow in 2012.  That path is hard enough as it is.  It 
would be a lot easier if the first time through you didn't have to deal 
with those that feel that they are missing something essential because 
table summary was "dropped".  We all benefit if that particular 
discussion could be deferred for a while, too.

It may be something you could do.  Or, with a suitable editor, could be 
done in parallel.  Might even be possible with the equivalent of #ifdefs 
in a common spec.

- Sam Ruby
Received on Friday, 6 February 2009 03:22:25 UTC

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