Rebuilding The Web

1. Posted by Dan Brickley
on Tuesday 2010-01-05 at 02:39:51 PST

Who is this 'we' you mention several times?

What would it take for you to be happy conducting this debate within the framework of the W3C HTML WG?

cheers,

Dan

2. Posted by Maciej Stachowiak
on Tuesday 2010-01-05 at 03:46:31 PST

> There has not been any in-depth debate about the design principles of HTML5,

HTML Design Principles - http://dev.w3.org/html5/html-design-principles/Overview.html

> the direction in which HTML5 is heading,

HTML5 bug tracker - http://bit.ly/6CvSBr
HTML5 issue tracker - http://www.w3.org/html/wg/tracker/issues/open

> nor the process in which HTML5 is developed.

HTML WG Decision Policy - http://dev.w3.org/html5/decision-policy/decision-policy.html

Hope this helps. You're welcome to advocate your views in the HTML WG in accordance with the process.

3. Posted by Lachlan Hunt
on Tuesday 2010-01-05 at 03:49:04 PST

What is there to debate on the topic of showing error messages for corrupt HTML5? That's clearly an issue for the browser vendors to decide, not Hixie, and at least as far as the major browsers seem concerned, draconian error handling for HTML, à la XHTML, is not going to happen. But reporting error messages in their error consoles, just like some do for JavaScript and CSS already, is doable and perfectly reasonable. But, again, that is an implementation decision for implementers to make, not something to be specced.

7. Posted by Oli Studholme
on Wednesday 2010-01-06 at 00:39:11 PST

“Debate HTML5 with whom, myself? Or with random people on a mailing list/forum/blog who have no decision-making power?”

How about IRC?
http://wiki.whatwg.org/wiki/IRC

Regarding draconian error handling I think your best bet is to build a time machine and get TBL to implement it right from the start. Unfortunately that’s not how the web works now, and wishing won’t make it so. Another alternative is to invest effort in education.

btw your premise that your comments are more important than other contributors, and that Hixie should agree to debate with you outside of the several channels that already exist, seems somewhat hubristic. Just sayin’

9. Posted by mattur
on Wednesday 2010-01-06 at 10:57:39 PST

You could have the debate right here!

Vlad: To meet the needs of many stakeholders in Web technology and to significantly evolve the Web, users should be exposed to error messages they a) don't understand b) can't do anything about and c) don't care about anyway.

WHATWG: Use XHTML5.

Vlad: OK.

[ends]

10. Posted by Oli Studholme
on Wednesday 2010-01-06 at 20:59:18 PST

“There are no existing "channels" that allow for public debate (which means a question is put and *must* be answered)”

Maybe it has something to do with the way you ask the question…

