<HR> Style Bug in IE6

It looks like there's a pretty serious CSS bug in IE6
(v6.0.2800.1106). The HTML below is validated STRICT HTML 4.01 and
renders as I would expect in Opera, FrontPage, and Netscape.

For some reason, there's an annoying vertical gap between adjacent
rules that doesn't go away. This looks like IE6 is incorrectly
setting the margin to some arbitrary value.

Does anyone know if this is a known bug at MS? If you know of one,
post the related bug ID. (If there's a better place to track known
IE6 bugs, let me know.)

Better yet, if anyone knows about a work around (besides the infamous
1px GIF), please post! I'm not looking for something that supports
all browsers back to the beginning of time, simply all HTML 4.1
compliant browsers. I know there isn't any browser that fully
supports HTML 4.01 STRICT, but a hack that works with IE6, Opera7, and
Mozilla 1.x as reasonable.

Try this code:
---------<snip>----------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html>

<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<title><hr> Test</title>
<style type="text/css">

</style>
</head>

<body>
<p>
Here's a series of tightly packed <hr>'s:
</p>
<hr>
<hr class="redrule-1">
<hr>
<p>
Here's the same series of tightly packed <hr>'s inside a
table:
</p>
<table style="width: 100%;">
<tr>
<td>
<hr>
<hr class="redrule-1">
<hr>
</td>
</tr>
</table>
<p>
Here's a series of tightly packed <hr>'s:
</p>
<hr>
<hr class="redrule-2">
<hr>
<p>
Here's the same series of tightly packed <hr>'s inside a
table:
</p>
<table style="width: 100%;">
<tr>
<td>
<hr>
<hr class="redrule-2">
<hr>
</td>
</tr>
</table>
</body>

</html>

mark.moore@notlimited.com (Mark Moore) wrote:

Inappropriate crosspost removed.
[color=blue]
>It looks like there's a pretty serious CSS bug in IE6[/color]

What else is new.
[color=blue]
>For some reason, there's an annoying vertical gap between adjacent
>rules that doesn't go away. This looks like IE6 is incorrectly
>setting the margin to some arbitrary value.[/color]

Yawn, this is a really trivial issue and moldy old news.
[color=blue]
>Does anyone know if this is a known bug at MS? If you know of one,
>post the related bug ID. (If there's a better place to track known
>IE6 bugs, let me know.)[/color]

Are you honestly so naive as to think that MS gives a monkey about IE
CSS rendering issues?
[color=blue]
>Better yet, if anyone knows about a work around (besides the infamous
>1px GIF), please post![/color]

Search this group @ groups.google.com, it's been dealt with numerous
times.

[pointless code bloat deleted]

--
Spartanicus

Mark Moore wrote:
[color=blue]
> It looks like there's a pretty serious CSS bug in IE6[/color]

*A* bug? You think there's only one? How quaint.
[color=blue]
> there's an annoying vertical gap between adjacent rules that
> doesn't go away. This looks like IE6 is incorrectly setting the
> margin to some arbitrary value.[/color]

Could be. Did you Google for IE/Win css bugs? What did you come up with?
[color=blue]
> Does anyone know if this is a known bug at MS? If you know of one,
> post the related bug ID.[/color]

Huh? Since when does MS publicly track bugs?
[color=blue]
> Try this code:[/color]

No. Instead, post a url. And don't cross-post unless it's really
called for. In this case, ciwas is the right group, so leave ciwah out
of it. And when you cross-post, please set followups. (I've set them
to ciwas.)

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

*Spartanicus* wrote:[color=blue]
> Inappropriate crosspost removed.[/color]

If cross-posted groups aren't suitable then reply to all groups
initially and set a follow-up such that everyone following the thread is
informed where the conversation is being directed. Cutting crossposts
like this is just as bad as multi-posting.
--
Andrew Urquhart
- FAQ: www.css.nu/faq/ciwas-aFAQ.html
- Archive: www.tinyurl.com/ysjbm (Google Groups)
- My reply address is invalid, see www.andrewu.co.uk/contact/

Hi, Mark,

1. To be precise... what does it mean yours

hr { margin: auto; } exactly ?

As far as I know CSS 2.1 does not say anything
about what margin-top: auto should be.
(Probably a bug in the specification)

In such circumstances UA is free to choose any suitable value.

2. HRs, TABLEs and IMGs are special cases as their traditional shapes and
rendering behavior cannot be defined in pure CSS.

Regards,

Andrew Fedoniouk.
http://terrainformatica.com

"Mark Moore" <mark.moore@notlimited.com> wrote in message
news:13adb93b.0406291115.27b8d094@posting.google.c om...[color=blue]
> It looks like there's a pretty serious CSS bug in IE6
> (v6.0.2800.1106). The HTML below is validated STRICT HTML 4.01 and
> renders as I would expect in Opera, FrontPage, and Netscape.
>
> For some reason, there's an annoying vertical gap between adjacent
> rules that doesn't go away. This looks like IE6 is incorrectly
> setting the margin to some arbitrary value.
>
> Does anyone know if this is a known bug at MS? If you know of one,
> post the related bug ID. (If there's a better place to track known
> IE6 bugs, let me know.)
>
> Better yet, if anyone knows about a work around (besides the infamous
> 1px GIF), please post! I'm not looking for something that supports
> all browsers back to the beginning of time, simply all HTML 4.1
> compliant browsers. I know there isn't any browser that fully
> supports HTML 4.01 STRICT, but a hack that works with IE6, Opera7, and
> Mozilla 1.x as reasonable.
>
> Try this code:
> ---------<snip>----------
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
>
> <html>
>
> <head>
> <meta http-equiv="Content-Type" content="text/html;
> charset=windows-1252">
> <title><hr> Test</title>
> <style type="text/css">
> 
> </style>
> </head>
>
> <body>
> <p>
> Here's a series of tightly packed <hr>'s:
> </p>
> <hr>
> <hr class="redrule-1">
> <hr>
> <p>
> Here's the same series of tightly packed <hr>'s inside a
> table:
> </p>
> <table style="width: 100%;">
> <tr>
> <td>
> <hr>
> <hr class="redrule-1">
> <hr>
> </td>
> </tr>
> </table>
> <p>
> Here's a series of tightly packed <hr>'s:
> </p>
> <hr>
> <hr class="redrule-2">
> <hr>
> <p>
> Here's the same series of tightly packed <hr>'s inside a
> table:
> </p>
> <table style="width: 100%;">
> <tr>
> <td>
> <hr>
> <hr class="redrule-2">
> <hr>
> </td>
> </tr>
> </table>
> </body>
>
> </html>[/color]

Use this if you want one pixel horizontal line "a la" ruler

..hr {
margin: 0;
padding: 0;
border-top: 1px solid red;
width: 80%;
height: 0px;
overflow:hidden;
text-align:center;
}

<div class=hr></div>

Andrew Fedoniouk.
http://terrainformatica.com

Brian and Spartanicus, I can't believe how rude your reponses are. I'm
not wanting to spark anyone here, but I honestly can't find anything
in Spartanicus' post to respond to. Feel free to blast me, but please
don't dismiss me. I post in good faith, and I'd appreciate the same
in return.
[color=blue]
> Did you Google for IE/Win css bugs?[/color]

Yes, I did scrub the web. I found no useful hits on incorrect
rendering of margins for stylized <hr>. Here's a sample from this
very list: http://groups.google.com/groups?hl=e...com%26rnum%3D2
[color=blue]
> Since when does MS publicly track bugs?[/color]

MS publicly tracks bugs here:
http://support.microsoft.com/default...sd=GN&ln=EN-US
They call it their "Knowledge Base", and bugs are identified by their
Knowledge Base ID. An example of a table bug in IE5.5 can be found by
searching for KB299446. (And, to directly answer your question: since
at least the mid 90's.)
[color=blue][color=green]
>> Try this code:[/color]
>
> No. Instead, post a url.[/color]

No, thank you. I could post a URL for now, but unless I'm willing to
leave the snippet up indefinitely, it will be of no use to anyone
later. (If you *really* hate to cut and paste, write me. I'll send
you a link.)
[color=blue]
> And don't cross-post unless it's really
> called for.[/color]

This is definitely a cross-post issue. The problem is not with <HR>,
and not with margins. It is an interaction between CSS and HTML.

Incidentally, the CSS testcases at http://www.w3.org/Style/CSS/Test/
don't seem to test the implementation of the box model on <HR>
elements, AFAICT.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:
[color=blue]
>1. To be precise... what does it mean yours
>
>hr { margin: auto; } exactly ?
>
>As far as I know CSS 2.1 does not say anything
>about what margin-top: auto should be.
>(Probably a bug in the specification)[/color]

http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins

For most cases the spec clearly states:
"If 'margin-top', or 'margin-bottom' are 'auto', their used value is
0"
[color=blue]
>In such circumstances UA is free to choose any suitable value.[/color]

That would normally be an error. The only cases where margin-top:
auto; should not be treated as margin-top: 0; are absolutely
positioned elements.
[color=blue]
>2. HRs, TABLEs and IMGs are special cases as their traditional shapes and
>rendering behavior cannot be defined in pure CSS.[/color]

IMG is a replaced inline element and as such follows the rules for
such as laid out in the spec.
The CSS spec has a large section on formatting tables.

What part of the traditional shape and rendering behaviour of an image
or table can not be defined in pure CSS?

HR is an oddity, but it's an oddity in HTML before you get anywhere
near CSS.
It's a block element, but how the visual horizontal rule relates to
the CSS box model is a bit vague - is the rule the content or is
created by borders? Browser behaviour can and does vary.
IE does treat HRs oddly. There's some default white space above and
below the visible rule. This white space looks like a margin but in
many ways doesn't behave like a margin.

This is of course the OP's problem and the best solution is to not use
HRs for such purposes. What little semantic meaning the <hr> has is
that it serves to indicate a change of topic. What does it mean to
change the topic three times in succession with no intervening
content?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

The best work around I've been able to generate is the following. This
works in IE6, O7, Moz1.7. It *doesn't* render correctly in FP2003,
FYI.

I got most of the solution from http://www.sovavsiti.cz/css/hr.html

Any comments?

---------------<snip>------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><hr> Hack</title>
<style type="text/css">

</style>
</head>

<body>

<p>Here's a series of tightly packed <hr>'s:</p>
<hr />
<hr />
<hr />

<p>Here's the same series of tightly packed <hr>'s inside a
table:</p>
<table style="width: 100%;">
<tbody>
<tr>
<td>
<hr />
<hr />
<hr />
</td>
</tr>
</tbody>
</table>

<p>Here's a work around that uses a stylized <div>:</p>
<div class="divider" style="background-color: red;"><hr /></div>
<div class="divider" style="background-color: green; width: 80%;"><hr
/></div>
<div class="divider" style="background-color: blue;"><hr /></div>

<p>Here are some <div>'s inside a table:</p>
<table style="width: 100%;">
<tbody>
<tr>
<td>
<div class="divider" style="background-color:red;"><hr /></div>
<div class="divider" style="background-color: green; width:
80%;"><hr /></div>
<div class="divider" style="background-color:blue;"><hr /></div>
</td>
</tr>
</tbody>
</table>

<p>NOTE: The hidden internal <hr> serves two purposes:</p>
<ul>
<li>Provide something useful for non-graphical UA's (e.g.
semantic parsers).</li>
<li>Fix an IE6 bug which doesn't render empty div's
correctly.</li>
</ul>

