hi @pfa...@chromium.org since you are on the devtools part of this change, could you review it?
please let me know if you want me to address anything
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
simple_selector->SimpleSelectorSpecificityTuple();This doesn't do a breakdown of nesting selectors? Any :is() would regarded a single unit?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This doesn't do a breakdown of nesting selectors? Any :is() would regarded a single unit?
Gosh yes, `:is()` showed up as a single component with the max argument specificity.
Refactored the component builder to recurse into specificity-bearing selector lists, and tested on the devtools cl
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Compute per-simple-selector specificity contributions in Blink and attach them to CSS.Specificity so DevTools can render an accurate breakdown without parsing selectors client-side.What's the advantage of doing this in the backend if we have to compute the components manually?
// Returns specificity components for this single simple selector.Aren't these the same?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Compute per-simple-selector specificity contributions in Blink and attach them to CSS.Specificity so DevTools can render an accurate breakdown without parsing selectors client-side.What's the advantage of doing this in the backend if we have to compute the components manually?
Per your and Bramus's feedback on the DevTools CL (crrev.com/c/7645008, PS3), parsing selectors in the frontend was "fragile and not future friendly" thats why i did the CL.
// Returns specificity components for this single simple selector.Aren't these the same?
They are not, `SpecificityTuple()` walks `NextSimpleSelector()` and returns the aggregated total for the whole complex selector, while `SimpleSelectorSpecificityTuple()` only returns this one simple selector's contribution (via `SpecificityForOneSelector()`). DevTools needs the per-simple-selector breakdown to render the per-component tooltip.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Compute per-simple-selector specificity contributions in Blink and attach them to CSS.Specificity so DevTools can render an accurate breakdown without parsing selectors client-side.Helmut JanuschkaWhat's the advantage of doing this in the backend if we have to compute the components manually?
Per your and Bramus's feedback on the DevTools CL (crrev.com/c/7645008, PS3), parsing selectors in the frontend was "fragile and not future friendly" thats why i did the CL.
True, I'm concernd with the manual work required. Any chance we can reuse the implementation from elsewhere? If we're recomputing the data in the inspector, we're not really improving fragility.
// Returns specificity components for this single simple selector.Helmut JanuschkaAren't these the same?
They are not, `SpecificityTuple()` walks `NextSimpleSelector()` and returns the aggregated total for the whole complex selector, while `SimpleSelectorSpecificityTuple()` only returns this one simple selector's contribution (via `SpecificityForOneSelector()`). DevTools needs the per-simple-selector breakdown to render the per-component tooltip.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Compute per-simple-selector specificity contributions in Blink and attach them to CSS.Specificity so DevTools can render an accurate breakdown without parsing selectors client-side.Helmut JanuschkaWhat's the advantage of doing this in the backend if we have to compute the components manually?
Philip PfaffePer your and Bramus's feedback on the DevTools CL (crrev.com/c/7645008, PS3), parsing selectors in the frontend was "fragile and not future friendly" thats why i did the CL.
True, I'm concernd with the manual work required. Any chance we can reuse the implementation from elsewhere? If we're recomputing the data in the inspector, we're not really improving fragility.
PTAL current PS, think i found a way that does not duplicate code, and also not make the change to brutal!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Compute per-simple-selector specificity contributions in Blink and attach them to CSS.Specificity so DevTools can render an accurate breakdown without parsing selectors client-side.Helmut JanuschkaWhat's the advantage of doing this in the backend if we have to compute the components manually?
Philip PfaffePer your and Bramus's feedback on the DevTools CL (crrev.com/c/7645008, PS3), parsing selectors in the frontend was "fragile and not future friendly" thats why i did the CL.
Helmut JanuschkaTrue, I'm concernd with the manual work required. Any chance we can reuse the implementation from elsewhere? If we're recomputing the data in the inspector, we're not really improving fragility.
PTAL current PS, think i found a way that does not duplicate code, and also not make the change to brutal!
much nicer, thanks!
current_compound.clear();This is my personal taste, but I find using a container after move risky (the code is correct currently, but future changes can easily introduce bugs). Can we write this with out use after moving?
std::reverse(compounds.begin(), compounds.end());use base::Reversed instead
for (const CSSSelector* simple_selector : compound) {do we also need to reverse compound?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This is my personal taste, but I find using a container after move risky (the code is correct currently, but future changes can easily introduce bugs). Can we write this with out use after moving?
Done
std::reverse(compounds.begin(), compounds.end());Helmut Januschkause base::Reversed instead
Done
do we also need to reverse compound?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
for (const CSSSelector* simple_selector : compound) {Helmut Januschkado we also need to reverse compound?
nice catch, yes!
ok reverted, this broke tests
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |