Re: [whatwg] Features for responsive Web design
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
wrote:
in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
The syntax allows addition of "KB" descriptor later, which — assuming UAs
will figure out how to measure actual bandwidth well enough — will allow
even more sophisticated selection based on file size (rather than only
1x/2x scale factors which are only a proxy for the file size).
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic
sizes of images.
Not actually sure what "intrinsic sizes of images" means.
A default size of the image when you don't specify any size in HTML/CSS.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
The current URI template proposal is limited. I've pointed out few cases
for which a single global set of breakpoints is not sufficient. I'd be
nice if you tried to extend the proposal to support those cases as well
(e.g. {case} → {case:category} and define breakpoints per category such as
'sidebar', 'gravatar', etc.)
And has same limitations for DPI adaptation as media>.
There are two categories of use-cases ("art-directed" and
"dpi/optimization") and is suited for only one of them, so
please don't frame the decision as "discarding" of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
This will only choose between large pixelated image and small pixelated
image, and will not make use of high display density.
I've explained it in more detail previously (using srcset as an example,
but it all applies to min-device-pixel-ratio: MQ as well)
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036051.html
--
regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think answers
>>> things well enough, nor do I think srcset does. Not for general use
>>> cases - but for specific one-off use cases, each has benefits.
>>
>>
>> Absolutely. And from what I read (and I admit not reading the entire
>> archive of messages, but still, prefer to say my piece anyway) the
>> main concern about picture was the potencial verbosity. Instead of
>> trying to solve this issue, it got discarded.
>
>
> in its current form is unable to support bandwidth-based
> negotiation well
By all accounts no solution proposed can do this. This is not a
only problem.
> (and that's not simply a matter of adding bandwidth media
> query) and has no mechanism to specify scaling factor for intrinsic sizes of
> images.
Not actually sure what "intrinsic sizes of images" means.
> IMHO those are pretty serious drawbacks that limit its functionality, which
> is much worse than "ugly, but gets job done" state of srcset.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
Should the design of the site change at any point, both solutions
break completely. It's a major problem I pointed out with
over in the CG. Srcset is no better in this regard.
> There are two categories of use-cases ("art-directed" and
> "dpi/optimization") and is suited for only one of them, so please
> don't frame the decision as "discarding" of a perfectly good solution, as it
> wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
> srcset addresses both dpi/optimisation and art-directed use-cases. It has
> its own problems, such as confusing microsyntax, so suggestions how to
> improve this are welcome.
Agreed, and already underway.
> Lamenting and accusing WHATWG of wrongdoing is not productive.
With respect, finding out where there have been fuck-ups is in
everyone's interest if we want to get the most out of the process and
communities who are all trying to better the web.
> If you'd like to see proposal succeed, then please help fixing its
> drawbacks.
I've said I don't. No part of my argument said I condone continued
argument for supporting picture - I in fact said I don't like it and
haven't liked it since it was in the CG.
> Make selection and embedding of 2x images easier.
> Give UA freedom
> to use cached higher-quality images when it can. Give UA freedom to choose
> images to minimize bandwidth or maximize quality. Reduce verbosity of most
> common cases.
>
> I've tried to raise those issues on the Responsive Images group's
> mailinglist, but got no constructive feedback.
That last bit is annoying. Some of the key players in that group seem
to ignore stuff since they decided was finished - I've had
the same problem myself.
> --
> regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Fri, 18 May 2012 20:24:00 +0100, André Luís
wrote:
Make no mistake; this is not a pride or attachment thing, this is a
knowing the reasons thing. I personally don't think answers
things well enough, nor do I think srcset does. Not for general use
cases - but for specific one-off use cases, each has benefits.
Absolutely. And from what I read (and I admit not reading the entire
archive of messages, but still, prefer to say my piece anyway) the
main concern about picture was the potencial verbosity. Instead of
trying to solve this issue, it got discarded.
in its current form is unable to support bandwidth-based
negotiation well (and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
IMHO those are pretty serious drawbacks that limit its functionality,
which is much worse than "ugly, but gets job done" state of srcset.
There are two categories of use-cases ("art-directed" and
"dpi/optimization") and is suited for only one of them, so
please don't frame the decision as "discarding" of a perfectly good
solution, as it wasn't.
srcset addresses both dpi/optimisation and art-directed use-cases. It has
its own problems, such as confusing microsyntax, so suggestions how to
improve this are welcome.
Lamenting and accusing WHATWG of wrongdoing is not productive.
If you'd like to see proposal succeed, then please help fixing
its drawbacks. Make selection and embedding of 2x images easier. Give UA
freedom to use cached higher-quality images when it can. Give UA freedom
to choose images to minimize bandwidth or maximize quality. Reduce
verbosity of most common cases.
I've tried to raise those issues on the Responsive Images group's
mailinglist, but got no constructive feedback.
--
regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On 18 May 2012 17:29, Matthew Wilcox wrote: > You have to understand that the idea was not the result of > idle thought. We went through a *lot* of thinking to reach that point, > and so it's not actually an attachement to that idea so much as *we > know* that idea inside out, what it does, what it doesn't, and why > it's like that. We had thought about it from a lot of angles, thrown > everything we could at it, and determined that was the most > robust, familiar, and flexible solution out of half a dozen > possibilities - each of which was under similar scrutiny. > > Then along comes srcset - which has not been subject to the same > scrutiny by that group. So *of course* it's getting questioned hard, > and *of course* is being held as answering the needs best. > > Until srcset has been properly discussed, inspected, picked apart, and > subjected to the same level of scrutiny as was, it's not the > trusted thing that is. > > Make no mistake; this is not a pride or attachment thing, this is a > knowing the reasons thing. I personally don't think answers > things well enough, nor do I think srcset does. Not for general use > cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. There are proposals to deal with the media-query only once to activate a specific page-global profile. It could support both ways: via media attribute in picture or source elements or via a detection made on the head. Anyway, I'll have to re-read the archive of past conversations to be able to formulate a complete proposal. But those efforts anyone of us might take need to be respectfully considered just as srcset has. And not discarded straight away. -- André Luís
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 1:54 PM, Benjamin Hawkes-Lewis < bhawkesle...@googlemail.com> wrote: > On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky wrote: > > On 5/18/12 3:16 AM, Markus Ernst wrote: > >> > >> 1. Are there other cases in HTML where an attribute value contains more > >> than one URI? > > > > > > * The "archive" attribute of (comma-separated list of URIs) > > > > * The "ping" attribute of (space-separated list of URIs) > > > > * The "style" attribute (which can, e.g., set both border-image and > > background-image). > > > > There might be others, but this is off the top of my head. > > HTML4's @profile is a whitespace-separated URI list: > > http://www.w3.org/TR/html4/struct/global.html#adef-profile > > RDFa's @property and @typeof are whitespace-separated lists of CURIEs: > not only CURIEs, they can also be full URIs. Steph. > > http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax > > http://www.w3.org/TR/rdfa-core/#s_syntax > > -- > Benjamin Hawkes-Lewis >
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky wrote: > On 5/18/12 3:16 AM, Markus Ernst wrote: >> >> 1. Are there other cases in HTML where an attribute value contains more >> than one URI? > > > * The "archive" attribute of (comma-separated list of URIs) > > * The "ping" attribute of (space-separated list of URIs) > > * The "style" attribute (which can, e.g., set both border-image and > background-image). > > There might be others, but this is off the top of my head. HTML4's @profile is a whitespace-separated URI list: http://www.w3.org/TR/html4/struct/global.html#adef-profile RDFa's @property and @typeof are whitespace-separated lists of CURIEs: http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax http://www.w3.org/TR/rdfa-core/#s_syntax -- Benjamin Hawkes-Lewis
Re: [whatwg] Features for responsive Web design
You have to understand that the idea was not the result of
idle thought. We went through a *lot* of thinking to reach that point,
and so it's not actually an attachement to that idea so much as *we
know* that idea inside out, what it does, what it doesn't, and why
it's like that. We had thought about it from a lot of angles, thrown
everything we could at it, and determined that was the most
robust, familiar, and flexible solution out of half a dozen
possibilities - each of which was under similar scrutiny.
Then along comes srcset - which has not been subject to the same
scrutiny by that group. So *of course* it's getting questioned hard,
and *of course* is being held as answering the needs best.
Until srcset has been properly discussed, inspected, picked apart, and
subjected to the same level of scrutiny as was, it's not the
trusted thing that is.
Make no mistake; this is not a pride or attachment thing, this is a
knowing the reasons thing. I personally don't think answers
things well enough, nor do I think srcset does. Not for general use
cases - but for specific one-off use cases, each has benefits.
Personally I'm coming around to a refined version of the srcset idea
rather than after some clear explanation. But, again, I only
see it being appropriate for one-off use cases - singular special-case
images within a page. I don't think anyone has yet come up with a good
enough general purpose solution that avoids contaminating the mark-up
with design-dependent properties which will all be invalid come a
re-design - that to me is not acceptable. The closest I've seen that
could possibly address that limitation is variables, but that
has it's own issues and does not answer the same use-cases as srcset
or .
-Matt
On 18 May 2012 16:40, Andy Davies wrote:
> On 18 May 2012 15:28, Glenn Maynard wrote:
>>
>> Only if there are actual problems solved by doing so, which there don't
>> seem to be. Instead, people seem to be hunting for excuses to use parts of
>> the other proposal just for the sake of using them, not to solve any actual
>> problem. ("That's not a good reason to do it? Hold on, let me try to come
>> up with another...")
>>
>
> Perhaps but I think the real problem may be this...
>
> The other proposals have been knocked around by various parties who
> wanted to solve a problem, they had time to discuss it, digest it and
> see how it grew to meet their needs.
>
> Now srcset was dropped on them as a surprise, they're still trying to
> understand it, they keep being re-assured it meets their needs but
> no-one who developed the srcset proposal has really come out and
> explained to them how it meets their needs so they keep asking
> questions...
>
> I wasn't involved in the picture discussion so have no particular
> attachment to it, I think both picture and srcset have problems in
> that they move breakpoints into the markup, srcset's "microsyntax" is
> pretty horrible and the picture syntax has issues too.
>
> The thing that really astounds me about the responsive/adaptive images
> hullabaloo is:
>
> The responsive image problem has been discussed for at least a year
> with plenty of ideas / workarounds floated around (only got to look a
> slidedecks form Mobilism, Breaking Development etc. for this) yet
> WHATWG seemed pretty unaware of it.
>
> When WHATWG did decide to do something about it they just dropped it
> on the people who wanted it by surprise without talking to them first
> even just to say "this is our proposal, this is how we think it solves
> your problem, what do you think?"
>
> I can understand why some of the "authors" are upset and I still thing
> the srcset needs explaining clearly rather than them having to chew
> through the spec.
>
> Cheers
>
> Andy
Re: [whatwg] Features for responsive Web design
On 18 May 2012 15:28, Glenn Maynard wrote:
>
> Only if there are actual problems solved by doing so, which there don't
> seem to be. Instead, people seem to be hunting for excuses to use parts of
> the other proposal just for the sake of using them, not to solve any actual
> problem. ("That's not a good reason to do it? Hold on, let me try to come
> up with another...")
>
Perhaps but I think the real problem may be this...
The other proposals have been knocked around by various parties who
wanted to solve a problem, they had time to discuss it, digest it and
see how it grew to meet their needs.
Now srcset was dropped on them as a surprise, they're still trying to
understand it, they keep being re-assured it meets their needs but
no-one who developed the srcset proposal has really come out and
explained to them how it meets their needs so they keep asking
questions...
I wasn't involved in the picture discussion so have no particular
attachment to it, I think both picture and srcset have problems in
that they move breakpoints into the markup, srcset's "microsyntax" is
pretty horrible and the picture syntax has issues too.
The thing that really astounds me about the responsive/adaptive images
hullabaloo is:
The responsive image problem has been discussed for at least a year
with plenty of ideas / workarounds floated around (only got to look a
slidedecks form Mobilism, Breaking Development etc. for this) yet
WHATWG seemed pretty unaware of it.
When WHATWG did decide to do something about it they just dropped it
on the people who wanted it by surprise without talking to them first
even just to say "this is our proposal, this is how we think it solves
your problem, what do you think?"
I can understand why some of the "authors" are upset and I still thing
the srcset needs explaining clearly rather than them having to chew
through the spec.
Cheers
Andy
[whatwg] Canvas: imageSmoothingEnabled not part of the state stack?
Looking into some of the features recently added to the canvas spec, I noticed that imageSmoothingEnabled wasn't added to the list of attributes saved and restored in the canvas state (in sec. 4.8.11.1.1). This also seems to be the case for the new line dash parameters. Intentional, or oversight? Stephen
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 5:51 AM, Julian Reschke wrote:
> ...which of course means that it stops being "simpler".
>
No, it means nothing of the sort. An API to access this would introduce
none of the problems with the multi-element approach; it would be simple
and straightforward to do.
I think it would be worthwhile to combine elements form both proposals; in
> particular to avoid the microsyntax and use proper markup instead.
>
Only if there are actual problems solved by doing so, which there don't
seem to be. Instead, people seem to be hunting for excuses to use parts of
the other proposal just for the sake of using them, not to solve any actual
problem. ("That's not a good reason to do it? Hold on, let me try to come
up with another...")
--
Glenn Maynard
Re: [whatwg] Problems with width/height descriptors in srcset
On Fri, May 18, 2012 at 2:17 AM, Markus Ernst wrote: > > > > > Is em different in these 2 elements, or is it actually rem? And whatever > answer, is it a problem or a feature? It's the same in those two, but it's not really rem - it's the initial font size, just like in Media Queries. (rem is the size of an em on the root element, which depends on style data.) Not really a feature or a bug, just a necessity. ~TJ
Re: [whatwg] Features for responsive Web design
On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The "archive" attribute of (comma-separated list of URIs) * The "ping" attribute of (space-separated list of URIs) * The "style" attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If one really wanted to, this could be handled by having .srcset be a list object, etc. Might still be a bit of a pain, of course. -Boris
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 13:09 schrieb James Graham: On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account. One use case is manipulating content in a contenteditable area, e.g. in a Rich text editor. A JS-based online editor such as TinyMCE or KTML may want to offer some kind of GUI for alternative sources. I am not sure whether this is a very important use case, as authors of online editors are usually JS experts and capable of writing complex string operations, too; but I assume the use case is at least valid.
Re: [whatwg] Bandwidth media queries
On 18 May 2012 11:17, Kornel Lesiński wrote: > I think we may be talking past each other, as I don't see how your answers > address the problems I'm trying to highlight. Indeed, I'm not debating your points - I accept that it isn't realistically achievable in HTML/CSS :) All the last comment was doing is pointing out that regardless of this, people will try to achieve the same effect using JS (and already are), and will wonder why it's not in HTML/CSS.
Re: [whatwg] Features for responsive Web design
On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account.
Re: [whatwg] Features for responsive Web design
On 2012-05-18 12:30, Maciej Stachowiak wrote: On May 18, 2012, at 3:16 AM, Markus Ernst wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). ...which of course means that it stops being "simpler". I think it would be worthwhile to combine elements form both proposals; in particular to avoid the microsyntax and use proper markup instead. Best regards, Julian
Re: [whatwg] Bandwidth media queries
I think we may be talking past each other, as I don't see how your answers address the problems I'm trying to highlight. It's not enough to say it's a hard problem. It's not going to solve itself. If you say media queries can be useful for bandwidth/quality use-cases, you need to actually specify how can they work. I'm trying to show here that MQ model is very problematic, and won't work well *even if UA has perfectly accurate bandwidth information at all times*! MQs are stateless and expected to match the same way globally, and that clashes with stateful and non-uniform nature of caches that should be taken into account. So please specifically address cases I've listed in my previous email. -- regards, Kornel On 18 maj 2012, at 10:52, Matthew Wilcox wrote: > Thanks for all the feedback everyone. > > I don't think it's going to stop people trying to do this though; > there are already write-ups for doing bandwidth detection in JS to > manipulate assets: > http://www.csskarma.com/blog/detecting-for-bandwidth/ > > Tricky problem. >> I'm not sure if that was intended to be an answer to my message: >> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036005.html >> >> I don't think that's at "decision" stage, because nobody has defined what >> options are there to decide. >> >> The options I see are not compelling: >> >> 1. let it match actual bandwidth and apply rules according to standard media >> query logic. This will suck, as the page design will flip and reload >> whenever wind blows, and cache will be wasted. >> >> 2. let it match some average or "sticky" value of bandwidth according to >> standard MQ logic. This will suck less, but still it won't make optimal use >> of cache OR bandwidth, and page may get stuck in suboptimal bandwidth (e.g. >> you catch WiFi only momentarily and get 3G browser stuck with peak value or >> vice versa). >> >> 3. Violate MQ logic and allow mixed queries on the page (e.g. if browser has >> cached image while it had high bandwidth, use the image, even if bandwidth >> has dropped since). That will allow UAs to use best quality images it can >> and eliminate redundant requests, but will create unpredictable, >> inconsistent nightmare for designers. >> >> >> That's why I think there needs to be alternative solution parallel to MQs. >> It's a shame that Respimg mailinglist is dead: >> >> http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html >> >> -- >> regards, Kornel Lesi��ski
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 3:16 AM, Markus Ernst wrote: > Am 15.05.2012 09:28 schrieb Ian Hickson: >>> srcset="face-600-...@1.jpeg 600w 200h 1x, >> face-600-...@2.jpeg 600w 200h 2x, >> face-icon.png 200w 200h"> > > Re-reading most parts of the last day's discussions, 2 questions come to my > mind that I have the impression have not been pointed out very clearly so far: > > 1. Are there other cases in HTML where an attribute value contains more than > one URI? > > 2. Have there been thoughts on the scriptability of @srcset? While sources > can be added to resp. removed from easily with standard DOM > methods, it looks to me like this would require complex string operations for > @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). Cheers, Maciej
Re: [whatwg] Features for responsive Web design
Am 15.05.2012 09:28 schrieb Ian Hickson: Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset.
Re: [whatwg] Problems with width/height descriptors in srcset
Am 17.05.2012 19:48 schrieb Tab Atkins Jr.: On Thu, May 17, 2012 at 10:27 AM, Jeremy Keith wrote: Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a "min-width:100px" approach, which is much clearer. It also lets us add "max-width", though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. or Yes, you got it. Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a "Mobile First" or "Desktop First" approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the "px" from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). No, if we're aping the CSS syntax more closely, we should just use CSS units. Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature?
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, May 18, 2012 at 6:01 PM, Bruce Lawson wrote: > On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. > wrote: > > I believe the CG rules >>> >>> would not allow an employee of a W3C Member company to be a "free agent" >>> though. > > > It appears not. I tried to join the responsive images CG as "just me" as I'm > interested, but not representing Opera, and don't like to give people the > impression that my interest or support of any suggestion means Opera will > implement it next Thursday. But I couldn't; I had to join as an Opera rep, > and get permission internally. That's time-consuming and process laden. I believe that is the case for all participation in the W3C. Unfortunately, I was not able to join a WG as a private "invited expert" and a different one as a Google representative (in my role as a Google contractor). I think that is a problem at the W3C that they don't allow you to have multiple different forms of representation per person. I even tried with different email addresses and that wasn't allowed either. Silvia.
Re: [whatwg] Problems with width/height descriptors in srcset
On 17 May 2012 18:59, Jeremy Keith wrote:
> I much prefer Tab's suggestion:
>
> > I think we should just go with a "min-width:100px" approach, which is
> much clearer.
> > It also lets us add "max-width"
>
> I'd like to add my support for this - by using a subset of media-queries
the UA can still choose the best image, whilst ambiguity is decreased ("now
is 600w a max or min?") and it has the upshot of being easier for
developers to pick up, use and debug. Seems better for pretty much everyone!
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a "free agent" though. It appears not. I tried to join the responsive images CG as "just me" as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden.