</body>

</html>

On 29 Jun 2004 12:15:25 -0700, mark.moore@notlimited.com (Mark Moore)
wrote:
[color=blue]
>It looks like there's a pretty serious CSS bug in IE6
>(v6.0.2800.1106). The HTML below is validated STRICT HTML 4.01 and
>renders as I would expect in Opera, FrontPage, and Netscape.
>
>For some reason, there's an annoying vertical gap between adjacent
>rules that doesn't go away. This looks like IE6 is incorrectly
>setting the margin to some arbitrary value.
>[/color]

It depends, really, on what you consider the HR element to be. It's
tricky to define it in the CSS box model. Is it a replaced content box
containing a line? Is it a border around an empty box? Is it something
else entirely?

One reason for the awkwardness here is that HR is, at least to a
certain extent, a presentational element. Once we've realised this,
it's not a big jump to decide that maybe the effect of a horizontal
rule might be better created using visual CSS, by simply adding a top
or bottom border to the item you wish to rule over or under.

-Claire

Mark Moore wrote:[color=blue]
> Brian and Spartanicus, I can't believe how rude your reponses are.[/color]

http://www.catb.org/~esr/faqs/smart-...tml#not_losing
[color=blue][color=green]
>> Instead, post a url.[/color]
>
> No, thank you.[/color]

If you cannot be bothered to upload a test case, then I cannot be
bothered to help.
[color=blue]
> This is definitely a cross-post issue. The problem is not with <HR>,
> and not with margins. It is an interaction between CSS and HTML.[/color]

By that definition, all css posts should be crossposted. Sort of
defeats the point of having separate groups, no? (Followups *re*set.)

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

> >(Probably a bug in the specification)[color=blue]
>
> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins
>
> For most cases the spec clearly states:
> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
> 0"[/color]

Thanks Steve for mentioning it.

Good wish to editors of specification:
I guess link above should be accessible from this chapter
http://www.w3.org/TR/CSS21/box.html#margin-properties.

[color=blue]
> IMG is a replaced inline element and as such follows the rules for
> such as laid out in the spec.
> The CSS spec has a large section on formatting tables.
>
> What part of the traditional shape and rendering behaviour of an image
> or table can not be defined in pure CSS?
>[/color]

<IMG width=200> - height effectively computes proprtionally using intrinsic
dimensions.

<IMG src="non-available-resource-url"> - produce different shapes in
different UAs - no way to override it in CSS.

<IMG src="available-resource-url" width=XX height=YY> - produce scaled
image. No image scaling so far in CSS.

<TABLE><TD width=40></TABLE>
width of the cell here means box width in terms of CSS.

<TABLE><TD style="width:40px; padding:10px"></TABLE>
CSS here changes box model completely and now width of the cell means *width
plus padding and border*
as like non-existed 'box-sizing' applied.

Andrew Fedoniouk.
http://terrainformatica.com

"Steve Pugh" <steve@pugh.net> wrote in message
news:gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com...[color=blue]
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>[color=green]
> >1. To be precise... what does it mean yours
> >
> >hr { margin: auto; } exactly ?
> >
> >As far as I know CSS 2.1 does not say anything
> >about what margin-top: auto should be.
> >(Probably a bug in the specification)[/color]
>
> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins
>
> For most cases the spec clearly states:
> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
> 0"
>[color=green]
> >In such circumstances UA is free to choose any suitable value.[/color]
>
> That would normally be an error. The only cases where margin-top:
> auto; should not be treated as margin-top: 0; are absolutely
> positioned elements.
>[color=green]
> >2. HRs, TABLEs and IMGs are special cases as their traditional shapes and
> >rendering behavior cannot be defined in pure CSS.[/color]
>
> IMG is a replaced inline element and as such follows the rules for
> such as laid out in the spec.
> The CSS spec has a large section on formatting tables.
>
> What part of the traditional shape and rendering behaviour of an image
> or table can not be defined in pure CSS?
>
> HR is an oddity, but it's an oddity in HTML before you get anywhere
> near CSS.
> It's a block element, but how the visual horizontal rule relates to
> the CSS box model is a bit vague - is the rule the content or is
> created by borders? Browser behaviour can and does vary.
> IE does treat HRs oddly. There's some default white space above and
> below the visible rule. This white space looks like a margin but in
> many ways doesn't behave like a margin.
>
> This is of course the OP's problem and the best solution is to not use
> HRs for such purposes. What little semantic meaning the <hr> has is
> that it serves to indicate a change of topic. What does it mean to
> change the topic three times in succession with no intervening
> content?
>
> Steve
>
> --
> "My theories appal you, my heresies outrage you,
> I never answer letters and you don't like my tie." - The Doctor
>
> Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>[/color]

Andrew Fedoniouk wrote:
[color=blue][color=green]
>> What part of the traditional shape and rendering behaviour
>> of an image or table can not be defined in pure CSS?[/color]
>
> <IMG width=200> - height effectively computes proprtionally
> using intrinsic dimensions.[/color]

img {width:200px;}
[color=blue]
> <IMG src="non-available-resource-url"> - produce different
> shapes in different UAs - no way to override it in CSS.[/color]

True.
[color=blue]
> <IMG src="available-resource-url" width=XX height=YY> -
> produce scaled image. No image scaling so far in CSS.[/color]

img {height:200px;width:50px;}

Works both in Firefox and IE, I just tried it.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Steelers Wheel - Stuck in The Middle

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:[color=blue]
> Steve Pugh <steve@pugh.net> wrote:[/color]
(correct attribution inserted)
[color=blue][color=green]
>> IMG is a replaced inline element and as such follows the rules for
>> such as laid out in the spec.
>> The CSS spec has a large section on formatting tables.
>>
>> What part of the traditional shape and rendering behaviour of an image
>> or table can not be defined in pure CSS?[/color]
>
><IMG width=200> - height effectively computes proprtionally using intrinsic
>dimensions.[/color]

<IMG style="width:200px"> produces exactly the same result in IE6,
Firefox 0.8 and Opera 7.51. In which browsers does it not maintain the
aspect ratio?
[color=blue]
><IMG src="non-available-resource-url"> - produce different shapes in
>different UAs - no way to override it in CSS.[/color]

