Re: [whatwg] The src-N proposal
On Nov 17, 2013 7:16 AM, "Ryosuke Niwa" wrote: > > On Nov 17, 2013, at 4:49 AM, Timothy Hatcher wrote: > > > On Nov 16, 2013, at 11:30 AM, Tab Atkins Jr. 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] 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 wrote: > On Fri, Nov 15, 2013 at 10:25 AM, 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 wrote: > On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox > 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 write > > 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): > > > > 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 wrote:
> 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 wrote:
> > On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
> >>
> >> On 7 February 2012 17:59, Boris Zbarsky 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 min
