Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Semantic markup (was: Simple centering in block?)
8 views
Skip to first unread message
Thomas 'PointedEars' Lahn
Apr 12, 2013, 10:01:17 AM4/12/13
to
Jukka K. Korpela wrote:
> 2013-04-12 14:47, Thomas 'PointedEars' Lahn wrote:
>> a “div” element and “span” elements should not have been used here
>> in the first place, but an “nav” elemen
There was a lot more. You have deliberately distorted the meaning of my
statement by omitting relevant parts, in order to support your fallacious
argument. Not the first time, if I recall correctly.
> […] There is no demonstrable benefit to be gained from using <nav>.
None that *you* are *aware of*.
> Many people promote it for quasi-religious reasons, with
> “semantic” as the mantra, failing to understand the semantics, i.e. the
> meaning, of “semantic”.
Of course, it has always been easier to dismiss ideas as nonsense – by
calling them (quasi-)religion, by calling their creators and followers
names; by crucifying them, burning them, forcing them to recant, hanging
them, chopping their heads off, locking them up for life, or deliberately
misquoting them (more or less in that order) – than to provide a single
*sound* argument against the idea or to provide viable alternatives.
However, this is not how progress is achieved, and it is obviously
contradicting core human nature; for if bullying naysayers would have
prevailed, humans would still be quadrupeds living in trees. But I digress.
I have done research on Semantic Web Technologies while studying computer
science, so I would like to think that I know what I am talking about when I
say “semantic”, and that I can be fairly rational about it.
Semantics is the study of meaning(s). [1] Particularly with regard to
computer science, it is not (quasi-)religion at all, of course; it is a
cornerstone of an informed approach to achieve a primary goal of computer
science, or “informatics” as it is also called: to *organize information* so
that it becomes *useful* even in *previously unforeseen* ways.
A primary goal of the W3C, led by its Director Tim Berners-Lee (who invented
HTML for that reason [2]), is to achieve a “Semantic Web”; a Web consisting
of *meaningful* information. [3] While this approach relates mostly to
languages other than HTML (ibid.), it needs not to exclude HTML. In fact,
RDFa [4], and the addition of semantic elements (that is, elements *only*
conveying semantics) in HTML5 (to those that already existed in previous
versions) [5a, 5b] shows that it works well with HTML, too.
> But they usually realize that they need to warn that especially for the
> purposes of styling, <nav> really makes things more difficult. Try styling
> it on old versions of IE
Your logic is flawed because its premise is based on a fundamental
misconception. The “nav” element, and other such HTML5 elements, ought not
to be styled *at all*. They are not intended to be used as a layout
container, but as a *content* container. They are there *solely* to convey
semantics, that is, *meaning(s)*. In the case of the “nav” element, the
meaning is “this content here *is* *for* navigation.” [6, 7]
It is left to the user agent how to interpret that. [6] Current user agents
*might* not interpret it at all – which would beg the question why it was
added to HTML5/WHATWG HTML in the first place, with HTML5/WHATWG HTML being
primarily *vendor*-driven, so there should be practical applications
already –, but future ones certainly could. Certainly, if the “nav” element
was used today *properly* (and there are people who do that), it is already
possible *today* to tell sections for navigation and sections not for
navigation apart *without* rendering the document. This possibility to
attach *meaning* to *textual content* is the benefit of semantic markup.
> (where styling of> <div> is smooth sailing), and you’ll see. Trolls, on
> the other hand, don’t write warnings, except fake warnings.
Ex falso quodlibet. The interesting thing about your postings, though, is
that you are quick to call names and slow to provide any references to
support your statements. As if you considered yourself infallible – by
which, curiously, but not surprisingly, we have come full circle.
X-Post & F'up2 comp.infosystems.www.authoring.html (where it belongs)
PointedEars
___________
[1] <http://www.merriam-webster.com/dictionary/semantics>
[2] <http://www.w3.org/History/1989/proposal.html>
[3] <http://www.w3.org/standards/semanticweb/>
[4] <http://www.w3.org/TR/xhtml-rdfa-primer/>
[5a] <http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#semantics-0>
[5b] <http://www.w3.org/html/logo/#the-technology>
[6] <http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-
element>
[7] <http://html5doctor.com/downloads/h5d-sectioning-flowchart.png>
--
When all you know is jQuery, every problem looks $(olvable).
> 2013-04-12 14:47, Thomas 'PointedEars' Lahn wrote:
>> a “div” element and “span” elements should not have been used here
>> in the first place, but an “nav” elemen
There was a lot more. You have deliberately distorted the meaning of my
statement by omitting relevant parts, in order to support your fallacious
argument. Not the first time, if I recall correctly.
> […] There is no demonstrable benefit to be gained from using <nav>.
None that *you* are *aware of*.
> Many people promote it for quasi-religious reasons, with
> “semantic” as the mantra, failing to understand the semantics, i.e. the
> meaning, of “semantic”.
Of course, it has always been easier to dismiss ideas as nonsense – by
calling them (quasi-)religion, by calling their creators and followers
names; by crucifying them, burning them, forcing them to recant, hanging
them, chopping their heads off, locking them up for life, or deliberately
misquoting them (more or less in that order) – than to provide a single
*sound* argument against the idea or to provide viable alternatives.
However, this is not how progress is achieved, and it is obviously
contradicting core human nature; for if bullying naysayers would have
prevailed, humans would still be quadrupeds living in trees. But I digress.
I have done research on Semantic Web Technologies while studying computer
science, so I would like to think that I know what I am talking about when I
say “semantic”, and that I can be fairly rational about it.
Semantics is the study of meaning(s). [1] Particularly with regard to
computer science, it is not (quasi-)religion at all, of course; it is a
cornerstone of an informed approach to achieve a primary goal of computer
science, or “informatics” as it is also called: to *organize information* so
that it becomes *useful* even in *previously unforeseen* ways.
A primary goal of the W3C, led by its Director Tim Berners-Lee (who invented
HTML for that reason [2]), is to achieve a “Semantic Web”; a Web consisting
of *meaningful* information. [3] While this approach relates mostly to
languages other than HTML (ibid.), it needs not to exclude HTML. In fact,
RDFa [4], and the addition of semantic elements (that is, elements *only*
conveying semantics) in HTML5 (to those that already existed in previous
versions) [5a, 5b] shows that it works well with HTML, too.
> But they usually realize that they need to warn that especially for the
> purposes of styling, <nav> really makes things more difficult. Try styling
> it on old versions of IE
Your logic is flawed because its premise is based on a fundamental
misconception. The “nav” element, and other such HTML5 elements, ought not
to be styled *at all*. They are not intended to be used as a layout
container, but as a *content* container. They are there *solely* to convey
semantics, that is, *meaning(s)*. In the case of the “nav” element, the
meaning is “this content here *is* *for* navigation.” [6, 7]
It is left to the user agent how to interpret that. [6] Current user agents
*might* not interpret it at all – which would beg the question why it was
added to HTML5/WHATWG HTML in the first place, with HTML5/WHATWG HTML being
primarily *vendor*-driven, so there should be practical applications
already –, but future ones certainly could. Certainly, if the “nav” element
was used today *properly* (and there are people who do that), it is already
possible *today* to tell sections for navigation and sections not for
navigation apart *without* rendering the document. This possibility to
attach *meaning* to *textual content* is the benefit of semantic markup.
> (where styling of> <div> is smooth sailing), and you’ll see. Trolls, on
> the other hand, don’t write warnings, except fake warnings.
Ex falso quodlibet. The interesting thing about your postings, though, is
that you are quick to call names and slow to provide any references to
support your statements. As if you considered yourself infallible – by
which, curiously, but not surprisingly, we have come full circle.
X-Post & F'up2 comp.infosystems.www.authoring.html (where it belongs)
PointedEars
___________
[1] <http://www.merriam-webster.com/dictionary/semantics>
[2] <http://www.w3.org/History/1989/proposal.html>
[3] <http://www.w3.org/standards/semanticweb/>
[4] <http://www.w3.org/TR/xhtml-rdfa-primer/>
[5a] <http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#semantics-0>
[5b] <http://www.w3.org/html/logo/#the-technology>
[6] <http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-
element>
[7] <http://html5doctor.com/downloads/h5d-sectioning-flowchart.png>
--
When all you know is jQuery, every problem looks $(olvable).
Jukka K. Korpela
Apr 12, 2013, 10:12:43 AM4/12/13
to
2013-04-12 17:01, Thomas 'PointedEars' Lahn wrote:
> X-Post & F'up2 comp.infosystems.www.authoring.html (where it belongs)
As so often, the troll, having given “advice”, which was both off-topic
> X-Post & F'up2 comp.infosystems.www.authoring.html (where it belongs)
and wrong, gave a pointless pseudo-lecture *shouting* a lot, and now
tries to troll in another group.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
John W Kennedy
Apr 12, 2013, 12:52:21 PM4/12/13
to
On 2013-04-12 14:01:17 +0000, Thomas 'PointedEars' Lahn said:
> A primary goal of the W3C, led by its Director Tim Berners-Lee (who invented
> HTML for that reason [2]), is to achieve a “Semantic Web”; a Web consisting
> of *meaningful* information. [3] While this approach relates mostly to
> languages other than HTML (ibid.), it needs not to exclude HTML. In fact,
> RDFa [4], and the addition of semantic elements (that is, elements *only*
> conveying semantics) in HTML5 (to those that already existed in previous
> versions) [5a, 5b] shows that it works well with HTML, too.
One might observe here that semantic markup was already a key concept
> A primary goal of the W3C, led by its Director Tim Berners-Lee (who invented
> HTML for that reason [2]), is to achieve a “Semantic Web”; a Web consisting
> of *meaningful* information. [3] While this approach relates mostly to
> languages other than HTML (ibid.), it needs not to exclude HTML. In fact,
> RDFa [4], and the addition of semantic elements (that is, elements *only*
> conveying semantics) in HTML5 (to those that already existed in previous
> versions) [5a, 5b] shows that it works well with HTML, too.
of IBM's original GML, back in the 70s.
--
John W Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Jukka K. Korpela
Apr 12, 2013, 1:11:51 PM4/12/13
to
2013-04-12 19:52, John W Kennedy wrote:
> One might observe here that semantic markup was already a key concept of
> IBM's original GML, back in the 70s.
And that would have little to do with HTML, which was never *really*
> One might observe here that semantic markup was already a key concept of
> IBM's original GML, back in the 70s.
based on SGML, just nominally, in the specs (browsers did not use
existing SGML parsers but ad hoc tag soup slurpers).
Regarding semantics, the page “The Roots of SGML -- A Personal
Recollection”,
http://www.sgmlsource.com/history/roots.htm
by Charles F. Goldfarb, the father of GML and SGML, does not contain a
single occurrence of the word “semantic”. It describes structural
markup, not semantic. Anyone who does not know the difference has a
problem with the semantics of “semantic”.
Besides, GML and SGML were meant to be, and are, *generalized* markup
languages. This means that markup may indicate structure, or it may
specify rendering, or both. It could also indicate semantics (i.e.,
meaning), of course, or whatever you like. And HTML was always a mixed
language, with both structural and rendering (“physical”) markup.
Semantic HTML markup, however, is yet to be invented, and probably won’t
be invented. The use of various microlevel notations for semantics
illustrates the lack of semantic markup in HTML itself – HTML becomes
just one of the carriers of real semantic metadata (though such metadata
is mostly still just write-only, except for limited experiments).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
John W Kennedy
Apr 12, 2013, 3:55:24 PM4/12/13
to
On 2013-04-12 17:11:51 +0000, Jukka K. Korpela said:
> 2013-04-12 19:52, John W Kennedy wrote:
>
>> One might observe here that semantic markup was already a key concept of
>> IBM's original GML, back in the 70s.
>
> And that would have little to do with HTML, which was never *really*
> based on SGML, just nominally, in the specs (browsers did not use
> existing SGML parsers but ad hoc tag soup slurpers).
That's implementation of browsers, not language design. The historic
> 2013-04-12 19:52, John W Kennedy wrote:
>
>> One might observe here that semantic markup was already a key concept of
>> IBM's original GML, back in the 70s.
>
> And that would have little to do with HTML, which was never *really*
> based on SGML, just nominally, in the specs (browsers did not use
> existing SGML parsers but ad hoc tag soup slurpers).
line from GML to SGML to HTML is clear.
> Regarding semantics, the page “The Roots of SGML -- A Personal Recollection”,
> http://www.sgmlsource.com/history/roots.htm
> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
> single occurrence of the word “semantic”.
deliberately being dishonest.
--
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
Jukka K. Korpela
Apr 12, 2013, 4:32:17 PM4/12/13
to
2013-04-12 22:55, John W Kennedy wrote:
>> And that would have little to do with HTML, which was never *really*
>> based on SGML, just nominally, in the specs (browsers did not use
>> existing SGML parsers but ad hoc tag soup slurpers).
>
> That's implementation of browsers,
Yes, that’s the reality. The troll, which you seem to be supporting, has
>> And that would have little to do with HTML, which was never *really*
>> based on SGML, just nominally, in the specs (browsers did not use
>> existing SGML parsers but ad hoc tag soup slurpers).
>
> That's implementation of browsers,
often claimed that there were some browser(s) that actually implemented
HTML as an SGML application, always failing to provide any evidence, and
doing that with a lot of noise.
> The historic
> line from GML to SGML to HTML is clear.
learned remarkably little from it, and attempts at retrofitting HTML to
SGML failed miserably.
>> Regarding semantics, the page “The Roots of SGML -- A Personal
>> Recollection”,
>> http://www.sgmlsource.com/history/roots.htm
>> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
>> single occurrence of the word “semantic”.
>
> Either you have no idea of what you're talking about, or you're
> deliberately being dishonest.
document contains the word “semantic”?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
dorayme
Apr 12, 2013, 5:50:53 PM4/12/13
to
In article <kk9qrb$9id$1...@dont-email.me>,
...
> >> Regarding semantics, the page “The Roots of SGML -- A Personal
> >> Recollection”,
> >> http://www.sgmlsource.com/history/roots.htm
> >> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
> >> single occurrence of the word “semantic”.
> >
> > Either you have no idea of what you're talking about, or you're
> > deliberately being dishonest.
>
> If you call me a liar, can you please specify exactly where that
> document contains the word “semantic”?
As far as I can tell, at least "s" occurs more than 100 times on that
url. There are 16 matches for "se", and no matches for "sem" and
therefore no matches for more of the word.
Outside possibility: Goldfarb made a typo and "semantic" was there in
disguise. <g>
--
dorayme
...
> >> Regarding semantics, the page “The Roots of SGML -- A Personal
> >> Recollection”,
> >> http://www.sgmlsource.com/history/roots.htm
> >> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
> >> single occurrence of the word “semantic”.
> >
> > Either you have no idea of what you're talking about, or you're
> > deliberately being dishonest.
>
> If you call me a liar, can you please specify exactly where that
> document contains the word “semantic”?
url. There are 16 matches for "se", and no matches for "sem" and
therefore no matches for more of the word.
Outside possibility: Goldfarb made a typo and "semantic" was there in
disguise. <g>
--
dorayme
tlvp
Apr 12, 2013, 9:07:32 PM4/12/13
to
On Fri, 12 Apr 2013 15:55:24 -0400, John W Kennedy wrote, of the claim:
>> Regarding semantics, the page “The Roots of SGML -- A Personal Recollection”,
>> http://www.sgmlsource.com/history/roots.htm
>> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
>> single occurrence of the word “semantic”.
>
> Either you have no idea of what you're talking about, or you're
> deliberately being dishonest.
It's easy enough to browse to the cited URL and Search for "semantic".
>> Regarding semantics, the page “The Roots of SGML -- A Personal Recollection”,
>> http://www.sgmlsource.com/history/roots.htm
>> by Charles F. Goldfarb, the father of GML and SGML, does not contain a
>> single occurrence of the word “semantic”.
>
> Either you have no idea of what you're talking about, or you're
> deliberately being dishonest.
Curiously, I meet the response "Not found" when I do so. I think that's
pretty good confirmation that the page in question really 'does not contain
a single occurrence of the word “semantic”.' Do you disagree?
Or is the point your seek to make some other point entirely?
Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
Christoph Becker
Apr 13, 2013, 5:51:01 PM4/13/13
to
Thomas 'PointedEars' Lahn wrote:
element. However, note that Jukka wrote "especially for the purposes of
styling", and AIUI elements that are not understood by a browser can be
more of a problem for scripting (e.g. traversing) the DOM.
> It is left to the user agent how to interpret that. [6] Current user agents
> *might* not interpret it at all – which would beg the question why it was
> added to HTML5/WHATWG HTML in the first place, with HTML5/WHATWG HTML being
> primarily *vendor*-driven, so there should be practical applications
> already –, but future ones certainly could. Certainly, if the “nav” element
> was used today *properly* (and there are people who do that), it is already
> possible *today* to tell sections for navigation and sections not for
> navigation apart *without* rendering the document. This possibility to
> attach *meaning* to *textual content* is the benefit of semantic markup.
The cited reference gives a note, where the "nav" element is useful:
| User agents (such as screen readers) that are targeted at users who
| can benefit from navigation information being omitted in the initial
| rendering, or who can benefit from navigation information being
| immediately available, can use this element as a way to determine
| what content on the page to initially skip and/or provide on request.
> [6]
<http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-element>
In <7441631.6...@PointedEars.de> Thomas 'PointedEars' Lahn wrote:
> However, a “div” element and “span” elements should not have been
> used here in the first place, but an “nav” element (HTML5 only), an
> “ul” element as child, with “li” elements as its children, with an
> “a” element (or similar) each as its child.
The "nav" element is reasonable. But I don't consider marking up the
navigation as "ul" particularly useful regarding the /semantics/.
--
Christoph M. Becker
> Jukka K. Korpela wrote:
>> But they usually realize that they need to warn that especially for the
>> purposes of styling, <nav> really makes things more difficult. Try styling
>> it on old versions of IE
>
> Your logic is flawed because its premise is based on a fundamental
> misconception. The “nav” element, and other such HTML5 elements, ought not
> to be styled *at all*. They are not intended to be used as a layout
> container, but as a *content* container. They are there *solely* to convey
> semantics, that is, *meaning(s)*. In the case of the “nav” element, the
> meaning is “this content here *is* *for* navigation.” [6, 7]
I agree that styling is not necessarily an issue regarding the "nav"
>> But they usually realize that they need to warn that especially for the
>> purposes of styling, <nav> really makes things more difficult. Try styling
>> it on old versions of IE
>
> Your logic is flawed because its premise is based on a fundamental
> misconception. The “nav” element, and other such HTML5 elements, ought not
> to be styled *at all*. They are not intended to be used as a layout
> container, but as a *content* container. They are there *solely* to convey
> semantics, that is, *meaning(s)*. In the case of the “nav” element, the
> meaning is “this content here *is* *for* navigation.” [6, 7]
element. However, note that Jukka wrote "especially for the purposes of
styling", and AIUI elements that are not understood by a browser can be
more of a problem for scripting (e.g. traversing) the DOM.
> It is left to the user agent how to interpret that. [6] Current user agents
> *might* not interpret it at all – which would beg the question why it was
> added to HTML5/WHATWG HTML in the first place, with HTML5/WHATWG HTML being
> primarily *vendor*-driven, so there should be practical applications
> already –, but future ones certainly could. Certainly, if the “nav” element
> was used today *properly* (and there are people who do that), it is already
> possible *today* to tell sections for navigation and sections not for
> navigation apart *without* rendering the document. This possibility to
> attach *meaning* to *textual content* is the benefit of semantic markup.
| User agents (such as screen readers) that are targeted at users who
| can benefit from navigation information being omitted in the initial
| rendering, or who can benefit from navigation information being
| immediately available, can use this element as a way to determine
| what content on the page to initially skip and/or provide on request.
> [6]
<http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-element>
In <7441631.6...@PointedEars.de> Thomas 'PointedEars' Lahn wrote:
> However, a “div” element and “span” elements should not have been
> used here in the first place, but an “nav” element (HTML5 only), an
> “ul” element as child, with “li” elements as its children, with an
> “a” element (or similar) each as its child.
The "nav" element is reasonable. But I don't consider marking up the
navigation as "ul" particularly useful regarding the /semantics/.
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Apr 13, 2013, 6:59:33 PM4/13/13
to
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Jukka K. Korpela wrote:
>>> But they usually realize that they need to warn that especially for the
>>> purposes of styling, <nav> really makes things more difficult. Try
>>> styling it on old versions of IE
>>
>> Your logic is flawed because its premise is based on a fundamental
>> misconception. The “nav” element, and other such HTML5 elements, ought
>> not to be styled *at all*. They are not intended to be used as a layout
>> container, but as a *content* container. They are there *solely* to
>> convey semantics, that is, *meaning(s)*. In the case of the “nav”
>> element, the meaning is “this content here *is* *for* navigation.” [6, 7]
>
> I agree that styling is not necessarily an issue regarding the "nav"
> element. However, note that Jukka wrote "especially for the purposes of
> styling", and AIUI elements that are not understood by a browser can be
> more of a problem for scripting (e.g. traversing) the DOM.
Tags that are not understood by an SGML-based markup parser are (to be)
> Thomas 'PointedEars' Lahn wrote:
>> Jukka K. Korpela wrote:
>>> But they usually realize that they need to warn that especially for the
>>> purposes of styling, <nav> really makes things more difficult. Try
>>> styling it on old versions of IE
>>
>> Your logic is flawed because its premise is based on a fundamental
>> misconception. The “nav” element, and other such HTML5 elements, ought
>> not to be styled *at all*. They are not intended to be used as a layout
>> container, but as a *content* container. They are there *solely* to
>> convey semantics, that is, *meaning(s)*. In the case of the “nav”
>> element, the meaning is “this content here *is* *for* navigation.” [6, 7]
>
> I agree that styling is not necessarily an issue regarding the "nav"
> element. However, note that Jukka wrote "especially for the purposes of
> styling", and AIUI elements that are not understood by a browser can be
> more of a problem for scripting (e.g. traversing) the DOM.
ignored; the content of corresponding elements is (to be) rendered, and no
nodes for them are to be added in the document tree (in the HTML5 DOM they
may be HTMLUnknownElement nodes, but HTML5 is not SGML-based).
When I said that the “nav” element ought not be styled, I meant that the
element of that type should not be styled, and that it ought not be used in
CSS selectors. If the document would otherwise be semantically structured,
there should be no problem with presentation then.
However, I must admit that I have used the element type in CSS selectors
myself; but apparently in such an insignificant way that there is no
(additional) problem with older IEs (tested down to IE 6.0.2800.1106).
Therefore, I must and can attenuate my dissuasion: the “nav” element type
*can* be used in CSS selectors *carefully*, and with consideration to the
target layout engines (the line for supporting borken browsers has to be
drawn *somewhere*, especially in commercial Web design where there is a
project budget to be met; BTDT).
It should also be noted that there are workarounds for non-HTML5 browsers,
particularly for older versions of MSHTML not recognizing element types for
styling:
<https://developer.mozilla.org/en-
US/docs/HTML/Sections_and_Outlines_of_an_HTML5_document#Using_HTML5_Elements_in_Non-
HTML5_Browsers>
>> [6]
> <http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-
element>
>
> In <7441631.6...@PointedEars.de> Thomas 'PointedEars' Lahn wrote:
>
>> However, a “div” element and “span” elements should not have been
>> used here in the first place, but an “nav” element (HTML5 only), an
>> “ul” element as child, with “li” elements as its children, with an
>> “a” element (or similar) each as its child.
>
> The "nav" element is reasonable. But I don't consider marking up the
> navigation as "ul" particularly useful regarding the /semantics/.
A navigation menu of that kind is a *list* of links, is it not? Therefore,
>
> In <7441631.6...@PointedEars.de> Thomas 'PointedEars' Lahn wrote:
>
>> However, a “div” element and “span” elements should not have been
>> used here in the first place, but an “nav” element (HTML5 only), an
>> “ul” element as child, with “li” elements as its children, with an
>> “a” element (or similar) each as its child.
>
> The "nav" element is reasonable. But I don't consider marking up the
> navigation as "ul" particularly useful regarding the /semantics/.
if the order of the links matters, use an “ol” (ordered list) element; if
they do not matter, use an “ul” (unordered list) element; if you want to
attach additional, *structured* information to menu items, use a “dl”
(definition list) element. This *is* the semantics of those element types,
and this is the best common practice for menus so far. (Try such a
navigation menu in a text browser – which gives an indication how accessible
the content is, for example how serializable for screen readers – and see it
*working*, by contrast to div-span tag-soup. The “menu” element is
currently [CR] at risk of being removed from HTML5, and it has no
counterpart in HTML 4.01. Menus based on SELECT elements are not accessible
and not interoperable.)
The “div“ and “span” element types, on the other hand, have no particular
semantics attached to them, and are primarily used for presentation: The
“div” element marks up an otherwise unspecified *div*ision of content in the
document (often used for presentation, like positioning, only), and the
“span” element marks up sections of running text (usually for text
formatting, but other purposes are conceivable, and it is used so) within a
paragraph (“p” element).
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
0 new messages