True, though the CSS3 icon property is a move towards this sort of
thing (though I don't think it would apply in this case, unless
there's a new pseudo-class for missing images). But this hardly counts
as part of the normal rendering of the img element. Next you'll be
asking to style the JavaScript error boxes.
[color=blue]
><IMG src="available-resource-url" width=XX height=YY> - produce scaled
>image. No image scaling so far in CSS.[/color]

<IMG style="width:XXpx;height:YYpx"> produces exactly the same result
as the HTML equivalent. Did you actually try it before posting or do
you mean something else?
[color=blue]
><TABLE><TD width=40></TABLE>
>width of the cell here means box width in terms of CSS.
>
><TABLE><TD style="width:40px; padding:10px"></TABLE>
>CSS here changes box model completely and now width of the cell means *widt
>plus padding and border*
>as like non-existed 'box-sizing' applied.[/color]

Your two examples are not equivalent.

<TABLE border="1"><TD width=40>Foo</TABLE>
<TABLE border="1"><TD style="width:40px;">Foo</TABLE>
Render at the same width in IE6, Opera 7.51 and Mozilla 1.6
As do
<TABLE border="1" cellpadding="10"><TD width=40>Foo</TABLE>
<TABLE border="1"><TD style="width:40px; padding: 10px;">Foo</TABLE>

Column/Cell widths are NOT calculated the same way as ordinary box
widths in CSS, so the difference between content-box and border-box
does not apply. See
http://www.w3.org/TR/CSS21/tables.html#width-layout

[snip]
Why did you then quote the entire previous message, including sig,
after you had quoted the parts you were replying to?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins[color=blue]
>
> For most cases the spec clearly states:
> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
> 0"...[/color]

Thanks for the link. I was wondering where should be defined value for
margin-top:auto...
Initial idea was in section describing margin-top...
[color=blue]
> IMG is a replaced inline element and as such follows the rules for
> such as laid out in the spec.[/color]

Traditional <IMG src="some-unavailable-uri"> rendering could not be defined
or overrided by CSS.
IMG srource could not be defined or changed by CSS.
Image scaling could not be reproduced anywhere else except IMG, etc.
[color=blue]
> The CSS spec has a large section on formatting tables.[/color]

<TABLE><TD width=20>...</TD></TABLE>
<TABLE><TD style="width:20px">...</TD></TABLE>
means completely different widths. Moreover: second case defines
width *including* possible CSS padding. There is no way in CSS currently to
achieve the same without using tables.

Final width and behaviour of simple:
<TABLE><TD >One two three</TD></TABLE>
could not be defined by CSS. There are no such entity yet as max-width:
max-intrinsic.

And I am yet silent about <TABLE><TD colspan=X>...</TD></TABLE>
etc.

Andrew Fedoniouk.
http://terrainformatica.com

"Steve Pugh" <steve@pugh.net> wrote in message
news:gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com...[color=blue]
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>[color=green]
> >1. To be precise... what does it mean yours
> >
> >hr { margin: auto; } exactly ?
> >
> >As far as I know CSS 2.1 does not say anything
> >about what margin-top: auto should be.
> >(Probably a bug in the specification)[/color]
>
> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins
>
> For most cases the spec clearly states:
> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
> 0"
>[color=green]
> >In such circumstances UA is free to choose any suitable value.[/color]
>
> That would normally be an error. The only cases where margin-top:
> auto; should not be treated as margin-top: 0; are absolutely
> positioned elements.
>[color=green]
> >2. HRs, TABLEs and IMGs are special cases as their traditional shapes and
> >rendering behavior cannot be defined in pure CSS.[/color]
>
> IMG is a replaced inline element and as such follows the rules for
> such as laid out in the spec.
> The CSS spec has a large section on formatting tables.
>
> What part of the traditional shape and rendering behaviour of an image
> or table can not be defined in pure CSS?
>
> HR is an oddity, but it's an oddity in HTML before you get anywhere
> near CSS.
> It's a block element, but how the visual horizontal rule relates to
> the CSS box model is a bit vague - is the rule the content or is
> created by borders? Browser behaviour can and does vary.
> IE does treat HRs oddly. There's some default white space above and
> below the visible rule. This white space looks like a margin but in
> many ways doesn't behave like a margin.
>
> This is of course the OP's problem and the best solution is to not use
> HRs for such purposes. What little semantic meaning the <hr> has is
> that it serves to indicate a change of topic. What does it mean to
> change the topic three times in succession with no intervening
> content?
>
> Steve
>
> --
> "My theories appal you, my heresies outrage you,
> I never answer letters and you don't like my tie." - The Doctor
>
> Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>[/color]

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:[color=blue]
>"Steve Pugh" <steve@pugh.net> wrote:[/color]

Andrew, you already replied to my message yesterday. And why are you
still not adding the correct attributions to the parts of my message
that you quote? And why are you still adding a full quote of the
previous message at the end of your post?
[color=blue][color=green]
>> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins
>>
>> For most cases the spec clearly states:
>> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
>> 0"...[/color]
>
>Thanks for the link. I was wondering where should be defined value for
>margin-top:auto...[/color]

The details of how properties are interpreted are found in the details
section of the spec. That's just the way the spec is written.
[color=blue]
>Initial idea was in section describing margin-top...[/color]

Sorry, which initial idea?
[color=blue][color=green]
>> IMG is a replaced inline element and as such follows the rules for
>> such as laid out in the spec.[/color]
>
>Traditional <IMG src="some-unavailable-uri"> rendering could not be defined
>or overrided by CSS.[/color]

Already commented on in my reply to your post of yesterday.
[color=blue]
>IMG srource could not be defined or changed by CSS.[/color]

Why should it be? That's content not presentation. Do you think that
CSS should have the ability to change the text content of, for
example, <h1>My web page</h1> ?
[color=blue]
>Image scaling could not be reproduced anywhere else except IMG, etc.[/color]

Sorry, what do you mean? As Els and myself have both demonstrated CSS
can resize images in exactly the same way that HTML can. So what are
you talking about here?
[color=blue][color=green]
>> The CSS spec has a large section on formatting tables.[/color]
>
><TABLE><TD width=20>...</TD></TABLE>
><TABLE><TD style="width:20px">...</TD></TABLE>
>means completely different widths.[/color]

No they don't. Those two cases will render exactly the same in modern
browsers with good support for the CSS standards (and regardless of
doctype sniffing).
[color=blue]
>Moreover: second case defines
>width *including* possible CSS padding.[/color]

Yes. Table columns widths do not follow the normal CSS box model. This
is, in part, to maintain compatability with the HTML rendering of
tables. i.e. the very thing that you're accusing CSS of not doing.
[color=blue]
>There is no way in CSS currently to
>achieve the same without using tables.[/color]

It's a table, so it's a table. What do you mean?

Are you saying that you want to replace <TABLE><TD
style="width:20px">...</TD></TABLE> with <DIV
style="width:20px">...</DIV> (with some non-zero padding) and have it
render at the same width?

This will be possible in CSS3 with the box-width property. It's
possible now if you:
(a) trigger quirks mode so IE and Opera 7 uses the IE5 box model (i.e.
IE's broken box model is the same as the border-box model)
(b) use -moz-box-sizing: border-box; to make Mozilla use the
border-box model.
(c) use box-sizing and/or box-width for future compatability.
This will cover most current and future browsers.

[color=blue]
>Final width and behaviour of simple:
><TABLE><TD >One two three</TD></TABLE>
>could not be defined by CSS. There are no such entity yet as max-width:
>max-intrinsic.[/color]

You have no HTML attributes there so I'm not sure what you want to
replace with CSS. Applying no styles at all will lead to exactly the
same rendering (obviously).

Are you trying to replace the table with a div? Then you need display:
table and/or display: table-cell. Blame MSIE for not supporting it,
the ability to size a box as if was a table has been part of CSS2 ever
since it was published in 1997.
[color=blue]
>And I am yet silent about <TABLE><TD colspan=X>...</TD></TABLE>
>etc.[/color]

colspan indicates a relationship between the data in the cells. It is
therefore properly part of the HTML and has no place in CSS.

If you're talking about replacing the table with divs, then you don't
need colspan. Look at the following in a CSS2 compliant browser (i.e.
not IE):

<div style="display: table-row">
<div style="display: table-cell; width: 100px; border: 1px
solid red;">Cell 1</div>
<div style="display: table-cell; width: 100px; border: 1px
solid red;">Cell 2</div>
</div>
<div style="display: table-row">
<div style="display: table-cell; width: 200px; border: 1px
solid red;">Cell 3</div>
</div>

[snip full quote of previous message]

cheers,
Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

Steve Pugh <steve@pugh.net> wrote:
[color=blue]
>CSS2 ever since it was published in 1997.[/color]

1998. Sorry.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

On Thu, 01 Jul 2004 10:51:19 +0100, Steve Pugh <steve@pugh.net> wrote:[color=blue]
>
>If you're talking about replacing the table with divs, then you don't
>need colspan. Look at the following in a CSS2 compliant browser (i.e.
>not IE):
>
><div style="display: table-row">
> <div style="display: table-cell; width: 100px; border: 1px
>solid red;">Cell 1</div>
> <div style="display: table-cell; width: 100px; border: 1px
>solid red;">Cell 2</div>
></div>
><div style="display: table-row">
> <div style="display: table-cell; width: 200px; border: 1px
>solid red;">Cell 3</div>
></div>
>[/color]

When I read this I got a bit excited, because I thought I remembered
trying this before and failing to "emulate" colspan. Sadly, when I
tried it in both Opera and FireFox it acted as I remembered; similar
to this ASCII-"art" recreation:

.---------------------------+-------------.
| Cell 1 | Cell 2 |
+---------------------------+-------------+
| Cell 3 |
'---------------------------'

The browsers connected the two table-row elements into a single table,
presumably implicitly creating a table box around them both.

Strangely enough, introducing an anonymous inline box between the two
DIV elements created a result more like you suggest:

.-------------+-------------.
| Cell 1 | Cell 2 |
'-------------+-------------'
Blah blah blah
.---------------------------.
| Cell 3 |
'---------------------------'

....presumably because it split the implicit table box into two
independent table boxes.

I'm left to wonder if it's possible to create two table boxes without
introducing "redundant" markup. Sadly, I suspect that it is
impossible, and even if it were possible the tables would not act as
one table for the purposes of border collapsing and column alignment.

-Claire

Claire Tucker <fake@invalid.com> wrote:[color=blue]
>On Thu, 01 Jul 2004 10:51:19 +0100, Steve Pugh <steve@pugh.net> wrote:[color=green]
>>
>>If you're talking about replacing the table with divs, then you don't
>>need colspan. Look at the following in a CSS2 compliant browser (i.e.
>>not IE):
>>
>><div style="display: table-row">
>> <div style="display: table-cell; width: 100px; border: 1px
>>solid red;">Cell 1</div>
>> <div style="display: table-cell; width: 100px; border: 1px
>>solid red;">Cell 2</div>
>></div>
>><div style="display: table-row">
>> <div style="display: table-cell; width: 200px; border: 1px
>>solid red;">Cell 3</div>
>></div>
>>[/color]
>
>When I read this I got a bit excited, because I thought I remembered
>trying this before and failing to "emulate" colspan. Sadly, when I
>tried it in both Opera and FireFox it acted as I remembered; similar
>to this ASCII-"art" recreation:
>
> .---------------------------+-------------.
> | Cell 1 | Cell 2 |
> +---------------------------+-------------+
> | Cell 3 |
> '---------------------------'
>
>The browsers connected the two table-row elements into a single table,
>presumably implicitly creating a table box around them both.[/color]

Hmm, Opera 7.51 honours the specified widths but Opera 7.23 and
Firefox 0.8 act as you describe.

The spec avoids responsibility for which is the correct rendering:
"Cells may span several rows or columns. (Although CSS 2.1 doesn't
define how the number of spanned rows or columns is determined, a user
agent may have special knowledge about the source document; a future
version of CSS may provide a way to express this knowledge in CSS
syntax.)"
http://www.w3.org/TR/CSS21/tables.html#q7

Annoying.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

On Thu, 01 Jul 2004 16:14:45 +0100, Steve Pugh <steve@pugh.net> wrote:[color=blue]
>
>The spec avoids responsibility for which is the correct rendering:
>"Cells may span several rows or columns. (Although CSS 2.1 doesn't
>define how the number of spanned rows or columns is determined, a user
>agent may have special knowledge about the source document; a future
>version of CSS may provide a way to express this knowledge in CSS
>syntax.)"
>http://www.w3.org/TR/CSS21/tables.html#q7
>[/color]

Presumably this term "special knowledge" is referring to the
well-defined meanings of the HTML table structure and associated
attributes. Not much use for describing appropriate rendering of an
arbitrary XML document, but then I suppose CSS isn't the best tool for
doing that anyway.

Best regards,
-Claire

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:<s7rEc.909175$Pk3.261780@pd7tw1no>...[color=blue]
>1. To be precise... what does it mean yours
>
>hr { margin: auto; } exactly ?[/color]

My precise intention is "margin: 0 auto 0 auto;", but as Steve remarks
below, my understanding is that auto top and bottom margins are set to
zero.

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> HR is an oddity, but it's an oddity in HTML before you get anywhere
> near CSS.
> It's a block element, but how the visual horizontal rule relates to
> the CSS box model is a bit vague - is the rule the content or is
> created by borders? Browser behaviour can and does vary.
> IE does treat HRs oddly. There's some default white space above and
> below the visible rule. This white space looks like a margin but in
> many ways doesn't behave like a margin.[/color]
[snip][color=blue]
> What little semantic meaning the <hr> has is that it serves to
> indicate a change of topic.[/color]

First, the very vagueness you speak of seems to me to be a clear
indicator of a weakness or outright flaw in the CSS specification.
Shouldn't it take a stand? Either clearly define for HR elements
whether the rule is the content, or instead, that it has no content
and the only thing left for the UA to render is its Cheshire like
border and background (just like an empty DIV, incidentally); or
specifically document that the rendering or HR elements is explicitly
undefined, and should therefore be avoided.

BTW, the CSS2.1 spec implies *strongly* that HR elements should be
rendered as empty contents with stylized borders when it describes the
typical formatting of HR elements for HTML 4.0 as "hr { border: 1px
inset }" and *doesn't* enumerate HR elements in the paragraph that
starts "The full presentation of some HTML elements cannot be
expressed in CSS 2.1,..."

http://www.w3.org/TR/CSS21/sample.html

As it is, the specified standard way to handle/render HR elements
slips silently between the CSS and HTML specifications. (Which is why
I believe this is a cross-post issue.)

I've seen this kind of discussion across the web as I was trying to
get to the bottom of my issue. But, it's simply a cop-out (IMHO).
Either the CSS spec, the HTML spec, or both are deficient. If HR
elements have any semantic meaning, even a little, they should be
treated as full citizens of valid content markup. If they have no
semantic content (or not enough, anyway), they should be excluded from
STRICT HTML. If ciwa.stylesheets and ciwa.html aren't the right
forums to ferret out this deficiency, what are?

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> This is of course the OP's problem and the best solution is to not use
> HRs for such purposes.[/color]

Please excuse my ignorance, but what or who is an OP? I'll assume you
mean the HTML author(s) for now...

This view may be strictly true, but is not terribly practical. For
instance, I'm tasked with cleaning up an already deployed site which
mashed content and display markup together. My goal is to refactor
the HTML and extract the display markup incrementally so I can keep
the site working, and demonstrate progress to the client (to keep them
happy with and paying for the cleanup).

Concretely, they used a 1px transparent spacer GIF in an IMG element
to render all the horizontal rules on their site (a *very* common
practice). By converting these to stylized HR elements, I can
significantly improve the code and bring them a step closer to fully
validated HTML and CSS and a step closer to properly factored content
and presentation markup.

If my only option is to eliminate HR elements, I am forced to identify
what other content element the rule is supposed to be decorating.
Worse, this decision may require customer involvement if the
identified object is not obvious, changes the visual display, or
requires changes to the source content or its pre-processing. This
difficulty is common in situations like this since the original
designer(s) didn't think about separating content from display in the
first place (by definition).

The bottom line is that lowering barriers to converting existing HTML
to well structured, fully compliant HTML and CSS is good for everyone
(especially CSS sticklers :oD ). And, well defined, consistently
rendered HR elements definitely lower the barrier.

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> What does it mean to
> change the topic three times in succession with no intervening
> content?[/color]

