Re: [webkit-dev] Unprefix -webkit-clip-path
Hi, I didn’t hear any objections to unprefix -webkit-clip-path. Unless no new concerns get raised, I’ll land the patch later this week. Greetings, Dirk On 21. Oct 2019, at 13:01, Dirk Schulze mailto:dschu...@adobe.com>> wrote: Hi, I’d like to unprefix the -webkit-clip-path implementation. The spec for clip-path is CSS Masking ED: https://drafts.fxtf.org/css-masking-1/ CR: https://www.w3.org/TR/css-masking-1/ Currently, WebKit has 2 independent(!) implementations: 1. The SVG clip-path CSS property that only applies to SVG elements and only allows referencing of clipPath SVG elements. 2. The -webkit-clip-path CSS property that started with basic shapes (CSS shape functions) and added support for referencing of clipPath SVG elements. While initially it just worked on HTML elements it covers SVG elements as well now. Therefore, the -webkit-clip-path implementation is a superset of the clip-path implementation and I intend to replace the latter with the former entirely. -webkit-clip-path will get an alias for clip-path. “Unprefixing" clip-path (ship with newly supported features) has been in discussion at Mozilla as well: https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path%7Csort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ<https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path|sort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ> https://groups.google.com/forum/#!msg/mozilla.dev.platform/RM5O36MZ4x4/mU0cOsT7EgAJ Main concern was the confusion around the path() CSS shape function which was the only CSS shape function not defined in CSS Shapes Level 1 (but defined in the Motion spec). As a result, the CSS WG moved the function to CSS Shapes Level 1 which should address the concerns of the Mozilla community. The work happens here: https://bugs.webkit.org/show_bug.cgi?id=187888 There are a few low-priority issues left (see master bug https://bugs.webkit.org/show_bug.cgi?id=126207). They should not have a real-world affect though as they are corner cases. Please raise your concerns here on the mailing list or send your support. Thanks a lot, Dirk Schulze ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefix -webkit-clip-path
Hi, I’d like to unprefix the -webkit-clip-path implementation. The spec for clip-path is CSS Masking ED: https://drafts.fxtf.org/css-masking-1/ CR: https://www.w3.org/TR/css-masking-1/ Currently, WebKit has 2 independent(!) implementations: 1. The SVG clip-path CSS property that only applies to SVG elements and only allows referencing of clipPath SVG elements. 2. The -webkit-clip-path CSS property that started with basic shapes (CSS shape functions) and added support for referencing of clipPath SVG elements. While initially it just worked on HTML elements it covers SVG elements as well now. Therefore, the -webkit-clip-path implementation is a superset of the clip-path implementation and I intend to replace the latter with the former entirely. -webkit-clip-path will get an alias for clip-path. “Unprefixing" clip-path (ship with newly supported features) has been in discussion at Mozilla as well: https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path%7Csort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ<https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path|sort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ> https://groups.google.com/forum/#!msg/mozilla.dev.platform/RM5O36MZ4x4/mU0cOsT7EgAJ Main concern was the confusion around the path() CSS shape function which was the only CSS shape function not defined in CSS Shapes Level 1 (but defined in the Motion spec). As a result, the CSS WG moved the function to CSS Shapes Level 1 which should address the concerns of the Mozilla community. The work happens here: https://bugs.webkit.org/show_bug.cgi?id=187888 There are a few low-priority issues left (see master bug https://bugs.webkit.org/show_bug.cgi?id=126207). They should not have a real-world affect though as they are corner cases. Please raise your concerns here on the mailing list or send your support. Thanks a lot, Dirk Schulze ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove CSS color-correction property
Hi Darin, On Jul 1, 2015, at 5:16 PM, Darin Adler da...@apple.com wrote: Hi folks. WebKit has a CSS property named color-correction. It’s still prefixed, so some would call it -webkit-color-correction and I don’t think it’s yet been proposed as a CSS standard. Apple engineers added this a while back so that WebKit could continue interpret webpage and image colors as device native color space for performance and to match content from legacy plug-ins. The property allowed some web content to specify sRGB to get predictable results when correctness mattered more than performance. If I’m not mistaken, this optimization is no longer effective on either of the Apple platforms. I’m pretty sure we always do the color correction. I suspect no one needs this feature. Do you mean that WebKit uses sRGB by default now? I thought the default would still be DeviceRGB. Greetings, Dirk I suggest we remove the property. Does anyone know a good reason not to remove it? I won’t necessarily land the code to remove it right away, but I’d like to get agreement on this now so I can do that later. — Darin ___ 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] Proposal: Remove CSS color-correction property
On Jul 2, 2015, at 8:47 AM, Tim Horton timothy_hor...@apple.com wrote: On Jul 1, 2015, at 23:36, Dirk Schulze dschu...@adobe.com wrote: Hi Darin, On Jul 1, 2015, at 5:16 PM, Darin Adler da...@apple.com wrote: Hi folks. WebKit has a CSS property named color-correction. It’s still prefixed, so some would call it -webkit-color-correction and I don’t think it’s yet been proposed as a CSS standard. Apple engineers added this a while back so that WebKit could continue interpret webpage and image colors as device native color space for performance and to match content from legacy plug-ins. The property allowed some web content to specify sRGB to get predictable results when correctness mattered more than performance. If I’m not mistaken, this optimization is no longer effective on either of the Apple platforms. I’m pretty sure we always do the color correction. I suspect no one needs this feature. Do you mean that WebKit uses sRGB by default now? I thought the default would still be DeviceRGB. DeviceRGB became equivalent to sRGB (thus causing WebKit to do color correction as if all colors are tagged as sRGB) on OS X a few releases ago. It no longer means “the same color space as the display”. I see. There was an attempt to specify this property from Mozilla. IIRC they had issues with color managed Flash applications that blend into a HTML context and same colors didn't match between Flash and HTML. So far Flash was the only use case. IMO not a forward looking approach. If sRGB and DeviceRGB are the only property values and DeviceRGB maps to sRGB in Safari, there doesn't seem to be a reason to keep the property. Greetings, Dirk Greetings, Dirk I suggest we remove the property. Does anyone know a good reason not to remove it? I won’t necessarily land the code to remove it right away, but I’d like to get agreement on this now so I can do that later. — Darin ___ 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] What's left to ship -webkit-filter unprefixed?
On Sep 18, 2014, at 8:11 PM, Max Vujovic mvujo...@adobe.com wrote: Hi folks, I’m wondering what work is left to ship -webkit-filter unprefixed? I’m asking because Firefox is gearing up to ship filter unprefixed [1], and it’d be great to see WebKit do it, too. We ship both properties, prefixed filter and unprefixed filter. Both with two different functionalities. * filter are just supported on SVG and just one reference to a filter element * -webkit-filter work just on HTML elements. It has support for the shorthand properties (even though not following the spec by word yet) and allows references to multiple filter elements. However, the filter references are still buggy and especially filter regions are not handled correctly. There might be other potential performance regressions for SVG when it comes to references of local filter elements in the same document. Some things that come to mind are: - Supporting the filter shorthand functions on SVG content. - Making sure the filter region and primitive subregion clipping calculations match the spec. Filters on SVG have an entirely different backend which is not compatible to the backend used for HTML elements. It basically is not designed for multiple filter instances. We would need to reimplement filters for SVG again, which doesn’t seem to be efficient. At the same time we need to make sure that SVG Filters are as reliable as they are today on SVG content since they are used a lot. IMO the way forward is to correct the implementation of -webkit-filter where possible. Some parsing quirks might just be fixed for the unprefixed filter property. In a second step, -webkit-filter must be independent of the logic used by HTML as much as possible. We are already going these steps with using RenderElement and so on. In a last step we either set up -webkit-filters in another place then RenderLayer where we still mostly do it today, or transform SVG to use RenderLayer as well. To answer you’re question: There is still some work left. Greetings, Dirk PS: I saw that you sent the same message to blink-dev. Even thought a lot changed in the filter backend (HW accelerated SVG Filters and so on), most of the design principles still apply to Blink the same way as they do to WebKit. Thanks, Max [1]: https://groups.google.com/d/msg/mozilla.dev.platform/ujWvBvtugGY/aS0oA44HuoUJ ___ 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] Port-specific OpenType support
Previous attempts to drop SVG Fonts failed because SVG Fonts were used in older iOS version without WOFF support a lot. My latest unofficial/informal attempt was a couple of weeks ago by asking one Apple representative. What changed since then? Greetings, Dirk On Sep 11, 2014, at 11:03 PM, Martin Robinson mrobin...@webkit.org wrote: On Thu, Sep 11, 2014 at 11:44 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: My question to WebKit-Dev is: Are there any ports who: 1) Want continued support for SVG fonts, and 2) Whose platforms do not support OpenType fonts natively? WebKitGTK+ supports OpenType natively and I as far as I know we have no problems dropping support for SVG fonts. If SVG fonts are supported by the Mac port though, we will probably still want to maintain support for our own port, if possible. --Martin ___ 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] Updating and Enabling the CSS Font Loading Spec
On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote: Hi All, WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading. Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4]. Do you want to implement it behind a compile time flag? IMO it is an important and great API. However, Cameron filed a lot of specifications but reports while implementing it [1]. So there might still be some issues to discover. I strongly support the implementation though. Greetings, Dirk [1] http://lists.w3.org/Archives/Public/www-style/2014Jun/ Please let me know if you have any questions, comments, or concerns. -Bear [1] http://dev.w3.org/csswg/css-font-loading/ [2] https://bugs.webkit.org/show_bug.cgi?id=98395 [3] http://www.chromestatus.com/features/6244676289953792 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=835247 ___ 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] Implement Geometry Interfaces
On Jun 13, 2014, at 8:36 AM, Filip Pizlo fpi...@apple.com wrote: Why can't these data structures be implemented as JavaScript built-ins that behave as if they were DOM objects? I am not sure. What do you have in mind? How could it look like? Greetings, Dirk -Filip On Jun 12, 2014, at 10:45 PM, Dirk Schulze k...@webkit.org wrote: On Jun 13, 2014, at 1:54 AM, Benjamin Poulain benja...@webkit.org wrote: On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. I don’t think that there is a real performance gain in comparison to a native implementation in DOM. Also, these interfaces are primarily designed as a way to communicate with CSS OM, DOM, SVG DOM and convenience for authors. Therefore, any performance optimizations in JavaScript should probably be more radical and address the DOM in general and not just a couple of APIs. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? The performance problems of WebKitCSSMatrix can be found in two areas: * Even if the transformations are purely 2D, all matrix operations happen in 3D. This can be addressed. * All transformations return a new WebKitCSSMatrix which allocates more memory. DOMMatrix addressed this with in-place transformation where the matrix itself is transformed. DOMMatrix is still compatible to WebKitCSSMatrix and SVGMatrix. Furthermore * DOMMatrix supports Float32Array and Float64Array as interchange format to make its use in JS even faster. What is the rationale for not having JavaScript primitive types? I don’t think that any of the interfaces can be described as “primitive”. They rather seem specific for the designed purpose. Greetings, Dirk 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] Implement Geometry Interfaces
On Jun 13, 2014, at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the JavaScript engine at that point, they cannot realistically standardize on a different abstraction later on. And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good. Blink is slowly moving the DOM into the JS engine. That doesn't make the DOM part of ECMAScript or needs approval of TC39. I do not think that typed arrays can be compared to DOMPoint or DOMMatrix. But DOMPoint to the plans of implementing DOM in JSC. I am interested in implementing the geometry interfaces into JSC. I wonder if we could generate the code from IDL as well. I do not think that this is possible with our code generators today. Is it? Greetings Dirk -- http://annevankesteren.nl/ ___ 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] Implement Geometry Interfaces
Hi, I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. Greetings, Dirk [1] http://dev.w3.org/fxtf/geometry/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Jun 13, 2014, at 1:54 AM, Benjamin Poulain benja...@webkit.org wrote: On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. I don’t think that there is a real performance gain in comparison to a native implementation in DOM. Also, these interfaces are primarily designed as a way to communicate with CSS OM, DOM, SVG DOM and convenience for authors. Therefore, any performance optimizations in JavaScript should probably be more radical and address the DOM in general and not just a couple of APIs. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? The performance problems of WebKitCSSMatrix can be found in two areas: * Even if the transformations are purely 2D, all matrix operations happen in 3D. This can be addressed. * All transformations return a new WebKitCSSMatrix which allocates more memory. DOMMatrix addressed this with in-place transformation where the matrix itself is transformed. DOMMatrix is still compatible to WebKitCSSMatrix and SVGMatrix. Furthermore * DOMMatrix supports Float32Array and Float64Array as interchange format to make its use in JS even faster. What is the rationale for not having JavaScript primitive types? I don’t think that any of the interfaces can be described as “primitive”. They rather seem specific for the designed purpose. Greetings, Dirk 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] Zoltan Horvath is now a WebKit reviewer
On Jun 11, 2014, at 6:39 PM, Bem Jones-Bey bjone...@adobe.com wrote: Awesome! Congratulations Zoltan! Congratulations Zoltan! On Jun 11, 2014, at 09:31 , David Hyatt hy...@apple.com wrote: Hi all, I'm pleased to announce that you now have someone new to pester for layout and rendering patch reviews! Zoltan Horvath is now a WebKit reviewer. He has done some excellent work in layout and rendering. He has primarily worked on shapes code, but also did useful refactoring in areas like line layout. Congratulations, Zoltan! dave (hy...@apple.com) ___ 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] Enable build for CSS3_TEXT
On May 21, 2014, at 6:32 PM, Zoltan Horvath zol...@webkit.org wrote: Hi there, We have 2 properties under CSS3_TEXT macro: -webkit-text-align-last (http://trac.webkit.org/changeset/162213) - parsingrendering are implemented -webkit-text-justify (https://bugs.webkit.org/show_bug.cgi?id=99945) - only parsing is implemented Spec : http://dev.w3.org/csswg/css-text-3/ CSS3_TEXT is disabled by default for our builds. Since we've got the proper testing for the existing code, I'd like to enable the flag by default. I object to enable -webkit-text-justify if it doesn’t actually have any functionality. This is poor behavior for authors since they can not feature test. It would be great to wait for CR of the spec and enable -webkit-text-align-last unprefixed. (Assuming that is isn't shipped in Safari yet.) So in general, I would vote for not enabling the flag at this point. Greetings, Dirk Let me know if you have any objections. Cheers, Zoltan ___ 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] Remove FILTERS and CSS_FILTERS flag
Hi, Do we still need the FILTERS and CSS_FILTERS compile time flag? Does any port still build without filters enabled? It is an integral part of the web platform now. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Remove CANVAS_PATH compiler flag where possible
Hi, I would like to ask to remove the CANVAS_PATH compiler flag from WebCore where possible. At the moment it guards the Path2D object and all related methods in Canvas like: void fill(Path2D path, optional CanvasWindingRule winding); void stroke(Path2D path); void clip(Path2D path, optional CanvasWindingRule winding); Firefox and Chrome will ship with Path2D enabled in the next release versions. WebKits implementation is interoperable with Firefox and Chrome. The only method on Path2D that just reached consensus but does not ship in other browsers is addPath(Path2D, optional SVGMatrix?). The risk that it will change in an not interoperable way is minimal. However, at the moment I would like to guard it behind a compiler flag and implementations shouldn’t ship with it within the next couple of weeks. Alternatively, I can remove the IDL method in favor for removing the CANVAS_PATH compiler flag completely. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove CANVAS_PATH compiler flag where possible
On Apr 17, 2014, at 5:45 AM, Benjamin Poulain benja...@webkit.org wrote: Hi Dirk, On 4/16/14, 1:18 PM, Dirk Schulze wrote: I would like to ask to remove the CANVAS_PATH compiler flag from WebCore where possible. At the moment it guards the Path2D object and all related methods in Canvas like: void fill(Path2D path, optional CanvasWindingRule winding); void stroke(Path2D path); void clip(Path2D path, optional CanvasWindingRule winding); Firefox and Chrome will ship with Path2D enabled in the next release versions. WebKits implementation is interoperable with Firefox and Chrome. The only method on Path2D that just reached consensus but does not ship in other browsers is addPath(Path2D, optional SVGMatrix?). The risk that it will change in an not interoperable way is minimal. However, at the moment I would like to guard it behind a compiler flag and implementations shouldn’t ship with it within the next couple of weeks. Alternatively, I can remove the IDL method in favor for removing the CANVAS_PATH compiler flag completely. I am in favor of keeping the flag around until the spec is stable (or Safari ships the feature). The flag is used only in 4 files, its cost seems minimal. No objection for addPath. Path2D in general is stable enough and is shipping in Firefox and Chrome with the next releases. I would like to remove the flag around Path2D. Safari 7 ships with CANVAS_PATH enabled when the flag is removed around Path2D, it should not enable the flag for addPath() yet. Would you be ok with this suggestion? Greetings, Dirk 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] Proposal: Remove ENABLE(SVG)
On Feb 4, 2014, at 5:20 AM, Steven Coul (scoul) sc...@cisco.com wrote: I agree, the time taken to build is not really a good reason for the change or lack of - as you point out there, are many other ways to optimize the build process/server which will have wider benefits. But does anybody consider size to be an issue? SVG adds a fair chunk to the size of a binary - especially in debug builds - which is not very friendly to embedded systems. ( Real embedded, not just a small form factor $500 PC running Windows etc ) I know in general WK seems to be aimed at desktop, big mobile etc - and we tend to ignore anything not directly related to the the main builds, but even on a desktop I wouldn’t mind seeing a crusade to make things smaller. One day I’ll see my whole OS in L1 Cache…….. In this case you may want to branch WebKit and remove more than just SVG. WebKit is a browser engine and should display web content. There is no doubt anymore that SVG is an integral part of the web. That is the the only decision that matters here IMO. Greetings, Dirk Steve Harry Coul sc...@cisco.com On Feb 4, 2014, at 6:11 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Xabier Rodríguez Calvar írta: Sorry for the late answer, but I was in Brussels at FOSDEM. O Ven, 31-01-2014 ás 14:01 +0100, Alberto Garcia escribiu: Not in the GTK+ port at least, I've been able to do builds without SVG perfectly fine, so there's probably something else wrong in your environment or the port you're using. Anyway, I'm also fine with removing it. It saves some times in our builds and I always use it unless I have to do something with SVG. I would keep it unless it doesn't pay off the effort of maintaining it. Br. I've checked the full clean build time of GTK port on a quad core i5-2320 (3GHz) machine with icecc buildfarm and -j30 makeflag: - with SVG disabled:WebKit is now built (11m:58s). - with SVG enabled: WebKit is now built (13m:38s). The difference isn't so big. But it was clean build, I don't think if developers always do clean builds. If you don't touch SVG related files, the build time shouldn't depend on enabled/disabled SVG. In my opinion the ENABLE(SVG) flag is not to speed up clean builds, but disable SVG if you don't want to ship it. There are so many way to speed up builds: - use more cores, use icecc buildfarm, use ccache - get rid of include paths and use module relative includes (But it can be a separated thread if anybody is interested in it.) Ossy ___ 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] Proposal: Remove ENABLE(SVG)
On Jan 28, 2014, at 4:51 PM, Philip Rogers p...@google.com wrote: This will make hacking on WebKit much easier. For better or worse, SVG is tightly coupled with the rest of rendering/. We recently measured SVG usage on the web and found 10% of all pageviews contain SVG. Do you plan to remove ENABLE(SVG_FONTS) as well? This is about SVG, not SVG_FONTS. And I agree that SVG can be removed. Not the latter at this point. Greetings, Dirk On Tue, Jan 28, 2014 at 4:34 PM, Andreas Kling akl...@apple.com wrote: This sounds good to me. A WebKit without SVG support is scarcely a WebKit at all. On Jan 28, 2014, at 4:13 PM, Sam Weinig wei...@apple.com wrote: Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I'd like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a minimal build working, but I don't think the clutter of the #ifdefs is worth that. -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 ___ 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] Bem Jones-Bey is now a reviewer
Hi Webkittens, I am happy to announce that Bem (bemjb) is a WebKit reviewer now! Bem spend a lot of efforts on the layout code of WebCore. Especially Shapes, fragmentation and floats are his area of expertise. Thanks Bem for all the work you have done so far and congratulations! Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-patch setup-git-clone
On Dec 24, 2013, at 8:17 PM, Ryosuke Niwa rn...@webkit.org wrote: I recently added a new webkit-patch setup-git-clone to automate many steps described in http://trac.webkit.org/wiki/UsingGitWithWebKit This command has been available since http://trac.webkit.org/changeset/160039 If you find any bugs, missing features, etc… I'm more than happy to review your patches. That is cool! I assume it also does the global changes like user name and email that I should be aware of? Greetings, Dirk - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 5, 2013, at 11:18 AM, John Mellor joh...@chromium.orgmailto:joh...@chromium.org wrote: On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa rn...@webkit.orgmailto: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. The thing is, srcN isn't a list, it's a list of lists. Consider the following srcN for a fixed-width image with art direction: img src-1=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x ph...@2x.jpg src-2=0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x photo-c...@2x.jpg I guess one could combine it all into one attribute, e.g. by introducing || as an 3rd separator, in addition to the existing , and ;. For example: img srcset=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x photo-c...@2x.jpg” I assume authors would just create a new line for each list. That is basically what you do with src-1 and src-2 as well in your example. Writing both beyond each other wouldn’t be very helpful for readability either. I personally do not see where authors would really care if the lists are in two attributes or one. It seems rather a matter of taste or even believe. The point is that srcset can be extended to support more as you suggest in your example. Greetings, Dirk But that seems rather harder to read... - R. Niwa On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss y...@yoav.wsmailto:y...@yoav.ws wrote: On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.wsmailto:y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.commailto:jackalm...@gmail.com wrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fimailto:koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa Will setting the limit on the number of possible attributes at 99 still enable that optimization? Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you? ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Animations feature flag
On Oct 16, 2013, at 1:42 AM, Dean Jackson d...@apple.com wrote: Hi floks, I’m about to add a flag WEB_ANIMATIONS, behind which I’ll start: - Implementing an animation engine that matches the model in W3C’s Web Animation spec - Allowing CSS and SVG animations to use the new engine - Exposing enough internal JS API to allow improved testing (currently a very weak point for us) - Possibly looking at implementing parts of the public API The last point was controversial when it was raised here a while ago. We should discuss it again when we have something to implement upon. There will also be a runtime flag to enable the new engine. With the flag disabled, nothing should break. Eventually we’ll be able to toggle the flag and have a better animation engine. Did you already open a master bug for the upcoming changes? Can you add a link please? Greetings, Dirk Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Oct 7, 2013, at 11:55 PM, Chris Fleizach cfleiz...@apple.com wrote:
Hi Dirk,
On Oct 7, 2013, at 12:36 AM, Dirk Schulze dschu...@adobe.com wrote:
I am all for accessibility! But isn't the idea to keep content out of CSS so
that it does not interfere with accessibility as much as possible?
The main problem with the 'content' property is that it is not accessible.
Why I really think it should not be used for more than symbols. ARIA and
class names on the element can help screen readers to make the styling
accessible as needed.
Is this a question? I'm not sure what you're driving at. Yes ARIA can be used
to provide labels, but when CSS content is used, there's nothing to label
(ie DOM Node)
I see.
Do you have use cases where unaccessible CSS is actually a problem? And
which actually needs to be done in CSS?
We come across scenarios like
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Where we don't want the screen reader to say shadowed white star -- we want
to label it with the semantic description -- New!
Understand.
Also, did you speak with people from screen reader software and societies
for people with different needs and preferences? Are they willing to adapt
this feature and on board?
Apple makes a screen reader for Mac and iOS, so this is not an issue for us.
Moreover, there's nothing for them to adapt or be on board with. WebKit can
start vending the right information and everyone benefits.
I hope you understand that I am not particularly concerned about Apples screen
reader solution. It is one implementation. I would like to know if JAWS, NVDA,
Dolphin and other are aboard.
This discussion should probably also move to the W3C mailing list www-style
unless you don't plan to expose it to the web.
Inside the webkit bug, the first comment states:
Description From James Craig 2013-08-22 17:59:42 PST (-) [reply]
AX: Implement CSS -webkit-alt property
Not in a spec yet, but discussion was positive and the issue is being tracked
by the CSS WG. Since this is holding up several projects, I propose
implementing the vendor-prefixed form: -webkit-alt.
http://lists.w3.org/Archives/Public/www-style/2012Nov/0319.html
Ah thanks! I couldn't find it on the mailing list and missed your link.
Greetings,
Dirk
Greetings,
Dirk
On Oct 1, 2013, at 7:08 AM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and
we’d like to start work on it. To clarify, the problem is that with CSS
generated content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM
node, we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google,
and Elika from Mozilla) are generally on board with the concept of
accessible text alternatives for CSS generated content and Tab suggested
the property name. It is not in a CSS4 draft yet, but some usage examples
are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak
“New” instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
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
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
I am all for accessibility! But isn't the idea to keep content out of CSS so
that it does not interfere with accessibility as much as possible?
The main problem with the 'content' property is that it is not accessible. Why
I really think it should not be used for more than symbols. ARIA and class
names on the element can help screen readers to make the styling accessible as
needed.
Do you have use cases where unaccessible CSS is actually a problem? And which
actually needs to be done in CSS?
Also, did you speak with people from screen reader software and societies for
people with different needs and preferences? Are they willing to adapt this
feature and on board?
This discussion should probably also move to the W3C mailing list www-style
unless you don't plan to expose it to the web.
Greetings,
Dirk
On Oct 1, 2013, at 7:08 AM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and we’d
like to start work on it. To clarify, the problem is that with CSS generated
content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM node,
we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak “New”
instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
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] Proposal: Use ICU in WebKit code
On Oct 5, 2013, at 7:37 AM, Darin Adler da...@apple.com wrote: Any thoughts on this? I am not sure what the status of the WinCE port is, but I’d like to hear from the maintainers of that port on the port status and their view on this strategy. Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a long time ago and already removed. Probably I was wrong. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes in QtWebKit development
On Sep 30, 2013, at 11:58 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 26 September 2013, Andreas Kling wrote: On Sep 25, 2013, at 12:40 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Saturday 14 September 2013, Andreas Kling wrote: On Sep 14, 2013, at 11:24 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: That said, in all likelihood the Qt port will not remain part of WebKit forever, ... (This being the main reason.) Since you already know you’re eventually going to leave, you could just move to a branch sooner rather than later. It’s unreasonable to expect WebKit to accommodate a port that has no forward-looking interest in the project. We do have a branch tagged and being prepared for 5.2. It was taken before the FTL merge and the following switch to require C++11 in all of the project. It will be very hard branch again after that point since we support 2-3 year old platforms by default, and the Webkit project want to move to using the latest and greatest compilers. So you are saying that you'll never branch QtWebKit from WebKit trunk again? I would love to, but I do not think it is going to happen. Quite honestly I wasn't sure I would be able to pull a new branch for 5.2 off, since older Linux (gcc 4.4), all windows builds and especially old OS X (10.6) were not building WebKit2 when I started. I got it working, but it the work to unroll unnecessary compiler features and library dependencies is just going to get harder from now on (if anyone want a patch to remove the C++11 requirement from WebKit2 late July, I have one). If a new branch is made from WebKit trunk in the future would likely only be limited to specific platforms, and therefore not suited as a module shipped with Qt, but as an optional upgrade. It’s commendable that you want to land your platform-agnostic patches before withdrawing from the project, but assuming your last branch point is already set, I don’t see why this necessitates keeping the Qt platform code around. We all know what happens when a webkit port works on a branch. In theory it shouldn't be a problem, but as you know it didn't work for the N9 browser branch in Nokia, it didn't even work for the iOS branch at Apple! So based on observations, I believe to be part of the project and able to commit upstream you must live upstream. I would not necessarily disagree with the problem of upstreaming work. But you said that most likely you wouldn't be able to branch WebKit anymore because of the compiler requirement. At least for Qt. Do you have other interests in QtWebKit beside the integral part of Qt so that it makes sense for you to maintain the port further? Another question that is just partly related to WebKit but more curiosity. Qt is deep integration into WebKit. We have (had?) a lot of Qt specific code in core WebCore to support QtXML and other things. Blink already stated that they would not accept such deep interventions in their platform. Is all that not important for you anymore? Can you operate with libxml2 and other libraries from now on? If that is the case, can't we limit the Qt specific code to just /platform/qt and remove all other Qt specific dependencies from WebCore? Greetings, Dirk Best regards `Allan Jensen ___ 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] Enable CSS_FILTERS and FILTERS on more bots
On Sep 9, 2013, at 4:44 PM, Gustavo Noronha Silva g...@gnome.org wrote: Pretty late to the party, but: Em Seg, 2013-08-19 às 14:08 -0700, Dirk Schulze escreveu: When I worked on CSS filters, I start realizing after reading the build errors that most bots (all but Mac bots?) have either CSS_FILTERS, FILTERS or both flags disabled. It would be extremely useful to have more than just one platform building with filters enabled. Could we make this possible on Gtk or Qt bot? The reason we don't enable CSS_FILTERS on the bots, AFAIK, is we haven't been able to make 3D work reliably and in a reproducible way on the bots (which run on VMs using Xvfb). We work towards this goal as time allows, and with webkit2 becoming our main target it has become more important. As soon as we get that (or real hardware bot) we sure should enable css filters. Thank you for the update! Greetings, Dirk Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ 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] Enable CSS_FILTERS and FILTERS on more bots
Hi, When I worked on CSS filters, I start realizing after reading the build errors that most bots (all but Mac bots?) have either CSS_FILTERS, FILTERS or both flags disabled. It would be extremely useful to have more than just one platform building with filters enabled. Could we make this possible on Gtk or Qt bot? Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Alexandru Chiculita is now a WebKit reviewer
Awesome! Congratulations Alex! This is really great news. Greetings, Dirk On Apr 24, 2013, at 2:42 PM, Dean Jackson d...@apple.com wrote: I'm happy to announce that Alex is now a WebKit reviewer. Congratulations Alex! Alex has done a lot of work in CSS Filters, amongst other places. For those who want to see him in action, here is his recent presentation at W3Conf: http://achicu.github.com/css-presentation/ http://www.youtube.com/embed/D7gsp7RnDfc Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
On Apr 22, 2013, at 9:32 AM, Simon Fraser simon.fra...@apple.com wrote: On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. I think it is worth it to do that. Not just because of CSS Exclusions, but for future properties as well. Greetings, Dirk Simon ___ 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] StyleBuilder vs StyleResolver
Hi, The style of CSS properties is either set in StyleBuilder/CSSProperty or in StyleResolver (alias CSSStyleSelector). StyleResolver has a giant switch statement to handle all CSS property values and set the style. It is the historical way to build the style. StyleBuilder was introduced ~2 years ago. Instead of a giant switch to handle all property styles, it has a concept of template to combine CSS property handling. In these last two years new properties were mainly added to StyleBuilder, older properties were left alone in StyleResolver. The concept of StyleBuilder was always controversial[1][2]. A lot of people had concerns that StyleBuilder is less readable and makes it harder to understand the code. I personally am more worried that we still have two ways to set the style. I think it is bad to keep half of the properties in StyleResolver and the other half in StyleBuilder. We may use the general spring cleanup to revalidate the concept of StyleBuilder and StyleResolver and decide to use the one or the other concept. Any thoughts? Greetings, Dirk [1] https://bugs.webkit.org/show_bug.cgi?id=54707 [2] https://bugs.webkit.org/show_bug.cgi?id=102844 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] OpenVG backend
Give others some days to read the mail and then go ahead with publishing patches. Greetings, Dirk On Apr 9, 2013, at 3:54 PM, Martin Robinson mrobin...@webkit.org wrote: Is any upstream port maintaining and using the OpenVG backend? I don't see references to it in any build files. If we are going to remove the Skia backend, we should probably consider removing all unused graphics backends. --Martin ___ 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] Sunsetting committership and reviewership
On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. The question is still how you measure active reviewers/contributors? Is it enough to comment on bugs? Real reviews? Must there be at least one r+ in this time? Is an actual commit required? What do we gain from reverting reviewer ship/ committer ship? I can absolutely understand security concerns on unused accounts. But this is the case on active contributors as well. How many people did change their passwords after the first activation of SVN access? If we have security concerns, we should reset all passwords for all people with SVN accounts from time to time. Greetings, Dirk Cheers, 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] Unmaintained feature list
Hi WebKit, The recent request from Andreas to remove CSS Variables leads to the question if there are more features that are not maintained at the moment. I think it would be honest and transparent if we collect all features that are not maintained at the moment in a Wiki page. This would give us the chance to review each feature individually and we would still have the overview over all features in question. It also makes it a lot easier to plan with the available resources IMO. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? This seems reactionary. We never had an activity counter before. Actually, I know WebKit reviewers who stopped working on the project for 2 years and restarted the activity later. Even with a fast growing community and an always changing code base, the expertise was still good enough to continue where stopped right away. On the controversy, it may leave people at the Blink project who want to switch back to WebKit later and even more harm is done to the WebKit project. I object to such a proposal. Greetings Dirk - R. Niwa ___ 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] Sunsetting committership and reviewership
Sent from my iPhone On Apr 5, 2013, at 12:00 AM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.commailto:kenneth.christian...@gmail.com wrote: I am not sure this is really needed. People sometimes disappear from working on trunk for extended periods of time due to internal products and downstream branches. It has happened multiple times to me. That doesn't mean that I won't come back and start working upstream later. Also it could be that some people working on Blink would like to contribute to WebKit in their spare time or in the future again. Part of being a reviewer is also knowing what and when to review, so I am not sure there really is an issue here. I'm not too concerned about the reviwership but more about committership from a security point of view. I don't think a lot of committers are going to monitor their old SVN accounts and update passwords periodically. Having lots of inactive SVN accounts isn't that helpful. Maybe I didn't phrase it correctly, but I'm suggesting more of suspension so that we have a smaller attack surface for SVN credentials. Suggesting the deactivation of the SVN account is reasonable, as long as you get it back on request. Greetings Dirk - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Cleaning House
On Apr 4, 2013, at 10:37 AM, Martin Robinson mrobin...@webkit.org wrote: On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen gga...@apple.com wrote: What would it take for WebKitGTK+ to adopt the JSC bindings? Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems there are some external branches/forks using V8. In the past, we've rejected proposals to add V8 support to WebKitGTK+. Geoffrey has a good point. V8 will develop along Blink. With a diverging Blink implementation from WebKit, the JS ABI must change as well. It is not clear if the V8 team is willing to make V8 compatible with other rendering engines, or if they even are able to. I expect that this won't be possible quite soon. WebKit projects should consider moving to, or moving back to JSC. Allowing both projects to continue quickly. Greetings, Dirk --Martin ___ 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 announcement: Web VHS API
On Apr 1, 2013, at 1:26 PM, Gavin Barraclough barraclo...@apple.com wrote: On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote: correction... NTSC = Never The Same Color (twice) How do we intend to implement this? – any pseudo random behaviour needs to be cryptographically secure to avoid risking an information leak here. You mean a time attack on VHS content? How does it actually affect request animation frame? Always 21 frames for NTSC and 24 for PAL? Can this be used to integrate region codes to prevent europeans to see VHS from the US? Dirk G. ___ 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] New web-facing canvas feature: opaque attribute
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
Re: [webkit-dev] SVGStopElement.idl recompiling every time if you build twice in a row?
Hi Darin, There is a bug report about this https://bugs.webkit.org/show_bug.cgi?id=107731 and a fix from Simon Nuking WebKitBuild/Debug/DerivedSources/WebCore/*SVGStopElement.dep fixed this for me. Greetings, Dirk On Mar 10, 2013, at 6:15 PM, Darin Adler da...@apple.com wrote: On Mac, SVGStopElement.idl keeps getting recompiled every time I build WebCore, and then in turn everything that uses the headers generated. Anyone know why this happens? Is this specific to Mac, or happening with other build systems too? -- Darin ___ 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] Philip Rogers is now a Reviewer
Congratulations Philip! :) Greetings Dirk On Feb 28, 2013, at 12:11 PM, Levi Weintraub le...@chromium.orgmailto:le...@chromium.org wrote: Congratulations, Mr. Rogers! On Thu, Feb 28, 2013 at 12:09 PM, Eric Seidel e...@webkit.orgmailto:e...@webkit.org wrote: Nice to have another hand for SVG reviews. :) Grats to pdr! ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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 practices for landing new/changed layout test expectations?
On Feb 25, 2013, at 4:27 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 3:36 PM, Glenn Adams gl...@skynav.com wrote: On Mon, Feb 25, 2013 at 3:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 2:48 PM, Dirk Pranke dpra...@google.com wrote: On Mon, Feb 25, 2013 at 2:05 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 1:39 PM, Dirk Pranke dpra...@google.com wrote: Are you suggesting we should land a failling baseline in the meantime? No. I'm suggesting patch authors perform their due diligence and either ask port maintainers to rebaseline or rebaseline tests themselves. I think either you misunderstood my question, or I am misunderstanding your answer. I'm not asking who, I'm asking what ... If we know some tests are failing, and when we fix a bug the tests will start passing again (but that patch might not land for quite some time), what should we (anyone) do in the meantime? Leave the tree red, land incorrect -expected baselines so that we can catch changes in behavior, or add lines to TestExpectations? Many of the lines you cited fell into the last category. Either one of those two solutions would work (although I strictly advice we do the latter) when there are failing tests and we need a fix in order for those tests to pass but I'm not interested in discussing that matter at the moment. I'm specifically opposed to adding new entries to TestExpectations for the sole purpose of rebaselining them later. One of the modes that the new generic TE file permits is to specify a generic Skip and overriding this with per-port Pass. This provides (IMO) a more manageable way to land a patch that you expect will require per-port mods to fully get the patch working on the primary ports. It also allows one to land a patch containing tests where a subsequent patch will provide the functionality to be tested. I recently used both of these modes to sub-divide a large patch and to incrementally verify (landing individual per-port fixes as needed) individual ports. Personally, I prefer this over the just turn bots red mode. I suspect the turn bots red approach results in greater churn, due to rollouts and re-landing, than the finer grain approach I outlined above. I agree it requires the committer to follow through on other ports and eventually remove the generic Skip and Pass rules (once it works everywhere), but we have to assume here (IMO) that committers will do the right thing and take responsibility for the process. [And if not, then remind them.] So I for one, would vote against the turn the bots red approach. Overall, I think that approach produces a higher interrupt load on our limited committer and reviewer resources. I think it would be useful to give other procedures an opportunity to be tried out so we can have more data for choosing between alternative approaches. This has been tried as many people including yourself are using this approach in landing and rebaselining patches. In particular, a lot of new contributors from Chromium port use this strategy. When I used to work for Google, I periodically went through all entries in TestExpectations files that needed rebaselines and manually rebaselined them myself because people just leave entries like I've cited in another email all the time. Quite frankly, I don't want it to be my (or anyone but patch author's) job to take care of all these stale entries people add. The problem of Chromium in the early days was that all tests were rebaselined when they failed. Too many tests turned the bots red at this time and the Chromium folks didn't (couldn't?) take attention of all these failing tests. We lost the chance to fix a lot of these bugs immediately during this time. It took months to cover these tests in bug reports and fix them finally. Some tests may still report that everything is ok, even if they are failing - untracked. I see the current needs rebaseline approach better, since the tests are at least logged. I do not have an opinion how they should be logged. Greetings, Dirk - R. Niwa ___ 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] New WebKit reviewer: Stephen Chenney
Hi WebKit folks, It is a pleasure to announce that Stephen Chenney schen...@chromium.org is a WebKit Reviewer now. Stephen did and does an awesome job on various SVG, Font and Skia related topics. He fixed at least a dozen of urgent security bugs and has a great understanding of the WebCore code base. Please join me in congratulating Stephen for his new status! Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 12:08 AM, Adam Barth aba...@webkit.org wrote: On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote: It's much easier to discuss a concrete example. Which interface are you interested in deprecating? I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point. A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it. Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here. It is a proposal so far and no draft yet. Technically, I am not the editor of it so. The proposal has quite some way to go (hopefully not too much) and I do not plan to land anything in this direction as long as the responsible WGs did not agree on continuing with the proposal and the general direction. I will post a separate mail with the actual feature implementation announcement when the time comes. Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class. I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. I got an action of the SVG WG to work on a replacement for SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix (which is definitely actively used by web content) and provide a basic interface that can be used beyond just SVG. There are a lot of use cases in the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious once. A specification interoperable format to share transformation data seems extremely desirable. I encourage everyone who is interested to look at the proposal and give feedback. Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future. I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it. I agree that we need more metrics to discuss the next active steps on WebKitCSSMatrix and I already uploaded a patch to add it to the FeatureObserver[1]. The question remains: How do we want to continue with deprecating WebKit specific features in the long term. Especially when we have a standard compliant replacement. It is extremely hard to maintain all different behaviors. So far we have multiple implementations of background, flex-box, gradients to name some. This doesn't scale very well and there will be a time where we can not guarantee for the correct functioning of old features. This is a problem that other browsers like IE are focused for quite some time as well (not necessarily successfully). As long as we are concerned to deprecate and remove features, we increase the complexity of the code base. Less and less reviewers will be able to determine the behavior of patches to the general code base, while we increase the feature count and interoperability between modules more and more. There is no other way then to risk breaking content that relies on non-standardized behavior of platforms. And we should formalize thi s to give a bit more reliability to web authors. The last section on [2] is too vague at the moment. I don't think we're be successful at formalizing a general approach at this time. Instead, we should consider each case in turn and use our best judgement. If a pattern emerges over time, we might want to document that pattern in http://trac.webkit.org/wiki/DeprecatingFeatures. At the moment, deprecating WebKitCSSMatrix seems premature as there isn't yet a suitable replacement. The discussion on each single feature let us forget the greater scope of this problem. That is why I did not start with a concrete example. What about going another direction? Right now we have compiler flags for a lot of new features. What if we turn this around? Why not having a compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make sure deprecated features still work
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote: On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com wrote: The discussion on each single feature let us forget the greater scope of this problem. That is why I did not start with a concrete example. What about going another direction? Right now we have compiler flags for a lot of new features. What if we turn this around? Why not having a compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make sure deprecated features still work properly. Release builds should turn it on to not break compatibility. But every binary build of a nightly or preview has it turned off. A lot of developers experiment with Chrome Canary and WebKit nightlies already. It might be a drop in the bucket, but still can have some influence on decreasing the use of deprecated content. Features like CSS gradients, transitions and animations might be good candidates at the beginning for this flag. This carries the risk of decreasing test coverage of Nightlies and Canaries. I don't think that is acceptable. Users who download them and cannot use a web page because that page had deprecated features will then not be able to experience what bugs we had, those deprecated features notwithstanding. I empathize with the desire to remove cruft. But we shouldn't remove things if it breaks the web, even in Nightlies and Canaries. I agree with Phil. And as a corollary, if removing something *doesn't* break the Web and we think it's otherwise bad, then there's no need to do a special dance with nightlies before removing. Then we should face it. Prefixed content for CSS gradients, animation, transition, transforms, CSS Image functions, masking and a lot more will not go away. This basically means we will need to support them for an undetermined period of time, possibly for the projects lifetime. This will be the same for every popular prefixed feature that we introduce in the future. If we are honest about this we may can prevent future content to be a burden on maintenance and use similar concepts as Mozilla does with runtime flags on unprefixed features. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com wrote: Then we should face it. Prefixed content for CSS gradients, animation, transition, transforms, CSS Image functions, masking and a lot more will not go away. This basically means we will need to support them for an undetermined period of time, possibly for the projects lifetime. This will be the same for every popular prefixed feature that we introduce in the future. If we are honest about this we may can prevent future content to be a burden on maintenance and use similar concepts as Mozilla does with runtime flags on unprefixed features. This is why we need to be extremely careful when introducing new features. I absolutely agree. Chrome introduced the runtime flags as one possible solution for this problem. Greetings, Dirk - R. Niwa ___ 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] Deprecating JS interface
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and any
method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote:
It's much easier to discuss a concrete example. Which interface are
you interested in deprecating?
I can understand that it is easier to discuss on a concrete example, even if I
would like to discuss this in a general scope. We have multiple interfaces that
we may want to deprecate at some point.
A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in
WebCore yet but hopefully replaced by a standardized Matrix interface in the
future[2]. This new interface will not be fully compatible to WebKitCSSMatrix
and I would like to warn authors before they actually start using it.
Again, I think it would be better to discuss this in a wider scope but am happy
to discuss it on the concrete example as well. This actually might make it
easier to come up with general rules in the future.
Greetings,
Dirk
[1] https://bugs.webkit.org/show_bug.cgi?id=110048
[2] https://bugs.webkit.org/show_bug.cgi?id=110001
Adam
On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and
any method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
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] Deprecating JS interface
On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote: It's much easier to discuss a concrete example. Which interface are you interested in deprecating? I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point. A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it. Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here. It is a proposal so far and no draft yet. Technically, I am not the editor of it so. The proposal has quite some way to go (hopefully not too much) and I do not plan to land anything in this direction as long as the responsible WGs did not agree on continuing with the proposal and the general direction. I will post a separate mail with the actual feature implementation announcement when the time comes. Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class. I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. I got an action of the SVG WG to work on a replacement for SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix (which is definitely actively used by web content) and provide a basic interface that can be used beyond just SVG. There are a lot of use cases in the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious once. A specification interoperable format to share transformation data seems extremely desirable. I encourage everyone who is interested to look at the proposal and give feedback. Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future. I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it. I agree that we need more metrics to discuss the next active steps on WebKitCSSMatrix and I already uploaded a patch to add it to the FeatureObserver[1]. The question remains: How do we want to continue with deprecating WebKit specific features in the long term. Especially when we have a standard compliant replacement. It is extremely hard to maintain all different behaviors. So far we have multiple implementations of background, flex-box, gradients to name some. This doesn't scale very well and there will be a time where we can not guarantee for the correct functioning of old features. This is a problem that other browsers like IE are focused for quite some time as well (not necessarily successfully). As long as we are concerned to deprecate and remove features, we increase the complexity of the code base. Less and less reviewers will be able to determine the behavior of patches to the general code base, while we increase the feature count and interoperability between modules more and more. There is no other way then to risk breaking content that relies on non-standardized behavior of platforms. And we should formalize this t o give a bit more reliability to web authors. The last section on [2] is too vague at the moment. Greetings, Dirk [1] https://bugs.webkit.org/show_bug.cgi?id=110002 [2] http://trac.webkit.org/wiki/DeprecatingFeatures Regards, 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
[webkit-dev] Enable CANVAS_PATH by default
Hi WebKit folks,
I worked on the Path interface defined by the Canvas spec of W3C and WHATWG
[1][2] for the last couple of weeks.
Summary:
Canvas supports a new DOM interface called Path. The Path interface takes a
series of very well known path methods like moveTo, lineTo, cubicCurveTo, rect
and allows to create and keep a path independent of a Canvas context.
Additionally, I added the attribute 'currentPath' to the Canvas context to
provide read and write access to the current path created on the Canvas
context. Code snippet:
var path = new Path();
path.rect(0,0,100,100);
var ctx = canvas.getContext('2d');
ctx.currentPath = path;
ctx.lineTo(200,200);
ctx.closePath();
var path2 = ctx.currentPath; // path2 != path
Not implemented are addText, addPath, addPathByStrokingText. Another proposal
from Rik Cabanier[3] seems to address the idea behind these methods better.
I would like to ask to enable CANVAS_PATH by default on trunk. Ports can
opt-out the flag again. More information about some implementation details in a
short article[4]. If there are any concerns, suggestions or questions, I am
happy to answer them.
Greetings,
Dirk
[1] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#path-objects
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects
[3] http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
[4] http://dschulze.com/blog/articles/10/html-canvas-path-object-in-webkit
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Opera and WebKit
I interprete 'Chromium' as V8 and not JSC. Dirk 2013/2/13 Oliver Hunt oli...@apple.com Welcome to webkit! Are you still going to be using Carakan? Or are you planning on using WebKit's ES engine? If so are there any Carakan-JSC compatibility issues we should be aware of? --Oliver On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie howc...@opera.com wrote: Dear WebKit community, Many of us have met through various web standards efforts, such as W3C and WHAT WG. Today I'd like to introduce Opera Software in a new forum for us: the webkit-dev mailing list. We have known WebKit and its KTHML predecessor for some time. Lars Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many years. TrollTech and Opera shared a building in Oslo, a building which has earned its place in the rendering engine hall of fame. Some of our best programmers have been working on the WebKit code for a while, and today we have announced that we will be using the WebKit engine in the future [1]. We will also submit our code; switching from Presto to WebKit frees up resources and allows us to contribute to the WebKit platform. The first contributions from our side will be in multi-column layout [2]. We have experimented with combining multicol layout with page floats and column spans [3]; in 10 lines of CSS code one can create amazingly beautiful, scaleable and responsive paged presentations [4]. We hope to work with you to further strengthen the open web that we all believe in. [1] http://www.opera.com/press/releases/2013/02/13/ [2] http://www.w3.org/TR/css3-multicol/ [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats [4] http://people.opera.com/howcome/2013/02-reader Cheers, Håkon Wium Lie CTO Opera Software http://people.opera.com/howcome ___ 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] Adding blending mode to background images
Hi Rik, Can you just add an example for the better understanding please? Greetings, Dirk On Feb 2, 2013, at 6:43 AM, Rik Cabanier caban...@gmail.com wrote: Hi, I'd like to add support for blending of background images. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=108546 Please let me know of any concerns. ___ 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] Adding blending mode to background images
On Feb 2, 2013, at 8:01 AM, Benjamin Poulain benja...@webkit.org wrote: On Fri, Feb 1, 2013 at 12:44 PM, Rik Cabanier caban...@gmail.com wrote: background-image: url(a.png), url(b.png); -webkit-background-blend-mode: screen, screen; Out of curiosity: I am probably way too late for the party, but why not blend surface-to-surface? E.g. background-image: blend(url(foo.png), url(bar.png), difference). This is in order to easily stack them: background-image: blend(blend(url(foo.png), url(bar.png), difference), url(giraffe.gif), screen). I like the idea, but it has the big disadvantage that you can not repeat an image, change origin and size before blending with the next layer. Greetings, Dirk Although, maybe we don't want that as it could get more difficult to optimize... 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] Remove webkitDashArray attribute from CanvasRenderingContext2d
Hi WebKit folks, I would like to know if we can remove the following API's in the CanvasRenderingContext2d interface: webkitDashArray webkitLineDashOffset Both were implemented 16 months ago and replaced by the following standardized, unprefixed operations and attributes 5 months ago: setLineDash getLineDash lineDashOffset Note that the webkit prefixed attributes were just implemented in JavaScriptCore, no support for V8. Some of the main reason for supporting these attributes 16 months ago were: - Firefox supported them - PDF.js needed them for draw PDFs. PDF.js checks for the existence of the standardized operations and attributes now and uses them if supported. Would it be possible to clean up the code a bit more and remove the prefixed attributes? Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
On Jan 30, 2013, at 1:12 PM, Dean Jackson d...@apple.com wrote: On 30/01/2013, at 12:46 PM, Dirk Schulze dschu...@adobe.com wrote: Would it be possible to clean up the code a bit more and remove the prefixed attributes? I don't think they should be removed yet. As you mentioned, it's been 16 months which is at least one Safari release cycle. I'd prefer that we give a console warning for now. This sounds reasonable for me. Just as a note, if the next Safari release for iOS and Mac do not add this console warning, it may take another year before the code can be cleaned up. The impact is minimal so. Greetings, Dirk Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
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? Have the concerns been
submitted to the editor and the WG working on the WebIDL specification?
More and more specifications describe interfaces by using WebIDL, including
HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general
concerns on WebIDL, they should be addressed on the spec before leaving CR
state. Not implementing WebIDL could not only block this specification in
particular, but also all other specs relying on it. Or maybe worst, it gets a
recommendation and we do not follow web standards anymore. It would be great to
hear a clarification. Maybe it is just a misunderstanding on my site.
Greetings,
Dirk
[1]
https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGGraphicsElement
[2] http://www.w3.org/TR/WebIDL/#NoInterfaceObject
On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces. However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance
behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED
soon.
Do you anticipate adding properties or functions that return
interfaces like SVGLocatable?
Here is a Wiki what we plan to do:
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
It might not reflect all changes that we discussed during the SVG WG meeting
today.
Greetings,
Dirk
Adam
He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event. That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.
Adam
On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions. That means that Region introduces a form of multiple
inheritance into the DOM. For example, Element implements Region but
Node does not implement Region.
There's a patch up for review that implements Region using C++
multiple inheritance [2]:
- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {
One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.
We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance. For example, there are many subclass of
Event and toJS(Event*) needs to return a wrapper for the appropriate
subtype. To solve the same problem, CSSRule has a m_type member
variable and a bevy of isFoo() functions [3].
A) Should we push back on the folks writing the CSS Regions
specification to avoid using multiple inheritance? As far as I know,
this is the only instance of multiple inheritance in the platform.
Historically, EventTarget used multiple inheritance, but that's been
fixed in DOM4 [4].
B) If CSS Regions continues to require multiple inheritance, should we
build another one-off RTTI replacement to implement toJS(Region*), or
should we improve our bindings to implement this aspect of WebIDL more
completely?
One approach to implementing toJS in a systematic way is to introduce
a base class DOMInterface along these lines:
class DOMInterface {
public:
virtual const AtomicString primaryInterfaceName() = 0;
}
That returns the name of the primary interface (i.e., as defined by
WebIDL [5]). When implementing toJS, we'd then call
primaryInterfaceName to determine which kind of wrapper to use.
One downside of this approach is that it introduces a near-universal
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
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). Have the concerns been submitted to the editor and the WG working on the WebIDL specification? I haven't submitted my concerns. There's nothing particularly wrong with the WebIDL language, just like there's nothing particularly wrong with English just because you can use it to write a terrible poem. Well, it seems to be a bit different. Your poem would still be valid as long as it follows the grammar and can still be read, even if it does not make sense to you. You suggest not supporting everything from WebIDL, which means not accepting the full specified grammar. I think this is a concern where you would like to see limitations to the current grammar and which should be discussed. More and more specifications describe interfaces by using WebIDL, including HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general concerns on WebIDL, they should be addressed on the spec before leaving CR state. I don't have any concerns with the WebIDL language. The WebIDL language is just a mechanism for writing precise specifications. Not implementing WebIDL could not only block this specification in particular, but also all other specs relying on it. That's nonsense. Just because we don't implement some crazy corner case of WebIDL that doesn't mean that we're unable to implement *all* specs that reply upon it. For example, HTML and DOM use WebIDL and we're able to implement them just fine. You suggest not implementing some corner cases. And as you say, we won't be able to support specifications relying on these corner cases. It rather seems you agree with my statement, even if it does not block former named specifications yet. I am not questioning your arguments to not support all corner cases of WebIDL. I am asking for an open discussion about particular cases on the relevant mailing lists (public-webapps for WebIDL) to address these concerns in the specification before leaving CR. Or maybe worst, it gets a recommendation and we do not follow web standards anymore. It would be great to hear a clarification. Maybe it is just a misunderstanding on my site. There's no experiment that you can run using web content to detect whether we implement WebIDL. All you can detect is whether we implement particular specifications that use WebIDL. We can just simply not implement the specifications that require COM-like implementations and we can continue to lead a happy life. This seems indeed a problem for WebIDL, since tests and testability is a requirement to leave CR. However, the WebApps WG might have a different thought. Greetings, Dirk Adam On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote: On Jul 25, 2012, at 3:50 PM, Adam Barth wrote: On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote: On Jul 25, 2012, at 2:33 PM, Adam Barth wrote: Eric Seidel points out that SVG uses multiple inheritance in its DOM interfaces. However, the situation there is a bit different. Although SVGSVGElement implements SVGLocatable, there aren't any interfaces with methods that return SVGLocatable, which means we don't need to implement toJS(SVGLocatable*). SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon. Do you anticipate adding properties or functions that return interfaces like SVGLocatable? Here is a Wiki what we plan to do: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
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.
If SVG2 does happen to avoid the problem, would we want to use implements
as the syntax in WebKitIDL or would we want a different syntax? I could see
arguments either way.
I think it would be desirable to follow WebIDL and the syntax of this
specifications as long as the goals overlap.
(FWIW I agree that we don't want to end up in a position where we'd have to
implement a QI-like mechanism for the sake of the bindings, but I can't tell
from the conversation so far if this is an immediate issue with SVG2, or just
a possible issue with other potential uses of implements).
If I understand Adam correctly, then the later. If there are problems with the
SVG2 specification, then I am happy to talk with the SVG WG and find solutions.
But the SVG WG still needs to cover the behavior of SVG 1.1 as much as possible.
Greetings,
Dirk
Regards,
Maciej
___
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)
On Jan 25, 2013, at 8:16 PM, Elliott Sprehn espr...@chromium.org wrote:
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.
As far as I understood it, HTMLInputElementFileSystem extends HTMLInputElement.
In WebIDL it would be:
HTMLInputElement implements HTMLInputElementFileSystem;
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.
Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
Hi Steve, Thank you for your interest on WebKit. Of course we would like to fix as many bugs as possible in a time frame as short as possible. With limited resources, this does not work very well for some bugs. So we need to prioritize our work. Even if external resources might be a priority for you, it doesn't need to be for others. We currently focus on performance and security. And external references in SVG have their security issues on their own (why we are very careful on implementing them). After all, WebKit is an open source project. Even if you already contributed by reporting bugs (thank you for that), you are very welcome to commit patches. I see that you may have limited time, as we do as well. A lot of people on this project still contribute in their spare time, even if they are employed to work on WebKit. Please join us to make webkit better. I am happy to review your SVG patches. Greetings, Dirk On Jan 14, 2013, at 12:52 AM, Steve Williams stephen.j.h.willi...@googlemail.commailto:stephen.j.h.willi...@googlemail.com wrote: Hi Maciej, 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.commailto:stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Jan 9, 2013, at 5:40 PM, Simon Fraser simon.fra...@apple.com wrote: On Jan 9, 2013, at 4:52 PM, Steve Block stevebl...@chromium.org wrote: I'm really not sure that this set of changes is going in the right direction. What's driving them; some abstract sense of purity, or reducing the chances of introducing real bugs that we've seen in the past? Some of both. I was investigating a bug where WebCore is generating unexpected negative sizes. While looking into how this could happen, I noticed that in some cases, negative sizes result from size types being used to represent things that seem more like points. It seems like it would be good to clean this up this misuse of size types, and perhaps in the long term, we can avoid negative sizes altogether, which would help avoid these kinds of bug in the future. It seems like a lot of churn for relatively little gain. I'd rather our time be focused on areas that actually benefit users of WebKit. I agree with this concern. Another object for representing 2D vector data will cause more maintenance cost now and in the future. And I doubt that it gives a big enough benefit over defining when to use Point and Size today. Greetings, Dirk Simon ___ 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] Keeping up with new additions to canvas
On Jan 8, 2013, at 11:37 AM, Dean Jackson d...@apple.com wrote: As well as the other suggestions, you can look at bugs in the Canvas component. e.g. https://bugs.webkit.org/show_bug.cgi?id=82790 Marked as duplicate ;) Dirk We should probably have a owner bug to collect all the HTML5-ish Canvas changes. Dean On 07/01/2013, at 11:18 PM, RGraph.net support richard.he...@gmail.com wrote: Hi, Is watching this mailing list the best way to keep up-to-date with new additions to the WebKit canvas implementation (such as the canvas Path object or hit regions)? Or perhaps there's an announcements list too? Thanks! -- Richard ___ 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] Changes to the WebKit2 development process
On Jan 8, 2013, at 2:57 PM, Sam Weinig wei...@apple.com wrote: Hello webkit-dev, We are making some changes to the development process for WebKit2. These changes were announced to reviewers in advance, and I'd like to share them with you now. WebKit2 has a core set of functionality that is valuable to all ports, and then aspects that are only of limited/specialized interest. It is becoming increasingly difficult to improve and advance the core functionality while maintaining the more peripheral aspects. In addition, changes to the core often require significant expertise to evaluate, for instance to ensure that the security and responsiveness goals of WebKit2 are met. The changes are: 1) WebKit2 now has owners. Only owners should review WebKit2 patches. While we do not want to apply this concept across the whole WebKit project at this time, for WebKit2 it is appropriate. The list of owners is documented in the Owners file at the WebKit2 top level directory, and in committers.py. 2) Ports must keep themselves building. Non Apple Mac ports, if broken by core functionality changes to WebKit2, are now responsible for fixing themselves. We have asked those who run the EWS bots to make sure that failing to build WebKit2 does not block the commit queue from committing. I didn't see a settlement on this point of the proposal on previous discussions. Did you elaborate on the feedback that you got when you asked for that the first time? I think it is a question of fair play to not leave core build bots of other platforms broken. That is what we agreed on WebKit and I don't see the reason why it should be different on WebKit2 (which is a part of WebKit). That doesn't mean that the other suggestions aren't reasonable. Greetings, Dirk 3) Over time, owners may remove peripheral functionality from the main WebKit2 directory, such as support for features that aren't broadly applicable. We will not do this immediately, and we will work with ports that are interested in such features to create appropriate, maintainable general-purpose mechanisms that can be used to implement them outside of core WebKit2 code. While we understand that this change will inconvenience some ports, we have decided that forward progress of WebKit2 is a more important concern, and we are moving forward with this change tonight. - Sam ___ 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] Keeping up with new additions to canvas
On Jan 7, 2013, at 4:18 AM, RGraph.net support richard.he...@gmail.com wrote: Hi, Is watching this mailing list the best way to keep up-to-date with new additions to the WebKit canvas implementation (such as the canvas Path object or hit regions)? Or perhaps there's an announcements list too? Bigger new features like Path or hit region proposals need to get pronounced on this list. Smaller improvements (bug fixes) are not necessarily announced. There is no separate list beside webkit-changes for all changes to WebKit. Greetings, Dirk Thanks! -- Richard ___ 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] Proposal: Add webkitFillRule to canvas
On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. Greetings, Dirk ___ 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] Proposal: Add webkitFillRule to canvas
On Jan 4, 2013, at 7:28 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze dschu...@adobe.commailto:dschu...@adobe.com wrote: On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.chmailto:i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) I don't see the problem here. That is how canvas works currently. fill() and clip() use the currentPath. Seems to be more natural to use the property then. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. Not at all, as demonstrated with the patch. How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. No, because the path is already applied to the context. That makes the property so natural and easy to implement. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . Right. I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. PDF.js - the JavaScript library. Not PDF the standard. And the library uses it already according to previous posts. Greetings, Dirk Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote: Hi everyone, I wanted to let you know that I have added the new CSS3 background-position offsets support to WebKit. This support is behind the ENABLE_CSS3_BACKGROUND feature define and it's disabled by default on all ports. I took the conservative approach despite it's a cool feature. Long story short, it allows you to specify three or four values to background-position. It's a nice addition as you can now position the images using length or values in relation to any of the four corners of elements, not just the top left corner. Opera, IE10 and Firefox implements this feature already (though the latter returns weird results using getComputedStyle). It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the two patches landed (parsing and rendering) are http://trac.webkit.org/changeset/135632 and http://trac.webkit.org/changeset/136378. I believe the position type (3-4 values) could be/or is used in other cases so we can reuse the parsing code for four/three values if needed. I will investigate this afterwards and make appropriate patches. I really hope that we don't use it any where else again (with the exception of -webkit-mask-position which should have same behavior as background-position). This is the use case for the calc() function. Sadly the calc() function came to late for CSS3 Backgrounds. That said, great work regarding the interoperability with other browsers. Greetings, Dirk I plan to enable it by default on Qt and EFL ports this week. If somebody wants me to enable it on their ports please tell me, I'll be happy to do it. Looking forward to your comments. Spec : http://www.w3.org/TR/css3-background/#the-background-position -- 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
Re: [webkit-dev] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 5:31 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote: Hi everyone, I wanted to let you know that I have added the new CSS3 background-position offsets support to WebKit. This support is behind the ENABLE_CSS3_BACKGROUND feature define and it's disabled by default on all ports. I took the conservative approach despite it's a cool feature. Long story short, it allows you to specify three or four values to background-position. It's a nice addition as you can now position the images using length or values in relation to any of the four corners of elements, not just the top left corner. Opera, IE10 and Firefox implements this feature already (though the latter returns weird results using getComputedStyle). It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the two patches landed (parsing and rendering) are http://trac.webkit.org/changeset/135632 and http://trac.webkit.org/changeset/136378. I believe the position type (3-4 values) could be/or is used in other cases so we can reuse the parsing code for four/three values if needed. I will investigate this afterwards and make appropriate patches. I really hope that we don't use it any where else again (with the exception of -webkit-mask-position which should have same behavior as background-position). This is the use case for the calc() function. Sadly the calc() function came to late for CSS3 Backgrounds. -webkit-mask-position should behave the same way as background-position? Even if I add feature to the latter? Why so? Because -webkit-mask and background share the same properties and syntax. Why should it be different on -webkit-mask-position? (Btw. CSS Masking already adapted the background-position syntax for mask-position[1]) it seems like transform-origin supports something similar. I need to look at it. http://www.w3.org/TR/css3-transforms/#transform-origin-property It definitely does not :) Greetings, Dirk [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position That said, great work regarding the interoperability with other browsers. Greetings, Dirk I plan to enable it by default on Qt and EFL ports this week. If somebody wants me to enable it on their ports please tell me, I'll be happy to do it. Looking forward to your comments. Spec : http://www.w3.org/TR/css3-background/#the-background-position -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- 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
Re: [webkit-dev] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 6:12 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Dec 3, 2012 at 10:42 AM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 5:31 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote: Hi everyone, I wanted to let you know that I have added the new CSS3 background-position offsets support to WebKit. This support is behind the ENABLE_CSS3_BACKGROUND feature define and it's disabled by default on all ports. I took the conservative approach despite it's a cool feature. Long story short, it allows you to specify three or four values to background-position. It's a nice addition as you can now position the images using length or values in relation to any of the four corners of elements, not just the top left corner. Opera, IE10 and Firefox implements this feature already (though the latter returns weird results using getComputedStyle). It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the two patches landed (parsing and rendering) are http://trac.webkit.org/changeset/135632 and http://trac.webkit.org/changeset/136378. I believe the position type (3-4 values) could be/or is used in other cases so we can reuse the parsing code for four/three values if needed. I will investigate this afterwards and make appropriate patches. I really hope that we don't use it any where else again (with the exception of -webkit-mask-position which should have same behavior as background-position). This is the use case for the calc() function. Sadly the calc() function came to late for CSS3 Backgrounds. -webkit-mask-position should behave the same way as background-position? Even if I add feature to the latter? Why so? Because -webkit-mask and background share the same properties and syntax. Why should it be different on -webkit-mask-position? (Btw. CSS Masking already adapted the background-position syntax for mask-position[1]) Ok sure. Then I will make -webkit-mask-position to behave the same per http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position . I did know they share the code but I didn't know how far. Thanks for pointing it out. it seems like transform-origin supports something similar. I need to look at it. http://www.w3.org/TR/css3-transforms/#transform-origin-property It definitely does not :) Sorry about that I read super quickly and based my thought of one of the test of css3test.com which expect right 10px bottom 20px and https://bugs.webkit.org/show_bug.cgi?id=37514#c8 . I'm not sure what is valid or not. Maybe Simon could tell us. Simon and I discussed it with the CSS WG and we came to the conclusion that we should not introduce the background-position syntax somewhere else in favor for calc(). -webkit-mask is so similar to background, that people have the expectations to behave the same. This is why -webkit-mask-position is an exception. Greetings Dirk Greetings, Dirk [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position That said, great work regarding the interoperability with other browsers. Greetings, Dirk I plan to enable it by default on Qt and EFL ports this week. If somebody wants me to enable it on their ports please tell me, I'll be happy to do it. Looking forward to your comments. Spec : http://www.w3.org/TR/css3-background/#the-background-position -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 8:43 AM, Simon Fraser simon.fra...@apple.com wrote: On Dec 3, 2012, at 4:51 AM, Alexis Menard wrote: I plan to enable it by default on Qt and EFL ports this week. If somebody wants me to enable it on their ports please tell me, I'll be happy to do it. I think it's preferable to enable for all ports if you think it's ready. In general, features should be enabled on trunk for everyone. Ports can turn off features in their shipping branches if they so choose. Why does this feature have a flag at all? background-position with up to 4 arguments is specified with CSS3 background and borders. There are three major implementations with this feature. So we are just catching up. If the future works as expected (and we should have tests that verify it), then we should remove the flag completely. Greetings, Dirk Simon ___ 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] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote: Why does this feature have a flag at all? background-position with up to 4 arguments is specified with CSS3 background and borders. There are three major implementations with this feature. So we are just catching up. If the future works as expected (and we should have tests that verify it), then we should remove the flag completely. Sounds like good practice to me. Why _not_ start that feature with a flag then remove the flag when fully ready/tested??? Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. Greetings, Dirk Benjamin ___ 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] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 1:15 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze dschu...@adobe.com wrote: Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. See http://trac.webkit.org/wiki/AddingFeatures The policy for adding new (major) features to WebKit is: major says everything IMO. background-position is not a major feature. However, to stay at the topic: Is there anything blocking 'background-position' with the new syntax? Any objections to remove the flags? If yes, I would like to know more about the problems. Greetings, Dirk I personally appreciate when authors take the time to have feature flags until the feature is finished. It has many advantages for making releases. Benjamin ___ 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] Adding CSS3 background-position offsets.
On Dec 3, 2012, at 2:54 PM, Alexis Menard ale...@webkit.org wrote: On Dec 3, 2012 6:21 PM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 1:15 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze dschu...@adobe.com wrote: Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. See http://trac.webkit.org/wiki/AddingFeatures The policy for adding new (major) features to WebKit is: major says everything IMO. background-position is not a major feature. However, to stay at the topic: Is there anything blocking 'background-position' with the new syntax? Any objections to remove the flags? If yes, I would like to know more about the problems. I can still remove the flag when everything is done. Probably tomorrow or so. I think it is reasonable to do this if no one objects till tomorrow. Greetings, Dirk Greetings, Dirk I personally appreciate when authors take the time to have feature flags until the feature is finished. It has many advantages for making releases. Benjamin ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit + OpenCL
On Nov 23, 2012, at 2:43 PM, Andreas Kling akl...@apple.com wrote: Hi folks, Do we really think it's a good idea to add yet another implementation of filters? We already have generic, NEON-optimized and WTF::ParallelJobs (which includes generic, OpenMP and libdispatch backends) implementations of this code, and now we're adding OpenCL too. On the WebKit Project Goals page http://www.webkit.org/projects/goals.html, it states that: WebKit is an engineering project not a science project. For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. Correct me if I'm wrong, but we don't see much use of these features on the web. I understand that there's a bit of a chicken/egg problem where a feature won't be interesting to content creators until it performs well enough, but it seems like we could at least decide on a single path forward instead of repeatedly forking the code. I designed the current SVG Filters implementation in a way that hopefully make it possible to implement HW accelerated filters on top of it. Skia and NEON already go this path. I am not defending the OpenCL implementation for SVG Filters per se, but different platform dependent solutions were expected and wanted. Software filters were designed to be a fallback if an implementation does not provide HW acceleration (yet). I hope that we see a Core Image version of filters in the near future as well. The code for that is in the history of the repository already. Greetings, Dirk -Kling On Nov 21, 2012, at 7:30 PM, Zoltan Herczeg zherc...@webkit.org wrote: Hi, we start upstreaming some OpenCL optimizations into WebKit. This is the master bug: https://bugs.webkit.org/show_bug.cgi?id=70099 Regards, Zoltan ___ 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] Adding blending mode to WebKit canvas
On Nov 11, 2012, at 10:09 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze k...@webkit.orgmailto:k...@webkit.org wrote: On Sunday, November 11, 2012, Rik Cabanier wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@gmail.com wrote: Wouldn't it be better to add a new property to canvas for blending? At the beginning, implementations are just require to use different blend modes in combination with 'source-over'. That could work too. There was a mailing list conversation about this a couple of months ago, and people were evenly split on the subject. The vast majority of cases will use 'source-over' in combination with blending so maybe it's best to keep it simple... It doesn't make sense to me for blend mode and composite operator to be separate in CSS, but combined in Canvas. Either there are valid use cases for specifying them separately or there are not. I cannot imagine how this could differ between Canvas and CSS. To be fair, the 'globalCompositOperator' property mixed the compositing modes with some blend modes already. Which is the fault of the WebKit implementation. IIRC they have been removed from the Canvas part of the HTML spec for some time, but were added later again. Now we have multiple independent implementations that support all currently specified operators. Is this the 'darker' compositing mode or are there others? Lighter and darker, yes. Greetings Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Adding blending mode to WebKit canvas
On Nov 9, 2012, at 4:39 PM, Rik Cabanier caban...@gmail.com wrote: Hi, I'd like to add support for blending modes to Canvas. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=100069 I also attached a large patch that shows how this feature can be implemented. Looking at your patches on bug 100069 and bug 101804, I actually have some questions. If I understand your API changes correctly, the 'globalCompositeOperation' property gets more keywords. The new keywords will be the same as for the 'blend-mode' property of the CSS Compositing spec. Does it mean that blend mode always will use the compositing operator 'source-over'? The example implementation of GraphicsContext::setPlatformCompositeOperation on CG indicates that it would be possible to combine blend modes with different compositing operators in CG already. If you set both with the same property 'globalCompositeOperation', it won't be possible to mix them in the future. If more implementations are capable to support mixing alpha compositing and blending, the property can not be changed anymore. Wouldn't it be better to add a new property to canvas for blending? At the beginning, implementations are just require to use different blend modes in combination with 'source-over'. Btw. why is this addition in CSS Compositing and not in the Canvas spec? Greetings, Dirk Please let me know of any concerns. ___ 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] Adding blending mode to WebKit canvas
On Sunday, November 11, 2012, Rik Cabanier wrote:
On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak
m...@apple.comjavascript:_e({}, 'cvml', 'm...@apple.com');
wrote:
On Nov 11, 2012, at 6:59 PM, Rik Cabanier
caban...@gmail.comjavascript:_e({}, 'cvml', 'caban...@gmail.com');
wrote:
Wouldn't it be better to add a new property to canvas for blending? At
the beginning, implementations are just require to use different blend
modes in combination with 'source-over'.
That could work too.
There was a mailing list conversation about this a couple of months ago,
and people were evenly split on the subject.
The vast majority of cases will use 'source-over' in combination with
blending so maybe it's best to keep it simple...
It doesn't make sense to me for blend mode and composite operator to be
separate in CSS, but combined in Canvas. Either there are valid use cases
for specifying them separately or there are not. I cannot imagine how this
could differ between Canvas and CSS.
To be fair, the 'globalCompositOperator' property mixed the compositing
modes with some blend modes already. Which is the fault of the WebKit
implementation. IIRC they have been removed from the Canvas part of the
HTML spec for some time, but were added later again. Now we have multiple
independent implementations that support all currently specified operators.
Greetings,
Dirk
There are cases where it makes sense to have them as separate properties.
To be honest, the main reason that the Canvas proposal combines them, is
because it is not possible to implement this efficiently using Core
Graphics.
If we break it up in 2 operations, we have to document the correct
behavior (= blending does not force source-over for blending) because the
spec can't be changed later.
This means that Safari and Firefox for Mac can only implement part of the
spec...
I prefer to have a consistent implementation that can be extended later as
opposed to a 'correct' API that is inconsistently implemented.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS and CORS
Hi WebKit folks,
I have a question to origin restriction and CSS. First the context:
CSS Masking[1] aims to combine the two different 'mask' property
implementations from WebKit and Firefox. To make it short, 'mask' takes an URL
and this can either be a reference to an image, or to an mask element:
svg
mask id=mask
…
/mask
/svg
style
img {
mask: url(#mask); /* references an SVG Mask element for masking
operation (Firefox), OR */
-webkit-mask: url(test.png); / takes a reference to an image and
operates the masking with the image (WebKit) */
/style
img … /
CSS Masking tries to make both possible in the future.
The problem is, that a mask can be in an external SVG file and be referenced
by SVG fragments: url(http://external.com/mask.svg#mask). It would still not be
sure it the fragment points to a graphical element like a path (then the SVG
file would be interpreted as image) or if it references a mask element, in
which case it will be an external resource. You need to download the file and
parse it to know that.
Does it matter to know if it is an external resource or image before
downloading?
A mask element can have events, which run JavaScript: mask
onload=console.log('CORS? Of course!'). Running the mask element will fire
the event, which is maybe a violation against CORS, since the SVG file can come
from a different origin.
For images, we don't care about the origin, don't run scripts and don't fire
events.
My question is if we have already an CSS property, widely implemented in
WebKit, where CORS matters? When do we decide not to go on with the
interpretation of a resource because of violation of CORS? Before we even
download the resource? After we may already parsed it?
Firefox does care about that before parsing and does not load the entire SVG
file if it is from a different origin. Since Firefox does not support image
references for 'mask', they always assume that the reference is an external
reference and not an image.
Opera does not care about the origin, but scripts are not executed and events
don't fire.
Greetings,
Dirk
[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property
PS: WebKit has support for 'mask' property with referencing of mask elements.
Currently, external files are not supported. The mask element must be in the
same document.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS and CORS
On Oct 26, 2012, at 9:04 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Oct 26, 2012 at 9:08 AM, Dirk Schulze dschu...@adobe.com wrote:
Hi WebKit folks,
I have a question to origin restriction and CSS. First the context:
CSS Masking[1] aims to combine the two different 'mask' property
implementations from WebKit and Firefox. To make it short, 'mask' takes an
URL and this can either be a reference to an image, or to an mask element:
svg
mask id=mask
…
/mask
/svg
style
img {
mask: url(#mask); /* references an SVG Mask element for masking
operation (Firefox), OR */
-webkit-mask: url(test.png); / takes a reference to an image and
operates the masking with the image (WebKit) */
/style
img … /
CSS Masking tries to make both possible in the future.
The problem is, that a mask can be in an external SVG file and be
referenced by SVG fragments: url(http://external.com/mask.svg#mask). It
would still not be sure it the fragment points to a graphical element like a
path (then the SVG file would be interpreted as image) or if it references
a mask element, in which case it will be an external resource. You need to
download the file and parse it to know that.
Does it matter to know if it is an external resource or image before
downloading?
Ouch. That sounds like a bad constraint. How do you plan to
implement that? I guess you'd need to load the SVG as an SVGImage and
then either extract the path or the bitmap depending if there is an
element with a given ID? At what point do you check for the ID? For
example, do you want for DOMContentLoaded, or do you wait to see if an
ID gets added by JavaScript executing in the page? Can mask.svg
execute JavaScript? (Normally we ban the execution of JavaScript
inside SVGImage.)
We could load the external file as a document (similar to iframe), check for
the header first, if it is an SVG document we check the element if it is a mask
or not. That was at least my naive idea. :)
A mask element can have events, which run JavaScript: mask
onload=console.log('CORS? Of course!'). Running the mask element will
fire the event, which is maybe a violation against CORS, since the SVG file
can come from a different origin.
I see! If the mask element can execute JavaScript, then we cannot
load the resource in an SVGImage because we forbid JavaScript
execution in an SVGImage. Where do you plan to load mask.svg?
Yes. But I just learned that Gecko never executes scripts on external
resources. External references don't have a browser context in Gecko and
therefore don't run JavaScript. Opera does support scripts if it is from the
same origin. However, this is unspecified in SVG and I am working towards
finding a common and secure solution. The approach from Gecko seems to be sane.
For images, we don't care about the origin, don't run scripts and don't fire
events.
Correct.
My question is if we have already an CSS property, widely implemented in
WebKit, where CORS matters?
CORS is supposed to matter for @font-face. I'm not sure whether it
does in our current implementation. In any case, it's easy to add
CORS support for a load. You can look at how the crossorigin
attribute for img works.
When do we decide not to go on with the interpretation of a resource because
of violation of CORS? Before we even download the resource? After we may
already parsed it?
The CORS go/no-go decision happens when we receive the response
headers, before we start parsing the resource.
Firefox does care about that before parsing and does not load the entire SVG
file if it is from a different origin. Since Firefox does not support image
references for 'mask', they always assume that the reference is an external
reference and not an image.
That seems vastly more sane. Supporting both images and mask
elements with the same syntax seems very difficult, if not impossible
given the constraints that we need to execute JavaScript for the
mask case.
Yes, the scripting part is a bit odd. I think following Gecko and don't allow
scripting on any external document seems sane.
Opera does not care about the origin, but scripts are not executed and
events don't fire.
Can we do that? Note: You still need to sorry about CORS because this
API lets you query for whether a document contains an element of a
given ID, which isn't something you're supposed to be able to learn
about cross-origin resources.
It would be a bit like the solution from Gecko, if no browser context, then no
script. Gecko added CORS as an additional restriction, which seems to be more
secure. clipPath for instance contributes to hit testing.
PS: WebKit has support for 'mask' property with referencing of mask
elements. Currently, external files are not supported. The mask element must
be in the same document.
Can we continue to do that? Referencing external files
Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?
On Monday, October 1, 2012, Gyuyoung Kim wrote:
Hello WebKit folks,
There were build warning related to unused parameter nowadays. I think
there are three solutions. One is to remove parameter,
another is to use UNUSED_PARAM macro and the other is to use /* */ in
parameters.
I like to use UNUSED_PARAM macro except for primitive parameters
personally, for example
void foo(RenderObject* object, int /*width*/, int /*height*/) {
UNUSED_PARAM(object);
}
I'd like to know what webkittens think about this.
If it is crystal clear what the parameters stand for, omit them. If not,
you find them commented out. UNUSED_PARAM is used when just some platforms
of flagged features use parameters, others not.
Dirk
Cheers,
Gyuyoung
___
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
On Sep 24, 2012, at 12:03 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler da...@apple.commailto:da...@apple.com wrote: On Sep 22, 2012, at 9:21 PM, Elliott Sprehn espr...@chromium.orgmailto:espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.commailto:dschu...@adobe.com wrote: 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. Dirk, given the fact that you quite logically referred to this as “the canvas Path object” when mentioning it to us, and the fact that both CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for this. Someone should make that suggestion on the WebApps mailing list! I am interested in the feature, not the name. I am fine with naming it CanvasPath. Remember that Path is not limited to Canvas, other then for instance SVGPathElement. I just want to avoid that people come to the impression that this can just be used for Canvas. A difference though is that the path object doesn't have to be associated with a canvas. It is/will be useful with other features such as SVG as well. I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better. DOM and HTML will lead to the same wrong conclusions IMO. And JS seems unusual as prefix. Greetings Dirk ___ 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
I know of at least one JS library that uses Path as object (paper.js). But the definition can be overridden. It is unlikely that this will break content, as long as the library does not want to use both. Other then that, the SVG WG wants to reuse the Path object in SVG and CanvasObject might confuse people but this seems unlikely as well. Greetings, Dirk Sent from my iPhone On Sep 23, 2012, at 6:22 AM, Elliott Sprehn espr...@chromium.orgmailto:espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.commailto: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
[webkit-dev] New Feature: Canvas Path object
Hi WebKit, I would like to ask if there are objections to implement the canvas Path object. The HTML Canvas specification and the WHAT WG HTML specification define the Path object [1][2]. The Path object and the CanvasRenderingContext2D share some graphics operations[3]: - closePath - lineTo - moveTo - arc - arcTo - ellipse (not implemented yet) - quadraticCurveTo - cubicCurveTo - rect But instead of drawing onto a Canvas, the operations get applied to a Path object. Furthermore the object allows adding other Paths with transforms. A Path object can then be drawn onto a Canvas. I opened https://bugs.webkit.org/show_bug.cgi?id=97333 for a patch and detailed discussions. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects [2] http://dev.w3.org/html5/2dcontext/#path-objects [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone willing to update webkit.org?
On Sep 18, 2012, at 7:04 PM, Eric Seidel e...@webkit.org wrote: I was noticing today that http://www.webkit.org/ is quite old and out of date. What xenon built 6 years ago, has stood up remarkably well, but it may be time for a refresh. (It also has no high-dpi support.) I'm aware that I have the ability to change it. But I'm also inviting others to do so: http://trac.webkit.org/browser/trunk/Websites/webkit.org In particular: - It mentions nothing of Safari on iOS or Chrome (which must be some huge fraction of our userbase by now) - Could link to numerous other sites showing information about WebKit (cia, ohloh, svnsearch) - Projects like SVG really aren't the current focus. :) They are not? Maybe not for you :) Dirk I'm sure this list is full of individuals with infinitely more visual design sense than I. So I invite your patches, my reviewing and committing fingers stand ready. :) -eric ___ 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] String::operator+= considered harmful
I thought we had efforts to make String::operator+= use StringBuilder somehow? I can remember that we had a discussion on webkit-dev and definitely on bugzilla about improving String::operator+= instead of replacing it with StringBuilder. Greetings, Dirk On Sep 4, 2012, at 4:22 PM, Adam Barth aba...@webkit.org wrote: As part of the work to deploy efficient string patterns [1] throughout WebKit, Benjamin and I noticed a bunch of very inefficient code that uses operator+= with Strings: String foo; for (...) foo += [...]; return foo; This pattern is particularly inefficient because += mallocs an entirely new buffer for the result and copies the the string into the new buffer. That means that this pattern makes O(n) calls to malloc and does O(n^2) work. A more efficient pattern is to use StringBuilder: StringBuilder foo; for (...) foo.append([...]); return foo.toString(); I'm in the process of going through WebCore and removing all callers of WTF::String::operator+=. Once that's complete, my plan is to remove WTF::String::operator+= from WTFString.h. Hopefully that will nudge contributors and reviewers towards more efficient string patterns. Removing operator+= will likely require changes to a number of port-specific files. I'll do my best to remove these, but I might need some help from maintainers of individual ports. If you're interested in helping out, please let me know. Many thanks, Adam [1] http://trac.webkit.org/wiki/EfficientStrings ___ 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] String::operator+= considered harmful
With a short search in the logs I found optimizations for at least operator+, but didn't search further: http://trac.webkit.org/changeset/86330 https://bugs.webkit.org/show_bug.cgi?id=58420 Greetings, Dirk On Sep 4, 2012, at 4:31 PM, Adam Barth aba...@webkit.org wrote: Do you have a proposal for how that would work and/or a link to the previous discussion? Adam On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze dschu...@adobe.com wrote: I thought we had efforts to make String::operator+= use StringBuilder somehow? I can remember that we had a discussion on webkit-dev and definitely on bugzilla about improving String::operator+= instead of replacing it with StringBuilder. Greetings, Dirk On Sep 4, 2012, at 4:22 PM, Adam Barth aba...@webkit.org wrote: As part of the work to deploy efficient string patterns [1] throughout WebKit, Benjamin and I noticed a bunch of very inefficient code that uses operator+= with Strings: String foo; for (...) foo += [...]; return foo; This pattern is particularly inefficient because += mallocs an entirely new buffer for the result and copies the the string into the new buffer. That means that this pattern makes O(n) calls to malloc and does O(n^2) work. A more efficient pattern is to use StringBuilder: StringBuilder foo; for (...) foo.append([...]); return foo.toString(); I'm in the process of going through WebCore and removing all callers of WTF::String::operator+=. Once that's complete, my plan is to remove WTF::String::operator+= from WTFString.h. Hopefully that will nudge contributors and reviewers towards more efficient string patterns. Removing operator+= will likely require changes to a number of port-specific files. I'll do my best to remove these, but I might need some help from maintainers of individual ports. If you're interested in helping out, please let me know. Many thanks, Adam [1] http://trac.webkit.org/wiki/EfficientStrings ___ 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] String::operator+= considered harmful
Yes, looks like the efforts didn't went further. Anyway, is there no possibility to improve operator+= further? It is very likely that even future code will land with this operator instead of StringBuilder. I think it is better to try to change the operator (if possible) instead of people. Greetings, Dirk On Sep 4, 2012, at 4:41 PM, Adam Barth aba...@webkit.org wrote: Ah, you're think of operator+, which is now quite efficient. This thread is about operator+=, which is sadly slower than molasses. Adam On Tue, Sep 4, 2012 at 4:38 PM, Dirk Schulze dschu...@adobe.com wrote: With a short search in the logs I found optimizations for at least operator+, but didn't search further: http://trac.webkit.org/changeset/86330 https://bugs.webkit.org/show_bug.cgi?id=58420 Greetings, Dirk On Sep 4, 2012, at 4:31 PM, Adam Barth aba...@webkit.org wrote: Do you have a proposal for how that would work and/or a link to the previous discussion? Adam On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze dschu...@adobe.com wrote: I thought we had efforts to make String::operator+= use StringBuilder somehow? I can remember that we had a discussion on webkit-dev and definitely on bugzilla about improving String::operator+= instead of replacing it with StringBuilder. Greetings, Dirk On Sep 4, 2012, at 4:22 PM, Adam Barth aba...@webkit.org wrote: As part of the work to deploy efficient string patterns [1] throughout WebKit, Benjamin and I noticed a bunch of very inefficient code that uses operator+= with Strings: String foo; for (...) foo += [...]; return foo; This pattern is particularly inefficient because += mallocs an entirely new buffer for the result and copies the the string into the new buffer. That means that this pattern makes O(n) calls to malloc and does O(n^2) work. A more efficient pattern is to use StringBuilder: StringBuilder foo; for (...) foo.append([...]); return foo.toString(); I'm in the process of going through WebCore and removing all callers of WTF::String::operator+=. Once that's complete, my plan is to remove WTF::String::operator+= from WTFString.h. Hopefully that will nudge contributors and reviewers towards more efficient string patterns. Removing operator+= will likely require changes to a number of port-specific files. I'll do my best to remove these, but I might need some help from maintainers of individual ports. If you're interested in helping out, please let me know. Many thanks, Adam [1] http://trac.webkit.org/wiki/EfficientStrings ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] CSS Masking in WebKit
Hi Dave, On Aug 31, 2012, at 11:57 AM, David Hyatt hy...@apple.com wrote: This is great! I'd like to be the goto reviewer for any changes you make on the CSS Masking side, since I implemented the original code. I also want to be kept in the loop if any changes are made to the way any of the -webkit-mask-* properties are specified. There are some interesting differences (especially in default values) when compared with the corresponding background/border-image properties, and I want to make sure all of that is well understood. I try to be careful and definitely keep you in the loop for -webkit-mask* related patches. Thank you for your interest! Also, it's important to make sure if there are any deviations/changes, that the -webkit-prefixed versions of these properties don't change behavior. Backwards compatibility is extremely important here. You'll notice that the way I preserved backwards compatibility on border-image for example was to go ahead and implement the unprefixed versions. I don't really have a good suggestion for how to do that here... it's possible a new prefix will be necessary. It all depends on if any changes are made that would break existing code. There is indeed one change in the Spec, that differs to the behavior in WebKit. The CSS WG resolved to remove -webkit-mask-attachment from the specification (unless it is requested by developers to add it again). This itself doesn't affect the behavior on WebKit much - rendering wise. However, it influences the syntax of the the shorthand -webkit-mask, which doesn't take attachment as type anymore. Greetings, Dirk dave (hy...@apple.com) On Aug 29, 2012, at 5:41 PM, Dirk Schulze wrote: Hi WebKit folks, The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. Basically the spec aims to specify the behavior of -webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath on Firefox. I would like to implement the specification in the next weeks and months. Since masking and clipping are basic operations that use the existing capabilities in all graphic libraries, and sine we are using it heavily internally in WebKit already, I do not plan to introduce a new compiler flag. However, some features will be covered by existing compiler flags like SVG Mask and SVG ClipPath, allowing to disable these parts. I created a master bug that covers the work [2]. Greetings, Dirk [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html [2] https://bugs.webkit.org/show_bug.cgi?id=95389 ___ 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
[webkit-dev] CSS Masking in WebKit
Hi WebKit folks, The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. Basically the spec aims to specify the behavior of -webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath on Firefox. I would like to implement the specification in the next weeks and months. Since masking and clipping are basic operations that use the existing capabilities in all graphic libraries, and sine we are using it heavily internally in WebKit already, I do not plan to introduce a new compiler flag. However, some features will be covered by existing compiler flags like SVG Mask and SVG ClipPath, allowing to disable these parts. I created a master bug that covers the work [2]. Greetings, Dirk [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html [2] https://bugs.webkit.org/show_bug.cgi?id=95389 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the New XMLParser dead?
On Aug 27, 2012, at 4:28 PM, Adam Barth aba...@webkit.org wrote: On Mon, Aug 27, 2012 at 4:02 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 27, 2012, at 3:48 PM, Adam Barth aba...@webkit.org wrote: On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 27, 2012, at 2:45 PM, Eric Seidel e...@webkit.org wrote: Checking back in: Curious if this effort is still underway. Adam and I would like to delete the New XML Parser if it's not needed in order to simplify the HTML 5 Parser again. :) We do tentatively plan to get back to it (the original implementor is currently working full-time at Apple on the WebKit team). As far as I can tell, no one has worked on the NEWXML code in over a year, the implementation doesn't work, and the code is disabled by all ports. It seems like we should remove it from trunk. We can retore it if/when someone is interested in working on it again. What you describe as the current status is (afaik) correct. The data point I provided (since Eric asked) is that we do in fact plan to get back to it. As far as simplifying the HTML5 parser - isn't most of the foundational work that touches the HTML5 parser also required for WebVTT, as mentioned by me in the email you quote below? Is there a big simplicity win to be had without breaking WebVTT? If so, we can think about whether removing the scaffolding and reconstructing it when needed is worthwhile. This is a separate issue. If there's a reason to remove it other than simplify the HTML5 parser again, then certainly we can consider it. But that was the only reason Eric cited, so I wanted to check if it's actually the case, in light of WebVTT. I am still curious about the answer. But I'd be happy to discuss other reasons instead. My understanding is that we don't typically leave broken, unused code in trunk unless someone is actively working on it. Having this code around has costs and little benefit: 1) The code needs to be maintained. 2) The code confuses contributors who don't know that it's dead. By contrast, if someone wants to work on this code again, they can just revert the patch that removed it. They might need to do some maintenance work at that point, but that's work that otherwise would have to have been done by someone else. Ha! So the reason for removing the code is simplifying the HTML5 parser, just to undo the simplification once the original writer has the time to come back to it. Seems like well spend time :) Greetings, Dirk As for VTT, I suspect that the VTT parser doesn't need all the complexity that the HTML parser needs. It's doing a much simpler task and likely can be made much simpler by not try to share code with the HTML parser at all. Adam ___ 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] bugs.webkit.org and trac.webkit org down?
On Aug 12, 2012, at 6:26 PM, Florin Malita fmal...@google.com wrote: And down it goes again… It is down for me as well… Dirk PS: Sorry, I always wanted to that :D On Fri, Aug 10, 2012 at 11:14 AM, Levi Weintraub le...@google.com wrote: We're back! On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo pe...@chromium.org wrote: It's been down for the past hour, again. Just a nudge in case it slipped through. Peter On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? br, Ossy Osztrogonac Csaba írta: It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? ___ 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 ___ 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] Kerning not working for SVG font when included in HTML file using @font-face
Thank you very much for reporting the bug Tony. In this case opening a bug report at http://bugs.webkit.org may be better. Greetings, Dirk On Aug 1, 2012, at 9:26 AM, Peter Beverloo pe...@chromium.org wrote: Please use the webkit-h...@lists.webkit.org mailing list for questions such as this one, as webkit-dev is intended as a forum for WebKit developers. In general, if exactly the same code behaves differently in WebKit compared to other browsers, or WebKit's implementation is different from what the specification says, you're always welcome to file a bug on http://bugs.webkit.org/. Thanks, Peter On Wed, Aug 1, 2012 at 5:23 PM, tony tonyii...@gmail.com wrote: Hi, I created a SVG font file and wanted to try kerning between two glyphs (V and G in the attached file). The kerning works when open the SVG in browser but does not work if i include it in HTML styles using @font-face. Please let me know if i am doing something wrong or is it a bug in webkit. PS: The same SVG font file when converted to ttf and the ttf refered to using @font-face in HTML works fine in Firefox14. Thanks Tony ___ 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] Multiple inheritance in the DOM
On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces. However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior.
Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.
Greetings,
Dirk
He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event. That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.
Adam
On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions. That means that Region introduces a form of multiple
inheritance into the DOM. For example, Element implements Region but
Node does not implement Region.
There's a patch up for review that implements Region using C++
multiple inheritance [2]:
- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {
One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.
We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance. For example, there are many subclass of
Event and toJS(Event*) needs to return a wrapper for the appropriate
subtype. To solve the same problem, CSSRule has a m_type member
variable and a bevy of isFoo() functions [3].
A) Should we push back on the folks writing the CSS Regions
specification to avoid using multiple inheritance? As far as I know,
this is the only instance of multiple inheritance in the platform.
Historically, EventTarget used multiple inheritance, but that's been
fixed in DOM4 [4].
B) If CSS Regions continues to require multiple inheritance, should we
build another one-off RTTI replacement to implement toJS(Region*), or
should we improve our bindings to implement this aspect of WebIDL more
completely?
One approach to implementing toJS in a systematic way is to introduce
a base class DOMInterface along these lines:
class DOMInterface {
public:
virtual const AtomicString primaryInterfaceName() = 0;
}
That returns the name of the primary interface (i.e., as defined by
WebIDL [5]). When implementing toJS, we'd then call
primaryInterfaceName to determine which kind of wrapper to use.
One downside of this approach is that it introduces a near-universal
base class along the lines of IUnknown [6] or nsISupports [7]. I
don't think any of us want WebKit to grow an implementation of
XPCOM...
I welcome any thoughts you have on this topic.
Thanks,
Adam
[1] http://dev.w3.org/csswg/css3-regions/
[2] https://bugs.webkit.org/show_bug.cgi?id=91076
[3]
http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
[4] http://www.w3.org/TR/dom/#node
[5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
[6]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
[7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
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] Multiple inheritance in the DOM
On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces. However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance
behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED
soon.
Do you anticipate adding properties or functions that return
interfaces like SVGLocatable?
Here is a Wiki what we plan to do:
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
It might not reflect all changes that we discussed during the SVG WG meeting
today.
Greetings,
Dirk
Adam
He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event. That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.
Adam
On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions. That means that Region introduces a form of multiple
inheritance into the DOM. For example, Element implements Region but
Node does not implement Region.
There's a patch up for review that implements Region using C++
multiple inheritance [2]:
- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {
One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.
We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance. For example, there are many subclass of
Event and toJS(Event*) needs to return a wrapper for the appropriate
subtype. To solve the same problem, CSSRule has a m_type member
variable and a bevy of isFoo() functions [3].
A) Should we push back on the folks writing the CSS Regions
specification to avoid using multiple inheritance? As far as I know,
this is the only instance of multiple inheritance in the platform.
Historically, EventTarget used multiple inheritance, but that's been
fixed in DOM4 [4].
B) If CSS Regions continues to require multiple inheritance, should we
build another one-off RTTI replacement to implement toJS(Region*), or
should we improve our bindings to implement this aspect of WebIDL more
completely?
One approach to implementing toJS in a systematic way is to introduce
a base class DOMInterface along these lines:
class DOMInterface {
public:
virtual const AtomicString primaryInterfaceName() = 0;
}
That returns the name of the primary interface (i.e., as defined by
WebIDL [5]). When implementing toJS, we'd then call
primaryInterfaceName to determine which kind of wrapper to use.
One downside of this approach is that it introduces a near-universal
base class along the lines of IUnknown [6] or nsISupports [7]. I
don't think any of us want WebKit to grow an implementation of
XPCOM...
I welcome any thoughts you have on this topic.
Thanks,
Adam
[1] http://dev.w3.org/csswg/css3-regions/
[2] https://bugs.webkit.org/show_bug.cgi?id=91076
[3]
http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
[4] http://www.w3.org/TR/dom/#node
[5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
[6]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
[7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
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] Delaying Applying CSS Effects
In SVG we have SVGResourcesCache which takes care of that. Greetings, Dirk On Jul 24, 2012, at 3:56 PM, Dean Jackson wrote: On 25/07/2012, at 6:09 AM, Keyar Hood ke...@chromium.org wrote: I am working on https://bugs.webkit.org/show_bug.cgi?id=90405 The problem is that when doing SVG filters in CSS using URL references, if the target SVG filter is after the element that the filter is to be applied to (the filtered element), then the filter will not be applied. Looking at the code, a getElementByID() call is made when looking for the target SVG filter. However, this does not work when the target SVG filter is after the filtered element. I believe this is because the DOM element for the target SVG filter does not exist yet. I am wondering if there is some way to delay resolving these CSS effects until after the DOM has finished loading. Your analysis sounds right. I think we'll have to do exactly that: delay calling buildFilterEffectRenderer until the document has loaded. 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] SVG video chat (2)
That would be great, but please also provide different times. I am not available from 9 to 12 mostly. So I have to say no to all provided times. Before or after that is fine. Greetings, Dirk On Jun 7, 2012, at 9:48 AM, Philip Rogers wrote: Last month we had a video chat with the SVG team in WebKit and it was very well received. If there are other highly-coupled, highly-distributed sub-components of WebKit I would highly recommend setting one of these up. SVG, The last video chat went great and as a group we decided to do it again. If you'd like to join please add your name, availability, and topics you'd like to discuss to the spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On May 31, 2012, at 7:55 PM, Maciej Stachowiak wrote: On May 31, 2012, at 5:51 PM, Jacob Goldstein jac...@adobe.com wrote: I haven't found that to be the case for the tests I have written for each suite, the output from testharness can be as simple as PASS or FAIL, or include additional debug information defined by the test author. That being said, my experience is likely more limited than yours. Peter Linss, who wrote and maintains the W3C testharness, would likely be open to suggestions for improvement if there is anything specific that we want to change. The source is more verbose. The output is uglier and less clear, at least by default. PASS and FAIL is not as good as what our test driver does by default, because you can't as easily tell what passed or failed or why. Our own harness tells you the expression the test evaluated that failed, and what the expected result was, so it's much quicker to debug a failure. I have given my feedback to James Graham before, including showing him how our test harness works. At the time, he was not open to making changes, in part because of details of Opera's internal testing setup and in part because eval is evil. I really would rather not reduce all our DOM tests to the Opera-driven level of source legibility and output quality. I think it is time not to discuss it privately anymore. This is the test suite that is/will be used by the CSS WG. Therefore, if there are reasonable suggestions for improvement, we should discuss it on public mailing lists. webkit-dev is a great start, but since it is used by CSS WG and since all contributors, not just opera contributors, need to use it on the CSS WG test suite, it should be discussed on the CSS WG side. The responsible mailing list should be public-css-testsuite. Let me give you an example. This zip file contains an actual w3c test case, and a webkit-style conversion of the same test: test-example.zip I have deliberately introduced the same failure into both. Which one do you think would be easier to debug? I agree, the output of the WebKit harness seems to be more useful and better for debugging. But I used to use the WebKit testing harness a lot. So my impressions are not independent. Greetings, Dirk Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Test the Web Forward
Hello WebKit community, We want to announce the W3C event Test the Web Forward hosted by Adobe. This hackathon builds off the Move the Web Forward initiative in order to help get developers more involved in contributing to the web platform we all work to define. During this hackathon, attendees will be learning about certain CSS and SVG features that need more tests in order to progress through the standards pipeline. Find more information on the official website http://testthewebforward.org/ Registration will open on June 1st and space is limited, so bookmark the dates (June 15th and 16th at the Adobe San Francisco office) and we hope to see you there! Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit SVG chatroulette
On Apr 26, 2012, at 11:49 AM, Philip Rogers wrote: If you don't work on SVG in WebKit you can stop reading now. WebKit, Is there interest in a 1hr video chat with WebKit people interested in SVG as a followup to the WebKit contributors meeting? A few active SVG contributors weren't able to make the meeting and we have some really cool topics to talk about (SVG2.0, RenderLayer work, etc.) Great idea! Can you set up another table with possible topics? Greetings, Dirk If this sounds interesting to you or you just want to say moin to #ksvg friends, please add your name and availability: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGRVRmJsendBYnB1dFFacE1mdV9PUEE Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores
Different developers will have different priorities. HD image data and async readback both have potential benefits in image quality and nonblocking responsiveness respectively. Here is an example of an application using getImageData which would clearly benefit from HD, but it's not obvious that async would be useful: http://mudcu.be/sketchpad/ This seems to be a use case for SVG and not canvas :) Dirk Here is another where HD helps but benefits of async are unclear, since it does a pixel read-write-modify cycle: http://nerget.com/pressure/pressure.html Tying HD to async may hurt the adoption of both by requiring developers to take two different code change hits when they only care about one. In particular, the async change is likely to be more invasive to code structure. If developers are discouraged, they may end up using neither. Thus, in my opinion, these two enhancements to ImageData should stand and fall on their own merits. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
