Let's consider the following tree. div#host -- SR |-span (pseudo='x-foo') When we have a CSS selector #host:x-foo, it should match the span.
I would like to implement this like shadowPseudoId, since this also breaks shadow boundary.
Created attachment 171601 [details] WIP
This contains a lot of debug-printf... But it succeeds in styling custom pseudo elements.
I don't understand why you're implementing this again? UnknownPseudoElements and shadowPseudoIds are exactly what you need already.
Comment on attachment 171601 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=171601&action=review > Source/WebCore/css/CSSSelector.cpp:395 > + if (name.startsWith("x-")) I could be wrong, but it should be easier to make this work at the attribute-setting time, right?
First I thought I would like to use the shadowPseudoId, but I was afraid that it causes some confusion. But maybe it's OK to use it anyway...
Created attachment 171769 [details] Patch
This patch depends on https://bugs.webkit.org/show_bug.cgi?id=100831, so it won't run until it's landed.
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14692355
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14677391
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/14697180
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/14678390
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/14684376
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/14687379
Comment on attachment 171769 [details] Patch Attachment 171769 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/14561501
Created attachment 172009 [details] Patch
Comment on attachment 172009 [details] Patch The change looks good. In my understanding, we currently allows arbitrary name for pseudos. What is our plan to reject invalid ones?
Comment on attachment 172009 [details] Patch Attachment 172009 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/14686775
Comment on attachment 172009 [details] Patch (cq- for now just in case.)
Comment on attachment 172009 [details] Patch hmm. let's fix build breakage...
(In reply to comment #17) > (From update of attachment 172009 [details]) > The change looks good. > In my understanding, we currently allows arbitrary name for pseudos. What is our plan to reject invalid ones? Yes. I would like to do some refactoring (https://bugs.webkit.org/show_bug.cgi?id=100826) first. Then it should become easy to reject invalid ones. I'll work it in https://bugs.webkit.org/show_bug.cgi?id=100919
Created attachment 172210 [details] Patch
Created attachment 172251 [details] Patch
Comment on attachment 172251 [details] Patch Clearing flags on attachment: 172251 Committed r133428: <http://trac.webkit.org/changeset/133428>
All reviewed patches have been landed. Closing bug.
I'm not sure how, but I think this patch may have caused a 2% increase in memory usage on the Chromium page cyclers. http://build.chromium.org/f/chromium/perf/chromium-rel-win7-webkit/intl2/report.html?rev=165925&graph=ws_single_peak_r&history=100 Regression range: http://trac.webkit.org/log/?verbose=on&rev=133430&stop_rev=133428
Another graph that shows the regression: http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/intl1/report.html?rev=166182&graph=V8.MemoryHeapSampleTotalUsed_0.75&trace=V8.MemoryHeapSampleTotalUsed_0.75&history=150 In theory, the regression could also be from http://trac.webkit.org/changeset/133429/, but I don't see how.
Another regressions that are either from this patch or http://trac.webkit.org/changeset/133429/: http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dom_perf/report.html?rev=166198&graph=CreateNodes&history=100
(In reply to comment #28) > Another regressions that are either from this patch or http://trac.webkit.org/changeset/133429/: > > http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dom_perf/report.html?rev=166198&graph=CreateNodes&history=100 Time for some speculative rollouts? :)
I tried to roll this out, but couldn't due to conflicts with http://trac.webkit.org/changeset/133749. Could someone more familiar with these patches give it a shot?
Hmm... It's hard for me to imagine this causes such memory regression...
(In reply to comment #31) > Hmm... > It's hard for me to imagine this causes such memory regression... Let me try to roll this out anyway. I hope this is innocent, though.
Thanks! If it turns out to be Dimitri's patch, r=me on relanding this. We'll know once the rollout goes in.
Reverted. https://bugs.webkit.org/show_bug.cgi?id=101533 Let's see the page cycler for a while.
This patch seems innocent? http://build.chromium.org/f/chromium/perf/chromium-rel-win7-webkit/intl2/report.html?graph=ws_single_peak_r&history=100&rev=-1
(In reply to comment #35) > This patch seems innocent? Yes. Sorry for the misplaced blame. Thanks for trying the rollout. It must be http://trac.webkit.org/changeset/133429/.