Set Ready For Review
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool is_legacy_column_rule =
style.ColumnRuleWidthInternal().HasSingleValue() &&
style.ColumnRuleStyle().HasSingleValue();
// Record use counter for the `column-rule-width` property if its resolved
// value is non-zero and the corresponding style is "none" or "hidden". This
// is to evaluate web compat risk in changing the behavior of
// `column-rule-width` to be independent of the `column-rule-style`.
//
// https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
if (is_legacy_column_rule && value_phase == CSSValuePhase::kResolvedValue &&
layout_object) {
int width_value = style.ColumnRuleWidthInternal().GetLegacyValue();
EBorderStyle style_value = style.ColumnRuleStyle().GetLegacyValue();
if (width_value != 0 && (style_value == EBorderStyle::kNone ||
style_value == EBorderStyle::kHidden)) {
layout_object->GetDocument().CountUse(
WebFeature::kResolvedColumnRuleWidthWithNoneOrHiddenStyle);
}
}
It thought this only had web compat risk if it was queried, not just if it resolved to the legacy value. Will this only be kResolvedValue if an author queries this themselves?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
bool is_legacy_column_rule =
style.ColumnRuleWidthInternal().HasSingleValue() &&
style.ColumnRuleStyle().HasSingleValue();
// Record use counter for the `column-rule-width` property if its resolved
// value is non-zero and the corresponding style is "none" or "hidden". This
// is to evaluate web compat risk in changing the behavior of
// `column-rule-width` to be independent of the `column-rule-style`.
//
// https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
if (is_legacy_column_rule && value_phase == CSSValuePhase::kResolvedValue &&
layout_object) {
int width_value = style.ColumnRuleWidthInternal().GetLegacyValue();
EBorderStyle style_value = style.ColumnRuleStyle().GetLegacyValue();
if (width_value != 0 && (style_value == EBorderStyle::kNone ||
style_value == EBorderStyle::kHidden)) {
layout_object->GetDocument().CountUse(
WebFeature::kResolvedColumnRuleWidthWithNoneOrHiddenStyle);
}
}
It thought this only had web compat risk if it was queried, not just if it resolved to the legacy value. Will this only be kResolvedValue if an author queries this themselves?
It thought this only had web compat risk if it was queried, not just if it resolved to the legacy value.
That should be the case. When the style is `none` or `hidden`, the rendering will be the same either with or without the behavior change, since column-rule and outline don't affect layout. The only observable difference is the value queried via getComputedStyle().
Will this only be kResolvedValue if an author queries this themselves?
Sam Davis can answer for sure, but I'd expect the answer to be "yes." Resolved values are intended specifically for getComputedStyle(). Internal codepaths that need the used value should be asking the ComputedStyle object for values rather than coming through here.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yes, like Kevin mentioned, the observable difference will be when the value is queried via getComputedStyle() since there's no rendering difference.
In terms of the `value_phase` being kResolved value, the primary place where this is css_computed_style_declaration.cc (which I'm guessing corresponds to what powers getComputedStyle).
That's not the *only* path though, there are some others that seem like one offs like:
* html/forms/internal_popup_menu.cc in:
* SerializeComputedStyleForProperty
* inspector/inspector_dom_snapshot_agent.cc in:
* InspectorDOMSnapshotAgent::BuildStylesForNode
* inspector/legacy_dom_snapshot_agent.cc in:
* LegacyDOMSnapshotAgent::GetStyleIndexForNode
* svg/svg_animate_element.cc in:
* ComputeCSSPropertyValue
* view_transition/view_transition_style_tracker.cc in:
* capture_property lamda.
* This one is only used for something called "border copying" and I checked with the VT folks that this is the right behavior.
Some of this need a closer look to determine if we should pass kComputedValue or kResolvedValue, the two suspects are the html_forms and svg_animate ones. But that's outside the scope of this change.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
bool is_legacy_column_rule =
Hmm ok as long as this is tracking the cases we care about, that's fine by me
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
bool is_legacy_column_rule =
style.ColumnRuleWidthInternal().HasSingleValue() &&
style.ColumnRuleStyle().HasSingleValue();
// Record use counter for the `column-rule-width` property if its resolved
// value is non-zero and the corresponding style is "none" or "hidden". This
// is to evaluate web compat risk in changing the behavior of
// `column-rule-width` to be independent of the `column-rule-style`.
//
// https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
if (is_legacy_column_rule && value_phase == CSSValuePhase::kResolvedValue &&
layout_object) {
int width_value = style.ColumnRuleWidthInternal().GetLegacyValue();
EBorderStyle style_value = style.ColumnRuleStyle().GetLegacyValue();
if (width_value != 0 && (style_value == EBorderStyle::kNone ||
style_value == EBorderStyle::kHidden)) {
layout_object->GetDocument().CountUse(
WebFeature::kResolvedColumnRuleWidthWithNoneOrHiddenStyle);
}
}
Kevin BabbittIt thought this only had web compat risk if it was queried, not just if it resolved to the legacy value. Will this only be kResolvedValue if an author queries this themselves?
Sam Davis OmekaraIt thought this only had web compat risk if it was queried, not just if it resolved to the legacy value.
That should be the case. When the style is `none` or `hidden`, the rendering will be the same either with or without the behavior change, since column-rule and outline don't affect layout. The only observable difference is the value queried via getComputedStyle().
Will this only be kResolvedValue if an author queries this themselves?
Sam Davis can answer for sure, but I'd expect the answer to be "yes." Resolved values are intended specifically for getComputedStyle(). Internal codepaths that need the used value should be asking the ComputedStyle object for values rather than coming through here.
Alison MaherYes, like Kevin mentioned, the observable difference will be when the value is queried via getComputedStyle() since there's no rendering difference.
In terms of the `value_phase` being kResolved value, the primary place where this is css_computed_style_declaration.cc (which I'm guessing corresponds to what powers getComputedStyle).
That's not the *only* path though, there are some others that seem like one offs like:
* html/forms/internal_popup_menu.cc in:
* SerializeComputedStyleForProperty* inspector/inspector_dom_snapshot_agent.cc in:
* InspectorDOMSnapshotAgent::BuildStylesForNode* inspector/legacy_dom_snapshot_agent.cc in:
* LegacyDOMSnapshotAgent::GetStyleIndexForNode* svg/svg_animate_element.cc in:
* ComputeCSSPropertyValue
* view_transition/view_transition_style_tracker.cc in:
* capture_property lamda.
* This one is only used for something called "border copying" and I checked with the VT folks that this is the right behavior.
Some of this need a closer look to determine if we should pass kComputedValue or kResolvedValue, the two suspects are the html_forms and svg_animate ones. But that's outside the scope of this change.
Hmm ok as long as this is tracking the cases we care about, that's fine by me
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Add use counter for disengangling resolved values change
This CL introduces granular use counters for the ouline-width and
column-rule-width CSS properties affected by the disentanglement work in
crrev.com/c/6909751. These counters are property-specific to accurately
measure usage and assess potential web compatibility risks resulting
from the CSS issue resolution [1], which led to decoupling the
outline-width and column-rule-width resolved values from their
corresponding style values.
[1]:
https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |