Re: Support Existing Content

On May 4, 2007, at 2:46 AM, Gareth Hay wrote:

>
> 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 think if error handling is clearly specified, the harm is pretty  
small. Can you tell me what you what you think the harm is? I don't  
think we can just take it as an axiom that it's harmful.

>>> 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?

It requires implementation of a mode for HTML5 that is separate from  
all current parsing and rendering modes, and could lead to loss of  
market share if other UAs are less lenient.

> 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.

Sounds like we've come a lot close to agreement. Now can you tell me  
what's the benefit to end users (as opposed to web developers, using  
web development software, or in-browser developer tools) seeing this  
error?

>>> [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?

If you sent me a document, I loaded it in a program that someone else  
gave me, and it said "Segmentation Fault", I would probably be  
annoyed at the author of that program. And if that document contained  
my bank statement, I would be quite frustrated.

> Why is it "end user" punishment. It's the /authors/ fault.

The author's mistake prevents the user from receiving the information  
they want, and exposes them to a confusing error message. Regardless  
of whose fault it is, surely this is a punishment for the end user.  
How can it not be? If you get hit by a car, does it make you feel  
better that it's the driver's 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.

OK, but what's the actual harm of doing so? Can you describe it in  
words? You've said repeatedly that you think nonconforming content is  
really bad, but you haven't once explained how its existence hurts  
anyone, or how wiping it out would help anyone.

>>> 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.

Since I have some experience developing a browser, I can assure you  
that this is exactly who gets the blame. When Site X doesn't work in  
Safari, users don't try to find out if the site has a bug, they  
complain to Apple or switch to Firefox.

> What would happen, no-one would be able to read digg and they lose  
> all their 'custom'.

Unless it worked in other browsers that were less strict about error  
checking.

> 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 for.

It's a problem for them because if they publish with a minor syntax  
error by mistake, they lose business. It's a problem for users  
because they don't get the info they want. It's a problem for browser  
vendors because we usually get the blame for site problems.

>>> 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  
> altogether.

Failing to render all HTML would prevent users from seeing even more  
documents than just failing to render nonconforming HTML. So  
obviously it's not a good idea.

Regards,
Maciej

Received on Friday, 4 May 2007 10:12:00 UTC