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

2013-11-07 Thread Elliott Sprehn
On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote:

 On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

  On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com
 wrote:
  On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote:
  I've suggested before that the attributes could be combined if that's
  considered simpler. My only concern is that most developers aren't
 used to
  putting line breaks in html attributes, so might feel obliged to put
 all the
  alternatives on one line, harming readability. But as long as the
 developer
  documentation encourages line breaks, that could be fine...
 
  As I replied before, there should only be one attribute — srcset. Given
 that
  your micro format extends around parts of the existing micro format of
  srcset, it just makes sense to reuse the same attribute. Wishing srcset
  didn't exist doesn't make it go away.
 
  srcset doesn't significantly exist yet. It's in one browser's
  nightly.  I'd like to resolve this soon, but it doesn't help anything
  to pretend that it's already a done deal that must be engineered
  around.

 It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.


Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't
see srcset on HTMLImageElement. What do you mean it's shipped?

document.createElement('img').srcset is undefined.

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


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

2013-11-04 Thread Elliott Sprehn
On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote:

 99 is a very high upper bound while it would still allow us to implement
 the optimization we're thinking of.

 I'm of the opinion that we should use exactly one attribute for this
 feature.



Can you explain what this optimization is? It's difficult to figure out how
to address your issues without knowing what optimization it prevents.

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


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

2013-11-04 Thread Elliott Sprehn
On Mon, Nov 4, 2013 at 4:55 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Mon, Nov 4, 2013 at 3:12 PM, Elliott Sprehn espr...@chromium.orgwrote:

 On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote:

 99 is a very high upper bound while it would still allow us to implement
 the optimization we're thinking of.

 I'm of the opinion that we should use exactly one attribute for this
 feature.


 Can you explain what this optimization is? It's difficult to figure out
 how to address your issues without knowing what optimization it prevents.


 I'm not sure if I wasn't clear here but I'm saying that having an upper
 bound of 9 or 99 would address the concern of not being able to implement
 the particular optimization we're considering.


Yeah; what optimization do you plan to implement though?



 Completely separate from that concern, I don't want us to add more than
 one content attribute to address the use cases src-N proposal addresses for
 the API's sake although I wouldn't firmly object to it if there is a broad
 consensus that this is a feature we want in WebKit.

 However, I don't think that there is such a consensus amongst the WebKit
 community yet as far as I've been following this thread. As such, I DO NOT
 support implementing this feature in WebKit.

 - R. Niwa


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


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-06-19 Thread Elliott Sprehn
On Wed, Jun 19, 2013 at 9:46 AM, Andreas Kling akl...@apple.com wrote:

 On Jun 19, 2013, at 6:37 PM, Timothy Hatcher timo...@apple.com wrote:

 What about?

 StyleResolver* existingStyleResolver()
 StyleResolver styleResolver()



This doesn't make sense since calling styleResolver() again won't create a
new one so it's also existing style resolver.

I rather like the foo() and ensureFoo() methods. foo() is just a plain
getter like any other method, the class may start with:

setFoo(Foo*);
Foo* foo();

later we want to also allow optionally created when needed so we add:

Foo* ensureFoo();

The current naming and methodology makes a lot of sense. fooIfExists()
always bugs me because there's no reason to decorate a getter that is just
a plain getter. Adding an ensureFoo() method shouldn't make me rename the
existing foo() method to fooIfExists().

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


Re: [webkit-dev] What do we do with various Web component features?

2013-04-29 Thread Elliott Sprehn
On Mon, Apr 29, 2013 at 10:30 AM, Anders Carlsson ander...@apple.comwrote:


 ...

 +1

 From what I’ve heard, the Shadow DOM changes have negatively impacted the
 packability of the DOM code which is unfortunate. I’m all for removing it.


Could you elaborate on what you mean by the packability of the DOM code?

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


Re: [webkit-dev] Test frame size for reftests

2013-04-24 Thread Elliott Sprehn
On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke dpra...@chromium.org wrote:


 ...


 I think this raises two related questions, both of which would be helped
 by concrete examples:

 1) What sort of test are you writing where 800x600 isn't big enough to
 test what you need to test?

 2) What sort of test are you writing where there's needs to be something
 on the page not included in the test
 *and* will render differently in different browsers?

 I can posit the existence of both sorts of things, but I'm not sure when
 they arise in practice?



I've seen tests before that have lots of form controls where a bunch were
outside the viewport.

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


Re: [webkit-dev] Test frame size for reftests

2013-04-24 Thread Elliott Sprehn
On Wed, Apr 24, 2013 at 3:31 PM, Dirk Pranke dpra...@chromium.org wrote:




 On Wed, Apr 24, 2013 at 3:29 PM, Elliott Sprehn espr...@chromium.orgwrote:

 On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke dpra...@chromium.orgwrote:


 ...


 I think this raises two related questions, both of which would be helped
 by concrete examples:

 1) What sort of test are you writing where 800x600 isn't big enough to
 test what you need to test?

 2) What sort of test are you writing where there's needs to be something
 on the page not included in the test
 *and* will render differently in different browsers?

 I can posit the existence of both sorts of things, but I'm not sure when
 they arise in practice?



 I've seen tests before that have lots of form controls where a bunch were
 outside the viewport.


 Sure, you *can* write such tests. Did you *have to*?


Certainly not, I just know such tests already exist.

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


Re: [webkit-dev] RenderLayer::isStackingContext() confusion

2013-04-03 Thread Elliott Sprehn
The function does what it says, it's just not obvious why:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/css/StyleResolver.cppsq=package:chromiumtype=csq=adjustRenderStylel=1469

