<font> and style="" in HTML5

Summary: <font> is gone, style="" is made global.

On Sat, 30 Jun 2007, Rene Saarsoo wrote:
> 
>     There once was a master webdesigner who used the
>     style attribute. A novice designer, seeking to
>     imitate him, also began to use inline styles. When
>     the novice asked the master to evaluate his HTML,
>     the master criticized him for using inline styles,
>     saying, ``What is appropriate for the master is not
>     appropriate for the novice. You must understand the
>     Tao of Web Design before going inline.''
> 
>              -- Paraphrased from The Tao of Programming.
> 
> 
> Good evening you all,
> 
> created a list of reasons, why I think the @style should not be removed.

I've made it a global attribute.


> 1. Some use cases
> 
> First I think, no-one has really pointed out good
> use-cases for using inline styles.
> 
> 1.1. Tag clouds
>      <http://www.flickr.com/photos/tags/>
> 
> 1.2. Bar graphs
>      <http://concepts.waetech.com/bargraph/>
> 
> 1.2. Computer-generated HTML
>      The best example is Google giving you the HTML
>      version of .doc or .pdf document.

I'm not sure bar charts are a good argument, but the others make sense, I 
guess.


> 2. Everyone is using it.

That's not a good argument. :-)


> 3. It's really useful for debugging
> 
> It's clearly THE easiest ways to style a single element.
> Quick and dirty prototyping anyone?

Such documents wouldn't need to be conforming.


> 4. @style relates to <style> as <style> relates to <link>
> 
> Let's consider <style> and <link rel="stylesheet">.
> 
> When I have a lot of documents with same visual design,
> then having <style> element with same declarations in
> each of those documents is ceartanly evil. I should use
> <link> to point to the common styles in separate file.
> 
> So, is the <style> element evil and should be dropped?
> 
> No, because when I have styles, that are specific to
> just one document, then there is no big reason to create
> extra CSS file for those styles.
> 
> Similarly with @style and <style>. If you have just
> one element in one document, that you want to style in
> a specific and unique way, then there is no logical reason
> to make up new #id or .class.

Fair enough.


> 4.1. Note, that removing @style would mean inconsistencies
>      with current CSS spec.

That's not a great reason. Specs can change. :-)


> 5. What about JavaScript style property?
> 
> Even when we remove @style, the JavaScript style property
> will still have to remain. And it clearly should, because
> how else could you animate elements and do other dynamic
> stuff like that?

The CSS animation proposal from Apple is probably a good answer.


> 6. What about <script> and @onclick, @onmouseover, etc?
> 
> If we are going to drop @style, then we should be consistent and also 
> drop all the scripting related attributes too.

Why?


> But what about PROs of dropping @style?
> 
> The only reason seems to be, that using @style is mostly bad practice 
> and having it available, encourages all those bad practices.
> 
> But even if we remove the @style from the spec, it will still be 
> available for authors. Only those authors who read the spec or use 
> validator, will notice the change. But aren't those the authors who 
> would abandon those bad practices anyway?

Fair point.


