[webkit-dev] Feature announcement: Font Boosting

[John Mellor]

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 
adjustfeature
in Mobile Safari, that the QT port also seems
interested in . Other mobile browsers have
corresponding features: Mobile Firefox uses font
inflationand IE Mobile
applies text
size 
adjustment
.

Font Boosting increases the font size in wide blocks, so that you can
easily read the text after double-tapping to fit the block to the screen,
instead of having to zoom in further then scroll from side to side for each
line you read.

The details are subtle (since web text layout is complicated), and there's
still a lot of tweaking to do. We chose to boost font sizes more than
Mobile Safari (which has various limits), producing easily legible text,
more in line with IE Mobile and Firefox Mobile.

This is core functionality for mobile browsers, so we would like to
upstream our implementation of Font Boosting to WebCore. We are keen to
share code with other ports (e.g. QT and Mobile Safari) that are interested
in this feature, and will be happy to incorporate suggestions on how to
make this easier.

I've opened webkit.org/b/84186 to track this effort.

Best wishes,
John
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[John Mellor]

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
present, e.g.:



and if a legacy MobileOptimized meta tag is present then we will use a
viewport with the width provided, e.g. if the following tag is present:



we will treat that the same as a "width=240" viewport tag (though IIRC the
legacy Android Browser ignored the provided width and just treated it as
device-width).

However note that we give these implicit viewport declarations lower
priority than actual viewport meta tags, so irrespective of the order they
appear in the document, a viewport meta tag will override any behaviour we
infer from the doctype or those legacy meta tags.

We do all this because some number of legacy sites depend on this
behaviour. I'm afraid we don't know how common these sites still are; but
these heuristics have never seemed to cause us any problems.

It makes sense to propose standardizing the XHTML-MP behaviour on www-style
since I agree with Kenneth that this is something that should be covered by
the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
good place to try and standardize how we deal with legacy mobile meta tags.
And we'd be happy to see any of these heuristics incorporated into
WebKit (either before or after they get standardized) so we don't need to
fork them.

Cheers,
John

*: (unlike Hugo's current patch, we don't add "initial-scale=1.0,
user-scalable=no", just "width=device-width", since there doesn't seem to
be any reason to assume that XHTML-MP sites want to disable zooming, and it
may actually lead to a worse user experience).

On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> Hi there,
>
> On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai  wrote:
> > I see. That's unfortunate. I don't really know the best path forward
> here.
> > I'm inclined to agree with Alexey that we should at least try to
> standardize
> > this before committing code. It's not clear to me where this should be
> > specced. Easiest path forward is to make this proposal to both
> > wha...@whatwg.org for the HTML spec and www-st...@w3.org for the CSS
> Device
> > Adaptation spec.
>
> I will pass it by the CSS Device Adaptation spec first as I really
> think it fits there.
>
> > We'll see what the response there is and can decide what to do next based
> > off that response. Does that sound OK?
>
> I think we will add a feature flag for now, together with layout tests
> for a document with XHTML-MP doctype using and not using fixed
> layouting.
>
> > I'm reluctant to make a change like this, but it sounds like there might
> not
> > be a better choice. One concern I have is how many sites would break due
> to
> > this behavior? For example, will this fix sites on N9, but break them on
> > Android/iOS or are these wapforum doctypes never sent to Android/iOS
> because
> > of UA-sniffing?
>
> It can only break browsers respecting the viewport meta and using
> fixed layouting in some way, those currently mobile browsers. As far
> as I heard Android and iOS are using similar tricks but they seldom
> get the pages due to UA sniffing. I already tried contacting the
> Android team.
>
> Cheers,
> Kenneth
> > On Fri, May 4, 2012 at 3:39 PM, Kenneth Rohde Christiansen
> >  wrote:
> >>
> >> Nokia actually looked into this about a year ago and we homogenized
> >> our UA strings across our different devices, so that we could start to
> >> tell contents providers to give us the best content supported by our
> >> browsers. Part of this work was actually simplifying our UA string so
> >> much as possible and it is actually quite similar to what you are
> >> using today.
> >>
> >> The user agent for the N9 browser, for instance, is:
> >>
> >> Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
> >> NokiaBrowser/8.5.0 Mobile Safari/534.13
> >>
> >> The problem is not just the user agent. For instance the user agent is
> >> known by your Google, and we did pass validation for Tier 1 YouTube
> >> content, but the Google search team, as far as I heard, decided that
> >> we didn't have enough market penetration for them to turn on Tier 1
> >> content for us, and serves us the XHTML-MP (Tier 3?) content instead.
> >>
> >> As far as I understand, the decision comes from that team not wanting
> >> to dedicate resources to make sure the Tier 1 content keeps working on
> >> our device. I totally understand their reasoning and decision, but it
> >> is a saddens me given the promise of the open web and HTML5. It is
> >> even more sad that this is not a unique case and it will only be
> >> solved the day content providers stop looking at the user agent
> >> strings.
> >>
> >> Kenneth
> >>
> >> On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai

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

[John Mellor]

> I think it would be great to talk about this at the WebKit summit
tomorrow, if you are there.

Unfortunately I wasn't able to make the WebKit summit, but beverloo
mentioned that you were able to chat a little. I'm happy to discuss further
by email or otherwise :)

For those who aren't following the bug, I've uploaded the full diff[1] of
Chrome for Android's current Font Boosting implementation (not for review,
just for reference to show how it fits together). And I've uploaded the
first actual patch (adding compile/runtime flags) to webkit.org/b/87394,
which is now up for review.

Cheers,
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 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 intent to
>> the text size 
>> adjust<http://developer.apple.com/library/ios/DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html#//apple_ref/doc/uid/TP40006510-SW16>feature
>>  in Mobile Safari, that the QT port also seems
>> interested in <http://webkit.org/b/73546>. Other mobile browsers have
>> corresponding features: Mobile Firefox uses font 
>> inflation<http://dbaron.org/log/2026-font-inflation>and IE Mobile 
>> applies text
>> size 
>> adjustment<http://msdn.microsoft.com/en-us/library/ff462082(v=vs.92).aspx#sectionToggle2>
>> .
>>
>> Font Boosting increases the font size in wide blocks, so that you can
>> easily read the text after double-tapping to fit the block to the screen,
>> instead of having to zoom in further then scroll from side to side for each
>> line you read.
>>
>> The details are subtle (since web text layout is complicated), and
>> there's still a lot of tweaking to do. We chose to boost font sizes more
>> than Mobile Safari (which has various limits), producing easily legible
>> text, more in line with IE Mobile and Firefox Mobile.
>>
>> This is core functionality for mobile browsers, so we would like to
>> upstream our implementation of Font Boosting to WebCore. We are keen to
>> share code with other ports (e.g. QT and Mobile Safari) that are interested
>> in this feature, and will be happy to incorporate suggestions on how to
>> make this easier.
>>
>> I've opened webkit.org/b/84186 to track this effort.
>>
>> Best wishes,
>> John
>>
>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer
> Nokia Mobile Phones, Browser / WebKit team
> Phone  +45 4093 0598 / E-mail kenneth at webkit. <http://gmail.com>org
>
> http://codeposts.blogspot.com ﹆﹆﹆
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Device and page scaling

[John Mellor]

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 changes its scaling
> factor.

We should just recompute it by calling dispatchViewportPropertiesDidChange
on the ChromeClient.

Dana Jansens wrote:
> The other difference between ports or platforms is how
> deviceScaleFactor is applied. It can be applied by being multiplied
> into pageScaleFactor, or it could be applied separately as a
> post-processing/compositing property, or potentially other ways. Did
> you have thoughts on that? You say pageScaleFactor is unchanged,
> but I think it would be nice to separate these two things more
> distinctly, then combine them more explicitly where appropriate.

It doesn't make sense to always scale output by deviceScaleFactor (for
example when viewing a desktop page on mobile the deviceScaleFactor isn't
really relevant). Instead it's primary purpose is just as input to the
computeViewportAttributes calculation to help resolve the meaning of
device-width, through which it affects the default pageScaleFactor. And
this way you only have one real scale factor to worry about:
pageScaleFactor, which always gives you the ratio of screen to CSS pixels.

