Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

[Rick Byers]

Sorry for the delay.

We agree that scroll anchoring has unrealized potential to be valuable for
the web at large, and to make that happen we should be investing a lot more
working with y'all (and if we can't succeed, probably removing it from
chromium). Concretely +Chris Harrelson who leads rendering for Chrome (and
likely someone else from his team), as well as +Nick Burris from the Chrome
input team will start digging in ASAP. In addition to just the normal
high-bandwidth engineer-to-engineer collaboration between chromium and
gecko I propose the following high-level goals for our work:

   - Ensure that there are no known deviations in behavior between chromium
   and the spec (one way or the other).
   - Ensure all the (non-ua-specific) site compat constraints folks are
   hitting are captured in web-platform-tests. I.e. if Gecko passes the tests
   and serves a chromium UA string it should work as well as in Chrome (modulo
   other unrelated UA compat issues of course).
   - Look for any reasonable opportunity to help deal with UA-specific
   compat issues (i.e. those that show up on sites that are explicitly looking
   for a Gecko UA string or other engine-specific feature). This may include
   making changes in the spec / chromium implementation. This is probably the
   toughest one, but I'm optimistic that if we nail the first two, we can find
   some reasonable tradeoff for the hard parts that are left here. Philip (our
   overall interop lead) has volunteered to help out here as well.

Does that sound about right? Any suggestions on the best forum for tight
engineering collaboration? GitHub good enough, or maybe get on an IRC /
slack channel together somewhere?

Rick

On Mon, Oct 7, 2019 at 2:11 PM Mike Taylor  wrote:

> Hi Rick,
>
> On 9/28/19 10:07 PM, Rick Byers wrote:
> > Can you give us a week or so to chat about this within the Chrome team
> > and get back to you?
>
> Any updates here?
>
> Thanks.
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Rick Byers]

On Tue, May 16, 2017 at 4:54 AM, Maciej Stachowiak  wrote:

>
>
> > On May 16, 2017, at 1:16 AM, Ryosuke Niwa  wrote:
> >
> > On Mon, May 15, 2017 at 11:57 PM, Anne van Kesteren 
> wrote:
> >> On Tue, May 16, 2017 at 7:29 AM, Ryosuke Niwa  wrote:
> >>> Given we're talking about how these tests are ran inside WebKit,
> >>> whether there is an agreement about this or not is sort of irrelevant.
> >>> If a test doesn't run as expected, we can run it inside a HTTP server.
> >>
> >> I was just trying to help clarify why what makes sense for WebKit,
> >> might not make sense for tests designed to run on all engines. If
> >> that's not desired here, I'll stop.
> >
> > Sure, I don't think we're interested in changing the way tests are ran
> > elsewhere.
> >
> > It would be great if upstream web-platform-tests could use relative
> > paths whenever possible or allowed annotation (e.g. we'd add such
> > annotation) as to which tests could be ran locally via file URL.
> >
> > However, that's more or less a secondary concern (nice-to-have)
> > whereas how web-platform-tests are imported and ran in WebKit are a
> > lot more important to us due to the impact it has on our development
> > process, tooling, as well as the maintenance cost.
>
> I agree with Ryosuke. We don't want to impose on others, but these two
> changes would be convenient for WebKit's use. Perhaps somewhere in WPT
> space (a GitHub issue?) would be the appropriate venue to discuss it. I am
> assuming here the tradeoff is just the maintenance burden of keeping the
> relative paths up to date, but maybe there is some deeper reason not to do
> it.
>

Filed https://github.com/w3c/web-platform-tests/issues/5945

Even though (after much debate) chromium has switched to using wptserve all
the time, there are still some situations where I'd find it handy to be
able to load a test (which I know doesn't depend on wptserve) from some
other server or filesystem.  So I'd support changing this upstream.


>  - Maciej
> ___
> 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] Another WPT bite

[Rick Byers]

On Fri, May 12, 2017 at 2:43 PM, youenn fablet  wrote:

>
> Le ven. 12 mai 2017 à 11:07, Alexey Proskuryakov  a écrit :
>
>>
>> 9 мая 2017 г., в 11:27, Simon Fraser  написал(а):
>>
>>
>> Another consideration here is "would my test be useful for other browser
>> vendors". I don't think the answer is a unanimous "yes", so I think we
>> should only use WPT for tests that will think are worth sharing.
>>
>>
>> Since imported WPT tests are very flaky, and are not necessarily written
>> to defend against important regressions, investigating issues with them is
>> relatively lower priority than investigating issues observed with WebKit
>> tests. So I would recommend not mixing tests for WebKit regressions with
>> WPT tests - if your test eventually ends up in LayoutTests/imported, it
>> will become a lot less effective.
>>
>
> WPT tests are flaky in WebKit because WPT stability bots do not run yet
> Safari, and most tests are written in non-WebKit environment.
> Often, it is due to the fact that tests are not passing and flakiness is
> only seen with failing assertions.
>
> From my experience with fetch API tests, I disagree that broken WPT tests
> are lower priority.
> I think it will change as more WebKit contributors will author WPT tests.
>
> I agree that tests doing subtle WebKit-specific regression checks are not
> good candidates for WPT upstream.
> When the test is all about conformance with a spec, it is a very good
> candidate.
>
>
>> Using the complicated harness has a similar consequence - if you use any
>> WPT goodies like templates or server side scripts, the cost of
>> investigating issues on the test increases, and makes the test less
>> valuable.
>>
>
> It is true that WPT put some emphasis on easing authoring of tests.
> I guess there is a learning curve here in WPT test debugging.
>
> If you have a file with 20 tests, it is harder to debug.
> It is also increasing the chances for flakiness/timeouts.
> Maybe we could send that feedback.
>
> WPT infra could also be improved: more verbose debug-only output, enabling
> running selected subtest only...
> testharness.js is actively maintained and is continuously improving.
> Since we have specific requirements as you are describing, we should push
> them.
>

Concretely, please file issues with the "infra" label

to
track upstream WPT infrastructure bugs and feature requests.  Google has an
ongoing contract with Bocoup (Bob and Mike cc'd) who are improving the
infrastructure every day.  Of course there's an opportunity to make it even
better fast with more funding from additional organizations who would
benefit :-)

>
> I don't know if there is any way to adopt WPT that won't make testing less
>> effective. WPT tests may be useful in very rare cases, where we actively
>> want to communicate certain subtle behavior details to other vendors - but
>> even so, I imagine that other vendors may not put high priority on those,
>> for the same reasons.
>>
>
> My own experience is that WPT tests are actually very valuable, at least
> when we are talking about interoperability/spec conformance.
> I also see WPT as an efficient way to author tests.
>
>
>>
>> - Alexey
>>
>> ___
>> 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Rick Byers]

On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov  wrote:

>
> 9 мая 2017 г., в 11:27, Simon Fraser  написал(а):
>
> Another consideration here is "would my test be useful for other browser
> vendors". I don't think the answer is a unanimous "yes", so I think we
> should only use WPT for tests that will think are worth sharing.
>
>
> Since imported WPT tests are very flaky, and are not necessarily written
> to defend against important regressions, investigating issues with them is
> relatively lower priority than investigating issues observed with WebKit
> tests. So I would recommend not mixing tests for WebKit regressions with
> WPT tests - if your test eventually ends up in LayoutTests/imported, it
> will become a lot less effective.
>

FWIW this is absolutely NOT how we're treating this in chromium.  If this
is how things end up in practice then we will have failed massively in this
effort.

We figure if we want the web to behave consistently, we really have no
choice but to treat web-platform-tests as first class with all the
discipline we give to our own tests.  As such we are actively moving
 many of our LayoutTests to
web-platform-tests and depending entirely on the regression prevention they
provide us from there.  Obviously there will be hiccups, but because our
product quality will depend on web-platform-tests being an effective and
non-flaky testsuite (and because we're starting to require most new
features have web-platform-tests before they ship), I'm confident that
we've got the incentives in place to lead to constant ratcheting up the
engineering discipline and quality of the test suite.

Pragmatically to get there incrementally we're applying different policies
to different WPT directories.  Eg. for some directories if a WPT import
results in new failures we probably won't care enough to prioritize
investigating them.  But for many (which map to a feature team on the hook
for quality in that area) we'll treat it with the same priority as a newly
failing LayoutTest on our bots.

Of course the WebKit project might have a higher test quality bar than the
chromium project, so the right choice could be incredibly different for you
than for us.  But should you choose to treat WPT as a first-class test
suite for your project, we're committed to working together to make it work
well in practice for all of us.  We figure that in the long-run, if we
shift investments from our own LayoutTests to web-platform-tests, even
though there will be some additional costs and risks, it'll eventually lead
to both lower testing costs and higher product quality because we're
leveraging the work of spec editors like Anne and other implementors who
are also working to improve the test suite.

Using the complicated harness has a similar consequence - if you use any
> WPT goodies like templates or server side scripts, the cost of
> investigating issues on the test increases, and makes the test less
> valuable.
>
> I don't know if there is any way to adopt WPT that won't make testing less
> effective. WPT tests may be useful in very rare cases, where we actively
> want to communicate certain subtle behavior details to other vendors - but
> even so, I imagine that other vendors may not put high priority on those,
> for the same reasons.
>
> - Alexey
>
>
> ___
> 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] Implementing Universal Second Factor (U2F)

[Rick Byers]

As I understand, there's active development going on in both chromium and
Edge for Web Authentication right now.  I'm sure those folks would love to
collaborate with someone working in WebKit (and I'm happy to make
introductions).

On Wed, Feb 22, 2017 at 6:08 PM, Sam Weinig  wrote:

>
> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa  wrote:
>
> On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  wrote:
>
>> Chrome ships with a built-in extension that exposes the high-level API
>> (which I think we all agree is a hack).  We recently had this discussion
>> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/wfIVkXvQ7kQ/VfuOr_FhBwAJ>
>> about the right path forward here, and agreed that we should instead focus
>> our efforts
>> <https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/u2f%7Csort:relevance/blink-dev/qCJhuuZH5p0/le6l1t37AQAJ>
>> on the Web Authentication API <https://w3c.github.io/webauthn/> instead,
>> since it seemed much more likely to be something that would become
>> interoperable between browsers.
>>
>
> Boris's comment in the referenced thread makes me think that we should
> just implement https://w3c.github.io/webauthn/ if any:
>
> 1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a
>> pref so people
>> can experiment with it.
>> 2) [Gecko/Firefox] plan to ship the API being developed at
>> https://w3c.github.io/webauthn/ once it stabilizes.
>> > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in
>> the future.
>
>
> As such, I don't think we should be implementing FIDO U2F API on trunk.
>
> - R. Niwa
>
>
> Given that data, I agree with Ryosuke, and adding an implementing of the
> FIDO U2F API doesn’t seem like a great fit for WebKit.
>
> That said, Jacob, do you have any interest in working on an implementation
> of the Web Authentication specification?
>
> - Sam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Rick Byers]

Chrome ships with a built-in extension that exposes the high-level API
(which I think we all agree is a hack).  We recently had this discussion

about the right path forward here, and agreed that we should instead focus
our efforts

on the Web Authentication API  instead,
since it seemed much more likely to be something that would become
interoperable between browsers.



On Wed, Feb 22, 2017 at 3:46 PM, Sam Weinig  wrote:

>
> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield  wrote:
>
> I’m working on adding support to WebKit for FIDO U2F (JS API:
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-javascript-api-v1.1-id-20160915.html Architecture
> overview: https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-overview-v1.1-id-20160915.html ). The FIDO U2F
> specification allows a secure second factor to be used during
> authentication flow, with bidirectional verification (token verifies
> server, server verifies token and token’s knowledge of a specific private
> key). There are current implementations in Chrome, Opera, and Blink
> (Firefox). I’m primarily interested in bringing support to Safari, so that
> is the focus what I am currently working on.
>
>
> Hi Jacob, and welcome to WebKit.
>
> I went looking for how to use the feature in Chrome and Firefox (I assume
> you meant Gecko (Firefox), not Blink (Firefox)) I’m a little confused as to
> how this feature is exposed in the other browsers.  On the topic of the
> low-level MessagePort API, section 3 states “This specification does not
> describe how such a port is made available to RP web pages, as this is (for
> now) implementation and browser dependent” (https://fidoalliance.org/
> specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-
> api-v1.1-id-20160915.html#api-levels).  Similarly, for the high-level
> API, it states in section 3.2, “Implementations may choose how to make such
> an API available to RP web pages. If such an API is provided,
> it should provide a namespace object u2f of the following interface" (
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#
> high-level-javascript-api).
>
> Do you have insight into how either of these APIs are exposed in other
> browsers? How do you plan on exposing them in WebKit?
>
> I should say, generally, I am concerned with APIs that leave important
> details like how the APIs are exposed to the implementation, as they lead
> to non-interoperable implementations.
>
> Thanks,
> - Sam
>
>
> ___
> 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] PSA: higher precision event timestamp landing soon - port verification needed

[Rick Byers]

On Mon, Jun 10, 2013 at 5:19 PM, Benjamin Poulain wrote:

> On Mon, Jun 10, 2013 at 7:37 AM, Rick Byers  wrote:
>
>> There's been discussion / patches in the past for exposing system time as
>> a separate timestamp on the Event object (as IE does).  See
>> https://lists.webkit.org/pipermail/webkit-dev/2012-October/022574.html,
>> https://bugs.webkit.org/show_bug.cgi?id=94987 and
>> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html.
>>
>> In particular, the use of UNIX-epoch timestamps means such measurements
>> will never be completely accurate (due to NTP skew, leap seconds, etc.).
>>  But just updating the timestamp everyone uses to be more accurate (even if
>> not perfect) seems like a clear win.
>>
>> Do you think both approaches should be pursued, or is updating the
>> existing timestamp to be as accurate as possible within the epoch semantics
>> good enough?
>>
>
>  Kind of different goals in one timestamp. :)
>
> For input events, the accurate time delta covers many use cases. High
> precision time would be nice but it is not really a must have.
>

Right, but isn't NTP skew a problem (at least in theory) even for accurate
time deltas when using an epoch-based timestamp?  At least I believe that's
part of the push back flackr@ got when he tried to plumb PlatformEvent
timestamps into the DOM event objects a few months back.


> For other kind of events, a high precision timestamp like you suggest
> could make sense.
>

> Benjamin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: higher precision event timestamp landing soon - port verification needed

[Rick Byers]

There's been discussion / patches in the past for exposing system time as a
separate timestamp on the Event object (as IE does).  See
https://lists.webkit.org/pipermail/webkit-dev/2012-October/022574.html,
https://bugs.webkit.org/show_bug.cgi?id=94987 and
http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html.

In particular, the use of UNIX-epoch timestamps means such measurements
will never be completely accurate (due to NTP skew, leap seconds, etc.).
 But just updating the timestamp everyone uses to be more accurate (even if
not perfect) seems like a clear win.

Do you think both approaches should be pursued, or is updating the existing
timestamp to be as accurate as possible within the epoch semantics good
enough?

Thanks,
 Rick


On Sun, Jun 9, 2013 at 2:30 AM, Benjamin Poulain wrote:

> Hi WebKit,
>
> Next week, I will land a patch changing the way event timestamps are
> handled: https://bugs.webkit.org/show_bug.cgi?id=117179
>
> Previously, the PlatformEvent timestamp was ignored when creating a DOM
> Event, and a new timestamp was generated with currentTime() when the DOM
> Event was created.
> After the change, the timestamp from the PlatformEvent is used for the DOM
> Event.
>
> This change will help web pages to determine the speed and acceleration of
> input with a better accuracy.
>
> The patch of https://bugs.webkit.org/show_bug.cgi?id=117179 updates the
> Mac port to adapt for the changes. The other ports may need to be changed
> as well.
> Please take a minute to check your port, and create a bug blocking 117179
> if needed.
> The timestamp passed to create PlatformEvents must now be the time in
> seconds since Unix Epoch.
>
> Benjamin
>
> ___
> 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] Unprefixed and prefixed DOM events.

[Rick Byers]

On Mon, Jan 14, 2013 at 9:56 AM, Alexis Menard  wrote:

> On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers  wrote:
> > On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard 
> wrote:
> >>
> >> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers 
> wrote:
> >> > I've been wondering about the implications of prefixed events.  Do we
> >> > have
> >> > other examples of events that had prefixed names and were later
> >> > unprefixed?
> >> >
> >>
> >> We've never had such a case in the past. It's the first time we have
> >> to "unprefix" DOM events.
> >>
> >> > In particular, what are the composition implications of your solution?
> >> > When
> >> > you say "depending
> >> > if someone is listening to it or not" you mean whether there is a
> >> > handler
> >> > attached that will be triggered by this event, not whether there is a
> >> > handler for that type of event anywhere on the page, right?  Is it
> >> > likely
> >>
> >> I'm not sure to understand this part. What is the difference you are
> >> talking about? Do you mean whether the user added an event listener on
> >> an element or on the document. If it's the case then WebKit event
> >> delivery code does not make any difference from what I can see.
> >
> >
> > Sorry, what I'm trying to ask is, what happens when:
> >  - e1 has a 'webkitTransitiionEnd' handler, and
> >  - e2 has a 'transitionend' handler
> >
> > You made it clear that if e1==e2 then you'd dispatch only transitionend.
> > But what about when e1 is neither an ancestor or descendant of e2?  I.e.
> are
> > you looking at all handlers on the page to determine which events to
> > dispatch, or only some subset of them specific to the context of the
> event
> > being dispatched?
>
> In that particular case, from my testing e1 handler will be called and
> e2 handler too. The case I was raising is if you have an event handler
> installed on the same element for both events.
>

Perfect, thanks.  I think that means the majority of composition scenarios
I was worried about should be fine...

 >
> >>
> >> > that existing code might put handlers on the document (eg. maybe as a
> >> > sort
> >> > of polling mechanism when there are many elements that may be involved
> >> > in
> >> > transitions?), and if so are we likely to have trouble with different
> >> > libraries that used to co-exist peacefully in the same site no longer
> >> > working together?  The philosophy of "forcing" a site to update to the
> >> > unprefixed name really only makes sense to me if you think of a site
> as
> >> > a
> >> > single application, not as a collection of separately maintained
> >> > libraries
> >> > and components.
> >>
> >> Well usually libraries tend to support multiple vendors so if we send
> >> the unprefixed version then I'm pretty sure it's handled somewhere.
> >> For example, Opera and Mozilla ship unprefixed for some time so I
> >> believe anyway the web is slowly updating. Worst I believe that
> >> because WebKit does not ship unprefixed transitions and animations
> >> they end up having code extra to support us.
> >
> >
> > Oh, if most important libraries have already updated to always listen for
> > the unprefixed events (and most important sites using those libraries
> have
> > updated  to a version that does this), then I agree there shouldn't be
> any
> > such composition concerns.  I don't have any data, but I just assumed
> with
> > the history of CSS animations on webkit-dominated mobile, that there
> could
> > still be a lot of deployed code (especially in the mobile space) that
> looks
> > only for webkitTransitionEnd.
>
> Adam proposed a solution to gather data, I think we should do it.
>
> >
> >> >
> >> > Rick
> >> >
> >> > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth 
> wrote:
> >> >>
> >> >> That does sound like a tricky problem.  Your approach sounds
> >> >> reasonable to me.  If you like, we can use the FeatureObserver [1] to
> >> >> estimate how often these various cases occur.
> >> >>
> >> >> Adam
> >> >>
> >> >> [1]
> >> >>
> http://lists.webkit.org/pipermail/webkit-dev

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Rick Byers]

On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard  wrote:

> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers  wrote:
> > I've been wondering about the implications of prefixed events.  Do we
> have
> > other examples of events that had prefixed names and were later
> unprefixed?
> >
>
> We've never had such a case in the past. It's the first time we have
> to "unprefix" DOM events.
>
> > In particular, what are the composition implications of your solution?
>  When
> > you say "depending
> > if someone is listening to it or not" you mean whether there is a handler
> > attached that will be triggered by this event, not whether there is a
> > handler for that type of event anywhere on the page, right?  Is it likely
>
> I'm not sure to understand this part. What is the difference you are
> talking about? Do you mean whether the user added an event listener on
> an element or on the document. If it's the case then WebKit event
> delivery code does not make any difference from what I can see.
>

Sorry, what I'm trying to ask is, what happens when:
 - e1 has a 'webkitTransitiionEnd' handler, and
 - e2 has a 'transitionend' handler

You made it clear that if e1==e2 then you'd dispatch only transitionend.
 But what about when e1 is neither an ancestor or descendant of e2?  I.e.
are you looking at all handlers on the page to determine which events to
dispatch, or only some subset of them specific to the context of the event
being dispatched?


> > that existing code might put handlers on the document (eg. maybe as a
> sort
> > of polling mechanism when there are many elements that may be involved in
> > transitions?), and if so are we likely to have trouble with different
> > libraries that used to co-exist peacefully in the same site no longer
> > working together?  The philosophy of "forcing" a site to update to the
> > unprefixed name really only makes sense to me if you think of a site as a
> > single application, not as a collection of separately maintained
> libraries
> > and components.
>
> Well usually libraries tend to support multiple vendors so if we send
> the unprefixed version then I'm pretty sure it's handled somewhere.
> For example, Opera and Mozilla ship unprefixed for some time so I
> believe anyway the web is slowly updating. Worst I believe that
> because WebKit does not ship unprefixed transitions and animations
> they end up having code extra to support us.


Oh, if most important libraries have already updated to always listen for
the unprefixed events (and most important sites using those libraries have
updated  to a version that does this), then I agree there shouldn't be any
such composition concerns.  I don't have any data, but I just assumed with
the history of CSS animations on webkit-dominated mobile, that there could
still be a lot of deployed code (especially in the mobile space) that looks
only for webkitTransitionEnd.

>
> > Rick
> >
> > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth  wrote:
> >>
> >> That does sound like a tricky problem.  Your approach sounds
> >> reasonable to me.  If you like, we can use the FeatureObserver [1] to
> >> estimate how often these various cases occur.
> >>
> >> Adam
> >>
> >> [1]
> >> http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html
> >>
> >>
> >> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard 
> wrote:
> >> > Hi all,
> >> >
> >> > As you know I'm working on unprefixing CSS transitions and I need a
> >> > few advice from the DOM experts.
> >> >
> >> > Problem : CSS Transitions when they finish to animate send a DOM event
> >> > "transitionend" as specified there [1] to give the developer a notice
> >> > that the transition finished. Today WebKit sends the prefixed
> >> > counterpart "webkitTransitionEnd". Animations also have the same event
> >> > and few more. So today the problem is when we should send the prefixed
> >> > event and when we should send the unprefixed one, and if we should
> >> > send both.
> >> >
> >> > I think that sending both events will break content somewhere as JS
> >> > functions attached with addEventListener will be called two times.
> >> >
> >> > Sending only the unprefixed event will break WebKit-only content the
> >> > day we ship CSS Transitions unprefixed. I know they should not produce
> >> > WebKit only code but it's not the point of the dis

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Rick Byers]

