update to match flexbox spec language on "min-width:auto" & items with intrinsic aspect ratios

NEW
Unassigned

Status

()

defect
4 years ago
3 days ago

People

(Reporter: dholbert, Unassigned, NeedInfo)

Tracking

(Depends on 1 bug, Blocks 2 bugs, {dev-doc-needed})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
webcompat ?

Firefox Tracking Flags

(Webcompat Priority:?)

Details

(Whiteboard: [webcompat][layout:backlog])

Attachments

(1 attachment)

Reporter

Description

4 years ago
Posted file testcase 1
The "min-width:auto" language that I implemented/updated in bug 1015474 got rewritten in the spec in August, here:
  https://hg.csswg.org/drafts/rev/9b745a07d529#l1.33

The current (rewritten) spec language is here:
  http://dev.w3.org/csswg/css-flexbox-1/#valdef-min-width-min-height-auto

At the time, I didn't think this latest rewrite actually changed the behavior much, but I just noticed that it actually did.  Specifically:
 - The old language (which we have implemented) *only* considered the min-content size "if the item has no intrinsic aspect ratio".
 - Whereas, the new language *does* consider the min-content size *even if there's an intrinsic aspect ratio*. It defines "content size" as the "min-content size in the main axis, clamped, if it has an aspect ratio, by any definite min and max cross size properties converted through the aspect ratio, and then further clamped by the max main size property if that is definite."

I posted to www-style to clarify why this change was made & if it was intentional (personally I prefer the old behavior for this case):
https://lists.w3.org/Archives/Public/www-style/2015Feb/0485.html

If the current spec language sticks, I'm filing this bug to implement that new language.
Reporter

Comment 1

4 years ago
The current spec language is indeed sticking, as noted here:
 https://lists.w3.org/Archives/Public/www-style/2015Mar/0029.html
Reporter

Updated

4 years ago
OS: Linux → All
Hardware: x86_64 → All
Reporter

Updated

2 years ago
Duplicate of this bug: 1331692
Reporter

Comment 3

2 years ago
Note: this bug causes minor breakage in the Spotify web player's recently-updated DRM-enabled "flash-free" UI (which happens to be the UI that they show me, but not the one that they show everybody).

e.g. if you visit this page with a skinny-ish browser window:  https://open.spotify.com/search/results/coheed and look at the top 5 songs, the durations aren't aligned, particularly for songs with long names.  The div with the song name (with class="tracklistcol name") refuses to shrink to be skinnier than the song name, despite having "flex: 1; width: 0;".  If I manually add "min-width:0", then it'll cooperate and shrink (and allow text-overflow:ellipsis to take effect on one of its descendants), though -- and then everything aligns nicely.   This is a form of this bug, as discussed in dupe bug 1331692.
Reporter

Updated

2 years ago
Depends on: 1349738
See Also: → 1349738
Reporter

Updated

2 years ago
Blocks: 1373826
Reporter

Updated

2 years ago
Whiteboard: [webcompat]
Reporter

Updated

Last year
Duplicate of this bug: 1443274
Reporter

Updated

Last year
Duplicate of this bug: 1442273
Reporter

Updated

Last year
Duplicate of this bug: 1452047
Reporter

Updated

Last year
Duplicate of this bug: 1468066
Reporter

Updated

Last year
Blocks: 1468066
Reporter

Updated

6 months ago
No longer blocks: 1468066
Flags: webcompat?
Whiteboard: [webcompat] → [webcompat][layout:triage-discuss]
Reporter

Updated

2 months ago
Duplicate of this bug: 1541297

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

ni? myself to discuss at upcoming webcompat triage.

Flags: needinfo?(svoisen)
Whiteboard: [webcompat][layout:triage-discuss] → [webcompat][layout:backlog]
You need to log in before you can comment on or make changes to this bug.