Maciej Stachowiak wrote:
> Can you explain why the target-densitydpi feature even exists? It
> seems ill-conceived to me, and the most straightforward fix would
> be to remove it. I have not heard anyone explain the use case for
> it. (I'm also not clear on the details of what it actually does, and
> neither the name nor the docs are enlightening.)

Designers who insist on pixel-perfect rendering can use
"width=device-width, target-densityDpi=device-dpi" to make their site
render at one CSS pixel per screen pixel, letting you get crisp non-scaled
borders etc. It does however require the designer to manually adjust
dimensions and font-sizes to compensate for the dpi using
window.devicePixelRatio, which is incredibly onerous (especially in a
cross-platform design, which must look the same on devices that don't
support target-densityDpi, hence everything needs to be implemented twice).

That's the main use case, though it's pretty niche (if you want
pixel-perfect UI, it's generally less hassle to just use high resolution
images and scale them down). The other values I don't know of any
compelling use cases for; I'll talk to the engineer who first added this
and see if they have any good ones.

I don't know whether or not we can remove it (would need to check how
popular it is), but it might be possible to deprecate it (recommend against
using it). That's probably something we should discuss on www-style rather
than here.

Cheers,
John

On Wed, May 30, 2012 at 8:08 AM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> Hi,
>
> I don't think we are doing that much differently.
>
> Desktop Safari is scaling directly in WebCore using the
> pageScaleFactor whereas Qt like iOS scales outside of WebCore (using a
> tiled backing store), resulting in the FrameView not being in UI
> pixels.
>
> devicePixelRatio currently can become 1 on some viewport meta tag
> cases in Qt (/Chromium), but I am already convinced that we should
> remove the code doing this, which would basically solve most of our
> differences in behavior.
>
> Cheers,
> Kenneth
>
>
> On Wed, May 30, 2012 at 8:17 AM, Simon Fraser 
> wrote:
> > On May 29, 2012, at 7:31 PM, Alexandre Elias wrote:
> >
> >> Thanks for looking into this, I like this naming scheme and Chrome for
> Android would be willing to switch to it.
> >>
> >> Another major semantic question is how deviceScaleFactor relates to the
> FrameView viewport size.  Currently on Chrome for Android and Qt ports, the
> viewport is just the physical pixel size, whereas on ChromeOS it's
> pre-divided by deviceScaleFactor (passed in that way by the embedder -- the
> whole UI is device-scale-independent there).
> >>
> >> I don't know what the Mac Safari port does and would be very interested
> to hear.  If the Mac port behaves like ChromeOS here and there is no
> intention to switch to the other approach, we may unfortunately have to
> introduce yet another variable to represent the split in behaviors;
> otherwise ChromeOS can adjust its viewport size to converge with all other
> ports.
> >
> > On Mac and iOS, deviceScaleFactor exactly matches
> window.devicePixelRatio, and is simply a measure of how many physical
> pixels correspond to each "UI" pixel on the device: 1 for normal displays,
> and 2 for Retina displays on relevant iOS devices. Theoretically these
> could change if a window moves between displays, but are independent of
> user scaling.
> >
> > All FrameView/viewport sizes etc are in "UI" pixels, and are not
> affected by deviceScaleFactor. This sounds like the ChromeOS way, which is
> prefera

Re: [webkit-dev] Device and page scaling

[John Mellor]

> 1) automatically scaling content to the AutoValue (ie 160) DPI, which is
what most mobile optimized sites do

All WebKit-based mobile browsers I've met do target-densityDpi=auto by
default, and resolve auto as 160 (and if they don't use 160, they probably
have good reasons for it like expecting the device to be used at unusually
short or long reading distances -- see wkbug.com/88114 -- in which case the
web page should generally respect that). So there should be no need to
specify this explicitly.

> 2) allowing the user to have pixel perfect rendering on a given device.

Yes, this is the main use case the feature had in mind. Though it's a lot
of work to actually use as you have to then manually multiply all your font
sizes, dimensions, etc by window.devicePixelRatio (and in practice you need
to maintain a completely different set of css for browsers which don't
support target-densityDpi). Is there significant value-add over what you
can achieve with high resolution images (srcset, image-set) and device
units in CSS / subpixel rendering?

Cheers,
John

On Fri, Jun 1, 2012 at 5:15 PM, Konrad Piascik  wrote:

> Reposting comment from Bug 88047
>
> After discussing this internally we believe that while the current
> implementation of target-densitydpi is not ideal it's ability to allow you
> scale your viewport to a given target density as well as to allow you to
> not scale (deviceDPI) are both desired features of this API that we'd like
> to have available to developers.
>
> This is useful for 2 cases:
> 1) automatically scaling content to the AutoValue (ie 160) DPI, which is
> what most mobile optimized sites do
> 2) allowing the user to have pixel perfect rendering on a given device.
>
> -Konrad
> 
> From: webkit-dev-boun...@lists.webkit.org [
> webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth [
> aba...@webkit.org]
> Sent: Friday, June 01, 2012 2:21 AM
> To: Maciej Stachowiak
> Cc: kenn...@webkit.org; webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Device and page scaling
>
> I've posted a patch to remove target-densitydpi:
>
> https://bugs.webkit.org/show_bug.cgi?id=88047
>
> There's some concern that target-densitydpi is used by some apps that
> are bundled 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,
> Adam
>
>
> On Wed, May 30, 2012 at 7:57 PM, Maciej Stachowiak  wrote:
> >
> > On May 30, 2012, at 4:24 PM, John Mellor  wrote:
> >
> >>
> >> Maciej Stachowiak wrote:
> >> > Can you explain why the target-densitydpi feature even exists? It
> >> > seems ill-conceived to me, and the most straightforward fix would
> >> > be to remove it. I have not heard anyone explain the use case for
> >> > it. (I'm also not clear on the details of what it actually does, and
> >> > neither the name nor the docs are enlightening.)
> >>
> >> Designers who insist on pixel-perfect rendering can use
> "width=device-width, target-densityDpi=device-dpi" to make their site
> render at one CSS pixel per screen pixel, letting you get crisp non-scaled
> borders etc. It does however require the designer to manually adjust
> dimensions and font-sizes to compensate for the dpi using
> window.devicePixelRatio, which is incredibly onerous (especially in a
> cross-platform design, which must look the same on devices that don't
> support target-densityDpi, hence everything needs to be implemented twice).
> >>
> >> That's the main use case, though it's pretty niche (if you want
> pixel-perfect UI, it's generally less hassle to just use high resolution
> images and scale them down). The other values I don't know of any
> compelling use cases for; I'll talk to the engineer who first added this
> and see if they have any good ones.
> >
> > It seems to me that you could better address this use case by supporting
> fractional CSS pixels, which hopefully our new subpixel layout code can
> enable. The tricky thing about "target-densityDpi=device-dpi" is that it
> forces you to sniff the device pixel ratio and change pretty much all your
> layout based on it. If historically it would actually alter what is
> reported for devicePixelRatio, then it would be pretty hard to make a site
> design that looks right on both 1x and 2x devices with
> "target-densityDpi=device-dpi. So I'm skeptical that anyone has made good
> use of it.
> &

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

[John Mellor]

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 complicated) is or can be self-evident.
>
>>
>
>> That's a pretty strong claim. I find that the vast majority of codebase
>
>> to be quite self-evident.
>
>
>
> If you (who I gather has quite a bit of WebKit experience) find something
>
> self-evident, does not mean it is is.
>
> To be fair, as I said, I was able to read WebKit code without much trouble
> 2-3 months into my internship. I'm not sympathetic to people who can't read
> code as well as an undergraduate college student.
>
> Also, we need require some kind of prior knowledge of things. For example,
> InlineBox might be a foreign concept to you but it's plain dead obvious for
> anyone who has read CSS2.1 specifications.
>
> Similarly, there might be some classes that are self-explanatory for
> someone who knows ES5 well and confusing for someone who is not.
>
> Where should we draw a line then?
>
Even obvious (to some) concepts like InlineBox have subtleties, for example
not all inline-level elements have inline boxes. An unambiguous class-level
comment could make this clearer, for example:

