W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Support Existing Content

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 03 May 2007 15:41:27 -0700
Message-ID: <463A6517.4060906@sicking.cc>
CC: public-html@w3.org

As has been suggested before, I think it'd be better to create a 
document separate from the spec that is meant for users of the spec, 
i.e. web authors. I think that could be made much more readable than the 
spec ever will be, even if we remove error handling from it.

The XBL2 spec will have the same thing done to it.

/ Jonas

Jeff Schiller wrote:
> 
> What do the editors think of:
> 
> a) put the HTML5 language in one spec (including the DOM tree):
> audience = content authors, user agent developers
> 
> b) another spec that has guidelines for user agents to process
> legacy/non-conforming content into an HTML5-compatible DOM tree:
> audience = user agent developers
> 
> That way content authors don't get the wrong idea if they're only
> looking at the HTML5 spec to learn it.
> 
> Jeff
> 
> On 5/3/07, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> Gareth Hay wrote:
>> >
>> >
>> > On 3 May 2007, at 18:07, Maciej Stachowiak wrote:
>> >
>> >>
>> >> On May 2, 2007, at 2:10 PM, Gareth Hay wrote:
>> >>
>> >>> I'm not trying to make lives easier on any side.
>> >>> The web is a mess, even you concede this point with your rantings
>> >>> about external advertising content.
>> >>> Do you want it to continue like this? or do you want to pro-actively
>> >>> fix it?
>> >>
>> >> What's the point of "fixing the web" if it doesn't make anyone's lives
>> >> easier? This is a totally serious question - a lot of people seem to
>> >> be advocating the forcing of valid markup regardless of whether it
>> >> helps or hurts people. Surely the reason for abstract goals like use
>> >> of conforming markup is to have good concrete effects.
>> >>
>> > It only hurts the lazy, or the uneducated author. Either can change 
>> easily.
>> > I'm not advocating we make HTML rocket science or brain surgery, it
>> > doesn't have to be hard, at the moment it /is/ hard because it id
>> > broken, new authors find broken ways of doing things and see nothing
>> > wrong "because it works".
>>
>> These are the arguments against "draconian errorhandling" that I can see:
>>
>> 1.
>> If we're making something that is that backwards incompatible, why not
>> instead go all the way and do something like XHTML2 that is a completely
>> new language. That way we could get rid of tags that we're only keeping
>> around for backwards compatibility anyway.
>> And at that point we might as well also use XML rather than create a new
>> language that needs a parser written for it. Most UAs need an XML parser
>> anyway.
>>
>> 2.
>> It's hard for authors to get things perfect. Writing bug free code has
>> nothing to do with being lazy or uninformed. When did you ever run into
>> a bugfree software program? If you want to generate something with as
>> strict parsing rules as that you probably want to write code that
>> provably creates good output. The only way I can think of to do that
>> would be to let servers generate DOM-like data structures that then gets
>> serialized before sent over the wire.
>> While this sounds like a good design to me, it would be a big change
>> from how servers work today and would significantly raise the bar for
>> adopting HTML5 for authors.
>>
>> 3.
>> The "cleanup" of the web it would accomplish is actually fairly small.
>> Most quirks and inconsistencies is in how things behave after they have
>> been parsed. The biggest one is in how things are rendered, but also in
>> how the DOM behaves.
>> And while there is some value for UA developers since they'd have an
>> easier time writing the parser, I see little to no value for web authors
>> over having relaxed, but consistent, error handling in the various 
>> browsers.
>>
>>
>> The result is that the price you pay for such strict error handling (1
>> and 2) is very high, while the value you get (3) is pretty small.
>>
>> / Jonas
>>
>>
Received on Thursday, 3 May 2007 22:44:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:58 GMT