Repository navigation
[css-sizing] Incorrect use of the word "compute" in definition of intrinsic keyword values #2708
Description
The min-content and max-content values are defined as "otherwise compute to the property’s initial value". I read that as "otherwise (in the block-axis) the computed value of this property is the property’s initial value". This is not what UAs actually implement and would be problematic to implement since it would introduce a dependency on the writing-mode property. For example:
<div style="height: min-content">
<div style="height: inherit"></div>
</div>The spec suggest that the inner element should inherit the value auto. This seems wrong to me, it should inherit the value min-content (and this is what UAs currently implements).
I suggest you reword it as "otherwise the used value is the property’s initial value".
Activity
fantasai commentedon May 29, 2018
Well, the used value is a length, so we'll have to word it some other way...
[css-sizing-3] Don't compute *-content to 'auto' in block axis bc imp…
tabatkins commentedon Jun 13, 2018
Agenda+ to confirm that (a) the behavior change is desirable, and (b) that our edits (switching to "behaves as") are satisfactory.
css-meeting-bot commentedon Jun 27, 2018
The Working Group just discussed
Incorrect use of the word "compute" in definition of intrinsic keyword values, and agreed to the following:RESOLVED: change to "behave as" instead of "compute"The full IRC log of that discussion
<dael> Topic: Incorrect use of the word "compute" in definition of intrinsic keyword values<dael> github: https://github.com//issues/2708
<fantasai> https://github.com/w3c/csswg-drafts/commit/b603bfb33da70080b83f78e74f41c8af89b9b88b
<dael> fantasai: Changes are ^
<dael> fantasai: The min content and max content keywords and that type are currently defined to behave as property initial value if spec in block axis.
<dael> fantasai: Spec says they compute to property initial value so auto on height or none or max-height.
<dael> fantasai: Mats would prefer it to say "bahevs as" rather then "computes to"
<dael> fantasai: TabAtkins and I have no strong opinion. Up to impl.
<dael> s/bahevs/behaves
<dael> fantasai: Example from Mats is if you explicitly inherit height and gave one of these keywords you should get that keyword. Makes sense, but can't imagine anyone inheriting height.
<dael> dbaron: Issue is impl have to impl what spec says and that can be a pain to do
<dael> florian: If no real use case and simplier thing to impl, why not?
<dael> dbaron: Note one interesting point that request is the opposite of the request a few issues ago.
<dael> fantasai: Yep
<emilio> https://bugs.chromium.org/p/chromium/issues/detail?id=850872 is a broken site for inheriting height fwiw :-)
<dael> dbaron: Maybe figure out underlying principle. Maybe if it's a property that effects type of boxes.
<dael> Rossen_: Any reasons to not word it as "behaves as"?
<dael> Rossen_: I sympathize with Mats and having dependency between properties when computing the value of others is usually a thing to avoid. By not being a strict as current wording it at least doesn't explicitly say this is what it is.
<dael> Rossen_: We're not fixing issue by changing wording
<dael> Rossen_: For current sizing spec, are we okay make the change to "behave as" instead of "compute"
<dael> Rossen_: Objections?
<dael> fremy: Wasn't change to revert?
<dael> Rossen_: revert what?
<dael> fantasai: Resolution asked is to accept the change
<dael> florian: Reverse is earlier issue
<dael> Rossen_: I said change to behave as instead of compute.
<dael> RESOLVED: change to "behave as" instead of "compute"