Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

An open invitation to the HTML5 team

HTML5 was conceived and continues to be developed within a group of likeminded people. There has not been any in-depth debate about the design principles of HTML5, the direction in which HTML5 is heading, nor the process in which HTML5 is developed. As a result, HTML5 may not be meeting the needs of many stakeholders in Web technology and may be insufficient to significantly evolve the Web. I invite the HTML5 team to a series of debates, with myself and others, on HTML5 and the future of Web technology.

Oh, no, more of the same old discussions

Yes, some of the topics that need discussing are old ones, but they are still unresolved. Many of them have been simply sidetracked or ignored. And there are new topics that should be discussed as well.

This is important to everyone

Who is the HTML5 spec being developed for? In the past, when the Web was new and it wasn't yet clear who all the players and stakeholders were, enhancing HTML used to be a way for browser vendors to add new features into their browsers. Today, browser vendors are not the only stakeholders in Web technology, so enhancements to HTML need to come out of a real collaborative partnership amongst all stakeholders in Web technology. We owe it to the current users of the Web and for future generations to have open and honest debate today on how to best to evolve Web technology.

Challenging one's beliefs can leads to better solutions

The only way to know if we are doing the right thing is to scrutinize our assumptions and beliefs. This open invitation to the HTML5 team to debate the future of Web technology may see some of their assumptions confirmed. They may even convert some current critics of their work onto their side. Or new ideas may emerge that have not even been considered to date. The point is that it is essential, and our responsibility, to have this debate in order to create better solutions for the users of the Web.

We care about the Web too!

We don't want to see the Web broken. We want the Web to have really cool features. We want developers to build feature rich and powerful Web applications. We believe the browser can be a powerful Web application runtime environment. We have a lot in common, let's build on that and discuss our differences.

What's the next step? - A challenge to Ian Hickson

The next step is to begin meaningful discussions about HTML5 and the future of Web technology; discussions in which fear mongering, bullying and personal attacks are put aside. Let's try to find ways to make each other's ideas work instead of fail, and be open to new possibilities.

The first phase in these debates is a challenge, from me to Ian Hickson, chief editor of the HTML5 spec. Ian I invite you to debate me on the following topic: Error messages should be displayed for corrupt HTML5.

Will you accept my invitation Ian?

Public comments

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.

4. Posted by Vlad Alexander
on Tuesday 2010-01-05 at 09:58:12 PST

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

I, like many others, do not have confidence in the way W3C HTML WG is functioning. The browser vendors have total control over the process. Until other stakeholders in Web technology have an equitable voice and influence in the process, I will continue to advocate for change from the street.

Maciej - thanks for the links but these are not links to any type of debate where all the stakeholders engage before decisions are made. Criticisms on mailing lists, made after the fact, do not constitute active engagement and debate.