On Mon, 10 Mar 2008, Leif Halvard Silli wrote:
> 
> Thus, Section 9, which permits <FONT> for WYSIWYG tools (via the WYSIWYG 
> signature), really only says that such authors are permitted to skip 
> preplanning and post-editing. As if only WYSIWYG users have problems 
> with those parts of the authoring process:
> 
> * <FONT>, in order: “to allow a way for WYSIWYG editors, which don't 
> have enough information to use the "real" "semantic" elements,” [1]
> 
> However, the draft in fact “knows” that even non-WYSIWYG authors have 
> similar problems, since it suggests that one should “strongly 
> discourage” and “not letting it be ok” for hand-coding authors to use 
> the @style attribute (which hand-coders will often use as an ad-hoc 
> solution). Despite this knowledge about the similarities, the draft ends 
> up expecting different things from each author group:
> 
> * “... got to find a solution to this [the <font> issue], while not 
> letting it be ok for hand-coding authors to abuse the style="" 
> attribute.” [2]
>
> * “ ... we really should find a way to strongly discourage its use [the 
> style attribute] [...] for non-WYSIWYG authors.” [3]
> 
> The current aproach
>
> 1) fails to set one standard for all documents
>
> 2) fails to identify the similarities between WYSIWYG non-WYSIWYG 
> authoring (even non-WYSIWYG authors have a need for a "forgiving" mode - 
> where they can "misuse" the style attribute, in order to see "fast 
> results")
>
> 3) creates problems in mixed mileu situations (as soon as the author 
> opens the WYSIWYG made document in a non-WYSIWYG tool, then other rules 
> suddenly apply).
> 
> Instead, I propose this approach:
> 
> 1) One goal for all documents, regardless of authoring tool.
>
> 2) An 'UNREADY signature' instead of a 'WYSIWYG signature'. When used, 
> one can expect to find certain features that are typical for a document 
> that is still being edited: misuse of style attributes,(perhaps) <font> 
> elements, lack of @ALT attributes etc. Both hand-coding authors and 
> WYSIWYG author can use it, if they need.
>
> 3) A spesification of the authoring process, which should be outlined as 
> a multistep process. The final touches - the 'semantification' of the 
> document, doesn't happen 'naturally' - it needs preplanning or 
> postprocessing. HTML authoring is never a one step thing. (Unless the 
> authoring tools offer lots of useful, premade - or interactive - 
> templates which gives the author the /impression/ that is only one 
> step.)
> 
> Post processing: Roughly something like this: When written, then 
> identify elements of the document/HTML fragment with identical styling, 
> classify them - and place them in style sheets. Etc. (Adding @alt texts 
> could belong here.)
> 
> Afterthought, WYSIWYG: We should realise how important the after process 
> often is, compared with preplanning. (At least until one has created 
> some templates that can be reused.) And thus, WYSIWYG tools have no 
> excuse: They too can be made to do postprocessing. I imagine that 
> WYSIWYG tools could have buttons that take care of the post processing. 
> And also it would be natural to have "generate class based upon the 
> styling of this element" buttons. (I think there are several word 
> processors that have similar features - I have at least tried one.) Such 
> buttons could be used for making the document ready for public 
> consumtion.
> 
> Aferthought, non-WYSIWYG: While separate style sheets is a brilliant 
> idea, it is always a tempation to fix things "right there" instead of 
> inside the separate style sheet. Therefore, hand-coding authors too need 
> tools that can extract classes and stylesheets from their code.
> 
> Validation: While @STYLE and <FONT> can be useful during authoring, in 
> demonstration pages and in test case pages etc, they should not be 
> permitted in "for consumtion" pages. And thus should _not_ be allowed to 
> be stamped with the W3 Validation stamp. Merely the use of the "UNREADY 
> signature" should prevent it from validation. Since such documents are 
> UNREADY, they need not validate.
> 
> The point of these proposals is to make us have more realistic approach 
> to the creation of authoring tools. Realising the multistep nature of 
> HTML authoring is crucial, I think. If we say that authoring is a 
> mulistep process, then we should try to identify the steps and spec 
> them.
> 
> [1], [2], [3]: see the section about the “the font element” in the 
> draft.

I've dropped <font>. This didn't really leave anything for the "unready" 
state, so (although I like the idea and proposed something similar myself) 
I haven't done anything with this idea.


On Fri, 28 Mar 2008, Daniel Glazman wrote:
> 
> The CSS WG has found today an incompatibility problem between the HTML4 
> and the HTML5 definitions of the style attribute.
> 
> Excerpt from HTML 4.01 spec [1]:
> 
>   For example, for CSS2 inline style, use the declaration block
>   syntax described in section 4.1.8 (without curly brace delimiters).
> 
> Excerpt from HTML 5 spec [2]:
> 
>   The style  attribute, if specified, must contain only a list of zero
>   or more semicolon-separated (;) CSS declarations.
> 
> This change has an implication on the error handling supposed to occur 
> during the parsing of the contents of the attibute. An example is the 
> following one :
> 
>   style="color:lime; (; color:red"
> 
> HTML 5 will make the element red, because HTML 5 explicitely splits the 
> contents of the attribute at semicolons.
>
> The error handler looking for the matching closing parenthesis does not 
> find it at all, the () pair on the stack is closed finding the semicolon 
> ending the declaration.
>
> In HTML 4, the style attribute holding the contents of a CSS block, the 
> error handler will look for the matching closing parenthesis as required 
> by CSS 2.1 until the end of the attribute's content. The element will 
> then be lime.
> 
> The CSS WG would like the definition of the style attribute in HTML 5 to 
> go back to the phrasing of HTML 4, entirely leaving the definition of 
> that attribute's value to the stylesheet's language and error handling. 
> We don't think HTML 5 should define the contents of the style attribute 
> in deeper details than what HTML 4 does, and in particular should not 
> specify how individual stylistic data are separated inside the value of 
> the style attribute.

Actually the HTML5 spec explicitly says that the attribute "must be parsed 
and treated as the body of a declaration block", which I believe means 
that the appropriate error handling rules do indeed take effect. The 
sentence you quote above is giving the authoring requirements, not the 
user agent requirements.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'