- From: Rene Saarsoo <nene@triin.net>
- Date: Sat, 30 Jun 2007 18:39:08 +0300
- To: public-html@w3.org
First, sorry for some of the flamy arguments in my previous letter, it was late at night and I couldn't insist. Trying to be more constructive this time. I wrote: >> Note, that removing @style would mean inconsistencies >> with current CSS spec. Lachlan Hunt wrote: > Please explain what that means? I meant, that existing CSS specification teaches us how the style attribute is part of the cascade, and when we drop style from HTML, we also have to drop it from CSS. But I was wrong, because we still have style attribute in HTML5, just only the <font> element can have it. Which brings me to this use-case: > Computer-generated HTML. > > The best example is Google giving you the HTML > version of .doc or .pdf document. This can actually be covered by the <font> element, only that <font> requires you to have WYSIWYG signature and you can't really say that HTML preview of PDF file was generated by WYSIWYG editor. Maybe we should have a COMPUTER-GENERATED signature instead? That would cover a wider range of applications that produce purely presentational HTML, including WYSIWYG editors. (Computer-generated is probably bad term, because you could also say, that any dynamic website is computer-generated.) Thinking out loud... The knowledge about the style attribute is ceartanly widespread. I guess that every single CSS-introductory-book tells you, that there are three ways to specify apply CSS rules: inline styles, embedded stylesheets and external CSS files. Even the best books with best intentions tell you this. And every developer knows this attribute. Of course, the better books tell you, that it's better not to use it. But what I have noticed is, that the community usually tolerates a little use of it. But clearly the community doesn't tolerate the <font> element any more. I think there has been enough talk about the evilness of <font>. It has been deprecated in current HTML spec and so on. What signal are we giving, when we bring back the <font> element in HTML 5 (although only allowed to WYSIWYG tools)? And what are we going to do with the pile of CSS books, all teaching the use of style attribute? Wouldn't it be better to just get rid of the <font>, like the deprecated status in HTML4 promised, and allow style attribute for every element (maybe only in WYSIWYG context). Additionally "font" is not really a good name choice, because you can use it to set any style, not just typography-related styles. Lachlan Hunt wrote: > So, in summary, you're argument is that it is sometimes more > convenient to use style="" than it is to assign an ID or class > and place styles in a <style> element. Precisely. What I mean is, that having content and style separated is not a goal in itself. The goal is to make our code more easily manageble. And to achieve that, we have to reduce complexity. Just like in any other software development. Similarly like using functions in program source code is not the goal in itself. The goal is to make code more manageble by reducing complexity. Usually defining functions helps to reduce complexity, but you should be aware of over-engineering. If you just want to say "Hello", then it's usually better to write: print "Hello"; than: function hello() { print "Hello"; } /* a lot of code between */ hello(); It's quite the same with CSS. If you just want to write a single line of text in red, it's most readable to use inline CSS: My favorite color is <em style="color:red">red</em>. It's much harder to understand code like this: <style type="text/css"> .fav-color { color: red; } </style> <!-- a lot of HTML in between --> My favorite color is <em class="fav-color">red</em>. What was the gain of defining a new CSS class? Nothing. It just increased the complexity of the page. Sure, it's a good habit to not use inline styles, but if you just use it for rare styles in rare documents, then I don't see anything fundamentally wrong with it. -- Rene Saarsoo
Received on Saturday, 30 June 2007 15:39:59 UTC