Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Introduces HTML 5.1 Tag To Chrome

Posted by timothy on from the tagging-wars-ensue dept.

darthcamaro (735685) writes "Forget about HTML5, that's already passe — Google is already moving on to HTML5.1 support for the upcoming Chrome 38 release. Currently only a beta, one of the biggest things that web developers will notice is the use of the new "picture" tag which is a container for multiple image sizes/formats. Bottom line is it's a new way to think about the "IMG" tag that has existed since the first HTML spec."

63 of 94 comments (clear)

  1. 5.1? by Anonymous Coward · · Score: 1

    I thought that with the introduction of HTML5, they were going to stop numbered standards... all revisions to the spec would fall (confusingly) under the HTML5 moniker. I'm happy if that turned out to be untrue.

    1. Re:5.1? by Anonymous Coward · · Score: 2, Informative

      HTML 5 isn't even a standard, yet, for all that everyone is yapping about it. It's still a draft.

    2. Re:5.1? by Lennie · · Score: 5, Informative

      It's a bit more complicated.

      The big standards organisation is W3C. They only call it a standard after everyone agrees on what the standard is and there are implementations in the field that prove that the model works. In that sense they are a bit like the IETF. Part of the IETF motto (TAO): "We believe in rough consensus and running code".

      So in the case of HTML5, all browsers will implement the parts of the HTML5 they want to first and only when there are multiple implementations of a feature/part of the HTML5 standard, everyone agrees on what that part of the standard should look like and the documents are ready will W3C rubber stamps it a standard.

      So you can already use it before it is a standard. Most parts, by now probably pretty much all of it, of the specification is stable. They are just changing documents to improve working and adding clarifications.

      Using the implementations is actually encouraged, because the vendors want to see how it is being used to know if the specification actually works in the way it was intended. Or if it is just to complicated to work with.

      Then you have the WHATWG, which is a number of browser vendors (Mozilla, Opera, Microsoft, Webkit/Blink) sitting together creating new HTML5 ideas and standards documents. Those standards documents can eventually be used as a basis by the W3C.

      The WHATWG was formed when the W3C, a long time ago, said: all HTML will be XML based in the future. And basically said: HTML is a document format. The WHATWG said: no, way. Let's start a new group of people, because we don't want to deal with strict XML and we actually make it possible to let the web be an application delivery platform.

      So really HTML5 pretty much is done. All the browser implementations are done, except for support of certain parts or features.

      HTML 5.1 is just a working document title. It is just a set of new features being added to HTML 5 which will end up as part of HTML5.

      Fun fact about the picture element is: it did not come out of the WHATWG or W3C or browser vendors, it came out of a community of webdevelopers to create 'responsive images'. A problem that didn't have a good solution yet.

      Responsive images is about downloading a the right size of image based on the device it will be displayed on.

      --
      New things are always on the horizon
    3. Re:5.1? by MatthiasF · · Score: 5, Insightful

      Microsoft is not a part of WHATWG. They have cooperated with it's members, but are not adhering to the standard. And for good reason it seems, since they avoided the CANVAS specs worried that items in it were not royalty-free and sure enough Apple patented it and numerous other issues.

      WHATWG is just as incompetent as W3C. The only way to reach a reasonable standard is for dialog and not bullying. Google has done nothing but bully over the last five years, making WHATWG more dangerous than helpful. Chrome itself has numerous behaviors that are counter-productive specifically to differentiate itself and cause a divide instead of a method of progress.

      I firmly believe that those who are deciding these standards should be working as independant contractors, following an ethos and not being paid directly by any one player. Otherwise, there seems to be a lot of bias going on because so many rely on Google (from advertisements or direct payments), and we should not be trusting Google if we want an Internet without massive invasions of privacy.

  2. nail in W3C coffin by globaljustin · · Score: 1, Interesting

    can we give the WHATWG the credit they deserve now?

    the W3C (including "inventor of the internet" Behrners-Lee) intentionally retarded the development of new HTML & CSS standards in order to push for 'baked-in' DRM/tracking capability...

    they couldn't get the changes into a version of HTML, so they sat on their thumbs and used process to keep HTML from progressing...repeat: W3C tried to keep new development of HTML from happening

    enter WHATWG

    we only have HTML5 & CSS3 because of WHATWG...look at the W3C...they **still** are on some 3.2.1.4 version of HTML

    let's get HTML5.1 across all platforms and make it the permanent development channel...it practically is so already, but I want to see people integrate this important truth of the **development of the whole internet** into their (your!) schema for tech

    --
    Thank you Dave Raggett
    1. Re: nail in W3C coffin by Anonymous Coward · · Score: 1

      Repeating as a rhetorical tool is quite common. It is repeated to stress the gravity of the statement, and in some cases to make sure the listener/reader pays careful attention to word usage. For those that hear a human speaking voice in their head when they read (most people), it still makes total sense. Get off your high horse.
      Criticizing people online for your own hypocritial failings: "It just wastes space and looks a little self important."

    2. Re:nail in W3C coffin by Carewolf · · Score: 3, Informative

      Not to spoil your rant, but the picture tag is defined here: http://www.w3.org/html/wg/draf...

      Notice the hostname.

    3. Re: nail in W3C coffin by I'm+New+Around+Here · · Score: 2

      Many /.ers don't know what the word "rhetorical" means.

      They only have heard it in the phrase, "It was a rhetorical question." So they think its definition is "something you don't agree with".

      --
      If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
    4. Re:nail in W3C coffin by Lennie · · Score: 3, Informative

      Most of the HTML5 specifications gets developed here first:

      http://www.whatwg.org/specs/we...

      Then eventually after a long process will end up here:

      http://www.w3.org/TR/html5/

      However Picture-tag actually came from the community first, not the W3C or the vendors directly:
      http://responsiveimages.org/ only later did it become http://www.w3.org/community/re... and later became part of the HTML5-specification.

      --
      New things are always on the horizon
    5. Re:nail in W3C coffin by Carewolf · · Score: 1

      Most of the HTML5 specifications gets developed here first:

      http://www.whatwg.org/specs/we...

      Then eventually after a long process will end up here:

      http://www.w3.org/TR/html5/

      However Picture-tag actually came from the community first, not the W3C or the vendors directly:
      http://responsiveimages.org/ only later did it become http://www.w3.org/community/re... and later became part of the HTML5-specification.

      Ehmm. W3C is the community, WhatWG is the vendors. The whole point of WhatWG was to coordinated between browser vendors.

  3. srcset attribute by Rosyna · · Score: 2

    I thought we already had this with the img tag's srcset attribute. Do we really need a new tag?

    1. Re:srcset attribute by Pieroxy · · Score: 4, Informative

      This allow to change the img source according to media queries, which is not possible using CSS and/or the img tag.

      --
      Write boring code, not shiny code!
    2. Re:srcset attribute by QuasiSteve · · Score: 1

      This allow to change the img source according to media queries, which is not possible using CSS

      Could you explain this in more detail?

      I thought it was perfectly possible to have an @screen CSS with one image source, and an @handheld CSS with another image source?

      ( Not to mention the 'device-pixel-ratio' tricks. )

      In addition, while sub-optimal, servers themselves can already send different media based on the request headers; isn't that how the whole 'mobile vs desktop mode' in smartphone browsers works (or rather, is supposed to work) anyway?

    3. Re:srcset attribute by Pieroxy · · Score: 1

      You cannot change the source of an image in CSS. SRC is an html attribute that cannot be overriden. What you can do in CSS is change a background image, but not the primary image. While they render approximately the same, there are a few differences that make background images unsuitable for some purposes, SEO being one of them.

      As for serving different content for different user agents, good luck maintaining your database of screen size and densities per UA string, not mentionning that Apple does server the same UA whatever the model of iPhone you have (which can include different sizes and densities).

      --
      Write boring code, not shiny code!
  4. Browser wars are back by Anonymous Coward · · Score: 3, Insightful

    So it's in the guise of "standardisation", except in name only. There is no standard is the new standard.

    And it does mean you need to keep on updating your web browser or you get shut out of steadily ever more websites that used to work just fine with the exact same browser last week. It is in fact fashionable to look at user agents and not merely complain, no, simply present a "we don't like your browser, fuck you" page without so much as contact information to the website owners or anything.

    This includes websites that present little more than text with illustrations. That's right, among the websites that are harshly shutting out browsers for not having quite enough of this new html5 sauce are those that could've done perfectly well with just the features html3 provides. If this is called progress, you can keep it.

    1. Re:Browser wars are back by Anonymous Coward · · Score: 1

      The browser wars have been back since Firefox 0.whatever.
      This isn't anything new.
      Even Microsoft are taking part in it now. It is great.

      These things will be in beta for a while yet.
      Well, this might not be. PICTURE is a fairly simple thing that will get pushed through pretty quickly. It is just IMG on steroids and the brain of several geniuses in one.

      This is all a good thing.
      WHATWG completely changed web tech development after W3C sat doing nothing for years and tried to force a shit standard on people that never wanted it, XHTML2. (take your XML and sit on it. HTML != XML and never will be!)
      I just wish everyone would ignore W3C, they have been nothing but harmful.
      WHATWG have done more in their fairly short life than W3C has in the entire webs life.

    2. Re:Browser wars are back by Anonymous Coward · · Score: 3, Insightful

      A good thing? Hardly. The idea of standardisation is that we don't deliberately break everybody's browser every other week. The W3C always was near-useless, but this bunch is worse than useless, except for the select few that would have the very latest browser at any given point in time anyway. The rest, the vast majority, is now expending a lot of work just to prevent getting shutting out, but isn't getting nearly enough return on investment on this.

      Much like how the linux bunch "really need" replacements for things that work just fine elsewhere, fail to look what's already there, and start to reinvent well-established wheels with gay abandon, breaking compatability with everybody else down to applications becoming linux-only after having run fine elsewhere for ages. There really is no excuse, but that doesn't stop the gay blades running the show.

      This meritocracy isn't. It's just crazy. We need to speak up more often. Then again, we can't. The WHATWG is mostly a big vendor vehicle. End-users aren't invited, they're expected to shut up and watch advertisements.

    3. Re: Browser wars are back by Anonymous Coward · · Score: 2, Interesting

      This browser war is already over, and Chrome has won, both on the desktop and on mobile devices. It probably has over 50% of the market at this point. IE is the next biggest player at around 20%. Firefox is a footnote, at around 10% or less. Safari and Opera are less relevant than Firefox. And the remaining browsers are even less relevant than they are.

      It didn't even have to be this way. If the Forefox devs had only listened to their users several years ago and fixed Firefox's speed and memory problems, then these users wouldn't have had to flee to Chrome. Firefox, and Mozilla, would still have actual influence over the future of the web.

    4. Re:Browser wars are back by Anonymous Coward · · Score: 1

      Anything relying on systemd (eg. gnome) counts, especially if it didn't do so in the past. And yes, linux is busily becoming the new windows. Apparently this is part of "linux on the desktop" these days, and if so I'd say the people running the show are poor strategists as well as poor architects and poor contributors to the community. So, not wrong, so sorry dear fanboi gp.

    5. Re: Browser wars are back by Anonymous Coward · · Score: 1

      Firefox is dead.

      I made the switch to Pale Moon last week and have not looked back. Bloody brilliant.

      I also switched to FossaMail and am very happy. This was less pressing for me because Thunderbird was in the "OK" category rather than the "steaming pile of crap" which is Firefox.

    6. Re: Browser wars are back by Skuto · · Score: 1

      PaleMoon is just Firefox 24 ESR. You're still using Firefox, someone just s/Firefox/PaleMoon/g 'd it.

    7. Re: Browser wars are back by neoritter · · Score: 1

      The problem with page hit statistics is they are influenced by outside factors. Type of people that go to wikipedia, etc.

      IMO, this: http://en.wikipedia.org/wiki/U...

      Paints a different picture depending on your perspective. I find the odd split between NetApplications and the others as indicative that somewhere the statistics are as robust as they could be.

  5. Finally by jones_supa · · Score: 1

    I'm certainly going to get some really nice subwoofer to go with this.

  6. little ridiculous by say2joe · · Score: 1

    Not really 5.1. Most browsers are implementing the picture tag...however, it is important to note that they're the first to have a release supporting it. This topic Haas been discussed since responsive web design had an acronym.

    1. Re:little ridiculous by znrt · · Score: 1, Insightful

      discussed since responsive web design had an acronym.

      always wondered what idiot first chose "responsive" to brand that "dynamic layout" thing, which is absolute semantic nonsense but just stuck because who cares about semantics nowadays (because who could resist getting fancy words thrown at!). any clue?

      doesn't surprise me that we now have "responsive" labelled webapps that are actually less responsive than ever.

    2. Re:little ridiculous by TheSunborn · · Score: 1

      How it it "semantic nonsense" ?

      The design is responsive, in that it respond to changes in the size of the viewport(Screen/Window size). Makes perfect sense to me :}

    3. Re:little ridiculous by Sloppy · · Score: 1

      It's nonsense because most users, when they think about how a web app responds to an event, they're thinking of their "clicks" (or touches) rather than changing viewports. Changing viewports is a rare event (and therefore relatively unimportant) compared to pretty much anything else.

      Saying a page is "responsive" when someone tilts their tablet, is like saying a car has "great handling" because the door handles feel nice whenever you stroke them. It's not that either is a bad thing; they're simply labeled stupidly and also imply things which might be false. And for whatever reason, some people resent terminology that is simultaneously stupid and deceitful. (Weirdos!)

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    4. Re:little ridiculous by znrt · · Score: 1

      because "responsive" already meant "exhibiting consistently fast reaction". in that sense, designs can't be responsive at all. implementations might be.

      funny thing is that what you call "responsive design" is actually "2 or more designs" implemented together. this usually comes at the cost of extra resource usage and, if anything, this overhead can only negatively impact overall "responsiveness". so "responsive pages" are likely to be less responsive by definition. see the nonsense?

      it's semantical nonsense because it reuses a term that expressed an overall characteristic of something, to refer to a particular feature of it. it's confusing.

      btw responding to changes in the size of the viewport or container wasn't even new, it's a cool feature that had been already around for decades on many platforms and was called "dynamic layout" or "fluid layout" or simply "using a layout manager". ok, that might not be catchy enough for current buzzword standards, but choosing "responsive" for it was really lame.

  7. talk about "old tech" by dltaylor · · Score: 2, Informative

    So now we have a relabeled "TIFF" container?

    Tagged Interchange File Format (TIFF) has been around since the 1980s; the Amiga had a nice version, and I used them in a very old document system for the US Navy. The file could hold multiple instances of the same data, in different formats. A picture could be JPEG, GIF, a PDF bitmap, ..., for example, and the platform displayed/printed whatever it could.

    1. Re:talk about "old tech" by Anonymous Coward · · Score: 1

      The whole point of the picture element is that you don't have to download all the possible sizes, just the one that's appropriate for your display.

    2. Re:talk about "old tech" by dltaylor · · Score: 1

      The "one"? Unless it's a form of DRM not supported on a specific platform, many, or all, of the formats are displayable. Of course, the browser will "automagically" know which of the several you want THIS time.

      It's still old tech. lseek(), read() or GET. You don't have to pull all the versions from storage with TIFF, either.

    3. Re:talk about "old tech" by sexconker · · Score: 1

      The whole point of the picture element is that you don't have to download all the possible sizes, just the one that's appropriate for your display.

      What's appropriate for my display, exactly?
      You have to base it on the VIEWPORT, but that's VARIABLE because the USER can change that shit.
      Any viewport change and you risk having to download the newly "appropriate" version.

      This shit is retarded - just provide a decent size by default and offer a link to the original size.
      The whole premise of why we'd want to do this is retarded as well. Phones are getting resolutions of 2560x1440 now.

    4. Re:talk about "old tech" by Goaway · · Score: 1

      the Amiga had a nice version

      It did not. IFF is entirely unrelated to TIFF.

      You are also over-romanticising the TIFF format quite a bit. In actuality, it is quite a mess and mostly supports a million complicated features exceedingly few people actually want, making supporting it a completely nearly impossible.

    5. Re:talk about "old tech" by zmooc · · Score: 4, Informative

      It's much more than that; the images contained in a TIFF file cannot be downloaded separately while the images contained in a picture-tag can. This way I don't have to wait for ages when browsing on my phone while I can still enjoy top quality images on my desktop. That was already possible by allowing the webserver to serve a different pictures based on the User Agent, but that's ugly and it doesn't allow the user to choose the bigger file after all. Furthermore, this new tag allows the browser to select an image based on the speed of the connection, potentially making the web much more responsive in general.

      --
      0x or or snor perron?!
    6. Re:talk about "old tech" by znrt · · Score: 1

      You have to base it on the VIEWPORT, but that's VARIABLE because the USER can change that shit.

      not if you manage to sheep users to use the same dumb ui model, which is why everyone is carving to accomplish exactly that (a copycat of apple's, which is shiny and famous and cool, all the way down from google to ubuntu, crashing through several windows)

    7. Re:talk about "old tech" by Njovich · · Score: 1

      I have seen a lot of weird features in TIFF, but being able to dynamically load the correct size of images over the network using media queries to save bandwidth isn't one of them.

      So, no, this is absolutely nothing like TIFF.

    8. Re:talk about "old tech" by omfgnosis · · Score: 1

      What's appropriate for my display, exactly?
      You have to base it on the VIEWPORT, but that's VARIABLE because the USER can change that shit.
      Any viewport change and you risk having to download the newly "appropriate" version.

      +

      The whole premise of why we'd want to do this is retarded as well. Phones are getting resolutions of 2560x1440 now.

      There's more to it than that, and yet more coming in the future. Yes, media queries tend to be primarily viewport queries. Viewport data is more complex than just pixel dimensions though, because a browser pixel is not a device pixel. This is why device-pixel-ratios are also supported. A 2560x1440 phone likely responds to a media query as ~854x480@3x (the math isn't right, I wonder what the real device pixel viewport size is).

      Picture/source also supports mime-type alternation, just like video/audio sources do. This allows content to be delivered in preferred media types (e.g. webm, webp) where possible with fallbacks to less-preferred types (e.g. h264, png/jpg/gif), potentially reducing bandwidth and cost.

      The same group that led the picture element is now leading element queries, which will allow size-based queries to be derived from the size displayed on screen, rather than the size of the viewport itself (as in, placing a responsive image in a sidebar will have different download characteristics from placing it in a full-width column).

      And browser vendors can develop selection algorithms based on user preference (e.g. prefer faster downloads) and network conditions (e.g. high latency cell, bandwidth limits, etc) rather than viewport conditions alone.

      Literally none of the features discussed here are possible with the feature set that existed before picture. Some (some!) can be approximated with JavaScript, generally badly and often with very undesirable consequences.

    9. Re:talk about "old tech" by sexconker · · Score: 1

      What's appropriate for my display, exactly?
      You have to base it on the VIEWPORT, but that's VARIABLE because the USER can change that shit.
      Any viewport change and you risk having to download the newly "appropriate" version.

      +

      The whole premise of why we'd want to do this is retarded as well. Phones are getting resolutions of 2560x1440 now.

      There's more to it than that, and yet more coming in the future. Yes, media queries tend to be primarily viewport queries. Viewport data is more complex than just pixel dimensions though, because a browser pixel is not a device pixel. This is why device-pixel-ratios are also supported. A 2560x1440 phone likely responds to a media query as ~854x480@3x (the math isn't right, I wonder what the real device pixel viewport size is).

      Picture/source also supports mime-type alternation, just like video/audio sources do. This allows content to be delivered in preferred media types (e.g. webm, webp) where possible with fallbacks to less-preferred types (e.g. h264, png/jpg/gif), potentially reducing bandwidth and cost.

      The same group that led the picture element is now leading element queries, which will allow size-based queries to be derived from the size displayed on screen, rather than the size of the viewport itself (as in, placing a responsive image in a sidebar will have different download characteristics from placing it in a full-width column).

      And browser vendors can develop selection algorithms based on user preference (e.g. prefer faster downloads) and network conditions (e.g. high latency cell, bandwidth limits, etc) rather than viewport conditions alone.

      Literally none of the features discussed here are possible with the feature set that existed before picture. Some (some!) can be approximated with JavaScript, generally badly and often with very undesirable consequences.

      Literally none of the features discussed in your post are desirable for users.
      If you're hosting different versions, provider links to the versions and let the user choose.
      Don't serve up different content to different browsers unless you absolutely have to (and when you absolutely have to, odds are your UI is terrible).

    10. Re:talk about "old tech" by omfgnosis · · Score: 1

      Literally none of the features discussed in your post are desirable for users.

      Nonsense. Most so-called responsive techniques were driven by user demand:

      1. for the "real web" on mobile devices
      2. for actually usable web pages on mobile devices
      3. for high resolution displays with sharper text and more detailed images
      4. for respectful and reliable behavior in varying network conditions

      These sorts of demands have been so strong that they upset the entire mobile industry, destroying huge incumbent companies.

      As far as specific features...

      Device-pixel ratios are how users get sharper text—and now images—when their hardware allows it. The alternative is that either users see smaller and smaller content/UI, or they are stuck with low-resolution displays. Neither of those are desirable outcomes for users (and sales show pretty well that users prefer high-resolution).

      Mime-type alternation allows:

      - all users (rather than some) to view content—this is self-evidently desirable by users;
      - some users to reduce bandwidth—this is self-evidently desirable by any user who is bandwidth-constrained (either in terms of speed of data cap).

      Element queries allow UI elements to be reusable components, so that they always behave the same way under the same circumstances. This is fairly obviously desirable by everyone, as the alternative is to have things work in myriad ways depending on unrelated circumstances.

      User-based settings for preferring faster downloads/reduced data consumption is obviously desirable. I can't for the life of me imagine how you could say it's not.

      If you're hosting different versions, provider links to the versions and let the user choose.

      Nothing is preventing a responsive site from doing just that, but still being smart about which (and how many) bits to send down the wire to a particular user.

      Don't serve up different content to different browsers unless you absolutely have to (and when you absolutely have to, odds are your UI is terrible).

      You seem to fundamentally misunderstand what responsive design is about. This is not about serving different content (at all) nor distinguishing between browsers (at all). It's about providing optimal rendering of the same content for different viewing/network conditions. Fundamentally, what is optimal for 2560x1440@1x is not optimal for 2560x1440@3x. What is optimal for LTE is not optimal for EDGE.

    11. Re:talk about "old tech" by sexconker · · Score: 1

      Your opinions represent everything wrong with modern web design. Just because shit is popular doesn't mean it's good.
      Every fucking site I go to on my phone presents me with shit I don't fucking want in a format I can barely fucking use, typically with content from the real site missing. Half of them will refuse to respect my preference of seeing the full site.

      It absolutely is about presenting different shit to different users based on browser, device, etc..
      If you want to reduce bandwidth and increase speed, you would NOT use picture, video, etc. on first landing, you would LINK to shit. A sane-sized image and a few links, with descriptive text is preferable to automatically loading video, audio, giant images, different sizes of the same image, etc.. This is true of both mobile browsing and desktop browsing.
      A "mobile" site should be no different from a fucking regular site in this day and age. Devices can handle it. If users can't see shit they can zoom. The browser can scale elements up via CSS, or reduce the viewport size internally while presenting a scaled up view of it, and scale that up HTML being what it is, shit will reflow automatically. Barring that, zoom as-visible and pan. Scaling is easy. Dealing with shitty fucking mobile design trends that only ever half work is infuriating.

    12. Re:talk about "old tech" by badkarmadayaccount · · Score: 1

      Are they gonna add text overlay, that would greatly improve cache performance on sites like 9gag

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  8. Oh yeah Google? by Anonymous Coward · · Score: 1, Funny

    Well, I'm going to support HTML 6.9. With Hookers and Blackjack.

    In fact, forget the Blackjack!

    1. Re:Oh yeah Google? by znrt · · Score: 2

      With Blackjack! And Hookers!

      ftfy. thanks for the hard laugh xD

  9. Re:cool by x0ra · · Score: 2, Funny

    Well, why did you move to a modern multi GB / GHz / TB / Gbps machine, "oughtn't 640K to be enough for anybody ?"

  10. At long last... by Dutchmaan · · Score: 1, Funny

    depreciated

    1. Re:At long last... by Bite+The+Pillow · · Score: 1

      </first post>

  11. In addition ... by fahrbot-bot · · Score: 1

    ... the use of the new "picture" tag which is a container for multiple image sizes/formats ...

    ... I hear each one can take the place of a 1000 words.

    --
    It must have been something you assimilated. . . .
    1. Re:In addition ... by plover · · Score: 3, Funny

      ... the use of the new "picture" tag which is a container for multiple image sizes/formats ...

      ... I hear each one can take the place of a 1000 words.

      ... and it will only require 50,000 words in which to send it.

      --
      John
  12. No 5.1 - don't let versions get popular! by bussdriver · · Score: 5, Informative

    The 5.1 label was just to separate it out, the intention of most was to have it live so that there is no new version. As you probably know already, most the major stuff is not directly under HTML5 but are side groups which either are under HTML5 or they are separate but are treated like they are part of HTML5 (openGL or web sockets for example.) New tags like MAIN, DETAIL, FIGURE or PICTURE, well those ended up in HTML5 but were not around or changed quite a bit. Firefox still doesn't support DETAIL even though it has had decent documentation for quite a while now (it didn't for a long time...)

    The mature people involved realized that version numbers do not mean a whole lot because vendors market themselves as supporting "STANDARD X.Y" but lack full support or correct support (MS being a great example.) There is little practical reason for versions because they do not mean a whole lot and real world developers have to work around mixed user support anyway.

    If you don't like the PICTURE tag, try to get HTTP 1 & 2 to finally finish the drafts on image sizes so we can do the content negotiation on the server; where it belongs. The whole reason this came about was there was no smart way to get IMG to handle it and there is a use case where CSS media queries (which is not really css 3.x either) do not work. You should be using CSS but when you can't PICTURE is what you use if you can't configure your server (I would suggest some JS that sets a cookie until the browsers finally start sending the info.)

    --
    Democracy Now! - uncensored, anti-establishment news
  13. Re:retro is always popular... by znrt · · Score: 2

    use of tables for top-bottom layout was the one thing css should have relied on and even promoted, but they chose to bury it, and brought up that bizarre bottom-top layout model that barely mimics what tables already did in a natural way. it was about semantics, thay said. but, hey! now you got plenty of semantics! we have col_sm_4, and even col-md-1!!

  14. It's nit picking but... by rHBa · · Score: 3, Informative

    Tim Berners-Lee didn't invent the internet, he is credited with inventing the World Wide Web.

  15. Re:Question... by Anonymous Coward · · Score: 1

    On the other hand, Firefox is adding them as an official feature, as part of their upcoming "Tab Center" feature: https://bugzilla.mozilla.org/show_bug.cgi?id=1058854

  16. avoidance tactic by globaljustin · · Score: 2

    your comment is a good way to incite off-topic controversy and deflect attention from the **content of my post**

    which is actually important stuff...think about what I've presented and stop being a grammar nazi

    --
    Thank you Dave Raggett
  17. Re:mother of all demos by rHBa · · Score: 1

    Ooo, snappy snappy, just like a crocodile! I'm sorry if I misinterpreted the quotes you put around "inventor of the internet" but there's no need to spit the dummy!

  18. It's about time for a code upgrade by Art3x · · Score: 3, Funny

    Last night I finally started reading an old book, HTML: The Definitive Guide, 3rd. ed., published in 1998. "HTML is a young language, barely five years old," it begins, "but already in its fourth interation. Don't be surprised if another version appears before you finish reading this book."

    I smiled to myself. If only he had known that HTML 4 would stay with us for eleven years, and that when 5 came out, they said they wouldn't update the version numbers anymore.

    But the book was right: another version came out before I finished it.

  19. Re:cool by aliquis · · Score: 1

    more 'standards' just to obsolete every browser and stimulate undesired upgrades.

    Says the guy with Windows XP and IE6.

  20. Re:mother of all demos by rHBa · · Score: 1

    To be honest I thought you had some interesting points in your original post but now you seem like a bit of a dick. Calm your temper a bit and you won't deflect attention from the content of your post.

  21. Re:cool by Anonymous Coward · · Score: 1

    The wonderful thing about standards is that we have so many of them to choose from.

  22. Re:retro is always popular... by znrt · · Score: 1

    said the pro who thinks html has variables ...

  23. Re:Question... by Elbart · · Score: 1

    Great, another reason to switch to Chrome.

  24. Re:cool by madprof · · Score: 1

    You are right, but the comment you are replying to was not talking about Chrome or web standards.

  25. Re:mother of all demos by madprof · · Score: 1

    How on Earth did you manage to come to the conclusion that Englebart's 1968 demo was somehow related to the Internet? The Internet has a number of key players to thank for its development, both technical and legislative, but Doug Englebart is not one of them. His influence was elsewhere.

  26. Re:mother of all demos by globaljustin · · Score: 1

    well thanks for reading...i misinterpreted the tone of your response

    --
    Thank you Dave Raggett