Actually I’ve been using CSS since at least 2004 (though probably well before that, I just know for a fact in 2004 I wasn’t =p) in place of tables.
Like I said, I can see the benefit of many of the new elements after reading over the specs and doing some research. They aren’t really meant directly for users, but will allow user agents to enhance the users experience.
Yes, the spec is incomplete right now (working draft) and the uses some things are clear as mud, but I think it’s definitely getting there. I see little harm in replacing certain divs with sections, articles, headers, footers, and navs when appropriate. At worst, the browser will just need to be shimmed to treat it like a div. At best, browsers will be able to give semantic meaning to those elements. Divs have no semantic meaning. Those and their cousins, spans, are purposely devoid of semantic meaning because sometimes you just need to group stuff.
Also, who cares if HTML5 is getting a bit looser with it’s specs (which honestly I have seen no real evidence of). We have nice strict specs right now and nobody follows them. Even if we made things more strict, they would still be just as abused. Browsers would still have to do their best to figure stuff out, because if they don’t, the browser gets blamed, not the site.
Just because HTML5 has looser standards doesn’t mean you have to choose to develop crap. Like I said, I still write code that can validate against HTML 4.01 Strict (with the exception of the new tags). I don’t necessarily have to, but I do.
Unrealistic expectations of time… and the “we need something new” without asking “why?” Syndrome. There seems to be this obsession some folks have with newer more faster change change change on things that work just fine if you bother using them right. Often times said changes/improvements are not improvements at all; “change for the sake of change” is just as bad as “status quo no matter how bad things get”.
A good well written computer language specification SHOULD remain largely unchanged for DECADES or more! You don’t see people clamoring to change Posix, and that dates back to the 60’s. Minor additions or removals should certainly happen along the way, but total overhauls and changes to structural rules for no good reason only make things more fractured, harder to deal with and harder to TEACH.
But it’s new and shiny, and for some people that’s all you need, who cares if there’s no meat underneath that glaze or it’s two steps back in terms of actual progress or improvements. Yum, shiny.
It’s why again, HTML 5 is documentative - it’s trying to document what’s possible instead of saying what we should do; and that’s not how one should write a specification used for building things. Construction specifications by definition should be authoritative; dictatorial even… 4 Strict was authoritative. Don’t use these, don’t use these, get rid of these, etc, etc…
People are using HTML5 and many are selling templates and themes creating with this. Eventually this WILL be pushed as a standard. I understand completely what you’re saying, but popularity is what conquers on the end of the day.
1. HTML5 will be ready for use in 20nn. No use until then. Notice I say “use” not “try”.
I’d point out that we’re constantly using software “not ready yet”. Your OS, *nix, Windows, Mac, all are constantly receiving updates, service packs. Your compiler. Your interpreter. Your everything in day to day production use. The same thing.
Browsers and browser vendors are doing exactly the same thing with HTML5. That makes HTML5 ready for use today.
2. Using “bloated” jQuery is no good.
Actually, I believe there are two kinds of programmers. Those that never miss a chance to get knee deep in low level coding and those that like code abstraction more.
It seems you are getting kicks out of being in the first category. That probably keeps your from being “jQuery friendly”.
I personally like an abstraction layer to keep me from reinventing the wheel each and every time, for once, and to help me be more concise in my programming logic. I appreciate jQuery and the likes. For productivity, if nothing more.
And that’s probably why you don’t like HAML or SASS also, even though they clearly make the way you write markup less bloated. Clearly.
3. A tag in XHTML is better than a tag in HTML. Even more so, it’s better than a tag in HTML5.
A tag is a tag is a tag. You could use it for good or for evil. One judges a page by the code in it not by the doctype it starts with.
And HTML5 is user friendly. Why would we want anything else? You want penalties for those writing bad markup? That’s not the name of the game.
The name of the game is helping those trying and acknowledging those that can write good markup. So you don’t punish those that can’t, you award those that can. But all must be served. This is not a natural selection contest. It’s a let’s get together world.
4. I agree CSS3 should help those with less knowledge, even though it breaks a few rules and steps over the markup and behavior barriers.
Doesn’t this contradict your view on “bloated” jQuery and your choice of a benevolent dictator for XHTML? The same rules that try to make it harder for developers, no matter their skill? You should take a side and stick to it.
5. A markup/scripting/programming language should remain unchanged for decades.
It’s not about the language. It’s about the change in platforms, in markets. New things emerge that require different approach. Change is only natural. If a kick in the behind is looked at as a step forward, it’s safely to look at HTML5 as an advance.
I don’t think you entirely grasped my view – or you just misunderstood it.
[QUOTE=itmitică;5082860]
What you say:
1. HTML5 will be ready for use in 20nn. No use until then. Notice I say “use” not “try”.[/quote]
Actually not really my point – to me it’s a “try and reject” as it offers no benefits and is a step backwards in terms of actual progress.
But unlike OS, HTML works just fine and doesn’t NEED those ‘updates’… updates to fix ACTUAL problems and updating for the sake of updating are a world apart; and not every new version is a good thing; see Win ME, Vista, Windows 8, Gnome 3/newer, KDE4…
Not even CLOSE to the same thing; comparing an unstable API to bugfix downloads? You’re kidding, right?
Ok, you understood that…
I see people talking about abstractions as a good thing; but we’re talking about an client side INTERPRETED LANGUAGE tied to limited pipe width, where frameworks, off the shelf libraries and any extraneous code is a waste…
ESPECIALLY when the ‘useful’ parts of said libraries like jquery serve only one real purpose… to take a semi-verbose language and make it needlessly crytic… If you’re going to dial the clock back to 1970 with cryptic symbols to reference things, why bother even using a high level language in the first place?!?
I’ll give you part of that – but it’s more that I’m sick to death of useful websites being flushed down the toilet by 500k or more scripting idiocy making the pages LESS useful than they were before the scriptards took over the industry.
That in most cases the things people do end up using 10k of script on top of the 100k library JUST to do what could have been done as 5k without the library; or worse is stupid animated crap that shouldn’t even be on a website in the first place since it pisses all over accessibility…
Just say no… That’s NOT productivity, it’s the exact opposite.
An extra layer of abstraction and need for precompilation of something that’s already a scripting format is NOT less bloat; makes you reliant on extra tools for nothing…
But really my problem with them is they make things more cryptic for no good reason – GOD FORBID you have to type out the name of something or use clear block delimiters. I mean this **** makes assembler look lean, elegant and simple; which is akin to calling the USS Nimitz same…
… and on that front it CERTAINLY doesn’t make things any easier to maintain since you’re just extending the toolchain, adding extra layers of abstraction, and using shorthand for everything; We’re not court stenographers.
Though that does seem to be the new trend in computing; a return to C’s fundemental concept of “how artificially difficult can we make programming by being as needlessly cryptic as possible?” – as if writing code that puts the annual obfuscation contest to shame is a badge of honor.
It isn’t.
Admittedly, my being a fan of Wirth family languages greatly colours my view on the subject.
Not sure where you’re getting I’m saying that – while I do prefer the stricter structural rules that help prevent you from shooting yourself in the foot in the first place (again, Wirth fan, Pascal won’t let you shoot yourself in the foot).
As you said, a tag is a tag – but some tags should never have existed since they don’t feed into the point of HTML (hence many of them being deprecated in STRICT), and tags should have clearly defined purposes – in fact they DO. God forbid we have clear consistent rules for using them.
I don’t see how looser rules is more user freindly – you can teach clearly defined rules; slap it together any old way is NOT user friendly in the long term – it’s a sleazy shortcut used for expedience that will come back and bite you sooner or later.
Because again, at that point god forbid we have clear rules and guides for people to follow, consistent use of the various bits for what they are for, so that everyone is on the same page and can consistently have easy to follow code… Just sleazing it out any old way makes everything SO much better, consistent and easier for the world… RIGHT.
Wow… You had to go to college to come up with something that… Ok, I won’t say it. Negative reinforcement is a GOOD THING, and the only real way for people to learn; People make mistakes, have them pointed out to them, and learn from the mistakes – shlepping along the re-re’s without telling them they’re doing something wrong is NOT going to help ANYONE learn a blasted thing.
… 99% of the time people are writing bad markup is that they’re learning from other people with bad markup skills, “specifications” you need a law degree to follow, or just aren’t being told they’re doing it wrong. Letting them continue to sleaze along does nobody any good – PARTICULARLY THEMSELVES!!!
While I prefer natural selection when it coems to WORK. Otherwise you’re just bailing out those who probably shouldn’t even be in the job. Just ask Wall Street about that… or not… or not…
Not even close to what I’m saying… I don’t see that it breaks any rules or “steps over markup and behavior” – where are you even getting that FROM?!?
Or are you in the crowd that considers stupid things like hover effects to be behaviors; when they aren’t… It’s NOT changing the content, it’s just changing how it’s PRESENTED. That’s not behavior, it’s presentation.
Not sure what you even mean by that – but again I don’t see it breaking the lines you seem to think it does…
RULES DO NOT MAKE THINGS HARDER!!! They make things easier since rules can be a guide to easily follow to build things. Having loose, barely defined or no rules at all is just chaos; making more work for everyone.
Again, GOD FORBID we have clearly defined simple rules, guidelines and recommendations. Nope, let’s just have everyone sleaze it out however they like; that’ll make things easier… RIGHT.
“safely to look at as an advance”?!? Having trouble deciphering what that even means… Englisc Moder Wyrter… but if said “advancement” involves removing rules, creating pointless redundancies, and enlarging the specification for no good reason – that’s not advancement.
… and yet notice they put block level containers in their examples, INCLUDING UL around menus – one of their examples:
<nav>
<h1>Navigation</h1>
<ul>
<li><a href="articles.html">Index of all articles</a></li>
<li><a href="today.html">Things sheeple need to wake up for today</a></li>
<li><a href="successes.html">Sheeple we have managed to wake</a></li>
</ul>
</nav>
They just include the H1 as part of the navigation block, despite not being a link.
NAV does not miraculously change how anchors behave in regards to their content, as such, if you removed the UL/LI you’d have what screen readers, search engines and people with CSS off would/should be reading as a single run-on sentence thus:
Index of all articles Things sheeple need to wake up for today Sheeple we have managed to wake
Not exactly a desirable result; making it a pointless extra element that could just as easily have been an attribute instead of an extra tag… for a smaller/tighter DOM, less code, and without screwing with the structural rules for no good reason.
JUST AS your use of an anchor to link to the spec didn’t magically break your sentence into multiple pieces. The only real purpose is serves is the last bit you quoted:
User agents […] can use this element as a way to determine what content on the page to initially skip and/or provide on request.
… and that couldn’t have just been an attribute on an existing tag or wrapper why exactly? Again, it exists JUST to justify the practice of wrapping extra tags around things that already have meanings… There’s no reason for that even to be a tag; and it would have neatly dodged the bullet of backwards compatibility.
Just like SECTION, just like HEADER, just like AUDIO, just like VIDEO… undoing the progress of strict by adding new redundancies and extra tags for no reason is not progress.
“safely to look at as an advance”, or "“safely to look at as progress”.
And no, I’m not referring to rollover effects. I mean the CSS3 that starts dictating what links do, how links behave like, instead of what links look like.
I’ve argued a few with Craig about that.
But I know you know that too. Those two are just part of classic Jason’s Gorilla War of Argument: first change the color of the weaker spots and then invade the whole place LOL
Again, links in nav are not part of a sentence.
Let’s say this:
you ask me: What countries are there in Eastern Europe?
and I may respond: Romania, Moldova, Bulgaria, Ukraine, Poland.
See what I did there: an enumeration. A list. If this was a conversation then yes, those would belong in a paragraph at least. They could also be in a list element. But that’s scenario number one for nav use.
Scenario number two: we’re not talking about content in nav like that, a conversation. Content in nav can also be plain simple: an enumeration of links. Without a story behind. Remember: “a section with navigation links”. So you don’t need to get on a stage and recite it. You just go through it, knowing it’s an enumeration.
Making the nav element redundant with list elements is what you have in mind and it’s because you don’t accept it’s role.
Indeed, put in nav some semantic elements and you have your self a complex content. After all, it is a section.
But put there just links and you have there a enumeration of links. This argument I’ve done it before with you.
Simple as that: complex content vs. simple content.
You don’t have to justify your links, but you can include them in a more complex content, if you feel like.
This is a whole other argument: HTML5 is so different in some areas that people with habits have trouble adjusting to it. Which is just fine, since HTML5 offers them the option of remaining true to their habits. Like SASS does: any valid CSS is also valid SASS.
Oh, and HAML, at least, does simplify the markup process and it does help you make fewer to no errors. But, like with HTML5, you should at least try it before use it. And then there’s Slim for you, if HAML is still your bad medicine.
What I don’t get is why are you still arguing that writing opening tags/closing tags is safer and smarter than having a mechanism in place to automatically do that for you, error free.
[QUOTE=itmitică;5082860]1. HTML5 will be ready for use in 20nn. No use until then. Notice I say “use” not “try”.
I’d point out that we’re constantly using software “not ready yet”. Your OS, *nix, Windows, Mac, all are constantly receiving updates, service packs. Your compiler. Your interpreter. Your everything in day to day production use. The same thing.[/quote]
No it isn’t - there is a huge difference between software that has already gone through ALPH, BETA GAMMA/PRODUCTION repeases and which is subsequently receiving minor patches. HTML 4 has received minor patches like that since its PRODUCTION release in 1997.
HTML 5 is still some years away from the ALPHA release stage.
and all are behind the current draft to varying extents since the HTML 5 draft can be updates several times a DAY and new browsers only come out a few times a YEAR.
Penalties for writing bad markup - such as refusing to display the page at all - is essential if we want to ensure that markup is written properly. That’s one of the biggest benefits of XHTML over HTML. It is also one of the benefits that “strict” mode JavaScript introduced. The errors you find and fix now are the ones that will not turn around and bite you in three years time when you make changes where the error actually creates problems.
Also HTML 5 allows you to define contradictions in your page such as specifying that an input field is mandatory but must be left empty both at the same time by introducing the useful patrtern attribute wnich makes the required attributealso introduced in HTML 5 obsolete. <input type=“text” required pattern=“^$”>
It also introduces multiple tags that all do the exact same thing - by the time HTML 5 becomes a standard all browsers will properly support using the object tag for those things that HTML 5 is proposing to introduce the iframe and embed tags for. The embed tag became obsolete when IE5 died and iframe will be obsolete once IE7 dies as the object tag works correctly for those purposes in all more recent browsers. A matter of shutting the barn door not only after the horse has gone but where all of the walls of the barn have been blown away as well.
Once IE8 dies there is likely to be a split in what languages are used for writing web pages. Those who want to use correct markup will use XHTML while those who don’t care will continue on as they have until now with the HTML 3.2 they currently use (although they might switch from the HTML 4 transitional doctype they currently use to pretend that they are using HTML 4 to using the short version of the doctype that doesn’t distinguish whether the page is written in HTML 2 or HTML 5).
As far as jQuery is concerned I see nothing wrong with people using it if they use it properly and their site is actually using most of the functionality it provides. Of course to be able to properly use a JavaScript library like that you need to understand JavaScript to a fairly advanced level in order to be able to properly understand how the jQuery code works. It is ridiculous how many sites there are that use 20 lines of code to call jQuery in order to do something that can be done in 10 lines of JavaScript without jQuery.
Neither of those makes any sense – I think the word “safely” is what’s throwing me since that’s an adverb, not a transitive verb. That whole statement ending up being akin to “When nine hundred years old you reach, look as good, you will not, hmmm?”
… and how is the behavior and PRESENTATION of that effect any different that using a hash link? Hell, if you look at the mechanism:
<section id="acc1">
<h2><a href="#acc1">Title One</a></h2>
<p>This content appears on page 1.</p>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum lacinia elit nec mi ornare et viverra massa pharetra. Phasellus mollis, massa sed suscipit pharetra.</p>
<p class="accnav"><a href="#acc2">next ➧</a></p>
</section>
It IS a hash link effect; it’s just being PRESENTED different – that’s not behavior, it’s not actually CHANGING the content or checking the content, it’s just presenting it in a different manner; WASTING javascript on that would be crossing the line; but people have been crossing that line from JS for ages with fat bloated stupid nonsense.
That’s not behavior.
Though personally I’d never put an effect like that on a website since transitions don’t work with auto, and fixed dimensions suck… but that’s a whole different argument.
and how is one saying that? With other tags, or in your case:
PUNCTUATION! Throw a few commas between them then fine, but I’m seeing people do this with 5:
Which is a laugh as semantically that’s the same as saying
<nav>HomeForumsLinks</nav>
Or this with 5:
<nav>
<a href=“#”>Home</a>
<a href=“#”>Forums</a>
<a href=“#”>Links</a>
</nav>
Which is the same as saying
<nav>Home Forums Links</nav> – the single block level wrapper doesn’t change that the special inline element A does jack to the meaning of it’s content.
Since anchor does NOT break word or change the meaning. You’re latching onto the word “sentence” when the more important part was – ok, let’s spell it out: “run-on of unstyled undelimited unbroken text with no pauses.”
See what I did there: an enumeration. A list. If this was a conversation then yes, those would belong in a paragraph at least. They could also be in a list element. But that’s scenario number one for nav use.
Enumerated by WHAT? Spaces are not a delimiter, and anchors do not change the meaning of what they are wrapping or add separation in any way, shape or form, which is why it’s just as valid to do:
<b>H</b>Home
or
<span>H</span>Home
or
<a href=“#” accesskey=“H”>H</a>ome
without breaking up the word…
While
<a href=“#”>Home</a>
<a href=“#”>Our Story</a>
“Home Our Story” with no delimiters makes about as much sense as “safely to look at as an an advance” or “engrish moist goodry I be speaking” – and that’s what omitting block level containers around them, delimiter text between them (punctuation), or any other form of separation means.
… and some people are trying to make it more different than it is – and different from what the specification and it’s examples even SAY.
Putting what you are saying squarely into the same category of nonsense as “text/html makes it not XHTML” or “full XHTML isn’t supported because you can’t do <div />” – it’s the same complete misunderstanding of what the specification pages even SAY.
Which again, look at their examples; still using list for menus, and the nav section that isn’t a list is in prose with paragraphs. The natural language of the text doing the job instead of just randomly slapping words together without block delimiters. Even your own argument uses commas as breaks/delimiters… whitespace and inline level tags are not a delimiter in HTML! EVEN 5!!!
Looks more like being too lazy to type out full opens and closes, which IMHO is more likely to cause errors/mistakes since you can’t clearly see them.
Oh yes, because removing ALL structural elements makes it even clearer… RIGHT… though I can see how it might be useful for people who can actually read with color syntax highlighting; which is to say USELESS for me since that headache inducing acid trip is one of the many ‘modern’ tools on my **** list of how not to learn to code.
Because it’s more cryptic, harder to read, likely breaks if you miss even something as simple as a tab, you can’t see where anything actually ends in a clear or realistic fashion or even indicate what is being cleared when scrolling down anything that’s bigger than you have lines on the screen.
Oh yes, such a big improvement. You know, there’s a reason Prolog was stillborn… and Ruby was stillborn until someone had the brilliant idea to make it do something useful with RAILS. But again, I’m a Wirth language guy – I’m all about verbose code with clear openings and endings to elements/blocks/sections. Relying on whitespace to handle it (python comes to mind) or using oddball shortcuts or funky orders to indicate it is NOT clear code; it’s the exact opposite…
All I can figure is hunt and peck people who can’t take the time to learn to use the input device they should know how to use are behind this garbage; see Ruby’s “elsif” or Mozilla “rust” for prime examples of that type of shortsighted half-assed idiocy in action… where it ends up being akin to class=“f l bR cf w90 a” – effectively useless a year after you write it or for the next poor shlub who comes along and has to maintain it.
though also, if you have enough markup to require those types of ‘shortcuts’ or precompilers… yeah, lets call it what it is, a precompiler… you have enough markup to need those, there’s probably something WRONG with your markup.
or that same 20 lines + jquery for something that’s CSS’ job. As we were joking about a year ago someone posts the question “how do I make a link red on hover” some script-tard will creep out of the woodwork saying “use jquery”.
As evidenced by the trash nube-bait found on sites like Dynamic Drive.
While something like this would be nice, since it’d make it much easier to separate the good and bad developers… it’s not going to happen.
As Tantek Çelik (Mozilla’s web standards lead) said in an interview with Eric Meyer: “When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device.”
Nobody is going to enforce the bad markup = nothing rendered strategy in their browser, because then the browsers that don’t look “better”. So, all of the browsers will contain to work on their “guessing” features so they can render bad markup. Unfortunately that’s how the real world works.
I think we’re wasting our breath hoping for this magical perfect world were all websites are coded properly. It’s not going to happen. The best we can do is continue to evangelize good practices and enforce them where we can.
HTML5 may not help curb bad habits, but that doesn’t mean it prohibits you from using self-enforce good practices.
I really don’t like the new none media tags of HTML5 to much but given everyone is huffing and puffing about it these days it would probably be difficult to get a job without something to show. I haven’t had to deal with it yet but I would assume dropping HTML5/CSS3 knowledge is a must. It may be crap… but the opinions of many outweigh the opinions of a small majority. Especially when those supporting it are leaders in the industry. A year or so back I though there might be hope but I have pretty much given up on that considering all the hype and promotion it is getting. At this point I’m thinking it is better to embrace it and make a good living than keep to achieve some self-fulfilling prophecy for nothing but a few pats on the back by a small majority. deathshadow60 or anyone can say how much HTML5 sucks and is not ready but the fact of the matter is all the promotion and support it is getting by the leaders in the industry makes it alright. Sad… but true. I may have just talked myself into using it to the full extent for my current project… oh this thread is dangerous…
The hype is something out of this world. It’s like when everybody was saying web 2.0 not knowing what this even was. Many even incorporate such words in their proposal. So you can imagine the ambiguity there.
HTML5 is a lot of the same. Many are using HTML5 knowing it does not improve, just to get on the bandwagon. Publishers, article writers etc. are all writing about HTML5 to join the hype and to get recognition whilst they do it. It’s like a vicious circle, but during that time you either profit from this circle or be left out. Big companies believe what they read and when they’ve read it they will no doubt post jobs in this related field. I’ve already seen well paid jobs asking for HTML5 and CSS3.
You keep saying you don’t want to phrase the content in nav… but you do. It’s a simple concept you can’t seem to grasp: links, one after the other, are not words in a sentence.
But I keep looking at you revolving around your tail, saying that the enumeration it’s not a sentence yet is should make sense as a text when read one after the other, like a sentence does. You require punctuation. There is no need for that. Links in nav are like cans in a shelf: pick one, don’t try to make the shelf a book you have to read. And I believe you manage to pick one even if they don’t have any punctuation to separate among them.
So… inspect the shelf, don’t read it. It will never make sense like that. Get it now?
And you’ll notice some examples in the specs that aren’t using lists. And those examples also have more complex content, that’s why there are a few more elements beside links in them.
Anyway.
Basically: when I put links in nav, by its definition, I don’t have to throw wrapping elements around them. Any other element element, beside links, means overkill.
Unless the content in the nav element is complex enough to demand another semantic construction. A simple enumeration of a few links is not. Is not.
Simple menus or multilevel menus spells out lists. Notice the difference: menus, nav.
And it doesn’t mean it was the right choice. Lists are used in menus because they degraded in a comprehensible way. Lists are used in menus for structure, and not for semantics needs. Lists replaced divs in menus and that was regarded as a semantics win. Is it?
What is a link? A piece of content, inside an anchor element.
What is nav? A section with links, pieces of content, inside anchor element. Like a shelf (nav), with cans (anchors), and the juicy content inside them. You’ll also notice the content in one can doesn’t run over the content in some other.
When I put links in nav, the content is already well delimited. Being inside the anchor tags. Automatically wrapping lists around them is overkill. Why slapping some other outer li tags around them will make more sense? Only because you can’t step outside of your habit’s box. A habit gone bad.
When do I think about putting other elements in the nav element? When my nav content starts telling a story. That is, when I have enough links and enough content to semantically structure that story. And using lists for that is but one way to tell that story.
When do I think about wrapping lists around links in nav? Only when is semantically viable. Which may be never. A list element has a place wrapping links only when is semantically required. Not to structure the content, to delimit the content, or in hope it will be, somehow, brighter than the sun
[QUOTE=itmitică;5083777]You keep saying you don’t want to phrase the content in nav… but you do. It’s a simple concept you can’t seem to grasp: links, one after the other, are not words in a sentence.
But I keep looking at you revolving around your tail, saying that the enumeration it’s not a sentence yet is should make sense as a text when read one after the other, like a sentence does. You require punctuation. There is no need for that. Links in nav are like cans in a shelf: pick one, don’t try to make the shelf a book you have to read. And I believe you manage to pick one even if they don’t have any punctuation to separate among them.
So… inspect the shelf, don’t read it. It will never make sense like that. Get it now?[/QUOTE]
Honestly, I’m wondering if we’re hitting up against ranguage rarrier, since I’m having a devil of a time figuring out what it is the above is even trying to say… “don’t want to phrase the content in nav”?!? What does that even MEAN? " don’t try to make the shelf a book you have to read"?!? HUH? Soon the super karate monkey death car would park in my space. But Jimmy has fancy plans… and pants to match.
So I’m not ‘getting it’ – because to be frank I’m having trouble deciphering what on earth you were even trying to say there… though that seems to be a problem with a LOT of posts 'round these parts lately. Like we’re getting this weird mix of Yoda and Super Karate Monkey Death Car.
Which is EXACTLY what I’m saying – they have more complex content because you need more complex content than just running out a bunch of words with no delimiters. Whitespace aren’t delimiters, anchors aren’t delimiters, so it’s just a jumble of nonsensical words. Putting it into sentences with punctuation, making it a comma separated list or using other punctuation, THEN it would make sense. Just going:
EVEN INSIDE NAV, is the same as omitting those anchors altogether gramatically and semantically. It is semantically the EXACT SAME THING as just going “My Profile Settings Log Out” as if there was no markup – which is gibberish where you can’t even tell where one thing begins and the next one ends. It’s WHY we were supposed to use lists on that stuff in the first place – and NAV does absolutely nothing to change that! Might as well be saying “The monkey clown horrible karate round and yummy like cute small baby chick would beat the donkey.”
enumerated by WHAT? Anchors don’t enumerate, spaces don’t enumerate, the wrapping container doesn’t enumerate them… You need delimiters or block level tags to SAY they’re enumerated – otherwise you’re just dumping random words or groups of words in there any old way… the OPPOSITE of semantic markup. You’re gonna do that one might as well go back to not using paragraphs and going with double-breaks and instead of using heading tags just do <font size=“+1”><b>
That’s what I think you’re missing – ANCHORS DO NOT CHANGE THE MEANING OR STRUCTURE OF THE TEXT THEY ARE APPLIED TO – HTML 5 does nothing to change that! Omitting block level containers, text delimiters or natural language is the same as taking your book shelf, ripping all the bindings off the books, cutting all the pages to the same side then stuffing them loose on the shelf end to end. Good luck finding where one book ends and the next begins.
Your verbose obsession over a simple enumeration of links. The fact that they are there one after the other, in a dedicated, semantic container element, that alone makes it a semantic enumeration. You’re trying to write a lengthy poem that bores the hell out of everybody, when a simple haiku is all your readers ask.
The links in nav HAVE NO MEANING. The CONTENT in which they appear, if any, has to have some meaning. But IF you only got links in it, then LISTS are the last things you can apply and say: “Whoa, semantics!”. It’s DIV’s you have to put there, for structure, not lists.
Off Topic:
You sure people understand better with caps on!? Or do you believe battles are easily won with cheap little angry sarcasm over language?! I won’t go down the Gorilla War path with you, I know better than that.
Nav is a semantic container. For “links”. Not for “lists of links”. You’re adding lists because you’re used to a lie: a ul, and an id=“nav” for it, equals the biggest semantic win. It was not. It still isn’t. It will never be.
You can add div’s to structure your links, you can add headings, paragraphs in the nav element, if you want it to make sense when reading it like a book, and it’s possible you may NEVER use lists in it. LISTS AREN’T A MUST!
Let’s say anchors don’t have a role to play: “ANCHORS DO NOT CHANGE THE MEANING OR STRUCTURE OF THE TEXT THEY ARE APPLIED TO”.
Well then, you make a ul, put some “regular” content in its li elements (no links what so ever), and then put an id=“nav” to your ul? Does it still apply? Is an anchor a missing link somehow?
After that, you make a ul, put some anchors in its li elements, and then put an id=“ניווט” to your ul? Does it still spell out as being a navigation element? Can you go straight to navigation then?
You’re missing a lot of points more often because you believe your native language rules over the whole world. Well, it’s not, and a nav element is one missing link over all natural languages involved in web developing. It’s a step forward. If you can see that.
No, because if I have a list I need to make it a list, instead of a bunch of words just thrown in there randomly with nothing separating them – and again, anchors don’t separate/delimit them. SPACES don’t separate/delimit them since you can also have spaces INSIDE them. You seem to think I’m saying you HAVE to use a list - and AGAIN I’m saying you need to use DELIMITERS, which could be a list, or P, or DIV, or commas, or hyphens, or natural language text.
Failing to add punctuation, block level containers of some sort (not just lists) or natural language texts – and just dumping the average menu into NAV without any extra markup is exactly that – just throwing the words in there any old way. That’s so simple I can’t understand how you could even argue it.
and…
It’s not about saying it’s a navigation, it’s about saying it’s a list – so that the words inside it are broken up semantically by SOMETHING instead of just being crapped inside a container any old way with NOTHING MEANINGFUL separating them. Why you are even bringing an ID into the equation is beyond me since that means jack so far as semantics are concerned and has nothing to even do with the discussion. Only reason to put an ID there is to hotlink to it with a hash or to target it with CSS or scripting… in other words NOTHING to do with the discussion.
Is gramatically and semantically the EXACT SAME THING as saying:
<nav>My Profile Settings Log out</nav>
Because anchor opens/closes are no more separating the content than a SPAN or B or I or any other phrase element would! If it’s a list of choices, you put it in a list; because as you implied and as the specification says, all that NAV means is that there are navigational links inside this block level container. “The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.” – That’s it…
It does NOT provide any formatting or structure for it’s content; as indicated by it being nothing more than a block level container and the ONLY reason for it’s existence according to the specification being as a indicator that allows some user agents to skip past it to get to the content. Which means if you have a list of choices, it still goes in a list. Which means if you have paragraphs, you put them in paragraphs… and if they are multiple separate items that don’t fit any of those descriptions, you’d use DIV, or punctuation, or any other form of delimiter to separate them grammatically.
Otherwise, AGAIN, you’re just dumping the words in there any old way with NOTHING to say they are separate items grammatically or structurally…
Geez, I’ve agreed and disagreed with DS about 50 times in this thread. =p
However, this time, I completely agree with DS.
Just because you are putting something in a nav element doesn’t mean you can neglect it’s other semantics. A list of items needs to be in a list element. Period.
DS’ sentence explanation is completely accurate, though it may seem a bit off.
However, consider this:
<p>This is a <a href=“#”>picture</a> of a <a href=“#”>cookie</a>.</p>
Do you agree that semantically is equivalent to:
<p>This is a picture of a cookie.</p>
(If you don’t, I give up now. =p)
So, why would the anchors magically give meaning to this?
One thing that’s nice about HTML is a list’s a list, a paragraph’s a paragraph, and so on. All elements have exactly one semantic meaning. Their parent containers have no influence on that meaning.
Which is why MOST of the fancy new HTML 5 structural elements are pointless redundancies – since the content inside them still needs semantic tags; Notice that for HEADER you’d still be putting numbered headings in them? The examples for NAV, ARTICLE and SECTION are wrapping tags that already have meaning? Putting extra ‘semantic’ meanings around tags that already HAVE meanings is pointless; yet that’s EXACTLY what the new elements seem to be for.
Which is why I still say if people bothered to use H1…H6 and HR properly, you wouldn’t need any of it excepting perhaps NAV’s suggestion of user agents skipping it in some instances – at which point why do we need a new tag?
While they are redundant now, a parent does give semantic meaning to it’s children (in a sense). For example, the nav element would help screen readers provide more consistent access to navigation (or at least a skip to navigation feature without the need to actually implement one).
Likewise, the section and article tags have the handy ability that you can restart your headers while still giving your document a proper outline (which is an amazing feature for CMS and the like). Also, nested sections and articles give meaning as well (an example they use is having a nested section in a blog post which could be for comments).
The time element is also a great one for providing a way to give machine-readable times while still providing the format you want for users.
I’m not saying I like all of them, but there are about a dozen that after studying the current specs and doing some research I’ve come to embrace. It still has some growing pains, but hopefully those will get sorted out and we’ll get something that adds new features without becoming redundant. The ones I currently like are nav, time, section, article, header, footer (when inside of section or article), video, audio (though they still have many growing pains ahead), and canvas (I’m on the fence with this one, in regards to if we need another element, but I use it because it’s the only real way to access the canvas API). I’m still undecided on the others.
Most of the elements don’t give the end-user anything new in and of themselves, however, it gives more semantic meaning to certain things, which then allows user agents to do things they couldn’t (or at least couldn’t reliably) before.
(It’s fun being in the middle, I get to argue no matter what is posted. =p)
