Re: XHTML Basic 1.1 and setting input field to numeric mode
Luca Passani <[email protected]>
| Newsgroups | gmane.comp.web.html.general |
|---|---|
| Message-ID | <[email protected]> |
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
>