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

Benjamin Hawkes-Lewis wrote:
> 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.
innerHTML() has been around since MSIE 4. The reason why W3C hasn't 
standardised it yet is because they would like people to manipulate the 
DOM. Well, this is not the way it works. If W3C won't standardise it, 
the world will move ahead without W3C. Same will apply to @style. It's a 
question of whether you want to be part of the group of people who 
helped further disconnect W3C from the de-facto standards adopted in the 

> I'd typically stick a class on the sentence and provide a second 
> include for the CSS.
disgusting, if you ask me.
>> 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.
If not impossible, this is certainly not practical: you would need to 
repeat the same code in the page (PHP. JSP, whatever), which would be 
against best practices in other domains.
In addition, your approach will have implications on performance (which 
may be unbearable in some contexts)....
>>>> - 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.
manipulating the DOM on the server is not what happens in 99% of 
web/mobile-web applications. 99% of applications spit out strings which 
happen to be markup (most often tag soup, to be totally honest, but 
please allow those who want to be compliant a way out)
>>>> - 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.
I disagree with everything you say. But what annoys me the most is the 
ideological attitude that you (and others) are taking. Since you think 
that in some ideal world content and presentation (for some 
not-better-specified definition of content and presentation) should be 
totally separated, you are taking this to the extreme consequences of 
enforcing separation in the markup itself. Well, this is fascism.
I am OK with the markup "incentivizing" separation, but enforcing it 
this way is a major design flaw.

>> 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.
No. I am saying. The style attribute may be necessary in some cases, so 
it should not be marked as deprecated.
It is as simple as that.

> 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:
> NB: Of direct relevance to this whole discussion is this wikipage 
> about the inclusion of the "style" attribute in HTML5:
...which mentions scenarios where @style makes sense.


Received on Wednesday, 25 June 2008 21:24:44 UTC