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

This is absolutely fantastic. Your code makes my point exactly.

 > It's not poetry, but anyways:

it's not poetry and the fact that you cannot use @style *is* the culprit.
What about this (to be fair to you, I will also start with your arrays 
that simulate interaction with the backend):

<?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',
        ),
    ),
);

}
?>
<!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>
</head>
<body>
<h1>Image pairs</h1>
<?php
foreach( $pairs as $pair ) {
    $pair_width   = $pair[0]['width'] + $pair[1]['width'];
?>
 <div style="width:'*<?= $pair_width ?>* .'px;">
   <?foreach ( $pair as $image ) { ?>
   <img src="<?= htmlentities( $image['url'] )?>" width="<?= 
$image['width']?>"
           height="<?= $image['height']?>"  alt="<?= 
htmlentities($image['text_equivalent'],ENT_QUOTES)" />
    <?php  } ?>
</div>
<?php } ?>
</body>
</html>

look! Miracle! it's still almost XHTML!!!!

and, let me tell you, I am not the greatest PHP programmer. If I had to 
do this in Java, assuming I can use JSTL and a common MVC framework such 
as Struts, Spring MVC or similar (i.e. I typically already find all the 
variables in the context of the page, since the controller has placed 
them there for me), this would be as simple as:

<!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>
</head>
<body>
<h1>Image pairs</h1>
<c:forEach var="pair" items="${pairs}">
<div style="width:${pair[0].width+pair[1].width}">
  <c:forEach var="image" items="${pair}">
     <img src="${image.url}" width="${image.width}" 
height="${image.height}" alt="${image.textEquivalent}">
  </c:forEach>
</div>
</c:forEach>
</body>
</html>

(if you had to create a style tag, as you would be forced to do, if you 
want to avoid using a deprecated attribute, you would get my original 
point about repeating the code)

you see? another miracle....are you guys still going to tell me that 
@style should be deprecated in the name of purity of separation? what 
about the real world?

Luca

Benjamin Hawkes-Lewis wrote:
> 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
>

Received on Tuesday, 1 July 2008 07:51:20 UTC