could not place <dl> inside <address>
Gildor Oronar
<address>
...
<dl>...</dl>
...
</address>
The dom inspector of Firefox 3.0.9 shows it parses this way:
<address>...</address>
<dl>...</dl>
The following HTML code demonstrate the case, where the <dt> element
should float
to the left as styled, but not in Firefox 3.0.9.
(a quick temporary link to the following HTML is here:
http://favorking.3322.org/test.html )
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<style type="text/css">
address {font-size: smaller;}
address dl { width: 30ex;}
address dd { text-align: right; }
address dt { float: left; }
</style>
</head>
<body>
<address>
<p>
<strong>Zhang Weiwu</strong><br/>
General Manager
</p>
<p>
Beisihuan Zhong Road No. 238 <br/>
Baiyan Building Unit 406B
</p>
<dl>
<dt>Tel:</dt>
<dd>++86 10 8231 8580 ext. 105</dd>
<dt>Email:</dt>
<dd>zhangwe...@realss.com</dd>
<dt>Skype:</dt>
<dd>zhangweiwu</dd>
<dt>Web:</dt>
<dd>www.realss.com</dd>
</dl>
</address>
</body>
</html>
My question is: is this a bug of Firefox? In my case Opera 9.64 behave
as I expected, a.k.a. <dt> floated to the left.
Or am I wrong to use <address>?
The definition of <address> on w3c is too poor to show if it should contain
the delivery or visiting address, or it can contain "address" in general
sense,
which include all contact information. The example also fail to show this:
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-structural.html#edef_structural_address
Since <address> is a block element (see XHTML 2.0 style sheet:
http://www.w3.org/TR/2004/WD-xhtml2-20040722/xhtml2-style.html#a_stylesheet
), I took it as "address" in general, which is all contact information,
thus should
be able to hold <dl>.
C A Upsdell
> If I place a <dl> element in <address>, like this:
> <address>
> ...
> <dl>...</dl>
> ...
> </address>
>
> http://www.w3.org/TR/2004/WD-xhtml2-20040722/xhtml2-style.html#a_stylesheet
<address> is defined as inline in the HTML specs, not block.
Your DOCTYPE specifies HTML and quirks mode. In quirks mode, browser
differences are more likely.
The URL you cite is an XHTML 2 working document, and therefore is
irrelevant to this issue.
Lars Eighner
talented Gildor Oronar broadcast on
comp.infosystems.www.authoring.stylesheets:
> If I place a <dl> element in <address>, like this:
><address>
> ...
><dl>...</dl>
> ...
></address>
This is not valid.
> The dom inspector of Firefox 3.0.9 shows it parses this way:
><address>...</address>
><dl>...</dl>
Browsers can do as they please with broken markup.
> The following HTML code demonstrate the case, where the <dt> element
> should float
> to the left as styled, but not in Firefox 3.0.9.
> (a quick temporary link to the following HTML is here:
> http://favorking.3322.org/test.html )
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
><html>
><head>
><style type="text/css">
> address {font-size: smaller;}
> address dl { width: 30ex;}
> address dd { text-align: right; }
> address dt { float: left; }
></style>
></head>
><body>
><address>
><p>
Not valid. See the 4.01 Transistional DTD. ADDRESS can only contain
%inline elements, which is not the same as block elements styled to display
inline.
><strong>Zhang Weiwu</strong><br/>
> General Manager
></p>
><p>
> Beisihuan Zhong Road No. 238 <br/>
> Baiyan Building Unit 406B
></p>
><dl>
><dt>Tel:</dt>
><dd>++86 10 8231 8580 ext. 105</dd>
><dt>Email:</dt>
><dd>zhangwe...@realss.com</dd>
><dt>Skype:</dt>
><dd>zhangweiwu</dd>
><dt>Web:</dt>
><dd>www.realss.com</dd>
></dl>
></address>
></body>
></html>
> My question is: is this a bug of Firefox? In my case Opera 9.64 behave
> as I expected, a.k.a. <dt> floated to the left.
When you write invalid markup browsers may differ in how they recover from
the error.
> Or am I wrong to use <address>?
You are wrong to put a block element in ADDRESS.
> The definition of <address> on w3c is too poor to show if it should contain
> the delivery or visiting address, or it can contain "address" in general
> sense,
The purpose of the ADDRESS element is clear. It is to allow the user to
contact the author or person responsible for a page or a part of the page.
It is not intended for any address that might occur in a text. (For
example, if a page gives address of several friends, the ADDRESS element is
for the address of the person who maintains the page, not for the address of
any of the friends.
As you have noticed, this contact information might be a postal address or a
street address. But it also might be an e-mail address, a mailto link to
e-mail, a link to a web form, and so forth. Unfortunately, there has never
be a standard way of expressing what kind of information the ADDRESS block
contains. (A similar failing can be found in the BLOCKQUOTE element, which
has never had a standard way of attributing the quoted material.)
Common practice is to use a link (mailto or http) for e-mail or web form
addresses and to use BR to make postal addresses look like addresses on
envelopes or packages. Since the principal use of HTML is on the World Wide
Web, not many authors expect or encourage contact by persons visiting a
street address (if it differs from the postal address). This still leaves
many kinds of communications possibilities. Telephone numbers are styled
differently in various parts of the world, so users may not recognize that a
telephone number is a telephone number, and if the author prefers text to a
cellphone number, how should that be communicated?
There is no generally accepted answer to these questions yet.
> which include all contact information. The example also fail to show this:
> <http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-structural.html#edef_structural_address>
Your example is from the XHTML 2 draft. There is no XHTML 2 DTD yet (that I
can find) but this
<http://www.w3.org/TR/xhtml2/mod-structural.html#s_structuralmodule>
XHTML 2.0 - XHTML Structural Module
seems to indicate that XHTML 2 does not contemplate allowing other block
elements in ADDRESS (as opposed to P, which has previously excluded other
block elements but will admit some in XHTML 2).
> Since <address> is a block element (see XHTML 2.0 style sheet:
> http://www.w3.org/TR/2004/WD-xhtml2-20040722/xhtml2-style.html#a_stylesheet
> ), I took it as "address" in general, which is all contact information,
> thus should be able to hold <dl>.
It does not follow that a block element will necessarily be permitted to
contain other block elements. In fact ADDRESS does not permit it in 4.01,
and apparently it is not contemplated in XHTML 2.
--
Lars Eighner <http://larseighner.com/> September 5914, 1993
292 days since Rick Warren prayed over Bush's third term.
Obama: No hope, no change, more of the same. Yes, he can, but no, he won't.
dorayme
Lars Eighner <use...@larseighner.com> wrote:
> The purpose of the ADDRESS element is clear. It is to allow the user to
> contact the author or person responsible for a page or a part of the page.
> It is not intended for any address that might occur in a text. (For
> example, if a page gives address of several friends, the ADDRESS element is
> for the address of the person who maintains the page, not for the address of
> any of the friends.
It might have been clear. But it is much ignored these days. It just
feels so right to so many authors to use Address for addresses
generally. And, I suppose, they do have a point, it would be a rather
more useful element for this purpose.
If a mistake is repeated enough, is it still a mistake? Be careful with
this Lars, it is not quite a simple matter and no, I am not a post
modernist relativist. <g>
--
dorayme
Andy Dingley
> If a mistake is repeated enough, is it still a mistake?
When there's a pre-existing specification, then yes.
Even if no-one reads the spec, the tree still makes a crashing sound
when it falls.
Harlan Messinger
It seems like such a weird element. Isn't it the only element that
appears in the BODY instead of the HEAD that is meant to signal
information about the document?
Andy Dingley
wrote:
> It seems like such a weird element.
Not for its age. Back in those days we had all sorts of weirdness:
remember the <hallucigenia> and <anomalocaris> tags?
The weird part is that <address> has survived so long since then, even
past the great paleosemantic extinction that was HTML 4 Strict. Surely
its widespread abuse has diluted its original intention beyond any
usefulness?
C A Upsdell
Well, what is within the ADDRESS tag is rendered, which makes it logical
to put it in the BODY. Things in the header do not generate content.
As for ADDRESS being a weird tag: it is like CITE, CODE, KBD, PARAM,
SAMP, VAR, etc., and I have found many of these to be useful from time
to time. We could do without them by using SPANs, but this would be
clumsier and would remove meta-information from the page.
Lars Eighner
<f513b155-59fa-40a1...@m26g2000yqb.googlegroups.com>, the
lovely and talented Andy Dingley broadcast on
comp.infosystems.www.authoring.stylesheets:
This is creeping over to HTML rather than stylesheet territory. The
stylesheet point is: you cannot expect styling to do what you want when the
markup is invalid. (Unfortunately, you also cannot expect crossbrowser
consistency when the markup *is* valid --- but at least you have a shot at
it.)
There seems to be tons of stuff in HTML (and various bleeding-edge draft
specs) that are not especially well-thought out. In the old days the
emphasis was on the problem of structure vs. presentation which sort of
obscured the somewhat overlapping problem of what was for the human and what
was for the machine. A good example that I have mentioned is BLOCKQUOTE and
Q. They have the CITE attribute. What the hell good is CITE? In print an
inline quote will have attribution in the running text or in a footnote.
But CITE doesn't do either of those things --- it doesn't create a footnote
and it doesn't add inline attribution to the text. CITE doesn't help the
human and it doesn't help the machine. Well, the machine could put CITE in
a tooltip --- if it is a browser with tooltips --- but what then would the
TITLE attribute mean, and what should the machine do if both CITE and TITLE
have values for the same Q?
--
Lars Eighner <http://larseighner.com/> September 5915, 1993
293 days since Rick Warren prayed over Bush's third term.
dorayme
<82c457dd-6890-463e...@j19g2000yqk.googlegroups.com>,
Andy Dingley <din...@codesmiths.com> wrote:
> On 9 Nov, 22:53, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
> > If a mistake is repeated enough, is it still a mistake?>
>
> When there's a pre-existing specification, then yes.
>
I knew someone would say this.
> Even if no-one reads the spec, the tree still makes a crashing sound
> when it falls.
It is imagined as particularly loud for the black letter lawyer or
literalist type of person.
Still, the specs on ADDRESS are so very clear, that it is quite a bold
contempt to use it for anything but author contact info. Hard to know
whether to admire a widening interpretation or to condemn it.
--
dorayme
Andy Dingley
> Hard to know
> whether to admire a widening interpretation or to condemn it.
"Widening an interpretation" implies that there was an interpretation
to begin with.
Not having a clue to begin with isn't the same thing at all.
dorayme
<4e636145-f8a5-4c0d...@m16g2000yqc.googlegroups.com>,
Andy Dingley <din...@codesmiths.com> wrote:
You are right, distinct things. When Address was invented, there was an
opportunity to invent something rather different and probably far more
broadly useful. But don't be too hard on the inventors. Although they
might not have had a single clue about the psychology of people - fancy
calling the element Address, when they meant things about the author(s)!
It's ok, Andy, I completely sympathise but I think you are being a tad
harsh. These guys had narrowly focussed skills and they have done an
impressive job. Ease up on them.
--
dorayme