Lachlan, thanks for being open minded (yes, I'm being ironic)!

5. Posted by Vlad Alexander
on Tuesday 2010-01-05 at 10:00:50 PST

In an email, Ian Hickson responded to my request for a public debate as follows:

You are always welcome to debate HTML5; it has been an open process since
its inception six years ago. We have literally over a thousand people
subscribed to the WHATWG mailing list, and literally hundreds of people
have actively contributed to HTML5's development:

http://www.whatwg.org/specs/web-apps/current-work/multipage/acknowledgements.html

You can also participate in open debate by posting to the WHATWG blog, or
by taking part in the WHATWG forums, or by participating in the many W3C
mailing lists for HTML's development.

For more details on how to participate in HTML's development, please see
the WHATWG FAQ:

http://wiki.whatwg.org/wiki/FAQ

6. Posted by Vlad Alexander
on Tuesday 2010-01-05 at 10:02:11 PST

Ian Hickson wrote: "You are always welcome to debate HTML5"

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

Ian Hickson wrote: "it has been an open process"

The process is not really open if the senior people on the HTML5 team do not make themselves available to face their critics in direct and structured two-way discussions such as I am proposing to you.

Ian, as the leader of the HTML5 team, you have a responsibility to make yourself available to debate what is being decided by your group. Will you accept this request to have a public debate with me on the issues?

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’

8. Posted by Vlad Alexander
on Wednesday 2010-01-06 at 10:38:13 PST

Oli Studholme wrote: "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."

There are no existing "channels" that allow for public debate (which means a question is put and must be answered). Input on mailing lists, forums, blogs and IRC can and is ignored by the HTML5 team, who respond to only those issues that they feel are safe to respond to; issues that do not challenge basic principles and assumptions; issues that do not question who is making the decisions that will shape the Web for the next decades.

Oli Studholme wrote: "Regarding draconian error handling I think your best bet is to build a time machine..."

Please check out my argument for having error message in HTML5 and see if my proposal is a fair and reasonable way to use error messages and hardly draconian.

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?

12. Posted by Vlad Alexander
on Thursday 2010-01-07 at 09:44:08 PST

Oli Studholme wrote: "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."

In my article 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. And Web browsers should only display error messages if Web site creators are using new features (i.e. HTML5).

Lachlan Hunt wrote: "What new arguments do you have, which haven't already been responded to in the past?"

The responses in the past have been inadequate. For example, in the comments for my article on error messages, you say that this will not happen, you describe the method and you state that it's a bad idea. This is not a compelling argument. What is missing is the "why". Why won't this happen? Why is this a bad idea?

Lachlan, in those comments, I also asked you to provide me with solid arguments against the four points I made in the article. You did not respond. I am not criticizing you for not responding, but this is an example of partial/unfinished conversations that have occurred in the past on lists, blogs and forums.

Lachlan Hunt wrote: "It's also not clear how or where you want this debate with Hixie to take place."

This Web site has debate software. In a private email to Ian, I sent him login details and the link to the public page that will allow him to debate me, and allow for public comments. The debate software allows for multiple people on each side of the debate, as well as a moderator. If Ian would prefer to have an additional person on his debate team and a moderator, I would welcome that.

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

15. Posted by Vlad Alexander
on Friday 2010-01-08 at 10:43:25 PST

Oli Studholme wrote: "And 'almost never see error messages' is the same as 'will see error messages'."

My statement is open to the possibility of errors to occur during transmission. For example, half the document gets cut-off by a proxy server or during FTP.

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?

19. Posted by Vlad Alexander
on Wednesday 2010-01-13 at 02:39:59 PST

Lachlan Hunt wrote: "The reason why it's a bad idea is because showing error messages to end users ..."

It would be extremely rare for Web site visitors to see error messages because Web site creators will fix them when they test/review their work.

Lachlan Hunt wrote: "...especially when it will occur on the vast majority of sites that already do contain errors."

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

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

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.

21. Posted by Vlad Alexander
on Wednesday 2010-01-13 at 03:18:17 PST

Martin Kliehm wrote: "..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."

This is a wonderful example. Let's make a use-case out of it. Sally, a non-technical Web site visitor is doing online banking and a proxy server at her ISP cuts off half of the Web page that shows her banking activity. Martin, should Sally be notified is some way that there is something wrong with the Web page and instructed to press the refresh button or should Sally be given the mushroom treatment by her Web browser?

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?

25. Posted by Vlad Alexander
on Wednesday 2010-01-13 at 09:04:31 PST

Philip Taylor wrote: "Testing and reviewing code is insufficient, because the errors only occur with certain inputs ..."

Exactly, certain inputs which are quite rare. For example, it would be extremely rare for a Web site visitor to accidentally insert a U+FFFF character into a blog posting.

Philip Taylor wrote: "(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?"

Error message should be displayed, but Sally will never see it in this case. This is a perfect example of a case where the Web site creator catches the problem during test/review of the system and fixes the problem.

Philip Taylor wrote: "...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."

In my article where I lay out the argument in support for error messages, I ask if documents on the Web are important or not. Do you believe that the "Web is just a collection of rubbish"?

Philip Taylor wrote: "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."

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.

Philip Taylor wrote: "So we should reduce the harmful effects ... designing markup languages with less complex notions of 'correct' (e.g. without so many forbidden character ranges)"

On this point I am in total agreement with you but the HTML5 team is rejecting any calls for new markup languages or significant changes to HTML.

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.

27. Posted by Vlad Alexander
on Wednesday 2010-01-13 at 11:34:54 PST

Lachlan Hunt wrote: "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?"

Lachlan, does this mean you agree with my argument for error messages for corrupt HTML5 and the only stumbling block is identifying HTML5 pages? Is so, and then we can talk implementation!

Philip Taylor wrote: "Is there a specific way that you prefer [to display error messages to users]?"

For most types of errors, I would prefer to use the message bar built into most browsers as shown in the screen shot below.

A screen shot of a Web browsers displaying an error message in a yellow bar above page content. The error message reads: 'This Web page contains errors that may cause the page to display or function incorrectly. Click here for options...'.

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?

30. Posted by Vlad Alexander
on Thursday 2010-01-14 at 08:58:54 PST

Lachlan Hunt wrote: "Also, can you answer my previous questions at the end of comment 24? [Question in comment 24: 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?]

Please re-state examples one by one and I will try to address them for you. Please provide examples only if they are applicable to HTML5, not XML.

Lachlan Hunt wrote: "I then went on to debunk a likely candidate for such detection: the DOCTYPE."

Is that called pre-emptive debunking? :-) The use of DOCTYPE is feasible but not my first choice. I would simply write into the spec that some features, such as <video> and <canvas>, must only work in documents written to specification. You are giving users new features free of charge and in exchange you simply ask that they use them in documents that are written to specification - that's a fair and reasonable trade.

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.

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.