Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming

In-Depth Look At HTML5 150

Posted by CmdrTaco from the digging-in-for-the-long-haul dept.
snydeq writes "InfoWorld's Peter Wayner offers a four-part series devoted to the new features of HTML5. Each article examines the evolving spec in-depth, focusing on canvas, video, audio, and graphics for display options, including the <canvas> and <video> tags, Scalable Vector Graphics, and WebGL; local data storage, including Web Storage, Web Database, and other APIs designed to transform Web pages into local applications; data communications, for cross-document messaging, WebSockets, and other HTML5 APIs that improve website and browser interactivity; and forms, for increasing control over data input and validation."
This discussion has been archived. No new comments can be posted.

In-Depth Look At HTML5 More

In-Depth Look At HTML5

Comments Filter:
  • Browser makers finally need to decide on one codec or it will just lead to the situation we had in 90's with tons of codecs (or everyone will keep using Flash). Google and OSS people have to stop being like a little kid and accept that H.264 is already everywhere from mobile devices to GPU's and HDTV's and HTML5 will not get anywhere if it isn't used. It's too late. There will come another round after H.264 gets old - make sure open source and free codec is ready by then. Now lets just enjoy that we even ha

    • Re:The truth is (Score:5, Informative)

      by Microlith ( 54737 ) on Wednesday March 09, 2011 @12:28PM (#35432250)

      Google and OSS people have to stop being like a little kid and accept that H.264 is already everywhere from mobile devices to GPU's and HDTV's and HTML5 will not get anywhere if it isn't used.

      They can accept it all day long and want to distribute software that will encode and decode h.264, but where do you expect for them to get the money for the per-copy royalties from? Of course, being unwilling to push software that is inherently un-free is acting like a little kid.

      • Well, pushing software that has no hardware support and provides no clear advantage to the end-user over H.264 is.. something. Pushing it only because it'll allow your corporation to dictate by fiat the possible business models for web video, that's something too. OTOH, acting like something that is "inherently unfree" is worse, regardless of useful it is, is pretty childish.

        • Pushing it only because it'll allow your corporation to dictate by fiat the possible business models for web video, that's something too.

          Like h.264, who have a whole schedule of royalties based upon your business model? The only one that gets a free pass, mind you, is free-streaming video.

          OTOH, acting like something that is "inherently unfree" is worse, regardless of useful it is, is pretty childish.

          So pursuing alternatives to royalty-encumbered standards is childish. Got it. Time to start paying for those

          • Like h.264, who have a whole schedule of royalties based upon your business model?

            A consortium of 20 companies is far preferable to a single BDFL who effectively decides what will run on the web and what won't. A schedule of royalties is far preferable to the alternative, which is "I want to sell a better codec, but it's impossible because Google gives away mediocre ones."

            • A consortium of 20 companies is far preferable to a single BDFL who effectively decides what will run on the web and what won't.

              Even when the "BDFL" basically puts it into the open and goes hands-off? They're just putting a video codec out into the open, not deciding what will and will not run on the web (in contrast to Adobe and Microsoft, who are and have tried, respectively.)

              "I want to sell a better codec, but it's impossible because Google gives away mediocre ones."

              I see this sort of sentiment leveled a

              • I see this sort of sentiment leveled against open source software all the time, what makes it more true now than before?

                No other open source vendors have a monopoly. Web video is Youtube and a minuscule fraction is everything else. Vendors only care about supporting YouTube. If Google is able to dictate the hardware codec your equipment is built with, by setting the codec of YouTube, then they can effectively force everyone else to use their format. People might invent better codecs than YouTube's, but

                • pretty much everything you've said here is bullshit, why would any hardware/software player manufacturer go "oh, i support youtube, guess i'm done, people won't want to watch ripped dvds or their existing content etc etc etc".

                  • Ah this is where you're wrong. It's all about controlling the streaming from large providers to set-top boxes, Netflix, YouTube, and Hulu to AppleTVs, Rokus, and the (basically moribund, due to Google's incompetence) GoogleTV platform. The companies in the MPEG-LA and Google both see that streaming distribution will be the future, and that no one will rip movies in the future, because it won't be sold. Physical media's days are numbered. I will be extremely happy if hardware supports both formats, and mo

                    • how is a set top box not a media player? just because the front end is probably running a html 5 browser doesn't mean they can't do whatever the hell they want with the codec behind the scenes, in fact they'll probably encode and stream it in whatever codec they feel gives them the most quality for their bandwidth, if the MPEG-LA want to stay competitive they'll have to . the idea that no-one will rip movies is just plain stupid and is a completely separate issue to whether physical media will become irre

                    • No one is arguing for MPEG eliminationism and if they are, they're idiots. The argument is that HTML5 should list WebM as a base codec that everyone must support. The reasoning is that as long as you provide a WebM version, you're guaranteed that all users can view it. If you want to have an H.264 version or whatever other codec that's fine, but the standard should specify that everyone at least supports WebM.

                      The reason for not using H.264 as the common codec that everyone should support is due to the W3C's

                • So you don't think Google is interested in the real money it could save by creating better codecs, allowing them to reduce bitrate for current quality, and saving them a tremendous amount of bandwidth?

                  Also, I take issue with this: "people might invent better codecs...bring them to market." Do you bring equations to market? No, of course not. You bring products to market. Charging for encoding/decoding is a doomed business model and it deserves to be for a lot of reasons, not the least of which is the a

                  • I think Google is interested in providing the bare minimum quality required to keep the hits to youtube where they are. That is the extent of their commitment. Making 250,000 people with cellphones happy is far more important to them than making one filmmaker happy.

                    Also, I take issue with this: "people might invent better codecs...bring them to market." Do you bring equations to market? No, of course not. You bring products to market.

                    Software is a product. That's just where I come from on this one.

                    Chargi

                    • You're assuming that algorithms are a product, which I am not convinced of. Video encoding is one of a class of problems which is not yet solved; i.e. we're constantly improving at it. Having a large target use an open-source tool attracts more development, not less; or, put another way, business dollars are not the only source of development funding.

                      Do you really think that a site driven by a qualitatively better codec couldn't threaten YouTube, especially if its lower bandwidth requirements lowered its

                    • Just for fun, submit a patch to Mozilla that changes the factory default search of Firefox to Bing, and see how "immune to this kind of treatment" Open Source Software really is.

                      Why do I have to submit a patch to Mozilla? I can just fork the code, create my own version with the search set to Bing by default and distribute it myself. Done. Try having a version of IE where the factory default search is Google instead of Bing.

                    • Do you really think that a site driven by a qualitatively better codec couldn't threaten YouTube,

                      Yes.

                      You are falling for the classic geek error of assuming that if you build a better mousetrap, the world will beat a path to your door. No, it won't. People still buy crappy, inelegant, not very effective mousetraps because they are cheap, and everyone knows what they do. .

                    • It wouldn't have the first thing to do with people beating a path to your door, and lots to do with "what YouTube does, I can do for cheaper (less ads, more content) -- and better is just a side effect." You are falling for the classic error of having this idea that just because something is popular it is inviolate. Look at MySpace. That was a pretty thorough monoculture, and yet one quarter it just deflated. Facebook. Altavista. Geocities. Gawker. Are you really claiming eternally enduring web site

              • Even when the "BDFL" basically puts it into the open and goes hands-off?

                Is there some sort of covenant and indemnification to that effect? Is there a Community Process? Is there a way for people to work within the process and still compete on quality and have a practical way of delivering a better experience outside of it?

                I mean, like Android, this is really the most bullshit kind of open sourcing. None of the benefits accrue to the end users, because almost none of the end users know how to code. All o

                • I mean, like Android, this is really the most bullshit kind of open sourcing.

                  That is a complete bullshit statement and a complete lie. Propaganda much?

                  Android does accept input and patches. Not only have bugs I've filed been fixed, at least one of my recommended patches are now running in Android; which was first adopted by third party roms. As are hundreds of other patches and improvements. And no, I do not work for Google or a carrier.

                  Android absolutely is open source in the most literal sense. Anyone who says otherwise is ignorant or an idiot with an agenda.

                  With your idiotic logi

                  • Nothing you say here contradicts what I said.

                    • Where? Demonstrate:

                      Android does accept input and patches. Not only have bugs I've filed been fixed, at least one of my recommended patches are now running in Android; which was first adopted by third party roms.

                      Never said they didn't. They love it when people do their work for them for free!

                      Android absolutely is open source in the most literal sense.

                      It most certainly is, I never said it isn't. It's a bullshit kind of opensourcing, but that's just a qualification.

                      Anyone who says otherwise is ignorant or

                    • Marginal cost != cost of production, and even if it were, that would be for an intellectual resource with no physical manifestation, that is never updated, and never serviced. Are you seriously claiming that Google spends zero dollars on the development, maintenance and support of Android?

                    • If you release your product for free you don't have to provide a good product, because anyone who wants to actually make money from people who would pay for it will never be able to enter the market. Once Google's "free" product is entrenched, it becomes impossible to make money selling or improving a competing OS, and competitors wither away, unless they bind their hardware to their OS and use sales of one to subsidize the other, like HP and Apple. Consumers no longer have a choice of OS, because there's really only one game in town for their phone, and entrepreneurs who want to create a new OS face the proposition of having it lose millions of dollars a year before breaking even, and significant barriers to entry among the hardware vendors -- they've invested so much in Android, Google gives them a good cut of the side revenues, lets them put their crapware and efused bioses on them, etc.

                      Except the actual market forces prove you wrong. The cost of an Android phone vs an iPhone vs a Windows Phone vs Symbian phone are all around the same. The customers aren't seeing a drop in price for a phone because the OS is free, so your argument fails because Android has outsold Windows Mobile, Symbian, and RIM due to people actually wanting them because they like them better. Whether it's the OS, the hardware specs or whatever, it's definitely not the price.

                      As for the barriers to entry among hardware ve

                    • Just a little quibble here:

                      People do not buy Android phones. They are given away "for free" with the contract. The only phones people are really buying is the iPhone.

                    • People do not buy Android phones. They are given away "for free" with the contract. The only phones people are really buying is the iPhone.

                      Perhaps I should ask Verizon for my money back when I purchased the original Droid early last year. Or what bout the cost of the HTC Evo? Or the other tons of Android phones which are at various price points which range from some "free" with contract to being at the same price point as the various iPhone models. Sorry, but claiming that "The only phones people are really buying is the iPhone" is just flat out bullshit.

        • Re:The truth is (Score:4, Insightful)

          by Lennie ( 16154 ) on Wednesday March 09, 2011 @01:17PM (#35432950)
          How do you think H.264 started out ? With zero hardware support, this is where VP8 was a few months ago. Now they have a few hardware manufacturers that ship VP8 built in. Any many said they would do the same. The whole H.264 / VP8 debate is also about looking at the future not just now.

          • How do you think H.264 started out ? With zero hardware support, this is where VP8 was a few months ago. Now they have a few hardware manufacturers

            H.264 is supported by every digital HDTV system on the planet. It is studio production codec, a broadcast, cable and satellite distribution codec.

            It is deeply entrenched in CCTV, commercial, industrial, medical, military and security applications.

            Yes, VP8 has the support of a few hardware manufacturers.

            But H.264 is suppported by Apple, Fitjusitu, Hitachi, JVC, Microsoft, NTT, Mitsubishi, Panasonic, Philips, Samsung, Sony, Toshiba and Yamaha.

            In the second tier, by the 953 H.264 licensees like LG and Vi

        • Re: (Score:2)

          by jrumney ( 197329 )

          Well, pushing software that has no hardware support

          This argument has no basis in fact. VP8 has started to appear in the lists of hardware accelerated codecs from most ARM SoC manufacturers already. Some even have firmware upgrades to enable it in chips they have already shipped.

      • Re:The truth is (Score:4, Informative)

        by PhunkySchtuff ( 208108 ) <kai&automatica,com,au> on Wednesday March 09, 2011 @01:17PM (#35432948) Homepage

        H.264 is royalty free for Internet video that is free to end users (Internet Broadcast AVC) until at least December 31, 2016.
        You need to pay a small licensing fee to use an encoder which Google would have to do with all the videos they encode on YouTube, but as far as including the codec in the browser, it's completely free of charge for at least another 5 years - by which time we will have probably moved on to something better.

        Now is not the time to be pushing a private agenda, now is the time to get on board with established industry standards and get something more open into the next round.

        http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf [mpegla.com]

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          Would you buy a book written in disappearing ink?
          "It's fine, you can read it right now, no problem!" ?

          • Re: (Score:3)

            by devxo ( 1963088 )
            Not everything lasts forever. In fact, only few things do. You ate food yesterday and that ain't coming back. Nor is your ex-girlfriend. Sometimes you just have to move on and do other things.

            • Your universe is only free for 10^1000 years. After that you're going to have to pay royalties.

            • it's a poor deal if you the alternative is food you can buy once and eat whenever you want until you get sick of it and delete it.
          • Actually yeah I would, especially if it was just a novel. It would actually make the book far more useful as then once I have read it I would have at least a usable notepad as apposed to the 3 rooms of my house with wall to wall bookcases that realistically never get touched once I have read everything on it.

        • Re: (Score:2)

          by Draek ( 916851 )

          it's completely free of charge for at least another 5 years - by which time we will have probably moved on to something better.

          We won't, and the whole point of standards is that we shouldn't have to.

          This is not the time for you technophiles to go spreading your political agenda at the cost of everyone else, this is the time for us to unite and get it right the first time around with a proper, Free standard for the web, just as all its predecessors have been.

      • On the other hand, Google has absolutely no problem pushing Adobe Flash. So obviously Google is quite flexible when it comes to these things.

    • Re:The truth is (Score:4, Informative)

      by pipatron ( 966506 ) <pipatron@gmail.com> on Wednesday March 09, 2011 @12:42PM (#35432432) Homepage
      How do you figure they could license the patents? It's most probably legally impossible unless they write new browsers from scratch and then pay from their own pockets for everyone downloading their software. The ball isn't in the hand of the OSS people here.

    • Re:The truth is (Score:4, Insightful)

      by Rysc ( 136391 ) * <sorpigal@gmail.com> on Wednesday March 09, 2011 @12:57PM (#35432662) Homepage Journal

      . Google and OSS people have to stop being like a little kid and accept that H.264 is already everywhere from mobile devices to GPU's and HDTV's and HTML5 will not get anywhere if it isn't used

      No. H.264 doomsayers like you have to stop being like a little kid and accept that a royalty-encumbered codec will never be accepted as the "one codec." No, seriously, *NEVER*. If you insist on one codec then you can forget about H.264; put it out of your mind, it doesn't exist.

      OSS people are not being pedantic or skinflints, it's just practical reality. It's "but H.264 has won!" people who need to wake up and smell some reality: H.264 is not nearly as permanently entrenched as you think it is. I'll take HTML5 with a mandated royalty-free codec over your "entrenched" de-facto standard any day of the week and twice on Sundays: in such a fight HTML5 will win nine times out of ten.

      • I'm right between your argument and the GP's. I'm annoyed at Google for indicating they're going to drop support for h.264 (they can afford whatever future royalties will come), and I'm annoyed at Apple for saying they're not going to support WebM (they've got the resources to drop a few lines of code into their products to support it). I mean, all modern browsers support JPG, GIF and PNG; why can't we support even two major standards without everyone getting in a snit?

        • Re: (Score:2)

          by Draek ( 916851 )

          In the case of Apple it's politics: they really don't like competition, and the h.264 licenses ensure the barrier of entry is high enough they don't have to worry about some puny little dev team disrupting their marketplace with some shiny new browser.

          In the case of Google however, it's *also* about politics, but a slightly different take: they really don't like monopolies and oligopolies, since they tend to make dirtying and eliminating Google their first priority (see also: Bing, iPhone), and putting a Fr

    • Since you mention codecs, Google just released a version of VP8 for the WebM project [webmproject.org]. The improvements are noteworthy.

    • Re: (Score:2)

      by Lennie ( 16154 )
      Firefox and Chromium (non-Google-branded open source base of Chrome) are open source browsers, the H.264 license model does not fit well with the open source development model. For example when a Linux distribution compiles Firefox or Chromium, they would need to get their own license for all the users of that distribution. The license cost up to 5000000 annually. In the past only Chrome included H.264 and not Chromium, Google didn't want to seperately maintain that part of the code, thus they dropped su

    • Why is this an issue for you?

      You can host your videos in H264 and WebM and deliver whichever is supported to each client. Or, if you don't like that, you can just support one and ask your customers to install a plug-in. After all, there will be free H264 plug-ins for the browsers that don't ship with H264 support (actually, I think there already are). The only exception, of course, is iOS where users will not be allowed to use WebM, so I guess you'll go for H264.

      On the other hand, when a browser like IE9

      • The only exception, of course, is iOS where users will not be allowed to use WebM, so I guess you'll go for H264.

        The problem with that is the market has changed and will continue to move away from Apple as a significant market segment. It used to be Apple and RIM where the only mobile platforms with clout. Now Android is pushing RIM out and eclipsing Apple in the numbers game. Which means, in the next couple of years to decade or so, if Apple doesn't support WebM, their owners will likely have an inferior experience which in turn likely means reduced sales which in turn quickly spirals into Apple supporting WebM or it

    • Re: (Score:2)

      by mldi ( 1598123 )
      Why do they have to decide on one or the other? What's wrong with supporting both? If someone wants to pay commercial licensing for encoding h264, they can. If they have a tighter budget and need something free and open but still supported, they can.

      Everybody wins?

      • Re: (Score:2)

        by Draek ( 916851 )

        Because all it takes is for a single significant player to decide not to support one of the codecs in order for the other to gain dominance over the whole market. And since Apple went crying and bitching to the W3C that they weren't ever gonna implement a Free codec because they didn't wanna, we need a counterpoint for the WebM/Theora side in order to have a meaningful debate instead of the zealots going all "iOS doesn't support it, therefore it's dead". Not that it has stopped them, but at least Firefox an

    • So, exactly what kind of business model should Mozilla adopt to pay for h.264's licensing fees?

  • Why isn't there a "Caption" tag? (I mean for images, not for tables).

    So if you had something like this:

    <img caption="yadda yadda yadda" src='"blah blah blah">

    Then the caption would be underneath the photo, with the photo and the caption treated as one block (i.e., with the body text wrapped around it the same way it is wrapped around the photo.)

    I'm sure there's a good reason -- can someone enlighten me?

        - aj

    • The reason is that HTML doesn't have support for photographs. It has support for images. If you want to caption a photo it is trivial to do. Meanwhile, images have ALT text which does what you want except that presentation is left up to the browser.

    • <pedantic> Also, the way you've described it, the caption wouldn't be a tag; it would be an attribute of the image tag:
      caption as an attribute:
      <img caption="yadda yadda yadda" src="blah blah blah">

      caption as a tag:
      <img src="blah blah blah"> <caption text="yadda yadda yadda">

      </pedantic>

    • Probably because there would need to be additional coding to support a caption attribute. Browsers would need to determine the correct size and placement for the caption because it could throw off the image size. And it could be a headache for developers who want precision in their layouts. Would <img src="photo.jpg" caption="This is my caption" width="200" height="200"> still display an image that's 200x200px, or would it need to stretch/skew the image for the caption to be shown? Would the page's de

    • Almost all browsers except IE already support ANY [xmlsucks.com] tag. Just stick it between < and >, then style it in css.

      So you can already have a <photo>photo tag</photo>, a <crap>crap tag</crap>a <slashvertisement>slashvertisement tag</slashvertisement> etc.

      • Re: (Score:2)

        by toriver ( 11308 )

        ... but for XHTML you would need to namespace it since it would be outside the HTML (default) namespace.

        But I guess XHTML is dead now.

        • ... but for XHTML you would need to namespace it since it would be outside the HTML (default) namespace.

          But I guess XHTML is dead now.

          First off, it's not XHTML. It's just using the existing tags syntax, but with arbitrary tag names, and styling via css and manipulation via javascript.

          Second, yes, happily XHTML has been dead for almost 2 years, according to the W3C - and they would know - they're the ones who killed it [w3.org].

          2009-07-02: XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5. Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009,

    • Re: (Score:2)

      by Korin43 ( 881732 )

      Why isn't there a "Caption" tag? (I mean for images, not for tables).

      So if you had something like this:

      <img caption="yadda yadda yadda" src='"blah blah blah">

      Then the caption would be underneath the photo, with the photo and the caption treated as one block (i.e., with the body text wrapped around it the same way it is wrapped around the photo.)

      My guess is that it's not there because it would make the standard more complicated, and it doesn't add anything you can't do now (<div><img src='"blah blah blah">yadda yadda yadda</div>). Besides that, making it an attribute wouldn't make very much sense, because you'd probably want to be able to apply HTML to the caption. Making it the content of the img tag might make sense though (<img ...>yadda <i>yadda</i> yadda</img>), but that would make the distinction betw

    • hypertext doesn't belong in attributes.

  • I used to laugh at "web programmers" (Score:3, Interesting)

    by erroneus ( 253617 ) on Wednesday March 09, 2011 @12:53PM (#35432602) Homepage

    I recall when the web was young people would claim "I program in HTML!" I was like "yeah, I can insert 'bold' and 'a' tags too..." In the beginning, HTML was nothing more than what the name says it is -- a markup language. (Of course "language" somehow means programming? No it doesn't...)

    Well, now things are different, of course. Web programming today is real programming for some... still markup for others. But now the web is becoming more than a presentation medium which is very exciting I think.

    • I'm still not in love with client technologies but I knew they were powerful when I first dug into "DHTML" and created an animation using nothing but html and js. Essentially it's still the same recipe, with server-side powering the whole thing. Good times.

      But yeah, agreed. I used to scoff at the title myself but these days I'm in awe at the power of "UI programmers" who well versed in both client side and design elements. They code JS, they do graphics, they know design, they write server-side web APIs, an

      • Re: (Score:3, Funny)

        by H0p313ss ( 811249 )

        It's downright impressive.

        Until you start using it and discover it's all smoke, mirrors, duct-tape and baling wire.

      • Re:I used to laugh at "web programmers" (Score:5, Interesting)

        by Lennie ( 16154 ) on Wednesday March 09, 2011 @02:04PM (#35433560)

        I don't know how it is in the US, a lot of the time this is all self-taught. Because pretty much no-one seems to teach HTML/CSS/JS/etc. properly in school/university and so on.

        Javascript is one of the most used programming languages and because it looks simple or familair most people assume it is, but in reallity it is the probably the least understood language by frequent developers. Most have no clue what prototypal inheritance is for example.

        Also the Javascript name is just a marketing ploy because it has nothing to do with Java.

        The core of the language is very small and was created and working in just 10 days.

        It is a functional programming language with a C-syntax.

        With the recent creating of node.js (a fully event-driven framework for writing network programs) Javascript has also become much more populair on the server.

        Node.js was created in 2009 and is already almost the most watched project on github.com for example.

        There introduction video where the creator/author explains what it is about:

        http://developer.yahoo.com/yui/theater/video.php?v=dahl-node [yahoo.com]

        So it is just an event-loop just like a webserver like nginx.

        One of the design goals is actually:

        The API should be both familiar to client-side JS programmers and old school UNIX hackers.

        I guess that applies to me twice. :-)

      • Re: (Score:3, Interesting)

        by roadsider ( 970039 )

        As a web designer who started as a print designer before the web was invented and even before the advent of desktop publishing, this whole meshing of coding and designing represents a kind of repudiation of the concept of WYSIWYG.

        I took to the web design relatively easily, but only because HTML looked very similar to the same code used by the old digital phototypesetting machines made by Compugraphic, but early on, we all seemed to hope for that "killer app" that would finally get us away from the code. To

        • And good riddance. "WYSIWYG" programs invariably generate a spaghetti-like mess of a page that could had no semantic logic, and could only be practically modified by using the program in question.

          You don't design in code. You design with Photoshop (at least for the final version) and then hand it over to people who understand code to implement.

          • And good riddance. "WYSIWYG" programs invariably generate a spaghetti-like mess of a page that could had no semantic logic, and could only be practically modified by using the program in question.

            You don't design in code. You design with Photoshop (at least for the final version) and then hand it over to people who understand code to implement.

            Sure, but what about that vast majority of web pages out there which are not developed by a whole team of specialized professionals? I know a few people who do some pretty good web design, and none of them sketch it up and hand it to a dev team. Unless your web page is really a complex application that happens to run in the browser, one web designer is quite enough to produce a professional-quality webpage,

  • There's been a lot of talk about HTML5 transforming today's browsers into tomorrow's platforms as this simple search suggests [google.com]. Essentially, with all of these additions, there seems to be a keen interest in providing "local application" experiences to web-based tools. For example, many of these additions essentially provide access to hardware devices in one form or another.

    This is all nice in theory, but once we start including the 'kitchensink' tag, who's to say that browsers won't end up as bloated as

    • And with as many security vulns. I really hope site sandboxing featuers become easier to use too. Currently I use a separate browser profile for unsavory companies like Facebook but as all these apps bleed together it would be nice to have a clean, easy to use separation feature.

    • Re:Cool, but... (Score:5, Insightful)

      by skids ( 119237 ) on Wednesday March 09, 2011 @01:09PM (#35432830) Homepage

      Well, despite the fact that XML and HTML are abysmal markup languages, they are a heck of a lot better and more consistent than the off-the-cuff designed-by-horses carnivals you find in PDF and other markup languages that started as internal document formats for proprietary word processors. Consistent design leads to more well organized, less complex code.

      In addition, since HTML5 is coming with declarative animation features embedded, and on the heels of active use of the DOM, it has to be designed with performance in mind -- so there's a counterweight for the tendency for bloat to accrue.

      That said, with HTML looking to become a "living standard" after HTML5 or in other words, complete anarchy, there will be space for a streamlined markup language to make gains again in another half decade or so -- if someone can finally produce something that doesn't suck for human readability and for complex relationships that transcend tree structures. Perhaps we will have the first popular non-textual markup language by decades end.

      • Re: (Score:2)

        by Nadaka ( 224565 )

        Well, I am fed up with xml and html specifically. I had my hopes set on xhtml2. I had even started working on tools for it. That got screwed over by the mess that is html5. I would love to create something even leaner and cleaner than xhtml2. But html is now a titan, I don't see room for anything to gain significant use.

        What do you mean by non-textual? a markup language that can only be assembled in an WYSIWYG IDE?

        • Re: (Score:2)

          by skids ( 119237 )

          Well, there's always YAML to extend....

          What do you mean by non-textual? a markup language that can only be assembled in an WYSIWYG IDE?

          Personally I've always thought graphical languages should be more like a free-form spreadsheet than those glorified text editors we call IDEs. No I do not mean WYSIWYG, except maybe where it makes a lot of sense to do so on small fragments, because the idea of a language, as opposed to an editor, is that you are looking at the underlying representation, not the final produc

        • >That got screwed over by the mess that is html5.
          It got screwed over by sitting in committee and going nowhere (and the bit that did happen did not please the potential implementers), until finally the browser makers said "fuck it, we'll do it ourselves"

    • Re: (Score:2)

      by Lennie ( 16154 )
      There is already a kitchensink in the specification. Although at this point it is only an image: http://images.whatwg.org/abstract.png [whatwg.org] http://www.whatwg.org/specs/web-apps/current-work/complete/ [whatwg.org] Anyway support for the device-tag is planned for the next big update. The device-tag allows access to the webcam (like Flash currently does), serial ports (so you can use your barcode reader with your webapplication), but also supposedly USB-stick-fileaccess (maybe useful for something like ChromeOS ?) and so on.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close