[webkit-dev] Fwd: help building webkit-clutter-1.11.0+20121003
Hello, I am building Webkit-clutter using Mingw on Windows with configure ./configure --prefix=/opt/emo2 --with-gstreamer=1.0 --with-target=win32 --with-port=clutter i installed all the dependencies it prompted.but it is giving error. ./configure: line 17485: syntax error near unexpected token `0.16' ./configure: line 17485: ` PKG_PROG_PKG_CONFIG(0.16)' Any one have idea what is wrong ? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] More C++11 in WebKit2!
Hello, that was not my intention. I was under the (wrong) impression that range-based for existed in VS2010. I'll back that change out. - Anders On Apr 28, 2013, at 1:26 PM, Hausmann Simon simon.hausm...@digia.com wrote: Hi, Just for clarification: This means dropping support for Visual Studio 2010 and requiring 2012 (released about a year ago). Simon Anders Carlsson ander...@apple.com wrote: Hello everyone, just a friendly heads-up that I intend to land https://bugs.webkit.org/show_bug.cgi?id=115259 soon, which makes use of three more C++11 features, namely: - Not requiring a space between right angle brackets in templates. - Range-based for loops - Auto. Looks like the EFL and Qt ports need to start building as C++11! The rest of the ports are fine. Thanks, - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: help building webkit-clutter-1.11.0+20121003
please send complete log error. or do remove the line no.. if it comes under if block in configure script, do remove that block From: Hardik Gohil hardikgohil1...@gmail.com To: webkit-dev@lists.webkit.org Sent: Monday, 29 April 2013 5:33 PM Subject: [webkit-dev] Fwd: help building webkit-clutter-1.11.0+20121003 Hello, I am building Webkit-clutter using Mingw on Windows with configure ./configure --prefix=/opt/emo2 --with-gstreamer=1.0 --with-target=win32 --with-port=clutter i installed all the dependencies it prompted.but it is giving error. ./configure: line 17485: syntax error near unexpected token `0.16' ./configure: line 17485: ` PKG_PROG_PKG_CONFIG(0.16)' Any one have idea what is wrong ? Thanks in advance. ___ 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] obtaining webkit.org address?
I don't think WebKit has a strict policy on this. I would actually prefer that we phase out webkit.org email addresses. I like to be able to determine what someone's affiliation is. Simon On Apr 28, 2013, at 9:10 PM, Glenn Adams gl...@skynav.com wrote: On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote: And if one prefers to use a webkit.org address, like you are doing? A little follow-up: when I got my SVN account and credentials earlier this year as a committer, I expected to be given or at least asked if I wanted a webkit.org address, to which I would have said yes. However, I wasn't asked and the credentials went through with my company address. As my company is basically just me, I would prefer to use a webkit.org address in order to identify better with the community as such. So I'm just now following up on this inquiry about how to get a community address. On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.org wrote: Previously people used to get SVN accounts associated to a @webkit.org alias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] obtaining webkit.org address?
Hi, Stats are totally busted for WebKit because of that so I agree with simon here. Also with webkit.org email you can't make sure you're speaking on behalf of your company or not (work time vs spare time). Thanks. On Mon, Apr 29, 2013 at 2:17 PM, Simon Fraser simon.fra...@apple.com wrote: I don't think WebKit has a strict policy on this. I would actually prefer that we phase out webkit.org email addresses. I like to be able to determine what someone's affiliation is. Simon On Apr 28, 2013, at 9:10 PM, Glenn Adams gl...@skynav.com wrote: On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote: And if one prefers to use a webkit.org address, like you are doing? A little follow-up: when I got my SVN account and credentials earlier this year as a committer, I expected to be given or at least asked if I wanted a webkit.org address, to which I would have said yes. However, I wasn't asked and the credentials went through with my company address. As my company is basically just me, I would prefer to use a webkit.org address in order to identify better with the community as such. So I'm just now following up on this inquiry about how to get a community address. On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.org wrote: Previously people used to get SVN accounts associated to a @webkit.org alias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. 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] obtaining webkit.org address?
What Simon said is correct. We would prefer that contributors use their company affiliated email for committing. However, if there is a need for a webkit.org email (some people don't have access to their work email when not in the office, for example), please email me with your request for an @webkit.org email with the username you would like and where you would like it to be forwarded. A further note is, if you are given a @webkit.org email and have a company affiliation, the company affiliated email should be used for committing, the @webkit.org email is meant for mailing lists. Thanks! Brian On Apr 29, 2013, at 10:17 AM, Simon Fraser simon.fra...@apple.com wrote: I don't think WebKit has a strict policy on this. I would actually prefer that we phase out webkit.org email addresses. I like to be able to determine what someone's affiliation is. Simon On Apr 28, 2013, at 9:10 PM, Glenn Adams gl...@skynav.com wrote: On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote: And if one prefers to use a webkit.org address, like you are doing? A little follow-up: when I got my SVN account and credentials earlier this year as a committer, I expected to be given or at least asked if I wanted a webkit.org address, to which I would have said yes. However, I wasn't asked and the credentials went through with my company address. As my company is basically just me, I would prefer to use a webkit.org address in order to identify better with the community as such. So I'm just now following up on this inquiry about how to get a community address. On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.org wrote: Previously people used to get SVN accounts associated to a @webkit.org alias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. 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] What do we do with various Web component features?
On Apr 27, 2013, at 2:38 PM, Benjamin Poulain benja...@webkit.org wrote: On Fri, Apr 26, 2013 at 9:46 PM, Ryosuke Niwa rn...@webkit.org wrote: There appears to be a lot of Web component related features in WebKit that used to be maintained by Chromium contributors; specifically those related to Shadow DOM and node distributions. What do we do with them? The specification is still under the construction and our implementation is getting outdated day by day. I certainly see the value of the proposed specification, and I would like it to be shipped by WebKit browsers. However, having unmaintained code that is this invasive in WebCore is very harmful in short term. Is anyone stepping up to maintain the code, or should we consider removing them for the time being? All that unmaintained code has a cost we should not have to pay. I am in favor of removing it and bring the code back later when someone decide to support that spec. +1 From what I’ve heard, the Shadow DOM changes have negatively impacted the packability of the DOM code which is unfortunate. I’m all for removing it. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] More C++11 in WebKit2!
On Apr 28, 2013, at 1:00 PM, Geoffrey Garen gga...@apple.com wrote: Hi Mikhail. In continuation of the topic I'd like also to know people's opinion about Pass*Ptr types deprecation: I don't think this is appropriate until the compilers on all our major target platforms support C++11. I believe Windows is currently the primary barrier. Once we have C++11 on all our major target platforms, I think it would great to adopt C++11 idioms throughout the project. I believe that part of our reasoning for deploying C++11 idioms in WebKit2 is that it meets this criterion. I agree. In WebKit2 we have much more freedom to do C++11 experimentation, both due to not having to think about Windows but also due to the fact that WebKit2 is about one fifth the size of WebCore when it comes to number of lines of code. When we come up with successful C++11 design patterns and idioms in WebKit2, we can apply them to WebCore when the time is ready. (One thing I’m playing with in WebKit2 is to stop using PassOwnPtr and just using std::move instead). - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What do we do with various Web component features?
On Fri 2013-04-26, at 9:46 PM, Ryosuke Niwa rn...@webkit.org wrote: There appears to be a lot of Web component related features in WebKit that used to be maintained by Chromium contributors; specifically those related to Shadow DOM and node distributions. What do we do with them? The specification is still under the construction and our implementation is getting outdated day by day. I certainly see the value of the proposed specification, and I would like it to be shipped by WebKit browsers. However, having unmaintained code that is this invasive in WebCore is very harmful in short term. Is anyone stepping up to maintain the code, or should we consider removing them for the time being? I agree that it should be removed from WebKit at this time. The bit-rot has already started to set in. We'll need a new solution for the details and summary elements, as they are currently implemented using this functionality. I believe Antti has expressed interest in working on this. -Andreas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enabling Features through Defaults
Hi WebKit, I am experimenting with how to add an item to defaults, and can't seem to get the incantation quite right. I have been using WebGL as an example. This patch: https://bugs.webkit.org/show_bug.cgi?id=53096 and the terminal command: defaults write com.apple.Safari WebKitWebGLEnabled -bool YES To start, I'm attempting to add a single flag for CSS Exclusions. But after making the changes and copying the above command for WebKitCSSExclusionsEnabled, the read preference always return false. I'm just doing a simple debug build and run-safari —debug. Am I missing something, has the architecture changed? -Bear ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Features through Defaults
WebKit2 prefs have a bit more complexity to their names. For the Safari “Content” page group (normal pages): defaults write com.apple.Safari.ContentPageGroupIdentifier.WebKit2WebGLEnabled -bool YES On Apr 29, 2013, at 10:59 AM, Bear Travis betra...@adobe.com wrote: Hi WebKit, I am experimenting with how to add an item to defaults, and can't seem to get the incantation quite right. I have been using WebGL as an example. This patch: https://bugs.webkit.org/show_bug.cgi?id=53096 and the terminal command: defaults write com.apple.Safari WebKitWebGLEnabled -bool YES To start, I'm attempting to add a single flag for CSS Exclusions. But after making the changes and copying the above command for WebKitCSSExclusionsEnabled, the read preference always return false. I'm just doing a simple debug build and run-safari —debug. Am I missing something, has the architecture changed? -Bear ___ 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 do we do with various Web component features?
I agree that we should remove most of the Shadow DOM related code (the portions supporting distribution especially). It is invasive, has significant architectural issues (including use of a confusing mutating iterator) and forces generic code many places where it would not be needed otherwise. It is essentially blocking us from improving DOM data structures. The code has been developed organically in parallel with the spec and I feel that a future new implementation could be cleaner. antti On Sat, Apr 27, 2013 at 2:38 PM, Benjamin Poulain benja...@webkit.orgwrote: On Fri, Apr 26, 2013 at 9:46 PM, Ryosuke Niwa rn...@webkit.org wrote: There appears to be a lot of Web component related features in WebKit that used to be maintained by Chromium contributors; specifically those related to Shadow DOM and node distributions. What do we do with them? The specification is still under the construction and our implementation is getting outdated day by day. I certainly see the value of the proposed specification, and I would like it to be shipped by WebKit browsers. However, having unmaintained code that is this invasive in WebCore is very harmful in short term. Is anyone stepping up to maintain the code, or should we consider removing them for the time being? All that unmaintained code has a cost we should not have to pay. I am in favor of removing it and bring the code back later when someone decide to support that spec. 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] Enabling Features through Defaults
On Apr 29, 2013, at 11:13 AM, Timothy Horton timothy_hor...@apple.com wrote: WebKit2 prefs have a bit more complexity to their names. For the Safari “Content” page group (normal pages): defaults write com.apple.Safari.ContentPageGroupIdentifier.WebKit2WebGLEnabled -bool YES Err, I botched that. defaults write com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2WebGLEnabled -bool YES On Apr 29, 2013, at 10:59 AM, Bear Travis betra...@adobe.com wrote: Hi WebKit, I am experimenting with how to add an item to defaults, and can't seem to get the incantation quite right. I have been using WebGL as an example. This patch: https://bugs.webkit.org/show_bug.cgi?id=53096 and the terminal command: defaults write com.apple.Safari WebKitWebGLEnabled -bool YES To start, I'm attempting to add a single flag for CSS Exclusions. But after making the changes and copying the above command for WebKitCSSExclusionsEnabled, the read preference always return false. I'm just doing a simple debug build and run-safari —debug. Am I missing something, has the architecture changed? -Bear ___ 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] obtaining webkit.org address?
It seems like you could get nearly both things if you just had people list both their @webkit.org and @company.com addresses (or at least a company affiliation, if not an actual address) in committers.py, right? -- Dirk On Mon, Apr 29, 2013 at 10:26 AM, Brian Weinstein bweinst...@apple.comwrote: What Simon said is correct. We would prefer that contributors use their company affiliated email for committing. However, if there is a need for a webkit.org email (some people don't have access to their work email when not in the office, for example), please email me with your request for an @webkit.org email with the username you would like and where you would like it to be forwarded. A further note is, if you are given a @webkit.org email and have a company affiliation, the company affiliated email should be used for committing, the @webkit.org email is meant for mailing lists. Thanks! Brian On Apr 29, 2013, at 10:17 AM, Simon Fraser simon.fra...@apple.com wrote: I don't think WebKit has a strict policy on this. I would actually prefer that we phase out webkit.org email addresses. I like to be able to determine what someone's affiliation is. Simon On Apr 28, 2013, at 9:10 PM, Glenn Adams gl...@skynav.com wrote: On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote: And if one prefers to use a webkit.org address, like you are doing? A little follow-up: when I got my SVN account and credentials earlier this year as a committer, I expected to be given or at least asked if I wanted a webkit.org address, to which I would have said yes. However, I wasn't asked and the credentials went through with my company address. As my company is basically just me, I would prefer to use a webkit.org address in order to identify better with the community as such. So I'm just now following up on this inquiry about how to get a community address. On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.org wrote: Previously people used to get SVN accounts associated to a @webkit.org alias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] More C++11 in WebKit2!
On Apr 29, 2013, at 10:33 AM, Anders Carlsson ander...@apple.com wrote:
On Apr 28, 2013, at 1:00 PM, Geoffrey Garen gga...@apple.com wrote:
Hi Mikhail.
In continuation of the topic I'd like also to know people's opinion about
Pass*Ptr types deprecation:
I don't think this is appropriate until the compilers on all our major
target platforms support C++11. I believe Windows is currently the primary
barrier.
Once we have C++11 on all our major target platforms, I think it would great
to adopt C++11 idioms throughout the project.
I believe that part of our reasoning for deploying C++11 idioms in WebKit2
is that it meets this criterion.
I agree.
In WebKit2 we have much more freedom to do C++11 experimentation, both due to
not having to think about Windows but also due to the fact that WebKit2 is
about one fifth the size of WebCore when it comes to number of lines of code.
When we come up with successful C++11 design patterns and idioms in WebKit2,
we can apply them to WebCore when the time is ready. (One thing I’m playing
with in WebKit2 is to stop using PassOwnPtr and just using std::move instead).
I feel like consumeValue(std::move(localTemporary)) is less understandable than
consumeValue(localTemporary.release()). But I guess that's just surface syntax.
Here's a few things I am interested in about the effects effect of this.
I think a lot of the helpfulness of the Pass* types is in the following
scenarios:
== Scenario A ==
PassOwnPtrT valueProducer() { ... }
void valueConsumer(const PassOwnPtrT) { ... }
void someOtherFunc()
{
valueConsumer(valueProducer());
}
-- Is this still doable with std::move / rvalues? If so what does it look like?
-- Will it be possible to have typechecking fail if you try to give
valueConsumer a regular smart pointer instead of a movable one?
== Scenario B ==
PassOwnPtrT valueProducer() { ... }
void valueConsumer(const PassOwnPtrT) { ... }
void someOtherFunc()
{
OwnPtrT temporaryLocal = valueProducer();
temporaryLocal-someSideEffect();
valueConsumer(temporaryLocal.release());
}
-- Is this still doable with std::move / rvalues? If so what does it look like?
-- Will it be possible to have typechecking fail if you try to give
valueConsumer a regular smart pointer instead of a movable one, i.e. you
forget the release/move?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Crash in JSC while loading gap.com on 1.6.3
Hi, I am using the 1.6.3 release (an old one) for my development and get a crash while loading gap.com and youtube.com/tv.(Both related to JS function apply having an incredibly large number of arguments) My processor is ARM 11 based and the smaps of the crash point me to the location where the JIT has dumped the bytecode for excuting various JS functionality. From the looks of it, the issue I face is very similar to this one https://bugs.webkit.org/show_bug.cgi?id=108991 however, since I am on an old version it is difficult for me to fix it in my JSC. Can anyone help me out over here as to where should I patch my JSC source code Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Crash in JSC while loading gap.com on 1.6.3
Three suggestions: 1) If you find a bug in some part of WebKit (JSC or elsewhere), you should file it on bugs.webkit.org. webkit-dev isn't really the right venue for bug reports. 2) You should be more specific - in the bug report that you will file and not in this thread - about what port you're using. Version 1.6.3 is ambiguous, to me. There are a number of ports that support ARM, and it's not clear to me which you're using. Hence, I don't even know how old 1.6.3 is, because I'm not familiar with the versioning that the different ports do. 3) Your best bet is probably to update to a newer version, and see if the bug reproduces. -Filip On Apr 29, 2013, at 10:15 PM, developer World world2deve...@gmail.com wrote: Hi, I am using the 1.6.3 release (an old one) for my development and get a crash while loading gap.com and youtube.com/tv.(Both related to JS function apply having an incredibly large number of arguments) My processor is ARM 11 based and the smaps of the crash point me to the location where the JIT has dumped the bytecode for excuting various JS functionality. From the looks of it, the issue I face is very similar to this one https://bugs.webkit.org/show_bug.cgi?id=108991 however, since I am on an old version it is difficult for me to fix it in my JSC. Can anyone help me out over here as to where should I patch my JSC source code Thanks ___ 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] Fwd: Feature removal: CSS variables
Hi Karen, Have you decided whether you can maintain the CSS variables in WebKit or not? As far as I checked, I didn't find any patches posted or committed by you on Bugzilla or on Trac. We have a contributor's meeting coming up in Thursday, and I would like to know whether we can proceed to remove the feature from the trunk for the time being. - R. Niwa On Sun, Apr 7, 2013 at 7:30 PM, Karen Shaeffer shaef...@neuralscape.comwrote: On Sun, Apr 07, 2013 at 05:40:33PM -0700, Ryosuke Niwa wrote: On Sun, Apr 7, 2013 at 4:17 PM, Jon Rimmer jon.rim...@gmail.com wrote: As well as being in Chrome, custom property support is also being developed by Mozilla[4]. It is an actively edited W3C spec that is expected to reach Last Call status soon[5]. Given that situation, removing it from WebKit seems a very negative step. If it is removed and remains unimplemented in Safari and other WebKit browsers, then they will continue to fall behind competing layout engines. If it is removed now and must be resurrected at a later date, then the total cost is likely to be greater than making the effort to turn it on and take ownership of it *now*. I definitely see a value in keeping the feature. However, there is a practical problem of someone having to maintain the code. Now that all contributors who have previously worked on this feature has left to work on Blink, I don't see who can be maintaining this code in WebKit. Are you volunteering to maintain the code? If not, then who is? Not having this feature will be unfortunate and we might need to add it back in the future, but that's much better than leaving unmaintained code in our codebase. - R. Niwa Hi Niwa, I am willing to consider if it is practical for me to volunteer to maintain CSS variables for the webkit project. I'll need a week to make an informed decision, because I already have a full plate. But I am very interested in webkit, and this seems like a good time to step up to help the team. CSS variables does appear to be a worthy feature to maintain. If the team is willing to let this sit for a week, then that'll give me time to consider the issue properly. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What do we do with various Web component features?
On Mon, Apr 29, 2013 at 10:30 AM, Anders Carlsson ander...@apple.comwrote: ... +1 From what I’ve heard, the Shadow DOM changes have negatively impacted the packability of the DOM code which is unfortunate. I’m all for removing it. Could you elaborate on what you mean by the packability of the DOM code? - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
