Moving over to HTML5

Printable View

Show 200 post(s) from this thread on one page

Mar 12, 2012, 08:05
Sega

Moving over to HTML5

I've been looking at the differences of XHTML and HTML5. I've always used XHTML but I feel it's about the right time for a change.

The main differences I spotted where the new tags which made things more semantic, this includes:
<content><header><nav><article><section><footer>

The doctype was much easier, as you did not need that long-winded doctype as we had before.

There are no self-closing tags either (as I've understood). To be honest I don't like this change. I feel all tags must be closed, or so I was taught back in university. Either case it is what it is and they seam to be history.

I've spotted to pretty cool new video and audio properties. I a bit scared of getting too deep on those. w3school has not examples of them, it just lists them, maybe examples would be a good way to know how to implement these.

I won't be taking a deep plunge just yet, but I feel it's time to start embrassing this new technology. If I missed anything please post something up. Hope this helps others to make the transition too.

Kind regards,
Sega
Mar 12, 2012, 09:16
Raghavender

Here are the useful links for html5 development...

http://www.diveintohtml5.com/table-o...ts.html#detect

http://html5doctor.com/article-archive/

Thanks,
Raghavender Reddy
Mar 12, 2012, 09:35
deathshadow60

Quote:

Originally Posted by Sega

I've been looking at the differences of XHTML and HTML5. I've always used XHTML but I feel it's about the right time for a change.

Wow, that must have been some heavy drinking and/or smoking to come up with that choice. Sorry, but I can't fathom why anyone sees a benefit to it.

Quote:

Originally Posted by Sega

The main differences I spotted where the new tags which made things more semantic, this includes:
<content><header><nav><article><section><footer>

You mean the pointless and redundant tags that exist JUST to placate the people who slap extra DIV around things for no reason? Section is flat out redundant to DIV -- which is to DIVide the content into sections, NAV's alleged semantics and accessibility doesn't work in anything, and just adds an element to the dom for no reason on what should probably have just been an attribute on lists, HEADER is pointless nonsense since we already HAVE heading tags, and if you bother using heading tags and horizontal rules properly you don't need header, section, content or footer! But apparenlty with people being too stupid to understand how those are supposed to work and after decades of people not bothering to learn more than ten tags and a quarter the attributes, it's time to throw more tags at it, because that will fix everything...

About the only one that makes is Article -- really, I can't say that's worth it either; sure, it might someday help with screen readers and data scrapers, but much like meta tags on files it's just bloat nobody is going to use properly.

Quote:

Originally Posted by Sega

The doctype was much easier, as you did not need that long-winded doctype as we had before.

Because god forbid you declare EXACTLY which specification you are using ,have accurate versioning, and a link back to the document defining the structure. (of course, god forbid any of the browser makers got off their blasted backsides and USED said link for what it's FOR!)

Quote:

Originally Posted by Sega

There are no self-closing tags either (as I've understood). To be honest I don't like this change. I feel all tags must be closed, or so I was taught back in university. Either case it is what it is and they seam to be history.

Again part of why I think HTML 5 is undoing ALL of the progress of the past decade with STRICT; We finally started to get people on board for this **** two or three years ago, now let's just crap all over it and take a trip in the wayback machine with Mr. Peabody.

Quote:

Originally Posted by Sega

I've spotted to pretty cool new video and audio properties.

Which could/should have been applied to OBJECT instead of introducing two new REDUNDANT tags... and of course it's worked wonders for getting it so content providers only have to worry about one data format instead of having to deploy three or four different formats... oh wait, NO IT HASN'T -- It's more fractured than EVER -- It's more fractured than the peak of WMP vs. MOV vs. Flash vs. Realplayer (a fight flash won for good reason) -- These tags exist for the sole purpose of each browser maker pimping their favorite pet codec technology; well, that and letting the teenagers fapping to the idea of Ogg actually feel like their rubbish codec counts for something -- It's almost bad enough to make one wish for the days of Realplayer vs. WMP. I said ALMOST.

Quote:

Originally Posted by Sega

I won't be taking a deep plunge just yet, but I feel it's time to start embrassing this new technology. If I missed anything please post something up. Hope this helps others to make the transition too.

I think you meant embracing... though honestly you look too deep into it, it's outright embarrassing what a disaster the steaming pile of manure known as HTML 5 is so far as markup goes.

Again, I can't believe anyone even wants to use it in the first place or sees any advantage to it! It's a step BACKWARDS!!! In terms of coding practices, redundancies, loosening and outright discarding structural rules, and pointless bloat -- it's the worst of HTML 3.2 and browser specific nonsense all over again...

... and now it's getting worse since it's a sick buzzword the suits are latching onto like they did "web 2.0" or "SEO"... where the sleazeball scam artists can just mention it and the suits bob their heads because they heard it mentioned in Forbes.... and getting IT advice from the pages of Forbes is like getting financial advice from Popular Electronics.
Mar 12, 2012, 13:51
TehYoyo

Quote:

Originally Posted by deathshadow60

Wow, that must have been some heavy drinking and/or smoking to come up with that choice. Sorry, but I can't fathom why anyone sees a benefit to it.

You mean the pointless and redundant tags that exist JUST to placate the people who slap extra DIV around things for no reason? Section is flat out redundant to DIV -- which is to DIVide the content into sections, NAV's alleged semantics and accessibility doesn't work in anything, and just adds an element to the dom for no reason on what should probably have just been an attribute on lists, HEADER is pointless nonsense since we already HAVE heading tags, and if you bother using heading tags and horizontal rules properly you don't need header, section, content or footer! But apparenlty with people being too stupid to understand how those are supposed to work and after decades of people not bothering to learn more than ten tags and a quarter the attributes, it's time to throw more tags at it, because that will fix everything...

About the only one that makes is Article -- really, I can't say that's worth it either; sure, it might someday help with screen readers and data scrapers, but much like meta tags on files it's just bloat nobody is going to use properly.

Because god forbid you declare EXACTLY which specification you are using ,have accurate versioning, and a link back to the document defining the structure. (of course, god forbid any of the browser makers got off their blasted backsides and USED said link for what it's FOR!)

Again part of why I think HTML 5 is undoing ALL of the progress of the past decade with STRICT; We finally started to get people on board for this **** two or three years ago, now let's just crap all over it and take a trip in the wayback machine with Mr. Peabody.

Which could/should have been applied to OBJECT instead of introducing two new REDUNDANT tags... and of course it's worked wonders for getting it so content providers only have to worry about one data format instead of having to deploy three or four different formats... oh wait, NO IT HASN'T -- It's more fractured than EVER -- It's more fractured than the peak of WMP vs. MOV vs. Flash vs. Realplayer (a fight flash won for good reason) -- These tags exist for the sole purpose of each browser maker pimping their favorite pet codec technology; well, that and letting the teenagers fapping to the idea of Ogg actually feel like their rubbish codec counts for something -- It's almost bad enough to make one wish for the days of Realplayer vs. WMP. I said ALMOST.

I think you meant embracing... though honestly you look too deep into it, it's outright embarrassing what a disaster the steaming pile of manure known as HTML 5 is so far as markup goes.

Again, I can't believe anyone even wants to use it in the first place or sees any advantage to it! It's a step BACKWARDS!!! In terms of coding practices, redundancies, loosening and outright discarding structural rules, and pointless bloat -- it's the worst of HTML 3.2 and browser specific nonsense all over again...

... and now it's getting worse since it's a sick buzzword the suits are latching onto like they did "web 2.0" or "SEO"... where the sleazeball scam artists can just mention it and the suits bob their heads because they heard it mentioned in Forbes.... and getting IT advice from the pages of Forbes is like getting financial advice from Popular Electronics.

Ah, c'mon DS. Lighten up. He did say 'kind regards' to you.

Sega, what I think he's trying to say is that HTML5 is still a draft and, while it does help old, poorly developed websites display correctly, it is a step backwards in the general, overall development of the web. I don't think it's a step forward, although it does have some interesting features. To be honest, CSS3 is more exciting.

I wouldn't recommend using it right now. Especially when it's only a draft and still well away from a rec.

~TehYoyo
Mar 12, 2012, 14:02
Sega

Hello deathshadow :) How are things?

Quote:

Originally Posted by deathshadow60

Wow, that must have been some heavy drinking and/or smoking to come up with that choice. Sorry, but I can't fathom why anyone sees a benefit to it.

It's the future, and I don't want to be left behind. I see templates and everything else being done in HTML5. I've recently got involved in template development so being up-to-date is important.

Quote:

You mean the pointless and redundant tags that exist JUST to placate the people who slap extra DIV around things for no reason? Section is flat out redundant to DIV -- which is to DIVide the content into sections, NAV's alleged semantics and accessibility doesn't work in anything, and just adds an element to the dom for no reason on what should probably have just been an attribute on lists, HEADER is pointless nonsense since we already HAVE heading tags, and if you bother using heading tags and horizontal rules properly you don't need header, section, content or footer! But apparenlty with people being too stupid to understand how those are supposed to work and after decades of people not bothering to learn more than ten tags and a quarter the attributes, it's time to throw more tags at it, because that will fix everything...

These new tags make reading the code easier. You're completely right, as they are all DIV tags, irrespective of their name. The new properties allow you to section the page easier. If I thought HTML5 was going to be dropped I'd not bother learning it.

Quote:

Again part of why I think HTML 5 is undoing ALL of the progress of the past decade with STRICT; We finally started to get people on board for this **** two or three years ago, now let's just crap all over it and take a trip in the wayback machine with Mr. Peabody.

I was onboard years ago, but I dread to think of myself using an old markup language.

Quote:

I think you meant embracing... though honestly you look too deep into it, it's outright embarrassing what a disaster the steaming pile of manure known as HTML 5 is so far as markup goes.

Here is a question for you, where do you see HTML5 in the future, and do you really see it vanishing before people make it the standard.

Edit:

Quote:

Originally Posted by TehYoyo

Ah, c'mon DS. Lighten up. He did say 'kind regards' to you.

I find the perspective funny yet true at the same time. :) all in good fun. I love reading some his posts anyhow :)
Mar 12, 2012, 14:10
TechnoBear

Quote:

Originally Posted by TehYoyo

Sega, what I think he's trying to say is that HTML5 is still a draft and, while it does help old, poorly developed websites display correctly, it is a step backwards in the general, overall development of the web.

I don't understand your thinking here. "Old, poorly developed websites" will presumably have been built before HTML5 was even a twinkle in the eye of the W3C. :confused:
Mar 12, 2012, 14:12
Sega

Quote:

I wouldn't recommend using it right now. Especially when it's only a draft and still well away from a rec.

Template Forest has lots of HTML5 templates and they seem to be selling quite well. In fact I listen to Grooveshark and that's been coded in HTML5. There is a dozen or so games developed using HTML5 including Angry Birds and Cut the Robe. People, companies and even Sitepoint (look at the homepage) are pushing HTML5 is if people are suppose to be using it now.
Mar 12, 2012, 14:41
TehYoyo

Quote:

Originally Posted by Sega

Template Forest has lots of HTML5 templates and they seem to be selling quite well. In fact I listen to Grooveshark and that's been coded in HTML5. There is a dozen or so games developed using HTML5 including Angry Birds and Cut the Robe. People, companies and even Sitepoint (look at the homepage) are pushing HTML5 is if people are suppose to be using it now.

Well then those people are wrong. People proclaim that HTML5 will be good (which, it probably will). Not that you should drop everything and use it. The homepage for Sitepoint is XHTML strict, a good doctype to use. Sure, companies develop in HTML5. Google, Facebook, use the HTML5 doctype, which is alright (and advised by @samanime ;). I'm curious to hear his/her motives as to this. You shouldn't, however use the new tags, though, because users w/out JavaScript on IE will have it broken.

Quote:

Originally Posted by TechnoBear

I don't understand your thinking here. "Old, poorly developed websites" will presumably have been built before HTML5 was even a twinkle in the eye of the W3C. :confused:

What I'm trying to say is that HTML5 increases acceptance for previously deprecated attributes and tags like target and align (if I'm not mistaken)

