Bug 86146 took care of @supports, but the JS api was implemented in Opera and FIrefox as well. It was previously supportsCSS() but has now shifted to CSS.supports(). http://dev.w3.org/csswg/css3-conditional/#the-csssupportsrule-interface
What went into Firefox? I can't see either supportsCSS or CSS.supports in my nightly. Are FF and Opera changing names soon or should a prefix be used here (boo)? How happy is everyone with the new name?
It's pretty early to commit to this Paul. I don't sense the CSS WG has concluded its thinking; furthermore, I wonder if this should be handled by the normal prefixing rules, i.e., as WebkitCSS, until the WG has reached a consensus about unprefixing.
(In reply to comment #2) > It's pretty early to commit to this Paul. I don't sense the CSS WG has concluded its thinking; furthermore, I wonder if this should be handled by the normal prefixing rules, i.e., as WebkitCSS, until the WG has reached a consensus about unprefixing. I disagree. Nobody's brought up anything further on the matter since we put it into the spec; the only thing that's been delaying Last Call is our issues around the handling syntax errors in @supports. Once we hit Last Call (which will happen next week at TPAC), we'll only be a few weeks to CR, which is a guaranteed "unprefix" event. Implementing it a month early, when it's not going to hit public before CR, and when everyone else is unprefixing, is fine. So, Pablo, do it without a prefix.
Created attachment 171936 [details] Patch
Comment on attachment 171936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171936&action=review window.CSS is a glorified namespace so far, i'm not sure if there's a better way right now to handle, bindings-wise, what's effectively a bunch of static methods. Also, is it defined in any spec yet (Tab?). > Source/WebCore/css/DOMWindowCSS.idl:32 > +[ > + InterfaceName=CSS > +] interface DOMWindowCSS { Should this one be conditional on CSS3_CONDITIONAL_RULES for now? > Source/WebCore/page/DOMWindow.h:271 > + DOMWindowCSS* cSS(); The funky casing is due to the CodeGenerator uses WK_lcfirst for the method call, should i add an exception there or is this fine?
Comment on attachment 171936 [details] Patch Attachment 171936 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/14681075
Comment on attachment 171936 [details] Patch Attachment 171936 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/14663671
Comment on attachment 171936 [details] Patch Attachment 171936 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/14670623
Comment on attachment 171936 [details] Patch Attachment 171936 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/14678669
(In reply to comment #5) > (From update of attachment 171936 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=171936&action=review > > window.CSS is a glorified namespace so far, i'm not sure if there's a better way right now to handle, bindings-wise, what's effectively a bunch of static methods. Also, is it defined in any spec yet (Tab?). It's in the obvious spec, in the obvious place. ^_^ http://dev.w3.org/csswg/css3-conditional/#the-css-interface > > Source/WebCore/css/DOMWindowCSS.idl:32 > > +[ > > + InterfaceName=CSS > > +] interface DOMWindowCSS { > > Should this one be conditional on CSS3_CONDITIONAL_RULES for now? Probably, yeah. > > Source/WebCore/page/DOMWindow.h:271 > > + DOMWindowCSS* cSS(); > > The funky casing is due to the CodeGenerator uses WK_lcfirst for the method call, should i add an exception there or is this fine? I suspect you'll want an exception there, just because it reads so badly.
Created attachment 172164 [details] Patch
Created attachment 184091 [details] Patch Rebased.
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16065210
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/16037899
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16067096
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16033951
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16036915
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/16035952
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16063332
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/16067146
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/16040976
Comment on attachment 184091 [details] Patch Attachment 184091 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16065316
Created attachment 184268 [details] Patch
Comment on attachment 184268 [details] Patch Attachment 184268 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16083341
Comment on attachment 184268 [details] Patch Attachment 184268 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16083340
Created attachment 184354 [details] Patch
Comment on attachment 184354 [details] Patch r=me with gtk build fixed
(In reply to comment #27) > (From update of attachment 184354 [details]) > r=me with gtk build fixed Thank you! I've checked the build failure and I'll append the changes needed for the GTK build to pass. I'd still like to request that you upload the updated reviewed patch again so the EWS can confirm the fix is indeed OK if it's not too much of a hassle for you.
Created attachment 186587 [details] GTK build fix Should fix the GTK build failure.
(In reply to comment #28) > (In reply to comment #27) > > (From update of attachment 184354 [details] [details]) > > r=me with gtk build fixed > > Thank you! > > I've checked the build failure and I'll append the changes needed for the GTK build to pass. I'd still like to request that you upload the updated reviewed patch again so the EWS can confirm the fix is indeed OK if it's not too much of a hassle for you. Oh, cool! I'll post a new patch, thanks!
Created attachment 186664 [details] Patch for landing
Green all around :-)
Comment on attachment 186664 [details] Patch for landing Rejecting attachment 186664 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=gce-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 186664, '--port=chromium-xvfb']" exit_code: 2 cwd: /mnt/git/webkit-commit-queue Last 500 characters of output: s). patching file LayoutTests/platform/qt/TestExpectations patching file LayoutTests/platform/win/TestExpectations Hunk #1 succeeded at 2409 (offset -3 lines). patching file LayoutTests/platform/wincairo/TestExpectations Hunk #1 succeeded at 2908 (offset -2 lines). patching file LayoutTests/platform/wk2/TestExpectations Hunk #1 succeeded at 329 (offset -13 lines). Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /mnt/git/webkit-commit-queue Full output: http://queues.webkit.org/results/16522305
Created attachment 187902 [details] Patch for landing Rebased.
Comment on attachment 187902 [details] Patch for landing Clearing flags on attachment: 187902 Committed r142739: <http://trac.webkit.org/changeset/142739>