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

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

From: Luca Passani <passani@eunet.no>
Date: Wed, 25 Jun 2008 21:10:49 +0200
Message-ID: <48629839.3000709@eunet.no>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
CC: Mark Birbeck <mark.birbeck@webbackplane.com>, Tina Holmboe <tina@greytower.net>, Shane McCarron <shane@aptest.com>, "Michael(tm) Smith" <mike@w3.org>, www-html@w3.org

Benjamin Hawkes-Lewis wrote:
> Luca Passani wrote:
>> Deprecating the style attributed makes a few assumptions that are not 
>> always true:
>> - authors/developers have control over the whole page they are 
>> generating
> This could be used as an argument for any feature whatsoever. 
> Developers do not control whether third-party markup uses the 
> "marquee" element either. Surely the key point is whether or not it is 
> reasonable to expect the third-party markup to continue to use the 
> "style" attribute rather than gradually shift to something else.
Italian wisdom goes "nobody is as deaf as the guy who has no intention 
to hear". I think this applies very clearly to you.

So, you are requested to inject a red sentence into a page you know 
nothing about in advance. Injection may happen through innerHTML(), 
server-side include or similar. How do you do it without style@ ?

(if you answer "font tag", I'll pay you a beer :)

>> - authors/developers do not need to generate CSS properties 
>> dynamically just like any other bit of markup
> The "style" attribute is not necessary for this:
> http://dorward.me.uk/www/css/inheritance/
> http://www.hunlock.com/blogs/Totally_Pwn_CSS_with_Javascript

Hahaha. very funny. So, here is what I needed to do in a project once:

<div style="width:240px"><img src="pic.gif" width="140" 
height="20"/><img src="pic.gif" width="100" height="20"/></div>

the page was generated server side and the 240px value was generated by 
the server which happened to know that those two particular pictures had 
140 and 100 pixels respectively.

How would you do that?

(Also, you are forgetting that on mobile devices, DOM manipulation and 
Javascript cannot be taken for granted.)

>> - authors/developers can always use an existing style sheet 
>> class/property for their needs
> I doubt this is an assumption at play here. If you can add a "style" 
> attribute, then you will normally have element-level control of the 
> DOM, and so could also add a "class" or "id" attribute. (There may be 
> badly built template/content management systems which are exceptional 
> in this regard, but, again, there may be such systems that generate 
> "marquee" elements.)
DOM manipulation is not available in most mobile devices.
>> - authors/developers do not need to test/prototype/experiment with  
>> the look and feel of a page
> I don't need the "style" attribute to do that.
well, they do. Others here have said that. Not too mention that it can 
be an extremely useful shorthand. There is a large space between what is 
excellent and what is bad. I can go as far as admitting that @style is 
not excellent, but I wouldn't agree with anything that says that @style 
is bad (as the term deprecated does).
 Java programmers know that they should use getters and setters to 
manipulate the values in a given class, but this doesn't mean that a 
program that sets a public variable in another class will make the 
compiler crash and burn (in fact, it won't even warn)

Received on Wednesday, 25 June 2008 19:11:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:20 UTC