Re: Statistics on mobileOK Basic

On Wed, Mar 12, 2008 at 12:24 PM, Jo Rabin <jrabin@mtld.mobi> wrote:
>  3) But now, it seems mad that a lot of HTML is generated by machines and
>  other tools and that human readable formats are transferred to other
>  machines for display purposes. The machines don't need it to be human
>  readable - in fact that is the cause of the problem, in some ways.
>  5) HTML5 seems on the face of it to perpetuate this thinking. Would it
>  be better to create a non human readable format that you can't
>  reasonably write by hand, if it's important to reduce the complexity of
>  parsers? If that's not important why is validity such a big deal?

I do most strongly sympathize with this line of thinking. Tools are
involved enough at every point in the chain that it doesn't strike me
that we need more relaxed, "human-friendly" formats. Perhaps those
involved with browser development can confirm, but again I've heard
anecdotally that most rendering code in a browser is present to work
around bad markup; they'd be faster if they could assume more about
the document's format.

So there is a cost to embracing a more relaxed standard that has a
larger universe of "valid" documents, with yet no more expressive
power. And, to my mind, little benefit.

We've already come a long way to make HTML more rigorous and therefore
more easily, consistently parseable. Sure, browsers will continue to
have to deal with cruft. But they can give VIP treatment to documents
that are correctly structured, as Firefox's "standards compliance
mode" does. Is there going to be as much benefit to complying with
HTML 5 in this way, if it offers a looser definition of
well-formedness? I would imagine not as much.

I suppose I think this is just a needless facet of HTML 5; the rest of
it is at least plausibly useful.

But... I realize I've gone on too long about HTML here.


>  6) Given we live in the world we do, where browsers do put up with any
>  old nonsense, and noting Dom's comments earlier in this thread about
>  errors you should care about, vs ones that you shouldn't, should we not
>  in BP be taking a stand against strict validity, and limit ourselves to
>  proper problems? How would we do that?

+1 to standing, in principle, for standards. My original issue was
more with the required vocabulary of XHTML Basic (e.g. required
xml:lang attribute -- a big gotcha), but, that is an XHTML Basic issue
if anything, and I'm sure one on which informed people can disagree,
and I am not even informed there. I don't suggest a change to what
we're working on.

Received on Wednesday, 12 March 2008 17:11:31 UTC