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

Rijk van Geijtenbeek wrote:
> Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> 
>>I see however no reason why CSS should have different rules than all
>>those other document formats and especially not insanely complicated
>>ever changing ones as the rules discussed above and proposals for CSS
>>Level 3 suggest. Maybe mainstream browser developers have the necessary
>>resources and expertise to understand and implement it, Tim Tool
>>Developer has not. He should not be required to. No one should.
> 
> Joe Web Designer just uses his local Windows copy to create a style sheet,  
> and adds some comments in his own language, adds his name, maybe adds a  
> copyright symbol, saves his file in the local windows charset and uploads  
> without thinking much. Most of the time he is lucky, and the server is  
> smart enough to send .css files as text/css. Chris Lilley mentioned that  
> those using text/* should know about encoding and otherwise it is just  
> their fault is something goes wrong, but that is not very realistic. It  
> works for HTML, after all. For HTML, if he does something wrong, a few  
> funny characters show up in the text. This happens all the time. With CSS,  
> you want to punish him by assuming UTF-8, which will garantee lots of  
> stylesheets will not be applied.

The only way to ever get global support for UTF-8 is to force it 
down to the throats of the users. Sooner or later everybody is going 
to hit character set issues and pretty much everybody will have some 
clue what a charset means. If the user's choice is between UTF-8 and 
ISO-8859-1 (for old documents) instead of all the currently used 
charsets, I think we're much closer to the solution.

However, it might make some sense to interpret invalid byte 
sequences in UTF-8 file as invalid characters and proceed instead of 
halting but I really think that user agent should NOT try to guess 
"correct" character set. If the author sees the style sheet isn't 
applied correctly, he then goes to figure it out. If the user agent 
magically fixes the problem in some situations, the author just 
thinks the browser has some weird bug when the automagic fixing of 
the problem fails later. Error revocery is good (as in, skipping the 
failed part and continuing at the next known good location), but 
automagic error fixing (*trying* to decode/reinterpret the broken 
part) is asking for trouble.

User agents are already expected to be able to parse CSS files 
written for future specifications of CSS. I don't see, how skipping 
the part that isn't understood is bad in case the file has some 
known-bad-characters. Obviosly, an user agent isn't required to work 
like this but I think it's much better choice than trying to make 
uneducated guesses.

> The @charset rule we are now encouraged to use is exotic looking for most  
> web designers, it doesn't appear in most of the how-to-use-CSS books or  
> web-tutorials they have read so far. And they might even be afraid that  

I REALLY think we shouldn't specify new stupid rules simply because 
there already exist some stupid tutorials. Fix the stupid tutorials 
and specify good rules.

-- 
Mikko

Received on Friday, 20 February 2004 14:30:18 UTC