- From: Leif Halvard Silli <lhs@malform.no>
- Date: Tue, 21 Aug 2007 18:23:07 +0200
- To: Sander Tekelenburg <st@isoc.nl>
- Cc: public-html@w3.org
2007-08-21 17:09:58 +0200 Sander Tekelenburg: > At 15:56 +0200 UTC, on 2007-08-21, Leif Halvard Silli wrote: > > [...] > >> The main thing that I agree very strongly with Karl in is that the >> offline and online "gap" should be bridged, and that this can happen >> through setting up clear/strict recommendations for which extensions >> to use - which all sides (authors, authoring software, browsers, >> servers) should pay attention to. This bridging should include >> official language and charset extensions, taking example from Apache, >> which also allready offer its own such extensions, and have done so >> for a very long time allready. > > While I agree with the gap needing a better bridge, I disagree that file name > extensions are a solution. They are just one possible implementation for > marking a file's type, charset, etc. I took care to say that it «can happen [this way]». Should it be supported or not? Should we think about other methods instead? Which are they? Can both be supported? Currently the extension method doesn't work out of the box. But it should be relatively easy for browsers to start reading charset suffixes. We basically have everyting. We only need to start using it. > Not every environment works with file > name extensions at all (for instance, they were allowed, but basically > meaningless on Mac OS pre-X). I had a Mac in those days as well - I cannot quite subscribe to this. > And although I do not know, I wonder how useful > they would be for users of non-western scripts -- many users don't understand > the meaning of file name extensions, but if you don't even know the script > they are presented in... First, I will object the wording «non-western». I am borded in general by «the west». Second, this just a help. If the charset is specified inside the file but not in the filename, then the browsers will use that charset instead - as they allready do. Third: writing file extensions is simpler than writing META tags. Even for «not-none-westerners». Fourth: Both META and extensions need not be written by the users themselves - it can be handled by their applications. The purpose is to bridge the gap between online and offline. My take on that, is that we must do like the Mac users did: we must adapt. To the servers. > The entire point of the Content-Type header is to allow the conventions of > one environment to be bridged to those of another one. (MIME types are rather > limiting though. Something like the UTIs Apple recently introduced in Mac OS > X would be nicer: <http://arstechnica.com/reviews/os/macosx-10-4.ars/11>) Do you think that we will see that Mac OS X 10.5 will replace Apache with some UTI web server? And when will it happen with all the Apache on Linux servers that basically serves the world? Most of them haven't even upgraded to Apache 2. -- leif halvard silli
Received on Tuesday, 21 August 2007 16:23:19 UTC