[whatwg] several messages about XML syntax and HTML5
tekelenb at euronet.nl
Mon Dec 4 11:44:38 PST 2006
[I unintentionally sent my previous message off-list. Sorry about that. Am
moving this back to the list again. As there's nothing personal in it, I
assume that's OK.]
At 18:37 +0000 UTC, on 2006-12-04, Ian Hickson wrote:
> On Mon, 4 Dec 2006, Sander Tekelenburg wrote:
[smiley to indicate validity -- frowny to indicate browser has best-guessed]
> Users are psychologically affected by smiles and frowns, and would be made
> unhappy if their computer mostly frowned at them. Making users unhappy is
> not considered a good thing in usability studies.
I'd call that an indirect effect on usability at best, but OK. Still, it
seems to me the negative feeling stems from the user not understanding the
meaning of the 'frowny', not from the frowny itself.
>> It would just indicate to the user that the current presentation of the
>> site is nothing more than the browser's best guess.
> This is wrong on two fronts. First, it wouldn't indicate that to the user,
> because the user wouldn't have a clue what the smile was for
That applies to every icon. It only gets meaning after the user has learned
FWIW, I have some experience teaching non-techies to use iCab and they in
fact like the frowny/smiley and find it useful -- once they've been informed
what it is.
> (Most users don't care about standards.)
They do care about the reliability of their sources, which is the same thing,
whether they know it or not. If due to some markup error some content doesn't
appear in some situations, or some content is moved/changed such that its
meaning changes, that can have a big impact on the user.
For Joe Average's blog this may not matter, but for a governmental
information site, pricing or specs of items in a shop, a timetable for flight
departures, it very likely will.
The browser indicating that it is sure of what it is rendering would be a
> Second, it isn't the browser's best guess. HTML5 defines error handling in
> detail, so it doesn't matter if the page is conformant or not, it's still
> going to be interoperably handled.
Surely you're not saying that HTML5 will define error handling for every
possible case a UA may run into? No doubt UAs will run into invalid HTML5
documents, and apply best guesses -- because the user won't accept a "this
browser refuses to render invalid documents" message.
That aside, HTML5 UAs will continue to have to best-guess all those billions
of existing invalid pre-HTML5 documents.
>> FWIW, iCab has had this feature for some 8 years, maybe longer. [...]
> You might want to consider what market share iCab has.
And IE's market share is due to its usability? :) You don't seriously think
that iCab's small market share is due to its frowny/smiley? More likely it is
due to many other reasons. (For one. It's targeted at a niche market, by
being Mac-only and extremely configurable. For another, up until recently its
CSS 2 support sucked (now it rocks). For another, it isn't pre-installed on
>> But then you simply implement it so that you get a happy smiley when the
>> page is valid, and nothing at all when it isn't.
> This would still fail usability testing, though for different reasons. Now
> the reason is that the user would think the browser was broken, because it
> randomly, on about 5% of pages, would show a smile.
How is that different from that key in the status bar that they see randomly
on some pages?
The Web Repair Initiative: <http://webrepair.org/>
More information about the whatwg