- From: Scott Luebking <phoenixl@sonic.net>
- Date: Sun, 23 Dec 2001 07:24:50 -0800
- To: w3c-wai-ig@w3.org
Hi, One of the reasons why I was suggesting different approaches was to let sites choose an approach that fits their style. For some sites who are commited to the elegance of markup languages, they can use one approach. For other sites who just see HTML as that thing that gets the information on customers' screen, there is another approach. In a way it comes down to picking one's battles. Is accessibility more important or the elegance of a markup language? A slightly philosophical question comes into play. Does technology serve people or do people serve technology? There are people whose applications will not benefit from putting the extra work supporting the elegance of markup languages. I'm a little unclear about this following approach? "...I would suggest that a reasonable approach would be to write the page as structural HTML, with classes, and divisions, to impose the higher level structure, then transform it into the table based page description HTML for the GUI browsers." What is a table based page description? What server/preprocessor technology is needed? How long does it take for web designers who only know HTML to learn how to use it? Scott > This approach is a travesty of the whole markup language concept, but, > as it is easiest, is the one that is most likely to get adopted. The > sites that don't need to save time will simply "save money" by going > this way, rather than doing it better. > > If the site has a consistent house style (and if they don't, I would > suggest that the designers are out of control++), and there is enough > understanding of structure for the content providers to actually be > able to indicate the structure, I would suggest that a reasonable > approach would be to write the page as structural HTML, with classes, > and divisions, to impose the higher level structure, then transform > it into the table based page description HTML for the GUI browsers. > This is essentially the server side XML approach, except that the > master version is the fallback version. One can use additional classes > and/or processing instructions, to hint at the presentational form, > beyond what is implied by obeying the house style. One could even use > private attributes (optionally stripped to allow validation) to carry > presentational information for the pre-processor. > > ++ To me, fonts specified all over the place and failing to indicate > headers indicates designers who have no clear view of the style they > want to achieve, but are simply throwing things at the screen. WYSIWYG > and house styles don't mix all that well.
Received on Sunday, 23 December 2001 10:24:54 UTC