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.'
Permalink for comment 485639
To read all comments associated with this story, please click here.
HTML 5 === Pointless Bloat
by deathshadow on Wed 17th Aug 2011 22:57 UTC 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