First we set the z-index to be auto for static position elements. Next we
set the z-index to be 0 for elements based on the big set of cases in
adjustRenderStyle, and then you can tell in RenderLayer if you're a
stacking context based on if you have z-index != auto.

I'd add a comment explaining. The alternative is to check that big set of
cases every time someone calls isStackingContext but that might be slower.
Changing the name of the method would make the code more confusing, since
it is checking the right thing just through some complicated process.


On Wed, Apr 3, 2013 at 3:48 PM, Shawn Singh shawnsi...@chromium.org wrote:

 Background:

 According to CSS 2.1 spec, an element becomes a stacking context when:
   - it is positioned  (relative, absolute, or fixed)
   - and it has a non-auto z-index

 Spec also mentions that there's room for expanding this definition; the
 examples I know about are fixed-position elements and elements with
 transforms.


 Questions:

 The implementation of RenderLayer::isStackingContext() looks fishy.  It
 only checks for a non-auto z-index.  It does not check for the positioning
 style of the layer.  There is no indication that it checks for any more
 recent special cases such as fixed-position or transforms.

 Is this function name a misnomer?  should it actually be renamed to
 hasNonAutoZIndex() ?

 If the additional criteria is not being checked inside this helper
 function, then where is it?  I see some code in collectLayers that looks
 vaguely similar to checking whether an element is positioned, but what
 about all the other uses of isStackingContext everywhere?

 Thanks!
 Shawn

 ___
 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] Disable the automated markup fixes

2013-04-02 Thread Elliott Sprehn
This is just the behavior of the HTML5 parser not something special about
webkit. Why do you want to turn it off?



On Tue, Apr 2, 2013 at 6:58 PM, Aaron Lewis the.warl0ck.1...@gmail.comwrote:

 Hi Ben,

 Thanks for reply,

 But I checked the source code, the createMarkup function is from
 WebCore, so it's not about QtWebkit, right?

 Correct me if I'm wrong 

 On Wed, Apr 3, 2013 at 9:57 AM, Benjamin Poulain benja...@webkit.org
 wrote:
  On Tue, Apr 2, 2013 at 6:53 PM, Aaron Lewis the.warl0ck.1...@gmail.com
  wrote:
 
  I'm running a test app with QtWebkit, looks like webkit is attempting
  to fix invalid markups automatically,
 
  For page contents like this,
  [...]
 
 
  Wrong mailing list.
 
  This is the QtWebKit mailing list:
  https://lists.webkit.org/mailman/listinfo/webkit-qt
 
  Benjamin



 --
 Best Regards,
 Aaron Lewis - PGP: 0xDFE6C29E ( http://keyserver.veridis.com )
 Finger Print: 9482 448F C7C3 896C 1DFE 7DD3 2492 A7D0 DFE6 C29E
 ___
 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] Ever increasing binary size

2013-03-22 Thread Elliott Sprehn
I'd be really interesting to see what patches are causing the growth and by
how much. I wonder how much of this is from some of the fancier template
things we have (ex. the 600 template expansions from StyleBuilder)


On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel e...@webkit.org wrote:

 It seems like it should be trivial to set up an EWS bot to track size
 changes.

 It would (sadly) need to clobber, as my understanding is that
 incremental builds are not deterministic in their sizes:
 https://code.google.com/p/chromium/issues/detail?id=110002
 (our bug about this for Chromium Try servers).

 Thankfully the EWS is very well suited for this task.

 On Fri, Mar 22, 2013 at 1:29 AM, Benjamin Poulain benja...@webkit.org
 wrote:
  On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org wrote:
 
  WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB.
  WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB.
 
  Our binary size increased by 7.2% in just 4 months.
 
 
  I have been tracking this issue for a bit. I can send more detailed view
 of
  the growth if anyone is interested.
 
 
  Is this a problem?  I think it is. It means that we use more RAM when
  WebKit is loaded onto memory. It means that it takes longer to load
 WebKit
  into RAM. It means that auto-update, etc... various browsers that use
 WebKit
  needs to send more data over the network.  6MB costs you a ton if you're
  wiring over cellar network.
 
 
  RAM space is not the only problem we have with big binaries. The bigger
 our
  code gets, the less efficiently we use the fast CPU caches and WebKit
 gets
  slower over time overall.
 
  On embedded, you typically have tiny caches and slower memory. This
 leads to
  a lot of memory pressure and we had to cut binary size sometimes to get
 the
  performance back.
 
  What strategies can we use to address this problem?
 
 
  I would like it if EWS could report growth and shrinkage somehow, and
 have a
  warning in case of abnormal growth.
 
  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

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


Re: [webkit-dev] Best way to disable JavaScript

2013-03-18 Thread Elliott Sprehn
On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote:

 ...
 There are problems with mode (2):

 * It breaks features that are implemented in JavaScript.

 The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
 autofill all run JavaScript. This means that they break when users disable
 JavaScript.


The web inspector works even with JS disabled in Safari (I filed the very
first bug about this actually back when it crashed :)) and I just tested
and Reader works fine too.

Are there any examples of browser provided UI that actually breaks with JS
disabled? I'm pretty sure those all run in different worlds.

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


Re: [webkit-dev] New web-facing canvas feature: opaque attribute

2013-03-13 Thread Elliott Sprehn
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does globalAlpha
still work?

It's sad that WebGL picked such a generic name that isn't about all alpha
related things.