(cf “*must* be answered,” “fear mongering, bullying and personal attacks,” “I do not have confidence in the way W3C HTML WG is functioning,” “Lachlan, thanks for being open minded (yes, I'm being ironic)!”…)

I checked your argument and think it is well-meaning but unrealistic. Please show your grandmother a page with an XML error and ask her what she should do. Ideally add one to an e-commerce or bank website and gauge the reaction. Any error freaks non-technical people out. Also, you expect that all current HTML-generating tools will become capable of producing compliant code based on a specification—yet for example Microsoft is still unable to make a browser that correctly processes XHTML.

I actually think one of HTML’s strengths is it’s best effort rendering. I think this forgiveness (& HTML’s low barrier of entry) helped make the net such a success. If only valid pages were allowed on the internet, there wouldn’t be much out there.

Instead of debate—in which you seem to desire to beat Hixie into submission with your idea—why don’t you give dialog a go?

PS I’m pleasantly surprised you even responded to this random person on a blog with no decision-making power :P

11. Posted by Lachlan Hunt
on Thursday 2010-01-07 at 04:30:00 PST

Vlad, I'm sorry that you think I'm not open minded. I am perfectly willing to listen to and well reasoned arguments. But I've not seen any from you on this topic and I really don't understand what you realistically expect to achieve from this. What new arguments do you have, which haven't already been responded to in the past?

It's also not clear how or where you want this debate with Hixie to take place. Are you looking for a face to face debate? Or an e-mail debate? Or on IRC? What sort of structure are you expecting? Do you want the traditional style 3 vs. 3 approach, with 3 on the affirmative side and 3 on the negative side, with each team given their turn to make their arguments and rebuttals? Or do you just want it one-on-one with Hixie?

13. Posted by Oli Studholme
on Thursday 2010-01-07 at 19:45:25 PST

“I make an argument that Web site visitors (i.e. grandmother) will almost never see error messages because if Web browsers displayed error messages, the Web page creators will fix errors when they test/review their work.”

You assume web page creators will test/review their work. You also assume that web page creators are human. And “almost never see error messages” is the same as “will see error messages”. The number of pageviews per day must be staggering now. If even a tiny percentage have errors that’s a lot of error messages.

Even if we ignore all the shitty software that makes error-filled HTML, humans are error-prone. You dream of a world where there are zero errors in the HTML, the browser that displays the code and decides if there’s an error, and the spec. Sounds great to me, but also somewhat unrealistic.

“And Web browsers should only display error messages if Web site creators are using new features (i.e. HTML5).”

By new features do you mean new elements? I’ve made a site using the <div class="element-name"> pattern so I can use HTML5 without using new elements (due to IE JS disabled concerns). I use the HTML5 doctype. I validate using the HTML5 validator. How can you tell it’s HTML5?

Finally for your reading pleasure:
http://diveintomark.org/archives/2004/01/14/thought_experiment

14. Posted by mattur
on Friday 2010-01-08 at 08:10:19 PST

Also:
http://diveintomark.org/archives/2008/03/09/no-fury-like-dracon-scorned

16. Posted by Lachlan Hunt
on Wednesday 2010-01-13 at 00:52:41 PST

I find it hard to believe that you're unaware of the reason why. I've heard the argument raised against you many times in the past. It seems more likely that you're just choosing to ignore it.

The reason why it's a bad idea is because showing error messages to end users, most of whom won't understand what it means, and none of whom will be able to do anything about it to correct it, is clearly bad usability, especially when it will occur on the vast majority of sites that already do contain errors.

What you really want is for error messages to be made more visible to developers, since they're the ones who can actually do something about it on their sites. But that needs to be done by encouraging developers to install and use the appropriate tools, rather than simply trying to force the error messages to be shown to everyone.

17. Posted by Philip Taylor
on Wednesday 2010-01-13 at 00:56:18 PST

The difficulty with testing is that even if you get complete test coverage of all your application code, the correctness of your output depends on your input data. E.g. it's common that posting a blog comment containing U+FFFF will break XHTML sites, because they never tested that case. Since XML's rules are stricter than the rules applied by the input and processing parts of the site, it's easy to introduce data that is handled perfectly fine right up to the point where it throws an error at an unrelated user's browser. Perfect input validation seems infeasible because most applications have many sources of input (HTTP form data, HTTP headers, databases, text files, JSON APIs, etc) and it's hard to catch them all. Output filtering (e.g. deleting all characters that aren't valid XML) seems easier, since it can be added to whatever function escapes '<' to prevent XSS attacks, but nobody appears to do it properly. The result is that most XHTML sites are vulnerable to DOS attacks from unlucky or malicious users, even when they were carefully tested and reviewed, with errors introduced long after authoring.

18. Posted by Maciej Stachowiak
on Wednesday 2010-01-13 at 01:04:36 PST

Vlad,

No True Scotsman?

20. Posted by Martin Kliehm
on Wednesday 2010-01-13 at 02:58:40 PST

Error messages should not be displayed for corrupt HTML5 (or XHTML), because the corruption may have happened beyond your control between server and client, where mobile ISPs compress, rewrite and misuse your originally clean code in every way imaginable.

22. Posted by Philip Taylor
on Wednesday 2010-01-13 at 04:08:08 PST

"are you trying to argue that bugs or limitations in existing software is the reason certain features should not be implemented in future software/specs?"

I think my current view is that pervasive classes of implementation bugs should be an important consideration in the design of future systems. E.g. almost everyone writing code in C introduces buffer overflows, which indicates a fundamental difficulty that programmers have with avoiding such bugs. Testing and reviewing code is insufficient, because the errors only occur with certain inputs and are hard to spot. So we accept the reality that programmers will make mistakes, and build new compilers with stack corruption checks, and design new languages with automatic bounds checking, and create operating systems that randomise memory layout, all of which help reduce the harmful effects of these errors. (In this case, the security concerns mean it's often less harmful from the user's perspective for the program to throw an exception or otherwise terminate, than for it to continue running.)

Similarly, almost everyone writing code that emits XML based on user input has bugs that allow non-well-formed output, particularly because of syntax restrictions that aren't necessary for disambiguating the grammar. We're never going to stop everyone writing bugs like that. Testing and reviewing code is insufficient, because the errors only occur with certain inputs and are hard to spot. In the case of almost all web sites, it's less harmful for users to see a slightly corrupted page, than for the entire page (or large chunks of it) to be completely unusable. So we should reduce the harmful effects by using server-side serialisation frameworks that guarantee correct output for any unrestricted input, and designing markup languages with less complex notions of "correct" (e.g. without so many forbidden character ranges), and having web page consumers recover automatically from errors.

23. Posted by Philip Taylor
on Wednesday 2010-01-13 at 04:31:55 PST

Sally sets up a payment on her banking site, and clicks the "confirm" button. The web server sends back a page saying "Your transaction has been completed. Before you go, perhaps we could interest you in some offers from our partners? Special offer today: save £££s on your mortgage!" but the person who typed in today's special offer text (via a COBOL interface to their decades-old database) used ISO-8859-1 instead of UTF-8 and so the web page output is incorrectly encoded. Should the page be replaced with an error message and Sally told to press the refresh button?

It seems to me that hypothetical situations on banking sites can be used to argue either way. No solution will be ideal for all cases, so it's a matter of finding what's better overall; and the vast majority of sites are not banks and their users will care much more about just getting some information from the page and much less about minor errors.

24. Posted by Lachlan Hunt
on Wednesday 2010-01-13 at 08:40:02 PST

What are you suggesting we do to determine which pages are new, and thus subject to showing error messages, and which pages are old, and thus should have errors ignored as today? The DOCTYPE, maybe?

If so, then authors will just learn to use an alternative DOCTYPE that doesn't trigger this unwanted behaviour, making the HTML5 DOCTYPE effectively useless in practice. Also, the browsers that implement this first will be at a competitive disadvantage, and users who will likely be irritated by the error messages, will just switch to a browser that works.

Do you realise the impact this would have on sites that choose to begin migrating existing page templates to utilise new HTML5 features? Imagine a news or blog site template being updated to utilise some new HTML5 sectioning elements, for example. These tempates will be used for all articles in the database, but consider what would happen to the articles that contain old mistakes that weren't caught when they were published? Suddenly, these old articles will start showing error messages to users just because the site decided to upgrade their templates to use HTML5, and it's likely that the developer won't notice this for a while.

Besides, there are already many hundreds of pages out there, including high profile sites like Google, using the HTML5 DOCTYPE, and it's highly likely that many of them contain errors of some kind (Google does, in fact, contain validity errors), or be subject to errors caused by unexpected user input that could occur at any time. Who do you think is going to go back and fix whatever mistakes are already in those pages? Do you realise how costly that could be for larger sites to go back and check all of their pages? Do you really think a browser is going to ship if it's known to display some error message to users viewing Google, and do you really expect Google to go through all their legacy code to fix their mistakes?

Since the error messages you're asking for are really targeted at developers, can you explain why you think everyone should be subjected to them, as opposed to just exposing them through error consoles and other tools, such as improved editors that help ensure correctness, that are easily accessible and usable by developers?

Why do you believe that developers will always see errors and fix them before they go live, despite there being several examples, some of which have been presented to you in this comment thread, where that has certainly not been the case for XML?

26. Posted by Philip Taylor
on Wednesday 2010-01-13 at 10:15:23 PST

"At no point in time have I advocated entire pages to be completely unusable. There are other ways to display error messages to users that will achieve the same result."

Is there a specific way that you prefer? Your error-messages post has examples of fatal unrecoverable errors in other applications as "the norm", and in the comments you seem to suggest following Opera's XML error page (which makes the page unusable, unless the user has the expertise to understand "Reparse this document as HTML" or clicks on it randomly), so I've assumed that's the kind of behaviour you are expecting in the context of HTML. I'm quite possibly jumping to incorrect conclusions - if you want non-fatal errors instead, then it would be a very different debate, so it'd be good to be clear on that. (Then the usual arguments would be that authors will ignore non-fatal errors, because they're lazy and want to focus on making their site look pretty and have useful content rather than being valid, so errors will be common; and most users won't understand the error indicator so it'll be confusing and a waste of valuable UI space, so browser developers prefer to handle errors silently by default.)

"Do you believe that the "Web is just a collection of rubbish"?"

That sounds like a false dilemma between "all web pages have no syntax errors" and "all web pages are rubbish". Most of the web is riddled with errors, and a lot of the web is very useful, and I'm not aware of much correlation between those groups.

28. Posted by Isaac Lin
on Wednesday 2010-01-13 at 18:15:28 PST

I believe any web site author who is indeed eager to fix all errors, letting none escape to their users, has the tools available now to do so. I don't think changes to the default user interfaces by the popular browser vendors will increase this population significantly.

Regarding a one-on-one debate: though I have no objection to looking for ways to increase the public's engagement with the W3C, I think individual challenges may not be the most effective mechanism. I do not believe it would be the best use of the committee's time to respond to every person's request for a debate.

29. Posted by Lachlan Hunt
on Thursday 2010-01-14 at 01:35:59 PST

"Lachlan, does this mean you agree with my argument for error messages for corrupt HTML5 and the only stumbling block is identifying HTML5 pages?"

No, it does not mean that. You seem have ignored the rest of my message and answered none of my questions. I'm just trying to understand how you think your suggestion will work in practice, given your earlier claim:

"Nobody is advocating error message for existing content. Error messages should be displayed for future content written to a future spec such as HTML5."

I then went on to debunk a likely candidate for such detection: the DOCTYPE. But if you have a realistic alternative, please explain.

Also, can you answer my previous questions at the end of comment 24?

31. Posted by Gaurav
on Friday 2010-01-15 at 21:11:44 PST

It's true, Vlad. The browser vendors are in complete control of HTML. If the spec writers were to write something and the browser vendors choose not to implement it, there is nothing anyone can do except write their own browser. It is completely unfair to all the other stakeholders in the process.

32. Posted by Fre
on Sunday 2010-01-17 at 09:39:08 PST

There are two sides to this story in my eyes.

Firstly, showing an error message to the end user does not help that user in any way. It's the responsibility of the developer to make sure the code is correct. Thus I feel that an implementation in an (x)HTML)-editor is far more appropriate, more like a real application won't compile if it has syntax errors.

Obviously in a perfect situation you could make the browser show a warning to the end user because it would motivate the developer to change it's faulty code. In a real life situation however I think there are far more lazy and incompetent developers out there than you might think. Still resulting in a lesser experience for the end user.

Secondly, what will this mean for developers getting ahead of things? What if I decide to implement some CSS3/HTML5 features that are currently not supported by the browser? Will these unsupported tags render an error? Probably? But more importantly is what this will result to in the future: even more browser identifiers and hacks. Is that really what we want?

I like the iCab approach, which is basically the same implementation as the Firefox Webdeveloper Toolbar. But this won't change anything. Developers that care about the standards will already have the Firefox Webdeveloper toolbar installed or will already be using the w3c validator. Lazy developers won't mind because the end experience won't be affected.

In the end it comes to down to this: Yes, in an ideal situation we should have a warning or block to websites not respecting the specifications. But there's no way we can implement this without affecting the end user experience and being forcefully enough at the same time.