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

Thank you for the long and instructive answer Benjamin. I understand 
that I am coming in into a discussion that has obviously been going on 
for years and changing anything is not simple. So I will focus on the 
important points which, I think, need correction. About the style 
attribute, you write, among other things:

 > "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.

exactly. Even without going into discussion about how wrong it is to
design markups assuming that something else server-side will need to 
happen first,
you provided the reason why deprecating the style attribute is a big 
mistake.
It interferes with the way people builds web and mobile applications alike.

 > 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.

Little aside: my personal motivation is to build mobile applications 
that work on today's devices.
I would like to be able to do that without having to deliver the 
following messages to my customers:
"I deliberately ignore W3C recommendations because they are wrong and 
incompatible with the state
of the industry. Look they even deprecated the style attribute". End of 
the aside.
So, HTML5 has nothing to do with my use case. XHTML Basic 1.1 does, 
because it will
be converging with XHTML Mobile Profile. And I would like to do my job 
without
having to explicitly shoot down W3C first.
As you may know, W3C's BP (which are, IMO, not very good, but I digress) 
depend on XHTML Basic 1.1:

http://www.w3.org/TR/mobile-bp/

unfortunately, the best practices are being marketed by W3C and dotMobiu 
as a guidelines for developing web apps today.
So, here is the disconnect. Something that, according to W3C, should be 
adopted today, relies on
a spec built to break with the past and (more or less explicitly) 
disregarding backward compatibility.

Luca

Benjamin Hawkes-Lewis wrote:
> 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 08:26:24 UTC