On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com wrote:

 The main reason for this feature is to enhance performance of canvas
 operations.
 Are we certain that this will always be the case? For instance, is google
 going to make certain that the cairo and core graphics backends don't slow
 down?

 Rik


 On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com wrote:

 I think opaque vs. alpha: false is a matter of opinion. The
 functionality doesn't change, regardless of what you call it.

 I agree with Gregg that this really should be implemented to reflect the
 functionality that WebGL already has. Wether 2D or 3D, there's a lot of
 common ground between the various canvas contexts and it doesn't make much
 sense to reinvent the wheel when one context type has already implemented
 the functionality.

 --Brandon


 On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:


 An attribute on the canvas element would presumably be equally
 applicable to all contexts. Is there a reason that it's better to have
 opaqueness specified at context creation time instead of on the canvas?
 Also, I think opaque is easier to understand than alpha: false.

  - Maciej

 On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:

 It would be nice if this was the same as WebGL instead of different.
 Especially because 2d canvas and WebGL need to inter-operate in the near
 future.

 In WebGL to create a canvas with no alpha (an opaque canvas) you do this

gl = canvas.getContext(experimental-webgl, { alpha: false });

 Why can't 2D canvas be this

ctx = canvas.getContext(2d, {alpha: false});

 As for why this is important to be the same see the proposal for Canvas
 in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)

 In that proposal the backingstore of a canvas can be moved to/from a
 worker. That solution may or many not be the final solution but it points
 out that whatever solution is chosen we need the solution to work for both
 canvas 2d and WebGL and as such needs a common way to create backing stores
 with no alpha.



 On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@adobe.com
 wrote:

 This is a very long thread and I did not see any conclusions or
 agreement on this thread. Can you summarize the topic and the status on the
 acceptance level please?

 Greetings,
 Dirk

 On Mar 13, 2013, at 9:15 AM, Stephen White senorbla...@chromium.org
 wrote:

  Hi WebKittens,
 
  I'm planning to implement the canvas opaque attribute, as proposed
 here:
 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html
 .
 
  This is an attribute that causes the allocation of an opaque backing
 store for canvas, allowing optimizations at the time the canvas is
 composited into the page, such as disabling blending and culling obscured
 content.  It is based on the moz-opaque attribute currently shipping in
 Firefox.
 
  I'll be placing the feature behind the build-time flag
 ENABLE(OPAQUE_CANVAS).
 
  Let me know if you have any comments or concerns.
 
  Stephen
  ___
  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



 ___
 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


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


Re: [webkit-dev] Feature Proposal: Implement Stream and StreamReader

2013-02-19 Thread Elliott Sprehn
This API seems like it's in an inconsistent state with the other web
platform features going on right now.

ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for
a constructor for Blob.

It's a bit concerning that we're going to add this feature, and then
perhaps change it, and then need to go through the how long does it take
to deprecate features cycle again.

What's the plan for turning this on?


On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia z...@chromium.org wrote:

 Hi webkit-dev!

 I'm currently working on adding support for Stream and StreamReader to
 WebKit.
 https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

 This support will be behind the ENABLE_STREAM feature define.

 I have a prototype which implements readAsArrayBuffer() from an XHR
 connection at:
 https://bugs.webkit.org/show_bug.cgi?id=110194

 Tests will be added as I change it to a real implementation.

 Cheers,
 -Zach

 ___
 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] Feature Proposal: Implement Stream and StreamReader

2013-02-19 Thread Elliott Sprehn
Darin Fisher pointed out to me that this is about Stream and StreamReader
per the subject, not StreamBuilder (which is not planned to be implemented
yet).

So sounds good to me! :)


On Tue, Feb 19, 2013 at 1:28 PM, Elliott Sprehn espr...@chromium.orgwrote:

 This API seems like it's in an inconsistent state with the other web
 platform features going on right now.

 ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for
 a constructor for Blob.

 It's a bit concerning that we're going to add this feature, and then
 perhaps change it, and then need to go through the how long does it take
 to deprecate features cycle again.

 What's the plan for turning this on?


 On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia z...@chromium.org wrote:

 Hi webkit-dev!

 I'm currently working on adding support for Stream and StreamReader to
 WebKit.
 https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

 This support will be behind the ENABLE_STREAM feature define.

 I have a prototype which implements readAsArrayBuffer() from an XHR
 connection at:
 https://bugs.webkit.org/show_bug.cgi?id=110194

 Tests will be added as I change it to a real implementation.

 Cheers,
 -Zach

 ___
 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] WebKit2/Mac and C++11

2013-01-30 Thread Elliott Sprehn
Thanks for the advance warning! :)

- E


On Wed, Jan 30, 2013 at 3:17 PM, Anders Carlsson ander...@apple.com wrote:

 Hello!

 This is just a friendly heads-up that the Mac specific parts of WebKit2
 will soon start requiring C++11 features (move semantics and variadic
 templates being the two most important).

 Any recent version of Xcode (4.2 or later) should support this, and we're
 already building all of WebKit2 as C++11 on Mac anyway.

 - Anders
 ___
 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] Can we remove Notification.show()?

2013-01-28 Thread Elliott Sprehn
This seems like a badly designed API, constructors shouldn't have side
effects and not having show() means after calling close() the notification
object is useless which is silly.


On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson atwil...@google.com wrote:

 So, we've recently landed some fixes to address permissions handling for
 Notification.show(): http://trac.webkit.org/changeset/140927

 Turns out, the notifications specification does not have a show() API (the
 notification is automatically shown from the constructor --
 http://notifications.spec.whatwg.org/#api). Does anyone have any
 objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS
 flag to bring us under compliance with the spec?

 Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs, not
 only do they get support for the old webkitNotifications API, but also some
 of the old API (like show() and cancel()) is exposed on the new
 Notifications objects, because we share the same interface for
 webkitNotifications and Notifications. Do we care (will this make it harder
 to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start
 using those APIs on the new Notifications objects)?

 -atw

 ___
 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
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Elliott Sprehn
Perhaps the time to remove ENABLE_SVG is in several years once many pages
depend on it and disabling it results in a busted browser...


On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar ararunpra...@gmail.com
 wrote:

 Eric, Most of the resource constraint environments(embedded systems) still
 disables the SVG. If the define is removed code size of WebKit will be
 increased by atleast 3 to 4M.


 On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote:

 This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393

 Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
 defines (and potentially unifying SVG and HTML style resolve more
 closely)?

 --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad

 ___
 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] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Elliott Sprehn
On Fri, Jan 25, 2013 at 8:09 PM, Dirk Schulze dschu...@adobe.com wrote:


 On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak m...@apple.com wrote:

 
  On Jan 25, 2013, at 4:13 PM, Adam Barth aba...@webkit.org wrote:
 
  On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com
 wrote:
  On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
  On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com
 wrote:
  This is a followup to the multiple inheritance discussion.
 
  Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2
 do not have multiple inheritances of interfaces that are exposed to
 bindings. But SVG2 still uses the implements statement for
 [NoInterfaceObject] interfaces [2]. This should at least address your
 initial concern not to inherit from different interfaces exposed to
 bindings.
 
  However, during a discussion on IRC I got the impression that we do
 not plan to support the implements statement because it can do weird
 things. If this is right, I would like to understand why this is the case?
 
  We don't intend to support all the possible things that you can do
  with implements.  With implements, you can define arbitrarily
  complicated relationships between interfaces, including some that can
  be implemented only with a QueryInterface-like mechanism.  We're not
  going to implement QueryInterface, so we're not going to implement any
  specifications that require it.
 
  This sounds that you consider having implements in our WebIDL
 interpreter, or at least would not block adding this per se. This was my
 concern in the first place, since this is already in use in a lot of
 specifications (just with [NoInterfaceObject] as far as I saw).
 
  WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
  compiler.  If you spec something that requires a QueryInterface-like
  mechanism in the implementation, we will not implement it regardless
  of what language you write the specification in.  It's a conscious
  design decision not to implement a COM-like (or XPCOM-like) system.
 
  Setting aside the more general question, does the SVG2 set of interfaces
 effectively require a QueryInterface-like mechanism? What limitations, if
 any, on the use of implements would a spec have to follow to dodge this
 bullet? SVG2 is still evolving, so I suspect it could adjust its use of
 implements if it's an issue for us.

 SVG2 does not require any inter process communication. The QueryInterface
 was an example of Adam what we should not implement. SVG2 uses WebIDL's
 implements statement for [NoInterfaceObject] interfaces, as the HTML
 specification is doing it. But SVG uses multiple implements statements
 per interface:

 interface SVGViewSpec
  {
   readonly attribute SVGTransformList transform;
   readonly attribute SVGElement viewTarget;
   readonly attribute DOMString viewBoxString;
   readonly attribute DOMString preserveAspectRatioString;
   readonly attribute DOMString transformString;
   readonly attribute DOMString viewTargetString;
 };
 SVGViewSpec implements SVGFitToViewBox;
 SVGViewSpec implements SVGZoomAndPan;

 SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.

 I hope that I am not mistaken and that this is not what you mean with
 QueryInterface.


Since they're NoInterfaceObjects we can just merge the idl into the file in
WebKit or use Supplemental in WebkitIDL. You've written it with multiple
implements to be DRY in the WebIDL, that's not a problem for WebKit.

See: HTMLInputElementFileSystem.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Elliott Sprehn
On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze dschu...@adobe.com wrote:

 ...
 The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
 are implemented by a lot of other interfaces as well. Supplemental is just
 supposed to be set once per interface. That is why Supplemental doesn't
 work for SVG. The alternative would be to implement the attributes and
 operations of SVGFitToViewBox and SVGZoomAndPan into every class that
 implements them. This would be a lot of code copies. And these are not the
 only interfaces that would need to be merged.


That's an issue of being DRY though, which we can certainly solve in
WebKit. I don't think Adam has an issue with extending webkit IDL to help
with that, or at least I'd hope not.

We could probably use multiple inheritance in C++ and copy/paste the idl
defs, or add some new IDL feature for it.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal to remove list-item special counter

2013-01-16 Thread Elliott Sprehn
On Wed, Aug 15, 2012 at 3:50 PM, Darin Adler da...@apple.com wrote:

 On Aug 15, 2012, at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:

  WebKit is the only browser that implements the magic counter named
 list-item and we have no tests for it.

 Seems like we really ought to add some tests for it.

  It's not useful since we don't support the ::marker pseudo element

 Maybe it can’t be used for its best and most obvious uses without
 ::marker, but it still work and can be used for some things. Here’s an
 example of it doing some good:

 style #list-count:before { counter-increment: list-item -1; content:
 counter(list-item); } /style
 ol
  liA/li
  liB/li
  liC/li
 /ol
 The list above has span id=list-count/span items in it.

 I’m still OK with removing it if there is an argument that the current
 implementation does more harm than good.


I've scoured the web and can't find any reference to anyone using it,
mention of it's usage on any pages and no other browser supports it. In
terms of harm, it adds implementation complexity, especially when I want to
rewrite counters to be much simpler and faster.

I'd like to go ahead with the removal and then we can bring this back if
developers show interest. Does that sound reasonable?

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

2012-12-21 Thread Elliott Sprehn
On Fri, Dec 21, 2012 at 6:09 AM, Antti Koivisto koivi...@iki.fi wrote:

 On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 No, it's just a refactoring on the CSS side, so we don't have to
 repeat a bunch of stuff every time we have an at-rule that contains
 other rules.  It just makes the WebIDL easier and less error-prone.


 It seems bit strange to add a web-exposed type if it is just a spec
 writing helper. Each new type has non-zero cost (code size of generated
 bindings etc).

 Internally it obviously makes sense to share code, I'm just wondering why
 we would want to expose this via API.


