Question on "<div/>" (not a typo) tag

[Don Bruder]

Hi folks...
I've recently had reason to want to meddle with some HTML written by
others, and I've bumped into something that I'm not familiar with - the
tag "<div/>" (No, that's not a typo - I did indeed mean "greater-than
div forward slash less-than")

I'm aware of the "<div>" (no slash) ... "</div>" (leading slash)
bracketing forms, and I think I've got at least a reasonable
understanding of them and what they do, but until I started messing with
these pages, I hadn't encountered the "trailing slash" version. No
searching has found me an answer, so I expect it's something so common
as to be considered a "why bother mentioning it? - everyone knows" item.
Except this particular "everyone" doesn't know.

So would someone please be so kind as to either tell me what's up with
the trailing-slash variation, or, failing that, point me to someplace
that will do so?


Thanks in advance...

[Jukka K. Korpela]

Post by Don Bruder
I've recently had reason to want to meddle with some HTML written by
others, and I've bumped into something that I'm not familiar with - the
tag "<div/>"

For most practical purposes, it will be treated as a typo for <div>.
Browsers just ignore the "/".

However, in XHTML, <div/>, formally means <div></div>, i.e. a div
element with empty content. Such a construct is discouraged, because
browsers won't normally take it that way. Reference:
http://www.w3.org/TR/xhtml1/#C_3

If the document is served using an XHTML document type (which is rare),
<div/> will be taken as empty div by modern browsers.

Formally, by good old (pre-XHTML) HTML specifications, <div/> is
equivalent to <div>>, i.e. the start tag <div> followed by the
greater-than sign. No browsers take it that way, but validators will,
and then you get confused.

The morale is: <div/> is bad. Don't do <div/>. If you ever need to write
a div element with empty content, use <div></div>.

[Helmut Richter]

However, in XHTML, <div/>, formally means <div></div>, i.e. a div element with
empty content. Such a construct is discouraged, because browsers won't
http://www.w3.org/TR/xhtml1/#C_3

Thanks, I forgot that one, even though I have already stepped into that
trap myself.

[Jukka K. Korpela]

Post by Don Bruder
I've recently had reason to want to meddle with some HTML written by
others, and I've bumped into something that I'm not familiar with - the
tag "<div/>"

For most practical purposes, it will be treated as a typo for <div>.
Browsers just ignore the "/".

However, in XHTML, <div/>, formally means <div></div>, i.e. a div
element with empty content. Such a construct is discouraged, because
browsers won't normally take it that way. Reference:
http://www.w3.org/TR/xhtml1/#C_3

If the document is served using an XHTML document type (which is rare),
<div/> will be taken as empty div by modern browsers.

Formally, by good old (pre-XHTML) HTML specifications, <div/> is
equivalent to <div>>, i.e. the start tag <div> followed by the
greater-than sign. No browsers take it that way, but validators will,
and then you get confused.

The morale is: <div/> is bad. Don't do <div/>. If you ever need to write
a div element with empty content, use <div></div>.

[Helmut Richter]

Post by Don Bruder
Hi folks...
I've recently had reason to want to meddle with some HTML written by
others, and I've bumped into something that I'm not familiar with - the
tag "<div/>" (No, that's not a typo - I did indeed mean "greater-than
div forward slash less-than")

(You did indeed mean "less-than div forward slash greater-than".)

<xyz abc="uvw"/>

is an abbreviation of

<xyz abc="uvw"></xyz>

It is standard in XML and thus also in XHTML, and also in the upcoming HTML5.
In other versions of HTML, it is not standard but may sometimes be understood.
If you write it <xyz abc="uvw" /> with an additional blank, it is often
understood as <xyz abc="uvw"> which may or may not be intended.

Advice:

- Use what is standard in the language versions you are using; then you won't
get problems. If, for any reason, you do otherwise, you should at least
adhere to the following two advices:

- If an element has no closing tag (such as <img> or <br>), it should hardly
be misleading for man or machine to use it.

- If an element has a closing tag (such as <div>), one should never use it
unless the standard supports it. Otherwise, e.g. in HTML4 text, it may be
misinterpreted as opening tag only.

[Don Bruder]

In article

Post by Helmut Richter

Post by Don Bruder
Hi folks...
I've recently had reason to want to meddle with some HTML written by
others, and I've bumped into something that I'm not familiar with - the
tag "<div/>" (No, that's not a typo - I did indeed mean "greater-than
div forward slash less-than")

(You did indeed mean "less-than div forward slash greater-than".)

erf... Good catch. That's what I get for rushing, then not proofreading
before hitting send. :-P

Post by Helmut Richter
<xyz abc="uvw"/>
is an abbreviation of
<xyz abc="uvw"></xyz>
It is standard in XML and thus also in XHTML, and also in the upcoming HTML5.
In other versions of HTML, it is not standard but may sometimes be understood.
If you write it <xyz abc="uvw" /> with an additional blank, it is often
understood as <xyz abc="uvw"> which may or may not be intended.
- Use what is standard in the language versions you are using; then you won't
get problems. If, for any reason, you do otherwise, you should at least
- If an element has no closing tag (such as <img> or <br>), it should hardly
be misleading for man or machine to use it.
- If an element has a closing tag (such as <div>), one should never use it
unless the standard supports it. Otherwise, e.g. in HTML4 text, it may be
misinterpreted as opening tag only.

Between yours and the other replies so far, looks like I've got things
covered - Essentially, it sounds as though when I'm digging through the
code I'm looking at, anytime I see "<div/>" (or for anything other than
<img ...>) I can safely read it as "<div></div>" (or <tr></tr>, and so
on) and expect that reading will be close enough for understanding.
(which is going to make a huge difference - up to now, it's been leaving
me wondering how to properly pair it with something else. Now I know not
to be looking for its "other part" - there isn't one.)

Thanks everybody!

[Barry Margolin]

Post by Don Bruder
Between yours and the other replies so far, looks like I've got things
covered - Essentially, it sounds as though when I'm digging through the
code I'm looking at, anytime I see "<div/>" (or for anything other than
<img ...>) I can safely read it as "<div></div>" (or <tr></tr>, and so
on) and expect that reading will be close enough for understanding.
(which is going to make a huge difference - up to now, it's been leaving
me wondering how to properly pair it with something else. Now I know not
to be looking for its "other part" - there isn't one.)

Do you actually see this frequently? There are a few tags that many
authors get confused about -- P and BR for example, because they're seen
as separators rather than containers. But everyone knows that SPAN and
DIV are containers, so they should always come in matched pairs. Even
when you're creating an empty DIV (to be filled in later by Javascript),
I think most people pair them up as <div></div>.

The only place where I frequently see these as singletons is in jQuery
code. It's standard in jQuery to create an element with something like
$("<div>") or $("<div/>") -- jQuery encourages use of shorthand like
this.

[Don Bruder]

Post by Barry Margolin

Post by Don Bruder
Between yours and the other replies so far, looks like I've got things
covered - Essentially, it sounds as though when I'm digging through the
code I'm looking at, anytime I see "<div/>" (or for anything other than
<img ...>) I can safely read it as "<div></div>" (or <tr></tr>, and so
on) and expect that reading will be close enough for understanding.
(which is going to make a huge difference - up to now, it's been leaving
me wondering how to properly pair it with something else. Now I know not
to be looking for its "other part" - there isn't one.)

Do you actually see this frequently? There are a few tags that many
authors get confused about -- P and BR for example, because they're seen
as separators rather than containers. But everyone knows that SPAN and
DIV are containers, so they should always come in matched pairs. Even
when you're creating an empty DIV (to be filled in later by Javascript),
I think most people pair them up as <div></div>.
The only place where I frequently see these as singletons is in jQuery
code. It's standard in jQuery to create an element with something like
$("<div>") or $("<div/>") -- jQuery encourages use of shorthand like
this.

The pages I'm looking at/fiddling with are absolutely lousy with
occurrences of <div/> (not to mention literally dozens of <div
class=...> ... </div> sets per page), lightly sprinkled with <tr/>, and
an occasional <p/> or <br/> thrown in for variety. And yes, these pages
do indeed use more JQuery calls than I care to try to count, so I'd
imagine your comment about the shorthand is probably valid.

[Winston]

... I've bumped into something that I'm not familiar with - the
tag "<div/>" (No, that's not a typo - I did indeed mean "greater-than
div forward slash less-than")

ITYM less-than ... greater-than.

So would someone please be so kind as to either tell me what's up with
the trailing-slash variation, or, failing that, point me to someplace
that will do so?

It was XHTML (see XHTML spec, which came out between HTML 4 and 5) that
said that all tags, including "empty" tags, must be closed. Non-empty
tags (such as <em> that enclose content </em>) have always had to be
closed, but XHTML also required "empty" tags like <img> be closed, and
introduced <tag ... /> as both short for <tag ...></tag> and a
convenient way to close empty tags.

From what I've seen, XHTML *required* a space before the closing '/' in
such tags, but some widely-used browsers ignore that and accept a final
'/' as a tag close indicator whether or not there's a space in front of
it. Once lots of pages using the invalid construct existed, the web
browser developers that adhered to the XHTML spec found themselves at a
competitive disadvantage and so switched to accepting constructs such as
"<div/>" as valid.

HTH,
-WBE

[Jukka K. Korpela]

Post by Winston
It was XHTML (see XHTML spec, which came out between HTML 4 and 5) that
said that all tags, including "empty" tags, must be closed.

It's about closing elements, not tags. Here the distinction is
essential. And it was not XHTML that defined this feature; it was XML,
and XHTML could not help adopting it, because it is by design an "XML
application".

And what XML actually says is that every element must have a closing
tag, which may, however, be the same as the opening tag.

Post by Winston
Non-empty
tags (such as <em> that enclose content </em>) have always had to be
closed,

Regarding elements, it was the principle in specifications that any
element may be closed by using shorthand notations, like <em/foo/ (where
the second "/" closes the elements; whether you call it a tag is a
matter of definition). But browsers did not implement this.

Post by Winston
but XHTML also required "empty" tags like <img> be closed, and
introduced <tag ... /> as both short for <tag ...></tag> and a
convenient way to close empty tags.

XHTML also says that on the web, <tag/> should only be used if the
element's declared content is EMPTY. One reason to this is that browsers
treat <tag/> simply as <tag>, so the element is never closed or it will
be implicitly closed by some random element.

Post by Winston
From what I've seen, XHTML *required* a space before the closing '/' in
such tags,

No it does not (or "did not"). Please check the actual specifications
before giving more lessons. It simply says that for compatibility with
old browsers, a space *should* be used there on web pages and other
contexts where compatibility is relevant.

Post by Winston
but some widely-used browsers ignore that and accept a final
'/' as a tag close indicator whether or not there's a space in front of
it.

Wrong. In HTML mode, <tag/> is just <tag>, and in XHTML mode, <tag/> and
<tag /> are treated the same. It's some old user agents that did not get
<tag/> right as an *opening* tag that lead to the space recommendation.

Post by Winston
Once lots of pages using the invalid construct existed, the web
browser developers that adhered to the XHTML spec found themselves at a
competitive disadvantage and so switched to accepting constructs such as
"<div/>" as valid.

You are just making things up.

[Winston]

Post by Jukka K. Korpela

Post by Winston
It was XHTML (see XHTML spec, which came out between HTML 4 and 5) that
said that all tags, including "empty" tags, must be closed.

It's about closing elements, not tags. Here the distinction is
essential.

... and especially on a newsgroup devoted to HTML, you're right, I
used the wrong terminology and should have been more careful.

Post by Jukka K. Korpela
And it was not XHTML that defined this feature; it was XML, and
XHTML could not help adopting it, because it is by design an "XML
application".

Yes, but I doubt the OP cared about so detailed a history.
"See XHTML" seemed sufficient.

Post by Jukka K. Korpela

Post by Winston
From what I've seen, XHTML *required* a space before the closing '/'
in such tags,

No it does not (or "did not"). ... It simply says that for
compatibility with old browsers, a space *should* be used there on web
pages and other contexts where compatibility is relevant.

My mistake, then. I thought that SHOULD had enough emphasis that that's
how everyone was supposed to be doing it.

[and later...]

Post by Jukka K. Korpela
Wrong. In HTML mode, <tag/> is just <tag>,

(You must not be talking about really old user agents here.)

Post by Jukka K. Korpela
and in XHTML mode, <tag/> and
<tag /> are treated the same. It's some old user agents that did not get
<tag/> right as an *opening* tag that lead to the space recommendation.

where "not right" is actually "would fail to recognize tag at all
because it was parsed as < + tag/ + >, and tag/ was not a recognized
mark type (e.g., Mosaic-2.4/libhtmlw/HTMLparse.c:ParseMarkType only
ended the name at NUL or isspace()).

Post by Jukka K. Korpela

Post by Winston
Once lots of pages using the invalid construct existed, the web
browser developers that adhered to the XHTML spec found themselves at a
competitive disadvantage and so switched to accepting constructs such as
"<div/>" as valid.

You are just making things up.

I'll rephrase. When I was modifying Chimera's parser to accommodate the
then-new "/>", the XHTML stuff I saw said don't do <tag/>. I indeed
read it as virtually MUST, not SHOULD. I rapidly discovered there were
lots of web pages, and apparently some web page authoring tools, that
left out that space, and concluded that it was very unlikely they would
ever be fixed to do as XHTML said they should. I then changed my code
to accept <tag/> as < + tag + />, whether I thought leaving out the
space was valid or not. None of this matters in the least to anyone
else, though.

Rewriting the earlier comment in light of my misunderstanding...
Although people were told to use "<tag />", that recommendation has
generally been widely ignored, and lots of pages use the <tag/> form.

In any case, if the OP reads any of this, I think the question of what
<div/> means and where it came from has been answered.
-WBE

[Stanimir Stamenkov]

Post by Winston

Post by Jukka K. Korpela
Wrong. In HTML mode, <tag/> is just <tag>,

(You must not be talking about really old user agents here.)

"HTML mode" doesn't really mean "really old user agents" - it just
means content served and interpreted as text/html.

Just try out opening from .html file:

<html>
<span/>
<div>...</div>
</html>

What DOM tree you expect to get?

[Winston]

Post by Winston

Post by Jukka K. Korpela
Wrong. In HTML mode, <tag/> is just <tag>,

(You must not be talking about really old user agents here.)

"HTML mode" doesn't really mean "really old user agents" - it just means
content served and interpreted as text/html.

Er, I think you missed the word "not" in my reply?
-WBE

[Stanimir Stamenkov]

Post by Winston

Post by Winston

Post by Jukka K. Korpela
Wrong. In HTML mode, <tag/> is just <tag>,

(You must not be talking about really old user agents here.)

"HTML mode" doesn't really mean "really old user agents" - it just means
content served and interpreted as text/html.

Er, I think you missed the word "not" in my reply?

Seems I've misinterpreted it as "you must not talk", not that I've
missed the "not".

[Winston]

Post by Stanimir Stamenkov

Post by Winston

Post by Stanimir Stamenkov

Post by Winston
(You must not be talking about really old user agents here.)

"HTML mode" doesn't really mean "really old user agents" - it just
means content served and interpreted as text/html.

Er, I think you missed the word "not" in my reply?

Seems I've misinterpreted it as "you must not talk", not that I've
missed the "not".

Ah, OK. Yes, in American English, my "You must not be talking
about ____" is similar to, but a bit stronger than, saying "You're
apparently not talking about ____" (i.e., [I assume we agree that]
what you just said {is not true for} / {does not to apply to} _____).
-WBE

[Don Bruder]

Post by Winston

Post by Stanimir Stamenkov

Post by Winston

Post by Stanimir Stamenkov

Post by Winston
(You must not be talking about really old user agents here.)

"HTML mode" doesn't really mean "really old user agents" - it just
means content served and interpreted as text/html.

Er, I think you missed the word "not" in my reply?

Seems I've misinterpreted it as "you must not talk", not that I've
missed the "not".

Ah, OK. Yes, in American English, my "You must not be talking
about ____" is similar to, but a bit stronger than, saying "You're
apparently not talking about ____" (i.e., [I assume we agree that]
what you just said {is not true for} / {does not to apply to} _____).
-WBE

Original poster here...

How did this simple question (which was answered quite well, within just
a few hours of initially being posted) get turned into such a pissing
contest weeks later?

Methinks someone (I'm looking at YOU, "Winston", since you're the one
who started the "flow") has far too much time on their hands.