What it means is it was a quick way to demonstrate the air gap above
and below IE6 horizontal rules (although I'm sure you already
recognize that the meaning of any particular content shouldn't affect
its rendering). ;o)

A more semantically meaningful example would have been
"<div>above</div><hr><div>below</div>", but I was afraid the gap may
have been mistaken as an artifact of the font descender area.

Since you asked, it would be perfectly reasonable for a document with
a large number of dynamically generated sections (I think you called
them "topics") to have one or more empty sections. If HR elements
separate sections, two consecutive empty sections would yield the
<hr><hr><hr> example.

I think that answers all the questions so far...

-------------------- Side Note ----------------------
Steve, Andrew, and Claire (below), thanks for the thoughtful replies.
I apologize for not responding sooner, but I'm using the Google News
Browser, and this thread wasn't attached to my original post. I was
monitoring the original thread which has unfortunately only yielded a
flame fest with little or no content.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:<s7rEc.909175$Pk3.261780@pd7tw1no>...[color=blue]
>1. To be precise... what does it mean yours
>
>hr { margin: auto; } exactly ?[/color]

My precise intention is "margin: 0 auto 0 auto;", but as Steve remarks
below, my understanding is that auto top and bottom margins are set to
zero.

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> HR is an oddity, but it's an oddity in HTML before you get anywhere
> near CSS.
> It's a block element, but how the visual horizontal rule relates to
> the CSS box model is a bit vague - is the rule the content or is
> created by borders? Browser behaviour can and does vary.
> IE does treat HRs oddly. There's some default white space above and
> below the visible rule. This white space looks like a margin but in
> many ways doesn't behave like a margin.[/color]
[snip][color=blue]
> What little semantic meaning the <hr> has is that it serves to
> indicate a change of topic.[/color]

First, the very vagueness you speak of seems to me to be a clear
indicator of a weakness or outright flaw in the CSS specification.
Shouldn't it take a stand? Either clearly define for HR elements
whether the rule is the content, or instead, that it has no content
and the only thing left for the UA to render is its Cheshire like
border and background (just like an empty DIV, incidentally); or
specifically document that the rendering or HR elements is explicitly
undefined, and should therefore be avoided.

BTW, the CSS2.1 spec implies *strongly* that HR elements should be
rendered as empty contents with stylized borders when it describes the
typical formatting of HR elements for HTML 4.0 as "hr { border: 1px
inset }" and *doesn't* enumerate HR elements in the paragraph that
starts "The full presentation of some HTML elements cannot be
expressed in CSS 2.1,..."

http://www.w3.org/TR/CSS21/sample.html

As it is, the specified standard way to handle/render HR elements
slips silently between the CSS and HTML specifications. (Which is why
I believe this is a cross-post issue.)

I've seen this kind of discussion across the web as I was trying to
get to the bottom of my issue. But, it's simply a cop-out (IMHO).
Either the CSS spec, the HTML spec, or both are deficient. If HR
elements have any semantic meaning, even a little, they should be
treated as full citizens of valid content markup. If they have no
semantic content (or not enough, anyway), they should be excluded from
STRICT HTML. If ciwa.stylesheets and ciwa.html aren't the right
forums to ferret out this deficiency, what are?

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> This is of course the OP's problem and the best solution is to not use
> HRs for such purposes.[/color]

Please excuse my ignorance, but what or who is an OP? I'll assume you
mean the HTML author(s) for now...

This view may be strictly true, but is not terribly practical. For
instance, I'm tasked with cleaning up an already deployed site which
mashed content and display markup together. My goal is to refactor
the HTML and extract the display markup incrementally so I can keep
the site working, and demonstrate progress to the client (to keep them
happy with and paying for the cleanup).

Concretely, they used a 1px transparent spacer GIF in an IMG element
to render all the horizontal rules on their site (a *very* common
practice). By converting these to stylized HR elements, I can
significantly improve the code and bring them a step closer to fully
validated HTML and CSS and a step closer to properly factored content
and presentation markup.

If my only option is to eliminate HR elements, I am forced to identify
what other content element the rule is supposed to be decorating.
Worse, this decision may require customer involvement if the
identified object is not obvious, changes the visual display, or
requires changes to the source content or its pre-processing. This
difficulty is common in situations like this since the original
designer(s) didn't think about separating content from display in the
first place (by definition).

The bottom line is that lowering barriers to converting existing HTML
to well structured, fully compliant HTML and CSS is good for everyone
(especially CSS sticklers :oD ). And, well defined, consistently
rendered HR elements definitely lower the barrier.

Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=blue]
> What does it mean to
> change the topic three times in succession with no intervening
> content?[/color]

What it means is it was a quick way to demonstrate the air gap above
and below IE6 horizontal rules (although I'm sure you already
recognize that the meaning of any particular content shouldn't affect
its rendering). ;o)

A more semantically meaningful example would have been
"<div>above</div><hr><div>below</div>", but I was afraid the gap may
have been mistaken as an artifact of the font descender area.

Since you asked, it would be perfectly reasonable for a document with
a large number of dynamically generated sections (I think you called
them "topics") to have one or more empty sections. If HR elements
separate sections, two consecutive empty sections would yield the
<hr><hr><hr> example.

I think that answers all the questions so far...

-------------------- Side Note ----------------------
Steve, Andrew, and Claire (below), thanks for the thoughtful replies.
I apologize for not responding sooner, but I'm using the Google News
Browser, and this thread wasn't attached to my original post. I was
monitoring the original thread which has unfortunately only yielded a
flame fest with little or no content.

Claire Tucker <fake@invalid.com> wrote in message news:<9vg5e01v6cm3gs40977fthssflop6jbgqk@4ax.com>. ..[color=blue]
> It depends, really, on what you consider the HR element to be. It's
> tricky to define it in the CSS box model. Is it a replaced content box
> containing a line? Is it a border around an empty box? Is it something
> else entirely?[/color]

I understand it's tricky, but isn't that the CSS specification's whole
purpose? If CSS-WG doesn't define how it's to be rendered, who does?
If the rendering of HR elements it undefined, shouldn't the spec say
so?
[color=blue]
> One reason for the awkwardness here is that HR is, at least to a
> certain extent, a presentational element.[/color]

If HR elements are purely presentational, shouldn't they be excluded
from valid HTML markup? Would it be better to allow them in
transitional HTML, but exclude them from STRICT?
[color=blue]
> it's not a big jump to decide that maybe the effect of a horizontal
> rule might be better created using visual CSS, by simply adding a top
> or bottom border to the item you wish to rule over or under.[/color]

This presupposes there is an existing element to decorate with a top
or bottom border. In practice, it can be difficult to identify such
an element which may explain why there are so may "useless" HR
elements (or worse, IMG elements) used in modern web sites to create
the effect of a horizontal rule.

Mark Moore wrote:
[color=blue]
> Please excuse my ignorance, but what or who is an OP?[/color]

op = original post | original poster, i.e., author of original post

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Mark Moore wrote:
[color=blue]
> Claire Tucker wrote...
>[color=green]
>> One reason for the awkwardness here is that HR is, at least to a
>> certain extent, a presentational element.[/color]
>
> If HR elements are purely presentational, shouldn't they be
> excluded from valid HTML markup?[/color]

What's dicey about this is that <hr> is a bit flawed from a markup
point of view, since it doesn't mark up anything. It is an empty
element. <p> was also defined as an empty element in an early html
draft, a "paragraph separator." AIUI, some SGML types got involved,
and changed what they could so that HTML would look and behave more
like an application of SGML.
[color=blue][color=green]
>> it's not a big jump to decide that maybe the effect of a
>> horizontal rule might be better created using visual CSS, by
>> simply adding a top or bottom border to the item you wish to rule
>> over or under.[/color]
>
> This presupposes there is an existing element to decorate with a
> top or bottom border.[/color]

Well, yes, but if there are no block level elements in a document,
then an <hr> is surely unnecessary. Your particular problem -- trying
to identify an element to attach a border to -- is part of the
ugliness of converting a site, but not part of the larger problem of
www authoring.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Steve Pugh <steve@pugh.net> wrote in message news:<9jm7e0h4qg27l278oatih2kgctjpj67aua@4ax.com>. ..[color=blue]
> <div style="display: table-row">
> <div style="display: table-cell; width: 100px; border: 1px
> solid red;">Cell 1</div>
> <div style="display: table-cell; width: 100px; border: 1px
> solid red;">Cell 2</div>
> </div>
> <div style="display: table-row">
> <div style="display: table-cell; width: 200px; border: 1px
> solid red;">Cell 3</div>
> </div>[/color]

Steve, I gotta say, that's the coolest trick I've seen all week. I'd
seen display: table-cell in the docs, but didn't have time to
understand how it might be useful.

Steve Pugh <steve@pugh.net> wrote in message news:<38a8e0lj9q9l8kq1lrpdb1ol8snh1cfrdj@4ax.com>. ..[color=blue]
> Claire Tucker <fake@invalid.com> wrote:[/color]
[snip][color=blue][color=green]
> > .---------------------------+-------------.
> > | Cell 1 | Cell 2 |
> > +---------------------------+-------------+
> > | Cell 3 |
> > '---------------------------'[/color][/color]
[snip][color=blue]
>
> Hmm, Opera 7.51 honours the specified widths but Opera 7.23 and
> Firefox 0.8 act as you describe.[/color]

Mozilla 1.7 renders this way as well (wondering to myself, "Is FF0.8
the same as Moz1.7?").

[color=blue]
> The spec avoids responsibility for which is the correct rendering:
> "Cells may span several rows or columns. (Although CSS 2.1 doesn't
> define how the number of spanned rows or columns is determined, a user
> agent may have special knowledge about the source document; a future
> version of CSS may provide a way to express this knowledge in CSS
> syntax.)"[/color]

Not so fast...

Now that I'm looking at the CSS2.1 more closely, your case seems to be
clearly specified, and all three implementations render correctly
formed tables (with one exception I'll get to a little later).

According to section 17.2.1:

<BLOCKQUOTE cite="http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes">
<P>If the parent P of a 'table-row' element T is not a 'table',
'inline-table', 'table-header-group', 'table-footer-group' or
'table-row-group' element, an object corresponding to a 'table'
element will be generated between P and T. This object will span all
consecutive siblings (in the document tree) of T that require a
'table' parent: 'table-row', 'table-row-group', 'table-header-group',
'table-footer-group', 'table-column', 'table-column-group', and
'table-caption'. T and T's siblings may also be anonymous 'table-row'
objects generated by rule 1.</P>
</BLOCKQUOTE>

Since both your outer most DIV's are table-row elements, their parent
is not a table or inline-table element, *and* they are consecutive,
the UA *must* generate an anonymous table element that spans them
both. One 2x2 table with three cells should be rendered.

The following should render two identical tables, and one slightly
different:

<div style="display: table-row">
<div style="display: table-cell; width: 100px; border: 1px solid
red;">
Cell 1
</div>
<div style="display: table-cell; width: 100px; border: 1px solid
red;">
Cell 2
</div>
</div>
<div style="display: table-row">
<div style="display: table-cell; width: 200px; border: 1px solid
red;">
Cell 3
</div>
</div>
<div style="display: table;">
<div style="display: table-row">
<div style="display: table-cell; width: 100px; border: 1px solid
red;">
Cell 1
</div>
<div style="display: table-cell; width: 100px; border: 1px solid
red;">
Cell 2
</div>
</div>
<div style="display: table-row">
<div style="display: table-cell; width: 200px; border: 1px solid
red;">
Cell 3
</div>
</div>
</div>
<table>
<tr>
<td style="width: 100px; border: 1px solid red;">
Cell 1
</td>
<td style="width: 100px; border: 1px solid red;">
Cell 2
</td>
</tr>
<tr style="display: table-row">
<td style="width: 200px; border: 1px solid red;">
Cell 3
</td>
</tr>
</table>

The reason one of the three *may* render ever so slightly differently
is that CSS 2.1 suggests initializing with "table { border-spacing:
2px; }". If a UA follows this suggestion, the third table will render
with 2px cell spacing. If a UA does not initialize with these values,
all three tables should render identically.

http://localhost/doc/css/sample.html

Mozilla renders everything perfectly (by my reading). Opera seems to
have some trouble...

First, Opera 7.51 builds the anonymous table differently depending on
whether or not I include a STYLE element anywhere in the HTML, even if
the style block is completely empty!

If there are no style elements, Opera builds 2 anonymous tables (given
your original code, Steve). If a STYLE element is present, then Opera
will *correctly* build a single table, but renders it incorrectly (see
below for details).

Did the construction of anonymous tables change between CSS1 and
CSS2.1? If so, how does a UA distinguish between CSS1 and CSS2.1?
Maybe Opera's behavior is more correct assuming HTML with no explicit
STYLE element should be rendered using CSS1 rules.

Either way, it looks like Opera 7.51 incorrectly generates a TABLE
element to contain anonymous tables instead of generating an anonymous
element (with style="display: table"). I'm guessing this for now
because the tables are rendered with non-zero border-spacing, but I'll
work up a test case and attach my results in a follow-up.

Actually, it looks like O7.51 completely wanks the anonymous table
handling. If a STYLE element is present, the "new (and improved?)"
anonymous table generator seems to try and stitch together way more
than it should. Test cases to follow.

Finally, if you want your original code to work the way you liked,
simply insert anything that's A) empty, and B) is not table-ish
('table-row', 'table-row-group', 'table-header-group',
'table-footer-group', 'table-column', 'table-column-group',
'table-caption', or 'table-cell') between the rows.

Try this:

<div style="display: table-row">
<div style="display: table-cell; width: 100px; border: 1px solid
red;">Cell 1</div>
<div style="display: table-cell; width: 100px; border: 1px solid
red;">Cell 2</div>
</div>
<div style="display: none;"></div> 
<div style="display: table-row">
<div style="display: table-cell; width: 200px; border: 1px solid
red;">Cell 3</div>
</div>

Of course, you could simply enclose the two table-row DIV's within
<div style="display: table;"></div> which probably better describes
your intention in the first place.

Whew!

Sorry for the double post. I'm not sure why that happened. -MM

On Thu, 01 Jul 2004 19:09:14 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> Mark Moore wrote:
>[color=green]
>> Claire Tucker wrote...
>>[color=darkred]
>>> One reason for the awkwardness here is that HR is, at least to a
>>> certain extent, a presentational element.[/color]
>>
>> If HR elements are purely presentational, shouldn't they be
>> excluded from valid HTML markup?[/color]
>
> What's dicey about this is that <hr> is a bit flawed from a markup
> point of view, since it doesn't mark up anything. It is an empty
> element.[/color]

<img> marks up nothing as well. Yet it's pretty well defined. Of course,
the content potential for img is stronger than for hr.

As I mention so often, I've abandoned styling hr's short of display:none.
I only use them when I need a visual division in a no-CSS rendering of a
page that cannot be adequately communicated with text alone.

Neal wrote:
[color=blue]
> Brian wrote:
>[color=green]
>> <hr> is a bit flawed from a markup point of view, since it
>> doesn't mark up anything. It is an empty element.[/color]
>
> <img> marks up nothing as well.[/color]

But even there, it would have been better if were not empty, and the
contents took the place of the alt "tag." ;-)

<img src="chirac.jpg">French president Jacques Chirac declared that
NATO should <em>not</em> send troops to Iraq.</img>

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

On Thu, 01 Jul 2004 23:07:45 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> Neal wrote:[color=green]
>> <img> marks up nothing as well.[/color]
>
> But even there, it would have been better if were not empty, and the
> contents took the place of the alt "tag." ;-)[/color]

That I do agree with.

All,

I've proposed the following workaround to Microsoft, and they're
planning on adding it to their product support database. This was a
work around for the stylized <hr> issue I posted that started this
thread (see http://groups.google.com/groups?hl=e...ng.google.com).

I think this is the best solution to the problem from both the content
and presentational markup perspectives.

Let me know what you would change.

-------stuff I'm sending to MS---------

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title><hr> Hack</title>
<style type="text/css">

</style>
</head>

<body>

<h2>The Problem</h2>
<div style="background-color: yellow;">above</div>
<hr style="border-color: red; width: 80%;">
<div style="background-color: yellow;">below</div>

<h2>The Workaround</h2>
<div style="background-color: yellow;">above</div>
<div class="hr" style="border-color: red; width: 80%;"><hr></div>
<div style="background-color: yellow;">below</div>

</body>

</html>

> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins[color=blue]
>
> For most cases the spec clearly states:
> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
> 0"...[/color]

I mean HR is a special element and may has different opinion about
margin-top:auto.
[color=blue]
> IMG is a replaced inline element and as such follows the rules for
> such as laid out in the spec.[/color]

Traditional <IMG src="some-unavailable-uri"> rendering could not be defined
or overrided by CSS.
IMG srource could not be defined or changed by CSS - so you cannot change
its look-n-feel at all.
Image scaling could not be reproduced anywhere else except IMG, etc.
[color=blue]
> The CSS spec has a large section on formatting tables.[/color]

<TABLE><TD width=20>...</TD></TABLE>
<TABLE><TD style="width:20px">...</TD></TABLE>
means completely different widths. Moreover: second case defines
width *including* possible CSS padding. There is no way in CSS currently to
achieve the same without using tables. (CSS3::box-sizing does not count)

Computed width of simple table:
<TABLE><TD >One two three</TD></TABLE>
could not be defined by CSS. There are no such entity yet as max-width:
max-intrinsic.

And I am yet silent about <TABLE><TD colspan=X>...</TD></TABLE>
etc.

Andrew Fedoniouk.
http://terrainformatica.com

On Thu, 1 Jul 2004, Brian wrote:
[color=blue]
> <img src="chirac.jpg">French president Jacques Chirac declared that
> NATO should <em>not</em> send troops to Iraq.</img>[/color]

Should have been like that from the start, but (if I heard it right)
the NCSA team were too stubborn to change what they'd already
implemented.

HTML/3.0 (deceased) would have implemented this with the "fig"
element.

HTML/4.0 tried to implement it with the "object" element, but a
certain provider who'd already got a proprietary "object" element
somehow contrived to implement it in such an awkward way that no-one
was prepared to use it instead of the long-established img.

So we're still no further forward.

By the way, I find it hard to believe that all the detail of the
information contained in your "alternative text" could really have
been evident from the picture itself?!?

cheers

Alan J. Flavell wrote:
[color=blue]
> On Thu, 1 Jul 2004, Brian wrote:
>[color=green]
>> <img src="chirac.jpg">French president Jacques Chirac declared that
>> NATO should <em>not</em> send troops to Iraq.</img>[/color]
>
> Should have been like that from the start, but (if I heard it right)
> the NCSA team were too stubborn to change what they'd already
> implemented.[/color]

That's really discouraging. There seems to be a regular occurence of a
company using its dominance to dictate a standard that they do not own.
AIUI, a similar thing happened with color tv in the States.
[color=blue]
> HTML/3.0 (deceased) would have implemented this with the "fig"
> element.[/color]

I'm afraid to learn about HTML 3.0 because I don't want to know what
could have been.
[color=blue]
> HTML/4.0 tried to implement it with the "object" element, but a
> certain provider who'd already got a proprietary "object" element
> somehow contrived to implement it in such an awkward way that no-one
> was prepared to use it instead of the long-established img.[/color]

More of the same. grrr
[color=blue]
> By the way, I find it hard to believe that all the detail of the
> information contained in your "alternative text" could really have
> been evident from the picture itself?!?[/color]

It was a picture with a "bubble" to explain what he was saying. And he
was waving his finger, so he must have been emphasizing something. :-)

--
Brian

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:[color=blue]
> Steve Pugh <steve@pugh.net> wrote:[/color]

Correct attribution inserted yet again.
[color=blue][color=green]
>> http://www.w3.org/TR/CSS21/visudet.h...ts_and_margins
>>
>> For most cases the spec clearly states:
>> "If 'margin-top', or 'margin-bottom' are 'auto', their used value is
>> 0"...[/color]
>
>I mean HR is a special element and may has different opinion about
>margin-top:auto.[/color]

[snip]

This is the third reply you've posted to the same message of mine, all
saying basically the same thing. If you want a discussion then try to
follow the normal rules of discussions and reply to my replies rather
than merely rewording your original post. Until then, goodbye.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

mark.moore@notlimited.com (Mark Moore) wrote:[color=blue]
>Steve Pugh <steve@pugh.net> wrote in message news:<gev4e0d2u423pcg47ijrns3o6tqe1eq0a9@4ax.com>. ..[color=green]
>>
>> HR is an oddity, but it's an oddity in HTML before you get anywhere
>> near CSS.
>> It's a block element, but how the visual horizontal rule relates to
>> the CSS box model is a bit vague - is the rule the content or is
>> created by borders? Browser behaviour can and does vary.
>> IE does treat HRs oddly. There's some default white space above and
>> below the visible rule. This white space looks like a margin but in
>> many ways doesn't behave like a margin.[/color]
>[snip][color=green]
>> What little semantic meaning the <hr> has is that it serves to
>> indicate a change of topic.[/color]
>
>First, the very vagueness you speak of seems to me to be a clear
>indicator of a weakness or outright flaw in the CSS specification.
>Shouldn't it take a stand? Either clearly define for HR elements
>whether the rule is the content, or instead, that it has no content
>and the only thing left for the UA to render is its Cheshire like
>border and background (just like an empty DIV, incidentally); or
>specifically document that the rendering or HR elements is explicitly
>undefined, and should therefore be avoided.[/color]

That's going into areas that are not for the CSS spec. CSS is, in
theory, a general stylesheet language that can be used for more than
just HTML. It does have a special relationship with HTML and the spec
does makes some explicit rulings that only apply to HTML but defining
the default presentation for an HTML element seems like a step too
far.
[color=blue]
>BTW, the CSS2.1 spec implies *strongly* that HR elements should be
>rendered as empty contents with stylized borders when it describes the
>typical formatting of HR elements for HTML 4.0 as "hr { border: 1px
>inset }" and *doesn't* enumerate HR elements in the paragraph that
>starts "The full presentation of some HTML elements cannot be
>expressed in CSS 2.1,..."
>
>http://www.w3.org/TR/CSS21/sample.html[/color]

"This appendix is informative, not normative."
[color=blue]
>As it is, the specified standard way to handle/render HR elements
>slips silently between the CSS and HTML specifications. (Which is why
>I believe this is a cross-post issue.)[/color]

