Re: Support Existing Content

On May 1, 2007, at 12:27 AM, Roger Johansson wrote:

>
>
> On 1 maj 2007, at 02.13, David Hyatt wrote:
>
>> A spec could include elements that are considered poor practice  
>> and label them as such, and conformance checkers could be designed  
>> to help encourage authors to reach the highest level of  
>> conformance possible (thus avoiding these poor practice elements).
>
> I think that is necessary if HTML 5 is to gain any popularity among  
> Web standards-aware developers such as myself.
>
> Much of the current discussion could be avoided if the spec clearly  
> said something to the extent of "Browsers must implement and render  
> junk markup interoperably, but authors (Web designers, developers,  
> writers, CMS tools, WYSIWYG tools, etc.) must not use any of these  
> deprecated elements and attributes."
>
> Basically a clear distinction between what browsers have to accept  
> (all HTML that has ever been created) and what authors are allowed  
> to use (semantic, accessible, non-presentational HTML).
>
> Apologies if that is already in the HTML 5 WD. I have not had time  
> to read every word of it.

This is already in the HTML5 draft that has been proposed for  
adoption. It's the distinction between user agent conformance (what  
you have to accept to be conforming) and document conformance (what  
you have to emit to be conforming).

> Something that is bugging me (and I think others as well) is the  
> apparent fear browser vendors have of doing anything to encourage  
> people to create better (valid, well-formed, accessible, semantic)  
> markup.

We definitely want to encourage people to create better markup.  
Markup that passes automated conformance checking tools (DTD  
validators or more extensive checkers) is more likely to behave  
consistently in a variety of environments. Markup that better  
separates presentation is more likely to be usable on a variety of  
devices, and for users with accessibility needs.

I think the way to encourage good markup practices is to clearly  
express the benefits to content authors. For instance, the more kinds  
of errors we can identify with conformance checking, the more value  
there is to authors to using it.

> Obviously you can't display a modal dialog for each HTML error. But  
> most browsers have an error console that logs JavaScript errors and  
> warnings. Firefox lists CSS properties it doesn't recognise there  
> as well. Why not also list HTML errors in the error console?

Probably the best way for browsers to include reporting of HTML  
errors is through built-in access to conformance checking tools.

HTML is somewhat different from CSS and JavaScript in this regard.  
Unknown properties and JavaScript exceptions are all detected at  
runtime in a natural way that makes it possible to identify the  
direct source of the problem. But for many kinds of HTML conformance  
problems, detecting the source of the problem and giving a useful  
error message may actually be harder than just handling the error  
case properly.

Note that browsers don't generally warn of JS problems that should be  
an error according to the spec, but that the browser nontheless  
handles for compatibility, except perhaps in special-error-checking  
modes. Also, the CSS warnings displayed by Firefox are not an  
exhaustive list of CSS conformance problems. Using a CSS conformance  
checker will give you much better results.

Regards,
Maciej

Received on Tuesday, 1 May 2007 18:04:11 UTC