[line-clamp] Don't expose the `line-clamp` longhands [chromium/src : main]
Ian Kilpatrick (Gerrit)
Ian Kilpatrick added 1 comment![]( "Open in Gerrit")
Related details
- Anders Hartvoll Ruud
- Andreu Botella
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Anders Hartvoll Ruud (Gerrit)
Anders Hartvoll Ruud added 5 comments![]( "Open in Gerrit")
name: "-alternative-webkit-line-clamp",
alternative_of: "-webkit-line-clamp",
property_methods: ["ParseSingleValue", "CSSValueFromComputedStyleInternal"],
style_builder_custom_functions: ["initial", "inherit", "value"],
keywords: ["none"],
typedom_types: ["Keyword", "Number"],
stored_on_extra_field: ["Continue", "MaxLines", "HasAutoMaxLines", "BlockEllipsis"],
// overlaps with line-clamp
legacy_overlapping: true,
runtime_flag: "CSSLineClamp",
},
{
name: "-alternative2-webkit-line-clamp",
alternative_of: "-alternative-webkit-line-clamp",Can we get a comment on each of these alternatives to explain why we need both of them?
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;What is the explanation for this behavior? Looking briefly at the spec, I couldn't find anything relevant.
// not setting BlockEllipsisWhy not? It has _some_ initial value, surely.
LookupAndApply(line_clamp, resolver);
maybe_skip(GetCSSPropertyAlternativeWebkitLineClamp(), *priority);If we're adding code for it, we should probably have a test which verifies that line-clamp and -webkit-line-clamp interact correctly in the cascade. (I.e. a test which verifies that one overwrites the other by its cascade strength, not e.g. just order of appearance.)
// We store the line-clamp shorthands (continue, max-lines, block-ellipsis)They are longhands?
Related details
- Andreu Botella
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andreu Botella (Gerrit)
Andreu Botella added 2 comments![]( "Open in Gerrit")
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;What is the explanation for this behavior? Looking briefly at the spec, I couldn't find anything relevant.
This, alongside with not setting an initial value for `BlockEllipsis`, are to fix an interaction of things that I feel might be fine for a shorthand property, since they're explainable based on the longhands, but might not be so much for a longhand. I'm not sure that this fix is the right one, or even that there should be one at all though. Still, I should've documented this.
In the spec, `block-ellipsis` is an inherited property, while the other `line-clamp` longhands aren't. This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line. So you could hide or customize the ellipsis depending on the paragraph.
One consequence of this is that an unstyled child of an element with `line-clamp: 3` would have an unserializable value of `line-clamp`, since the value for the longhands would be `continue: normal` (initial), `max-lines: auto` (initial), `block-ellipsis: ellipsis` (non-initial, inherited).
This also means that `<div style="line-clamp: 3"><div style="line-clamp: initial"><div id="a"></div></div></div>`
These two behaviors seem acceptable if `line-clamp` is a shorthand, but not if it's shipped as a non-inherited longhand. To try to fix this, I had `line-clamp: none` _not_ set the value of `block-ellipsis`; and when serializing or comparing `line-clamp`, `block-ellipsis` is ignored if `continue: normal` (so a non-initial value of `block-ellipsis` doesn't prevent `line-clamp` from serializing or comparing to `none`).
Are there any other alternatives I could've used?
// not setting BlockEllipsisWhy not? It has _some_ initial value, surely.
- Anders Hartvoll Ruud
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andreu Botella (Gerrit)
Andreu Botella added 1 comment![]( "Open in Gerrit")
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;Andreu BotellaWhat is the explanation for this behavior? Looking briefly at the spec, I couldn't find anything relevant.
This, alongside with not setting an initial value for `BlockEllipsis`, are to fix an interaction of things that I feel might be fine for a shorthand property, since they're explainable based on the longhands, but might not be so much for a longhand. I'm not sure that this fix is the right one, or even that there should be one at all though. Still, I should've documented this.
In the spec, `block-ellipsis` is an inherited property, while the other `line-clamp` longhands aren't. This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line. So you could hide or customize the ellipsis depending on the paragraph.
One consequence of this is that an unstyled child of an element with `line-clamp: 3` would have an unserializable value of `line-clamp`, since the value for the longhands would be `continue: normal` (initial), `max-lines: auto` (initial), `block-ellipsis: ellipsis` (non-initial, inherited).
This also means that `<div style="line-clamp: 3"><div style="line-clamp: initial"><div id="a"></div></div></div>`
These two behaviors seem acceptable if `line-clamp` is a shorthand, but not if it's shipped as a non-inherited longhand. To try to fix this, I had `line-clamp: none` _not_ set the value of `block-ellipsis`; and when serializing or comparing `line-clamp`, `block-ellipsis` is ignored if `continue: normal` (so a non-initial value of `block-ellipsis` doesn't prevent `line-clamp` from serializing or comparing to `none`).
Are there any other alternatives I could've used?
Sorry, I left a paragraph unfinished there:
This also means that in `<div style="line-clamp: 3"><div id="a" style="line-clamp: initial"></div></div>`, `#a` will behave differently if it contains a clamp point than if it didn't have `line-clamp: initial`, because that resets the value of `block-ellipsis`.
Anders Hartvoll Ruud (Gerrit)
Anders Hartvoll Ruud added 1 comment![]( "Open in Gerrit")
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;Andreu BotellaWhat is the explanation for this behavior? Looking briefly at the spec, I couldn't find anything relevant.
Andreu BotellaThis, alongside with not setting an initial value for `BlockEllipsis`, are to fix an interaction of things that I feel might be fine for a shorthand property, since they're explainable based on the longhands, but might not be so much for a longhand. I'm not sure that this fix is the right one, or even that there should be one at all though. Still, I should've documented this.
In the spec, `block-ellipsis` is an inherited property, while the other `line-clamp` longhands aren't. This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line. So you could hide or customize the ellipsis depending on the paragraph.
One consequence of this is that an unstyled child of an element with `line-clamp: 3` would have an unserializable value of `line-clamp`, since the value for the longhands would be `continue: normal` (initial), `max-lines: auto` (initial), `block-ellipsis: ellipsis` (non-initial, inherited).
This also means that `<div style="line-clamp: 3"><div style="line-clamp: initial"><div id="a"></div></div></div>`
These two behaviors seem acceptable if `line-clamp` is a shorthand, but not if it's shipped as a non-inherited longhand. To try to fix this, I had `line-clamp: none` _not_ set the value of `block-ellipsis`; and when serializing or comparing `line-clamp`, `block-ellipsis` is ignored if `continue: normal` (so a non-initial value of `block-ellipsis` doesn't prevent `line-clamp` from serializing or comparing to `none`).
Are there any other alternatives I could've used?
Sorry, I left a paragraph unfinished there:
This also means that in `<div style="line-clamp: 3"><div id="a" style="line-clamp: initial"></div></div>`, `#a` will behave differently if it contains a clamp point than if it didn't have `line-clamp: initial`, because that resets the value of `block-ellipsis`.
I don't get it.
This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line.
That is not relevant for the computed value stage. "Value checked" by what? Where?
unstyled child of an element with line-clamp: 3 would have an unserializable value of line-clamp
Why is it not just `line-clamp: ellipsis`? Though it depends on what you mean by "unstyled child". (There is no such thing, unless it's display:none, or outside the flat tree.)
Related details
- Andreu Botella
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andreu Botella (Gerrit)
Andreu Botella added 1 comment![]( "Open in Gerrit")
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;Andreu BotellaWhat is the explanation for this behavior? Looking briefly at the spec, I couldn't find anything relevant.
Andreu BotellaThis, alongside with not setting an initial value for `BlockEllipsis`, are to fix an interaction of things that I feel might be fine for a shorthand property, since they're explainable based on the longhands, but might not be so much for a longhand. I'm not sure that this fix is the right one, or even that there should be one at all though. Still, I should've documented this.
In the spec, `block-ellipsis` is an inherited property, while the other `line-clamp` longhands aren't. This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line. So you could hide or customize the ellipsis depending on the paragraph.
One consequence of this is that an unstyled child of an element with `line-clamp: 3` would have an unserializable value of `line-clamp`, since the value for the longhands would be `continue: normal` (initial), `max-lines: auto` (initial), `block-ellipsis: ellipsis` (non-initial, inherited).
This also means that `<div style="line-clamp: 3"><div style="line-clamp: initial"><div id="a"></div></div></div>`
These two behaviors seem acceptable if `line-clamp` is a shorthand, but not if it's shipped as a non-inherited longhand. To try to fix this, I had `line-clamp: none` _not_ set the value of `block-ellipsis`; and when serializing or comparing `line-clamp`, `block-ellipsis` is ignored if `continue: normal` (so a non-initial value of `block-ellipsis` doesn't prevent `line-clamp` from serializing or comparing to `none`).
Are there any other alternatives I could've used?
Anders Hartvoll RuudSorry, I left a paragraph unfinished there:
This also means that in `<div style="line-clamp: 3"><div id="a" style="line-clamp: initial"></div></div>`, `#a` will behave differently if it contains a clamp point than if it didn't have `line-clamp: initial`, because that resets the value of `block-ellipsis`.
I don't get it.
This is because when deciding whether the clamp point has an ellipsis (and in the future, what custom string to show instead of an ellipsis), the value checked is not the one in the line-clamp container, but in the inline formatting context root for the clamped line.
That is not relevant for the computed value stage. "Value checked" by what? Where?
unstyled child of an element with line-clamp: 3 would have an unserializable value of line-clamp
Why is it not just `line-clamp: ellipsis`? Though it depends on what you mean by "unstyled child". (There is no such thing, unless it's display:none, or outside the flat tree.)
Why is it not just `line-clamp: ellipsis`? Though it depends on what you mean by "unstyled child". (There is no such thing, unless it's display:none, or outside the flat tree.)
I meant a child with no (relevant) styles set, so all the properties would inherit or have their initial values.
For the `line-clamp` shorthand, `line-clamp: none` sets all the longhands to their initial values; in particular, it sets `continue` to `normal` (or `auto` in the current spec text, which hasn't been updated yet; see https://github.com/w3c/csswg-drafts/issues/13670). Meanwhile, a value other than `none` always sets `continue` to either `collapse` or `-webkit-legacy`.
The reason for this is that with the initial value of `continue` there's no clamping, so `max-lines` and `block-ellipsis` don't take effect. But that also means that there's no syntax for `line-clamp` that results in `continue: normal` and `block-ellipsis: ellipsis`.
------
That is not relevant for the computed value stage. "Value checked" by what? Where?
You're right that this is not relevant for the computed value stage, but there's an alternative implementation of this where the `BlockEllipsis` computed style extra field does not inherit, and doesn't share the same storage with the `block-ellipsis` longhand. This could be made to work, but it'd need layout code refactoring, and I'd rather keep the difference between the different runtime flag options limited to the style code.
Related details
- Anders Hartvoll Ruud
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Anders Hartvoll Ruud (Gerrit)
Anders Hartvoll Ruud added 1 comment![]( "Open in Gerrit")
there's an alternative implementation of this where the BlockEllipsis computed style extra field does not inherit, and doesn't share the same storage with the block-ellipsis longhand.
I don't see why that would be needed.
I'd rather keep the difference between the different runtime flag options limited to the style code.
Agreed.
unstyled child of an element with line-clamp: 3 would have an unserializable value of line-clamp
[myself] Why is it not just line-clamp: ellipsis?
OK, now I see why it's not just `ellipsis`. `line-clamp: ellipsis` actually corresponds to `max-lines:none;continue:collapse;block-ellipsis:ellipsis`, where as we would actually need to represent `max-lines:none;continue:normal;block-ellipsis:ellipsis` on the "unstyled child".
This just sounds like poor design. Unless this is a deliberate choice by the CSSWG, we should just raise an issue and fix it.
Either way, the way it's set up now is wrong. When applying the initial value of `line-clamp` (as well as `none`), we do need to explicitly apply the _entire_ initial value onto the `ComputedStyle`. Right now, we're applying a partial initial value on top of some undefined `block-ellipsis` value.
If this _is_ a deliberate choice, then we probably need to return an empty string for the `line-clamp` longhand-which-should-have-been-a-shorthand. After all, this is how the true `line-clamp` shorthand would behave as well.
Related details
- Andreu Botella
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andreu Botella (Gerrit)
Andreu Botella added 1 comment![]( "Open in Gerrit")
bool ignore_block_ellipsis = a.Continue() != EContinue::kNormal;This just sounds like poor design. Unless this is a deliberate choice by the CSSWG, we should just raise an issue and fix it.
`continue: normal` blocks the effects of the other two properties, so this isn't necessarily a bad design in my opinion. When you're using `line-clamp`, the value space makes sense, and the only case where something goes wrong is when serializing.
------
I discussed some of this with Ian, and I think this implementation where the value state for the `block-ellipsis` property when exposed is also used for the `line-clamp` longhand is probably not a good idea. Instead, I'll work on a change where the `block-ellipsis` state is stored in a separate non-inherited computed state extra field, since the layout code change needed for this is relatively small.
Related details
- Anders Hartvoll Ruud
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |