Most discussion so far seems to be bikeshedding the syntax. To make this
more productive, can we focus on the core issues?
srcN brings two things to the table, compared to srcset:
1. It handles viewport-switching better (easier to author, avoids
repetition of image urls, allows bandwidth-driven
, and yet you can't afford to wait till layout to know the
dimensions.
On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson d...@apple.com wrote:
On 5 Nov 2013, at 9:55 am, Timothy Hatcher timo...@apple.com wrote:
On Nov 5, 2013, at 2:18 AM, John Mellor joh...@chromium.org wrote:
img srcset=(min-width
...@webkit.org
wrote:
On 11/6/13, 10:53 AM, John Mellor wrote:
Unfortunately, responsive images is a deceptively complex problem. There
are 3 main use cases:
1. dpr-switching: fixed-width image resolution based on devicePixelRatio.
2. viewport-switching: flexible-width image resolution based
On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
99 is a very high upper bound while it would still allow us to implement
the optimization we're thinking of.
I'm of the opinion that we should use exactly one attribute for this
feature.
The thing is, srcN isn't a list,
On Wed, Jul 11, 2012 at 4:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 11, 2012 8:43 AM, John Mellor joh...@chromium.org wrote:
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
What's the point of adding this comment when the URL contains all the
information
On Fri, Jul 6, 2012 at 11:49 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 6, 2012 3:16 PM, Per Bothner per.both...@oracle.com wrote:
On 07/06/2012 02:02 PM, Ryosuke Niwa wrote:
On Fri, Jul 6, 2012 at 12:54 PM, Per Bothner per.both...@oracle.com
wrote:
You're deluding yourself if you
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
Even obvious (to some) concepts like InlineBox have subtleties, for
example not all inline-level elements have inline boxes. An unambiguous
class
and CSS device units.
Once that patch lands, I'll start to unwind the complexity introduced
by the feature.
Thanks,
Adam
On Wed, May 30, 2012 at 7:57 PM, Maciej Stachowiak m...@apple.com wrote:
On May 30, 2012, at 4:24 PM, John Mellor joh...@chromium.org wrote:
Maciej Stachowiak wrote
Adam's suggestions all sound sensible (making deviceScaleFactor based only
on the physical device, deleting defultDeviceScaleFactor, and adding
effectiveDeviceScaleFactor).
Adam Barth wrote:
It's unclear to me how Page::effectiveDeviceScaleFactor
should react when the underlying physical device
,
John
[1]: http://webkit.org/b/FontBoosting
On Thu, Apr 19, 2012 at 2:02 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
I think it would be great to talk about this at the WebKit summit
tomorrow, if you are there.
Cheers
Kenneth
On Tue, Apr 17, 2012 at 10:17 PM, John
Both Chrome for Android and the legacy Android Browser do what Hugo
described, i.e. we default to a width=device-width viewport* when an
XHTML-MP doctype is provided.
And as suggested in wkbug.com/55874, we similarly default to a
width=device-width viewport if a legacy HandheldFriendly meta tag
Hi webkit-dev,
You may have heard http://youtu.be/aCdZIHBbRV0?t=1m26s that Chrome for
Android includes a Font Boosting feature. This is similar in intent to
the text size
12 matches
Mail list logo