// An inline box represents a rectangle that occurs on a line,
corresponding to
// all or part of some RenderObject. It must be inline-level and its
contents
// must participate in its containing inline formatting context. For
example a
// non-replaced element with a 'display' value of 'inline' generates an
inline
// box, as does an anonymous inline element (text directly contained inside
a
// block container element, not inside an inline element). But atomic
// inline-level boxes (such as replaced inline-level elements, inline-block
// elements, inline-table elements, and ruby elements) are not inline boxes
// since they participate in their inline formatting context as a single
// opaque box; these are handled by .
// http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#inline-boxes

Some may find that too verbose. But at least a link to the relevant part of
the spec would be a good start...
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

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-level comment could make this clearer, for example:
>>
>> // An inline box represents a rectangle that occurs on a line,
>> corresponding to
>> // all or part of some RenderObject. It must be inline-level and its
>> contents
>> // must participate in its containing inline formatting context. For
>> example a
>> // non-replaced element with a 'display' value of 'inline' generates an
>> inline
>> // box, as does an anonymous inline element (text directly contained
>> inside a
>> // block container element, not inside an inline element). But atomic
>> // inline-level boxes (such as replaced inline-level elements,
>> inline-block
>> // elements, inline-table elements, and ruby elements) are not inline
>> boxes
>> // since they participate in their inline formatting context as a single
>> // opaque box; these are handled by .
>> // http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#inline-boxes
>>
>
> What's the point of adding this comment when the URL contains all the
> information?  All we need is the URL.  If anything, we should be describing
> the difference between the inline boxes in CSS2.1 and our implementation
> instead.
>

That would be great! I agree that there's probably limited value in just
copy/pasting from specs like I did. Linking to the spec something is based
on and describing the differences would add a lot of value.


> Also, with that argument, we can start adding a WHOLE bunch of comments to
> WebCore like what DOM node is, and what "mutation" means, what "content
> attribute" is, etc... But we don't do that because we expect people to have
> some domain-specific knowledge. Of course, I'm not opposed to adding
> reference URLs as necessary since that'll be actually useful for
> some obscure concepts.
>
> - Ryosuke
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

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 all the
> information?  All we need is the URL.  If anything, we should be describing
> the difference between the inline boxes in CSS2.1 and our implementation
> instead.
> >
> > That would be great! I agree that there's probably limited value in just
> copy/pasting from specs like I did. Linking to the spec something is based
> on and describing the differences would add a lot of value.
>
> The problem is that we'll then incur the maintenace cost of keeping
> comments up-to-date and the risk of them getting out-of-date as we have
> previously discussed.
>
> - Ryosuke
>
Like many others on this thread, I don't buy this argument. It's well known
that developers spend much more time reading & understanding code than
writing it. This is especially true in an inevitably complex codebase like
WebKit, with many interdependencies. Well chosen comments that add value
(like describing the deviations from a spec) are worth maintaining. Indeed,
12 months down the line, the original author will probably have forgotten
enough detail that they themselves would have benefited by appropriately
commenting their code.

Even to check simple things like whether some method can return null you
typically have to grep through all references to the thing being returned,
and often in turn through all references to those. It's not feasible for
developers to read the full transitive closure of code that interacts with
every class they use, so they skim it and make mistakes. These mistakes
often then slip through code review because they look reasonable. The bugs
caused by these incorrect assumptions (that wouldn't have occurred with
appropriate comments) seem much more concerning than the hypothetical bugs
caused by stale comments.

To take an arbitrary example, lets say that while iterating through a
ListHashSet something causes entries to be deleted. Intuitively it seems
this needn't invalidate the iterator, as long as the entry the iterator is
currently pointing to isn't removed. But is that actually the case in this
particular implementation? A well-documented library like Java's
LinkedHashSet<http://docs.oracle.com/javase/6/docs/api/java/util/LinkedHashSet.html>
will
warn you "if the set is modified at any time after the iterator is created,
in any way except through the iterator's own remove method, the iterator
will throw a ConcurrentModificationException" and that's that. I just tried
to find this out in WebKit and had to read though ListHashSetIterator,
ListHashSetConstIterator, ListHashSetNode, ListHashSet::remove,
ListHashSet::unlinkAndDelete, HashTable::remove,
HashTable::internalCheckTableConsistency,
HashTable::removeWithoutEntryConsistencyCheck,
HashTable::removeAndInvalidateWithoutEntryConsistencyCheck,
HashTable::invalidateIterators, HashTable::shrink, HashTable::rehash,
ListHashSet::add, HashTable::add,
HashTable::makeKnownGoodIterator, HashTableIterator, HashTable::AddResult
and ListHashSetTranslator::translate, and even learn about using the template
keyword<http://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put-the-template-and-typename-keywords>
for
disambiguation. Eventually there was enough information to conclude that
yes, it probably is safe since the ListHashSetNodes are allocated on the
heap by ListHashSetTranslator::translate, so even though the HashTable
invalidates its own iterators and HashTable::rehash may reallocate its
storage, the actual ListHashSetNode pointed to by ListHashSetConstInterator
should continue to exist. But constantly having to do such deep research
makes coding highly inefficient, and there's a high risk of making errors.

All the best,
John
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

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 of lists. Consider the
following srcN for a fixed-width image with art direction:



I guess one could combine it all into one attribute, e.g. by introducing
"||" as an 3rd separator, in addition to the existing "," and ";". For
example:



But that seems rather harder to read...


> - R. Niwa
>
> On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss  wrote:
>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa  wrote:
>>
>>> On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss  wrote:
>>>
 On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa wrote:

> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. 
> wrote:
>
>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto 
>> wrote:
>> > Ignoring other aspects of this, the idea of making attribute name an
>> > enumeration is somewhat distasteful. It will require ugly special
>> parsing.
>> > The platform has plenty of attribute values that are lists already.
>>
>> The parsing aspect isn't particularly new - parsing data-* attributes
>> presents the same problem.  You just need to filter the list of
>> attributes on the element to look for things with a src- prefix.  I've
>> heard direct feedback from Yoav, implementing in Blink, that it's not
>> a big problem.
>>
>
> Just because it was not a big problem in one engine, it doesn't mean
> it won't be in other engines.
> If we're supporting src-N attributes in WebKit, I'd like to see N to
> have a small upper bound; e.g. 10.
> so that we can enumerate all parsed attributes statically at the
> compilation time.
>

 Out of curiosity, what would be the benefits of such a restriction?

>>>
>>> We're considering to implement an optimization that takes the advantage
>>> of parsed attributes being a finite set at the compilation time.
>>>
>>>  Having this feature will make it much harder to implement such an
>>> optimization.  Note that data-* attributes don't need to be parsed since it
>>> doesn't synchronously update Element's internal states.
>>>
>>> - R. Niwa
>>>
>>
>> Will setting the limit on the number of possible attributes at 99 still
>> enable that optimization?
>> Many people (on the RICG's IRC and on Blink-dev) feel that setting the
>> limit to 9, even if it'd be enough today, leaves fairly little space for
>> future evolution. Setting it to some random number between 10 and 99 feels
>> arbitrary to me. So, will 99 be OK with you?
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak  wrote:
>
> My initial impression is that it seems a bit overengineered.

I sympathize. The issue of srcN appearing to be a complex solution to a
seemingly simple problem came up again on IRC chatting to rniwa, so I
thought I'd try to explain this briefly.

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 viewport
width and devicePixelRatio.
3. art direction: same as #1 or #2, except additionally, must serve
completely different images based on viewport width.

The key difference between #2 and #3, is that with #2 it's just different
resolutions of the same image, and it's desirable for browsers to be
allowed to load lower resolution variants if bandwidth is limited or
expensive, whereas with #3, the browser must strictly respect the width
breakpoint (as the image could have a different aspect ratio, so loading
the wrong one could break the layout).

srcset tackles #1 perfectly, doesn't tackle #3, and tries to tackle #2 with
the 'w' unit but that doesn't work as
intended<http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/>,
because it turns out images destined for narrower viewports are sometimes
much larger.  tackles #1 and #3 but doesn't tackle #2.

srcN solves all three use cases:
1. srcN's  syntax (borrowed from srcset) addresses #1.
2. srcN's  syntax cleanly addresses #2.
3. Finally, srcN lets you supplement either of the above with
'd alternatives to address #3.

It really can't be much simpler; the only simplification that could be made
without sacrificing a use case would be to scrap the  syntax
for fixed-width images (which is technically redundant). Then instead of
something like the following:



you'd have to write:



where 400px is the intrinsic width of the image (and as usual in a
 declaration, the alternate image urls are annotated with
the width in image pixels of the image files). This would make the syntax
consistent between use cases #1 and #2, at the expense of requiring an
extra ~8 characters for use case #1. Might be a reasonable tradeoff if it
helps people understand it?

On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson  wrote:
> Also, we should be mindful that whatever solution should be vaguely
> applicable to other contexts where you’re selecting resources based
> on resolution, etc, such as video and CSS properties. I don’t want
> an explosion of attributes everywhere, and I don’t even know how
> you’d do that in CSS (background-image-1, background-image-2, …)

CSS already has media queries, so to give it parity with srcN, you just
need to allow  as an alternate syntax for image-set(),
e.g. image-set(100%;
's.jpg' 160, 'm.jpg' 320, '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 PM, Dean Jackson  wrote:

>
> On 5 Nov 2013, at 9:55 am, Timothy Hatcher  wrote:
>
> On Nov 5, 2013, at 2:18 AM, John Mellor  wrote:
>
> 
>
>
> I prefer this over multiple attributes. It is a syntax that needs little
> explanation before you can read it and use it. It also expands the existing
> srcset instead of confusing things with other attributes.
>
> srcN is also too fiddly. If you want to add a higher precedent srcN, you
> need to reorder all the existing srcN attribute names. With srcset you just
> need to edit a single attribute's value, adding a logic operator between
> the rules.
>
>
> This is a great point.
>
> Also, we should be mindful that whatever solution should be vaguely
> applicable to other contexts where you’re selecting resources based on
> resolution, etc, such as video and CSS properties. I don’t want an
> explosion of attributes everywhere, and I don’t even know how you’d do that
> in CSS (background-image-1, background-image-2, …)
>
> Dean
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

On Wed, Nov 6, 2013 at 8:00 PM, Maciej Stachowiak  wrote:

> (...)
>
> I know there are explanations for how src-N got to be as complex as it is.
> However, the following counterpoints come to mind:
>
> (a) The complexity is not well-contained; some of it leaks out even if you
> want to do something very simple (e.g. cases that would be served by srcset
> as currently proposed).
>

Actually, srcN should always be at least as simple as any real world
srcset. The dpr-switching case is identical (just rename the attribute to
src-1). A simple viewport-switching case like a full-width banner changes
from:

srcset="xs.png 400w .5x, s.png 400w 1x, m.png 400w 2x,
s.png 800w .5x, m.png 800w 1x, l.png 800w 2x,
m.png 1600w .5x, l.png 1600w 1x, xl.png 1600w 2x,
l.png .5x, xl.png 1x"

to just:
src-1="100%; xs.jpg 160, s.jpg 320, m.jpg 640, l.jpg 1280, xl.jpg
2560"

Not only is the srcN version shorter, it's also much easier to author: you
just say how wide the image will be, and how wide the available image files
are, and the browser does all the error-prone maths for you.

More complex examples are even more of a wash in favor of srcN - see how
the impenetrable 985 character srcset Tab posted on goo.gl/8qvWg0 can be
reduced to an intuitively understandable 113 character src-1.

These are not contrived examples; these are very common website layouts.

(b) I am dubious of some of the use cases proposed as essential for src-N
> that ratchet up the complexity. For example, your case #2 of
> viewport-switching, in particular its headlining use case of a multi-column
> view that changes number of columns at different viewport widths, was not
> addressed or even meaningfully discussed in the N years that srcset and
>  were being developed. This makes me doubt somewhat that
> addressing this use case is now absolutely critical. It seams kinda neat,
> but is it really a showstopper to address this in version 1.0 of the
> feature?
>

Web developers want something that works for all images. They asked *over
and over again* for a solution based on the layout size of the image. Sadly
that breaks preloaders <http://www.stevesouders.com/blog/2013/04/26/i/>, so
they grudgingly switched to advocating for solutions based solely on
viewport width, as it's all we'd allow them. But as responsive web design
becomes increasingly dominant, variable numbers of columns is a real
problem that almost every new site encounters. And it's just one convenient
example of something you can do with srcN that's hard with more rigid
solutions; since srcN's  effectively allows you to
define the mapping from viewport width to layout size, it can solve any
imaginable layout.

(c) Some of the complexity is not intrinsic to the use cases at all.
> Expressing a list of list syntax where one level of the list is implicit in
> numbered attribute names and the other level is an explicit list with comma
> separators is more complex than having a more unified list-of-lists syntax
> (for example, a microsyntax with two kinds of separators).
>

I've suggested 
before<https://lists.webkit.org/pipermail/webkit-dev/2013-November/025815.html>
that
the attributes could be combined if that's considered simpler. My only
concern is that most developers aren't used to putting line breaks in html
attributes, so might feel obliged to put all the alternatives on one line,
harming readability. But as long as the developer documentation 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
>> are 3 main use cases:
>> 1. dpr-switching: fixed-width image resolution based on devicePixelRatio.
>> 2. viewport-switching: flexible-width image resolution based on viewport
>> width and devicePixelRatio.
>> 3. art direction: same as #1 or #2, except additionally, must serve
>> completely different images based on viewport width.
>>
>
> How important and common are each of those use cases?


1. Some images on almost every website.
2. Some images on most responsive websites.
3. Some images on some responsive websites.

Judging by the unprecedented amount of noise web developers have made about
these issues, I think it's fair to say that all 3 are important. The nice
thing about the way srcN handles art direction (multiple attributes
notwithstanding) is that it's an optional feature; sites which don't need
it just use src-1 and don't have to worry about media queries at all.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Mellor]

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 decisions).
2. It handles art direction.

Does everyone agree that these are useful and long-overdue problems to
solve, and that the high-level approach of srcN (with 
syntax to handle viewport switching, and a layer of media queries above
that) is the best (only) known solution to these?


On Fri, Nov 8, 2013 at 3:24 PM, Dean Jackson  wrote:

> [And the holy book sayeth cursed is she who participates in standards
> email, doomed forever to receive email in CC and being unable to sleep at
> night. ]
>
> On 7 Nov 2013, at 17:43, "Tab Atkins Jr."  wrote:
>
> >> A proposal for a new paradigm of using multiple attributes deserves
> some resistance, careful consideration and exploration of alternatives. I
> feel my factual example of  was flippantly tossed aside. So I
> responded in jest.
> >
> > Apologies if you believed my response was flippant; it was short, but
> > serious and to the point.  I explained why the  example wasn't
> > very good - it's a single (albeit way overcomplicated) list of
> > commands.  The src-N attributes already contain lists, so they're
> > comparable.  I'm objecting to combining the src-N attributes into a
> > single attribute because that produces a *list of lists*, which is a
> > significant step further in mental complexity.
>
> one of the things I liked about srcset is that in the most urgent case it
> is simply one extra attribute with one higher resolution image.
>
> once we get into structure and ordering and multiple options and art
> direction any of these attribute solutions looks horrible. I don't care
> whether it is one attribute or 99, it's a pain to understand. if you want
> structure, use markup. I'm tempted to think the  element is a
> better solution for these advanced cases.
>
> fwiw path d is an attribute because we expected thousands of values in
> that and structure would have been too unwieldy.
>
> dean
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev