Guest post by 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.’
1 Hard truth about developing for iOS:
1. Apple can choose to put you out of business any time they want, for any reason, without recourse. APPLICATION DENIED.
What, and Google can’t? If they pull your app from the marketplace, you’re pretty much done. Just because they wouldn’t doesn’t mean they couldn’t.
Targeting the wrong person much ? I’ve never seen Kroc defend an Android product in this place. If there is something which Kroc advocates, it’s platform-independent web technologies.
Apple’s App Store just happened to be the single best example, in today’s world, of what may happen if you depend on a single tightly-controlled OS to survive…
Edited 2011-08-16 18:07 UTC
Yeah… There are still alternative distribution paths for Android and you can resubmit your app to the Market in a few seconds…
And I hear Apple takes 30% of any sales through the App Store even subscriptions and also you can not link to any other payment system.
The 12th hard truth. (For non-web progammers)
HTML5 is a press buzzword.
When they refer to HTML5 most of them really mean HTML5, CSS3 and Javascript.
That’s right, but I actually like that move. They (WC3 folks) announced this earlier, so it isn’t really buzz, like “Web 2.0”. What they did is to put a lot of stuff. The markup, the protocols like Websockets, but also HTTP-P2P and Microformats, Canvas, WebGL, … under one name, while developing these technologies independend from each other. And this is what I absolutely love, because it allows developers to have stuff that’s ready and stable, while other things are still in development or even get dropped (like that offline SQL thingy).
This provides a lot of freedom. Something that has been achieved by attacking IE from all sides.
I know, it’s not perfect, but it’s still great.
About the topic. I think the way web apps get programmed will change. There are lots of great ideas coming from the Node.js folks for example. One has to have a look at the (AOL sponsored) Socketstream frameworks. It makes it _very_ easy to create real time (as in multiplayer racing games) web applications. It doesn’t limit the developer and helps him with stuff like security. I doubt this is already the end of the road.
I know, I am probably too enthusiastic, but I really like how things develop in this area.
Actually… It wasn’t. http://www.w3.org/TR/IndexedDB/
Actually, WebSQL was dropped. IndexedDB is something else entirely. It’s a simple key-value store with support for indexes and cursors.
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
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.
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?
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.
[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.
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.
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…
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…
Hi,
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
Hi! How are things back in 1992?
Seriously… So you want to go back to purely using tags to control presentation? Really?
I have been doing this since 1996 or so. You can not and have never been able to say how any specific browser might render things reliably. It has always been horseshoes and hand grenades until CSS became prevalent. It is still hit or miss to some extent, but much better than it ever was in the past. If you want to control presentation, that is what CSS is for – HTML is for describing document structure, linking, and embedding.
In hindsight I almost wish all browsers shipped with absolutely no presentation defaults at all and forced authors to implement complete CSS styling for their work. It would actually save me some trouble most of the time as the first step required when you want pixel perfect rendering across modern browsers is to reset all that crap anyway.
Realistically it isn’t that way though because most of the time you really don’t need pixel perfect rendering and the defaults generally behave similarly enough that if you keep things simple they work well. I have nothing against this approach to doing web pages – simple is often good… As long as you are not naive enough to thing that “good” means “identical” it is a perfectly valid way to do things.
It doesn’t matter what is doing the accessibility. Please explain how the OS is supposed to do it without something telling it WTF it is looking at? You make it sound like semantic tags are a bad thing… You do realize most of those presentational tags from HTML 2.0 you seem fond of ARE semantic tags don’t you? H1 doesn’t mean “really big font”, it means “Top Level Heading”, it just also happens to render with a really big font in most browsers. There really are only a small handful of tags that were ever in HTML that can be considered purely presentational. The font tag for sure, i and b are really both – big, small, sub, sup – hell that is about it really, everything else is semantic.
The point is if you care how it looks you need to use CSS to control it – the tags purpose is to convey document structure. That is essentially what semantic means. If you want HTML without semantics… well you really don’t have anything left. Hell, if you don’t care about semantics just make a jpeg and use an img tag… Really, why not?
You do realize all of those things have semantics in them don’t you? They may not always be explicit, but even text files have semantics (TITLE IN ALL CAPS). How do you think Google extracts information like the title form say a .doc file when the metadata is missing? It looks for the first heading in it. Same with pdfs. HTML just makes it more explicit and well defined. How is that a bad thing?
You have a seriously misguided view of what HTML is, what it is for, and how it is actually used.
Edited 2011-08-17 04:26 UTC
Yes, definitely. However I would also like things to have improved – more tags for direct control of presentation, and better browser compatibility.
HTML should be for describing document structure for the purpose of presentation; not for describing document structure for no purpose at all.
Sane/standard defaults avoid the need to waste time/bandwidth providing superfluous information.
The stupidity of “pixels” as a measurement for anything (especially for web pages where there’s no sane way of knowing what the size the user’s screen is) is a different issue. Unfortunately, true resolution independence would require something extremely complex, like teaching browsers that percentages can contain fractions (e.g. size=”12.34%”).
Agreed. I’m not after “every pixel is identical in all browsers”. I just want the browser to do what I say without requiring an extra layer of bloat (CSS) to tell it to do what I say; in the way that HTML3 used to, but hopefully with even more control (like “{div bgcolour=”#1234″}” for e.g.).
Have you had a look at the accessibility features in something like Windows or Gnome? Things like shifting hue for colour blind people, screen magnification, etc? The only thing not covered is blind users and screen readers (but that’s an entirely separate issue).
Note: I don’t use the heading tags (I prefer doing the “{big}{big}{b}” thing, so I know what it should look like). In the same way I don’t use “{thead}” or “{th}”. I use tables for layout control. If I want an actual table with something like “Figure 1.3” underneath it; then I create a table (with borders) inside another table (without borders) and have “Figure 1.3” in the second row of the outer table (because “{tfoot}” is displayed as just another row and not underneath the table, and “{caption}” is displayed above the table (WTF?) which isn’t what I want either). I use the “title” attribute for tooltips and not for titles. For code I don’t use “{code}”, but prefer “{tt}” and a heap of “+nbsp;” (with “+gt;”, “+amp;”, etc) so that I can still do stuff like syntax highlighting.
I honestly don’t think I use any of the tags intended for semantics, because none of them are displayed how I want them to be displayed. The only exception to this is HTML links (and anchors).
To attempt to control presentation you are meant to use CSS (which is a bloated mess that would never have been needed if W3C had their priorities right).
Bandwidth and linking.
I didn’t say it was bad for search engines to use the semantic markup. I did say that search engines don’t need the semantic markup or justify the existence of semantic markup.
I don’t care how it is, I’m talking about how it should have been.
Have a look at the source for OSnews’ main page. It’s just over 62 KiB and consists of a mixture of JavaScript and HTML. On top of that there’s the CSS which is another 23.3 KiB, plus another little CSS for RSS (2.1 KiB). Then there’s a total of 167.4 KiB of extra javascript files, where the largest is for jQuery. That’s a total of 254.8 KiB of data (not including icons, pictures, etc). The content is only 19.3 KiB. How much of the remaining 235.5 KiB is there to control “look and feel”?
Now click on your browsers “refresh” button to refresh the OSNews main page. How long did it take to complete? For me it took a total of 8 seconds to drag all that data half way around the world, partly because the browser can’t start fetching all the data at the same time (for e.g. it can’t know which CSS file to download until after it’s started decoding the HTML).
Ok. Now try to convince me that this is “efficient”.
– Brendan
I won’t try and convince you about it is efficiency.
Efficiency of webpages is something I deal with on a regular basis.
However I do want to point out a few things:
Yes, CSS-model isn’t all that great. Downloading an extra file at the start of the page sucks. Especially if the system that makes the HTML doesn’t properly flush the data.
But a few lines of CSS could apply to many, many different elements on the page and would not even need to be downloaded when going to different pages.
If you would include style information in each and every single tag individually you would be sending a lot more text on the wire.
Ofcourse if you would like to reduce the number of requests before the page renders you could include it in the head it would possibly be even faster.
I don’t know why they included jquery on the page.
I’m also not happy that it is included at the top of the page. I would rather see any javascript at the bottom of the page. Preferably not even using a onDomReady event or similair. I doubt that is needed.
I also don’t like it if people don’t combine their seperate script files into one.
It seems pretty much no-one understand cache-headers these days. They don’t include any headers to get the files cached at the side of the browser. OSNews used to care a lot about mobile, but downloading or atleast checking every browser-session. If files have changed seem like a bad idea to me, especially on mobile.
Or why they use as many cookies as they do. I count 40 (!). I also do not know why a static file should have a Set-Cookie-header.
Or why they sent headers for those same static files which prevent it from being cached at all by most browsers.
That makes no sense to me.
I’m sure Kroc (I think he does the part of the site you see in the browser) could tell us more about it if he would read this thread, maybe he would even fix it.
But I’m pretty sure he would be bored out of his mind before he got to my comment. 😉
Anyway Kroc if you want any help, let me know.
I’m pretty sure OSNews could save on bandwidth and make pages load quicker if they change just a few things.
My guess is Kroc is a busy man. His HTML/CSS is usually pretty great he just needs to read a book by Steve Souders to get some tips on performance and slightly change his mindset.
I don’t manage OSNews’ code. I updated the header, so most of that is my code, but the bulk of it is old and complicated and as everybody is a volunteer and busy, it won’t be changed any time soon. I’m well aware of performance best practices which my own site employs, but OSNews is not my work.
Atleast I had one thing right, you all seem to be to busy to fix it.
So I guess bandwidth is not a big part of the bill ?
Edited 2011-08-17 15:37 UTC
I think that the current version of OSnews is from Adam.
Kroc used to work on the next version, which has since gone into indefinite hiatus for excessive life parallelism reasons.
Blame Tim Berners-Lee… He invented it and he was heavily opposed to supporting purely presentational markup since day one. The original browser he wrote used the equivalent of a user agent stylesheet to determine how things were displayed (it was not CSS, but it was conceptually the exact same thing).
You make it sound like stylesheets were something someone came up with one day to make your life difficult – they were ALWAYS there… You just didn’t have control over them originally.
HTML, like almost all other successful markup systems that came before it, is founded on the concept of separating presentation from structure and content. This idea is based on decades hard-earned experience. If you want to make a presentational markup system be my guest, but don’t try to corrupt HTML into one – it was never meant for that.
I don’t get your point (or your numbers). I loaded osnews in firebug and I see 5.3KB of css that is used by the site (the rss stylesheet is tiny and is only applicable to rss – it could have been omitted until needed). The actual page content is only 16.5KB. Everything else is javascript, images, or advertising crap and has nothing to do with you argument or mine (and certainly has nothing to do with controlling look or feel).
So the css weighs in at roughly 30% of the content size on the home page. In my experience that is about average. What you fail to take into account is that the 5.3KB styles the entire website, not just the home page. It is used on every single page of the site.
So your options are either:
1. Have a 5KB stylesheet, loaded once and cached by the browser, that can control presentation of all pages on the site for the entirety of the users visit.
2. Create some kind of crazy markup that incorporates all the styling it does, and then include that markup in the content of every page of the site, bearing in mind that the user will have to download all that markup again for every page load.
Ok. Now try to convince me that option 2 is “efficient”. Or maintainable. Or even sane…
That is leaving out the vast efficiency savings that are available with modern CSS (this site is rather old). Just using CSS gradients alone you can describe in a handful of bytes an image that used to take at least a few hundred bytes (and another connection) to download. Using CSS sprites you can combine a large number of images (like icons) into a single one that only requires 1 connection to download and shares a single palette – this can speed up resource loading AND makes things much smaller at the same time. You can also, get this, create different stylesheets for different uses – alternate layouts, targeting specific devices or usages, etc., all with the same markup. The list of things that make CSS good is a mile long…
I routinely make fairly graphically intense modern layouts that are at least an order of magnitude smaller than they would have been without CSS (if that were even possible), and much easier to maintain and understand to boot.
Why don’t you actual learn CSS instead of making up stupid arguments against it?
Edited 2011-08-17 18:26 UTC
Hi,
It was internal, and not something web developers had to care about, and therefore very different to CSS from a web developers perspective (despite being very similar from a web browser’s perspective).
I’m not sure which successful markup systems you’re referring to. I hope it’s not LaTeX (if you’ve ever tried to use LaTeX to get both HTML and PDF output that looks slightly similar you’ll understand why I’d suggest using something else instead).
The web site’s main page has changed since I wrote those numbers (3 new articles added, not sure how many removed), and (at the moment) I get 18.7 KiB for content. The CSS has also changed a lot – it was 215 lines (23.3 KiB) and now it’s only 77 lines (8.4 KiB). I’m wondering if the OSNews staff have done a few things to reduce the bandwidth.
I don’t think it’s fair to ignore any of the javascript. I’d argue that HTML has made it difficult for web developers to control presentation, and therefore they’re forced to rely on (for e.g.) CSS and javascript and direct DOM manipulation to regain control of presentation, and because the final “HTML + CSS + JavaScript + DOM + whatever is used server-side” quickly becomes an over-complicated mess; web developers use libraries and toolkits to try to cope. All of the javascript used by this site is a symptom of the problem, and therefore shouldn’t be ignored.
Given the choice between “HTML + CSS + DOM + who knows what else” and “a markup language designed for presentation and no need for anything else”, I’d choose option 2; because a single 20 KiB page that uses one or 2 languages is much better than a 200 KiB mess that uses many more different languages.
..and ignoring the vast efficiency savings that HTML could have had if modern HTML was designed for presentation.
So you’re suggesting that CSS means things like WML don’t have a reason to exist now?
The model I want is where raw content comes from where-ever (e.g. database), something like HTML is used to present that content to visual users, some sort of “Aural Markup Language” is used to present that content to aural users, something like WML is used to present that content to small devices, something else is used to present the content to search engines, etc. Basically, markup languages designed for specific purposes, rather than a horrid mess that tries to cope with everything imaginable at once.
I did learn the basics. I spent hours fighting with it trying to make it work (and mostly failing because it was far from intuitive). The only thing that learning the basics did was increase my desire to replace the entire “web” stack, from HTTP all the way up.
– Brendan
You probably were either learning from the wrong sources (VERY likely, lots of web rot out there) or failed to grasp how important semantic non-presentational markup is to using CSS properly. There’s a saying I use a lot — CSS is only as good as the HTML it’s applied to. If you’re still vomiting up HTML 3 style presentational markup (a disastrous mess that should never have been allowed in the first place) applying CSS is just going to result in a bloated mess. You start throwing classes and ID’s on EVERYTHING instead of using one convenient parent tag and it’s going to be a disaster as well…
Really though, saying the APPEARANCE on every element in the markup defeats the point of HTML — saying what things are so the USER AGENT can best determine how to show it. As another saying goes “If you choose your HTML based on the default appearance of the tags, you’re using HTML wrong!” — and that dates back to HTML 2. We got away from that with HTML 3 during the browser wars, and HTML 4 Strict was supposed to drag us back on track. (and now HTML 5 is just 3 in drag, worse than 4 Tranny as it least it was on hormone therapy getting ready to go under the knife)
But then, the markup alone is where a LOT of people screw up their pages — concentrating on the appearance before they even have semantic markup of the content (or a reasonable facsmile) with a logical document structure… That’s the approach I’ve been advocating for design over the past half decade or so… Semantic markup of content FIRST — that way you know it’s accessibile to EVERYTHING with tags saying what things ARE. THEN bend that markup to your will creating the layout in CSS for each of your primary media targets — Screen, Handheld, Print (and now screen+width for smartphones/tablets)…. then and only then boot up the goof-assed paint program like Photoshop to create the graphics you’ll hang on the layout. (and with CSS3 even that looks to get a swift boot in the patoot).
It’s why I laugh at the people who end up with the “but I can do it in photoshop” idiocy where they had some artist draw a pretty picture, that’s COMPLETELY non-viable as a website due to fixed height elements, fixed width elements, non-tileable or stretchable elements, and areas that can’t even dynamically adjust to the content inside them.
Hi,
It’s hard to remember the exact details now. What I do remember is that I was trying to use CSS to control page layout, and couldn’t get the layout I wanted – I kept getting strange/unexpected results, like pieces of the layout in unwanted places and pieces superimposed on other pieces. In the end, I had to reorder the HTML and change the layout to suit CSS, rather than being able to get what I wanted.
The layout I wanted wasn’t complicated either (page header, page footer, navigation menu/links at the top right, with main area in the middle). I still don’t know if it’s possible to have HTML in a logical order (e.g. main content, followed by “header, navigation, footer”) where CSS controls layout completely.
Of course I’m not saying that CSS isn’t capable of doing what I wanted (I honestly have no idea). I am saying it was far from intuitive, and that if it is possible it certainly isn’t easy.
– Brendan
Other than for the oddball feature phone that is 3+ years old? Yes, no reason at all. It is dead as a door nail going forward. No one is building WML devices anymore…
And you just illustrated why WML died… You really have some crazy notions, I gotta give you credit for not being shy with them. You are literally the only person I have ever seen describe markup soup as something they actually want.
Hi,
That’s sad – the idea of delivering one file that represents many (small) pages seemed important. I also severely doubt that you’ll ever be able to have one HTML file, with one CSS file that lays that HTML out as “one big page for normal users” plus another CSS file that lays that same HTML out as “many smaller pages for mobile users”.
I’ve got an idea. Rather than having lots of different vehicles (planes, cars, trucks, wheelchairs, skateboards), lets attempt to create a silver bullet that completely sucks for everything.
Different markup languages designed for different purposes is better than “10 variations of HTML plus 5 variations of XHTML plus 3 variations of CSS plus javascript plus DOM plus java plus flash plus 10 server side scripting languages plus at 15 different toolkits and frameworks to try to make it bearable for web developers plus browser incompatibilities because nothing helps make it bearable for browser developers” all sugar-coated in a layer of hype.
It’s the old “Do one thing and do it well” idea.
– Brendan
Depending on how complex it was… You could do something fairly trivial (i.e. equivalent to WML cards) with just HTML+CSS. You could even add transition effects to it and do a lot of neat stuff that WML cannot do – the card and stack metaphor is not really very complex to recreate.
However, if you wanted to keep the navigation history intact you would need a bit of javascript, at which point you would probably be better off just going all the way and using ajax to implement this as it adds a lot more flexibility vs. pure HTML+CSS.
Is it easier to do it this way than to use WML? No, not initially – but it isn’t rocket science either. Once you got the initial CSS/javascript bits working properly the markup is exactly the same as it would be for a regular HTML page, and you could even apply the card metaphor in the desktop browsers if you wanted to. It isn’t easier, but it is much more flexible and anything that supports HTML would understand it.
(HTML + CSS + Javascript) = infinite(MARKUP LANGUAGES)
…as long as the thing you are marking up fits the mental model of a generalized document. HTML is not a good way to describe everything, but as long as what you are describing is conceptually a document, you really do not need anything else. Ever.
I’ll try saying it this way… Any markup language you come up with will, BY DEFINITION, be severely limited in what you can do with it until you add 2 things to it:
1. The ability to define/redefine what the markup actually does (this is what CSS does).
2. The ability to add procedural, non-declarative, state-maintaining logic to it (this is what Javascript does).
That isn’t opinion – it is simply fact. Anything short of being able to do both of these and you end up with an inflexible waste of time that you will hit the proverbial wall with rather quickly.
HTML already has both of these, and by having them both it is inherently adaptable to pretty much any presentational device – a visual browser, a screen reader, something that generates brail, something that carves stone tablets… Doesn’t matter. You might need to come up with a new type of stylesheet to handle it (like aural), but you do not need to redefine HTML itself.
You could, if you wanted to, turn HTML into a procedural markup language. You would make each tag accept every possible attribute that can possibly affect it’s presentation (which in reality would be 1 attribute for every possible CSS property in existence – there are about 100 or so). You would have something like a sort of “megatag” under the hood that logically maps to a big function that can work with all the parameters known – all of your normal tags would simply be sane defaults for initializing the function so that say your font tag expects all the properties relevant to fonts, the big tag has a large default for font-size, etc. etc. It would still look and work like HTML, but the functionality would essentially be frozen into the schema of the markup language.
Then you would have to do it all again for screen readers, because they are fundamentally different….
Every time you wanted to add a new styling ability, you would have to release a new schema for the markup language, so that editors could deal with it, browsers could add the ability to parse the new properties and implement them, and users would know what their new options were. So you would have many distinct markups languages for each type of presentation device, mostly identical to each other with the exception of presentational attributes.
This is exactly what CSS does, with 4 important differences:
1. It adds a different language with a syntax optimized for defining presentation attributes in a much more concise and logical way than what can be described purely as attribute values. Markup is a horribly inefficient way to define things, because a definition is something that stands on its own – markup is for describing things – and the thing it is describing it what is contained inside the markup.
2. It adds the ability to map these presentation definitions to markup tags in a way that allows you to reuse the definition over and over again (inheritance). In effect you are defining your own tags when you do this.
3. It gives you the ability to inline the presentation properties within a single attribute (the style attribute) when you want to simply inline them and do not need inheritence. This gives you exactly the same capabilities as a procedural presentation tag language would, but is flexible – the capabilities are not frozen into the language schema anymore. Which leads to…
4. The absolutely most important part: you can add things to CSS without requiring any changes at all to the markup language itself. It exists separately. You can even define entirely new dialects of CSS for other purposes (like aural). The presentational capabilities of HTML 4 have increased immensely in the last few years, all without anyone having to come up with any new version of HTML.
Yes. EXACTLY!!! Markup does one thing very well – it describes things (i.e. “this is a paragraph”). CSS does a different thing very well, it defines things (i.e. a “paragraph” is a block element which indents the first line by 3em and has a top and bottom margin of 1en”).
The “do one thing and do it well” mantra is pretty much the reason that there is a fundamental distinctions between HTML and CSS – one language cannot do both well without being inherently cumbersome.
If you cannot see the inherent logic in this argument I don’t know what else to tell you…
Somebody hasn’t heard of Aural Stylesheets.
Hi,
You’re right – I hadn’t heard of Aural Stylesheets (and I wouldn’t be surprised if most people haven’t).
Do they magically restructure an entire web site? For example, with an Aural Stylesheet would the OSNews main page automatically be split up into many smaller (easier to navigate) pages with no more than about 8 articles/news items per page; with the headlines as a single list at the beginning (and all the extra clutter like the search, login, and the “legalese” at the bottom shifted to a separate page)? Or was I right from the start – it’s a barely adequate compromise that fails to come close to being usable on it’s own (unless web developers deliberately design a radically different “intended for audio” version of their site, that shares nothing in common with the “intended for video” version other than the database backend)?
Forgive me for suspecting the latter..
– Brendan
Edited 2011-08-17 10:18 UTC
It seems that you understand the what engineering is …
Magically expecting a specification to solve a problem instantly is ridiculous.
Lately I been using 51Degrees Mobi to deliver content for Mobile phones based on what the phone can do.
This toolkit doesn’t magically solve the problem for me but it gives me the ability to build something which does … much like the Aural Stylesheets.
Hi,
And that is probably where the problem starts. It doesn’t magically solve the problem, but does lure web developers into thinking “semantics” is “good enough”.
Providing facilities to allow blind people to use a web site isn’t really an option. Typically there’s legal obligations (various equal rights laws in different countries). Most web developers just couldn’t be bothered doing extra work for a relatively small amount of potential users. Instead they create “visual user only” web sites then fail to provide a stylesheet for aural users; and pretend that using semantic markup is “enough”.
Basically, “semantic markup” is used as a scapegoat, so web developers can continue doing nothing for blind users despite legal obligations.
Note: Before when I said I hadn’t heard of Aural Stylesheets, what I really meant was that I’ve done several web development modules (all of them that were offered) as part of a CS degree, and hadn’t heard of Aural Stylesheets. The university completely skipped over the entire issue. I’m hoping galvanash will reply to this too – he’s been doing web development since 1996 or so, and I’d be willing to bet that in those 15 years he’s never created an aural stylesheet or tested any of his web sites with a screen reader.
Now consider what would happen if there was an Aural Markup Language (AUML?); and if web developers couldn’t rely on the “semantics” scapegoat. Web developers would be forced (by legal obligations) to actually design sites for blind users; and if that happened a lot of people (not just blind people) would use it (it’d be perfect for things like smartphones – imagine browsing OSNews via. headphones while you’re out jogging).
– Brendan
I think CSS is a shining pearl.
Not only in structure. (bring a sort object orientated approach like inheritance) but also semantically it is very quick to grasp, write and read.
It also is preferred use in many best practice due to performance advantages to HTML styling tags.
Tables is one example where the CSS styled ones load faster than the HTML tags.
I hope that they can just forgo the majority of HTML styling tags in favour of CSS.
Aural stylesheets – no. I have read about them but I have never done a website using them. I have, however, tested quite a few sites I have done using JAWS. I will admit, however, that the effort was simply to ensure basic compatibility with a screen reader – I wanted it to work, but we did not go out of our way to optimize for it. That said, if you just want basic screen reader support and you use semantic tags properly it is pretty much automatic
Well in any discipline you will have those that will do “just enough” and those that will make their best efforts to great stuff.
Blaming the semantic markup and CSS however for lazy devs is still crazy.
Better standards support for screen-readers would be welcome, but tags like em and other ‘crud’ are very useful for rendering HTML in Braille or have it read by screen-readers. Compared to Word or PDF, HTML (when written with semantic tags) is far superior for the blind and visually impared.
WOW… that’s the dumbest thing I’ve heard in a long time. Lemme guess, ASP developer?
Semantic markup and separation of presentation from content allows you to use less markup in your server side code — it allows you to reskin the entire page without once touching whats making the markup — it usually ends up less code overall.
How is that “making developers work harder” — or are you one of those who’s worshiping at the feet of the dipshit photoshop jockeys who think they know ANYTHING about accessibility, maintainability, or even what’s practical to implement on a website in the first place?
Your entire post reeks of failing to understand the technologies you’re running your mouth about! But then, I could say the same thing about the people who coded the latest iterations of Hotmail, Yahoo’s entire site, or Google Search…
Type of statements I’d expect from someone white-space stripping to hide bad coding practices, still using tables for layout, failing to put a doctype on there so it has to hack around IE being in quirks mode, line-breaks instead of paragraphs, non-breaking spaces and line-breaks to do padding’s job, tables for NOTHING (worse than for layout!) and inlining ALL their presentation so they can’t even leverage caching models across pages.
Much less a lack of headings, lists or anything else to make things like search engines and screen readers treat a page as anything more than one giant run-on paragraph. Author meta after HEAD is closed, multiple instances of closing head and opening body, inlined style attributes, invalid inlined styles… Triple-nested BIG tag doing H1’s job… You know, 2.5k doing 1.1k’s job?
Edited 2011-08-17 23:22 UTC
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.
You mean like the EXISTING tags of numbered headings and ul?
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.
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
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!
Which could just as easily have been added to OBJECT.
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…
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)
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.
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)
Only reason they exist is to target them via hash, scripting or CSS… Using semantic tags usually involves using less classes and ID’s…
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.
… 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.
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.
I’m not seeing where you get that as I am in fact arguing in FAVOR of semantics — and that’s my problem with the new tags as they muddy the water by applying extra meanings we don’t need. It’s like the nimrods who go around slapping P around EVERYTHING just because it happens to be text or in flow. (P around IMG comes to mind)… A LABEL/INPUT pairing is not a paragraph or list item or table cell. Putting a P around it is pointlessly applying the wrong semantics… To me, putting NAV around a UL is that same type of idiocy… or DIV#header vs. HEADER when a numbered heading tag (H1,H2, etc), maybe with SMALL for de-emphasis and a couple span as styling hooks can typically handle that all by itself.
But then I always hated id=”nav” or class=”nav” — so NAV as a tag is going to annoy me as being pointlessly vague. EVERY BLASTED ANCHOR ON A PAGE is “navigation” — doesn’t narrow it down a whole lot on meaning. Are we supposed to now wrap it around everything that has an anchor in it? I think not. Pointless bloated element that exists NOT for the accessibility bullshit they claim, but to justify the people who put that extra div around their UL for NOTHING. Probably why I use classes and ID’s like “mainMenu”, “userMenu”, etc…
NOT IF WHAT GOES INSIDE THEM ARE THE EXISTING SEMANTIC TAGS (H1, H2, P, UL, OL… even HR) — at which point wrapping them with ANOTHER semantic meaning … well, that’s shellac on a pile. Covering a turd in bug excrement isn’t the answer, no matter how shiny and new it looks.
I think that’s what you’re missing — I don’t see the point of these allegedly semantic new tags if they’re just going around tags that already have meanings. That’s called pointless bloat!
This is how I interpret the new tags…
NAV = The stuff here consists of primary navigation links. If you are looking for the collection of links that the author identifies as authoritive this website you just found it.
HEADER = The stuff here is NOT part of the primary content of this page, it is decorational and/or contains index/navigation items that are not related to the primary content.
FOOTER = Semantically means exactly the same thing as HEADER, it simply allows for a distinction between things that come before the document and things that come after.
ARTICLE = This stuff here is a self-contained document that is capable of standing on its own. If you want to just grab the meat of this page this is what you want.
ASIDE = Stuff that isn’t critical to the rest of the content on the page (like the news sidebar on this site)
SECTION = Arbitrary way to divy things up if you so choose to. I’m not a big fan of this one because it seems to me exactly the same thing as what DIV was supposed to be.
MENU = Everyone thinks menu is a bit “off”… which is why no one supports it. Since no one supports it it probably won’t be around much longer (unless someone can think of a way to actually use it effectively)
Anyway, I won’t go through them all, because most of the remaining ones are not terribly useful. HTML5 is not perfect – never said it was. I just don’t see why you are so hell bent against it. At least some of the semantic tags make a lot of sense – your contention that they all just replicate existing tags doesn’t jive for me at all. Sure, you can hack a lot of the existing semantic tags into whatever you want them to mean, but then you have lost their initial meaning. For example, an H1 should be the top level heading in a document – a HEADER of a webpage is something else entirely – HTML5 just makes that distinction explicit.
It brings in new tags primarily to recognize the fact that “documents” that exist outside of the web (which contain their own existing semantic structure) need a way to be incorporated into existing website structure without having to heavily modify either the website or the document. If you don’t see the logic in this I don’t know what else I can tell you to convince you.
In other words UL/A’s job, maybe with ARIA roles…. tags you’d probably HAVE inside it ANYWAYS making it a pointless extra container.
Like the H1, maybe a para that’s directly under the h1 which means it’s not sectional content, making this tag nothing more than justification for the people who insist on ading DIV#header to the markup for no good reason.
This is one I can ALMOST see the point of — but if it’s floating content at the bottom after a HR, I really don’t see the need for this to have anything more than a DIV… and that’s as a STYLING hook, not a semantic one!
In other words all content that should be between H2’s or between an H2 and a HR… assuming you bother with the semantic meaning of HR. (but much like the rest of the elements, nobody bothers looking at the meaning and goes right for it’s default appearance)… but then my hand flies up ready to deliver a “Benjamin Sisko’s mother-**** pimp-slap” every time I see H1 containing a title immediately followed by a h2 with a tagline inside it… when that tagline is NOT the start of a subsection of the document.
Which is NOT what an ASIDE means, though certainly everyone seems to be ABUSING it as such — an aside is a side note about the main topic, that isn’t integral to it. Using it for elements unrelated to the main topic means it’s not an ASIDE…
I’m not sure what good an element nobody is going to use for what it means is going to be in a specification where nobody is bothering to do that anyways…
Which is how I see all these other elements. DIV — division, divide it up into sections.
Doesn’t help W3SchoolhouseRot is already abusing it incorrectly in their examples… though these days that steaming pile of webrot only continues to plod on like the old gray mare because nubes are STILL dumb enough to think the site has anything to do with the W3C. (which it doesn’t).
Funny thing is, if they just brought menu back as what it was in 3.2, it would automatically work everywhere and be a great option instead of NAV.
Funny that, the ones I think are useful you didn’t mention. DATALIST, WBR, and MARK… and I only list MARK because it means no more stuffing a class on SPAN’s for doing that. I really wish there were a lot less of these pointless grouping containers redundant to DIV and a lot more MEANINGFUL tags for wrapping raw CDATA. METER, PROGRESS and TIME for example aren’t bad either.
But those aren’t the ones anyone’s even trying to use or getting excited about — and I really don’t get that. The “semantic” block level grouping containers really are bloat, nothing more.
under-which all other headings are the start of subsections… meaning it should be the topmost eading on the page; like the heading on the site. I fail to see how flushing heading structure down the crapper and “making them all H1”, abusing the h1/H2 pairing for taglines, and grouping them in an extra tag for nothing is an improvement — unless it’s throwing your hands up in the air and saying “Screw it, people are too stupid to use numbered headings”.
I think in a lot of ways that’s my biggest issue with 5 — a LOT of it seems to be “people are just vomiting up 3.2 and slapping tranny on it. Oh well, let’s placate them and to hell with making things better”… hence the looser rules, more tags for people to abuse and mis-use when they can’t even use any of the existing tags right, etc, etc…
It’s like the W3C threw it’s hands up in the air and said “Oh well, just barf up a spec any old way”.
Edited 2011-08-18 02:13 UTC
You are completely missing my point…
If you author a document (say a white paper), you want to use document semantics. The new grouping tags (header, footer, article, etc.) are NOT document semantics – they are web page semantics.
It is to facilitate the very common practice of embedding a document that was created for stand-alone use into another document that was created to house web content… If the author of the original document did his job right, and you do your job right and use the new semantic grouping tags – you won’t step on each other’s toes so to speak.
The point is – if you do what a lot of people have done in the past (including me) and styled your H1 so that it behaves as a block header with a background image and other such stylistic stuff (not using ids or classes)… Well when you inject a document that contains H1 elements it all goes wonky. Sure, you can work around it about 20 different ways, but this avoids the whole problem quite elegantly imo.
I get where you are coming from – I really do. I also do not like wasting tags when they are not needed. But header, footer, nav, article, and aside are genuinely useful if you accept them for what they are – semantics created to match how people actually write web pages (as opposed to semantics for documents – which is what we had already). But whatever, to each his/her own. I don’t expect to convince you to change your mind – but I hope I gave a rational enough argument that you at least won’t continue thinking all people supporting HTML5 are stupid
ps. The news sidebar on this site is a perfect example of what an aside is supposed to be. It IS related (it acts as an overflow to the main news items) but it is not critical (or integral) to it. I don’t have a clue why you would think otherwise.
ps.ps. HTML5 supports ARIA roles just fine. But ARIA is not intended to be purely semantics – it is semantics with a concrete purpose (accessibility) and as such it is much more complex than the modest addition of a few tags. Its also still a draft spec and virtually no one is using it. Just saying…
(I will try not to repeat what galvanash already mentioned)
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 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.
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.
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).
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
Wow, damn. Thank you Professor Obvious for clearing that up.
They’re basically saying HTML5 is insecure because javascript is plaintext.
This has to do with the program design and not the choice of HTML for the implementation.
They use Facebook and GPS location as an example.
In the end, you’re relying on the phone to tell the truth. This is true whether it goes through a Javascript layer or is programmed natively. These things can be spoofed at a hardware, OS or driver layer upstream or the communications layers downstream.
If these locations need to be relied upon you need to control the entire stack beginning with tamper-proof hardware strapped to someone’s ankle. Things which you cannot control, say cellular communications, need to be encrypted and the locations need to be signed.
And even then, you need to make sure that the person’s foot is still attached 😉
Took me a while to realize that, by “native apps”, he meant things like Microsoft Office.
If you assume he means things like iOS/Android apps, the only potential complaint with any merit to it is that HTML5 local storage isn’t designed to be easily backed up, copied between browsers, etc. the way a .doc file could be.
(I don’t consider “1. Your code is forced to be at least technically open-source” to be a valid complaint under any circumstances, so I ignored that one)
…to worry about. Just stop with the flash/multiple pop up/”Are you sure you want to leave the page” annoying BS that has made the web a PITA just to surf. WTH is wrong with these people?
There are legitimate uses to these “Are you sure ?” modals, actually. I’m glad the WordPress editor uses them, as an example. It’s just too bad that people abuse them so much.
The big problem I have with HTML5 is the attempt to do a whole heap of changes all at once rather than a bit by bit piecemeal approach where the most important (but non-controversial) things can be standardised and deployed straight away and spend more time on the more complex controversial things that don’t need immediate deployment.
Take video and audio – that is the the number one reason why most people have Flash installed in the first place, so that they can watch YouTube and other video services. The focus should be on low hanging fruit like that and not marketing HTML5 as some sort of swiss army knife that’ll slice, dice and keep the lettuce fresh for up to 5 days.
HTML5 isn’t the be all and end all but for a large number of people once those low hanging fruit are addressed the the need to have it installed pretty much evaporates pretty quickly. Does Flash have a place in the future? sure it does but it shouldn’t be at the expense where we have advertisers playing obnoxiously flashing videos.
You are confusing HTML5 the buzzword with HTML5 the markup standard… HTML5 is the “bit by bit” approach. The alternative was XHTML2, which represented massive and fundamentally incompatible changes relative to HTML4.
I hear so many people saying things like “Now HTML 5 is here, nobody will need to use Flash anymore because HTML 5 can do video!”
Flash is a lot, lot, LOT more than just a video playback system for the web. A lot of people don’t realize it. For these people, it’s the hardest truth.
You mean something like what this tool does for HTML5 ?:
http://tumultco.com/hype/features/
Just let us look at security. When security *does* matter, it is the right way to have access to the sources. You *can* look for security issues. You can’t do that on closed systems. You have do secure your system, regardless of the point. Regardless if the user can see the code or not. They can always disassemble or you have to do it server-side. It will be attacked sooner or later.
*But* there is another thing that is a part of this all: Copyright. Do you have a license for all the parts of the html5 & JavaScript code? And a redistribution license? And a license that doesn’t need to be accepted by the user? (Just imagine: enter a url and get asked if you like to accept the printed GPL. And you have to accept it to get the JavaScript Code, which renters the web site, … )
This might not be relevant now. But when lawyers start to sue site owners and users, it will be different. And as we know the lawyers, it will be.
While most people see future web apps as more basic application aimed at consumers I have recently been in charged of creating specialized tools for internal use at a company. Of course, these tools had to be HTML5.
You will get into trouble when you are working with lists of several thousand items (some of our databases have row counts in the millions) and while just doing iterations in pure JS is pretty fast the slowest operations are DOM manipulation and changing the “GUI”.
You have to know a few tricks and make good use of localStorage and WebWorkers (+ a lot of ajax to reduce those hundred of thousands of rows to “just” a few thousand) if you want to get these kind of things done. Something you don’t have to deal with in native apps.
Mind you, that these issues are not only related to niche, complex applications. Just take the example of a music application. A lot of people have a library of several thousand tracks and working with that in a native app is no problem, but creating an <li> and doing JS manipulation on it will get you closer to the limits of JS speed.
So while some people say that the JS speed race is merely artificial at this point I say: give me moar!
Long live Flash! Yes I know it’s buggy sometimes, but it is secure, cross-platform and is easy to develop in, nuff said.