W3C home > Mailing lists > Public > www-html@w3.org > June 2008

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

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Mon, 30 Jun 2008 23:11:56 +0100
Message-ID: <48695A2C.9060108@googlemail.com>
To: Luca Passani <passani@eunet.no>
CC: Mark Birbeck <mark.birbeck@webbackplane.com>, Tina Holmboe <tina@greytower.net>, Shane McCarron <shane@aptest.com>, "Michael(tm) Smith" <mike@w3.org>, www-html@w3.org

Luca Passani wrote:
> Benjamin Hawkes-Lewis wrote:
>> 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.
> better ways in theory. Not in practice.

Again, I was addressing the general point, not "style" in particular. 
The fact that there are use-cases for a feature does not mean there 
aren't better ways to address those use-cases. Deprecation is a 
mechanism for gradually moving from worse to better ways of addressing 
use-cases by warning people about what's planned. Therefore the fact 
that there are use-cases for a feature /cannot/ be an argument against 
deprecation, or nothing would ever be deprecated.

So the mere existence of use-cases for the "style" attribute is not by 
itself a sufficient argument against deprecation.

Now, in the case of the "style" attribute, there may well be other 
arguments against deprecation, but I think they all turn out to be 
arguments against its removal in disguise. For example, you might argue 
that "style" is the /best/ way to address a particular use-case. This 
is, I guess, the position you're gravitating towards with your "theory" 
and "practice" rhetoric.

>>> 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.
> it is, if presented as an alternative to <div style="color:red">Red 
> Text</div>
>> * Adding a style attribute /is/ manipulating the DOM.
> sure, for some definitions of manipulating the DOM

Since you agree that adding a style attribute is a change to the DOM 
(for "some definitions"), I think we've clarified that changing the DOM 
is not an issue for you. As far as I can tell from what you're saying, 
anything that is not your choice of markup is a "hack".

> What is a hack to me, isn't a hack to you and the other way around, 
> probably. 

Maybe it would help if you picked a phrase that you don't think is so 

>> * 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.
> well, yeah, I imagined implementation.

It's not poetry, but anyways:

header( 'content-type: application/xhtml+xml; charset=utf-8' );

// For demonstration purposes, we'll define the images, but the
// imagined case is that these are dynamic not static.
$pairs = array(
             'url'             => 'http://example.com/images/1.jpg',
             'width'           => 40,
             'height'          => 100,
             'text_equivalent' => 'hello',
             'url'             => 'http://example.com/images/2.jpg',
             'width'           => 30,
             'height'          => 200,
             'text_equivalent' => ' world',
             'url'             => 'http://example.com/images/1.jpg',
             'width'           => 20,
             'height'          => 500,
             'text_equivalent' => 'goodbye',
             'url'             => 'http://example.com/images/2.jpg',
             'width'           => 10,
             'height'          => 400,
             'text_equivalent' => ' world',

$i           = 0;
$pairs_css   = '';
$pairs_xhtml = '';

foreach( $pairs as $pair ) {
     $id           = 'image-pair-'.$i;
     $pair_width   = $pair[0]['width'] + $pair[1]['width'];
     $pairs_css   .= '#'.$id.'{width:'.$pair_width.'px;}';
     $pairs_xhtml .= '<div id="'.$id.'">';

     foreach ( $pair as $image ) {
         $pairs_xhtml .= '<img src="'
                         .htmlentities( $image['url'] )
                         .'" width="'
                         .'" height="'
                         .'" alt="'
                         .'" />';

     $pairs_xhtml .= '</div>';

/* One loop has produced two blocks: one suggested styling, one
"semantic" markup, that can be output wherever we like. You could
output the CSS to a file and cache it, but in this case we'll assume the 
styles are throwaway and just use the (undeprecated) "style" element. */

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<meta http-equiv="Content-Type" content="application/xhtml+xml; 
charset=utf-8" />
<title>Image pairs</title>
<style type="text/css"><![CDATA[<?php echo $pairs_css; ?>]]></style>
<h1>Image pairs</h1>
<?php echo $pairs_xhtml; ?>

>> * 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.
> I think we are in a loop here. IMO it should be up to the coder to 
> understand when the time to 'refactor' their markup has come, and 
> multiple @style uses would be better turned into a reusable class. 

I suppose you can consistently assert both that "style" should be 
allowed in order to avoid code repetition in final delivery /and/ that 
it should be allowed in order to allow repetition in prototyping.

Coders can produce markup however they like; it doesn't mean that every 
coding preference needs expression at a markup language level (many 
coding preferences can actually be met by decent programmers' tools) and 
naturally XHTML 1.1 Basic doesn't even try. There's no special catering 
for people who struggle to read lowercase markup, for example.

If a coding practice tends to produce worse code, I think it becomes 
harder to argue for features to support it. I've never found "style" 
terribly helpful myself, and from watching others work with it, my 
impression is that prototyping using the "style" attribute does tend to 
produce worse markup. That's not so much an argument for removing the 
"style" attribute as a reason why I don't (personally) find the 
prototyping use-case terribly persuasive as a reason for keeping it. Not 
that I'm a decision-maker in all this.

> Enforcing this with the grammar (even though just deprecating) is IMO 
> wrong!

As avoiding the "style" attribute is /not/ being enforced in the 
proposed standard, this opinion appears to have only indirect bearing on 
the deprecation that is the subject of this thread.

Deprecation is a warning mechanism to ease migration. So long as the 
Working Group views XHTML2 as a natural migration target from XHTML 1.1 
Basic, and so long as "style" is likely to be absent from XHTML2, I'd 
guess it's incumbent on the Working Group to warn publishers of that by 
deprecating it.

So it seems to me you either need to:

1. Make the case that XHTML2 is not a natural migration target, or at 
least that there are other natural migration targets which are likely to 
include the "style" attribute or something very similar.


2. Make the case against removing the "style" attribute from any (X)HTML 
standard. None of your arguments seem specific to XHTML 1.1 Basic anyway.

Benjamin Hawkes-Lewis
Received on Monday, 30 June 2008 22:12:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:38:52 UTC