Re: [webkit-dev] Another WPT bite

2017-05-16 Thread 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

2017-05-12 Thread 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

2017-05-12 Thread 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)

2017-02-22 Thread 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 <wei...@apple.com> wrote:

>
> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
>
> On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers <rby...@chromium.org> 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)

2017-02-22 Thread 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

2013-06-10 Thread 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 benja...@webkit.orgwrote:

 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] PSA: higher precision event timestamp landing soon - port verification needed

2013-06-10 Thread Rick Byers 
On Mon, Jun 10, 2013 at 5:19 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On Mon, Jun 10, 2013 at 7:37 AM, Rick Byers rby...@chromium.org 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] Unprefixed and prefixed DOM events.

2013-01-14 Thread Rick Byers 
On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org wrote:

 On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org 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 aba...@webkit.org 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 ale...@webkit.org
 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

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

2013-01-14 Thread Rick Byers 
On Mon, Jan 14, 2013 at 9:56 AM, Alexis Menard ale...@webkit.org wrote:

 On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers rby...@chromium.org wrote:
  On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org
 wrote:
 
  On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org
 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 aba...@webkit.org
 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 ale...@webkit.org
   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

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

2013-01-12 Thread 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 aba...@webkit.org 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 ale...@webkit.org 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?

2012-12-07 Thread Rick Byers 
On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov apav...@chromium.orgwrote:

 On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth aba...@webkit.org wrote:

 On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov apav...@chromium.org
 wrote:
  On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org
 wrote:
  On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org 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 we were
testing all our high-dpi chrome work before we had retina hardware, we
wanted everything to be 2x bigger so we could spot low resolution images
(which was the most common issue).  If you use a 30 screen at twice the
normal viewing distance,

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

2012-12-07 Thread Rick Byers 
On Fri, Dec 7, 2012 at 10:53 AM, Alexander Pavlov apav...@chromium.orgwrote:

 On Fri, Dec 7, 2012 at 7:30 PM, Rick Byers rby...@chromium.org wrote:

 On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov apav...@chromium.orgwrote:

  On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth aba...@webkit.org wrote:

 On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov apav...@chromium.org
 wrote:
  On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org
 wrote:
  On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org
 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 we were
 testing all our high-dpi chrome work before we had retina hardware, we

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

2012-12-04 Thread Rick Byers 
 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 m...@apple.com wrote:



 On Nov 28, 2012, at 8:23 AM, Adam Barth aba...@webkit.org wrote:

  It looks like this thread got dropped over Thanksgiving.  (Responses
 inline.)
 
  On Thu, Nov 22, 2012 at 1:43 PM, Benjamin Poulain benja...@webkit.org
 wrote:
  On Wed, Nov 21, 2012 at 2:42 PM, Rick Byers rby...@chromium.org
 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=0qpcustomd=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

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

2012-12-04 Thread Rick Byers 
On Tue, Dec 4, 2012 at 2:28 PM, Benjamin Poulain benja...@webkit.org wrote:
 On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers rby...@chromium.org 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 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.


 Tell me where it is said touch events have to works like you described.
 Multiple implementations, running on phones, have very efficient scrolling
 despite having handling for touch events. I am amazed you made an argument
 out of this.

Nowhere does it say touch events have to work this way, that's part of
the point - much of the behavior of touch events is still undocumented
and unspecified.  If we're going to make the implementations better
while exposing a consistent model to applications, we need to document
this sort of thing somewhere.

Here is a stupid sample app

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

2012-11-21 Thread 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

2012-10-19 Thread 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 image
[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/99493https://bugs.webkit.org/show_bug.cgi?id=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

2012-05-29 Thread 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