* SUMMARY Should show dynamic specificity values of :matches(...) against the current selected element. * TEST <style> :matches(div, .foo) { color: blue; } </style> <div>Specificity for this is (0, 0, 1)</div> <p class="foo">Specificity for this is (0, 1, 0)</p> * STEPS TO REPRODUCE 1. Inspect the <div> in the test case. => specificity of :matches should be (0, 0, 1) 2. Inspect the <p> in the test case => specificity of :matches should be (0, 1, 0) * NOTES - It might also be nice to show a * or some explanatory text (e.g. "(0, 0, 1)*") to clarify that the specificity is dynamic and may change for different elements.
<rdar://problem/19526046>
Created attachment 244940 [details] [PATCH] Proposed Fix
Attachment 244940 [details] did not pass style-queue: ERROR: Source/WebCore/inspector/InspectorStyleSheet.h:241: The parameter name "element" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/WebCore/inspector/InspectorStyleSheet.h:242: The parameter name "element" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 2 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 244940 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=244940&action=review > LayoutTests/ChangeLog:9 > + * inspector/css/selector-dynamic-specificity.html: Added. Gosh, those Inspector tests aren't easy to write. > Source/WebCore/inspector/InspectorCSSAgent.h:155 > + RefPtr<Inspector::Protocol::CSS::CSSRule> buildObjectForRule(StyleRule*, StyleResolver&, Element*); Shouldn't element be const? > Source/WebCore/inspector/InspectorStyleSheet.cpp:1010 > + selectorChecker.match(&selector, element, context, specificity); It would be good to get the result and ASSERT it is true. The specificity is nonsense if matching fails.
Comment on attachment 244940 [details] [PATCH] Proposed Fix Attachment 244940 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5094626008498176 New failing tests: inspector/css/selector-specificity.html
Created attachment 244945 [details] Archive of layout-test-results from ews104 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
> > Source/WebCore/inspector/InspectorStyleSheet.cpp:1010 > > + selectorChecker.match(&selector, element, context, specificity); > > It would be good to get the result and ASSERT it is true. > The specificity is nonsense if matching fails. Oh, darn, this is what caused the existing test to fail. Maybe we should keep the old static calculation in if a selector is not-dynamic and doesn't match. That way at least we can know the specificity.
(In reply to comment #7) > > > Source/WebCore/inspector/InspectorStyleSheet.cpp:1010 > > > + selectorChecker.match(&selector, element, context, specificity); > > > > It would be good to get the result and ASSERT it is true. > > The specificity is nonsense if matching fails. > > Oh, darn, this is what caused the existing test to fail. > > Maybe we should keep the old static calculation in if a selector is > not-dynamic and doesn't match. That way at least we can know the specificity. Why would you have the selector if it does not match the element?
If a CSS Rule matches the current selected element, we show that rule in the sidebar. We calculate the specificity for each selector in that rule, some may match the element, some may not. Given this test: <style> .foo, .bar { color: green; } </style> <div class="foo">Inspect Me</div> Inspecting .foo, we would expect to show the specificity for both ".foo" and ".bar" in the sidebar, despite only ".foo" matching.
> > Source/WebCore/inspector/InspectorCSSAgent.h:155 > > + RefPtr<Inspector::Protocol::CSS::CSSRule> buildObjectForRule(StyleRule*, StyleResolver&, Element*); > > Shouldn't element be const? Unfortunately, eventually it has to pass down to SelectorChecker::match which takes a non-const Element. Maybe that could be made const, I didn't check.
Created attachment 245019 [details] [PATCH] Proposed Fix
Created attachment 245020 [details] [IMAGE] Tooltip - Dynamic Specificity matching current element
Created attachment 245021 [details] [IMAGE] Tooltip - Dynamic Specificity matching parent element (inherited)
Created attachment 245023 [details] [IMAGE] Tooltip - Dynamic Specificity not matching current element (no value)
Comment on attachment 245019 [details] [PATCH] Proposed Fix Clearing flags on attachment: 245019 Committed r178767: <http://trac.webkit.org/changeset/178767>
All reviewed patches have been landed. Closing bug.
The new test appears to be horrible slow on some bots, any insight why? http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=inspector%2Fcss%2Fselector-dynamic-specificity.html Strangely, of all Mac bots only Yosemite Debug WK2 is affected.