Re: [whatwg] IRC and WWW integration proposal
On Fri, 01 Feb 2013 07:41:59 +0100, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Shane Allen sh...@snoonet.org schrieb am Thu, 31 Jan 2013 23:40:11 -0600: A protocol attribute for link elements would be totally hilarious. Not if the device is a tablet, or a phone running a browser that supports it. Need support from a page/article or even a project? Hit a button, and if the protocol is implemented, you're in the IRC channel able to garnish that support instantly. We probably misunderstood each other. Protocols are mentioned at the beginning of a URL; having a protocol attribute on a link element would therefore be redundant. To illustrate: link rel=chat protocol=irc href=irc://irc.freenode.com/whatwg Instead of: link rel=chat href=irc://irc.freenode.com/whatwg Or a more fitting example of how it could be used: a href=http://whatwg.org; protocol=httpWHATWG/a But, what happens now? a href=http://whatwg.org; protocol=mailtoWHATWG/a Hilarious :-) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Proposal for HTML5: Virtual Tours
On Fri, 31 Aug 2012 11:55:31 +0200, Leo Willner leo.will...@chello.at wrote: To throw in my 5 cents: If tour is just needed for panos we could do a pano-tag, for that we need the distorted 360°-pano-image and do a rendering of it in the browser into a 360°-pano. But it's *really* not needed. This is such a small use case, and is doable already with canvas or other web features. Advanced tours? WebGL. Less advanced ones? Canvas, - or just images, css, transitions and animations. This is really something you can easily build with existing technologies. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] input type=barcode?
On Fri, 31 Aug 2012 12:26:23 +0200, Alexandre Morgaut alexandre.morg...@4d.com wrote: Working in Web applications solutions, I would really love such input type or mode Thing is, we don't need this on the web platform until some user agent actually supports giving input by a reader (don't even have to restrict it to barcode, it can be whatever). To the website it will in fact just look like a very fast user typed in the data (or pasted it in). So this is possible to do already. input type=barcode makes very little sense imho, because what you want to input is always a number or some text. *How* you input that data shouldn't be any of the web site's business. If I want to type in the number on the barcode manually instead of scanning it, I should be allowed to do that. If the royal mail service in Norway haven't set inputmode to barcode/reader on their input type=text box for inputting tracking code, the user agent is still *totally* able (and allowed) to push in data from a barcode reader there still. Quite frankly, there is no need to spec stuff like this now, as long as it's not being used at this time. Why hint about something that doesn't exist in user agents? Right now we don't have _any_ inputmode hints at all. It's still possible to provide inputs to input fields from voice-to-text, from keyboard, from touchscreens with on-screen keyboards, pre-filling etc. Basically, there is no need to say anything about a barcode reader, if you have one in your user agent, just use it... It will work already. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński kor...@geekhood.net wrote: One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). I don't see the big problem, I think the spec is fine here. Yes it allows for putting a float there, but authors won't use it, so what's the problem? The spec already say you should use the number to calculate the correct intrinsic size, and the implementation will know what to do with a float number there if someone finds an actual use for it. This isn't limiting it for the sake of making anything easier, it's not like the x is an integer is any easier than the x is a float. And if you *do* somehow find a good use for it down the line (and I believe there might be, maybe 0.5x) it'll be there and work. No harm. :) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] [JavaScript / Web ECMAScript] Dropping the “escaped reserved words” compatibility requirement
On Thu, 05 Jul 2012 10:47:46 +0200, Mathias Bynens math...@qiwi.be wrote: Has the time come to drop this compatibility requirement? Looks like a good time, if there truly has been no compat problems with doing the change Mozilla did. We'll align and try it out. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] frame accuracy breaking case for 25fps / status of 29.97fps
On Mon, 09 Jul 2012 18:46:20 +0200, adam k li...@inconduit.com wrote: i have a 25fps video, h264, with a burned in timecode. it seems to be off by 1 frame when i compare the burned in timecode to the calculated timecode. i'm using rob coenen's test app at http://www.massive-interactive.nl/html5_video/smpte_test_universal.html to load my own video. what's the process here to report issues? please let me know whatever formal or informal steps are required and i'll gladly follow them. Well, it works beautifully in that web site you reference. What do you think is wrong actually? I'm not so sure if the spec is the first and best way to go to find the error(?) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, 16 May 2012 09:42:46 +0200, Chris Heilmann code...@gmail.com wrote: img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript So we praise the terse syntax of it and then offer a NOSCRIPT for backwards compatibility? Now that is a real step back in my opinion. Please, read Tab's full email. No need to willfully mislead people just to create a flame war like this. You know as well as we do as that the backwards compat story is: img src=foo.jpg srcset=foo.jpg 2x Extra noscript is only for a *Javascript* polyfill that will give you the behavior in current browsers. That means, only those who absolutely want switching to work with browsers not having implemented it, should use something like this. In fact, polyfilling other solutions will require the exact same, because you'd have to cater for people having Javascript turned off. However, you can also polyfill the simple version, but you would get two requests in some browsers if you do that. So you can optimize what you want. The only thing we're talking about -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Correcting some misconceptions about Responsive Images
Thank you for the well written email. On Wed, 16 May 2012 09:13:01 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: 3. @srcset doesn't have good fallback behavior. Yup, it does. The simplest way is to just do the simplest thing: provide both a @src and a @srcset, and that's it. This has good behavior in legacy UAs, and in new ones. The only downside of this is that if you're polyfilling the feature in legacy UAs, you get two requests (first the @src, then whatever the JS changes it to). If this is problematic, there's a more verbose but still simple way to handle this (afaik, first suggested by Odin): img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript It was not first suggested by me, I shopped around in the RespImg CG and on different blogs and comments and articles and picked that up somewhere along the path. I think Scott Jehl's Some early thoughts on img@srcset in the real world might be the first place I saw it: https://gist.github.com/2701939 Although he said something to the effect that plausible, but may have some issues. Hence my proof of concept *demo* of a srcset polyfill that optimizes for few requests: http://odin.s0.no/web/srcset/polyfill.htm To show that it can work. The example I'm using is: img srcset=small.png 500w, big.png 1000w style=display:none noscriptimg src=small.png alt=Alt here/noscript It'll work without javascript, only showing one alt text. With javascript on, it'll copy the alt text to the real img and take away the display:none (which is only there to hinder IE showing a broken image icon when you have no Javascript). In modern UAs, JS just has to remove the @style. In legacy UAs, JS removes the @style and sets the @src appropriately (the data: url ensures that there's not an extra request before JS activates). If JS isn't turned on, the first image just never displays, but the second one does. This is more complicated and a bit more fragile than the previous solution, but it only ever sends a single request. Yes. I have a live test for something like that. It works in all devices and browsers I've got access to. Which is not really very much, but should cater for quite a large part of the internet. (:P) It's at the same page ( http://odin.s0.no/web/srcset/polyfill.htm ). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox m...@matthewwilcox.com wrote: Am i right in believing that the srcset attribute are limited to pixels? A unit that's dying out in all responsive designs? Is it extensible to em, % etc? Because that's what's used. I'm afraid you are confusing a lot of stuff together here. You can use em and % freely in your stylesheets/CSS. The values from srcset is used to fetch the right resource during early prefetch, checked against the width and height of the viewport (and only that viewport). Having ems or % would make no sense whatsoever there, because you don't know what they mean. 50% of what? The viewport size? You would basically make it always matching. Because 50% will always be half of whatever your viewport size is... Say you writeimg srcset=mycoolpic.jpg 50%w, myotherpic.jpg 75%w If viewport is 50px wide, mycoolpic will match 25px, myotherpic will match 37.5px, so it'll pick myotherpic.jpg If viewport is 200px wide, mycoolpic will match 100px, myotherpic will match 150px, so it'll pick myotherpic.jpg If viewport is 500px wide, mycoolpic will match 250px, myotherpic will match 375px, so it'll pick myotherpic.jpg If viewport is 1000px wide, mycoolpic will match 500px, myotherpic will match 750px, so it'll pick myotherpic.jpg See the pattern? It'll always pick the one closest to 100%, no matter what. It doesn't make sense. Also note: the width of an image, and the value you write in srcset, doesn't need to have any connection at all. It's only used to match against the viewport to choose what picture the user agent will fetch. This example will make your logo a smaller mobile version when your viewport width is 600 or smaller (you should also have some media queries in your stylesheet that change the layout at that stage): img src=fallback... srcset=logo-150px.jpg, logo-50px.jpg 600w Here, the logo-50px.jpg will only be loaded if your viewport width is less than 600. It'll choose logo-150px.jpg for everything else. CSS (and the domain media queries work in), and resource fetching that works with prefetching/-loading is two totally seperate things/problems. If you make a solution that will support em/% in a meaningful way, you would have to wait for layout in order to know what size that means. So you will have slower-loading images, and ignore the we want pictures fast requirement. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] img srcset for responsive bitmapped content images
On Wed, 16 May 2012 11:22:07 +0200, Julian Reschke julian.resc...@gmx.de wrote: Inventing a new microsyntax is tricky. - comma separated implies you'll need to escape a comma when it appears in a URI; this may be a problem when the URI scheme assigns a special meaning to the comma (so it doesn't affect HTTP but still...) Indeed. Edward did not write it all as a spec, though, so cases like that might be a bit detailed for a first proposal. Hixies extension of srcset does however have some spec text, and that does in fact handle your first case: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates - separating URIs from parameters with whitespace implies that the URIs are valid (in that they do not contain whitespace themselves); I personally have no problem with that, but it should be kept in mind Me neither. I'm no big fan of non-valid URIs. :-) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] picture / img srcset not needed
On Wed, 16 May 2012 11:50:51 +0200, Matthew Wilcox m...@matthewwilcox.com wrote: So wrap an image in SVG? I don't see this as being very clean. The problems Tab pointed out are enough for it to not meet the use cases anyway. So it doesn't matter one way or the other. :-) Using SVG like this is not a suitable solution. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Tim Kadlec t...@timkadlec.com wrote: The lack of em support is a concern though I understand the complications you have brought up. Using ems for media queries (which in turn dictate layout which in turn dictates the image I want to load) is increasingly looking like a much wiser decision than using pixels. A perfect example are devices such as the Kindle Touch which have a much higher default font size. A real world example, and case study, can be found here: http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ I don't think it is fit for this round of spec. It is in direct conflict with preloading/prefetching. It's a different model and requires a different fix. Model 1, before load: do image decision, fetch image while loading the page Model 2, after load: load page, do image decision after layout srcset is using model 1, which is faster and in the same way images are done today. I don't think you'll be able to convince vendors to ditch that optimization. media queries is doing model 2. I suggest we find a way to do that with javascript. Maybe some form of deferring image loading at all, saying that I will fetch image on my own. Then you can do the delayed image loading that would need to happen in a media query world. Having a fix for model 1, doesn't hinder something for model 2 to come at a later point. Now suppose that for that layout displayed in their screenshot, the header image was changed to be a vertical oriented phone and the size was reduced. In that case, I would want srcset to kick in with a different image. It sounds like it would not be able to accomplish this right now? No, you're right about that. Or it could work in the current proposal, but I don't really think it's worth it. The spec does have an algorithm for updating the image that does a new fetch and show, but it's not required to run it. So you can't really depend on it. But it can work. If it has already fetched a bigger image, and has that in cache, it might not want to fetch a smaller one when you rotate though. Why show something of worse quality than what you already cache? If the intrinsic sizes are different, well, the user agent doesn't know that until it has downloaded the image anyway. IMHO that should rather be done with a model 2. That means, in the short term: finding a way to solve it using client side javascript. So in clear text: I don't think that should be supported by imgsrc. That's a job for a media query. Model 2. Forgive me if I'm just missing something. It's early and my coffee hasn't kicked in quite yet. :) PS: I would be very happy if you didn't top-post, and also trimmed your quotes so that it's easy to follow and read (I read email on my phone when I'm out, and I love when people write emails that work nicely on the phone). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
Henri Sivonen hsivo...@iki.fi wrote: The what's currently in the spec is terribly counter-intuitive in this regard. The spec has a bug where it is contradicting itself in some steps. That makes it very hard to read and confusing for those who read those steps. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src= are appropriate for the pixel density case. Yes, the late load (or extra load). And the early load. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset= is bad for the art-direction case and picture is bad for the pixel density case. Wll. Not too sure I agree with /all/ of that. I agree in general, but I also think that the early load model should be allowed to fetch based on viewport size straight away. If I have to choose between loading image late, when mq etc engine has started, being very flexible and loading image fast, not flexible at all, just browser magic - I'd go for the second one. Even though we want to serve small images to my mobile phone, I'd still like for it to be as fast as the browser is able to handle. But it is merely meant for different sizes of the same content image then. Only doing pixel densities feels very limiting. A bit too limiting to be useful for the non-art directed I just want it to go fast. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Oh, please do quote what you are answering. It's very hard to follow such a conversation like this. Matthew Wilcox m...@matthewwilcox.com wrote: If there was a way to do this in JS, we'd have found it. Every time we run up against the pre-fetch problem. In fact, it is only the pre-fetch problem that causes responsive images to be an issue at all. It'd be trivial to fix with JS otherwise. I could be more clear. I believe this is what you are talking about: I said: media queries is doing model 2. I suggest we find a way to do that with javascript. Maybe some form of deferring image loading at all, saying that I will fetch image on my own. Then you can do the delayed image loading that would need to happen in a media query world. When I say find a way to defer it, I mean spec a way to do it, and implement that. Something like: img defer src=blabla.jpg I understand the problem :-) Also, i don't think non-pixel based layouts can be easily dismissed. It's where the whole movement is going and already pixel based MQ are described as limited and not a best practice. ... But it doesn't work. Please read my emails, and come with constructive technical feedback on why you think it *can* in fact work. I can not see a method where that would work in an non-broken way. Technical problems won't just magically go away by not acknowlegding them. And I did find a way forward for the model 2, make a way to defer the image load and find a way to load it. Maybe picture element should always defer? It actually *has to* because it uses media queries, so in fact, picture might be a solution for model 2 in the future. But @srcset is solving the other part of the equation (model 1). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Responsive images and printing/zooming
Markus Ernst derer...@gmx.ch wrote: I read the current spec and huge parts of today's discussions to find out how images with multiple sources are intended to behave when printed, or when the page is zoomed, but I found no hints. I think some words on this might be useful in the spec, regardless of what the final syntax will be. Both issues you are highlighting is in the domain of competing browsers to implement in the best way for their users/device/intended use case. They should not, IMHO, be part of the spec. I'll tell you how I see it: 1. Print When a page is printed (or also converted to PDF or whatever), both viewport width and pixel ratio change. Are UAs expected to load the appropriate sources then? This could result in increased bandwidth, delayed printing, and IMHO a disturbed user experience, as the image may differ from the one seen on screen. Thus, I suggest to always use the resource actually shown on screen for printing. They are not _required_ to do anything when those change. The spec draft does have an algorithm for updating img elements though: The user agent may at any time run the following algorithm to update an img element's image in order to react to changes in the environment. (User agents are not required to ever run this algorithm. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates (Scoll way past the first algorithm, and you'll get to that algorithm) So it's up to the user agent to decide what to do in that case. I think it would be very nice to substitute the picture, if you can get one with a higher resolution. But it might even use the one it has in the preview, and download the big image while the user is using his time pressing options etc. Then, when the user agent has gotten the new image, it can dissolve the preview to use the new higher-res one - and also decide to use that one for the print. If it can't make the deadline (user hitting print), it can just use the one it has. Or another user agent that likes to nag its users might decide to nag the user. This is a place for quality of implementation (QoI), where browsers can compete on providing the best experience. I like it. 2. Zoom On mobile devices, web pages are often zoomed out to fit the viewport width by default, the user is supposed to manually zoom in and scroll in order to read parts of pages. I understand that the whole thing about responsive design is to make this kind of zooming unnecessary, but in practice there will be all kinds of partly responsive designs using responsive images. Specially in cases where separate sources are given to match device pixel densities, zooming might matter, as for a zoomed-out page the low res image might be more than sufficient, but after zooming in the higher resolution might be appropriate. Which OTOH can disturb the user experience, when the images differ. Yes, but you might get a quicker page load if you do the smallest one first. You can load that one and then when you're done with all the network activity, you can start a new job to download a bigger version in the background. You can substitute that one when you have it (or when the user zooms). Or the browser may choose to just load the one it wants for zoom straight away. It's decideable! If a browser does something that's ugly, the users of that browser will just have to bear with it, or switch to another one (hehe ;-) ). These are not things at a user experience level, that need to be interopable. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Problems with width/height descriptors in srcset
Jeremy Keith jer...@adactio.com wrote: If I'm taking a Mobile First approach to development, then srcset will meet my needs *if* Nw and Nh refer to min-width and min-height. In this example, I'll just use Nw to keep things simple: img src=small.png srcset=medium.png 600w, large.png 800w (Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png). Or you can do it Desktop First with the same behaviour: img src=large.png srcset=small.png 0w, medium.png 600w, large.png 800w the 0 in srcset would have to override the implict 0 that large got in src. But that should be easy. If, on the other hand, Nw and Nh refer to max-width and max-height, I *have to* take a Desktop First approach: img src=large.png srcset=medium.png 800w, small.png 600w (Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use narrow.png unless the viewport is narrower than 600 pixels, in which case use small.png). Likewise: img src=small.png srcset=medium.png 800w, small.png 600w, large.png 92000w I really admit that the 92000w looks really ugly. And if you have a viewport that is wider than 92,000 px it will choose the small.png. Maybe it should have a Infinite marker for that case. Can't think of a beautiful solution there. One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: Mobile First or Desktop First. Because the srcset syntax will support *either* min- or max- width (but not both), it will therefore favour one case at the expense of the either. But making them bigger and more verbose will make them that for every single element you're adding in @srcset. Hardly something to sing about. img src=a.jpg srcset=abc.png max-width:800, bcd.png max-width:200 max-height:200, b...@2.png max-width:200 max-height:200 density:2 vs img src=a.jpg srcset=abc.png 800w, bcd.png 200w 200h, b...@2.png 200w 200h x2 The other problem with my straw man proposal is that it kinda looks like CSS, but it isn't (max-width: 200 wouldn't work e.g.) so authors would get that wrong much more often. And... Okay, my straw man is just horrible. It'd be better if someone could come up with a real alternate proposal though? I kinda like the syntax in the spec draft, it's short and sweet. And obvious when you know. People will learn it from good documentation probable (heh) or hopefully quickly understand once they have browsers to test in. It might be hard learning all this from a spec and scattered emails - that's what spec people are used to, but not so with webdevs. Dev Opera and MDN would probably have good texts on it where people actually look stuff up. Both use-cases are valid. Personally, I happen to use the Mobile First approach, but that doesn't mean that other developers shouldn't be able to take a Desktop First approach if they want. By the same logic, I don't much like the idea of srcset forcing me to take a Desktop First approach. I am sympathetic to the idea, but right now I don't know how to. If we can't find something that's preferable (concise, easy to read etc) and can do both - I would however prefer that it put most weight on how the image tag is mostly used on the web today. And allowing sites to mobile enable their images by adding smaller images to srcset. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... Ah! What a truly great question, so simple. The answer is: no, it is not media-queries although they look like it. A big problem is that it's so easy to explain it by saying it's just like media-query max-width, rather than finding the words to illustrate that they are totally different. The *limited effect* also feels similar which doesn't help the case at all. So, even though I have a rather bad track record of explaining any thing, I'll try again: Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. :-) With mediaqueries, you don't know at the time when you're prefetching an image, what box it is in. So many media queries will either not make sense (so they won't work like authors intend them to), OR the browser would have to wait until it has layout for it to start fetching images. Neither of these two would actually be good, so they are in conflict. I'd also like to give an example on the smart uses in the future for imgsrc; right-click save could fetch the biggest quality image and save that one instead of the one it has currently fetched. Bruce Lawson bru...@opera.com skreiv Tue, 15 May 2012 23:46:44 +0200 Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) No. It only works on device-width also, and it's only a hint, so it's actually part of your part 2: 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? Yeah, sounds more like it. But it applies to the whole thing. I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. Exactly. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. It's heavily optimized for the usecase that will happen most often: for retina type displays: img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x bruce-speaking-for-myself-not-Opera I'm not speaking for Opera either, but we do work for Opera, and it's hard to disclaim everything always. I hope it made sense. -- Odin Hørthe Omdal (odinho/Velmont) · Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Silvia Pfeiffer silviapfeiff...@gmail.com skreiv Wed, 16 May 2012 00:57:48 +0200 Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. If that's the case, would it make sense to get rid of the @media attribute on source elements in video and replace it with @srcset? Video is at least a bit different in that you don't expect it to be fully loaded and prefetch at such an early stage as img. But I've been thinking about that since I read something like we already have media queries in source for video, but it's not really implemented and used yet. I'm not sure. What do you think? As far as I've seen, you're highly knowledgeable about video. Why do we have mediaqueries on video element? Do we have a use case page? Doing the same as whatever img ends up doing might be a good fit if the use cases are similar enough. Would be nice to be consistent if that makes sense. -- Odin Hørthe Omdal · odinho / Velmont · Opera Software
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
the different content images based on their set of mediaqueries. I can see a few use cases there, but they are orthogonal to what we're talking about here. I think it's something worth solving, but doing it inside srcset is not where. -- Odin Hørthe Omdal (odinho/Velmont), Core, Opera Software
Re: [whatwg] runat (or server) attribute
Just use type=text/server-js... Is that really a good idea? It seems odd to use a mime type for such a reason. I thought it was quite a nice idea. Why would it not be? It's describing what's in the script tag, just like it's supposed to do. It's even a quite much used pattern for doing client side templates script type=text/template on the web today. Mime types are not magical any more. Before we could make our own text/x-whatever, but prefixes are not really any use. If you want something specific to your program you could always use something specific as prefix, -- but for this use case just doing text/server-js seems rather nice :-) -- Odin Hørthe Omdal (odinho, Velmont)
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
Kornel Lesiński wrote: Selection of 1x/2x images is relevant only as long as we have 100dpi screens and slow connections, and both will disappear over time. Well, the web is a huge place. I'm quite sure that'll take ages and ages if it ever happens at all (I don't think it'll ever disappear). Might get irrelevant for some small and specific markets/segments though. How about that: picture source src=narrow_low-quality srcset=narrow_hi-quality 2x media=max-width:4in source src=wide_low-quality srcset=wide_hi-quality 2x img src=fallback alt=alt /picture Instead of srcset it could be src2x or another attribute that specifies image for higher screen density and/or bandwidth. The point is that media= would allow author to choose image version adapted to page layout, and another mechanism connected to source would allow UA to choose image resolution. Seeing it here in code it's actually not such a monster that I'd said it'd be. So I like it even more, and it's the obvious way for these to interact. I think it'd be a mistake to call it src2x though, -- it feels very specific. You can scale up to double then, but you can't necessarily go beyond that: going down for e.g. mobile. OTOH, 2x will be the most common usage at least as far as I can tell. img src=dog.jpg src2x=d...@2.jpg vs. img src=dog.jpg srcset=d...@2.jpg 2x is not really all that different, but the second should be more flexible. Also downscaling: img src=dog.jpg srcset=d...@2.jpg 2x, dog-lo.jpg 0.5x Actually, for this to work, the user agent needs to know the size of the standard image. So: img src=dog.jpg width=960 srcset=d...@2.jpg 2x, dog-lo.jpg 500w So if you've got the smartphone held in portrait, it's 250 css pixels wide, and so 500 real pixels, it could opt to show dog-lo.jpg rather than dog.jpg. -- Odin Hørthe Omdal, Core, Opera Software
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
Kornel Lesiński said:
Odin said:
Actually, for this to work, the user agent needs to know the size of the
standard image. So:
img src=dog.jpg width=960
srcset=d...@2.jpg 2x, dog-lo.jpg 500w
So if you've got the smartphone held in portrait, it's 250 css pixels
wide, and so 500 real pixels, it could opt to show dog-lo.jpg rather
than dog.jpg.
But still displayed at 960 CSS pixels or course? That'd be fine (and the
UA could even download dog@2x when user zooms in).
Yes, that's a good thing to pinpoint. The picture will be in a 960 CSS
pixels box, but depending on the stylesheet - maybe
img { max-width: 100%; height: auto }
It will ofc resize the backed picture down to fit that rule, when it
comes to the layout part. But yes, the picture will behave as if it is
960 px wide, only with lower dpi (resolution). Just the opposite of 2x
in fact.
All optional replacements of the src will have to be fitted in the same
box as the original src. That might actually require you to specify both
width and height upfront. Of course, people won't really do that, so I
guess we're bound to get differing behaviour... Hm.
What do people think about that? What happens here? You have no info on
the real size of the picture. I guess maybe the browser should never
load any srcset alternatives then? If you have no information at all
it's rather hard to make a judgement.
A photo gallery wants to show you a fullscreen picture, and give you:
img src=2048px.jpg srcset=4096px.jpg 2x
In this example, us (humans :P) can easily see that one is 2048 px and the
other 4096 px. If I'm viewing this on my highres Nokia N9, a naïve
implementation could pick the 2x, because it knows that's nicely highres
just like its own screen.
But it would actually be wrong! It would never need anything else than
the 2048 px for normal viewing because it is anyway exceeding its real
pixels on the screen.
--
Odin Hørthe Omdal (odinho, Velmont), Core, Opera
Re: [whatwg] [Server-Sent Events] Infinite reconnection clarification
I think I should do a TLDR since I didn't really get any answers: 1. Should EventSource *ever* time out once it has once been connected? 2. What do browsers do today? What do you think is a good thing to do? I tried Opera, Firefox and Chromium for question 2. Opera: Gives up after 2-3 minutes. Firefox: Gives up after ~15 minutes. Chromium: Doesn't ever give up. Longer and longer retry intervals, upper limit (I think) of 1 minute between each retry. And the TL version follows: On Tue, 17 Apr 2012 16:44:56 +0200, Odin Hørthe Omdal odi...@opera.com wrote: If I understand correcly, the spec expects the implementation to keep reconnecting indefinitely, when the network cable is yanked. It is a strong feeling, but it'd be nice to get it clarified in plain text in the spec. Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code. CLOSED (numeric value 2) The connection is not open, and the user agent is not trying to reconnect. Either there was a fatal error or the close() method was invoked. The task that the networking task source places on the task queue once the fetching algorithm for such a resource (with the correct MIME type) has completed must cause the user agent to asynchronously reestablish the connection. This applies whether the connection is closed gracefully or unexpectedly. It doesn't apply for the error conditions listed below. And this is the place a small clarification could come in handy: Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. Maybe Network errors after a successfully established connection must cause the user agent to try reestablishing the connection indefinitely. Or something better. At least, make it clear what is going to happen. :-) On that note, it'd also be nice to hear what the other vendors do with the connection. It seems like both Firefox and Chromium has an exponential fallback with a max-value between the reconnection tries. The first tries will probably respect the given *reconnection time*, but after a while that'll be too often. I tried yanking the network for 10+ minutes, and when I put the cable in again, both Firefox and Chromium used 25 seconds to reconnect. When only yanking it for one minute, the reconnection was much faster (2-5 seconds). This with *reconnection time* set to 500ms. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Thu, 08 Mar 2012 12:50:41 +0100, Ingar Mæhlum Arntzen ingar.arnt...@gmail.com wrote: Here's my reasoning. The progress value that is visualized in the video element (i.e. currentTime) is part of the end-user experience. For this reason it is important that it communicates the appropriate abstraction consistently to all end-users. Ah, but that is up to the user agent to decide how to show the time code. The currentTime should be normalized from 0 until duration. That makes the API behave in a common way for all easy tasks. If you write a video player for your small cat clip, that video player will also work with streaming video without any problem. That is a good thing. However, the user agent is free to show you (the user) your real position. And I agree that doing that makes sense. They don't exclude eachother. Maybe joinTime or some other property could be added to hold that information (which Chromium appears to lack - according to Sean O'Halpins comments). Alternatively, to match you suggestion, if it is the sum (startTime + currentTime) that is visualilzed in the video element, that might be OK too, but possibly more phrone to confusion? Only video player authors will actually see and use those attributes. They should be built for being robust and working nicely for different usages. Like I said, making the dumb video player also work for live streamed video without any changes. If you want to do a more advanced media player that is live video streaming aware, you will have to opt-in to that instead. All the same is possible, only one way is more backward-proof than the other. Philip Jägenstedt proposed offsetTime for what we've called startTime, which IMHO is a clearer name. In addition, I wonder if negative values for currentTime are legal. For instance, when streaming a Formula 1 race that starts at 17.00, I would not be surprised to see negative currentTime if I join the stream before the race starts. They are not, and shouldn't be. currentTime is always normalized to 0 - duration. However, you would be perfectly able to write a video player that does that by using offsetTime and currentTime together. Even better, the proposed currentDate exposes the underlying date of recording (or similar date) of the media, which you can then just look for 2012-03-08 17:00. Actually, you could also build your video player to show that date on-screen, because 17:00 on the screen might be 18:13 at my place, because a) I'm in a different time zone, and b) there's 13 minutes worth of buffering between the Formula 1 production cameras and my computer. -- Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
[whatwg] [media] startOffsetTime, also add startTime?
startOffsetTime seem to leave people confused, I often have to explain it, and yesterday I read the spec[5] and old emails and got confused myself. It hasn't been implemented after almost 2 years. Having the UTC time of the clip you're getting would be very useful. But it'd be really nice to get the start of the non-normalized timestamp exposed to javascript for synchronizing out-of-band metadata with the live streamed media. Browsers are currently supposed to take the timestamp and normalize it to 0 for currentTime. Chromium currently does not do that; it starts at 3:15, if I join a streamed video that I started streaming 3 minutes, 15 seconds ago. I don't think using the UTC time as the sync point is very stable at the moment. It'd be a much quicker, stable, and easier win to get a startTime, timelineStartTime or timeSinceStart or similar that exposes the NON-normalized timestamp value at the start of the stream. So that, if you do startTime + currentTime you're able to get the actual timestamp that the stream is at, at that point. And in contrast with startOffsetTime this one won't ever change, so startTime + currentTime will always be continuously increasing. The Date UTC which startOffsetTime would use, seems to be varying quite a bit. You need to know your streaming server and what it does in order to understand the result. Even different media from the same server might give different results if the streaming server implementation just reads the UTC time directly from the file. The information could be useful, but for more advanced uses. startOffsetTime and initialTime came out of this conversation in 2010: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/thread.html#26342 And introduced here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028004.html Sean O'Halpin of BBC recently mentioned[2] some of the confusion: There seems to be some confusion here in how the HTML5 media elements specification is dealing with logical stream addressing versus physical stream addressing. The excerpt above talks about a user agent being able to seek to an earlier point than the first frame originally provided by the server but does not explain how this could possibly happen without communication back to the server, in which case we are effectively dealing with a request for a different physical resource. At the very least, the fact that the Firefox and Chrome teams came up with different interpretations shows that this part of the specification would benefit from clarification. And an earlier blog post about startOffsetTime specifically[3]: The reason for setting this out is that we'd like to see consistent support for startOffsetTime across all commonly used codecs and for browser vendors to bring their implementations into line with the published HTML5 media elements specification. There are ambiguities in the specification itself, such as the interpretation of 'earliest seekable position', which could be clarified, especially with respect to continuous live streaming media. Browser vendors need to agree on a common interpretation of attributes such as currentTime so others can experiment with the exciting possibilities this new technology is opening up. Sooo... It would be nice to get some real cleanups to the whole media + time thing. :D 1. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#offsets-into-the-media-resource 2. http://www.bbc.co.uk/blogs/researchanddevelopment/2012/02/what-does-currenttime-mean-in.shtml 3. http://www.bbc.co.uk/blogs/researchanddevelopment/2012/01/implementing-startoffsettime-f.shtml -- Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Thu, 06 Oct 2011 17:05:29 +0200, Adam Barth w...@adambarth.com wrote: The reason it's implemented like that is because I didn't add any new security checks. I just expanded the canvas taint-checking code to understand that a CORS-approved image could pass. Ok, so not really intended then. Good :-) w.r.t. to blocking the whole image, there isn't any security benefit for doing so (if we did so, attackers would just omit the crossorigin attribute). If you want to prevent folks from embedding the image, you need something that works regardless of how the image was requested (like From-Origin). Well. I could, as server operator, block everything that didn't have an Origin-attribute. It wouldn't work then for browsing normal pages on your own, but maybe for a special api of some such. Anyway, that was really never my concern; the whole reason for actually having a crossorigin-attribute on the image would be because you want to get that extra check so you can be able to use it like you want. With WebKit now, if I built such an application, I wouldn't have any nice and obvious method of knowing whether I really could use the picture or not. Throwing an error on the image on the other hand makes it fail early, before I do all the canvas-processing. Since the crossOrigin attribute exist, it'd make sense to have it behave as a real way for you to say «I'm going to use this and I need an explicit allowance». Right now, the attribute doesn't really do anything from the author's point of view. It /may/ make an untainted image, or it might not. It's obviously different from always making tainted images (like not using the attribute would), but I think the whole reason why someone would go to the extra trouble of adding «crossOrigin» is if they really want an untainted image. If they don't care about tainting, and just really want the picture, they can refrain from setting the crossOrigin attribute. If they actually want a fallback, they can easily just reload the picture without crossorigin, and they will probably get the cached image directly from the browser (because it already has it, only won't show it). Obviously, if there hadn't been a crossOrigin-attribute, this would be the nice way to handle all image fetching. -- Odin Hørthe Omdal, Opera Software
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Thu, 06 Oct 2011 18:11:54 +0200, Adam Barth w...@adambarth.com wrote: If they actually want a fallback, they can easily just reload the picture without crossorigin, and they will probably get the cached image directly from the browser (because it already has it, only won't show it). Obviously, if there hadn't been a crossOrigin-attribute, this would be the nice way to handle all image fetching. It sounds like you're arguing that it's better for developers if we fail fast and hard, which is the opposite of how most of the web platform is design (vis HTML versus XML). The arguments revolving around wishful thinking about how the world should have been don't carry much weight for me. Well, you're violating the specification. And this is something quite different from XML versus HTML. And also, we're doing the same on XHR. If you set xhr.withCredentials and the server do allow your origin, but doesn't allow credentials, you just don't send a request without credentials and hope the author doesn't see it. That will throw an error. For new stuff like this, there's no reason being loose. If something doesn't work in any browser at all, they will fix it, if it works in one, but not any other they will think all the other browsers are doing something wrong. In the spec, you'll get notified that your picture won't be tainted, -- in WebKit's implementation it will just crash when you really try. Anyway, for my part we could've just not had the crossorigin attribute at all, and just send Origin-header to all cross-origin images. But then everyone needs to do the same thing, and it would apparently also break some sites ( http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032212.html ). -- Odin
[whatwg] [CORS] WebKit tainting image instead of throwing error
If the CORS-check did not succeed on img src=http://crossorigin.example.net crossorigin, this should happen according to spec: Discard all fetched data and prevent any tasks from the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. If a CORS resource sharing check failed, the user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console). http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch In this scenario an author wanting to do some canvas processing with the image, will be able to check img.onerror to see whether she can use that image. The image won't load on a failed check. Gecko does this. WebKit, on the other hand, only taints the image and loads it anyway, breaking the spec. The error will instead crop up in a way that is more verbose and harder to miss when she tries to read the image data out. Is WebKit's method a lesser surprise than the image just not showing up (if they don't check for thrown error)? It'd be nice to hear why it's implemented like that, if there are any good reasons. WebKit's method seemed most obvious to me at first, but after investigating a bit I'm not sure anymore... -- Odin Hørthe Omdal Core QA, Opera Software
