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">
<!--
hr {
margin: auto;
text-align:center;
width: 80%;
}
..redrule-1 {
border: none;
border-bottom:
1px solid red;
}
..redrule-2 {
border: none;
height: 1px;
color: red;
background-color: red;
}
-->
</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> 34  10969 
Mark Moore wrote: It looks like there's a pretty serious CSS bug in IE6
*A* bug? You think there's only one? How quaint.
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.
Could be. Did you Google for IE/Win css bugs? What did you come up with?
Does anyone know if this is a known bug at MS? If you know of one,
post the related bug ID.
Huh? Since when does MS publicly track bugs?
Try this code:
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/
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" <ma********@notlimited.com> wrote in message
news:13**************************@posting.google.c om... 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">
<!--
hr {
margin: auto;
text-align:center;
width: 80%;
}
.redrule-1 {
border: none;
border-bottom:
1px solid red;
}
.redrule-2 {
border: none;
height: 1px;
color: red;
background-color: red;
}
-->
</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>
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. Did you Google for IE/Win css bugs?
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
Since when does MS publicly track bugs?
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.)
Try this code:
No. Instead, post a url.
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.)
And don't cross-post unless it's really
called for.
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" <ne**@terrainformatica.com> wrote: 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)
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"
In such circumstances UA is free to choose any suitable value.
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.
2. HRs, TABLEs and IMGs are special cases as their traditional shapes and
rendering behavior cannot be defined in pure CSS.
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 <st***@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">
<!--
hr { /*BUGBUG: This doesn't work for IE6 (or earlier?) */
margin: auto; /* need margin auto (not margin: 0) so the block
element will center if width less than 100% */
}
div.divider {
height: 1px; /* pick your favorite height and color */
background-color: black;
margin: auto; /* so width < 100% is centered */
}
div.divider hr { /* for CSS1 browsers */
display: none;
}
div.divider * { /* for CSS2 browsers */
display: none;
}
-->
</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, ma********@notlimited.com (Mark Moore)
wrote: 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.
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: Brian and Spartanicus, I can't believe how rude your reponses are.
http://www.catb.org/~esr/faqs/smart-...tml#not_losing
Instead, post a url.
No, thank you.
If you cannot be bothered to upload a test case, then I cannot be
bothered to help.
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.
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/
"Andrew Fedoniouk" <ne**@terrainformatica.com> wrote in message news:<s7rEc.909175$Pk3.261780@pd7tw1no>... 1. To be precise... what does it mean yours
hr { margin: auto; } exactly ?
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. 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.
[snip] What little semantic meaning the <hr> has is that it serves to
indicate a change of topic.
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. This is of course the OP's problem and the best solution is to not use
HRs for such purposes.
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. What does it mean to
change the topic three times in succession with no intervening
content?
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" <ne**@terrainformatica.com> wrote in message news:<s7rEc.909175$Pk3.261780@pd7tw1no>... 1. To be precise... what does it mean yours
hr { margin: auto; } exactly ?
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. 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.
[snip] What little semantic meaning the <hr> has is that it serves to
indicate a change of topic.
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. This is of course the OP's problem and the best solution is to not use
HRs for such purposes.
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 <st***@pugh.net> wrote in message news:<ge********************************@4ax.com>. .. What does it mean to
change the topic three times in succession with no intervening
content?
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 <fa**@invalid.com> wrote in message news:<9v********************************@4ax.com>. .. 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?
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?
One reason for the awkwardness here is that HR is, at least to a
certain extent, a presentational element.
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?
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.
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: Please excuse my ignorance, but what or who is an OP?
op = original post | original poster, i.e., author of original post
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
Mark Moore wrote: Claire Tucker wrote...
One reason for the awkwardness here is that HR is, at least to a
certain extent, a presentational element.
If HR elements are purely presentational, shouldn't they be
excluded from valid HTML markup?
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. 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.
This presupposes there is an existing element to decorate with a
top or bottom border.
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/
Sorry for the double post. I'm not sure why that happened. -MM
On Thu, 01 Jul 2004 19:09:14 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: Mark Moore wrote:
Claire Tucker wrote...
One reason for the awkwardness here is that HR is, at least to a
certain extent, a presentational element.
If HR elements are purely presentational, shouldn't they be
excluded from valid HTML markup?
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.
<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: Brian wrote:
<hr> is a bit flawed from a markup point of view, since it
doesn't mark up anything. It is an empty element.
<img> marks up nothing as well.
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
<us*****@julietremblay.com.invalid> wrote: Neal wrote: <img> marks up nothing as well.
But even there, it would have been better if were not empty, and the
contents took the place of the alt "tag." ;-)
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---------
<!--
In the following HTML, the embedded STYLE element can be used to
workaround an issue with IE6's rendering of HR elements with "small"
top or bottom margins (i.e. margin less than ~1em). You'll most
likely want to incorporate its content into your external style sheet.
The inline style attributes in the sample code (e.g. style="...")
should not be included in production HTML. They're included here to
help visually demonstrate the issue and the workaround when viewed in
IE6.
-->
<!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">
<!--
hr {
margin: auto; /* eliminate top and bottom margins and center when
width < 100% */
}
div.hr {
border: 1px gray inset;
margin: auto; /* so width < 100% is centered */
}
div.hr hr { /* for CSS1 browsers */
display: none;
}
div.hr * { /* for CSS2 browsers */
display: none;
}
-->
</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>
On Thu, 1 Jul 2004, Brian wrote: <img src="chirac.jpg">French president Jacques Chirac declared that
NATO should <em>not</em> send troops to Iraq.</img>
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: On Thu, 1 Jul 2004, Brian wrote:
<img src="chirac.jpg">French president Jacques Chirac declared that
NATO should <em>not</em> send troops to Iraq.</img>
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.
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.
HTML/3.0 (deceased) would have implemented this with the "fig"
element.
I'm afraid to learn about HTML 3.0 because I don't want to know what
could have been.
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.
More of the same. grrr
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?!?
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
On Fri, 2 Jul 2004, Brian wrote: Alan J. Flavell wrote:
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.
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.
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? HTML/3.0 (deceased) would have implemented this with the "fig"
element.
I'm afraid to learn about HTML 3.0 because I don't want to know what
could have been.
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
<us*****@julietremblay.com.invalid> wrote: Alan J. Flavell wrote:
On Thu, 1 Jul 2004, Brian wrote: <img src="chirac.jpg">French president Jacques Chirac declared that
NATO should <em>not</em> send troops to Iraq.</img>
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.
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.
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 <jr****@newsguy.com> wrote: More closely it all boiled down to one single person 'Mark Andreesen' of
later Netscape fame...
[snip]
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". :-)
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:
[...] Alan J. Flavell wrote: 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.
[..] More closely it all boiled down to one single person 'Mark Andreesen' of
later Netscape fame,
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.
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.
(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...)
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". :-)
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: Jan Roland Eriksson <jr****@newsguy.com> wrote:
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". :-)
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.
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 <us*****@julietremblay.com.invalid> wrote: Wolfgang Wildeblood wrote:
Jan Roland Eriksson <jr****@newsguy.com> wrote:
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". :-)
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.
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.
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.
[1] Being unfamiliar with the features you want implemented, I decline
to comment on them.
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: I was merely trying to chide Roland for placing all the blame on
the leader, when the sheep are just as guilty.
It sounds like you've an axe to grind. Good luck with that.
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.
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.
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.
What's the big problem with IMG? Being an empty element it offends
their sense of symmetry, as do HR and BR.
I've already told you my problem with it. You ignored that in favor of
a vague ad hominem attack. Ho hum.
And if you really wanted alternative content, when images are not
rendered:-
<noimage>Any complexity of content allowed in here.</noimage>
And that would do what, exactly?
- would seem the obvious solution,
That doesn't seem very obvious to me.
But seriously
Come, man! You're not being serious at all!
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
On 3 Jul 2004 22:21:53 -0700, wo****************@yahoo.com.au
(Wolfgang Wildeblood) wrote:
What's the big problem with IMG? Being an empty element it offends
their sense of symmetry, as do HR and BR.
[snip]
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.
NOFRAMES, NOSCRIPT and NOEMBED were not around when IMG was being
added because there were no frames, scripts or embedded gubbins in
Mosaic.
What is it, exactly, that you find so distasteful about putting the
alternative content for IMG inside the IMG element as with OBJECT?
With the "alt" attribute we have a text-only alternative inside the
(albeit empty) element, so I don't see that it's such a stretch to put
the alternative text inside the element content itself.
NOSCRIPT was needed because the SCRIPT element is not intended to be
"seen" by the user, so it makes no sense for the alternative to appear
in the markup where the script is.
NOFRAMES is an interesting one since it is essentially redundant.
Netscape Navigator could easily have parsed this:
<frameset ...>
<frame ...>
<frame ...>
<frame ...>
<frame ...>
<body>
</body>
</frameset>
....by ignoring elements which are invalid in a frameset -- anything
other than FRAME and FRAMESET.
There's little point debating this now, however, since it's too late
to change this little mistake now and fortunately any browsing
situation these days will tend to have a browser available which can
properly deal with IMG in some form.
[snip!]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.
Are you suggesting that Opera has CSS properties for making a
clickable link out of any item? A quick Google search didn't turn up
anything on this, but then I wasn't really sure what to search for.
Can you provide more details?
Best regards,
-Claire
Brian <us*****@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.) 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.
--
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: Brian wrote:
Wolfgang Wildeblood wrote:
the CIWAHians
Echos of a certain occasional participant in these parts.
(You'll never see him again, you'll have to make do with me.)
Is this merely a change of username, then?
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, I meant empty. Sorry for the communication breakdown.
Yes there is. The W3C's great contribution, HTML4, with OBJECT.
It's a direct competitor.
Which came along much later, and has other disadvantages besides.
OBJECT is different, and more trouble than it's worth.
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.">
Really, you should go back and read the CIWAH archives to see just
how much time they've invested into whingeing about IMG.
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: Wolfgang Wildeblood wrote:
Really, you should go back and read the CIWAH archives to see just
how much time they've invested into whingeing about IMG.
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.
<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?
</> wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9**************************@posting.google. com>... Brian <us*****@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.)
Ah, the good old days. My favorite insult was this though:
http://andkon.com/xtra/award.jpg
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. mo**************@yahoo.com (MozillaCensorsMe) wrote in message news:<39*************************@posting.google.c om>... wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9**************************@posting.google. com>... Brian <us*****@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.)
Ah, the good old days.
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.
My favorite insult was this though:
http://andkon.com/xtra/award.jpg
Lamer. > 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.
Learn to snip, Andras, you bloody dickhead! wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9**************************@posting.google. com>... mo**************@yahoo.com (MozillaCensorsMe) wrote in message news:<39*************************@posting.google.c om>... wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote in message news:<a9**************************@posting.google. com>... Brian <us*****@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.)
Ah, the good old days.
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.
Probably that it's deserved.
I'm probably better off not knowing.
My favorite insult was this though:
http://andkon.com/xtra/award.jpg
Lamer.
> > 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.
Learn to snip, Andras, you bloody dickhead!
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Jeremy Collins |
last post by:
Hi all,
How do I specify "noshade" as the style for an <HR>
element in my style sheet?
hr {
height: 1px;
color: #EEEEEE;
????
}
|
by: Mark Moore |
last post by:
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...
|
by: Ted Mayett |
last post by:
OK. Here is a glitch, sorry if this has been mentioned before.
This is an erratic glitch. I am now up to three other people besides
myself who have been able to see this glitch. It seems it...
|
by: balakrishnan.dinesh |
last post by:
hi frnds,
In my html code, i have used <hrtag.
Im using it as "<hr color=red>", So the respective hr line color is
red in Mozila and IE browsers,
But it is not showing the color in Opera browser,...
|
by: Mich |
last post by:
Hi,
1)
i defined a html line in the aspx file like this but it's still visible::
<hr id="hr1" visible="false" />
So i defined it like this and now it's hidden:
<hr id="hr1"...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