~TehYoyo
Mar 12, 2012, 14:47
felgall

XHTML is much closer in the future than HTML 5 is. To be able to use XHTML we just need to wait for IE8 to die off since it and earlier versions of IE didn't support XHTML.

HTML 5 is still only at the working draft stage and contains lots of tags that serve the same purpose or contradict one another. A draft standard exists so that people can try out the alternatives to work out which of them works best. Presumably most of these superfluous tags will be gone by the time that HTML 5 reaches the ALPHA (candidate) release stage. When HTML 5 is finally released for general use it will need to have a more specific doctype in order to 1. be able to distinguish between the final version and the current early draft in what is allowed and 2. to be able to specify whether obsolete tags and attributes should be allowed in the page or not. If you run a page using the current doctype through a validator the validator has no way to tell whether the page is written in HTML 2 or HTML 5 as that doctype is equally valid for both of those versions and everything in between.

To be able to actually use HTML 5 properly will probably require waiting for IE15 to die (or possibly Chrome 168) as one or more such browser will probably not recognise everything properly according to the final standard.

So XHTML 5 is a lot further away in the future before it will be able to be used properly than XHTML is.
Mar 12, 2012, 14:55
TechnoBear

Quote:

Originally Posted by TehYoyo

What I'm trying to say is that HTML5 increases acceptance for previously deprecated attributes and tags like target and align (if I'm not mistaken)

Ummm... tags that were deprecated in HTML4 were deprecated for good reason. Those of us who care about web standards, accessibility, etc. don't use them, and don't find them any more "acceptable" because they might be back in the HTML5 specs. Browsers will go on displaying them the way they always have, so old, badly-built sites will still work as well as they ever did. That's to do with browsers, not HTML5. As deathshadow60 and others keep saying, HTML5 is a backwards step - and (IMO) they're right.
Mar 12, 2012, 14:58
itmitică

Looking at this thread and reading some people's concern that something may actually change and it's out of their control, brings a movie to mind.

And no, it's not Great Expectations (1946), it's The 40 Year Old Virgin (2005). :) LOL

Stop with the whining and use it already ;)

Or don't. Just stop trying to tell others not to try it. That's just wrong.

Let's be practical.

Logic and facts says no spec will ever be at least 75% supported by all browsers. That doesn't stop people proclaiming about XHTML. Which even now it's not fully supported by all UAs. And I have yet to see HTML5 breaking pages like XHTML does.

If we were to expect for all browsers and all users to reach the same technological level, we would never could understand what's wrong with earlier versions.

And that's why those that want to try HTML5 should be supported. The earlier adoption and the earlier use, the faster it's weaknesses will be revealed. They do all the work for you. So let's be supportive.

Standing on our hands will not bring us a magical spec and a magical browser.

That's why I think an open mind an a clear voice is better. Let's not love to hate.

Criticizing is easy. How about showing what can be done the best with what there is. After all, HTML5 means hard work. Let's respect that.

And if you want something to criticize, turn to CSS3. It's taking over content and behavior with easy implementations for feats that otherwise required more knowledge. Javascript should be easier instead, and jQuery certainly helps us. Another hard work example taken lightly.