It means you can add methods to the prototype across all the types, and you
can override methods across the types per the way they're described in IDL.
It also provides instanceof for type checking in JS.

If we're not going to expose it and be spec compliant then perhaps we
should take that up with the spec as an objection and see if they're
willing to use a NoInterfaceObject instead.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Behaviour of CapsLock in WebKit/Mac

2012-12-12 Thread Elliott Sprehn
This same bug exists in Gecko
https://bugzilla.mozilla.org/show_bug.cgi?id=712535

It appears Cocoa just doesn't notify of this:
http://stackoverflow.com/questions/12536356/how-to-detect-key-up-or-key-release-for-the-capslock-key-in-os-x

so we'd probably need to interact directly with the HID manager... and then
hope it's not at that level too :)


On Wed, Dec 12, 2012 at 10:43 AM, Wez w...@chromium.org wrote:

 Thanks Mark!

 If this is intentional behaviour of Mac OS X then ideally WebKit should
 work around it, but I wonder how much existing content that would break?


 On 11 December 2012 21:32, Mark Rowe mr...@apple.com wrote:


 On 2012-12-11, at 21:24, Wez w...@chromium.org wrote:

  Hi all,
 
  There's a bug reported against Chromium (crbug.com/144757) for the
 CapsLock key generating only a keydown when first pressed and released, and
 a keyup when next pressed and released, i.e. the keydown  keyup events
 correspond with the caps lock-state being toggled, rather than with the key
 itself being pressed or released.
 
  The same issue reproduces against Safari on Mac.  Is this a by-design
 behaviour of WebKit?

 It’s a known issue (https://bugs.webkit.org/show_bug.cgi?id=18792).

 - Mark



 ___
 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] Rolling out a patch requires a justification beyond a test failure in downstream projects

2012-12-11 Thread Elliott Sprehn
Do you have an example of when this has occurred? It's good to have
examples if we want to prevent this in the future.


On Tue, Dec 11, 2012 at 1:44 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi,

 I've encountered a couple of incidences where people roll out patches
 saying that test X is failing on some downstream project Y without giving
 any details as to how those tests are failing and why that's a real WebKit
 regression we should care about.

 First off, I don't think we should be rolling out patches based solely on
 a downstream test unless there is a clear evidence that the failure is a
 real regression in WebKit that affects more than just the said downstream
 project. You may talk to the author and he or she might be nice enough to
 agree to roll out the patch, but I don't think we should be rolling out
 patches right away regardless.

 Second, if there is a clear WebKit regression, then you should communicate
 the following information at minimum:

1. The exact location of the test that failed - URL, etc...
2. The nature of the failure - assertion failure, feature it's
testing, etc...
3. The output (before and) after the failure started happening.
4. Instructions to run the tests locally

 Without this, the author is left with no clue whatsoever
 to diagnose and/or fix the problem.

 - R. Niwa


 ___
 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] Behaviour of CapsLock in WebKit/Mac

2012-12-11 Thread Elliott Sprehn
Does this reproduce on every platform? If it's a OS X issue then it should
work on Windows or Linux I'd hope.

- E


On Tue, Dec 11, 2012 at 9:32 PM, Mark Rowe mr...@apple.com wrote:


 On 2012-12-11, at 21:24, Wez w...@chromium.org wrote:

  Hi all,
 
  There's a bug reported against Chromium (crbug.com/144757) for the
 CapsLock key generating only a keydown when first pressed and released, and
 a keyup when next pressed and released, i.e. the keydown  keyup events
 correspond with the caps lock-state being toggled, rather than with the key
 itself being pressed or released.
 
  The same issue reproduces against Safari on Mac.  Is this a by-design
 behaviour of WebKit?

 It’s a known issue (https://bugs.webkit.org/show_bug.cgi?id=18792).

 - Mark

 ___
 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] Prefix naming scheme for DOM-exposed functions

2012-12-07 Thread Elliott Sprehn
This seems like it would introduce bugs and make maintaining the DOM harder
since we'd need to duplicate logic. Right now we have appendChild() and
parserAppendChild(), and using parserAppendChild() for anything not in the
parser introduces web observable bugs and changes in behavior. We also only
have tests for the web exposed methods, unless you're suggesting we add C++
unit tests too? :)

Can you give an example of what you want to change in the non web exposed
appendChild() ?


On Fri, Dec 7, 2012 at 9:27 AM, Darin Adler da...@apple.com wrote:

 Hi folks.

 Many of the APIs designed for use in the DOM are not efficient for use
 inside WebKit, or have designs that are better for JavaScript than for C++.
 Antti Koivisto and I have been discussing how to best communicate this to
 WebKit contributors so they don’t end up using inefficient idioms just
 because they are familiar with them from use in JavaScript code on
 websites. So far, our best idea for this is to add a prefix to function
 names that indicate they are functions for use by the bindings machinery.
 Thus, a function like appendChild would get a new name:

 void bindingsAppendChild(Node*, ExceptionCode);

 The internal function that’s used to add a child node would be designed
 for the best clarity, ease of use, and efficiency within WebKit
 implementation code, even when that does not match up with the DOM
 standard. And could be refactored over time as WebKit design changes
 without affecting the bindings.

 - It’s not clear what the best prefix is. I don’t like the prefix “dom”,
 since it’s a lowercased acronym and an overloaded not all that precise
 term. The prefix “bindings” is sort of silly because these functions are
 not themselves “bindings”, rather they are the non-language-specific
 functions designed to be bound to each language. However, I do like the
 idea of a brief non-acronym word. So, still looking for a great prefix.

 - When appropriate, these exposed functions can be short inline functions
 that turn around and call internal functions.

 - These functions aren’t needed at all to implement reflected content
 attributes. Hooray!

 - So far my best idea on how to stage this is to new inlines without
 cutting the bindings over to them. Then cut the bindings generation script
 over, then remove and refactor the various unneeded underlying functions.
 Other ways to stage this would be add an attribute so we can can switch a
 class or a function at a time over to the new naming scheme, but base
 classes could make that process challenging and needlessly complex.

 - We don’t want to use ExceptionCode arguments much in internal
 functions. They lead both to confusing code and to inefficiency, and I
 think we can do much better without them. But they are still probably a
 good efficient way to indicate the need for an exception to the JavaScript
 binding. We’d eliminate ASSERT_NO_EXCEPTION as part of this.

 - This will be particularly helpful for future optimizations, such as one
 we are contemplating that will make currently-heavily-used functions such
 as firstChild more expensive, and currently-lightly-used functions such as
 firstElementChild cheaper. We need a way to rename such things and find
 internal callers and prevent people from accidentally undoing that effort
 as they do additional WebKit work.

 -- Darin
 ___
 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] RenderArena: Teaching an old dog new tricks

2012-11-15 Thread Elliott Sprehn
On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans cev...@chromium.org wrote:


 ...


 My read on the Arena is that it's fragmentation resistant (i.e. it will
 not repurpose a larger free chunk to satisfy a smaller allocation.)
 However, memory usage at any given time is defined by peak usage since it
 cannot release pages back to the system without ruining its security
 guarantee. Interestingly, it can't be super bad: we already bite this
 bullet for RenderArena as used by RenderObjects. The RenderArena lifetime
 is the same as the document / DOM and I was surprised to recently be told
 that we don't throw away the RenderArena on a full layout.


My understanding is that the render tree is rather small compared to the
DOM in terms of memory usage on most pages so not releasing it may not be
so bad, but never releasing the memory used from DOM nodes seems like it'd
be bad for large web apps.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] RenderArena: Teaching an old dog new tricks

2012-11-14 Thread Elliott Sprehn
I was present for one of the discussions about the exploit and how an arena
like allocator could have helped at Google. One proposed solution was to
allocate all the JS typed buffers in an arena.

Is there a reason we can't just do that? It's much less intrusive to
allocate ArrayBuffer in an arena than to allocate all DOM objects in one.

- E


On Wed, Nov 14, 2012 at 11:16 PM, Maciej Stachowiak m...@apple.com wrote:


 Following up on a bugzilla discussion:

  It is indeed significant that only a small number of classes are
 allocated within RenderArena. For example, when there's a RenderObject
 which has been freed but is still in use, it's not possible for the
 attacker to allocate (e.g.) a raw ArrayBuffer contents on top of the freed
 slot. So the attacker cannot place arbitrary bytes on top of where the
 vtable pointer is expected to be. We've made sure that the first
 sizeof(void*) bytes either point to a valid vtable pointer, or are a
 poisoned freelist pointer, or are an invalid pointer in the case that one
 of the (few) non-virtual classes is overlaid.
 
  It's essentially about limiting the attacker's possibilities when the
 inevitable rendering use-after-frees occur. There are some other non vtable
 related possibilities that get limited too.

 Interesting! How much value would be derived from allocating all classes
 with a virtual method in a separate heap from classes with no vtable and
 raw data buffers? And how much is specifically due to a more limited range
 of classes that may be present in the RenderArena? If classes with vtables
 getting overwritten by arbitrary data are the top fear, then there is
 probably a more modest solution than RenderArena. It could still cause
 additional memory fragmentation, but probably less so than RenderArenas.

 Regards,
 Maciej

 ___
 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] RenderArena: Teaching an old dog new tricks

2012-11-14 Thread Elliott Sprehn
On Thu, Nov 15, 2012 at 1:29 AM, Ryosuke Niwa rn...@webkit.org wrote:

 ...
 In other words, why are you interested in using the proposed allocation
 mechanism for only DOM nodes/objects instead of everything in
 WebCore/WebKit?


This was my concern as well. It would seem you'd need many different
arenas, and that would only make it really annoying to get use after frees
since they have to be in the same arena, not impossible.

The major danger is really ArrayBuffer (and I suppose String) which lets
you allocate an object of a specific size and aligned the same as the freed
object. You can then create thousands of them until you get one on top of
the freed location and fill in the buffer with the malicious vtable and ptr.

How hard would it be to allocate the void* buffer and the String UChar*
with an arena?

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Adding Web Animations to WebCore

2012-11-08 Thread Elliott Sprehn
I'd also like to object to this as the API is very complicated and doesn't
seem incremental or like it fits with existing platform features.

Also the naming of things is inconsistent and messy. Why are half the
interfaces and properties  abbreviated and half of them not?

This doesn't feel baked enough.

- E
 On Nov 8, 2012 4:45 PM, Dean Jackson d...@apple.com wrote:


 On Nov 8, 2012, at 4:11 PM, Douglas Stockwell dstockw...@chromium.org
 wrote:

 I wanted to let you know that work has begun on implementing Web
 Animations in WebKit. New code for this effort will be landed behind the
 ENABLE_WEB_ANIM feature define and a runtime setting. We expect to be
 turning this define on for Chromium buildbots so there will be build and
 test coverage as the new functionality is added.

 The current Editor’s Draft for Web Animations is available at:
 https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html

 The implementation will be tracked by a meta bug:
 https://bugs.webkit.org/show_bug.cgi?id=101660


 As well as Maciej's concerns, I'd like to add that we already have three
 non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I
 think we need to clean this up before adding any more complexity.

 I do very much support the idea of an animation API though.

 Dean



 ___
 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] moving focus when clicking on scrollbars

2012-11-01 Thread Elliott Sprehn
On Thu, Nov 1, 2012 at 4:42 AM, Maciej Stachowiak m...@apple.com wrote:
 ...
 Is our current behavior the same as the every browser engine, except Gecko 
 behavior described above?

Yes.

- Native *never* moves focus, even if the control is focusable (ex.
the wireless networks list in OS X Preferences.app)

- Trident, WebKit and Presto blur the activeElement when clicking a
scrollbar even if the element with the scrollbar is not focusable.
This results in the body being focused.

- Gecko *only* blurs the activeElement if the element with the
scrollbar is focusable (ex. overflow div + tabindex). That is, Gecko
will only blurs if the focus can be transfered to the scrollbar owner.


 I like the idea of being more like native control behavior.

I agree. I'll update the patch to match Gecko's mostly native, but web
friendly behavior.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Making more use of ScriptWrappable

2012-11-01 Thread Elliott Sprehn
On Thu, Nov 1, 2012 at 2:09 PM, Kentaro Hara hara...@google.com wrote:
 ...

 Thanks to the recent efforts of Adam Barth, V8 bindings are going to
 remove the need to enumerate all wrappers, and thus the HashMap does
 not need to store all wrappers. On the other hand, what about JSC
 bindings?


JSC has a map per world, and the main world wrappers are stored in the
ScriptWrappable, not in the map. Only Node's are ScriptWrappable it
seems.

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSDOMBinding.hl=137

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.hl=42

I'm not sure why setInlineCachedWrapper takes a Node* specifically, it
should just take a ScriptWrappable* so Adam's change works for JSC
too.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-26 Thread Elliott Sprehn
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
 ...

 I agree this is a good change but it appears that we should add more
 cache/loader tests before changing DRT's behavior given that there are
 active contributors who rely on the current DRT behaviors to detect
 regressions.


Can we add a flag to control this behavior? Then Antti could run the
tests without cache clearing when modifying things possibly related to
the cache code. We could even run a separate cr-linux bot like we do
for debug builds.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-25 Thread Elliott Sprehn
This requires weird contortions in the DOM and Render tree and removes
nice guarantees.

For example Node.h has:

TreeScope* treeScope() const;
Document* document() const;
Node* childNode(unsigned index) const;

Returning a const Document* or Node* from childNode makes the DOM
API's suddenly less useful, and marking them as non-const is
confusing. These methods shouldn't be making mutations and the
compiler should enforce that (or at least try to), and the const is also good
documentation.

On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting pkast...@google.com wrote:
 On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling kl...@webkit.org wrote:

 So, I propose that we allow only these two signature formats for raw
 pointers:

 - const Foo* foo() const;
 - Foo* foo();

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Adding high resolution platform timestamp to DOM events

2012-10-24 Thread Elliott Sprehn
This doesn't appear to be in any standard yet. You should probably send
something to public-webapps or the whatwg list and make sure others are
onboard for the idea before exposing it to the web.

On Wed, Oct 24, 2012 at 6:17 PM, Robert Flack fla...@chromium.org wrote:

 Hi webkit-dev,

 I would like to add platform timestamps to DOM events as the systemTime
 property. I have a patch implementing the feature:
 https://bugs.webkit.org/show_bug.cgi?id=94987. This will let us know the
 time at which the system received an event to be able to accurately handle
 it, whereas the timestamp property gives the time the DOM event was created
 in an inaccurate milliseconds since 1970 form. This has been discussed on
 www-dom (http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html)
 and www-perf (
 http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html)
 and use cases for this have been discussed (
 http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html).

 The platform timestamp comes in as a monotonic timestamp. Since the DOM
 Event spec requires that timeStamp() be a 1970-epoch based timestamp it is
 not sufficient for a high resolution precise time delta on event delivery.
 Instead, we add a systemTime property which uses the Performance API spec (
 http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html)
 for high res timestamps (time since document load timestamp to avoid user
 fingerprinting) and provide the platform's high resolution timestamp to
 ECMAScript.

 Let me know if you have any suggestions. I look forward to everyone's
 feedback, cheers!
 - Rob

 ___
 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] Improving DOM Exception console messages.

2012-10-02 Thread Elliott Sprehn
Even so what we have right now can be improved without exposing sensitive
information. For instance HIERARCHY_REQUEST_ERR or SYNTAX_ERR is really
useless, it would be much nicer to have the tag name and what was really
wrong.

As a current example, if you create a MutationObserver with the wrong
dictionary arguments you get a useless error message.

o = new WebKitMutationObserver(function() {})
o.observe(node, {});
// SYNTAX_ERR: wtf is really wrong?

I don't think we need to wait for interop here, we can just give you
sensible error messages.

On Mon, Oct 1, 2012 at 6:21 PM, Ryosuke Niwa rn...@webkit.org wrote:

 To make my position clear, I support improving the error messages on
 Inspector. I'm just worried about exposing that to the Web because this
 area is already terribly under-spec'ed.


 On Mon, Oct 1, 2012 at 5:48 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Mon, Oct 1, 2012 at 5:18 PM, Ojan Vafai o...@chromium.org wrote:

 This isn't spec'ed anywhere. I agree it would be ideal to get a spec for
 this, but I don't think we need to block on that in this instance.


 I would like to see us posting this on public-webapps or www-dom. I've
 seen js code that tried to parse exception messages to get more information
 about the failure.


 This is an area where browsers are completely incompatible already. I
 don't see much benefit from blocking on creating a specification to make
 this situation better for web developers. It's actually not that big of a
 deal if the error messages from different browsers are different.


 If Web developers wanted to know the details of failures on their
 websites as opposed to on Inspector, wouldn't it better to add some sort of
 API that could interoperate on all browsers?

 - Ryosuke



 ___
 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] WKCreateCTLineWithUniCharProvider

2012-09-26 Thread Elliott Sprehn
WKCreateCTLineWithUniCharProvider is in the WebKitSystemInterface so its
source is not available outside Apple.

On Wed, Sep 26, 2012 at 2:34 AM, Glenn Adams gl...@skynav.com wrote:

 Where can I find the source for WKCreateCTLineWithUniCharProvider? I'm
 working on a bug [1] in which I will need to at least understand and
 perhaps modify its behavior.

 Basically, to fix this bug, I need to pass character context from adjacent
 text runs (or adjacent inline text nodes) that will be used to affect the
 shaping substitutions but not otherwise participate in width or drawing
 behavior.

 Or is this functionality only exposed to Apple staffers? [If so, then I
 will instead approach doing a trial fix on one of the platforms that uses
 harfbuzz.]

 Regards,
 Glenn

 [1] https://bugs.webkit.org/show_bug.cgi?id=6148



 ___
 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] New Feature: Canvas Path object

2012-09-22 Thread Elliott Sprehn
On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.com wrote:

 Hi WebKit,

 I would like to ask if there are objections to implement the canvas Path
 object.


Do we have metrics on how often people already have things named Path? All
other canvas objects have a prefix like CanvasGradient and CanvasPattern,
this thing seems inconsistent and more likely to break existing pages.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] PSA: removing CSS3_FLEXBOX define

2012-08-19 Thread Elliott Sprehn
On Sat, Aug 18, 2012 at 2:42 AM, Kenneth Rohde Christiansen 
kenneth.christian...@gmail.com wrote:

 Nice, congratulations on getting this far! A lot of web developers are
 going to find flexbox extremely useful, and we should also not forget
 that it is even supported by IE10 (though prefixed with -ms-) now, so
 it will be good that people can also use it on WebKit based browsers
 soon.


Note that IE10's implementation is very different than the new spec.

http://msdn.microsoft.com/en-us/library/ie/hh673531(v=vs.85).aspx
http://dev.w3.org/csswg/css3-flexbox/

Even more bizarre they link to the deprecated flexbox spec:
http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/ but don't actually
implement it. :/

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal to remove list-item special counter

2012-08-15 Thread Elliott Sprehn
WebKit is the only browser that implements the magic counter named
list-item and we have no tests for it. This is from the CSS3 Lists module
(http://dev.w3.org/csswg/css3-lists/). This special counter was added back
in the initial implementation of CSS counters 6 years ago.

ex.

style li:before { content: ( counter(list-item) ); } /style

ol
 li
 /ol

It's not useful since we don't support the ::marker psuedo element, nor
does any other browser. The above example outputs (2) since the implied
counter increment is on the list marker which we don't actually support. I
can't find references to this thing in Google outside the spec itself
either.

Can I remove this feature?

- Elliott
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New runtime setting: css3TextDecoration

2012-08-14 Thread Elliott Sprehn
I don't think editing code breaking when the page uses -webkit prefixed
properties should block launching a feature. The point of the vendor prefix
is to assert the instability of the feature.

This wouldn't be a regression, it's just a missing feature.

On Tue, Aug 14, 2012 at 3:22 PM, Ryosuke Niwa rn...@webkit.org wrote:

 ...

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Add support for CSS3 text-decoration* properties

2012-08-01 Thread Elliott Sprehn
On Tue, Jul 31, 2012 at 7:35 PM, Bruno Abinader brunoabina...@gmail.comwrote:

 Hi all :)

 As suggested by Ojan, I am writing a mail to you about my intention to
 implement all updated and missing text-decoration* properties from
 CSS3 spec (currently in development), named below:

 -webkit-text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 )
 CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration
 Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration
 Status: Proposed patch / pending review


It seems weird to have a prefixed version of text-decoration instead of
just making text-decoration allow the new prefixed keywords.

What's the reason for having a whole new prefixed property?

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Multiple inheritance in the DOM

2012-07-26 Thread Elliott Sprehn
On Thu, Jul 26, 2012 at 3:45 PM, Alexandru Chiculita ach...@adobe.comwrote:

 ...
 If CSSPseudoElement would be designed to derive from the same base class
 as Element and share most of their style/layout properties, then 99% of the
 time people will just do region.element.style.top = '100px'; and no query
 interface would be needed.


I brought this up in #webkit yesterday, but Adam Barth made a good point
that making CSSPseudoElement an Element means you could appendChild it
anywhere, or even append children to it which doesn't make sense.

You could make detaching a CSSPseudoElement or appending a child to it an
error (which is easy since that's centralized in WebKit), but it's a little
weird in the spec.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Feature Announcement: CSS3 intrinsic width keywords (min-content etc.)

2012-06-18 Thread Elliott Sprehn
I'm currently implementing the CSS3 writing mode spec intrinsic width
keywords:
http://dev.w3.org/csswg/css3-writing-modes/#intrinsic-sizing

Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=38919

Currently I'm only adding support for width to match the behavior of Gecko.
I'll move on to height once the spec is clarified on behavior. In
discussions with Tab Atkins it looks like we can make height:
fill-available provide sensible 100% height behavior to simplify page
layout for authors which will be really nice.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev