Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Introduces HTML 5.1 Tag To Chrome

timothy posted about 2 months ago | from the tagging-wars-ensue dept.

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

Sorry! There are no comments related to the filter you selected.

fuck em a googol times up the nose (-1, Troll)

Anonymous Coward | about 2 months ago | (#47789387)

The Internet is too old and too grumpy for change. Get your new-fangled browser off my freshly-mowed lawn, you damn hipster bus-riding punks!

cool (-1, Flamebait)

Anonymous Coward | about 2 months ago | (#47789389)

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

Re:cool (2, Funny)

x0ra (1249540) | about 2 months ago | (#47789571)

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

Re:cool (0)

Anonymous Coward | about 2 months ago | (#47790237)

I see you have been properly brainwashed by decades of consumerism and planned obsolescence. Time for you to be a good little consumer and keep replacing your music and movie collections yet again, your smartphone every year, your automobile every 2 years, and your house every 5 years, otherwise our economic house of cards based on limitless perpetual growth will collapse.

Re:cool (0)

Anonymous Coward | about 2 months ago | (#47793529)

What's wrong about upgrading to a newer browser that is FREE and will help push the Web forward? Or would you rather still be stuck with GIFs instead of PNGs, software-rendered RealVideo instead of hardware-accelerated HTML5 video and require the Java plug-in just to have stupid hover effects?

Re:cool (1)

madprof (4723) | about 2 months ago | (#47794545)

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

Re:cool (0)

Anonymous Coward | about 2 months ago | (#47790417)

I didn't. The world around me did, i am still using older hardware but it is not like it is economical to keep upgrading it without going GB/GHz. So yes, forced upgrades - I have no choice in the matter unless i make vintage hardware my lifestyle.

Re:cool (0)

Anonymous Coward | about 2 months ago | (#47790611)

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

These days 640 KB RAM is not sufficient even for command-line GNU/Linux running terminal-mode applications.

Re:cool (0)

Anonymous Coward | about 2 months ago | (#47790693)

Actually the img tag still works, and HTML 5.1 picture tag (and many others) provide fall backs for browsers that don't support the new tag(s). Moreover, responsive images (picture tags) will save bandwidth and provide better art direction.

Re:cool (1)

aliquis (678370) | about 2 months ago | (#47792379)

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

Says the guy with Windows XP and IE6.

Re:cool (1)

Anonymous Coward | about 2 months ago | (#47793775)

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

5.1? (1)

Anonymous Coward | about 2 months ago | (#47789417)

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:5.1? (2, Informative)

Anonymous Coward | about 2 months ago | (#47789523)

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

Re:5.1? (5, Informative)

Lennie (16154) | about 2 months ago | (#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? (5, Insightful)

MatthiasF (1853064) | about 2 months ago | (#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.

Re:5.1? (0)

gsnedders (928327) | about 2 months ago | (#47791521)

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?

No 5.1 - don't let versions get popular! (5, Informative)

bussdriver (620565) | about 2 months ago | (#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.)

nail in W3C coffin (1, Interesting)

globaljustin (574257) | about 2 months ago | (#47789421)

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

Re: nail in W3C coffin (-1)

Threni (635302) | about 2 months ago | (#47789813)

You don't have to use "repeat" in written text online because there's no chance anything is going to happen to the first instance of the text. It just wastes space and looks a little self important.

Re: nail in W3C coffin (1)

Anonymous Coward | about 2 months ago | (#47790373)

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

Re: nail in W3C coffin (2)

I'm New Around Here (1154723) | about 2 months ago | (#47790785)

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

avoidance tactic (2)

globaljustin (574257) | about 2 months ago | (#47791289)

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

It's nit picking but... (3, Informative)

rHBa (976986) | about 2 months ago | (#47790379)

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

Re:It's nit picking but... (-1)

Anonymous Coward | about 2 months ago | (#47790633)

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

Word up! Al Gore invented the Internet. ;-)

mother of all demos (0)

globaljustin (574257) | about 2 months ago | (#47791313)

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 web' is just a marketing phrase...not noteworthy...his technical contributions were as part of a working group and many others have done much more noteworthy work

Re:mother of all demos (1)

rHBa (976986) | about 2 months ago | (#47791733)

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!

Re:mother of all demos (-1, Flamebait)

globaljustin (574257) | about 2 months ago | (#47793119)

if you're dumb enough to misinterpret those quotation marks, and feel so strongly about pointing it out that you take the time to post a comment then you deserve to be humbled

responding to dumb/troll comments appropriately can involve vitriol

Re:mother of all demos (1)

rHBa (976986) | about 2 months ago | (#47793657)

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.

Re:mother of all demos (1)

globaljustin (574257) | about 1 month ago | (#47807579)

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

Re:mother of all demos (1)

madprof (4723) | about 2 months ago | (#47794581)

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.

Re:nail in W3C coffin (3, Informative)

Carewolf (581105) | about 2 months ago | (#47790655)

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

Notice the hostname.

Re:nail in W3C coffin (3, Informative)

Lennie (16154) | about 2 months ago | (#47791183)

Most of the HTML5 specifications gets developed here first:

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

Then eventually after a long process will end up here:

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

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

Re:nail in W3C coffin (1)

Carewolf (581105) | about 2 months ago | (#47792095)

Most of the HTML5 specifications gets developed here first:

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

Then eventually after a long process will end up here:

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

However Picture-tag actually came from the community first, not the W3C or the vendors directly:
http://responsiveimages.org/ [responsiveimages.org] only later did it become http://www.w3.org/community/re... [w3.org] 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.

proves nothing (0)

globaljustin (574257) | about 2 months ago | (#47791323)

what does that prove?

NOTHING

the WHATWG is the only reason HTML/CSS has had any relevant improvements and, most importantly, ****the W3C has been purposefully hampering HTML/CSS development****

if I'm right it's a big f-ing deal...no one has presented any counterpoint...

srcset attribute (2)

Rosyna (80334) | about 2 months ago | (#47789439)

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 (4, Informative)

Pieroxy (222434) | about 2 months ago | (#47789661)

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

Re:srcset attribute (1)

QuasiSteve (2042606) | about 2 months ago | (#47795123)

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?

Re:srcset attribute (1)

Pieroxy (222434) | about 2 months ago | (#47795447)

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

Browser wars are back (3, Insightful)

Anonymous Coward | about 2 months ago | (#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.

Re:Browser wars are back (1)

Anonymous Coward | about 2 months ago | (#47789811)

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.

Re:Browser wars are back (3, Insightful)

Anonymous Coward | about 2 months ago | (#47790009)

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.

Re:Browser wars are back (-1)

Anonymous Coward | about 2 months ago | (#47790181)

You are so fucking wrong about linux. So many application, that are started on linux, become multiplatform, never heard of any that would gone from multiplatform to linux only (may have happened, but maybe there are real reasons for that, bitch). Mostly the only problems come from the fact that they don't have anyone compiling and testing on mac, which makes mac releases hard.

Re:Browser wars are back (0)

Anonymous Coward | about 2 months ago | (#47790441)

I havent heard of any going multiplatfrom to singleplatform either. but Linux introduces a lot of unique system calls that no other OS supports. Linux programmers then go on to make their "portable code" into Linux only code by not providing alternatives for non-linux systems (usually this is done from the outset, as i said, i havent seen anything change mid-ways). I see a lot of linux-only code out there by people who seem to think if it works on linux it is portable. It is sad to see these "microsoft world" style programmers in "open source" world :( monocultures suck sweaty arse, no matter if its linux or windows.

Re:Browser wars are back (1)

Anonymous Coward | about 2 months ago | (#47790567)

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.

Re:Browser wars are back (0)

Anonymous Coward | about 2 months ago | (#47792353)

Lmao, since Firefox.

Get off my lawn noob.

Re: Browser wars are back (2, Interesting)

Anonymous Coward | about 2 months ago | (#47790453)

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.

Re: Browser wars are back (1)

Anonymous Coward | about 2 months ago | (#47791385)

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.

Re: Browser wars are back (1)

Skuto (171945) | about 2 months ago | (#47794753)

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

Re: Browser wars are back (0)

Anonymous Coward | about 2 months ago | (#47792083)

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.

Stats or it didn't happen [wikimedia.org] .

Sorry to bring you back from your fantasy land to reality, but what I just linked above is a graph of the ratios of distinct user agents connecting to one of the highest traffic sites on the web. (Wikimedia sites, including Wikipedia, just to be clear.)

It clearly shows Chrome in the lead, but not by much of a margin. IE and Firefox are both within 10% of that. Safari is a close 4th with around half of Chrome's user base. Beyond that, then you can call it a lost cause.

Next time you make some dumb-ass assertion to back up your world view, try at least justifying it with some actual numbers from somewhere.

Also, I will never use Chrome because Chrome is a "soviet russia" type of browser. It watches you. And that will be its downfall, eventually.

Re: Browser wars are back (0)

Anonymous Coward | about 2 months ago | (#47793813)

Jesus Fucking Christ, did you even look at your stats? Did you look at when they're from?

Data from September 2012

Yes, that's right, you just tried to use 2 year old data to back up your point. Nice try, but you're wrong, and your data is outdated and irrelevant.

Let's look at some more recent data, okay? How about Wikimedia's stats for July 2014 [wikimedia.org] ?

Oh, my! Well, it looks like the GP is correct. Chrome has 26.49% of the desktop market, and 15.01% of the smartphone market. That's over 40%, which I consider reasonably close to the GP's estimate of 50%.

And the GP is right when it comes to Firefox. It has 9.78% of the desktop market, and a trifling 0.17% of the mobile market. That does put it right around 10%.

The GP is wrong when it comes to Safari. It's more popular than Firefox, at 4.32% of the desktop market, 5.51% of the tablet market, and 14.61% of the smartphone market. So that's over 20%.

But the GP is right about Opera being totally irrelevant. It's only at about 2% overall.

If we look at stats from today, we can clearly see that Chrome has absolutely crushed Firefox and the other browsers. Firefox is just BARELY holding on these days, and given how angry its users are with Australis and other changes, I could see it being at 5% by the end of the year. Face it, Firefox is a dead product at this point.

Re: Browser wars are back (1)

neoritter (3021561) | about 1 month ago | (#47810255)

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... [wikipedia.org]

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.

Finally (1)

jones_supa (887896) | about 2 months ago | (#47789477)

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

little ridiculous (1)

Joe Johnson (3773821) | about 2 months ago | (#47789501)

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:little ridiculous (1, Insightful)

znrt (2424692) | about 2 months ago | (#47790225)

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.

Re:little ridiculous (1)

TheSunborn (68004) | about 2 months ago | (#47790257)

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

Re:little ridiculous (1)

Sloppy (14984) | about 2 months ago | (#47791487)

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

Re:little ridiculous (1)

znrt (2424692) | about 2 months ago | (#47794157)

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.

talk about "old tech" (2, Informative)

dltaylor (7510) | about 2 months ago | (#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.

Re:talk about "old tech" (1)

Anonymous Coward | about 2 months ago | (#47789539)

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.

Re:talk about "old tech" (1)

dltaylor (7510) | about 2 months ago | (#47789595)

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.

Re:talk about "old tech" (0)

Anonymous Coward | about 2 months ago | (#47791523)

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

Ok, so a ranged GET request to read the TIFF's header, then you process the metadata (I hope it's all contiguous and doesn't ever need any more requests; I don't remember TIFF's layout) and then another GET ranged request to read the desired chunk. (lseeks over http, what a great idea. Hey, I have an idea: let's write a database!)

Re:talk about "old tech" (1)

sexconker (1179573) | about 2 months ago | (#47789931)

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.

Re:talk about "old tech" (1)

znrt (2424692) | about 2 months ago | (#47790281)

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)

Re:talk about "old tech" (1)

omfgnosis (963606) | about 1 month ago | (#47804103)

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.

Re:talk about "old tech" (1)

sexconker (1179573) | about 1 month ago | (#47804537)

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

Re:talk about "old tech" (1)

omfgnosis (963606) | about 1 month ago | (#47807433)

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.

Re:talk about "old tech" (1)

sexconker (1179573) | about a month and a half ago | (#47813725)

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.

Re:talk about "old tech" (1)

Goaway (82658) | about 2 months ago | (#47790049)

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.

Re:talk about "old tech" (0)

Anonymous Coward | about 2 months ago | (#47790467)

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.

So HTML5.1 is like this TIFF? a mess that "supports a million complicated features" that "few people actually want" and " making supporting it a completely nearly impossible".

Re:talk about "old tech" (0)

Anonymous Coward | about 2 months ago | (#47791413)

I recently finished a reverse-engineering effort on Gatan's DM4 image format. It's a bit like TIFF, but at least if I was implementing TIFF I'd have a standard to look at. These large and expansive file definitions are very daunting to implement, so I appreciate the comments by the parent poster. However, the GP does make a good point that there is very little to see here.

I don't know why the server can't just deliver the correct image. I've written hundreds of websites and web applications and my standard approach is to implement everything on the server and to learn what I can from the header information to be sure I send the right thing. If the user is browsing (or pretends to be, this shit isn't magic, we can't deal with every use case) from a small screen then I send them smaller images and tweak the raw basic simple HTML to display it. If the user is on something bigger then the layout (and content) is adjusted as appropriate. At all time, and as another poster mentioned, this is all about thumbnails and what I would call "throwaway" or "preview" graphics. At the end of the fucking day, my pages (and I think _all_ pages) should offer a simple link to the original content.

Re:talk about "old tech" (4, Informative)

zmooc (33175) | about 2 months ago | (#47790079)

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.

Re:talk about "old tech" (1)

badkarmadayaccount (1346167) | about a month and a half ago | (#47814563)

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

Re:talk about "old tech" (1)

Njovich (553857) | about 2 months ago | (#47790641)

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.

Re:talk about "old tech" (0)

Anonymous Coward | about 2 months ago | (#47791747)

Actually I think TIFF may see a renewal for this purpose in combination with ranged HTTP requests. There are modern uses of TIFF for large-format images stored in a tiled multi-resolution pyramid. A TIFF-aware application could fetch the TIFF header and then just retrieve the tiles/zoom-levels it wants while doing a zoom/pan interface for the user. While this may sounds ugly, it is nowhere near as ugly as the alternative: exploding this image into a million little files with some ad-hoc REST mapping layer to resolve the picture coordinates and zoom level into URLs (with every app requiring something different for this).

Oh yeah Google? (1, Funny)

Anonymous Coward | about 2 months ago | (#47789517)

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

In fact, forget the Blackjack!

Re:Oh yeah Google? (2)

znrt (2424692) | about 2 months ago | (#47790295)

With Blackjack! And Hookers!

ftfy. thanks for the hard laugh xD

At long last... (1, Funny)

Dutchmaan (442553) | about 2 months ago | (#47789579)

<first post> depreciated

Re:At long last... (1)

Bite The Pillow (3087109) | about 2 months ago | (#47791021)

</first post>

In addition ... (1)

fahrbot-bot (874524) | about 2 months ago | (#47789637)

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

Re:In addition ... (3, Funny)

plover (150551) | about 2 months ago | (#47789693)

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

code bloat (-1)

Khyber (864651) | about 2 months ago | (#47789855)

img is shorter than picture. good job bloating the code, whomever is responsible for this.

retro is always popular... (0)

Anonymous Coward | about 2 months ago | (#47790127)

layout tables, blink, and image maps ftw. and o yea, dont forget the comic sans.

Re:retro is always popular... (2)

znrt (2424692) | about 2 months ago | (#47790359)

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!!

Re:retro is always popular... (0)

Anonymous Coward | about 2 months ago | (#47792225)

Thankfully, inept web designers who only see the world in tables do not make the world go round. Especially ones who choose meaningless variable names.

Re:retro is always popular... (1)

znrt (2424692) | about 2 months ago | (#47794165)

said the pro who thinks html has variables ...

Question... (0)

Anonymous Coward | about 2 months ago | (#47790221)

Sidetabs back in Chrome yet?

No? Chrome still sucks then.

Re:Question... (1)

Anonymous Coward | about 2 months ago | (#47790931)

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

Re:Question... (1)

Elbart (1233584) | about 2 months ago | (#47794531)

Great, another reason to switch to Chrome.

They're not the only ones. (0)

Anonymous Coward | about 2 months ago | (#47790899)

Firefox has nearly completed their own implementation, and I'm sure Webkit isn't far behind either. I really don't understand the outrage in this case. It's useful technology that no one has to use, has sensible fallbacks, should be supported at roughly the same time if all goes well, and has variants coming out at the same time (srcset) to try to give page authors control over their resources. Further, none of the bright ideas others have suggested are comparatively good ideas that will lead to less of a mess, and people have been asking for this for responsive site designs for years.

This isn't the same thing as the MSE/EME fiasco, or even the HTML5 video codec fiasco. Google hasn't just done whatever the hell they want, and used their clout to make everyone else just have to grin and bear it. This time it's something that basically has willing consensus, and doesn't leave everyone a year behind Chrome like some dastardly villain bait and switching everyone while twirling their mustache.

It's about time for a code upgrade (3, Funny)

Art3x (973401) | about 2 months ago | (#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.

Isn't this just lowsrc= by a different name? (0)

Anonymous Coward | about 2 months ago | (#47792441)

Do we really expect half a dozen alternative image resolution substitutes in common websites? Whom does this extension serve? It's basically just a more complex lowsrc=.

Shouldn't the WHATWG rather spent some thought on streamlining HTTP Content-Negotation for this? That's precisely meant for delivering degraded content and device-specific representations. You'd think the major browser vendors could bring up a coherent Accept-Feature list for such purposes instead of concocting tedious markup workarounds. (Well, at least it's the same cheap workaround as with <video> then.)

amazing (0)

Anonymous Coward | about 2 months ago | (#47794803)

I am shocked at the amount of idiot babel in these comments.

Here's how the image tag works:

  show me a picture

Your browser downloads the same image file regardless of whether you're on a 1080p desktop display or an iPhone. What picture does is this:

  show happyface-large.jpg to big screens but show happyface-small.jpg to small screens

In this case, happyface-large.jpg might be a large image designed to look good in a layout for a large screen, while happyface-small.jpg is the same image, just reduced in pixel dimensions to a size appropriate for a mobile phone. In this case, the difference between these 2 images could be a lot of potential kilobytes that the mobile phone user doesn't in any way need to download to experience the image. With picture, the browser only grabs the image that is designated by the programmer as being the right match for their screen size.

Right now in order to offer the functionality that this *1* tag brings, developers have to jump through all sorts of very gross server side and javascript hoops that add unnecessary resource strain to a site, and I can tell you from much experience that the end result often ends up being "fuck it, let's give them happyface-large.jpg and just scale it down with the viewport." So on your mobile you're looking at huge graphics scaled down to that tiny screen FOR NO REASON. Picture gives every developer an easy way to say, "Ok, here's a smaller image that is appropriate for your screen size."

This will in no way do you any harm. This is a badly needed upgrade to the spec that give browsers CLIENT SIDE ability to show you images that are appropriate for your screen size/shape and pixel density. This will make web pages load faster on your phones and tablets. This will give you fancy hi-res images on that retina screen i-Thing you had to buy.

Re:amazing (0)

Anonymous Coward | about 2 months ago | (#47797361)

> This will make web pages load faster on your phones and tablets.

How does that work? The retina display on an iPad is bigger in terms of pixels (2048x1536 = 3.1 Megapix) than a typical HD monitor on your desktop (1920 x 1080 = 2.1 Mgeapix).

All this will do, if anything, will make web pages load faster on your desktop that on your shiny iAccoutrement.

Re:amazing (0)

Anonymous Coward | about 2 months ago | (#47799567)

Sorry, but that isn't entirely correct.

An example for phones:

Images served are specified by viewport width which is reported by the browser, and device pixel ratio. A good developer will specify a 320-ish pixel wide image for non retina mobile devices and a 640-ish (pixel-doubled) image for retina mobile devices. A 640px wide image is still a great deal smaller than a 1000+ pixel wide (desktop) wide image scaled down, which is what you are getting a lot of the time now. I'm using fuzzy numbers here, actual sizes of images served will be up to the specific site design constraints.

In a typical responsive site the iPad and other tablets still report as a 1024 x 768 viewport. This doesn't have anything to do with its actual resolution, it is just how it gets interpreted by the browser. Most responsive sites use a meta tag to baseline devices to a non-pixel doubled ratios for the purposes of standardizing math in the layout process. For a retina iPad, the developer then has the choice to show you a retina image that is essentially twice the effective resolution of the web site, but that your screen has enough pixel density to take advantage of. In the case on an iPad, you could very well see a higher res image than on a non-retina desktop. But keep in mind retina (and I'm using retina as a generic term for higher than 72 ppi) screens are not just confined to tablets and phones now.

Again, it is all up to the site developer to create appropriately sized assets and properly serve them up to the right viewports. If a developer doesn't generate an asset for a specific use case, you won't get it.

This has been a very real problem in web design/development and this new spec gives developers a much needed tool to make browsing experiences better across the board.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?