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

Luca Passani wrote:
> 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 
> field.

innerHTML() has been around for text/html a long time, but I believe its 
extension to XML is a recent innovation:

Personally, I recognize the value of the WHATWG-driven project of 
standardizing how user agents should treat widely implemented, but 
previously unstandardized features; I don't recognize the intrinsic 
value of /recommending/ such features to publishers regardless of their 
merits, purely because many publishers currently use them. In the 
proposed standard, how to treat "style" /is/ defined, so this is not a 
case of W3C not standardizing something.

>> I'd typically stick a class on the sentence and provide a second 
>> include for the CSS.
> disgusting, if you ask me.

It's not a matter of aesthetics.

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

I'm sure you /could/ implement this in such a way as to repeat code; I 
see no reason why you'd /need/ to however. Simply store the relevant 
"class" or "id" in association with the images, or generate the full 
HTML fragment/element at the same time and store that. Discard once used.

> In addition, your approach will have implications on performance (which 
> may be unbearable in some contexts)....

Assuming you don't repeat code, I doubt the performance implications 
would be significant, but perhaps you could share reproducible 
benchmarks for a real-world-like scenario that show otherwise?

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

I count "spitting out strings" as "changing the markup sent by the 
server". I'm not necessarily talking about using an implementation of 
the W3C DOM API on the server to generate a serialization; sorry if my 
language was too confusing on that point.

> I disagree with everything you say. 

Feel free to give reasons why you disagree.

> But what annoys me the most is the 
> ideological attitude that you (and others) are taking. 

Interesting choice of words. I take it you have "ideas", but I have 
"ideologies"? ;)

> 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 think calling conformance requirements of a technical specification 
"fascism" is either empty rhetoric or a category error:

> I am OK with the markup "incentivizing" separation, but enforcing it 
> this way is a major design flaw.

Deprecation does not enforce anything.

> No. I am saying. The style attribute may be necessary in some cases, so 
> it should not be marked as deprecated.

Ah okay. That's an erroneous conclusion, since (as has been repeatedly 
stated in this thread) deprecated attributes can be used where they are 

Deprecation should depend on whether the situation that necessitate its 
use can be improved on so that the preconditions will eventually no 
longer exist. For example, back in 1997 HTML 4.0 deprecated the "font" 
element because (it was thought) CSS provided a better way to suggest fonts.

As I suggested in my original contribution to the thread, it may be that 
other features to improve on the "style" attribute are required.
The HTML5 wikipage I linked discusses some possibilities.

Benjamin Hawkes-Lewis

Received on Wednesday, 25 June 2008 22:36:26 UTC