Linked by snydeq on Tue 16th Aug 2011 16:46 UTC
Web 2.0 InfoWorld's Peter Wayner discusses the 11 hard truths Web developers must accept in making the most of HTML5 -- especially those who are looking to leverage HTML5 in hopes of unseating native apps. 'The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchonization challenges, and politics should have us all scaling back our expectations for the spec.'
Thread beginning with comment 485370
To read all comments associated with this story, please click here.
HTML 5 == Pointless Bloat
by deathshadow on Tue 16th Aug 2011 19:33 UTC
deathshadow
Member since:
2005-07-12

Would be nice if the article had anything to do with HTML... but then, it would be nice if HTML 5 had anything useful to offer in terms of HTML, instead of being a market-speak buzzword (Fran hit this on the head).

A hefty part of why Javascript and CSS3 and a whole slew of other technologies have been thrown under the general HTML 5 banner is that from a markup standpoint, HTML 5 offers little if any improvement, and instead bloats out the markup for no good reason with it's new allegedly "semantic" tags -- FEW of which do anything useful a DIV can't, and seem to exist in the specification for the sole purpose of placating the people who vomit up HTML 3.2, slap a transitional doctype on it, then have the cojones to call themselves a modern developer. Congratulations, you're in transition from 1997 to 1998 -- Way to keep those skills up to date!

Now, instead of hooking up with a tranny they slap a HTML 5 Lip-service doctype on it, and still have their heads permenantly wedged up 1998's backside. The scary part is, this means that ALL the progress of HTML 4 Strict and/or XHTML 1.0 Strict is being flushed right down the crapper. So go ahead, sleaze out your page any old way with endless wrapping containers and to hell with putting anything in the already existing semantic tags properly -- That's what HTML 5 from a markup standpoint is for!

Of course, you'll have the people going "what about audio and video" to which I reply "what the hell is wrong with object apart from browser makers dragging their heels?" -- Many browser specific tags (like EMBED) were not adopted in 4 Strict (aka the REAL HTML 4) and the APPLET tag was dropped for being redundant to OBJECT, and we were SUPPOSED to have IMG go away at some point too -- this way you want to support the latest and greatest format, you just install the format... How the bloody hell is hard-coding the blasted codec into the browser "better" apart from stroking the ego of each browser makers favorite pet codec. It sure as hell doesn't make video distribution simpler with needing to distribute in what? Three formats? FOUR? Oh yeah, re-encoding that file four times is such an improvement and makes development so much simpler... much less the total lack of security technologies or even full-screen playback that makes most of your 'real' video sites either use it as a fallback for crappy devices that don't support flash, or just give it the finger entirely. NEVER thought I'd be rooting for flash on anything, but HTML 5 has made me a believer.

