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

Luca Passani wrote:

>  > 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 was talking about your generic claim that because something has uses 
it must not be deprecated. bgcolor support was also useful when HTML 
4.01 was released, that doesn't mean they were wrong for /that/ reason 
to deprecate it in favour of stylesheets.

Features may have use-cases a specification is intended to meet, but 
still be deprecated because there are /or/ will be in the future better 
ways to fulfill those use-cases.

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

* Manipulating the DOM is not a hack.
* Adding a style attribute /is/ manipulating the DOM.
* Repeating code is to be avoided, but I'd hardly call it a "hack" 
* My suggestion did not involve any repetition of code. Your imagined 
implementation did, but I can't understand why. Insisting that I 
proposed this, in direct contradiction of the email you're replying to, 
is really not helpful.
* I've regularly seen the style attribute used to apply the same style 
in multiple places, either for rapid prototyping or to style included 
DOM. That's an example of code repetition that can be avoided by using 
"link" or "style" elements rather than "style" attribute.

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

The style attribute is not an indication of a possible lack of 
separation; it is an /instance/ of lack of separation.

> Believe it or not, there 
> are people who know what they are doing out there, 

Is this anything other than a repetition of the claim that @style has 

> and making each and every error trappable as a DTD violation is a lost battle.

Not sure what you mean.

Also, you appear to have confused deprecation with something that has an 
effect on DTD validation. It doesn't necessarily.

For example, the deprecated bgcolor attribute exists in HTML 4.01 
Transitional, it exists in the HTML 4.01 Transitional DTD, it validates 
when included in an HTML 4.01 Transitional. Likewise, the style 
attribute is deprecated in the proposed XHTML 1.1 Basic, but should 
validate if included because it is included in the DTD:

Perhaps you'd like to review what "deprecated" actually means in the 
context of a W3C specification:

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

As far as I can see, it's not an instance of feature creep from XHTML 
2.0. It's just a warning that it might not be included in subsequent 
XHTML specifications, so you might not want to use it if you want to 
ease future migration.

Separation of styling and markup was an explicit goal of HTML 4.0:

It's an ongoing process.

Benjamin Hawkes-Lewis

Received on Saturday, 28 June 2008 14:12:49 UTC