RE: Extensibility and Uniformity; defining "error" behavior

On Tue, 30 Dec 2008, Larry Masinter wrote:
> 
> There is no reason to bake into webapps all of the funny processing 
> rules necessary to deal with current broken HTML on the Internet, and 
> many reasons not to.

On the contrary, uniformity across applications is needed.

Uniformity is _not_ needed across two applications when those applications 
exist in two completely separate markets that will never ever collide.

So for example, one could imagine that the rendering processor for a 
mobile device intended purely to access walled-garden content would not 
need to ever enjoy unifomity with the rendering processor of a typical Web 
browser, even if both used HTML. But this would be short-sighted, because 
if a user wanted to print the walled-garden content by sending it to an 
HTML enabled printer, and if the printer was also to be used by people 
using Web rendering processors, suddenly the two worlds collide: if the 
thre devices aren't enjoying uniformity, then now the user will find that 
the pages as viewed on the mobile device are not handled the same way on 
the printer.

Same with HTML-based e-mail clients: if the e-mail world and the Web world 
didn't share uniformity, then Web-based mail clients that support HTML 
would need to somehow convert HTML content intended for mail clients into 
the HTML that Web browsers speak just so i could render e-mail. Lack of 
uniformity between those two worlds would also mean that a user couldn't 
use the same authoring software.

Same with data mining applications. If data mining applications used HTML 
to store data, completely independent of the Web, and didn't enjoy 
uniformity with the processors of e-mail clients, then one day, when the 
data mining team decides to also mine data out of HTML e-mail, they will 
find they are unable to do so trivially because their interpretations of 
the content will have been different.

Another way that these worlds collide is that libraries are often reused 
between unrelated applications. If there exist two HTML parsers, for 
instance, and one is used by an e-mail client and a Web browser, and 
another is used by an e-mail client and a data mining tool, then now any 
lack of uniformity between Web browsers and data mining tools will be 
exposed as lack of uniformity between two mail clients.


It is in fact precisely _because_ we never know how applications will be 
extended, how our specifications will be reused, that we _must_ ensure 
that all applications have uniformity. We never know when two applications 
that we had thought were completely independent might need to work 
together, and when they do, any lack of uniformity will result in a poorer 
user experience.


> So the error handling rules for HTML browsers *should* be allowed to be 
> different from the error handling rules for HTML in webapps, and making 
> them the same does a disservice to both communities.

The processing rules -- error handling or otherwise -- for all 
applications *must* be the same, because any difference becomes a 
disservice to both communities when they eventually have to interact.


> Further, it seems like the "without having to reverse engineer" goal is 
> taken from the narrow perspective of "implementer of next generation 
> browser."

This has nothing to do with browsers. If there are no detailed specs, then 
the authors of HTML processors for e-mail clients need to reverse engineer 
the authors of HTML processors for other e-mail clients if they are to 
enjoy any kind of uniformity amongst mail clients, for instance.


> A well, written technical specification which is commonly observed is 
> quite useful -- even if it doesn't specify error behavior -- to provide 
> for interoperability between two agents which implement the technical 
> specification.
> 
> In most situations, this has been sufficient to provide for 
> interoperability.

I think if we are satisfied with the level of interoperability that we 
have on the Web today between the various applications -- whether command 
line HTTP clients, e-mail clients, data mining applications, search 
engines, browsers, or whatever else -- that we are most definitely not 
aiming high enough.

It is time that we stopped considering it acceptable that users have to 
deal with quirks and differences between processors, and time that we 
instead wrote serious specifications that are detailed enough that we 
never end up with ambiguities and differences of that nature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 31 December 2008 00:58:59 UTC