Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
IT

How HTML5 Will Change the Web 208

snydeq writes "InfoWorld's Peter Wayner looks beyond the codec and plug-in wars to examine nine areas where HTML5 will have a significant impact on Web development. From enabling more interactive graphics, to tapping local file storage, to geolocation, HTML5 is rife with rich capabilities — and may even improve our ability to secure applications delivered via the Web, Wayner writes. But the most important impact of HTML5 will be its ability to simplify Web development itself: 'HTML5 offers one language (JavaScript), one data model (XML and DOM), and one set of layout rules (CSS) to bind text, audio, video, and graphics. The challenge of making something beautiful is still immense, but it's simpler to work with a unified standard.'"
This discussion has been archived. No new comments can be posted.

How HTML5 Will Change the Web

Comments Filter:
  • Doesn't HTML5 JS still provide XSLT as well as DOM?

    • by jrumney ( 197329 )
      XLST is not a data model. It is however a different language than Javascript, and could be used to transform some other data model to DOM on the fly. Also I can't see JSON being replaced by the one true XML any time soon.
      • XSLT is not in itself a data model, but it assumes a data model that is not DOM (although obviously all "working with XML" models tend to have a lot in common). XSLT/XPath 2.0 depends explicitly on the W3C XDM data model. XSLT 1.0 (which is what you tend to find in browsers) is a bit more murky, but, for example, you won't find Result Tree Fragments in DOM (thank goodness).

        Recently there has been a bit of revival in client-side XSLT processing, so the point isn't totally obscure...

    • by improfane ( 855034 ) on Wednesday June 23, 2010 @10:23AM (#32665478) Journal

      Why are we using HTML5 and not XHTML 2?

      XML abuses aside, XHTML is superior to HTML5.

      HTML5 requires a more complex parser than XHTML ever will. XHTML can be validated for correctness, HTML5 is more difficult to do so.

      I honestly don't understand the reason for following the HTML route. XHTML is already in an industry understood format that tools already exist for.

      The market rarely reflects a superior technology. I still support XHTML. HTML5 is messy, ugly and a kludge.

      All that needs to happen is to transfer some of the newer tags of HTML5 into XHTML. Perhaps we can borrow from the microformat peeps? Afterall, it's supposed to be modular.

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Wednesday June 23, 2010 @10:48AM (#32665798)
        Comment removed based on user account deletion
        • by horigath ( 649078 ) on Wednesday June 23, 2010 @01:44PM (#32668374) Homepage
          HTML5 includes an XML model which is optional—much like the previous HTML 4/XHTML 1.x system. I expect many developers to use the XHTML syntax in their HTML5 projects for all of your reasons. Meanwhile, the proposal for XHTML 2.0 was unsuccessful because it was created almost completely without regard for what browsers and coders were already doing—it's incompatible with previous formats, where HTML5 was designed in part to gracefully extend the old formats and incorporate emergent practices already in use on the web.
      • by Jeremy Visser ( 1205626 ) on Wednesday June 23, 2010 @10:48AM (#32665818) Homepage

        There is nothing stopping you from using well-formed XML in your HTML5, or serving your document as application/xhtml+xml (explicitly stated in the HTML5 spec). Serving HTML5 as proper XML is dubbed "XHTML 5". It uses the same doctype. All the new tags -- video, audio, section, header, etc. are supported, but obviously the lax markup features of HTML5 (like being able to omit most tags) no longer apply.

        • by Xest ( 935314 ) on Wednesday June 23, 2010 @02:19PM (#32668926)

          The issue isn't that it's not possible, the issue is that HTML5 seems to tend towards HTML markup over XML markup.

          Effectively it pushes bad practice as standard because there really is no benefit to HTML markup other than the ability to write sloppy markup, which is stupid.

          People publish using tools nowadays, leave markup to the professionals (not that writing well formed XML is hardly a difficult job). If people can't understand how to write well formed XML markup then they've got no chance of understanding CSS and Javascript so might as well give up and use a web app to publish for them anyway.

          Best to support the people who actually write web apps to make it easier to write better web apps, than to support sloppy developers who use HTML markup "because it's easier".

      • Re: (Score:2, Interesting)

        by grumbel ( 592662 )

        XML abuses aside, XHTML is superior to HTML5.

        HTML can be loaded incrementally, XHTML can't, as you can only validate the document when you have all of it.

      • You can use XML-conformant HTML 5. It's called XHTML 5 (read the spec).
      • HTML5 requires a more complex parser than XHTML ever will.

        I guess that parsing time is a fraction of the whole time required to render the page: text rendering, displaying images and running JS.

        As I have never wrote a HTML parser, I can only draw analogies with other fields. E.g. in source code compilation most of the time is spent in optimizer, not parser. Even when optimizer is off, the times are still dominated by (1) the reading of all the source files (in C - headers) from disk and (2) semantics validation and code generation.

        • That sounds accurate about the actual parsing complexity but I didn't necessarily mean complexity at run time.

          I meant that a XHTML parser would imaginably much simpler than a HTML5 parser.

          • A HTML5 parser has many more potential code routes: with quotes, without quotes, overlapping, non-overlapping, I believe it needs a much more complex state machine to provide the flexibility. there is more conditionals in processing a document and generating the tree.
          • A XHTML document can be validated by DTDs or XSchema. Va
      • by mortonda ( 5175 ) on Wednesday June 23, 2010 @11:10AM (#32666154)

        Why are we using HTML5 and not XHTML 2?

        XML abuses aside, XHTML is superior to HTML5.

        Go read http://diveintohtml5.org/ [diveintohtml5.org]

        Essentially, the argument is, make it easy for the users - the web programmers, not the browser programmers, and to allow the browsers to incrementally implement the standard, rather than an all or nothing that no one will do. . Telling the browser to error out when the html is not correct or supported is user UNfriendly. HTML5 provides a graceful way to handle it.

      • Re: (Score:3, Interesting)

        by Tarlus ( 1000874 )

        I'm with you on this. It took me a while to get a good feel for valid XHTML strict. But I like the tight specification, because it makes the markup very consistent. (Ex: lowercase only, quotes for values assigned to parameters, closing slash on unclosable tags. Such as
        .) I've been seeing some HTML5 examples which seem to lack that same OCD level of control and it kinda makes me twitch. More user friendly, yes, but I've come to enjoy consistency. That's my preference and it's what works for me.

        Most of the n

        • by Tarlus ( 1000874 )
          And of course, I forgot to post that as plain old text. So my tags were rendered. Blah.

          (Ex: lowercase only, quotes for values assigned to parameters, closing slash on unclosable tags. Such as <br />.)

          Most of the new elements in HTML5 look like alternatives to div's with unique ID's ( <header> vs <div id="header">)
      • by lee1 ( 219161 )
        You can use xhtml syntax in html5 documents. To make your xhtml file into an html5 file, just change the doctype, and you're done. Some of the problems with xhtml documents, besides draconian error handling (which some see as an obstacle, although I don't) are: must serve with xml mimetype, which is not handled by IE, so you must break standards by serving to IE as html (which of course requires you to sniff for browser type); can not use document.write, which means it's awkward to include Google advertise
      • Why are we using HTML5 and not XHTML 2?

        Because HTML5 has better backward compatibility to existing HTML documents (and, for that matter, the model of XHTML 1.x) than does XHTML2, and adds features that are more useful to content providers and developers in delivering content and applications that are useful to end users.

        XHTML2 may have had some ideas that are, in their area, superior to HTML5, but is overall inferior in terms of features. Being XML-only (unlike HTML5, which supports an XML rendition but als

      • by mcvos ( 645701 )

        Why are we using HTML5 and not XHTML 2?

        Because XHTML 2 is designed by academics, while HTML 5 is cobbled together by browser makers.

        Browser makers apparently have different concerns. They don't care so much about abstractions and separations of concerns, and more about how easy it is to implement a renderer for it and how it will perform. Browser makers are probably less ambitious and more pragmatic. Or maybe they want to mark this out as their territory, instead of having other people tell them what to implement.

      • by Ant P. ( 974313 )

        Why are we using HTML5 and not XHTML 2?

        HTML5 is more than vapourware, and provides new features that are useful to people making real-world websites.

        XML abuses aside, XHTML is superior to HTML5.

        That is not logically possible when XHTML is a subset of HTML5 [whatwg.org].

        HTML5 requires a more complex parser than XHTML ever will.

        Guess what? The real world isn't a pretty theoretical little flower. HTML5 defines consistent error handling for content on the existing internet, not the non-existent one.

        XHTML can be validated for correctness, HTML5 is more difficult to do so.

        The code exists for both already, so this is a moot point.

        I honestly don't understand the reason for following the HTML route. XHTML is already in an industry understood format that tools already exist for.

        Because we're sick of waiting decades for the fucking W3C to do anything. They've procrastinated themselves

  • As always... (Score:5, Informative)

    by ojintoad ( 1310811 ) on Wednesday June 23, 2010 @08:44AM (#32664274)
    The link you really wanted where everything is on one page: http://www.infoworld.com/print/128080 [infoworld.com]
  • by betterunixthanunix ( 980855 ) on Wednesday June 23, 2010 @08:46AM (#32664294)
    HTML5 may offer a unified way to do things...but that does not mean that the other ways will just vanish. It will be a long time before HTML5 completely displaces Flash or Java applets, assuming that such a thing even happens. Frankly, I doubt that the popular browsers will even have a reliable implementation of the standard until at least 2013, so HTML5 won't really offer developers anything unified for a while.
    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Wednesday June 23, 2010 @08:54AM (#32664400)
      Comment removed based on user account deletion
      • by betterunixthanunix ( 980855 ) on Wednesday June 23, 2010 @08:58AM (#32664442)
        As you point out, developers will use a library that resolves the incompatibilities for them. More precisely, they will seek software the levels the field between browsers -- software that already exists, in the form of applets (Flash and Java) and HTML4/JS/etc. libraries. My point was that the current way to deploy applications on the web is not going to disappear just because HTML5 comes out, and that incompatibility between browsers will only ensure that the current methods stick around even longer.
      • > we can make games that run on pc, xbox, and ps3 but we can't manage some browser quirks?

        We do manage browser quirks. It's just a huge time sink that takes away from productive work.

        Also, try the following exercise. Make a list of every game that works on every version of xbox, every version of playstation, every version of nintendo, and every version of Windows. If you get zero, make a list of the apps that run on any version of each platform. I think you will realize that web apps are, in practice

    • by thijsh ( 910751 )
      They seem to agree on this, and think Flash is the way to go (see http://www.infoworld.com/print/125721 [infoworld.com]). Either that is BS or this article is BS, they can't claim both. Everything they say could be said for Flash and vice-versa.
      • They seem to agree on this, and think Flash is the way to go (see http://www.infoworld.com/print/125721 [infoworld.com]). Either that is BS or this article is BS, they can't claim both. Everything they say could be said for Flash and vice-versa.

        Sure they can have it both ways, just as long as it increases page hits on the infoworld website!

    • Re: (Score:3, Interesting)

      by Lumbre ( 1822486 )

      Frankly, I doubt that the popular browsers will even have a reliable implementation of the standard until at least 2013

      I doubt IE will ever have a reliable implementation for anything. HTML5 surely aims to simplify web development, but MS aims to use their proprietary BS, tags, and implementations. Just look at their box model. Look at all the extra time we have to take to develop for IE users.

      Plus, there are accessibility issues we have to overcome. We also need to develop for that small fraction of the population who use text browsers, those who are blind and have text read to them, those who don't install Flash (f

    • Whatever happened to XHTML taking over? I remember some people going crazy over it since it would simplify HTML (since HTML 4 was too bulky, whatever) and leave all the layout dirty work to CSS. Seems like HTML5 throws all that out and sticks with the status quo.
      • Re: (Score:3, Insightful)

        by Nadaka ( 224565 )

        What happened was that xhtml2 had two flaws.

        1: errors were treated like errors. That means that broken hacks made by graphic artists would result in an error message instead of a random attempt to render a broken document. This also made creating a partial implementation more difficult.

        2: No one implemented a reference implementation. So that web browser vendors would have to do all the heavy lifting.

        WHATWG formed and decided to take all the hacked errors and random implementations of browsers and make thos

        • As usual, its all political, kinda like an open source app forking then re-merging. XHTML1 was fine, most folks implemented it. Sounds like they are just going to kludge an XHTML5 from HTML5.
        • For some reason, W3C then abandoned the superior standard of XHTML2 and adopted the steaming pile that WHATWG dumped on them.

          You contradict yourself. How "standard" (as in "pile of paper") can be superior to actually working implementation?

          End-users (aka "content consumers") gain nothing from idealistic approach of pushing superior standard over working implementation. And HTML5 tried to address the needs of the end users by throwing bunch of fancy multimedia stuff into the standard. That to my limited knowledge wasn't even part of XHTML2.

          In the end, WHATWG has very little manpower to simultaneously create a great spec and

          • Re: (Score:3, Interesting)

            by Nadaka ( 224565 )

            I would hardly call html5 an actual working implementation. Hell, html4 isn't perfectly implemented in a good chunk of browsers yet.

            XHTML2 was an extensible format by definition. There was nothing there stopping you or anyone else from adding a video or canvas tag to it.

            A good specification needs to be consistent, it needs to be logical and well formed, it needs to be minimal but specific, it needs to address known problems with the previous specification.

            HTML5 is and does none of these.

          • Re: (Score:3, Insightful)

            by 0123456 ( 636235 )

            You contradict yourself. How "standard" (as in "pile of paper") can be superior to actually working implementation?

            I hope you're not a software developer. The world is full of 'actual working implementations' which have caused years of pain for the sake of not spending a few days thinking it through on a 'pile of paper' before implementing, and then 'not having the time' to rewrite it once the blatant design flaws become obvious.

            Most of the worst ideas in the history of the web have come from taking some web browser's 'working implementation' and making it part of a standard.

    • Re: (Score:3, Interesting)

      From TFA ...Flash groupies joke about HTML5 being a time machine to take you back to 2000...

      Because it replaces Flash completely .... and they are worried

    • HTML5 may offer a unified way to do things...but that does not mean that the other ways will just vanish.


      Nor does it mean that new ways will not evolve outside the standard.

      The standards committee moves slowly. It is beset by commercial, nationalist and ideological rivalries - which the entrepreneur - the outsider - can cheerfully ignore.

    • I have only bad things to say about Flash to be honest, however unfortunately browsers are not yet ready to play movies (the only reason I use flash anyway).

      However saying that browser with HTML5 will be enough to completely get rid of a Java applet is most likely misleading.

      I have real reasons to disagree with this, primarily based on a couple of months of work I put into research and development trying all possibilities in a browser to have a truly desktop-like application developed. I started small, wit

  • Of course (Score:3, Funny)

    by ch-chuck ( 9622 ) on Wednesday June 23, 2010 @08:46AM (#32664296) Homepage

    It will be adopted by progressive advertisers to achieve even greater degrees of annoyance per page

    I've seen the future and it's having a 50% off sale for the first 100 customers to click now!!

  • HTML5 will help change the Web, however, the true change that will come to the Web is finally when the Semantic Web will take off; unfortunately no one knows when or if it ever will.
    • by Yvanhoe ( 564877 ) on Wednesday June 23, 2010 @09:41AM (#32664906) Journal
      Semantic web will take off when AI agents will be elaborate enough to fill in all the metadata thet humans don't care about (because they are still better than computer at rebuilding the context of an information). Right now user-entered information has this form : "#GoReds : Arrived at the stadium at 10AM woohoo!" and semantic web expects them to do something like

      "<user id=1983744 nick="#GoReds"/> : Arrived at the<location><reference>ElisParkStadiumSouthAfrica</reference><tag>stadium</tag></location> at <datetime><timezone>SouthAfrica</timezone><time>10:00:00</time></datetime> woohoo"

      The core assumption that users cared about filling correct metadata was wrong outside the research community (and even outside the IT research community). It will take off but you need software to fill in what was assumed users would do.

      • by 0123456 ( 636235 )

        The core assumption that users cared about filling correct metadata was wrong outside the research community (and even outside the IT research community). It will take off but you need software to fill in what was assumed users would do.

        Now you just need to explain to me why I would _want_ my computer adding arbitrary information such as my location to every message I send.

        "Hi mum, I'll be over once I've finished watching a <reference>Goatse</reference><tag>video</tag>"

  • I love flashblock (Score:5, Interesting)

    by anss123 ( 985305 ) on Wednesday June 23, 2010 @08:55AM (#32664406)
    Will there be possible to have "CanvasBlock" on future browsers or are we stuck with CPU eating html5 animations?
    • by betterunixthanunix ( 980855 ) on Wednesday June 23, 2010 @09:00AM (#32664466)
      You most certainly can block it -- it resides nicely between two tags. The bigger question is, will asshole web developers use canvases in places where straight up text would have worked just fine, and force us to deal with their CPU eating abominations for no good reason at all?
      • Re: (Score:3, Insightful)

        I think I'll just put the canvas tags right besides the body tags and save myself a lot of work instead of dealing with this whole Aech Tee emm Ell thing.

      • Yes, but it's an open standard CPU eating abominations for no good reason at all, and that's all the difference in the world!

        (Sound of round being loaded into chamber)

        Are you with us or against us, comrade? Answer wisely.

      • by anss123 ( 985305 )

        You most certainly can block it -- it resides nicely between two tags.

        Will blocking the tag stop the underlying javascripts from running?

        • I dunno, but I'm sure somebody will be glad to add a feature into their browser that will strip all scripts, tags, and other unspecified annoyance delivery methods out of untrusted pages before it renders them.

          And I'll be quite glad to use that browser.

      • by gaspyy ( 514539 )

        Canvas is already abused. Some/Many sites use it for font rendering - see Cufon and similar projects. Cufon was born as an alternative to sIFR, the flash method of doing the same thing.
        Of course, the sane way of doing this is by embedding fonts, but that way has its own issues [richnetapps.com] (licensing, quality of fonts, etc.)

    • Well if you want examples of what can be done [youtube.com], I have demos of work I'm doing on add-ons to a game framework called Akihabara on Youtube. I've built clickable objects, menus, a scrollable console and am currently working on inventories and drag and drops items.

      So yes, you can do about anything that you used to do in Flash but you have a greater amount of control over it.
  • Comment removed based on user account deletion
  • Somebody has to actually use it first.

    Wasn't Youtube supposed to be switching to it months ago?
    • They had a test page for HTML5 stuff, but it would be pretty dumb to completely switch over to it before the specs are finished and all the main browsers have passable implementations of those specs.

    • Well developers are actually working in it right now. Considering the fact that there are no books on it published yet and browsers just started supporting it, it will start happening soon. For example, I have been working on adding functionality [youtube.com] to a game framework called Akihabara. The game isn't complete and will eventually be multiplayer but it requires reinventing alot of stuff within the limitations of the web and HTML5.
    • Re:It Won't (Score:4, Informative)

      by Rockoon ( 1252108 ) on Wednesday June 23, 2010 @09:57AM (#32665084)
      The answer is No, YouTube has not switched, and has no plans to switch, from Flash to HTML5.

      They can't because some browsers (most notably Firefox and Opera) will not support H.264, yet nearly all of their content is already in H.264. Thats game over right there for YouTube converting to HTML5. Maybe in 5 years or more, and only when all major browsers support a single codec.
      • Re:It Won't (Score:4, Informative)

        by drewness ( 85694 ) on Wednesday June 23, 2010 @10:17AM (#32665368) Homepage

        The answer is No, YouTube has not switched, and has no plans to switch, from Flash to HTML5.

        They can't because some browsers (most notably Firefox and Opera) will not support H.264, yet nearly all of their content is already in H.264. Thats game over right there for YouTube converting to HTML5. Maybe in 5 years or more, and only when all major browsers support a single codec.

        But Google is also offering (or is in the process of offering) all YouTube videos as WebM [webmproject.org], and the next versions of Firefox and Opera will have WebM support, and the dev channel of Chrome already has it. They really want to switch to HMTL5. I'm sure at this point they'd prefer IE and Safari to support WebM as well, but obviously they have the storage to keep every video as H.264 and WebM.

      • Re: (Score:3, Informative)

        by DarkXale ( 1771414 )
        Your information is out of date. Youtube is not going to use H.264 in the future, they're going to use WebM - which is Googles own format they've been pushing especially hard lately. http://www.youtube.com/html5 [youtube.com] Opera, Firefox, and Chrome all have WebM support, and Internet Explorer has ways to add in support too. The only major browser that is out of the loop at the moment is Safari.
  • by lkcl ( 517947 ) <lkcl@lkcl.net> on Wednesday June 23, 2010 @08:57AM (#32664430) Homepage

    ahh, the summary is wrong both from a W3C DOM standards perspective, because java is listed as the 2nd language supported by the W3C. the summary is wrong from a second perspective in that language bindings to HTML5-compliant web browser engines such as XulRunner and WebKit have been available for years. if Microsoft actually intend also to follow the HTML5 process properly, then it can be said that MSHTML, through its COM interface, also offers other language alternatives for decades rather than just years.

    now it's a sad fact that nobody really *knows* that you can get at HTML5-compliant web browser engines and use DOM functions (3000+) and access DOM properties (20,000+) through XPCOM, or Glib/Gobject or COM, but it's perfectly possible. the best demonstration of this at its most extreme limit, taking advantage of absolutely all HTML5 W3C DOM features, is the http://pyjs.org/ [pyjs.org] pyjamas project, which abstracts the differences between these three major web browser engine types (XulRunner, Webkit and MSHTML aka Trident) and presents a single uniform API. on top this uniform API, normalising the discrepancies between the three engine types, an entire Desktop GUI Widget Set API has been created.

    so the statement that there is "one HTML5 language: javascript" is just nonsense. for further examples of accessing HTML5 DOM using python, some of which will lead through to links to Ruby accessing HTML5 DOM such as AppCelerator, see http://wiki.python.org/moin/WebBrowserProgramming [python.org]

  • When will we get webcam streaming as flash offers?
    So far we have text, a codec and artwork.
    When will web 2.0 be interactive again?
  • In HTML5, the browser returns the latitude and longitude of the user to Javascript. Shouldn't the browser also return the planet, local star etc?

    How will ISS visitors browse?

    • by vlm ( 69642 )

      In HTML5, the browser returns the latitude and longitude of the user to Javascript. Shouldn't the browser also return the planet, local star etc?

      How will ISS visitors browse?

      They have a lattitude and longitude just like the rest of us. It just varies rather quickly, a degree of longitude every twenty seconds, or so.. On the other hand moon colonies "sub earth longitude" only varies about a degree every two hours.

      Do sailors, without adblock, get endless banner ads "hot girls in The Middle Of The Atlantic Ocean want to meet YOU!"

      • by vlm ( 69642 )

        On the other hand moon colonies "sub earth longitude" only varies about a degree every two hours.

        Err, if the earth didn't rotate, I mean. More like 15 degrees per hour plus or minus some rounding error for all non-earth orbit colonies. Pluto closest to 15 degrees/hr, moon furthest off.

  • An ambitious slogan. Things may become easier or faster, but this certainly won't change the web in the same way that say, the web changed how I read the news or how I shop for furniture.
  • by shikaisi ( 1816846 ) on Wednesday June 23, 2010 @09:03AM (#32664508)

    One language (JavaScript) to rule them all, one data model (XML and DOM) to find them, one set of layout rules (CSS) to bring text, audio, video, and graphics and in the darkness bind them.

    Why do I have a bad feeling about this?

    • Re: (Score:3, Funny)

      by Anomalyst ( 742352 )

      ... in the darkness bind them.
      Why do I have a bad feeling about this?

      Is it kosher to mix LoTR and Star Wars metaphors?

  • one data model (XML and DOM)

    Personally I'll be sticking to JSON

  • We must take the HTML5 specification and throw it into the Cracks of Doom. That is the only way to stop Ian Hickson from destroying the World of Men.
    • by Dracos ( 107777 )

      Agreed. HTML5 is full of crazy stuff, and few realize yet because video, canvas, and the other eye candy has been getting all the attention. Tag soup by default... I'd rather not go back to 1996. The return of some presentational tags (b, i, but not u) now with snazzy new presentational definitions (b really means bold, but we'll throw in big semantic-sounding words to appease the non-visual crowd).

      Good thing Hixie's l tag (for line of text, to kill all the natural text flow in block elements) never went

  • When a true random sampling of internet users shows 80%+ of those users using browsers with good HTML 5 support, then I'll start using HTML 5.

    Until then, as an internet developer for a small business, it's still HTML 4. We don't have the money to do both and we have to go where the users are.

    • Re: (Score:3, Insightful)

      by mcgrew ( 92797 ) *

      That's a wise choice I'm not sure others will follow. If possible, it's always best to use the oldest specs that are still supported that will actually do what you want the page to do.

      As to chickens and eggs, the egg came first, as any palientologist or biologist will tell you. Chickens aren't the only animals that lay eggs. It's ok if your egg lays dinasaurs, as long as the dinasaur is well trained.

  • I'd be happier if we hadn't had a moving target to work with for the past 15 years, with new W3C specifications becoming the vogue while major browsers still failed to implement older ones correctly. Also HTML5 is more "different" than "groundbreaking", which will just lead to more incompatibilities in browsers without a big benefit.
    How's the W3C reference implementation coming along by the way? :-P
  • HTML5 is just another level of bullshit to worry about when writing a web page that needs to render properly on multiple browsers.
  • Security? (Score:5, Insightful)

    by cgenman ( 325138 ) on Wednesday June 23, 2010 @10:02AM (#32665146) Homepage

    HTML5 will improve security

    While I love many things about HTML5, the idea of throwing out rendering libraries and starting again from scratch does not necessarily fill one with confidence about the security of the tools. Sure, less reliance on plug-ins means less opportunities for 3rd party security holes. But doing everything in the browser code itself also means that the potential attack vectors have more direct control over the machine. Plus any new library is going to have security vulnerabilities for a while.

    I'm not saying HTML5 is insecure. But let's not kid ourselves: there will be a year or two of scrambling to fix new attack vectors.

  • by Digana ( 1018720 ) on Wednesday June 23, 2010 @10:16AM (#32665344)
    ZOMBO [html5zombo.com]
  • And there is Microsoft only doing a subset of the spec, and users expecting to get the latest whiz bang stuff backported to IE6 and even worse IE6 mobile...

  • by vtcodger ( 957785 ) on Wednesday June 23, 2010 @10:24AM (#32665488)

    ***HTML5 will allow applications to tap local file storage***

    Once or twice a decade I encounter a "They can't possibly be serious" moment. This is one of those occasions.

  • First of all, its not one language when you count all the PHP, Java / JSP, ASP, Python, Perl, Tcl etc that runs on the server.

    Second of all, that one language should be Python FTW.

  • by Animats ( 122034 ) on Wednesday June 23, 2010 @12:39PM (#32667554) Homepage

    The current versions of all the major browsers can now dynamically download fonts. We can finally stop putting display text in images. Opera, Safari, Chrome, Firefox (3.6 or greater) and IE are all on board with this. By IE 9, they'll even be using the same font format, Web Open Font Format. (Except for the iPad, which, for some weird reason, currently requires fonts in SVG format. But even the iPad understands "@font-face")

    Few sites are using this capability yet. We are, as a demo. Try our steampunk search engine [sitetruth.com] with authentic Victorian fonts.

  • Nitpicks... (Score:3, Interesting)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Wednesday June 23, 2010 @01:38PM (#32668274) Journal

    Seems to be a minor thing simply wrong in every single point...

    Point #1 is flat wrong on this count:

    If drawing images is your goal, then the Canvas object may be powerful enough. But if you want to build specialized 3-D worlds like the ones found in the more sophisticated Flash and Shockwave games, you may be pining for the old days...

    Erm... Maybe WebGL isn't officially part of HTML5, but it's there, and Chrome is implementing it. And personally, I'd much rather force people to download a decent open source browser than a decent proprietary plug-in -- there's alway Chrome Frame if you really need it.

    Point #2:

    some developers deliberately disabled the Flash plug-in to avoid the headaches and overhead of rendering heavy Flash content. That won't be an option in the future.

    Bullshit. It'd take less than ten minutes to put this jQuery in a Chrome extension: $('canvas').remove();

    Point #3:

    Game programmers might store descriptions and artwork locally, saving the time of downloading the information again and again.

    That's what HTTP caches are for, and they work for XHR, too!

    Please, no one do this. Ever. HTML5 storage is for storing data. When you use it for caches, you add that much more stuff we might inadvertently back up, that much more cache we can't automatically purge (to claim disk space) or expire (from disuse), and you're doing more work to duplicate functionality HTTP already has.

    Point #4:

    The so-called microformats in HTML5

    I'm confused... microformats don't require HTML5, do they?

    Point #5 is fine, though it doesn't mention potential privacy concerns.

    Point #6:

    Google's new format will see some usage, for example in YouTube, but will never reach anywhere close to the ubiquity of H.264.

    Erm, do you know something we don't? Last I checked, YouTube is still H.264 -- in a Flash container, no less.

    Point #7, I don't care about.

    Point #8:

    This claim of better security, though, is a bit of a wild guess. The devious minds may use their malice aforethought to take advantage of the nice integration, perhaps drawing PayPal logos with the Canvas object...

    So phishing will be easier? Big deal. Hasn't Flash been the biggest vector for actual client-side pwnage for awhile?

    Point #9:

    Now, if only HTML5 came with the nice collection of tools that Adobe makes for Flash.

    Adobe has said they plan to target HTML5.

Avoid strange women and temporary variables.

Working...