And even then, use a reasonable tone. HTML5 and CSS3 are there trying to help us all. If one wants stuff made to feel good about him self, one should build it. Otherwise, one should use it. Or not. Respectfully.

One little observation: <div id="nav"> or <ul id="nav"> is not XHTML in it's purest form. It's simply put, low grade HTML.

And HTML5's <nav> it's not meant to replace that <div> or <ul> with a "nav" id. That's plain moronic, to think something like that. It's meant to finally put an element in place with what www is all about: navigation.
Mar 12, 2012, 15:40
TehYoyo

Quote:

Originally Posted by TechnoBear

Ummm... tags that were deprecated in HTML4 were deprecated for good reason. Those of us who care about web standards, accessibility, etc. don't use them, and don't find them any more "acceptable" because they might be back in the HTML5 specs. Browsers will go on displaying them the way they always have, so old, badly-built sites will still work as well as they ever did. That's to do with browsers, not HTML5. As deathshadow60 and others keep saying, HTML5 is a backwards step - and (IMO) they're right.

Wait...didn't I say that?

Quote:

Originally Posted by itmitică

Looking at this thread and reading some people's concern that something may actually change and it's out of their control, brings a movie to mind.

And no, it's not Great Expectations (1946), it's The 40 Year Old Virgin (2005). :) LOL

I don't get it. What movie is this?

Quote:

Stop with the whining and use it already ;)

Or don't. Just stop trying to tell others not to try it. That's just wrong.

It's wrong to advocate web practices? Huh. *Looks in web rules book* Ah...nope. don't see it. We're (or at least I'm) not trying to tell other people to not try it. But to use it, I wouldn't advise.

Quote:

Let's be practical.

Oh, we're being very practical.

Quote:

Logic and facts says no spec will ever be at least 75% supported by all browsers. That doesn't stop people proclaiming about XHTML. Which even now it's not fully supported by all UAs. And I have yet to see HTML5 breaking pages like XHTML does.

Huh...
*boots up IE8 (default Windows browser, 18.86% of the entire web community) and disables JavaScript*
Ah, yep. Yeah. Um..not workin' out for me.

Even so, even if it doesn't "break" web pages, it supports bad practice and takes a step backwards into sloppy web development.

Quote:

Standing on our hands will not bring us a magical spec and a magical browser.

Which is why we're advocating best practices and trying to get developers (not users/clients) to get to the level that they should be at.

Quote:

That's why I think an open mind an a clear voice is better. Let's not love to hate.

Let's not make generalizations. I like to think that I have both. And I don't think I've done anything that would imply that I "love to hate".

Quote:

Criticizing is easy. How about showing what can be done the best with what there is. After all, HTML5 means hard work. Let's respect that.

Exactly. Let's do our best with the specifications and recommendations.

Quote:

And if you want something to criticize, turn to CSS3. It's taking over content and behavior with easy implementations for feats that otherwise required more knowledge. Javascript should be easier instead, and jQuery certainly helps us. Another hard work example taken lightly.

Huh? On the contrary, I really like CSS3. And I would recommend using CSS over JavaScript because it's easier to understand/implement. And it's quicker (?).

~TehYoyo
Mar 12, 2012, 16:04
samanime

The reason I advocate the HTML 5 DOCTYPE is simple: it's short. =p

Seriously, that's my reasoning. Browsers handle it just fine and it's easier to remember.

Most people like to use the (X)HTML Strict DOCTYPEs because it enforcing good coding standards. However, I think this is a bit redundant. If you are a good coder and following good standards, why do you need to have the DOCTYPE to force you? If you code good HTML, it should validate. HTML 5 makes the self-closing /> optional, so you can use it or not, depending if you want to write XHTML or HTML. I personally prefer the later. It doesn't make my code any less standards compliant, and doesn't make my code any more sloppy.

When I validate, I want to validate strictly, so I'll generally mask the DOCTYPE, but that's because the HTML 5 validator is still experimental.

On the topic of the new HTML 5 tags, I have to admit... I see the point of some of them.

I'm working on a new pet project of mine and decided there was no harm in playing around with some of the new tags. I still think nav is redundant and won't use it. However, after doing some research I see a point to section, article (and header and footer).

DS claims it is redundant to div, but after doing more research, I have to disagree.

A section is a specific block of content. While this is sometimes redundant with div, it isn't always. The reason is sometimes you just have to use a div for a certain effect.

Take this for example (assume there is more and your code legitimately should look like this =p):

Code:

<div id="main"> <div id="section"> <h1>Something</h1> <p>I'm content. There are several paragraphs here, blah blah.</p> </div> </div>

Now, if a machine was to look at that, it has two choices: treat main and section both as a section of the site (and thus wind up with redundant blocks) or treat them both as fluff and ignore their logical groupings altogether.

Now, look at this example:

Code:

<div id="main"> <section> <h1>Something</h1> <p>I'm content. There are several paragraphs here, blah blah.</p> </section> </div>

Now section has semantic meaning, because it is indicating that it's contents have a logical grouping, and div can safely be ignored as fluff.

