Re: [webkit-dev] WebGL on Windows
Hi. By the way = is there any roadmap to have ACCELERATED_COMPOSITING available for WinCairo ? -- View this message in context: http://mac-os-forge.2317878.n4.nabble.com/WebGL-on-Windows-tp224559p230651.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
Hi, As Zoltan said this feature was introduced for Qt port. But now EFL, GTK and Nix use fastmalloc instead of system malloc too. It was fine and used for some use-cases in those days. To make a decision if the fastmalloc or the system malloc is better, we need some measurements. I made a quick test on EFL and Nix with SunSpider and with the Methanol test suite and haven't seen any significant performance differences between fastmalloc and system malloc on my desktop: Ubuntu 12.04 (x86_64). I haven't checked the memory consumption, it would need more preparation. Keeping the old TCMalloc and the custom allocator framework isn't blocker for us (University of Szeged), so we don't have objection against removing it from trunk. If nodbody is interested in maintaining the framework, it can be removed. If the final conclusion would be dropping TCMalloc, we willingly help in this clean-up. Ossy Zoltan Horvath írta: I used to work on memory related topics, while I was working on the University of Szeged. Based on a 2.5-year-old measurement (http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on the Qt-port, the page loading on the Methanol test suite was 5% faster (avg) with TCmalloc than the default system allocator on Linux. The performance results of the SunSpider suite was similar for both allocators. The memory consumption was always lower with the default os allocator. I guess the new allocator only has iOS support. I'm fine with removing TCmalloc, although this direction might raises further questions, like removing the custom allocation framework also. Feel free to cc me on bugs, I can help by contributing some patches. On Mon, Sep 30, 2013 at 2:48 PM, Geoffrey Garen gga...@apple.com I'm planning to remove our years-out-of-date port of TCMalloc, and replace it with something that takes maximum advantage of Mac and iOS virtual memory, threading, and security APIs. I've heard that TCMalloc has caused some problems for non-Mac, non-iOS ports in the past. So, if you maintain a port, this change might make things simpler for you. Are there any ports whose built-in malloc implementations are slow enough that they can't get by without TCMalloc? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Qt WebKit removed from upstream
Hello WebKit As everybody who followed the discussion in the Changes in QtWebKit development thread or recent commits to subversion knows, the Qt port was removed from WebKit trunk on Wednesday this week, From Digia we had a vague plan of trying to cut down drastically on the maintenance burden of our port, but without any clear cut goals of what we could use the port for, except it could very likely be useful to our existing users and customers. After the announcement of our plan, a lot of scepticism was raised on webkit- dev about whether it made sense for WebKit. Since Digia had announced that we would focus on the Chromium based Qt WebEngine, many seemed to feel that we would not be able to contribute enough to the WebKit project to justify the cost to everyone else of keeping the Qt port upstream. Based on the feedback from the community we decided to remove the port, instead of fighting repeated conflicts. We have had a great time working with the WebKit project over the course of the past 7+ years. There have been many conflicts but the end result has always been positive, and we would not want to be a burden for the project. With that in mind we say farewell to upstream. We will still be using WebKit, and shipping with a brand new branch in Qt 5.2, and we will be active in the project where it makes sense. Feel free to reach out to us using the usual channels. Thanks for having us The Digia Qt WebKit Team. Allan Sandfeld Jensen Michael Bruning Andras Becsi Simon Hausmann Jocelyn Turcotte Pierre Rossi Zeno Albisser -- Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Qt WebKit removed from upstream
Hello Allan, It's been a great run! QtWebKit was a trailblazer for some of the creative uses WebKit has found over the years. I'm sure the WebKit GTK+ developers will join me in saying thanks for helping open up the WebKit Open Source project, and I look forward to a time when the paths of the various WebKit ports may meet again. Regards, Alp Toker and the Nuanti team On 04/10/2013 14:14, Allan Sandfeld Jensen wrote: Hello WebKit As everybody who followed the discussion in the Changes in QtWebKit development thread or recent commits to subversion knows, the Qt port was removed from WebKit trunk on Wednesday this week, From Digia we had a vague plan of trying to cut down drastically on the maintenance burden of our port, but without any clear cut goals of what we could use the port for, except it could very likely be useful to our existing users and customers. After the announcement of our plan, a lot of scepticism was raised on webkit- dev about whether it made sense for WebKit. Since Digia had announced that we would focus on the Chromium based Qt WebEngine, many seemed to feel that we would not be able to contribute enough to the WebKit project to justify the cost to everyone else of keeping the Qt port upstream. Based on the feedback from the community we decided to remove the port, instead of fighting repeated conflicts. We have had a great time working with the WebKit project over the course of the past 7+ years. There have been many conflicts but the end result has always been positive, and we would not want to be a burden for the project. With that in mind we say farewell to upstream. We will still be using WebKit, and shipping with a brand new branch in Qt 5.2, and we will be active in the project where it makes sense. Feel free to reach out to us using the usual channels. Thanks for having us The Digia Qt WebKit Team. Allan Sandfeld Jensen Michael Bruning Andras Becsi Simon Hausmann Jocelyn Turcotte Pierre Rossi Zeno Albisser -- Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- http://www.nuanti.com the browser experts ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problem authenticating to svn
Em Qui, 2013-10-03 às 20:44 -0300, Gustavo Noronha Silva escreveu: I'm having trouble committing a patch. I can login to trac and to the buildbot, but svn doesn't let me in. I am using git-svn, I'm downloading the nightly tarball to try with svn itself just in case. My username is k...@webkit.org, can anyone take a peek at the server to see if there's anything wrong? Yeah, same problem with subversion itself. -- 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] Announcement: CSS3_TEXT_DECORATION flag
Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag
Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ 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] Announcement: CSS3_TEXT_DECORATION flag
On Fri, Oct 4, 2013 at 11:03 AM, Timothy Hatcher timo...@apple.com wrote: Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. Isn't the new inspector supposed to be used by other ports as well? If so, using -webkit-text-decoration-color in the inspector code requires all such ports enabling the build flag. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag
Or better yet, enable it for all ports on ToT. -Sam On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote: Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ 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] Announcement: CSS3_TEXT_DECORATION flag
All (?wincairo I'm not sure?) ports on trunk use the new Inspector, and the old one is being removed: https://bugs.webkit.org/show_bug.cgi?id=122295 On Fri, Oct 4, 2013 at 2:24 PM, Sam Weinig wei...@apple.com wrote: Or better yet, enable it for all ports on ToT. -Sam On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote: Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag
Yes, WinCairo uses the new inspector. On Oct 4, 2013, at 11:45 AM, Antonio Gomes toniki...@webkit.org wrote: All (?wincairo I'm not sure?) ports on trunk use the new Inspector, and the old one is being removed: https://bugs.webkit.org/show_bug.cgi?id=122295 On Fri, Oct 4, 2013 at 2:24 PM, Sam Weinig wei...@apple.com wrote: Or better yet, enable it for all ports on ToT. -Sam On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote: Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag
Yeah, as we agreed at the contributor’s meeting, if we think a feature is ready for experimentation, and we think it will eventually be enabled (e.g. there is a stable-ish spec), then we turn it on for nightly builds. I assume that this doesn’t break any existing decoration code? Dean On 5 Oct 2013, at 4:24 am, Sam Weinig wei...@apple.com wrote: Or better yet, enable it for all ports on ToT. -Sam On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote: Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? I have a legitimate use for -webkit-text-decoration-color that would allow me to eliminate a hack in the Inspector. — Timothy Hatcher On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote: Hello, all! Between the current and previous versions of the CSS3 Text spec, the text decoration section was split out into its own spec [1] [2] [3]. Because of this shift, I’m going to be creating a new compile-time flag: CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in [4]. For those who wish to follow progress, the feature bug is at [5]. The first thing I am working on is the text-decoration-skip: ink property [6]. I will also be migrating existing text-decorations code from behind the existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag. Thanks, Myles C. Maxfield [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/ [2] http://www.w3.org/TR/css3-text/ [3] http://www.w3.org/TR/css-text-decor-3/ [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html [5] https://bugs.webkit.org/show_bug.cgi?id=58491 [6] https://bugs.webkit.org/show_bug.cgi?id=121806 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Dean ___ 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 Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote: On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Does this imply that you'll remove the prefixes before shipping the features in a production release? Adam ___ 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 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote: On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote: On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Does this imply that you'll remove the prefixes before shipping the features in a production release? I can’t speak for anyone other than the Apple port, and even there I’m definitely not the official word on the topic, but I don’t think that is implied. It’s likely going to depend on perceived stability of the feature, testing, community feedback, etc. The important thing is that our goal is to get to the unprefixed stable form as soon as possible. Also, our prefixing/unprefixing rules are not set in stone. I think the community will evaluate them case by case. Dean ___ 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 Fri, Oct 4, 2013 at 1:37 PM, Dean Jackson d...@apple.com wrote: On 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote: On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote: On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote: Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. I think that's what Mozilla and Google are doing but I don't think we necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. We decided on a slightly different approach, which is to prefix things but enable them by default in nightly builds. That way a port must still decide at their shipping time whether or not to enable the feature. In the Moz + Google case, the experimental form is exposed unprefixed to a small number of users on the Web. In our case, the experimental form is exposed prefixed. We concluded that we’ve changed things enough times while prefixed that it was worth the extra “this is experimental and may change” notice. Does this imply that you'll remove the prefixes before shipping the features in a production release? I can’t speak for anyone other than the Apple port, and even there I’m definitely not the official word on the topic, but I don’t think that is implied. It’s likely going to depend on perceived stability of the feature, testing, community feedback, etc. The important thing is that our goal is to get to the unprefixed stable form as soon as possible. Also, our prefixing/unprefixing rules are not set in stone. I think the community will evaluate them case by case. I would encourage you (and others) not to ship new vendor-prefixed APIs in production releases. If the feature isn't stable enough to ship without a prefix, it's also harmful to the web ecosystem to ship with a vendor prefix. Adam ___ 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 5 Oct 2013, at 6:45 am, Adam Barth aba...@webkit.org wrote: Also, our prefixing/unprefixing rules are not set in stone. I think the community will evaluate them case by case. I would encourage you (and others) not to ship new vendor-prefixed APIs in production releases. If the feature isn't stable enough to ship without a prefix, it's also harmful to the web ecosystem to ship with a vendor prefix. We’re well aware of the risks and benefits. This ain’t our first time at the rodeo. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: Use ICU in WebKit code
Hi folks. A while back the WebKit project made use of ICU directly. There were some port maintainers who instead wanted to make WebKit work without ICU. At the time, the strategy we pursued was to make a Unicode layer in WTF that layered on top of ICU. We then created multiple implementations of that layer on top of other back ends. But this Unicode layer is simply an awkward renamed subset of ICU. I find it inconvenient when doing work that requires ICU features and it has held back my work in the past. At this point we are down to only two back ends: The one for ICU, and one that is implemented on top of Windows functions, UnicodeWchar.h/cpp. I believe UnicodeWchar is currently used only by the WinCE port. A number of the UnicodeWchar implementations are not complete. For example, the toLower function does not handle the “ß” character. I suggest we remove the Unicode.h abstraction and use ICU directly. I suggest we continue to use the ICU C API, by the way, not the C++ API. For the WinCE port, I suggest we do one of these two things: A) Change the port to require the ICU library. B) Implement a subset of ICU that is enough to compile WebKit, using implementations quite like the ones in UnicodeW.h/cpp today, but using the ICU function names and constants, rathe than an abstraction layer invented for WTF. Thus, code in WebKit can make use of ICU directly in a way that’s easier to understand. Any port that wants to work without ICU can implement an ICU subset compatibility layer in a way that does not require changes to the WebKit code. I am not in a good position to test this ICU subset compatibility layer, but I think it would be a quick easy job to refactor UnicodeWchar.h/cpp into that form. 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. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