Browsers can render the HR in whatever way they like - there doesn't
have to be a cross-browser default rendering, but however they choose
to render the HR they should make that rendering controllable via CSS.

That is where IE fails and is why I see the failing as being solely
with IE and not with the spec.
[color=blue]
>Either the CSS spec, the HTML spec, or both are deficient. If HR
>elements have any semantic meaning, even a little, they should be
>treated as full citizens of valid content markup. If they have no
>semantic content (or not enough, anyway), they should be excluded from
>STRICT HTML. If ciwa.stylesheets and ciwa.html aren't the right
>forums to ferret out this deficiency, what are?[/color]

The HTML spec can at most describe typical renderings because HTML is
about semantics not presentation.
The CSS spec defines the style language independent of any mark up
language. It does provide a typical default stylesheet for HTML (which
contains some very odd things not seen in any browser).

What you seem to want is a magic scroll that decsribes in precise CSS
terms what the each and every HTML element should be rendered like by
default. This can not exist. HTML is multi-platform and browsers will
have different default renderings for their different platforms. A
specialised kiosk browser might by default render HR via a fancy
graphic.

The deficiency lies with IE which does not make it's rendering of HR
fully accessible to CSS.
[color=blue][color=green]
>> This is of course the OP's problem and the best solution is to not use
>> HRs for such purposes.[/color]
>
>Please excuse my ignorance, but what or who is an OP? I'll assume you
>mean the HTML author(s) for now...[/color]

OP = Original Poster, in this case you.
[color=blue]
>This view may be strictly true, but is not terribly practical. For
>instance, I'm tasked with cleaning up an already deployed site which
>mashed content and display markup together. My goal is to refactor
>the HTML and extract the display markup incrementally so I can keep
>the site working, and demonstrate progress to the client (to keep them
>happy with and paying for the cleanup).
>
>Concretely, they used a 1px transparent spacer GIF in an IMG element
>to render all the horizontal rules on their site (a *very* common
>practice). By converting these to stylized HR elements, I can
>significantly improve the code and bring them a step closer to fully
>validated HTML and CSS and a step closer to properly factored content
>and presentation markup.[/color]

In you situation I would take a similar approach to that outlined by
yourself and others elsewhere in this thread and use
<div class="hr"><hr></div>

hr {display: none;}
div.hr {border-top: 1px solid black; ...etc... }

It's a hack but IE has forced our hand.
[color=blue]
>If my only option is to eliminate HR elements, I am forced to identify
>what other content element the rule is supposed to be decorating.
>Worse, this decision may require customer involvement if the
>identified object is not obvious, changes the visual display, or
>requires changes to the source content or its pre-processing.[/color]

But that process may help to increase the amount of structure built
into the document. By identifying separate topics and defining them
with <div>s, you can see where future revisions to the generation
process can split the document more effeiceintly. You can also see
where heading elements may need to be added at the start of sections,
or where they are currently being misused. In the long term such an
exrcise may be rewarding.
[color=blue]
>The bottom line is that lowering barriers to converting existing HTML
>to well structured, fully compliant HTML and CSS is good for everyone
>(especially CSS sticklers :oD ). And, well defined, consistently
>rendered HR elements definitely lower the barrier.[/color]

The default rendering of an HTML element can not be defined.

The barrier in this case is IE, not the spec.
[color=blue][color=green]
>> What does it mean to
>> change the topic three times in succession with no intervening
>> content?[/color]
>
>What it means is it was a quick way to demonstrate the air gap above
>and below IE6 horizontal rules (although I'm sure you already
>recognize that the meaning of any particular content shouldn't affect
>its rendering). ;o)[/color]

Ah, this is why real examples are helpful. When I saw <hr><hr><hr> I
thought that perhaps you were trying to make a divider composed of
three narrow lines of differing colours.
[color=blue]
>A more semantically meaningful example would have been
>"<div>above</div><hr><div>below</div>", but I was afraid the gap may
>have been mistaken as an artifact of the font descender area.[/color]

Setting background-color or borders on your test case eliminates that
possiblity. Setting borders eliminates the possibility of it being
margin collapsing as well.
[color=blue]
>Since you asked, it would be perfectly reasonable for a document with
>a large number of dynamically generated sections (I think you called
>them "topics") to have one or more empty sections. If HR elements
>separate sections, two consecutive empty sections would yield the
><hr><hr><hr> example.[/color]

From an aesthetic point of view I would say that whatever was
dynamically generating that document was flawed. It should only
include the <hr> if the section is not empty. But once that step has
been made the next step - to getting rid of the <hr> and setting a
border-bottom is remarkably small.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

mark.moore@notlimited.com (Mark Moore) wrote:
[color=blue]
>Steve Pugh <steve@pugh.net> wrote in message news:<9jm7e0h4qg27l278oatih2kgctjpj67aua@4ax.com>. ..[color=green]
>> <div style="display: table-row">
>> <div style="display: table-cell; width: 100px; border: 1px
>> solid red;">Cell 1</div>
>> <div style="display: table-cell; width: 100px; border: 1px
>> solid red;">Cell 2</div>
>> </div>
>> <div style="display: table-row">
>> <div style="display: table-cell; width: 200px; border: 1px
>> solid red;">Cell 3</div>
>> </div>[/color]
>
>Steve, I gotta say, that's the coolest trick I've seen all week. I'd
>seen display: table-cell in the docs, but didn't have time to
>understand how it might be useful.[/color]

It would be cool if it worked the way I thought it did. Opera 7.51 is
my default browser, I quickly looked at my example in that and saw
that all was good. As O7.51 has good CSS support I assumed that I was
right. But as other browsers with good CSS support differ I'm now
regretting posting without checking in more depth.
[color=blue]
>Steve Pugh <steve@pugh.net> wrote in message news:<38a8e0lj9q9l8kq1lrpdb1ol8snh1cfrdj@4ax.com>. ..[color=green]
>> Claire Tucker <fake@invalid.com> wrote:[/color]
>[snip][color=green][color=darkred]
>> > .---------------------------+-------------.
>> > | Cell 1 | Cell 2 |
>> > +---------------------------+-------------+
>> > | Cell 3 |
>> > '---------------------------'[/color][/color]
>[snip][color=green]
>>
>> Hmm, Opera 7.51 honours the specified widths but Opera 7.23 and
>> Firefox 0.8 act as you describe.[/color]
>
>Mozilla 1.7 renders this way as well (wondering to myself, "Is FF0.8
>the same as Moz1.7?").[/color]

They both use very similar versions of the Gecko rendering engine.
[color=blue][color=green]
>> The spec avoids responsibility for which is the correct rendering:
>> "Cells may span several rows or columns. (Although CSS 2.1 doesn't
>> define how the number of spanned rows or columns is determined, a user
>> agent may have special knowledge about the source document; a future
>> version of CSS may provide a way to express this knowledge in CSS
>> syntax.)"[/color]
>
>Not so fast...
>
>Now that I'm looking at the CSS2.1 more closely, your case seems to be
>clearly specified, and all three implementations render correctly
>formed tables (with one exception I'll get to a little later).
>
>According to section 17.2.1:
>
><BLOCKQUOTE cite="http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes">
><P>If the parent P of a 'table-row' element T is not a 'table',
>'inline-table', 'table-header-group', 'table-footer-group' or
>'table-row-group' element, an object corresponding to a 'table'
>element will be generated between P and T. This object will span all
>consecutive siblings (in the document tree) of T that require a
>'table' parent: 'table-row', 'table-row-group', 'table-header-group',
>'table-footer-group', 'table-column', 'table-column-group', and
>'table-caption'. T and T's siblings may also be anonymous 'table-row'
>objects generated by rule 1.</P>
></BLOCKQUOTE>
>
>Since both your outer most DIV's are table-row elements, their parent
>is not a table or inline-table element, *and* they are consecutive,
>the UA *must* generate an anonymous table element that spans them
>both. One 2x2 table with three cells should be rendered.[/color]

Ah, but should the third cell span the width of the first two or only
the width of the first one. I don't see how the passage you quote
helps in that respect. Any resolution seems to lead back to the
passage I quoted.

[snip strange Opera detail - interesting, however I have nothing to
add]
[color=blue]
>Did the construction of anonymous tables change between CSS1 and
>CSS2.1?[/color]

CSS1 really didn't have any of this sort of stuff in at all. The
questions about differences between CSS2 and CSS2.1 is pertinant and
explains many of the CSS rendering differences in recent releases of
Opera.
[color=blue]
>If so, how does a UA distinguish between CSS1 and CSS2.1?[/color]

They don't. This is a problem as CSS2 was not 100% backwards
compatible to CSS1 and CSS2.1 is not 100% backwards compatible to
CSS2.
[color=blue]
>Maybe Opera's behavior is more correct assuming HTML with no explicit
>STYLE element should be rendered using CSS1 rules.[/color]

Not as far as I can tell.
[color=blue]
>Finally, if you want your original code to work the way you liked,
>simply insert anything that's A) empty, and B) is not table-ish
>('table-row', 'table-row-group', 'table-header-group',
>'table-footer-group', 'table-column', 'table-column-group',
>'table-caption', or 'table-cell') between the rows.[/color]

That falls into the category of "redundant" markup that Claire was
complaining about. It would be nice not to need such hacks.

In general CSS tables are useless for the WWW beacuse IE does not
support them. When I have considered using them for projects where I
can afford to let IE users see a less than ideal layout I've never
used more than one table-row (i.e. I've used them to create columns
not grids). So this is an interesting diversion but nothing more at
present (so chances are that next week I'll need to do exactly
this...)

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>

On Fri, 2 Jul 2004, Brian wrote:
[color=blue]
> Alan J. Flavell wrote:
>[color=green]
> > Should have been like that from the start, but (if I heard it right)
> > the NCSA team were too stubborn to change what they'd already
> > implemented.[/color]
>
> That's really discouraging. There seems to be a regular occurence of a
> company using its dominance to dictate a standard that they do not own.[/color]

Right from the early days, I'd been reading discussions which pointed
out the compatility benefit of defining new elements as <element>text
content</element>, and having a general rule that any client agent
which didn't recognise the new <element> was supposed to ignore the
opening and closing tags, and simply render the content as part of the
displayed data.

Where, on the other hand, a new construct was defined as

<element wibble="some text">

(either as a self-closing element like <img> turned out to be, or
as a container element as the <script> element turned out to be), then
the renderer which hadn't implemented the <element> would have no
idea what to do with its "wibble" attribute; conversely, it would
ignre the <script> and </script> tags and render the content, which
wasn't exactly a neat idea, and led to those horrible "HTML comment"
ruses, in the early days of <script>.

So it all seemed to make sense. You'd almost have thought that the
NCSA team (I find it hard to believe they'd never met these ideas in
discussions) went out of their way to avoid achieving any kind of
compatibility with non-supporting browsers, no?
[color=blue][color=green]
> > HTML/3.0 (deceased) would have implemented this with the "fig"
> > element.[/color]
>
> I'm afraid to learn about HTML 3.0 because I don't want to know what
> could have been.[/color]

There were plenty of good ideas in there at the time; but also a fair
bit of what, with hindsight, we would now consider to be crud, and/or
presentational stuff that ought to have been in a stylesheet instead.

Oh, and the character representation model hadn't yet matured to the
point that it reached in RFC2070, which re-surfaced in HTML4 and which
we are now finally able - for the most part - to use with some kind of
confidence with reasonably current browsers.

And how _could_ 3.2 be so much less than 3.0 was supposed to have
been?

Sorry, I *do* seem to be re-fighting old battles here. I best stop
now, but you did tweak a bit of a sore nerve.

On Fri, 02 Jul 2004 17:15:33 GMT, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
>Alan J. Flavell wrote:[/color]
[color=blue][color=green]
>> On Thu, 1 Jul 2004, Brian wrote:[color=darkred]
>>> <img src="chirac.jpg">French president Jacques Chirac declared that
>>> NATO should <em>not</em> send troops to Iraq.</img>[/color][/color][/color]
[color=blue][color=green]
>> Should have been like that from the start, but (if I heard it right)
>> the NCSA team were too stubborn to change what they'd already
>> implemented.[/color][/color]
[color=blue]
>That's really discouraging. There seems to be a regular occurence of a
>company using its dominance to dictate a standard that they do not own.[/color]

Well, the "The National Center for Supercomputing Applications" is not a
"company" really :-)

