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

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

deprecated means "disapproved" and I don't think there is a good reason 
to disapprove of anyone using @style in XHTML  1.X (plain or basic).
I presented examples of legitimate uses of @style to which you responded 
with "hacks" (manipulate the dom,
repeat the code to create the CSS definition elsewhere, and so on).
Also, I don't understand why you don't apply the inverse reasoning: 
leave @style undeprecated and have a third-party validator/tool warn for 
uses of @style ("warning: use of inline styling may indicate lack of 
separation between content and presentation"). Believe it or not, there 
are people who know what they are doing out there, and making each and 
every error trappable as a DTD violation is a lost battle.

I can understand that XHTML 2.0 wants to start off with a clean slate 
and go for total separation of styling vs markup (for some definition of 
styling and markup).
I can understand that XHTML 2.0 has been called XHTML to ride the HTML 
wave and make the pill sweeter to whoever decides to go there at some 
point for some reason (or more likely, make the pill sweeter for their 
Yet using this to justify some reverse feature creep from XHTML 2.0 into 
the real XHTML is bad (unethical is the word that comes to my mind).

Having said this, I am happy that the proposal to undeprecate @style has 
made it to the WG table and, as far as I am concerned, I will stop here.


Benjamin Hawkes-Lewis wrote:
> 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 necessary.
> 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 Thursday, 26 June 2008 07:24:24 UTC