The same applies for the article element (the difference between the two is that article is meant for articles (blog posts, news articles, etc) while section is any general logical grouping.

Another boon is you can restart your headers within a section and article while still giving it a proper document flow (this is great when the content writers are someone that isn't the developer).

The new header and footer elements aren't really meant to provide global headers and footers, but to provide headers and footers to sections and articles.

Also, I like the datetime tag for properly marking up dates and times.

I haven't found much of a reason for the others, but for now at least I am a fan of: section, article, header, footer, datetime

Have at me, DS. =p

Oh, the new required attribute for input elements is also awesome. =p
Mar 12, 2012, 18:43
oddz

I will be honest. The only reason I have considered using HTML5 on a project is that I won't be left behind in the dust. I can fully understand that considering it seems to be all the hype these days. I have read and experimented with it but have yet to truly use it to it's capacity on any professional project for the reasons mentioned. Though I have developed "HTML5" sites by merely using the "HTML5" doctype. That is really the only way one can quantify a document as "HTML5" anyway. This is not say that if a project requires a useful "HTML5" technology like geolocation I won't use it. However, when I have total control over HTML I start with HTML4, validate against it than merely switch the doctype. I like deathshadow60 do find the new tags to be quit cumbersome and in many ways pointless. Though I definitely relate to the peer proessure of using it and fear one might fall behind the times given all the promotion it has. I don't see that going away anytime soon and I don't really forsee the w3c rewriting the spec in major way. Given that and peer pressure blame it on the w3c not the developers using it I say. I mean… it is near impossible to come across a job classified what doesn't mention to some capacity HTML5. So perhaps it all comes down – Don't hate the player hate the game.
Mar 12, 2012, 19:36
felgall

I think Wikipedia actually has a really clear explanation of what a W3C working draft (which is the stage HTML 5 is currently at) really means:

Quote:

At the working draft level, the standard is published for review by "the community". A WD document is the first form of a standard that is publicly available. Commentary by virtually anyone is accepted, though no promises are made with regard to action on any particular element of said commentary.

At this stage, the standard document may likely have significant differences from its final form. As such, any who implement WD standards should be ready to significantly modify their implementations as the standard matures.

http://en.wikipedia.org/wiki/W3C_recommendation

(emphasis mine)

Basically it exists so you can try it out and then tell them what parts are useful and what parts are garbage. All the garbage parts will eventually be removed from the draft.
Mar 12, 2012, 20:23
oddz

Well people have to think they are garbage first. With the big names that are promoting them I don't see them being scrapped. Seems like every well known developer is promoting the newer HTML5 tags these days.
Mar 13, 2012, 00:48
Sega

Oh man, I think I've sparked a big discussion here.

I have to completely agree with oddz here. I found many jobs which ask for HTML5 and CSS3, and this hype is really pushing things forward. How much will HTML5 change is unbeknown to me. I feel the old tags will probably go, and also a doctype will be incorporated. This self-enclosing thing is bull in my humble opinion.

To be honest I don't remember which tags were dropped in the XHTML revision back in the uni days, maybe somebody should remind me. In either case what I started learning I stuck with, and this would be my goal with HTML5. Using something that lasts, and not using it only having to change my methods once again.

When HTML5 is officially releases people would be looking at I don't know, HTML6. HTML5 might be a Vista of the web, who knows. I personally don't feel it would go in this direction. XHTML is the proper way of doing things, but just like jQuery took over traditionally coding JavaScript, HTML5 will be preferred to XHTML as it's easier.
Mar 13, 2012, 01:33
deathshadow60

Quote:

Originally Posted by Sega

It's the future, and I don't want to be left behind.

If that's the future, I'm fine RIGHT HERE. Newer isn't always better, and it's not like the old specifications (that are ACTUALLY specifications) are going anywhere.

Quote:

Originally Posted by Sega

I see templates and everything else being done in HTML5. I've recently got involved in template development so being up-to-date is important.

... and with 99% of stock templates being asshat rubbish only nubes are typically dumb enough to try to use, it's not exactly surprising these are the folks embracing this nonsense. That turdpress now defaults to it along with the rest of their markup that screams "we have no business making HTML or CSS" it only further compounds the issue.

Quote:

Originally Posted by Sega

These new tags make reading the code easier.

I don't find it so because they are nothing more than extra tags in the markup that are likely wrapping tags that ALREADY HAVE meanings. More code is not the answer, just as more tags is not the answer.

The majority of people writing code right now are blissfully unaware of two-thirds the tags we're supposed to be using; LEGEND, LABEL, TH, THEAD, TBODY, CAPTION, DEL, FIELDSET, BLOCKQUOTE -- most people writing code can't even keep PRE and CODE straight, and waste time wrapping tags that already have meanings in extra elements like DL or tables.... THROWING MORE TAGS AT THEM IS NOT THE ANSWER when people can't even keep straight what we already have!

Much less their all being redundant -- STRICT was ABOUT removing redundancies and getting rid of browser specific crap; HTML 5 is about adding redundancies and getting down on one's knees in front of the proverbial equine known as the browser makers.

Quote:

Originally Posted by Sega

You're completely right, as they are all DIV tags, irrespective of their name. The new properties allow you to section the page easier.

I'm not saying they're DIV tags, I'm saying they are pointless extra wrappers that shouldn't even be in the markup in the first place if people would bother having logical document structure and using numbered headings with horizontal rules PROPERLY...

Quote:

Originally Posted by Sega

If I thought HTML5 was going to be dropped I'd not bother learning it.

It's probably not going anywhere, there's just no legitimate reason to use it apart from nube predation, selling more books and seats at lectures, and giving the suits a new buzzword they don't actually understand. It most certainly is NOT about writing sites in a better manner or actually making development easier/clearer/cleaner/faster.

Quote:

Originally Posted by Sega

I was onboard years ago, but I dread to think of myself using an old markup language.

Would you want the car you're driving your family around in to be built by committee using a draft specification? Or would you prefer tried and true methods that work in the here and now and are unlikely to ever break moving forward.

... and even if it does finally leave 'draft' it offers no benefits other than bloating out pages for NOTHING, further fracturing the already fractured codec scene, and pissing all over accessibility in the name of improving it. Does the term "snake oil" ring a bell?

Quote:

Originally Posted by Sega

Here is a question for you, where do you see HTML5 in the future, and do you really see it vanishing before people make it the standard.

While I hope so, I think with so many people on-board it's going to be an uphill fight to stamp out this idiocy just as we STILL have people today sleazing out tranny with their heads stuck up 1997's backside... which is EXACTLY what we need to do with it; STAMP IT OUT -- We need to spread the word that this sick new trend offers ZERO real world improvements.

That or wait for HTML 6 to come in both transitional and STRICT, with STRICT deprecating most of what's in 5.

Quote:

Originally Posted by TechnoBear

I don't understand your thinking here. "Old, poorly developed websites" will presumably have been built before HTML5 was even a twinkle in the eye of the W3C. :confused:

Actually it makes perfect sense -- because all the asshat bull we've been told NOT to do since STRICT was introduced is now perfectly fine and acceptable in 5. Again, the loosening of the structural rules and undoing of everything STRICT gave us is precisely why HTML 5 is meant for the people who were still writing HTML 3.2 and slapping a 4 tranny doctype on it. Now they can wrap HTML 5's lip-service around it and continue to sleaze out their crappy code any old way; GO PROGRESS!

Remember, 5 is documentative, not authoritive -- which is why it's an insult to engineers everywhere to even call this bull a specification!

Quote:

Originally Posted by TechnoBear

Ummm... tags that were deprecated in HTML4 were deprecated for good reason. Those of us who care about web standards, accessibility, etc. don't use them, and don't find them any more "acceptable" because they might be back in the HTML5 specs.

... and is EXACTLY why I reject HTML 5 outright. Call me when someone who understood the point of STRICT is put in charge and they go back to saying what you SHOULD use and deprecate all the garbage you shouldn't! Maybe remove all the stupid new redundant nonsense while at it?

Until then I'm sticking with XHTML 1.0 Strict... STRICT for saying "don't use things you shouldn't be using" and XHTML for the consistent/improved structural rules.

Quote:

Originally Posted by itmitică

Or don't. Just stop trying to tell others not to try it. That's just wrong.

BULLCOOKIES -- that is NOT an attitude consistent with trying to achieve PROGRESS.... as George Bernard Shaw said:

"The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therein, all progress depends on the unreasonable man."

We need to start a "just say no campaign" -- this is your website; this is your website on HTML 5 -- any questions?

Quote:

Originally Posted by itmitică

That doesn't stop people proclaiming about XHTML. Which even now it's not fully supported by all UAs. And I have yet to see HTML5 breaking pages like XHTML does.

Gehugafugah?!? XHTML 1.0 works just fine within it's purpose all the way back to IE 5.0 and Nyetscape 4 -- that's what it's for, a formulation to allow HTML to be parsed both by HTML parsers and XML parsers; it was NEVER meant to be a full XML formulation and if you follow the compatibility guidelines for it, it works just fine. The only reason to choose XHTML 1 over other specs is the more consistent structural rules.

Now, if you're talking XHTML 2 or that XML application idiocy, then sure... but that's crap that really has no point being used on the web in the first place!

Quote:

Originally Posted by itmitică

And that's why those that want to try HTML5 should be supported. The earlier adoption and the earlier use, the faster it's weaknesses will be revealed. They do all the work for you. So let's be supportive.

Or we could just nuke the WhatWG from orbit, it's the only way to be sure.

Quote:

Originally Posted by itmitică

That's why I think an open mind an a clear voice is better. Let's not love to hate.

In other words feel good nonsense and "status quo for the win" -- so much for progress.

Quote:

Originally Posted by itmitică

Criticizing is easy. How about showing what can be done the best with what there is. After all, HTML5 means hard work. Let's respect that.

I find it to be the opposite of hard work -- because it just further justifies sleazing pages out any old way to the point you might as well go back to using HTML 3.2 and slapping a 4 tranny doctype on it... Net change or improvement ZERO!

Quote:

Originally Posted by itmitică

And if you want something to criticize, turn to CSS3.

What's wrong with 3? Admittedly the new column stuff is a train wreck, but what's available in the here and now is useful and gracefully degrades. Far, FAR less to complain about than the unmitigated idiocy HTML 5 brings to the table.

HELL, it's why the new javascript stuff and CSS3 have been put under HTML 5's banner -- as without them the emperor has no clothes.

Quote:

Originally Posted by itmitică

It's taking over content and behavior with easy implementations for feats that otherwise required more knowledge.

You say that like it's a bad thing...

Quote:

Originally Posted by itmitică

Javascript should be easier instead, and jQuery certainly helps us. Another hard work example taken lightly.

Ok, we're done here -- if you are using that fat bloated cryptic idiotic nonsense that bills itself as "making cross browser scripting easier" when 90% of it's codebase is blot for useless ugly pain in the ass animooted nonsense; In fact being the driving factor in why so many websites that used to be useful are now useless to myself and many others....

Just wow man... WOW. Take all the hate I have for HTML 5, and multiply it tenfold for the idiotic jquery BULL!!!

Quote:

Originally Posted by itmitică

And even then, use a reasonable tone. HTML5 and CSS3 are there trying to help us all.

Help, yeah... that's what 5 is for... NOT

Quote:

Originally Posted by itmitică

One little observation: <div id="nav"> or <ul id="nav"> is not XHTML in it's purest form. It's simply put, low grade HTML.

You mean XML, not XHTML -- the point of XHTML was to be a reformulation of HTML that XML could parse -- it was NOT TO TURN HTML INTO A FULL XML IMPLEMENTATION!!! -- at least not in the 1.0 version of the specification. Made up ******** tags in fact were such a inconsistent mess it's why X2 was backed away from faster than light.

I see people making that same nonsensical claim over and over again -- and all I can say is "have you even bothered READING much less COMPREHENDING the XHTML specification?!?" -- that's the same bekaptah fiction as the people who think XHTML should mean they can go <div /> or that what serving it as text/html somehow magically makes it not be XHTML... When the specification that says what XHTML is says text/html is valid, shorttags only works on EMPTY elements (DIV is never an "Empty" element), and it says quite clearly:

Quote:

XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4 [HTML4]. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents.

XML based, NOT A FULL XML IMPLEMENTATION - it's a reproduction of HTML 4 in a XML namepsace -- that's it. People seem to want to read more into it which just isn't there!

Quote:

Originally Posted by itmitică

And HTML5's <nav> it's not meant to replace that <div> or <ul> with a "nav" id. That's plain moronic, to think something like that. It's meant to finally put an element in place with what www is all about: navigation.

Extra DOM element for nothing since you'd still need the block level containers inside it (like the list) at which point why not just make it an attribute for lists instead of polluting the DOM making scripts run slower and have CSS have to work harder?

'nav' -- like most of the new allegedly semantic structural containers seems to be JUST for the people who were slapping a div around their UL for nothing and some vague accessibility crap that honestly, is wasting markup on way too small a portion of the audience then sending it to everyone; at which point... file it alongside the idiotic rubbish of using IE conditional comments for CSS -- or WORSE, to determine what classes are applied to an HTML tag. (a sure fire indicator whoever is writing the page needs to learn more CSS first!)

Of course I even hate the name "nav" because it's uselessly vague; I hate it as a class or ID, I hate it as a tag, because every blasted anchor on a page is 'navigation'. It does not clearly define what it is... and it's just been encouraging people who don't bother reading the specification to turn their menus into run-on sentences by removing their lists and block level containers.

Goes back to something Dan Schulz once said (even had as a sig here for a while)

Quote:

the people who used to write endless nested tables for no reason now just write endless nested DIV for no reason.

Exactly the crowd for whom HTML 5 seems tailored -- can't possibly leverage the existing semantic tags for meaning and target those -- of course not. Now they have allegedly semantic tags they can wrap around their existing semantic tags for no reason...

Yeah, that's a real improvement.

Something sucks, you come out and say it suck, you get off your ass and tell people it sucks and actively try to prevent it from taking something you used to find useful and letting the sleazeball scam artists pissing all over it and lead people down the gardent path to failure with their snake oil.

Basically: Lead, follow or get out of the way. That's how we make the world a better place instead of this soft, drum circle feel-good status-quo nonsense. "If you can't say anything nice" being a cop-out by thin skinned wussies who can't be bothered to get motivated about anything but complaining about the sheep dogs trying to protect them from the wolves.

Quote:

If you have no capacity for violence then you are a healthy productive citizen: a sheep. If you have a capacity for violence and no empathy for your fellow citizens, then you have defined an aggressive sociopath--a wolf. But what if you have a capacity for violence, and a deep love for your fellow citizens? Then you are a sheepdog, a warrior, someone who is walking the hero’s path. Someone who can walk into the heart of darkness, into the universal human phobia, and walk out unscathed.

Yakko Warner: "Either that or you're at the Ice Capades." :D
Mar 13, 2012, 06:20
Sega

Quote:

Originally Posted by deathshadow60

turdpress

lol :)

Quote:

Originally Posted by deathshadow60

The majority of people writing code right now are blissfully unaware of two-thirds the tags we're supposed to be using; LEGEND, LABEL, TH, THEAD, TBODY, CAPTION, DEL, FIELDSET, BLOCKQUOTE -- most people writing code can't even keep PRE and CODE straight, and waste time wrapping tags that already have meanings in extra elements like DL or tables.... THROWING MORE TAGS AT THEM IS NOT THE ANSWER when people can't even keep straight what we already have!

You've got a point there. The simplicity of HTML5 with it's <header><footer> tags would probably get used either way because of they are layout specific tags rather than markup tags. Which brings another argument to this. It would make no difference having <header> in the footer and <footer> in the header, as it's just markup and nothing to do with presentation. This draws an argument to why it should be used in the first place.

Quote:

Originally Posted by deathshadow60

Actually it makes perfect sense -- because all the asshat bull we've been told NOT to do since STRICT was introduced is now perfectly fine and acceptable in 5.

Doesn't really make sense actually! I means if it was so bad why have they reverted to it now. In fact why have they made HTML5 they way it is?

To be fair I can't see HTML5 disappearing, I an not entirely sure why the it was done like this preventing it from being given an official stamp. I really don't want to wait for HTML6 to come out or XHTML 3.0 is whatever they like to call it. I started coding back in 2001, HTML4 was the norm (if I was correct), where nested tables and title-case for tags were the in things. 12 years later we've only really gone from HTML4 to XHTML. I don't want to wait another 10 years for something to officially be called a standard. People were talking about CSS3 when I was in uni and that was back in 2005. We've only just started using it NOW! and it's 2012 (end of the world presumably) and it's not even a standard yet! Can you see what I am getting at. In terms of markup things but very slow.
Mar 13, 2012, 07:06
deathshadow60

Quote:

Originally Posted by Sega

I means if it was so bad why have they reverted to it now. In fact why have they made HTML5 they way it is?

Because it's made by/for the people who didn't embrace the entire NOTION of strict, or progress. It's basically throwing up their hands and saying "fine, go ahead and sleaze out pages any old way, who cares". I mean that's basically who created the WhatWG in the first place!

Progress - that's what it is. SURE...
(for those of you unfamiliar with it, that's called Sarcasm)

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...

Times like this a benevolent dictator might not be a bad idea.
Mar 13, 2012, 07:07
samanime

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.
Mar 13, 2012, 07:13
deathshadow60

Almost forgot this:

Quote:

Originally Posted by Sega

I started coding back in 2001, HTML4 was the norm (if I was correct), where nested tables and title-case for tags were the in things. 12 years later we've only really gone from HTML4 to XHTML. I don't want to wait another 10 years for something to officially be called a standard. People were talking about CSS3 when I was in uni and that was back in 2005. We've only just started using it NOW! and it's 2012 (end of the world presumably) and it's not even a standard yet! Can you see what I am getting at. In terms of markup things but very slow.

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.
Mar 13, 2012, 07:51
Sega

Quote:

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.
Mar 13, 2012, 09:47
itmitică

So Jason... a few disagreements. :)

What you say:

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.

Finally, a technical excerpt form the specs:

Quote:

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.
Mar 13, 2012, 11:31
deathshadow60

I don't think you entirely grasped my view -- or you just misunderstood it.

Quote:

Originally Posted by itmitică

What you say:

1. HTML5 will be ready for use in 20nn. No use until then. Notice I say "use" not "try".

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.

Quote:

Originally Posted by itmitică

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.

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...

Quote:

Originally Posted by itmitică

Browsers and browser vendors are doing exactly the same thing with HTML5. That makes HTML5 ready for use today.

Not even CLOSE to the same thing; comparing an unstable API to bugfix downloads? You're kidding, right?

Quote:

Originally Posted by itmitică

2. Using "bloated" jQuery is no good.

Ok, you understood that...

Quote:

Originally Posted by itmitică

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.

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?!?

Quote:

Originally Posted by itmitică

It seems you are getting kicks out of being in the first category. That probably keeps your from being "jQuery friendly".

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.

Quote:

Originally Posted by itmitică

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.

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.

Quote:

Originally Posted by itmitică

3. A tag in XHTML is better than a tag in HTML. Even more so, it's better than a tag in HTML5.

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.

Quote:

Originally Posted by itmitică

And HTML5 is user friendly. Why would we want anything else?

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.

Quote:

Originally Posted by itmitică

You want penalties for those writing bad markup? That's not the name of the game.

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.

Quote:

Originally Posted by itmitică

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

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!!!

Quote:

Originally Posted by itmitică

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.

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...

Quote:

Originally Posted by itmitică

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.

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.

Quote:

Originally Posted by itmitică

Doesn't this contradict your view on "bloated" jQuery and your choice of a benevolent dictator for XHTML?

Not sure what you even mean by that -- but again I don't see it breaking the lines you seem to think it does....

Quote:

Originally Posted by itmitică

The same rules that try to make it harder for developers, no matter their skill?

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.

Quote:

Originally Posted by itmitică

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.

"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.

Quote:

Originally Posted by itmitică

Finally, a technical excerpt form the specs

... and yet notice they put block level containers in their examples, INCLUDING UL around menus -- one of their examples:

Code:

<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:

Quote:

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.

Show 200 post(s) from this thread on one page