Re: Support Existing Content

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:14:19 UTC