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

Re: Support Existing Content

From: Gareth Hay <gazhay@gmail.com>
Date: Fri, 4 May 2007 10:46:12 +0100
Message-Id: <BC9F8C3D-C7F4-4002-B01A-AF342931402C@gmail.com>
Cc: matt@builtfromsource.com, public-html@w3.org
To: Maciej Stachowiak <mjs@apple.com>

On 4 May 2007, at 10:30, Maciej Stachowiak wrote:

>> I think that the situation we have just now is untenable.
> What's untenable about it? What is the actual harm of noncomforming  
> content that you're trying to solve?

You don't think tag-soup is harmful at all?

>> I don't think any form of (your definition) encouragement is going  
>> to work, after all, people have been pretty much free to go your  
>> way for years and haven't, so let's try (my definition)  
>> encouraging them a different way, which prevents them from getting  
>> things wrong.
> So who is helped by forcing error handling? We've already  
> established that "lazy or uneducated authors", browser vendors, and  
> end users will all be harmed by such an approach. But you still  
> haven't said who will be helped and how.

Have we already established such?
Lazy or uneducated users - yes, but any new novice users will learn  
the correct way, because other wise their code doesn't work.
Browser vendors? - hardly, stopping rendering on error can't be that  
difficult to add to their code, can it?
End users? - Only by poor authors, as I've said over and over and  
over again, existing content should be free to render in non-html5 mode.
I would concede to a point that a UA could decide to render  
automatically to html4 on error, but they still need to display that  
this has happened.

>> [aside: maybe it's because I grew up with "Segmentation Fault"  
>> fatal errors that I don't see that kind of error handling as "wrong"]
> Yes, most skilled human interface designers would consider it  
> unacceptable to show the string "Segmentation Fault" to an end user  
> ever, so your tastes in this regard are probably an outlier.

If I wrote a C program, it works for me, I send it to you, you run it  
and you get "Segmentation Fault", who do you blame?
Why is it "end user" punishment. It's the /authors/ fault.

>> I think "draconian" error handling leads to a much more educated  
>> author.
> So "more educated authors" is the benefit you're citing? Is that  
> it? You said before that uneducated authors would be harmed. Do you  
> think providing them with a forcible education outweighs the harm  
> to them and other groups?

So we specify the way someone /should/ write a document and then let  
them get away with doing it /close to/ the spec but not quite?
I think that is absurd, I really do.

>> Doesn't  "Parse error : line 5" - tell you all you need to know?
> If I loaded http://digg.com and saw that, then no, it would not  
> tell me all I need to know. Since what I need to know is the  
> information on the page, not a parse error.
So who are you going to blame? the browser vendor? I don't think so.
What would happen, no-one would be able to read digg and they lose  
all their 'custom'.
Why is this a problem if they haven't written the page properly?
Again "don't declare it as html5 if it isn't html5" is what I'm going  

>> I certainly wouldn't be to adverse to
>> 	 "This page was written as HTML5, but it is invalid. Error is  
>> 'non-conformity - line 5'. Do you want to try this as html4?"
>> Where the browser will attempt to render the page minus the html5  
>> doctype declaration.
> So you're ok with only annoying and confusing end-users instead of  
> preventing them completely from seeing the content. How about we  
> cut annoying the user out of the equation as well?
Ok if it's silly suggestion season, let's make authors render their  
pages to PDF and download them to UAs and you can still make use of  
JS and everyone gets the same output. Let's just do away with HTML  

Received on Friday, 4 May 2007 09:46:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:20 UTC