Now of course, EMBED is adopted (what the hell?!? a decade of saying "don't use that we just throw up our hands and say "whatever"... For 4 Menu and DIR were dropped as redundant to UL -- now menu is back and frankly, for christmas only knows what.

Then we have the elements that have NO LEGITIMATE REASON to EXIST as tags -- like CANVAS. Canvas is useless without javascript -- it only exists for javascript -- so why does it need a markup element again? Couldn't we just draw on an existing tag or create a dom element using the script? There is no reason for it to have it's own tag in the markup.

You figure in the bloat of the pointless allegedly semantic "header, nav" elements that seem to exist JUST to placate the people who slap extra DIV around tags for NOTHING... tags like FOOTER and SECTION that you'll end up slapping ID's on anyways just to resolve specificity... combined with most people STILL using tags for what they look like instead of what they mean -- and it's hardly a shock you see bloated slow inaccessible pages vomited up using hundreds of K of code to deliver less than 10k of content. Because naturally, more code that does nothing useful makes the page faster and easier to maintain. RIGHT.

To hell with HTML 5. I have NO plans to migrate past HTML 4.01 Strict and/or XHTML 1.0 Strict -- at least not until HTML 6 comes along and deprecates 90% of this new stuff as redundant to existing tags and never actually used properly... Just like 4 Strict did to HTML 3.2

Because to be brutally frank, HTML 5 -- in terms of what it offers for actually marking up content for a site -- is the new HTML 3.2. No, that's not a compliment. I can't believe after trying it for more than ten minutes anyone would be DUMB ENOUGH to even want to use it in the first place; But then it does also seem to exist to prey off the ignorance of nubes and to help places like Sitepoint sell new books.

CSS3, the new scripting? Great stuff... you take those away from HTML 5, you have a empty pointless shell setting website coding practices back a decade or more... Or would be setting it back a decade if more than a handful of developers actually bothered to understand STRICT, the separation of presentation from content, accessibility, or even the entire POINT of HTML.

Edited 2011-08-16 19:34 UTC

Reply Score: 9

RE: HTML 5 == Pointless Bloat
by galvanash on Tue 16th Aug 2011 23:23 in reply to "HTML 5 == Pointless Bloat"
galvanash Member since:
2006-01-25

HTML 5 offers little if any improvement, and instead bloats out the markup for no good reason with it's new allegedly "semantic" tags


Counterpoint... What is the harm in them? There are what, like 10 or so new semantic tags? Yes, none of them are strictly necessary - but in order to convey semantic meaning (if you care about that) the standard has to have a way to attach that meaning in a concrete way. So you either have a nav tag or you have a div with some type of defined attribute to identify it semantically - seems to me to be the same thing either way. Alternately, if you don't care about the semantics you can just ignore most of the new tags, no harm done.

The scary part is, this means that ALL the progress of HTML 4 Strict and/or XHTML 1.0 Strict is being flushed right down the crapper.


What was lost exactly? Do you have a concrete example? I still write my code as if it was XML (self closing tags, no empty attributes, etc.) and that is perfectly acceptable in HTML5. If you want the equivalent to XHTML you just have to make sure you conform and set your mime type properly (aka XHTML5).

I see alot that was lost if you are comparing HTML5 to the proposed XHTML2 spec, but compared to XHTML 1? Where is the backslide?

Of course, you'll have the people going "what about audio and video" to which I reply "what the hell is wrong with object apart from browser makers dragging their heels?"


I can't argue with that one much... The point was to have default and required codec for both audio and video - we didn't get that so the whole thing is a bit of a circle jerk... However, both tags have a considerable amount of functionality relative to embed/object/whatever.

Then we have the elements that have NO LEGITIMATE REASON to EXIST as tags -- like CANVAS. Canvas is useless without javascript -- it only exists for javascript -- so why does it need a markup element again?


[canvas tag] == [img tag w/client-side procedural source].

It makes perfect sense to have it as a tag - like many other HTML5 tags it has important semantic meaning. If you see a canvas tag in the source of a document you know immediately that something is supposed to be drawn there (and that something can be described using a title attribute). A div tag would not convey that.

You figure in the bloat of the pointless allegedly semantic "header, nav" elements that seem to exist JUST to placate the people who slap extra DIV around tags for NOTHING... tags like FOOTER and SECTION that you'll end up slapping ID's on anyways just to resolve specificity...


Semantic tags are not bloat. IDs are great to make sense of things for the author - they do nothing to convey structural meaning to others. Again, you are not required to use them (they do not always make sense). But when they do make sense they are genuinely useful.

combined with most people STILL using tags for what they look like instead of what they mean -- and it's hardly a shock you see bloated slow inaccessible pages vomited up using hundreds of K of code to deliver less than 10k of content.


Can't argue with that at all. But I do not see how HTML5 makes this problem any worse than HTML4 did. Granted, it doesn't do much to improve it either... But I don't see why you are hating on it so much. XHTML2 was going to have quite a few new semantic tags too...

CSS3, the new scripting? Great stuff... you take those away from HTML 5, you have a empty pointless shell setting website coding practices back a decade or more... Or would be setting it back a decade if more than a handful of developers actually bothered to understand STRICT, the separation of presentation from content, accessibility, or even the entire POINT of HTML.


I do understand STRICT. I also like HTML5. HTML5 does nothing to set back coding practices. The only legitimate argument I can think of against it is it de-emphasizes XML, which I too agree is a bad thing overall. But other than that...

The way I read your comments you think HTML should be as rigid and efficient as possible to convey the authors intent to the browser. That is very important, but semantics matter if the thing on the other end is NOT a browser (and that is a valid use case for the web). On one hand you argue against new semantic tags (just use divs), but on the other you complain about authors nesting wrappers (which is what you end up with if you eliminate the semantic tags). There has to be a middle ground...

Reply Parent Score: 4

Brendan Member since:
2005-11-16

Hi,

"combined with most people STILL using tags for what they look like instead of what they mean -- and it's hardly a shock you see bloated slow inaccessible pages vomited up using hundreds of K of code to deliver less than 10k of content.


Can't argue with that at all.
"

Must be my turn then.

For HTML, the content itself is just data from "somewhere" (typically a database); and the job of a web developer is to design and control the presentation of that content. Idiotic crud like CSS and "semantic" tags (even old stuff, like the "em" tag) just make it harder for web developers to do their job well (as they can't really say how any specific browser might render it), and push developers towards using things like Flash as a way of controlling presentation.

One supposed advantage of semantics is that it's "important" for accessibility. This is misguided, as most accessibility stuff needs to be taken care of at the OS's level so that all applications (not just stuff displayed by a web browser) is usable; and if accessibility is taken care of at the OS's level (like it already is in most OSs) then HTML itself needn't care about most accessibility. Of course for blind people, you really don't want HTML at all - you want something designed for complete control over audio (both sound and speech synthesis), including timing, volume, position, etc; and you want web developers to design sites specifically for audio (including site navigation, etc) instead of trying to make something intended for visual content delivery (and primarily used for visual content delivery) work in a "half-assed, almost better than nothing" way.

Then there's thing like search engines, which are already capable of producing extremely good results from things that lack any semantics; like PDF files, MS word files, text files, etc. They have no need for semantic markup, and often the tags intended for search engines (like the "keywords" meta-tags) are deliberately ignored by search engines.

For anything more than that, if you want "raw content + semantics" then use XML (not HTML and not XHTML).

Basically, the only valid reason for any/all tags in HTML is to tell the browser how something should look. Rather than concentrating on doing the job it was intended for (and doing it well); since HTML4 they've been making it worse just to make HTML something it was never intended to be.

- Brendan

Reply Parent Score: 0

HTML 5 === Pointless Bloat
by deathshadow on Wed 17th Aug 2011 22:57 in reply to "RE: HTML 5 == Pointless Bloat"
deathshadow Member since:
2005-07-12

Counterpoint... What is the harm in them? There are what, like 10 or so new semantic tags? Yes, none of them are strictly necessary

encourages people to add extra wrapping tags for NOTHING. See the dipshits who right now do nonsense like wrapping a div around a single UL just to give it an ID -- when the UL by itself is a perfectly good block level element for attaching styling to. 99% of the layouts where they were doing DIV#NAV and now use NAV that extra wrapper is POINTLESS.

... AND it's an extra element on the DOM, something search engines are FINALLY taking sites to task for with their speed analyzer... All for something that frankly, ARIA Roles make a hell of a lot more sense for.

but in order to convey semantic meaning (if you care about that) the standard has to have a way to attach that meaning in a concrete way.

You mean like the EXISTING tags of numbered headings and ul?

So you either have a nav tag or you have a div with some type of defined attribute to identify it semantically - seems to me to be the same thing either way.

Dom size... or the EXISTING semantic tags. I don't need HEADER, FOOTER or NAV, I know how to use H1/H2/H3/H4/H5/H6/UL/P/HR properly. (yes, HR -- end of topic/ section started by a heading!)... It is NOTHING more than bloat for the dips who wrap DIV around elements for NOTHING -- the only other reason for having div around something like a foooter is for PRESENTATION -- at which point you shouldn't be attaching more meaning to it in the first place!

But then, I've rarely seen anyone use HR for what it's for or put numbered headings in a sensible order for layout navigation on things like screen readers -- multiple H1's, skipping heading numbers, having low order (high numbered) headings before the H1... Mish-mash of idiocy.

What was lost exactly? Do you have a concrete example? I still write my code as if it was XML (self closing tags, no empty attributes, etc.) and that is perfectly acceptable in HTML5.

As is every other blasted type of formatting meaning there's no single consistent formatting rule -- just sleaze it together any old way... Yeah, that's progress. Thank you for providing your own example ;)

I see alot that was lost if you are comparing HTML5 to the proposed XHTML2 spec, but compared to XHTML 1? Where is the backslide?


Adopting tags like EMBED into the specification when it was originally rejected as redundant to OBJECT? Bringing back deprecated tags like MENU? Adding dozens of new tags when nobody can be bothered to use the ones we already have properly? (TH, THEAD, TBODY, CAPTION, LEGEND and LABEL for example!) 4 STRICT was not just about getting rid of presentational tags (FONT, CENTER, BASEFONT, U), but also redundancies (DIR, MENU, APPLET, S, STRIKE)... Now a whole slew of pointless redundant tags are being dumped in -- sounds like a backslide to me!

However, both tags have a considerable amount of functionality relative to embed/object/whatever.

Which could just as easily have been added to OBJECT.

[canvas tag] == [img tag w/client-side procedural source].

Which IMG was originally on the chopping block for OBJECT too, and could have been abandoned if Microsoft hadn't made such a broken OBJECT implementation... Still the best way to show jpeg2k though -- but of course we're going to be using .gif, .png and normal jpeg until we're old and gray as there's no way any better format could EVER come along...

It makes perfect sense to have it as a tag - like many other HTML5 tags it has important semantic meaning.

On something that isn't content and/or is strictly presentational when not present... Rule #1 of good javascript, enhance not supplant... and auto-attach insted of manually hooking in the markup. (Naturally the people who vomit up bloated jquery bull will never understand that)

If you see a canvas tag in the source of a document you know immediately that something is supposed to be drawn there (and that something can be described using a title attribute). A div tag would not convey that.

The only reason I can see it being useful is that it works like object for wrapping scripting off content... So I'll give you that. Still, it would be MUCH more useful if we could use it to draw extra stuff on existing elements... Something VML, SVG and Canvas are all pretty much useless for.

Hell, I'd love to see a vector language added to CSS so you could draw on the background bitmap -- much like the one created by linear-gradient. THAT would be useful.

Semantic tags are not bloat.

They are when the semantics are dubious and are used to WRAP OTHER SEMANTIC TAGS -- like H1... like UL... like P... Then you're just stacking semantics and making the document structure dozens of times more complicated than it needs to be. We have enough semantic tags as it sits, adding extra WRAPPING tags to go around wrapping tags? That's just STUPID... Especially when you take DOM size into consideration (Even more so with jquery and other scripttards going through the entire dom to attach their stuff with getElementsByClassName or getElementsByTagName)

IDs are great to make sense of things for the author

Only reason they exist is to target them via hash, scripting or CSS... Using semantic tags usually involves using less classes and ID's...


they do nothing to convey structural meaning to others. Again, you are not required to use them (they do not always make sense). But when they do make sense they are genuinely useful.

I dont' see them as useful -- at all. I see them as 100% bloat because if the tags inside them -- H1, P, A, HR -- already are conveying information, what purpose does adding any of that extra crap around them serve besides justifying the bloat of people who wrap extra DIV around things for nothing that couldn't be applied to the existing tags. I can understand DIV for grouping tags into sections, but I'm not changing or adding meaning by doing so -- Nor would I WANT TO.

combined with most people STILL using tags for what they look like instead of what they mean -- and it's hardly a shock you see bloated slow inaccessible pages vomited up using hundreds of K of code to deliver less than 10k of content.


Can't argue with that at all. But I do not see how HTML5 makes this problem any worse than HTML4 did. Granted, it doesn't do much to improve it either... But I don't see why you are hating on it so much. XHTML2 was going to have quite a few new semantic tags too...


... and XHTML 2 was a fat bloated train wreck of unneccssary crap too. Who'd have thought HTML 5 would end up being a retread of bad ideas, I suppose though you're right, it doesn't make it worse, it just adds tags to artificially justify the half-assed coding techniques of the people who still have their head permanently wedged up 1997's backside.

I do understand STRICT. I also like HTML5. HTML5 does nothing to set back coding practices.

Apart from the loosening of the rules, encouraging extra dom elements that serve no real purpose, adding back in tags that were deprecated for a reason, putting back in redundancies and adding even more new ones...

Gonna have to break this into two parts.

Reply Parent Score: 2

RE: HTML 5 == Pointless Bloat
by Lennie on Wed 17th Aug 2011 00:50 in reply to "HTML 5 == Pointless Bloat"
Lennie Member since:
2007-09-22

(I will try not to repeat what galvanash already mentioned)

HTML 5 offers little if any improvement


Actually one of the big improvements in HTML5 is that many differences between how browsers parse (mistakes in) HTML should now be handled in the same way.

The scary part is, this means that ALL the progress of HTML 4 Strict and/or XHTML 1.0 Strict is being flushed right down the crapper.


The scary part was that the W3C wanted to make an INcompatible XML-based version of (X)HTML following after (X)HTML4.

That would mean if you would visit a webpage with an older browser you wouldn't see anything useful.

No browser vendor wanted that, so that is one of the many reasons HTML5 or anything really came out of W3C for a long time.

Instead Mozilla and Opera started WHATWG to fix that, later Apple and, in a way, Google joined them.

You figure in the bloat of the pointless allegedly semantic "header, nav" elements that seem to exist ...


The semantic elements exist to make it possible to create alternative layouts easier and to make it possible for other tooling to understand the page. Things like screen readers for blind people.

Some thing actually help reduce the foot print of pages.

That is also one of the reasons we now have a lot of new INPUT-tag-types. To not need extra JavaScript to handle what could easily be handled by the browser. Form validation and so on.

Even if you dislike that other people do add divs with 'nav' and 'header' to their page. Many are doing so. You'll have to agree that having a standard way of doing that can only be an improvement.

Reply Parent Score: 3

RE[2]: HTML 5 == Pointless Bloat
by Lennie on Wed 17th Aug 2011 10:44 in reply to "RE: HTML 5 == Pointless Bloat"
Lennie Member since:
2007-09-22

I think I know why Kroc might have turned a bit of a blind eye to the performance parts of the loading of the pages, because ads are the worst offenders and they probably block loading of the rest of the page.

So anything the OSNews crew might do it improve things, wouldn't be very visible by the users as the ads would hide most optimizations (obviously not the anti-cache headers, cookies and so on they would all still be atleast some benevit).

Reply Parent Score: 2

RE: HTML 5 == Pointless Bloat
by lucas_maximus on Wed 17th Aug 2011 15:22 in reply to "HTML 5 == Pointless Bloat"
lucas_maximus Member since:
2009-08-18

1. It isn't hard to get your CSS specificity correct.

2. The whole point of semantic elements with CSS 3.0 is that I don't end up with div-itius and I actually have mark-up that represents what the f--k I want it to be.

3. If you want XHTML you can still have it, all one has to do is stick the XML namespace onto the <html> tag.

4. This BLOAT rubbish really pisses me off ... Computer tech has moved on since the 90s and the bandwidth I have available on my mobile phone is 20x - 30x what we had. Processor speed is soo fast now I can't even max out my fairly modest rig. JS now get compiled, so I don't even have to worry about optimizing loops (where JS was notoriously bad).

You stay in the 90s ... and resist change but the rest of the web community will leave you guys behind.

5. There will be no HTML6 spec ... HTML is now a rolling standard.

Edited 2011-08-17 15:22 UTC

Reply Parent Score: 2