Look into the activities of the "University of Illinois" and you can
find more info on NCSA.

<http://archive.ncsa.uiuc.edu/About/NCSA/>

More closely it all boiled down to one single person 'Mark Andreesen' of
later Netscape fame, who was somehow invited to NCSA to do some to me
unknown work there; apparently spent most of his time to write code for
the Mosaic web browser; personally "invented and implemented" the empty
<IMG> element into Mosaic; went on to present it to the WWW community of
that time; got suggestions for changes, but refused those with the
argument that all code was already written and he did not want to spend
time to change any of it.

I would lable the current status of <IMG> as a result of stubborn
personal pride more than being the result of a company wanting to "set
standards". :-)

--
Rex

Jan Roland Eriksson <jrexon@newsguy.com> wrote:
[color=blue]
> More closely it all boiled down to one single person 'Mark Andreesen' of
> later Netscape fame...[/color]

[snip]
[color=blue]
> I would lable the current status of <IMG> as a result of stubborn
> personal pride more than being the result of a company wanting to "set
> standards". :-)[/color]

So it's just like everything else to do with the WWW then. Why single
out Andreesen for your contempt? We can see exactly the same process
happening now with [insert name of pet W3C bogeyman here], doing
everything he can to convince people that CSS shouldn't be allowed to
develop useful content manipulation or hyperlinking features.

You can have all the CSS properties you want, as long as they are only
unimplementable font-related properties or pretty colours.

--
"Elemental, my dear Benton."

On Sat, 3 Jul 2004, Jan Roland Eriksson wrote:
[...][color=blue][color=green]
> >Alan J. Flavell wrote:[/color]
>[color=green][color=darkred]
> >> Should have been like that from the start, but (if I heard it right)
> >> the NCSA team were too stubborn to change what they'd already
> >> implemented.[/color][/color][/color]
[..][color=blue]
> More closely it all boiled down to one single person 'Mark Andreesen' of
> later Netscape fame,[/color]

I suppose I should apologise to NCSA for the misplaced emphasis when I
said "NCSA team". For those who weren't familiar with this
background, I really shouldn't give them the impression that I was
blaming the NCSA as a whole for some of the things that their Mosaic
team (later "Mosaic Communications Corp" aka Netscape) did.
[color=blue]
> that time; got suggestions for changes, but refused those with the
> argument that all code was already written and he did not want to spend
> time to change any of it.[/color]

(Which incidentally set the precedent for their later imposition of an
already-implemented <frame> design, instead of addressing the serious
concerns which were raised when they aired what they had done. But
let's not go there today...)
[color=blue]
> I would lable the current status of <IMG> as a result of stubborn
> personal pride more than being the result of a company wanting to "set
> standards". :-)[/color]

Seems to me that it's the same principle. Someone who was in a
dominant position (in this case, thanks to the Mosaic browser) was
able to release a new "product" to its admiring user base, despite it
failing some important tests of acceptability/compatibility which
could well have been resolved if the design had received appropriate
peer review.

Ho hum.

Wolfgang Wildeblood wrote:[color=blue]
> Jan Roland Eriksson <jrexon@newsguy.com> wrote:
>[color=green]
>> I would lable the current status of <IMG> as a result of stubborn
>> personal pride more than being the result of a company wanting to
>> "set standards". :-)[/color]
>
> We can see exactly the same process happening now with [insert name
> of pet W3C bogeyman here], doing everything he can to convince people
> that CSS shouldn't be allowed to develop useful content manipulation
> or hyperlinking features.[/color]

That's backwards. You're complaining that the wg will *not* implement
features you want.[1] In the case of <img>, the problem was that Mosaic
*did* implement a feature, but implemented it badly.

[1] Being unfamiliar with the features you want implemented, I decline
to comment on them.

--
Brian (remove ".invalid" to email me)

Brian <usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> Wolfgang Wildeblood wrote:
>[color=green]
> > Jan Roland Eriksson <jrexon@newsguy.com> wrote:
> >[color=darkred]
> >> I would lable the current status of <IMG> as a result of stubborn
> >> personal pride more than being the result of a company wanting to
> >> "set standards". :-)[/color]
> >
> > We can see exactly the same process happening now with [insert name
> > of pet W3C bogeyman here], doing everything he can to convince people
> > that CSS shouldn't be allowed to develop useful content manipulation
> > or hyperlinking features.[/color]
>
> That's backwards. You're complaining that the wg will *not* implement
> features you want.[1] In the case of <img>, the problem was that Mosaic
> *did* implement a feature, but implemented it badly.[/color]

That's not what I meant. I was merely trying to chide Roland for
placing all the blame on the leader, when the sheep are just as
guilty.

My message was in the sentences you snipped - that nothing has
changed. In the case of CSS, what you call "the wg" basically means
Hickson says, everyone else goes along with him. Which is the
situation Roland was complaining about with his personal bogeyman,
Andreesen, ten years ago.

Regarding the (yet another) discussion of IMG, that seems to have
taken on the character of a grudge that the CIWAHians are determined
to bear forever. There is no objective test that proves IMG is
"implemented badly" as you claim it is.

From an "ecological" viewpoint, it is one of, if not the, most
spectacularly successful markup elements there is. If we could scan
all the traffic on the network - Echelon style - we would probably
discover "<img" to be among the most common character sequences being
transmitted. Right up there with "the". People use it because it works
reliably, unlike OBJECT which people avoid because they consider it
unreliable.

What's the big problem with IMG? Being an empty element it offends
their sense of symmetry, as do HR and BR. Where were their precious
aesthetic sensibilities when Connoly was getting away with <P> as a
"paragraph separator", instead of:-

<p>Always mark the beginning AND END of paragraphs.</p>

But Connolly wasn't Andreesen so they just turn a blind eye to his
sin. You and I, Brian, as with all the people who arrived later, are
blameless. We should not involve ourselves in the personal grudges of
the old timers.

And if you really wanted alternative content, when images are not
rendered:-

<noimage>Any complexity of content allowed in here.</noimage>

- would seem the obvious solution, rather than the approach taken by
OBJECT. At least it would have had the advantage of consistency with
NOFRAMES, NOSCRIPT, NOEMBED.

[color=blue]
> [1] Being unfamiliar with the features you want implemented, I decline
> to comment on them.[/color]

We could start with some basics that should have been there right from
the start:

*[lang="en-US"] {
content-replace: search(color) replace(colour);
}

But seriously, I was referring to Hickson's often stated antipathy to
having linking controlled by CSS, as Opera does for XML, recognized by
the W3C version of CSS. May as well tell the tide not to rise.

--
"May I introduce Her Royal Highness, Princess Josephine of Tardis."
(I love these old Dr Who repeats :-) )

Wolfgang Wildeblood wrote:
[color=blue]
> I was merely trying to chide Roland for placing all the blame on
> the leader, when the sheep are just as guilty.[/color]

It sounds like you've an axe to grind. Good luck with that.
[color=blue]
> Regarding the (yet another) discussion of IMG, that seems to have
> taken on the character of a grudge that the CIWAHians are
> determined to bear forever.[/color]

Echos of a certain occasional participant in these parts. I'm sure
that "CIWAHians" is meant to be an insult, but I can't quite make out how.
[color=blue]
> There is no objective test that proves IMG is "implemented badly"
> as you claim it is.[/color]

Naturally, since there is no competing HTML with IMG as an element
that is not closed.
[color=blue]
> From an "ecological" viewpoint, it is one of, if not the, most
> spectacularly successful markup elements there is.[/color]

That tells us nothing about whether it could have or should have been
implemented differently.
[color=blue]
> What's the big problem with IMG? Being an empty element it offends
> their sense of symmetry, as do HR and BR.[/color]

I've already told you my problem with it. You ignored that in favor of
a vague ad hominem attack. Ho hum.
[color=blue]
> And if you really wanted alternative content, when images are not
> rendered:-
>
> <noimage>Any complexity of content allowed in here.</noimage>[/color]

And that would do what, exactly?
[color=blue]
> - would seem the obvious solution,[/color]

That doesn't seem very obvious to me.
[color=blue]
> But seriously[/color]

Come, man! You're not being serious at all!

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Brian <usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> Wolfgang Wildeblood wrote:
>[color=green]
> > Regarding the (yet another) discussion of IMG, that seems to have
> > taken on the character of a grudge that the CIWAHians are
> > determined to bear forever.[/color]
>
> Echos of a certain occasional participant in these parts. I'm sure
> that "CIWAHians" is meant to be an insult, but I can't quite make out how.[/color]

(You'll never see him again, you'll have to make do with me.) And you
might be sure, but you'd be wrong - CIWAHians isn't an insult, it just
describes where to find them. Next you'll be claiming that words like
"Americans" or "Australians" are insults. Really Brian, get a grip!

("Motherfucking cocksucker" is an insult. Search CIWAH for that
phrase, and you'll find AndKon's classic statement of Usenet
etiquette.)

[color=blue][color=green]
> > There is no objective test that proves IMG is "implemented badly"
> > as you claim it is.[/color]
>
> Naturally, since there is no competing HTML with IMG as an element
> that is not closed.[/color]

Huh? Do you mean "empty", not "closed" don't you? Yes there is. The
W3C's great contribution, HTML4, with OBJECT. It's a direct
competitor.

[color=blue][color=green]
> > From an "ecological" viewpoint, it is one of, if not the, most
> > spectacularly successful markup elements there is.[/color]
>
> That tells us nothing about whether it could have or should have been
> implemented differently.[/color]

It tells us everything. OBJECT is different, and more trouble than
it's worth. I know this is true (OBJECT is more trouble than it's
worth), because Mr Ray told me so. (Nice snipping, BTW.)

Really, you should go back and read the CIWAH archives to see just how
much time they've invested into whingeing about IMG. And it's the old
timers who like to boast that they "were there" at the time, who
whinge the most. Yet they always point the finger at Someone Else,
usually Mr Andreesen. These recurring discussions of IMG tell a lot
more about their characters than they do about markup.

[color=blue][color=green]
> > But seriously[/color]
>
> Come, man! You're not being serious at all![/color]

Well, I have many faults, but one I don't have is taking myself too
seriously.

--
More Nat, less Mel.
(Sig carried over from other newsgroup, to help the Echelon-bot track
me. If you understand it, get a job.)

