But who says when a list is really a list? Having two somehow related item one after the other means you got a list? Where is this lists obsession, this lists overkill stops?
Consider this:
<nav>Here you’ll find <a href=“#”>pictures</a> and <a href=“#”>cookies.</a></nav>
Semantically equivalent to:
<nav>
<a href=“#”>Pictures</a>
<a href=“#”>Cookies</a>
</nav>
Do you honestly believe you need lists for this?
(If you do, I give up now. =p)
Here we go again with the meaning. What meaning is there in a shelf with three cans: none. It’s a shelf, pick one already. Do you need to make a shelf for each can?
Don’t try to find another “meaning” on top of the semantics already in place. And if you want to use lists with that one, you really have to do something like this:
<nav>
<h1>Welcome</h1>
<p>Thank you for embarking on a journey around my website.</p>
<p>Here are the places I recommend you to visit:</p>
<ul>
<li><a href="#">My Profile</a></li>
<li><a href="#">Settings</a></li>
<li><a href="#">Log Out</a></li>
</ul>
</nav>
because the ul element only serves a mechanical separation purpose, it’s just a punctuation replacement, it conveys no extra “meaning”, it only serves an obsession for blindly wrapping links in lists. That’s what’s wrong: lists looked at as div’s with list bullets in front of them.
I mean, let’s talk about serious semantics, not semantics that suits your bad habits.
That it’s a list? That it needs delimiters? A menu is a list – so if you have a menu, use a list tag… That’s about as simple as you can get. If it’s not a menu and it’s a natural language sentence, P is probably more appropriate – if for some weird reason its’ not a list, use punctuation, or some other block level tag to separate them. Otherwise you’re just slapping words in there any old way and making a run-on of gibberish.
[QUOTE=itmitică;5084229]Consider this:
<nav>Here you’ll find <a href=“#”>pictures</a> and <a href=“#”>cookies.</a></nav>
[/quote]
Nothing wrong with that - natural language sentence where it’s clear they are separate thoughts.
[QUOTE=itmitică;5084229]Semantically equivalent to:
<nav>
<a href=“#”>Pictures</a>
<a href=“#”>Cookies</a>
</nav>
[/quote]
Not even close to semantically equivalent because there’s NOTHING separating them, nothing to put them in context, you’re just slapping words in there any old way! When dealing with semantics special or phrase elements do not break flow, therein they do not say they are separate choices, thoughts or destinations.
Lists, or add commas between them, or put it in a sentence, or add SOMETHING to tell us they are separate from each-other. Otherwise it’s just a run-on of words just slapped in there any old way… since:
“pictures cookies” with nothing else around it is gibberish; you need something to separate them – whitespace and anchors aren’t it!
In that example (and why I choose it) is that’s actually five cans – and since anchors apply NO MEANING or SEPARATION between then, You don’t know if they’re all five different choices, you don’t know if “My Profile Choices” are all one ‘can’ – That provides NOTHING to say there’s just three cans or if it’s just one big can or anything else!
Means a lot more, it means it’s a list; as opposed to without the list where it’s just a bunch of words with NOTHING separating them because as a special inline Anchors do NOT make them separate items!
Apart from saying it’s a list which is the ENTIRE reason semantically you’re supposed to do it in the first place… Calling good practice a bad habit and then slapping a bunch of text with NO punctuation or formatting at all?
RIGHT. That makes sense… Don’t know where you got that from, but WOW that’s some messed up nonsense that has NOTHING to do with proper practice of semantics, anything in either the HTML 4 or HTML 5 spec, and on the whole feels like you are pulling this out of your rump as we go.
You seem to be overfocusing on ‘list’ as opposed to ‘something to format the text, be it a list, natural language text, or punctuation’ – in fact you’re raving about lists like the anti-table folks who won’t even use tables on tabular data.
I was thinking on your re-using my examples to support your view on it, and more specifically your shelf analogy… My saying “you can’t tell if it’s five cans, three cans or one can” being better explained in another of my posts, and I just think it needs to be said again:
What you are defending is more like having a bookshelf where all the books have the same size pages, and you’ve ripped all the pages out of their bindings and just shoved them on a shelf end-to-end; good luck telling where one book begins and another book ends… because instead of nice neat covers containing sets of pages, you just have a endless stack of paper with no clear divisions.
“My Profile Settings Log Out” – is that five items? Three items? One Item? Your guess is as good as mine, and that’s what not having SOME FORM of delimiter other than whitespace basically is saying.
… and anchors aren’t delimiters. Screen readers, search engines, non-desktop screen renderers; they’ll have no clue – and that’s the entire REASON to use semantic markup instead of just sleazing out presentational markup of nothing but font, bold and line-breaks. At that point you should probably not even bother using HMTL/CSS and just ASCII format the text and set BODY to “white-space: pre;” with no other tags for all the difference it makes.
Since that’s basically what you’re advocating.
Let’s use an example you used:
<p>This is a <a href=“#”>picture</a> of a <a href=“#”>cookie</a>.</p>
Do you consider that four separate items, or a single sentence? It most certainly isn’t two items thanks to the CDATA textnodes, it’s certainly not four separate items because it’s all one flow text. Inline-level phrasing – as such removing all the text between them just makes it gibberish.
which clearly shows me you’re missing the point on nav, like you’re missing the point on a bunch of whole other HTML5 elements.
First off, a list can’t be used in menus unless those menus have a context for those lists. If you don’t have a context for a list, then you’re taking a shortcut. See my nav example where I show you need to have a context for a list.
Secondly, I’m glad to see you’ve adopted my view on navigation, that is that navigation can be links with everything, not just links in lists. That’s a step forward.
Slapping lists on a bunch of links just to structure them is opportunistic, is not semantic heaven. Much like pretending the content in nav has to make sense like a book chapter. But you insisted ul, and not div, or p, or some other elements, are a must, always and forever. I strongly disagree with you since.
And here is where you exaggerate: like I said, if you only have links, anchors are enough:
So? You’re kind of not making sense anymore.
I said that when you have other content in nav, you should use the proper elements for that content. I never said “restrain your self and put only links in there”, I said “Jason is wrong thinking nav is an ul element in disguise since he is wrong about using ul as a semantic element for a bunch of links in the first place”.
So, I have nothing against punctuation, paragraphs and such to be present in nav. Even lists, with the condition that there is a context requiring their presence. And that doesn’t mean you saying: “look, I see here lists of links”, no. Actual content that dictates a list to be present.
Since nav is pretty much self explanatory, just the anchors alone will do. If I have complex enough content in nav, meaning more than just a bunch of links, or links complex enough as content, then, other elements, semantic or not, but proper ones, non the less, can help better distinguish them. Only then.
Otherwise, you’re just following a bad habit: lists are for a bunch of links 'cos a benevolent dictator say so and you should obey No, I don’t! The dictator needs to change its attitude.
“There are two ways of living: giving a f-word, not giving a f-word. GIVE A NEGATIVE F-WORD !”
“Giving a negative f-word can destroy the universe as we know it !”
“I don’t care!!”
I think you’re not understanding my posts about as much as I’m not understanding yours.
The alleged purpose, the real one that holds any water, is it being a hint to certain user agents that it’s ok to skip what it wraps to get to the main content of the page – a minor and pointless aid not worthy of a tag… so why bother having the tag… Only thing I can fathom is to placate the people who go:
<div id=“nav”><ul>
Site after site you’ll see people wrapping a UL in a DIV – even if as you say it doesn’t need the UL, then it’s still extra wasted markup as anything they are doing to the div could be done to the UL, or vice versa – bad markup is bad markup, there’s no reason to justify it… most all of these allegedly semantic extra tags from HTML 5 seems to fall into one of two categories – legitimizing the bad practice of slapping extra DIV around everything for no good reason (HEADER, NAV and SECTION being the worst offenders) when the existing semantic tags and proper use of heading tags should already be providing MORE than enough semantics in that regard…
What does that even mean, “a context for a list”?!? I literally cannot figure out what it is you are even trying to say, or even what example that would apply to.
Adopt nothing, you were shoving words in people’s mouths and failing to understand what was being said from the start if you thought anyone here was saying otherwise!
Where did you see me say or even imply that – that has ABSOLUTELY NOTHING TO DO with any of my posts so far. If you thought I was saying that, then you completely failed to understand anything I was saying!
(in regards to 'every anchor on a page is navigation)
I was just saying that class=“nav” or id=“nav” or even NAV as a tag is uselessly vague; cryptic, not verbose… bordering on being gibberish – but again I’m a Wirth language type of guy, so I like to have meaningful class-names, meaningful function names, and fail to grasp this obsession of late on how “everything has to be abbreviated”… If every anchor on a page is navigation, what is the point of having a navigation tag? If every anchor on a page is navigation, how does class=“nav” under HTML 4 help anyone figure out what a list of links even is? It’s as uselessly vague as the idiocy you see from time to time of people going class=“style1” “style2” etc, etc… or the nonsense like class=“b lt qp dl ct cf”. Just like the idiotic ‘link src=“style.css”’ begging the question “which style?” – screen? Print? handheld?
Piss poor naming conventions make code harder to maintain - that’s all I was saying there.
which I think is the problem because I didn’t say that!!!. In fact my reading that you apparently thought that was my meaning just brought forth a string of expletives that would make truckers at a truck stop say “watch your mouth, there are mechanics in here.” If you thought that was my intent or what I was saying, you failed to comprehend my posts! COMPLETELY!
… and yet it appeared you were defending the LACK of such elements as valid, which is where I took issue. that is what you were saying and showing in your examples – as per this next bit I’m quoting:
Again, no they don’t… that’s EXACTLY what I’ve been saying is wrong and taking issue with as anchors do not change the flow and as such do not delimit the values in any way. Using JUST the anchors means no structure – words just slapped inside it any old way with no method whatsoever of telling that they are different thoughts. As in my last post, is that five separate items, three separate items, one separate items; it’s like a bookshelf filled with unbound pages of uniform size.
No, I’d be using a list around a list of choices; that’s what semantic markup is – lists around lists, headings around headings, paragraphs around paragraphs… I wouldn’t be using it ‘just because’. It’s certainly not a bad habit on say… menus, since menus are LISTS of choices.
Though I have no idea what that annoying **** was you linked to, or what it has to do with anything – had to kill it after five seconds for being too stupid.
You know noonope this little shell game of yours with accounts every time you get banned grows tiresome, as does your intentional belligerence and repeated attempts to take things out of context, stuff words in peoples mouths, and claim things were said that have nothing to do with the originating post.
Content that prepares you for a list appearing. Lists are not something you can just pull out of the sleeve whenever convenient.
“Site after site doing it” it’s not a reason. There was a time when “site after site” were doing tables for layout. And that became a bad habit.
[QUOTE=itmitică;5084229]
And if you want to use lists with that one, you really have to do something like this:
<nav>
<h1>Welcome</h1>
<p>Thank you for embarking on a journey around my website.</p>
<p>Here are the places I recommend you to visit:</p>
<ul>
<li><a href="#">My Profile</a></li>
<li><a href="#">Settings</a></li>
<li><a href="#">Log Out</a></li>
</ul>
</nav>
Notice the verbosity required?[/QUOTE]
Notice the p preparing the list? The whole heading and introductory stuff? Why would it be OK for you to say: “don’t strip down the nav to links alone” but it’s not OK for me to say “don’t strip down content to lists alone”, or “don’t just run lists out of the blue”? Since, like you, talking about more elements for links in nav, I believe you need more content in order to have lists anywhere, lists alone doesn’t cut it. At all.
I’ll leave it to that, since, apparently, it’s about to escalate into something else. Not on my behalf.
Off Topic:
You read too much into words and you document too little before jumping to conclusions and resorting to cheap shots:
Why isn’t it going to happen. Just imagine that we are far enough in the future for IE8 to be dead and gone.
At that point it becomes practical to use XHTML. At least some web browsers will stop at the point where they uncover a syntax error in the XHTML and will only render the page to that point followed by an error message telling you what is wrong. You use that information while TESTING your web page to fix the errors in the XHTML and get it rendering the page properly - only the final working version gets uploaded to the web and so all your visitors (except for the one person still using IE8) will see your page exactly the same. Only you got to see the broken version because you fixed the error that caused it to be broken before you uploaded it to the web. The result is that the uploaded XHTML web pages are all valid XHTML without even needing to mess about with validators.
The bad developers will be able to continue using HTML and uploading any old garbage to the web even where it isn’t valid HTML.
The only two things necessary for that to happen is for IE8 to die out and for the good developers to switch from using HTML to XHTML once all the browsers support it (and IE8 is the most recently released browser that doesn’t support XHTML).
So you are wrong - it is going to happen because there’s nothing to prevent it happening once IE8 is deaqd.
The context for that list is it’s a navigation. You don’t have to add all of that extra stuff to give it context.
And what’s wrong with being verbose? That’s what HTML is. It’s a verbose description of a document. If verbose was bad, then we should all just put stuff into as few divs as possible and ignore all the other elements.
As for the browser thing, I don’t see it happening where they are going to properly stop with XHTML syntax errors. If one browser doesn’t do it, then they are all going to implement “guessing”, because like that quote says: if a site breaks in a browser, people blame the browser, not the site or developer. So, if just one of them doesn’t do it, none of them will or they will “lose”.
Not so fast, or I might believe you’re always talking “lists”?
“I talked with Amy, Brad, Cindy and Joe to team with us at paintball”
vs
"I talked with:
o Amy
o Brad
o Cindy
o Joe
to team with us at paintball".
Yeah, yeah, punctuation. Only the content in nav is self described, much like elements in a phrase: subject, predicate, adjective. And since I don’t wrap spans around every word and punctuation in p, I don’t wrap every anchor in nav in li. If a few anchors is all I have in nav.
And I was making the same argument: what’s wrong with being verbose?
<nav>
<h1>Welcome</h1>
<p>Thank you for embarking on a journey around my website.</p>
<p>Here are the places I recommend you to visit: </p>
<ul>
<li><a href=“#”>My Profile</a></li>
<li><a href=“#”>Settings</a></li>
<li><a href=“#”>Log Out</a></li>
</ul>
</nav>.
And my whole point was, what’s wrong with being less verbose? Nothing, also.
No
<nav>Here you’ll find <a href=“#”>pictures</a> and <a href=“#”>cookies.</a></nav>
Links alone, by definition. No redundant elements. And no lists to force a false sense of semantics and since it’s not always about lists. Lists have their place less often then commodity dictates. And I mean here menus also.
If that sentence contained elements, I would put it in a list. However, that’s a sentence. It’s one paragraph, not a collection of elements (in the semantics of HTML).
You mention a phrase. All phrases are different. You have to analyze the phrase to determine what the various parts are. Same with HTML. You must analyze (and tell) the browser what each element is, because it can’t figure it out itself.
Also, you contradict yourself. You say a nav by definition means it’s filled with links… but your other nav example has lots of content. A list of links needs to be marked up as a list. It’s simple.
There is nothing with being verbose, but your example of being verbose:
<nav>
<h1>Welcome</h1>
<p>Thank you for embarking on a journey around my website.</p>
<p>Here are the places I recommend you to visit: </p>
<ul>
<li><a href="#">My Profile</a></li>
<li><a href="#">Settings</a></li>
<li><a href="#">Log Out</a></li>
</ul>
</nav>
is being verbose with the user. That’s completely different from being verbose with HTML.
I don’t know what you mean by “links alone, by defintion”. Nothing is defining that.
As DS said, that’d be interpreted as “Pictures Cookies”. The links aren’t redundant.
I’m not contradicting my self at all. I’ve said more than once that if the content in nav goes beyond just mere links, and if it’s complex enough, you can make semantic constructs for that content, which may include lists, but only if lists are required by that content’s context.
“Links alone, by definition” comes from the specs:
[B]The nav element represents […] a section with navigation links.
[…]
A nav element doesn’t have to contain a list, it can contain other kinds of content as well.
[…]
User agents […] can use this element as a way to determine what content on the page to initially skip and/or provide on request.[/B]
That makes “Pictures Cookies” good enough, no lists required. That is, is you can break the lists barrier, if you can get past this lists obsession, where you see lists everywhere.
Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer.
You can also see microdata annotations in the above example that use the schema.org vocabulary to provide the publication date and other metadata about the blog post.
In the following example, there are two nav elements, one for primary navigation around the site, and one for secondary navigation around the page itself.
A nav element doesn’t have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many <a
href="/school">school papers</a> are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a <a href="/school/thesis">thesis</a>.</p>
<p>To the west are several exits. One fun-looking exit is labeled <a
href="http://games.example.com/">"games"</a>. Another more
boring-looking exit is labeled <a
href="http://isp.example.net/">ISP™</a>.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>
Notice the first two have lists in them.
The third one doesn’t have a list. However, it does have a paragraph. It’s additional text to give meaning to the links. That is perfectly fine. However, there is no “Pictures Cookies”.
Make decisions on what you read in the specs. Those few examples in them will no be able to cover all possibilities.
nav is for links. Start from here.
Basically, an UA will look for nav and will expect to find links. It’s possible it may encounter other elements: headings, paragraphs even lists. But the one thing that will make nav a liar would be links missing not lists or verbosity missing. Forcing lists in there for verbosity whenever paragraphs are missing is just a habit gone bad.
Let’s step aside from lists a bit. You said paragraph. The paragraph is not there to give links meaning, is there to make you read a comprehensible phrase containing links. Verbosity: “Look at my Pictures. I’ll give you Cookies”.
If I don’t choose verbosity, putting only links in there is just fine: “Pictures Cookies”
Consider this:
Uită-te la [Pozele mele. Iți dau [URL="#"]Prăjituri](#).
Not being able to translate Romanian, you will still be able to get by, simply because anchors alone will do:
[Poze [URL="#"]Prăjituri](#)
Verbosity is no use if you don’t understand the natural language, whereas nav and simple links are good enough to relay the meaning. The same discussion I had in this thread about English and native speakers missing out on specs because they assume that English language rules all over. The nav element is for links not for poetry or prose. Those two would require different semantic approach. Not nav.
And yes, if content in some links is complex enough, say two or three words, you could add structural or semantic element to distinguish where one starts and where one ends. That doesn’t mean lists by default.
About lists.
To me, it seems that you look at the li element for links like a div element for content. But you pretend is for semantics.
Something along the lines of the next two examples being equivalent.
<ul>
<li><a href="#">Look at Pictures</a></li>
<li><a href="#">Eat Cookies</a></li>
</ul>
it’s structurally better then
<a href="#">Look at Pictures</a>
<a href="#">Eat Cookies</a>
But lists have to be required, not by the “I see lists here 'cos there are a bunch of links here with nothing more and that makes it a list” rule but by the content’s context. You need something more than something that spells out as list obsession.
[QUOTE=itmitică;5085864]
Nav is container for links. Those links don’t have to make sense when read together.
[/QUOTE]There is, however, an accessibility problem with adjacent links. See WebAIM for full details, but the relevant section is:
Adjacent links
When using a screen reader, it can sometimes be a little difficult to tell when link text ends and when another begins. JAWS says “link” before each link, which minimizes this problem, but it can be a little more difficult with Home Page Reader, which uses a female-sounding voice for all of the links. It is a good thing that the voice changes from a male-sounding voice to a female-sounding voice, but if there are five links in a row, the voice will not change at all in between links, which can lead to some confusion.
One solution is to provide a non-link character between each link. The vertical bar ( | ) is used quite often for this purpose. Another solution is to put the links in an ordered or numbered list. Screen readers tend to pause between list items, helping the user audibly distinguish between separate links.
I think I’ve acknowledged this part: [QUOTE=itmitică;5085856]And yes, if content in some links is complex enough, say two or three words, you could add structural or semantic element to distinguish where one starts and where one ends. That doesn’t mean lists by default.[/QUOTE]
The issue was raised in the early posts in the thread.
It’s solution to a problem outside the realm of semantics.
[QUOTE=itmitică;5085895]
It’s solution to a problem outside the realm of semantics.[/QUOTE]Unfortunately, semantics and accessibility are both relevant to good web design and I don’t see how it’s possible have a meaningful discussion of one without the other.
Nah, that’s pretty much hitting the nail on the head… since you’re basically saying to ignore semantics, structure and grammar.
Or actually providing structure since neither special or phrase elements do so. You are attributing capabilities to the anchor tag and/or whitespace that do not exist. Translating it to Romanian or even a ruby language wouldn’t change that.
[QUOTE=itmitică;5085951]You make it sound like I advocate bad design. That’s uncalled for.
[/QUOTE]I’m sorry if you feel that was a personal attack - that was not my intention. I was simply trying to express my own point of view, and if I worded it badly, then I apologise.
Next thing you’ll be talking about what a rouge I am going down to the local bizarre to buy some things, awaiting your next post with baited breath.