W3C home > Mailing lists > Public > www-html@w3.org > June 2008

Re: XHTML Basic 1.1 and setting input field to numeric mode

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Tue, 24 Jun 2008 07:43:20 +0100
Message-ID: <48609788.7020004@googlemail.com>
To: Luca Passani <passani@eunet.no>
CC: "Michael(tm) Smith" <mike@w3.org>, www-html@w3.org

Luca Passani wrote:
> sure, but this is the kind of things that makes one wonder whether those 
> who create the W3C recommendations have ever been involved in a real 
> project and have faced the challenges developers find in real life (such 
> as not being able to separate  style and content as neatly as the W3C 
> heads assume to be possible). In fact, I would argue that it's not even 
> possible to define what is style and what is content on a general basis.

Luca, Basic XHTML and XHTML 2 don't appear to be under the same pressure 
to be backwards compatible with current working practices that HTML5 is; 
although at an earlier stage of development, you might look to see if 
HTML5 is a better fit for your use-cases.

Language and definitions are always a tricky thing but I disagree that 
"style" and "content" are especially difficult to distinguish in the 
case of documents or applications, although they can be in the arts. In 
most cases, the conflation of the two represents a failure to perceive 
the abstract concept (e.g. heading) or abstract mode (e.g. emphasis) in 
the particular (e.g. bold).

But let's say, for the sake of argument, that there are cases where a 
stylistic effect is inextricably also a piece of content. White space 
used in poetry like that of E. E. Cummings or precise transcription of 
manuscript sources where authorial intent in choosing a presentational 
effect is highly uncertain may be examples of this.

In no way is CSS intended to used for style-that-is-content, since users 
are intended to be able to safely discard publisher CSS and still access 
all the content and functionality of documents and applications.

Therefore style-that-is-content should never go inside the CSS of a 
"style" attribute, so the argument that it is /intellectually/ hard to 
separate content from style is not (in my view) a valid argument for 
retaining the attribute. If anything, it is an argument for the 
retention of appropriate presentational markup or a use-case for a 
completely different encoding of information (such as TEI, SVG, PDF, or 
Adobe Flash).

Other than the misuse of CSS for style-that-is-content, I can think of 
two other use-cases in the wild for the "style" attribute:

1. "style" attribute used as syntactic sugar for styles that are applied 
to only one element in a document. For example, when an element in a 
timeline list is sized in proportion to its duration. In such cases, it 
would be /possible/ to apply the same styles by selecting the elements 
in a stylesheet rather than using a "style" attribute, although it will 
consume a little more bandwidth (bytes for the selector in the CSS).

2. "style" attributes used to add third-party imported CSS without 
affecting the rest of the page. This use-case would, I think, be more 
cleanly met by preprocessing third-party CSS or by some sort of module 
markup that scopes attached stylesheets than by a "style" attribute on 
each element. Changing how third parties deliver styles is not 
necessarily easy to do, however.

--
Benjamin Hawkes-Lewis
Received on Tuesday, 24 June 2008 06:43:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:14 GMT