Wolfgang Wildeblood wrote:[color=blue]
> Brian wrote:
>[color=green]
>> Wolfgang Wildeblood wrote:
>>[color=darkred]
>>> the CIWAHians[/color]
>>
>> Echos of a certain occasional participant in these parts.[/color]
>
> (You'll never see him again, you'll have to make do with me.)[/color]

Is this merely a change of username, then?
[color=blue][color=green][color=darkred]
>>> There is no objective test that proves IMG is "implemented
>>> badly" as you claim it is.[/color]
>>
>> Naturally, since there is no competing HTML with IMG as an
>> element that is not closed.[/color]
>
> Huh? Do you mean "empty", not "closed" don't you?[/color]

Yes, I meant empty. Sorry for the communication breakdown.
[color=blue]
> Yes there is. The W3C's great contribution, HTML4, with OBJECT.
> It's a direct competitor.[/color]

Which came along much later, and has other disadvantages besides.
[color=blue]
> OBJECT is different, and more trouble than it's worth.[/color]

With attributes like "classid", "codebase", and "standby", it sure
looks that way. But now you're clouding up the discussion. All we were
suggesting is that

<IMG src="crabspider.jpg">The male Crab Spider (<I>Thomisus
spectabilis</I>) is <EM>smaller</EM> than the female.</IMG>

provides more flexibility and better markup than what we have, namely:

<IMG src="crabspider.jpg" alt="The male Crab Spider (Thomisus
spectabilis) is smaller than the female.">
[color=blue]
> Really, you should go back and read the CIWAH archives to see just
> how much time they've invested into whingeing about IMG.[/color]

Really, I've been here for a few years now, and I don't recall folks
spending an inordinate amount of time on the subject.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

On Mon, 5 Jul 2004, Brian wrote:
[color=blue]
> Wolfgang Wildeblood wrote:
>[color=green]
> > Really, you should go back and read the CIWAH archives to see just
> > how much time they've invested into whingeing about IMG.[/color]
>
> Really, I've been here for a few years now, and I don't recall folks
> spending an inordinate amount of time on the subject.[/color]

<rhetorical>
Isn't it strange how those who complain most about the extent of the
discussion are often those who insist on prolonging it unnecessarily?
</>

wolfgangwildeblood@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9f17fcb.0407050920.19b079c7@posting.google. com>...[color=blue]
> Brian <usenet3@julietremblay.com.invalid> wrote:
>[color=green]
> > Wolfgang Wildeblood wrote:
> >[color=darkred]
> > > Regarding the (yet another) discussion of IMG, that seems to have
> > > taken on the character of a grudge that the CIWAHians are
> > > determined to bear forever.[/color]
> >
> > Echos of a certain occasional participant in these parts. I'm sure
> > that "CIWAHians" is meant to be an insult, but I can't quite make out how.[/color]
>
> (You'll never see him again, you'll have to make do with me.) And you
> might be sure, but you'd be wrong - CIWAHians isn't an insult, it just
> describes where to find them. Next you'll be claiming that words like
> "Americans" or "Australians" are insults. Really Brian, get a grip!
>
> ("Motherfucking cocksucker" is an insult. Search CIWAH for that
> phrase, and you'll find AndKon's classic statement of Usenet
> etiquette.)
>[/color]

Ah, the good old days. My favorite insult was this though:
http://andkon.com/xtra/award.jpg
[color=blue]
>[color=green][color=darkred]
> > > There is no objective test that proves IMG is "implemented badly"
> > > as you claim it is.[/color]
> >
> > Naturally, since there is no competing HTML with IMG as an element
> > that is not closed.[/color]
>
> Huh? Do you mean "empty", not "closed" don't you? Yes there is. The
> W3C's great contribution, HTML4, with OBJECT. It's a direct
> competitor.
>
>[color=green][color=darkred]
> > > From an "ecological" viewpoint, it is one of, if not the, most
> > > spectacularly successful markup elements there is.[/color]
> >
> > That tells us nothing about whether it could have or should have been
> > implemented differently.[/color]
>
> It tells us everything. OBJECT is different, and more trouble than
> it's worth. I know this is true (OBJECT is more trouble than it's
> worth), because Mr Ray told me so. (Nice snipping, BTW.)
>
> Really, you should go back and read the CIWAH archives to see just how
> much time they've invested into whingeing about IMG. And it's the old
> timers who like to boast that they "were there" at the time, who
> whinge the most. Yet they always point the finger at Someone Else,
> usually Mr Andreesen. These recurring discussions of IMG tell a lot
> more about their characters than they do about markup.
>
>[color=green][color=darkred]
> > > But seriously[/color]
> >
> > Come, man! You're not being serious at all![/color]
>
> Well, I have many faults, but one I don't have is taking myself too
> seriously.[/color]

mozillacensorsme@yahoo.com (MozillaCensorsMe) wrote in message news:<39665a4.0407100718.14f46ffa@posting.google.c om>...[color=blue]
> wolfgangwildeblood@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9f17fcb.0407050920.19b079c7@posting.google. com>...[color=green]
> > Brian <usenet3@julietremblay.com.invalid> wrote:
> >[color=darkred]
> > > Wolfgang Wildeblood wrote:
> > >
> > > > Regarding the (yet another) discussion of IMG, that seems to have
> > > > taken on the character of a grudge that the CIWAHians are
> > > > determined to bear forever.
> > >
> > > Echos of a certain occasional participant in these parts. I'm sure
> > > that "CIWAHians" is meant to be an insult, but I can't quite make out how.[/color]
> >
> > (You'll never see him again, you'll have to make do with me.) And you
> > might be sure, but you'd be wrong - CIWAHians isn't an insult, it just
> > describes where to find them. Next you'll be claiming that words like
> > "Americans" or "Australians" are insults. Really Brian, get a grip!
> >
> > ("Motherfucking cocksucker" is an insult. Search CIWAH for that
> > phrase, and you'll find AndKon's classic statement of Usenet
> > etiquette.)[/color]
>
> Ah, the good old days.[/color]

Indeed. "I only call someone a motherfucking cocksucker if they are
just casually acting in a motherfucking or cocksucking way." It still
boggles me what you meant.

I'm probably better off not knowing.

[color=blue]
> My favorite insult was this though:
> http://andkon.com/xtra/award.jpg[/color]

Lamer.

[color=blue][color=green][color=darkred]
> > > > There is no objective test that proves IMG is "implemented badly"
> > > > as you claim it is.
> > >
> > > Naturally, since there is no competing HTML with IMG as an element
> > > that is not closed.[/color]
> >
> > Huh? Do you mean "empty", not "closed" don't you? Yes there is. The
> > W3C's great contribution, HTML4, with OBJECT. It's a direct
> > competitor.
> >
> >[color=darkred]
> > > > From an "ecological" viewpoint, it is one of, if not the, most
> > > > spectacularly successful markup elements there is.
> > >
> > > That tells us nothing about whether it could have or should have been
> > > implemented differently.[/color]
> >
> > It tells us everything. OBJECT is different, and more trouble than
> > it's worth. I know this is true (OBJECT is more trouble than it's
> > worth), because Mr Ray told me so. (Nice snipping, BTW.)
> >
> > Really, you should go back and read the CIWAH archives to see just how
> > much time they've invested into whingeing about IMG. And it's the old
> > timers who like to boast that they "were there" at the time, who
> > whinge the most. Yet they always point the finger at Someone Else,
> > usually Mr Andreesen. These recurring discussions of IMG tell a lot
> > more about their characters than they do about markup.
> >
> >[color=darkred]
> > > > But seriously
> > >
> > > Come, man! You're not being serious at all![/color]
> >
> > Well, I have many faults, but one I don't have is taking myself too
> > seriously.[/color][/color]

Learn to snip, Andras, you bloody dickhead!

wolfgangwildeblood@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9f17fcb.0407130610.60f00423@posting.google. com>...[color=blue]
> mozillacensorsme@yahoo.com (MozillaCensorsMe) wrote in message news:<39665a4.0407100718.14f46ffa@posting.google.c om>...[color=green]
> > wolfgangwildeblood@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9f17fcb.0407050920.19b079c7@posting.google. com>...[color=darkred]
> > > Brian <usenet3@julietremblay.com.invalid> wrote:
> > >
> > > > Wolfgang Wildeblood wrote:
> > > >
> > > > > Regarding the (yet another) discussion of IMG, that seems to have
> > > > > taken on the character of a grudge that the CIWAHians are
> > > > > determined to bear forever.
> > > >
> > > > Echos of a certain occasional participant in these parts. I'm sure
> > > > that "CIWAHians" is meant to be an insult, but I can't quite make out how.
> > >
> > > (You'll never see him again, you'll have to make do with me.) And you
> > > might be sure, but you'd be wrong - CIWAHians isn't an insult, it just
> > > describes where to find them. Next you'll be claiming that words like
> > > "Americans" or "Australians" are insults. Really Brian, get a grip!
> > >
> > > ("Motherfucking cocksucker" is an insult. Search CIWAH for that
> > > phrase, and you'll find AndKon's classic statement of Usenet
> > > etiquette.)[/color]
> >
> > Ah, the good old days.[/color]
>
> Indeed. "I only call someone a motherfucking cocksucker if they are
> just casually acting in a motherfucking or cocksucking way." It still
> boggles me what you meant.
>[/color]

Probably that it's deserved.
[color=blue]
> I'm probably better off not knowing.
>
>[color=green]
> > My favorite insult was this though:
> > http://andkon.com/xtra/award.jpg[/color]
>
> Lamer.
>
>[color=green][color=darkred]
> > > > > There is no objective test that proves IMG is "implemented badly"
> > > > > as you claim it is.
> > > >
> > > > Naturally, since there is no competing HTML with IMG as an element
> > > > that is not closed.
> > >
> > > Huh? Do you mean "empty", not "closed" don't you? Yes there is. The
> > > W3C's great contribution, HTML4, with OBJECT. It's a direct
> > > competitor.
> > >
> > >
> > > > > From an "ecological" viewpoint, it is one of, if not the, most
> > > > > spectacularly successful markup elements there is.
> > > >
> > > > That tells us nothing about whether it could have or should have been
> > > > implemented differently.
> > >
> > > It tells us everything. OBJECT is different, and more trouble than
> > > it's worth. I know this is true (OBJECT is more trouble than it's
> > > worth), because Mr Ray told me so. (Nice snipping, BTW.)
> > >
> > > Really, you should go back and read the CIWAH archives to see just how
> > > much time they've invested into whingeing about IMG. And it's the old
> > > timers who like to boast that they "were there" at the time, who
> > > whinge the most. Yet they always point the finger at Someone Else,
> > > usually Mr Andreesen. These recurring discussions of IMG tell a lot
> > > more about their characters than they do about markup.
> > >
> > >
> > > > > But seriously
> > > >
> > > > Come, man! You're not being serious at all!
> > >
> > > Well, I have many faults, but one I don't have is taking myself too
> > > seriously.[/color][/color]
>
> Learn to snip, Andras, you bloody dickhead![/color]

As I've said before, I hated it when people tried to sneak a fast one
by me when they snipped important details and made them seem
unimportant.

<HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

re: <HR> Style Bug in IE6

Similar HTML / CSS bytes

/bytes/development

/bytes/it

/bytes/about