[Bug 13943] <track> The "bad cue" handling is stricter than it should be

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13943

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #17 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-10-01 00:11:45 UTC ---
(In reply to comment #11)
> I agree with Philip. The parser shouldn't droconianly drop cues for trivial
> authoring mistakes.

The error handling model here is the same as CSS's error handling model, which
is the least draconian model on the Web platform, and the exact opposite of
XML's, which people normally are referring to when they talk about draconian
error handling. Draconian error handling is throwing the entire document away
when you find one error. The handling we have here is forward-compatible
dropping of the self-contained unit of markup that is syntactically incorrect.

I strongly disagree that there is value in making the language DWIMmy. So far
on the Web, of the "bail on error", "ignore on error", and "try to work around
the error" models, the first has been found to be impractical (XML), the last
has been found to be unwieldly (HTML), and the second has been found to strike
the perfect balance between ease of use, simplicity, ease of implementation,
forward- compatibility, and consistency. We should not ignore the lessons we
have learnt with HTML.

We can never reliably catch authoring mistakes ("02.000" vs "20.000" both look
valid but one is wrong) nor reliably fix them (maybe "002.000" is a typo for
"02.000" or maybe it's a typo for "00.200" or maybe it's a typo for "20.000").
We can detect syntactic errors, and we can report them — that's what validators
are for and we should definitely have one.

Now if there are common errors that we can easily detect and deal with, it can
make sense to handle those. But we shouldn't try to handle errors that aren't
common, and we shouldn't try to handle errors without a good idea that they
really _are_ common, ideally based on solid data like foolip's.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 1 October 2011 00:11:49 UTC