Re: Support Existing Content

This is going to be my last post on the subject.
I find myself continually beating my head against a brick wall, and  
now my brains are falling out.
If I haven't explained my point by this point, and i think i have,  
then it's never going to get across.
Similarly, I haven't read anything near to convincing me to change my  
position, though I have tried.

On 4 May 2007, at 11:11, Maciej Stachowiak wrote:
>
> 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.
>
The harm is new authors, and existing bad authors continue to write  
non-conforming bad tag-soup and the web is always going to be a mess.
(What's the harm in letting someone remove the letter E form english,  
the rest of us could probably guess what authors mean, it's harder,  
but we /could/ do it)

>>
>> 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.
>
I still don't buy this one. UAs already render what we have. Freeze  
this as html4 mode (tag soup mode, whatever).
You can then /still/ use this parser as the starting code, which you  
are going to be changing anyway, for html5.

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

When your computer crashes - you want to know why.
If my browser is now only using html4 features and the /new/ html5  
features have been disabled, I'd like to know why. Especially as some  
website feature might now not work as I'm stuck in the wrong mode.

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

I agree.
But you know who to be annoyed at and you can vent your frustration.
Currently if I browse the web, and find errors, you can blame the  
author, who can blame the browser vendor, who can blame the author, etc.
Don't you think authors continually getting complaints, will lose  
business and either learn how to fix the problems, or maybe change  
career?
Is it really bad to strive for a situation where authors are  
producing good code? I really hope not.

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

Ok, Can you give me an example, in terms of the car hitting a  
pedestrian, what would happen with your method of error recovery?

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

I don't s a valid rason for allowing this to happn. In no othr  
disciplin do w allow random and arbitary changs to occur, why HTML?

>>>
>> 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.
>
I think you are maybe getting the "customer service" effect.
If I work for a company selling ipods, and people continually phone  
me up and say they don't play wma, or that there is no music on it,  
there is no fm tuner, what is the impression I get?
That all people buying ipods are stupid?
We all know they are not, you /may/ only get the stupid ones calling  
you up, and you never hear from the happy ones, or the ones that know  
what is going on, when errors present themselves.

>> 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.
>
I will go out on a limb here and suggest that this comment is because  
UAs have no intention of ever supporting "draconian" error handling.
Even if it were proved to be a vastly great thing.
It just worries me that the UAs seem to be here for as long as they  
can agree on how to do things, so they can try to steal each other's  
market share, but as soon as something goes against that ability,  
they are going to walk away, even if that "something" is going to be  
beneficial.
It seems to me that there will be topics that are "untouchable",  
because if the spec treads on those toes we lose the UA vendors and  
the process descends into chaos.
I for one would rather see the UA vendors still here, so may well  
just have to say that, although I don't agree, we have to progress.

Would it be acceptable to make a request of browser vendors to add a  
"stop on error" mode to their parsers, so we could selectively "opt-in"?
I know that request is out of scope of this list, and I can't  
actually see a browser vendor acquiescing to it as it's more work for  
something they actively don't want anyway.

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

If I change a site and don't check it works correctly before going  
live, (I deserve to lose business and) it's my fault.

> It's a problem for users because they don't get the info they want.

Even with a fallback rendering mode?

> It's a problem for browser vendors because we usually get the blame  
> for site problems.

As before, I /know/ you get some blame, but not all of it.

Thanks for the lively debate guys, but it's time to move on.

Received on Friday, 4 May 2007 10:53:09 UTC