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

Luca Passani wrote:

> 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@ ?

I'm not sure of the applicability of innerHTML to this particular 
discussion (a proposed XML-based markup standard), given that:

a) innerHTML is not yet standardized, though there is a proposal to 
standardize it.
b) innerHTML is not widely implemented for XML, though there are some 
implementations.
c) innerHTML is best avoided if you don't control the markup you're 
injecting, in order to ensure you end up with a working DOM.

I'd typically stick a class on the sentence and provide a second include 
for the CSS.

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

You could use "class" or "id" for that. You just need to insert the 
result of the calculation earlier in the output.

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

No, I am not. The first example I gave is of /server-side/ dynamic 
generation of CSS.

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

What makes you think I'm only talking about client-side DOM 
manipulation? When you change the markup sent by the server you also 
change the resulting DOM reconstructed on the client by parsing that markup.

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

Why do they /need/ it?

I'm well aware that some developers currently use the style attribute 
when prototyping, though this has always seemed a counter-productive 
approach to me because:

1. It encourages people to think about presentation while they are 
marking up.
2. Extra development time is spent converting "style" attributes into 
efficient selectors.
3. It makes the markup harder to see amongst all the CSS.

But different folks have different preferences and this use-case could 
be met by development tools such as Tidy that translate "style" 
attributes into selectors inside a "style" element before delivery to a 
client; it doesn't actually necessitate extra features in the language.

> Not too mention that it can be an extremely useful shorthand. 

Is this a weaker version of the original claim that it is necessary for 
prototyping, or something else entirely?

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

Are you basically saying the following?

* A "bad" feature is one that causes harm.
* Using the "style" attribute does not cause harm.
* Therefore the "style" attribute is not bad.

If so, it's arguable that the "style" attribute has a /tendency/ to 
cause harm:

1. Conflation of concerns makes it harder to maintain code.

2. It's often desirable to restyle included content from CSS for the 
host page even when this was not particularly envisaged by the original 
authors of the inclusion, but the specificity of CSS in the "style" 
attribute makes this impossible using CSS alone:

http://www.w3.org/TR/CSS21/cascade.html#specificity

NB: Of direct relevance to this whole discussion is this wikipage about 
the inclusion of the "style" attribute in HTML5:

http://esw.w3.org/topic/HTML/StyleAttribute

--
Benjamin Hawkes-Lewis

Received on Wednesday, 25 June 2008 20:41:53 UTC