I've been wondering about the implications of prefixed events.  Do we have
other examples of events that had prefixed names and were later unprefixed?

In particular, what are the composition implications of your solution?
 When you say "depending
if someone is listening to it or not" you mean whether there is a handler
attached that will be triggered by this event, not whether there is a
handler for that type of event anywhere on the page, right?  Is it likely
that existing code might put handlers on the document (eg. maybe as a sort
of polling mechanism when there are many elements that may be involved in
transitions?), and if so are we likely to have trouble with different
libraries that used to co-exist peacefully in the same site no longer
working together?  The philosophy of "forcing" a site to update to the
unprefixed name really only makes sense to me if you think of a site as a
single application, not as a collection of separately maintained libraries
and components.

Rick

On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth  wrote:

> That does sound like a tricky problem.  Your approach sounds
> reasonable to me.  If you like, we can use the FeatureObserver [1] to
> estimate how often these various cases occur.
>
> Adam
>
> [1]
> http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html
>
>
> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard  wrote:
> > Hi all,
> >
> > As you know I'm working on unprefixing CSS transitions and I need a
> > few advice from the DOM experts.
> >
> > Problem : CSS Transitions when they finish to animate send a DOM event
> > "transitionend" as specified there [1] to give the developer a notice
> > that the transition finished. Today WebKit sends the prefixed
> > counterpart "webkitTransitionEnd". Animations also have the same event
> > and few more. So today the problem is when we should send the prefixed
> > event and when we should send the unprefixed one, and if we should
> > send both.
> >
> > I think that sending both events will break content somewhere as JS
> > functions attached with addEventListener will be called two times.
> >
> > Sending only the unprefixed event will break WebKit-only content the
> > day we ship CSS Transitions unprefixed. I know they should not produce
> > WebKit only code but it's not the point of the discussion.
> >
> > A solution is to send the prefixed or the unprefixed event depending
> > if someone is listening to it or not. Let me explain.
> >
> > Let say there is a listener on the prefixed event only then we deliver
> > the prefixed event *only*.
> >
> > If there is a listener on the unprefixed event only we deliver the
> > unprefixed event *only*.
> >
> > If there are listeners on both events then we send the unprefixed one
> > *only* forcing people to rely on the unprefixed.
> >
> > It seems that this approach is an elegant one and allows us to remove
> > later in the future the support for prefixed transitions (including
> > the events). As a side note Opera is acting the same as the proposed
> > solution.
> >
> > Now obviously prefixed and unprefixed events in the DOM is something
> > new because it never happens in the past so we don't have support for
> > having such a mechanism for event delivery.
> >
> > I thought that we could somewhere in the Animation/Transition code be
> > smart and try to figure which event to send but it practically
> > impossible to access the EventListenerMap so I thought we could
> > support it somehow generically in the DOM events code. It will be
> > useful for the animations and maybe in the future (we're not really
> > sure if prefixed event will again show but who knows).
> >
> > So I did a first patch there [2] and I would like to gather feedback
> > whether the approach is correct (I don't know much the DOM related
> > code) or if somebody has a better idea on how to resolve the problem.
> > Also if I have missed something, please point it to me. The patch
> > doesn't include the support for HTML ontransitionend attribute which I
> > prefer to do in a later patch.
> >
> > Thanks.
> >
> > [1]
> http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property
> > [2] https://bugs.webkit.org/show_bug.cgi?id=105647
> > --
> > Software Engineer @
> > Intel Open Source Technology Center
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Possible device scale factor emulation approaches?

[Rick Byers]

On Fri, Dec 7, 2012 at 10:53 AM, Alexander Pavlov wrote:

> On Fri, Dec 7, 2012 at 7:30 PM, Rick Byers  wrote:
>
>> On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov wrote:
>>
>>>  On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth  wrote:
>>>
>>>> On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov 
>>>> wrote:
>>>> > On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens 
>>>> wrote:
>>>> >> On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth 
>>>> wrote:
>>>> >> > On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov <
>>>> apav...@chromium.org>
>>>> >> > wrote:
>>>> >> >> I'm working on emulating the device scale factor with Web
>>>> Inspector. My
>>>> >> >> goal
>>>> >> >> is to let web developers see their pages on "normal" (device pixel
>>>> >> >> ratio ==
>>>> >> >> 1) monitors the way they would look on e.g. retina screens.
>>>> >> >> Page::setDeviceScaleFactor() is not something we can use, since
>>>> it will
>>>> >> >> have
>>>> >> >> the reverse effect when used by platform-specific compositor code
>>>> >> >> (which I
>>>> >> >> saw on Chromium, and its compositor is far from being ready for
>>>> such
>>>> >> >> abnormal treatment.)
>>>> >> >
>>>> >> > I'm not sure I fully understand what you're trying to accomplish.
>>>>  Is
>>>> >> > the developer using a high density screen or a low density screen?
>>>> >
>>>> > A low density screen is used (that's what I meant by "normal" (device
>>>> pixel
>>>> > ratio == 1) monitors"). Imagine two 24" monitors, one high-density
>>>> (H) and
>>>> > one low-density (L), standing next to each other. I want any page to
>>>> be
>>>> > rendered exactly the same both on H and L monitor. So, @media and
>>>> image set
>>>> > elements should be chosen as if L monitor were H, but then the
>>>> respective
>>>> > images/glyphs/whatever downscaled to match the visible size of the
>>>> same
>>>> > items in the H monitor.
>>>>
>>>> I'm not sure I understand.  L has fewer pixels than H.  It's not clear
>>>> how two things can render exactly the same given that they'll render
>>>> using a different number of pixels.
>>>>
>>>
>>> I mean the user-perceived image, where one L's pixel covers a square of
>>> four H's pixels.
>>>
>>>
>>>> > Naturally, but I would prefer not to touch the compositor code, as it
>>>> is
>>>> > currently converging to the hardware-accelerated Ash implementation,
>>>> and
>>>> > it's going to take a while until the dust settles down.
>>>>
>>>> That's not really a good reason to pick an inferior design.
>>>>
>>>
>>> Agree. Assessing the design and picking the best approach was the
>>> original goal of my post.
>>>
>>>
>>>>  >> > In general, though, trying to shim this feature into WebCore isn't
>>>> >> > likely the right approach.  For WebKit2, for example, both the UI
>>>> >> > process and the web process need to agree about the device pixel
>>>> ratio
>>>> >> > or else the system gets confused about how big various regions of
>>>> >> > memory ought to be.  If you look at how we test high density
>>>> rendering
>>>> >
>>>> > That's one reason why I do not want to fiddle with ACTUAL device pixel
>>>> > ratios (the same holds for the WebCore and compositor code in
>>>> Chromium; the
>>>> > compositor code in desktop Chromium (non-Ash) is not ready to see
>>>> anything
>>>> > other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor()
>>>> has
>>>> > the following comment, "Don't allow page scaling when compositor
>>>> scaling is
>>>> > being used, as they are currently incompatible.")).
>>>>
>>>> What value do you want to return from window.devicePixelRatio?  If
>>>> you&#x

Re: [webkit-dev] Possible device scale factor emulation approaches?

[Rick Byers]

On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov wrote:

> On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth  wrote:
>
>> On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov 
>> wrote:
>> > On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens 
>> wrote:
>> >> On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth  wrote:
>> >> > On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov <
>> apav...@chromium.org>
>> >> > wrote:
>> >> >> I'm working on emulating the device scale factor with Web
>> Inspector. My
>> >> >> goal
>> >> >> is to let web developers see their pages on "normal" (device pixel
>> >> >> ratio ==
>> >> >> 1) monitors the way they would look on e.g. retina screens.
>> >> >> Page::setDeviceScaleFactor() is not something we can use, since it
>> will
>> >> >> have
>> >> >> the reverse effect when used by platform-specific compositor code
>> >> >> (which I
>> >> >> saw on Chromium, and its compositor is far from being ready for such
>> >> >> abnormal treatment.)
>> >> >
>> >> > I'm not sure I fully understand what you're trying to accomplish.  Is
>> >> > the developer using a high density screen or a low density screen?
>> >
>> > A low density screen is used (that's what I meant by "normal" (device
>> pixel
>> > ratio == 1) monitors"). Imagine two 24" monitors, one high-density (H)
>> and
>> > one low-density (L), standing next to each other. I want any page to be
>> > rendered exactly the same both on H and L monitor. So, @media and image
>> set
>> > elements should be chosen as if L monitor were H, but then the
>> respective
>> > images/glyphs/whatever downscaled to match the visible size of the same
>> > items in the H monitor.
>>
>> I'm not sure I understand.  L has fewer pixels than H.  It's not clear
>> how two things can render exactly the same given that they'll render
>> using a different number of pixels.
>>
>
> I mean the user-perceived image, where one L's pixel covers a square of
> four H's pixels.
>
>
>> > Naturally, but I would prefer not to touch the compositor code, as it is
>> > currently converging to the hardware-accelerated Ash implementation, and
>> > it's going to take a while until the dust settles down.
>>
>> That's not really a good reason to pick an inferior design.
>>
>
> Agree. Assessing the design and picking the best approach was the original
> goal of my post.
>
>
>>  >> > In general, though, trying to shim this feature into WebCore isn't
>> >> > likely the right approach.  For WebKit2, for example, both the UI
>> >> > process and the web process need to agree about the device pixel
>> ratio
>> >> > or else the system gets confused about how big various regions of
>> >> > memory ought to be.  If you look at how we test high density
>> rendering
>> >
>> > That's one reason why I do not want to fiddle with ACTUAL device pixel
>> > ratios (the same holds for the WebCore and compositor code in Chromium;
>> the
>> > compositor code in desktop Chromium (non-Ash) is not ready to see
>> anything
>> > other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor()
>> has
>> > the following comment, "Don't allow page scaling when compositor
>> scaling is
>> > being used, as they are currently incompatible.")).
>>
>> What value do you want to return from window.devicePixelRatio?  If
>> you're going to return 1 on L but 2 on H, then the two are unlikely to
>> render similarly as JavaScript on the page is likely to branch (or
>> select subresources) based on that value.
>>
>
> Right, so this should... or now, shouldn't, be instrumented, too...
>
>
>>  >> > on low density machines, you'll see that we override the device's
>> >> > actual pixel density via the WebKit/WebKit2 API.  That's to avoid
>> this
>> >> > confusion.
>> >
>> > Yes, this is exactly my scenario - render pages on low-density (DPR==1)
>> > monitors as if they were high-density (DPR==2 or something else.) So,
>> if the
>> > device's actual pixel density is overridden in WebKit/WebKit2, will
>> glyphs
>> > and images get 2x bigger than those without the override?
>> >
>> > My goal is to have them visually remain the same size (because 1 CSS
>> pixel
>> > should still correspond to 1 device pixel, as DPR==1 for low-density
>> > screens) along with the @media rules and -webkit-image-set elements (and
>> > perhaps some other things) appropriate for DPR==2 taking effect
>> (downscaling
>> > larger 2x DPR images where applicable, so that they will look as if they
>> > were rendered on a high-density screen.) Do you think this can be
>> emulated
>> > through the page settings, same was as the touch emulation
>> > (WebCore::Settings::setTouchEventEmulationEnabled()) instead?
>>
>> That's a super strange rendering mode.
>>
>
> Well, it turned out to work well for me, since all layout was done using
> the correct DPR (corresponding to the device), but still, the resources and
> media queries chose the right resources/styles, so the page looked as if it
> were displayed on a retina.
>

Are you sure this is what people want for testing purposes?  When

Re: [webkit-dev] pointer events specification - first editors draft

[Rick Byers]

On Tue, Dec 4, 2012 at 2:28 PM, Benjamin Poulain  wrote:
> On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers  wrote:
>>
>> >> The premise of the specification is that using mouse event and touch
>> >> events
>> >> interchangeably is needed. In reality, nobody was really asking for
>> >> that
>> >> because it is a terrible idea. You can already easily unify pen, touch
>> >> and
>> >> mouse by writing very little JavaScript, but it is only useful in very
>> >> few
>> >> cases.
>>
>> It's not accurate to say "nobody" is asking for it.   I agree that you
>> generally need to design explicitly for touch and mouse interactions, and
>> it's a legitimate concern that having a unified model may encourage
>> developers to ignore important differences.  However, developers are already
>> attempting to unify the events today when the right design involves treating
>> single-finger touch actions the same as mouse actions.  For example, Google
>> maps transforms both touch events and mouse events to a common unified event
>> system, as does the PlayN game engine (http://code.google.com/p/playn/).
>> There has been at least SOME positive response in the web developer
>> community to the idea of a unified event model, so I don't think it's fair
>> to dismiss this idea as having no value out of hand.
>
>
> That is just reiterating my point.
> The fact is applications have already easily unified touch and mouse for the
> rare cases where it is needed.
>
>>
>> >> In particular, having apps state clearly and declaratively [3] whether
>> >> a touch that starts on an
>> >> element should result in browser behavior like scrolling or events
>> >> which can be handled from
>> >> JavaScript is potentially a big win for touch scrolling performance
>> >> (something we struggle with in Chrome).
>> >
>> > This is a straw man.
>> > Chromium has implementation issues there, adding a new spec is not the
>> > solution to your problems.
>> >
>> > Having touch-action == "auto", the default, will have the exact same
>> > issues as you have today.
>> > Having touch-action == "none" does not buy you much since it would have
>> > been implemented
>> > today by responding to the very first event.
>>
>> This is incorrect.  Let me ellaborate on the benefit here.  The
>> fundamental difference between the two models is that touch events imply
>> (although it's not well specified, and implementations differ) that it's
>> possible to receive touchmove events while an element is being scrolled.  In
>> such a case, we can't really do threaded scrolling (especially if calling
>> preventDefault on the touchmove is supposed to stop scrolling at that
>> point).  This makes it incredibly easy for web developers to accidentally
>> defeat fast scrolling optimizations (just by having a touchmove handler on
>> an element which happens to contain a scrollable div).  For example,
>> http://store.apple.com/us has a touchmove handler on the document (for no
>> apparent good reason that I can see), which means that (in the chrome
>> desktop implementation at least), we're unable to do scrolling without
>> blocking on the main webkit thread because the page might really be
>> expecting to receive events for the touch.  In rare scenarios (when an app
>> needs to receive touchmove events for a parent element, but one if it's
>> children is scrollable) threaded scrolling appears impossible without
>> potentially breaking changes to the touchevent model.
>>
>> Pointer events, on the other hand, were designed from the start to avoid
>> this issue.  They require the developer to explicitly state whether they
>> want scrolling OR events.  The spec is explicit that you will NOT receive
>> events when the browser is performing a default action like scrolling.  So
>> "touch-action: auto" means that once a scroll gesture is detected (even when
>> the element itself isn't actually scrollable), you get a pointercancel event
>> indicating that the page will no longer receive events for the touch.  If
>> the developer REALLY wants to get all the events, they have to explicitly
>> state that they're disabling scrolling on the element with touch-action:
>> none.   IMHO, it's far better to require developers to make an explicit
>> trade-off between scrolling and app-level events, than it is to let them
>> believe they can have it both ways wi

Re: [webkit-dev] pointer events specification - first editors draft

[Rick Byers]

ents for the touch.
 If the developer REALLY wants to get all the events, they have to
explicitly state that they're disabling scrolling on the element with
touch-action: none.   IMHO, it's far better to require developers to make
an explicit trade-off between scrolling and app-level events, than it is to
let them believe they can have it both ways without appreciating the
performance implications.  I question whether a modern touch API should
even give developers the option of having janky scrolling, nevermind
whether it should be so easy to opt-in to that mode accidentally.

Do you agree there is some room for improvement in the touch event model
here?  If so, what path specifically do you propose for getting such
improvements into an open standard and into WebKit?

Note that it's no longer just interoperability with IE that we're concerned
about - Mozilla and Opera have both also indicated that they see pointer
events as the future, and that no new work should be done on touch events.
 What options do we have for moving touch input forward on the open web?

Rick

On Sat, Dec 1, 2012 at 3:17 AM, Maciej Stachowiak  wrote:

>
>
> On Nov 28, 2012, at 8:23 AM, Adam Barth  wrote:
>
> > It looks like this thread got dropped over Thanksgiving.  (Responses
> inline.)
> >
> > On Thu, Nov 22, 2012 at 1:43 PM, Benjamin Poulain 
> wrote:
> >> On Wed, Nov 21, 2012 at 2:42 PM, Rick Byers 
> wrote:
> >>> Outside of the design details, are there any thoughts or concerns
> >>> about WebKit getting an implementation of pointer events at some
> >>> point?
> >>
> >> In my opinion, the pointer events spec is a bad idea (at least, in its
> >> current state). I think adding it to WebKit would be hurting both the
> Web
> >> and WebKit.
> >>
> >> The premise of the specification is that using mouse event and touch
> events
> >> interchangeably is needed. In reality, nobody was really asking for that
> >> because it is a terrible idea. You can already easily unify pen, touch
> and
> >> mouse by writing very little JavaScript, but it is only useful in very
> few
> >> cases.
> >>
> >> For the common case, where you want to use touch and mouse events
> >> differently, the pointer events makes it harder to write correct code.
> Each
> >> event have a set of attributes with different meaning depending on the
> event
> >> type.
>
> I agree with Benjamin's technical concerns about this feature. Combining
> the very different models of touch and mouse is a bad idea. They are
> distinct and for anything beyond the trivial, you really need to treat them
> separately to get a good outcome. The basic premise of pointer events seems
> to be over-abstraction at the expense of the user experience.
>
> >
> > I'm sympathetic to these concerns, but, unfortunately, I don't see any
> > other path that leads to interoperability with Internet Explorer.
>
> In principle, other things being equal, interop with IE would be better
> than not having it. But other things are not equal. Their proposal is
> technically unsound.
>
> Further, I do not much of a pragmatic interop concern in this case. IE is
> so far not very relevant on device classes that generally feature touch
> UI[*]:
> <
> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0&qpcustomd=1>.
> The trajectory of Microsoft's touch-oriented OS efforts does not seem
> likely to change this trend in the near future.
>
> Clearly Microsoft has looked at this data and decided interop with other
> browsers in this area is not very important to them, relative to other
> goals. That's so even with a significant disadvantage in market share and
> deployed content in the relevant addressable market. Given that, why should
> IE's interoperability be more important to us than it apparently is to
> Microsoft?
>
> In conclusion, I do not think interop with IE is more important here than
> technically correct design. I'd say interop trumps sound design only when
> there is a mass of deployed content backing up the interoperability need.
>
> Regards,
> Maciej
>
>
> [*] I know that Windows for desktop/laptop machines also supports
> touchscreens, and some hardware that's primarily meant for
> keyboard-and-mouse type traditional input also features a touchscreen as a
> potential extra source of input. But from what I can discern, this is more
> a neat gimmick than something that is truly compelling to users or
> something that Web developers are rushing to take advantage of. Content
> that is specialized for touch UIs is overwhelmingly authors for Android
> and/or iOS. If I'm wrong on that, then I'd like to see some actual data to
> the contrary.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] pointer events specification - first editors draft

[Rick Byers]

Hi,
The W3C pointer events working group [1] has put out their first
editors draft of the Pointer Events specification [2].  Pointer events
offer a number of advantages over the current mouse event + touch
event model in WebKit.  In particular, having apps state clearly and
declaratively [3] whether a touch that starts on an element should
result in browser behavior like scrolling or events which can be
handled from JavaScript is potentially a big win for touch scrolling
performance (something we struggle with in Chrome).  Also, with the
increasing sales of windows touch screen devices and adoption of IE10,
touch input compatibility with IE seems like a valuable goal.

If anyone here is interested in providing feedback on the pointer
events design, I'd encourage you to join the working group (or at
least post your comments to public-pointer-events [4]).  The most
significant missing piece from the specification is a description of
interoperability with touch events (similar to the section on mouse
events [5]), but I'm optimistic there will be something reasonable
here soon (Mozilla and Opera are both involved and so care about this
issue too).

Outside of the design details, are there any thoughts or concerns
about WebKit getting an implementation of pointer events at some
point?

Thanks,
   Rick

[1] http://www.w3.org/2012/pointerevents/
[2] http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html
[3] 
http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property
[4] http://lists.w3.org/Archives/Public/public-pointer-events/
[5] 
http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#compatibility-mapping-with-mouse-events
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Enabling support for high-dpi custom mouse cursors

[Rick Byers]

One of the few places WebKit still doesn't support high-DPI images is
custom 'cursor' CSS rules.  I brought this up on www-style awhile back [1]
and the consensus was that using image-set was the preferred mechanism.
 The CSS4 images draft spec now specifies that cursor can take any 
[2], including an image-set.

I'd like to take the first step by enabling -webkit-image-set support for
'cursor' rules on the chromium port (tracked in
http://wkb.ug/99493).
 I plan to add an ENABLE(CSS_CURSOR_SCALE) flag which adds a single 'float
scale' to WebCore::Cursor that specifies the scale factor (in display
pixels per logical pixel) of the custom image data in a Cursor object.
 It's conceivable that other mechanisms could also use this (for example,
we could select the most appropriate image from a multi-resolution .cur
file).

Any concerns or suggestions?  I've got a rough working version of a patch
which I will get up for review next week sometime.

Thanks,
   Rick

[1] http://lists.w3.org/Archives/Public/www-style/2012Jul/0140.html
[2] http://dev.w3.org/csswg/css4-images/#image-values
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Adding new CSS (pointer) and (hover) media features to WebCore

[Rick Byers]

Hi Webkit-dev,
I just wanted to let you know that I'm about to add initial support (
https://bugs.webkit.org/show_bug.cgi?id=87403) for two new minor CSS media
query features:
http://dev.w3.org/csswg/css4-mediaqueries/#pointer
http://dev.w3.org/csswg/css4-mediaqueries/#hover

Ports can opt into this support by providing information about the pointer
devices available, currently just via Settings:: setDeviceSupportsTouch
(currently used only by Chromium).  I plan to add a similar simple
mechanism for mouse in a later CL (
https://bugs.webkit.org/show_bug.cgi?id=87806).

Ports that don't opt in will continue to behave exactly the same as they do
today - as if the media feature wasn't supported at all.  Please let me
know if you have any questions or concerns.

Thank you!
   Rick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev