Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Chrome Graphics Programming Upgrades

Google Introduces HTML 5.1 Tag To Chrome 94

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."
This discussion has been archived. No new comments can be posted.

Google Introduces HTML 5.1 Tag To Chrome

Comments Filter:
  • by Anonymous Coward

    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.

    • Re: (Score:2, Informative)

      by Anonymous Coward
      HTML 5 isn't even a standard, yet, for all that everyone is yapping about it. It's still a draft.
      • Re:5.1? (Score:5, Informative)

        by Lennie ( 16154 ) on Saturday August 30, 2014 @06:55AM (#47790205)

        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.

        • Re:5.1? (Score:5, Insightful)

          by MatthiasF ( 1853064 ) on Saturday August 30, 2014 @12:59PM (#47791291)
          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.
          • What motivation do the browser vendors have to implement a spec that they had no say in, and quite probably doesn't align with the desires of their users?

    • by bussdriver ( 620565 ) on Saturday August 30, 2014 @03:16AM (#47789773)

      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.)

  • can we give the WHATWG [wikipedia.org] 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

    • by rHBa ( 976986 ) on Saturday August 30, 2014 @08:02AM (#47790379)
      Tim Berners-Lee didn't invent the internet, he is credited with inventing the World Wide Web.
      • I know who invented the damn internet [wikipedia.org](not Behrners-Lee or Gore) and the whole notion that the abstraction that is the "world wide web" was somehow important to the **actual internet** is ridiculous

        nit picking? i never put up a nit for you to pick! you're putting words in my mouth

        non-tech media types say "Tim Behner's Lee, the man who invented the internet" all the time...it is a *common misconception*

        Behner's-Lee didn't do anything especially noteworthy in the development of the internet...the 'world wide

        • by rHBa ( 976986 )
          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!
        • by madprof ( 4723 )

          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.

    • by Carewolf ( 581105 ) on Saturday August 30, 2014 @09:55AM (#47790655) Homepage

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

      Notice the hostname.

  • by Rosyna ( 80334 ) on Saturday August 30, 2014 @12:46AM (#47789439) Homepage

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

    • Re:srcset attribute (Score:5, Informative)

      by Pieroxy ( 222434 ) on Saturday August 30, 2014 @02:32AM (#47789661) Homepage

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

      • 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 ra

        • by Pieroxy ( 222434 )

          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

  • by Anonymous Coward on Saturday August 30, 2014 @12:57AM (#47789465)

    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.

    • by Anonymous Coward

      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 tha

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        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

    • by Anonymous Coward

      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, the

      • by Anonymous Coward

        Firefox is dead.

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

        I also switched to FossaMail [fossamail.org] 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.

        • by Skuto ( 171945 )

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

  • I'm certainly going to get some really nice subwoofer to go with this.
  • 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.
    • Re: (Score:2, Insightful)

      by znrt ( 2424692 )

      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.

      • 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 :}

        • by Sloppy ( 14984 )

          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

        • by znrt ( 2424692 )

          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

  • by dltaylor ( 7510 ) on Saturday August 30, 2014 @01:19AM (#47789507)

    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.

    • by Anonymous Coward

      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.

      • by dltaylor ( 7510 )

        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.

      • 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.

        • by znrt ( 2424692 )

          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)

        • 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

          • 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).

            • 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

              • 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 spee

    • by Goaway ( 82658 )

      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.

    • by zmooc ( 33175 ) <{ten.coomz} {ta} {coomz}> on Saturday August 30, 2014 @05:48AM (#47790079) Homepage

      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.

    • by Njovich ( 553857 )

      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.

  • by Anonymous Coward

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

    In fact, forget the Blackjack!

  • <first post> depreciated
  • ... 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.

  • by Art3x ( 973401 ) on Saturday August 30, 2014 @02:58PM (#47791921)

    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.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...