[webkit-dev] Feature announcement: Font Boosting

Hi webkit-dev, You may have heard that Chrome for Android includes a "Font Boosting" feature. This is similar in intent to the text size adjust

Re: [webkit-dev] Default viewport value on WAP DTDs

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 is

Re: [webkit-dev] Feature announcement: Font Boosting

; Cheers > Kenneth > > > On Tue, Apr 17, 2012 at 10:17 PM, John Mellor wrote: > >> 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 in

Re: [webkit-dev] Device and page scaling

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 devic

Re: [webkit-dev] Device and page scaling

undled with Android, but folks appear willing to deprecate the > feature and to migrate those apps to using other mechanisms, such as > responsive images and CSS device units. > > Once that patch lands, I'll start to unwind the complexity introduced > by the feature. > > Thanks, &

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Fri, Jul 6, 2012 at 11:49 PM, Ryosuke Niwa wrote: > On Jul 6, 2012 3:16 PM, "Per Bothner" wrote: > > On 07/06/2012 02:02 PM, Ryosuke Niwa wrote: > >> On Fri, Jul 6, 2012 at 12:54 PM, Per Bothner > wrote: > >>> You're deluding yourself if you think the code (or any code this > >>> large and c

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa wrote: > On Wed, Jul 11, 2012 at 6:54 AM, John Mellor wrote: >> >> Even obvious (to some) concepts like InlineBox have subtleties, for >> example not all inline-level elements have inline boxes. An unambiguous >> class-le

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Wed, Jul 11, 2012 at 4:53 PM, Ryosuke Niwa wrote: > > On Jul 11, 2012 8:43 AM, "John Mellor" wrote: > > > > On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa wrote: > >> > >> What's the point of adding this comment when the URL contains

Re: [webkit-dev] The SrcN responsive images proposal

On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa 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, it's a list

Re: [webkit-dev] The SrcN responsive images proposal

, 'l.jpg' 640) For video, people should just do adaptive streaming using Media Source Extensions/DASH/HLS. It's only for images that the quality of the first frame is crucial, and yet you can't afford to wait till layout to know the dimensions. On Wed, Nov 6, 2013 at 5:39

Re: [webkit-dev] The SrcN responsive images proposal

ntation encourages line breaks, that could be fine... > (...) > > Regards, > Maciej > On Wed, Nov 6, 2013 at 10:33 PM, Benjamin Poulain wrote: > On 11/6/13, 10:53 AM, John Mellor wrote: > >> Unfortunately, responsive images is a deceptively complex problem. There >

Re: [webkit-dev] The SrcN responsive images proposal

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 de