Re: [whatwg] The src-N proposal
On Nov 17, 2013 7:16 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 17, 2013, at 4:49 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 16, 2013, at 11:30 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This entire discussion, for months, has been entirely about syntax. I don't think I've seen a single person talk about semantics, nor do I think it would make much sense to do so. Maybe semantics is the wrong word. I feel (and others agreed on webkit-dev) that the srcset term better represents this and syntactically using a delimiter instead of multiple attributes is more tenable. The aesthetic concerns *are* personal, as it's an opinion about whether you think it looks good and is understandable or not. Some people like it, some people don't. It's not a big deal. It is a big deal. Humans need to use this for years to come. Settling on something that is polarizing is a big deal. Without starting a debate on what semantics or aesthetics mean, syntax is a big deal. A bad syntax can totally kill a feature. Completely agree. For example, this is why authors opposed srcset for anything beyond switching images based on resolution—the authors have been quite vocal about the limitations of the syntax. At this point, however, src-N appears to have the most support from authors since the picture element and has far more interest from implementors, aside from WebKit. This doesn't necessarily mean that it should be shipped as is, but considering it's easily the closest thing to a consensus we've had between the two groups I think the most constructive thing to do is not to scrap it and start all over but to work with it a bit and see how to improve on the outstanding concerns. - Tim
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
To my knowledge the only implementor who flat-out refused to implement src-N was WebKit. There is interest from Mozilla and Blink, though it did sound like Blink was considering playing follow the leader. Take care, Tim Kadlec On Fri, Nov 15, 2013 at 12:25 PM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
Re: [whatwg] Features for responsive Web design
That's actually exactly why it's better _not_ to plan for it. We can't design features for problems we don't understand. It's better to wait until we have real problems before fixing them. You may not be able to predict every future problem, but surely you need to keep it in mind as you create solutions for today, right? For example, if all it takes is one higher resolution or one more feature to come along before a solution becomes unwieldy doesn't that imply the solution isn't a particularly strong one and is instead merely a stopgap? We can't be too bold with our predictions, but we do have to build with the future in mind or else condemn ourselves to a perpetual game of catch-up. Take care, Tim - http://twitter.com/tkadlec http://timkadlec.com http://implementingresponsivedesign.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
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/ 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? Forgive me if I'm just missing something. It's early and my coffee hasn't kicked in quite yet. :) -Tim On May 16, 2012, at 4:07 AM, Odin Hørthe Omdal odi...@opera.com wrote: 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] RWD Heaven: if browsers reported device capabilities in a request header
It's only an example. My point is that the server ought to be able to ask the client for data about *any given property* and if the client is capable it should send a header back. Which allows the server to then do whatever it needs with the information. This approach makes sense to me as well. Client-side feature detection is simply not capable of solving everything. Something like this would also be very future friendly. We don't know what properties are going to be important a few years down the line. If this model is implemented carefully, it would be easy to add new properties to the mix. - Tim On Tue, Feb 7, 2012 at 3:21 PM, Matthew Wilcox m...@matthewwilcox.comwrote: I think somehow lines are getting crossed and misunderstandings are happening. For what it's worth, everyone seems to be getting hung up on screen size. It's only an example. My point is that the server ought to be able to ask the client for data about *any given property* and if the client is capable it should send a header back. Which allows the server to then do whatever it needs with the information. Screen size is one example. Bandwidth is another. It's the *communication of capabilities* that interests me at this point, The allowing of an interrogation of possibliities and adaptive responses. Whether screen-size is a good idea or not comes after. And, screen size is useful when understood to mean CSS Pixels. Because that's what a browser renders. If a device has a screen 1900px CSS px wide, you know you never need send anything larger. On 7 February 2012 20:24, Charles Pritchard ch...@jumis.com wrote: On 2/7/2012 11:52 AM, Matthew Wilcox wrote: On 7 February 2012 17:59, Boris Zbarskybzbar...@mit.edu wrote: On 2/7/12 12:32 PM, Matthew Wilcox wrote: In what circumstances might this cause breakages? Whenever the server developer makes dumb assumptions. Which they do all the time. _All_ the time. And how could it possibly lock out any devices? See my earlier example of a desktop-class touchscreen system that's shipping right now. Every single concrete proposal I've seen so far in this thread would lock it out of actually using its touch capabilities on sites that would support such capabilities fine on other devices. I don't think I have enough knowledge of the case in point to argue either way, but I'm confused how this would be the case at the moment. We already see some frustrating lockout with websites that detect mobile user agents. They forward the agent to their special mobile website, where they will often popup an alert (Please download our APP!!!) every single time you visit the page. Their mobile site is frequently crippled, limited to only a few options, and the mobile browser is often capable of viewing the full desktop site at a reasonable screen width. Now, as sites mature, they have figured out to include a Desktop Version toggle, which is a big help. It's still frustrating that there are a few steps in between. These sites make an assumption, that the screen size has something to do with device capability. The screen size has to do with how much information the viewer has decided to consume at one time. I'm frequently using browser zoom (though I use OS zoom as well), and I don't need to be forwarded to the mobile site while I'm browsing on my desktop just because I'm not wearing my glasses. That said, I do try to work with my applications so that the mobile interface is an interface that I would like to use on my desktop when I'm zoomed in. That middle ground works well for me. Now obviously it's also good for the web in various ways, if people use the information correctly and such. My faith in this is somewhat tarnished by the fact that every concrete proposal for using it that I've seen seems to be broken by design, which means that chances of anyone using it correctly are vanishingly small. Can you tell us how they're broken so we can fix it? Did you read my earlier mails with examples of devices that are shipping right now that violate the various assumptions people trying to create these device class bins are making? I don't believe we should ever use classes of device. We've been down that route, it's a fail in and of itself. We should be using actual data, not assumed data based on some other data. We have abstract means of accessibility. WCAG2 explores that. We have classes of how data is accessed. It should be accessible from a keyboard only device. With touch screens, the world has been exploring more, the concept of accessible via pointer only (though virtual keyboards help). Keep in mind that keyboard and pointer are also two abstractions, not physical objects. There's a third class of accessibility, and that's programmatic access. Ensuring that the DOM has sufficient information that
