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
subjective?
>> * 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:
<?php
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(
array(
array(
'url' => 'http://example.com/images/1.jpg',
'width' => 40,
'height' => 100,
'text_equivalent' => 'hello',
),
array(
'url' => 'http://example.com/images/2.jpg',
'width' => 30,
'height' => 200,
'text_equivalent' => ' world',
),
),
array(
array(
'url' => 'http://example.com/images/1.jpg',
'width' => 20,
'height' => 500,
'text_equivalent' => 'goodbye',
),
array(
'url' => 'http://example.com/images/2.jpg',
'width' => 10,
'height' => 400,
'text_equivalent' => ' world',
),
),
);
$i = 0;
$pairs_css = '';
$pairs_xhtml = '';
foreach( $pairs as $pair ) {
$i++;
$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="'
.$image['width']
.'" height="'
.$image['height']
.'" alt="'
.htmlentities(
$image['text_equivalent'],
ENT_QUOTES
)
.'" />';
}
$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"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<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>
</head>
<body>
<h1>Image pairs</h1>
<?php echo $pairs_xhtml; ?>
</body>
</html>
>> * 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.
/or/
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