W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2017

Re: [csswg-drafts] [css-sizing] should specify how to handle infinite max-content sizes

From: L. David Baron via GitHub <sysbot+gh@w3.org>
Date: Thu, 23 Feb 2017 21:22:51 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-282125376-1487884970-sysbot+gh@w3.org>
In response to @FremyCompany's 
https://github.com/w3c/csswg-drafts/issues/1046#issuecomment-281551260
 :  I'm not sure how that spec statement is relevant; the parent div 
has 'width: max-content', so the containing block width should be the 
max-content width of the table, not the width of the browser window.  
But I think the spec I wrote a while back [explains how percentages 
should be 
handled](https://dbaron.org/css/intrinsic/#autotableintrinsic) (though
 also see the other parts of its [description of automatic table 
layout](https://dbaron.org/css/intrinsic/#autotable)).

Part of the reason that the test didn't do what I expect, though, is 
that Gecko has only added unprefixed support for `max-content` in some
 contexts; for `width`, it needs to be `width: -moz-max-content`.

The other part of the reason that Gecko didn't do what I expected is 
that tables actually have two different concepts of max-content width,
 specifically to avoid propagating the infinite max-content widths 
outside of the table (while still using them for the table's own 
sizing).  I introduced this as part of the [original reflow 
refactoring 
landing](https://bugzilla.mozilla.org/show_bug.cgi?id=300030), so it 
might be a little hard to track down the history (which is in CVS, but
 was never imported to either git or mercurial).

So it's actually possible that infinite max-content sizes aren't yet a
 general concept but are still local to only some areas.

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/1046#issuecomment-282125376
 using your GitHub account
Received on Thursday, 23 February 2017 21:22:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:08 UTC