W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [CSS21] response to issue 115 (and 44)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 25 Feb 2004 18:53:27 +0200
Message-Id: <2242386B-67B3-11D8-9491-003065B8CF0E@iki.fi>
To: WWW Style <www-style@w3.org>

On Feb 24, 2004, at 07:34, Jukka K. Korpela wrote:

> On Mon, 23 Feb 2004, Henri Sivonen wrote:
>>> Either guess is bound to be wrong in some cases. And if the guess 
>>> turns
>>> out to result in something containing undefined octets, I think we 
>>> can
>>> relatively safely guess that the guess was wrong.
>> Yes, but restarting the parser at that point is expensive.
> So what?

People don't like anomalies such as flashes of unstyled content. Also, 
I'd expect the developers to be unwilling to break incremental 
processing of network streams that allows parsing to start before 
everything has arrived over the network. Working around these issues 
would require lot of work for something that is classified as error 

>> But, as Ian Hickson pointed out, then the spec would be less useful 
>> and
>> everyone would have to just reverse engineer the market leader.
> How would that reduce the usefulness of a specification?

You could not rely on the specification to tell you what to implement.

> A specification
> tells authors and browser programmers what to do, how to comply. If
> you tell authors how browsers are required to treat authors' errors
> you are more or less telling them they ain't no errors really.

Perhaps, but experience with HTML suggests that leaving the behavior in 
error situations undefined is a bad idea and leads to reverse 
engineering the implementation with the largest installed base.

> And if other browsers need to imitate the market leader, the need will 
> not
> be removed by making the market leader's behavior a standard, still 
> less
> by making some different error processing a standard.

The expectation is that if the the spec defines error recovery, the 
market leader doesn't have to invent its own error recovery behavior.

>>> b) should assume Ascii, if the style sheet
>>> contains only octets with most significant bit set to zero.
>> Why would assuming ASCII be more useful than assuming windows-1252?
> Because we can be practically 100% certain that if the data comes with 
> no
> encoding specified and it looks like Ascii, it is Ascii. Not so with
> windows-1252 or iso-8859-1. It could just as well be iso-8859-2, for
> example, and there you go.

Sure. Is it better to always guess wrong and know it or to guess 
sometimes right and sometimes wrong and not know when the guess is 
right and when it's wrong?

Henri Sivonen
Received on Wednesday, 25 February 2004 11:54:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:11 UTC