Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

[css-grid] fr

33 messages.

[css-grid] Moving CSS3 Grid from Editor’s Draft to Working Draft
Chris Jones   Thu, 16 Feb 2012 18:05:15 +0000

www-style > February 2012 > 0760.html

Received on Thursday, 16 February 2012 18:06:11 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org
Copied to: sylvaing@microsoft.com, pcupp@microsoft.com, psalas@microsoft.com, mmielke@microsoft.com, alexmog@microsoft.com, Rossen.Atanassov@microsoft.com.

The Grid Spec Editors propose moving the current Editor’s Draft of the CSS3 Grid Layout module to Working Draft: http://dev.w3.org/csswg/css3-grid-align/ A list of changes made in Editor’s Drafts to the spec since the last Working Draft is below. We are happy to discuss any concerns about the move on www-style, or during Tuesday’s telcon (2/21/12). Thanks, Grid Spec Editors Changes made in 22 July 2011 Editor's Draft: • Included an algorithm for computing the size of Grid Tracks in the spec. • Removed the property grid-cell-stacking. • Removed the pseudo-element selector ::grid-cell. • Defined that Grid Cells named explicitly using the grid-template property cannot be styled (with the removal of the ::grid-cell pseudo-element selector they cannot be selected). • Removed the notion that Grid Cells could be given a display property which controls their inner layout. • Corrected an error in the automatic placement example. All children of the form should be display:block to ensure they are valid Grid Items. • Updated the Grid Columns and Grid Rows Properties grammar to correct an error and reduce ocurrences of <string> Changes made in 21 November 2011 Editor's Draft: • Section 2.4, Section 9: Removed the grid-layer property in favor of using z-index. • Section 6.5: Clarified whitespace rules. • Section 6.5: Changed "positive-number" to "positive-integer". • Section 6.5: Updated the spec to clarify that percentages-sized grid tracks are undefined when inside content-sized grids. • Section 8.1: Updated the spec to show that percentage-sized grid items resolve themselves against the grid cell, rather than the grid element. • Section 10.1: Updated definition of RemainingSpace for shrink-to-fit situations. • Section 10.2: Renamed NormalizedFractionBreadth variable to NormalizedFractionValue in the CalculateNormalizedFractionBreadth algorithm • Section 10.2: Addressed typos (e.g. Space -> SpaceToFill) in CalculateNormalizedFractionBreadth • Section 10.2: Updated CalculateNormalizedFractionBreadth to remove an unneeded inner loop in step 7. • Section 10.2: Updated steps 2 and 3 in DistributeSpaceToTracks function to correct use of delta variable • Section 10.2: Updated step 6 in ComputeUsedBreadthOfGridTracks to cover shrink-to-fit Grid Elements Changes made in 2 February 2012 Editor's Draft: • Section 2.2: Made a minor correction to the markup in Example 1. • Section 7: Specified item placement behavior for undefined grid lines. • Section 7.1: Specified that for the grid-column and grid-row properties, 'start' is only applicable to the starting line position and 'end' is only applicable to the ending line position. • Section 8.1: Updated the spec to better describe the behavior of box model calculations for stretch alignment. Changes made in 6 February 2012 Editor's Draft: • Section 10: Combined Sections 10.2 and 10.3, so that the overall algorithm is described in a top-down fashion. • Section 10.2: Removed the function DistributeSpaceToTracksBySpanCount, and added new functions ResolveContentBasedTrackSizingFunctions and ResolveContentBasedTrackSizingFunctionsForItems. The updates to the algorithm change the way in which Grid Items that span multiple tracks resolve their min-content and max-content contributions to those tracks such that "tighter" grids are produced.
[css-grid] IE fragmentation algorithm
Peter Salas   Thu, 29 Aug 2013 22:41:51 +0000

www-style > August 2013 > 0642.html

Received on Thursday, 29 August 2013 22:42:21 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

Section 12 for the CSS grid spec is currently empty and I was asked to document IE's algorithm for fragmenting grids. It consists of a small modification to the regular (non-fragmented) algorithm: First, compute grid track sizes and grid item positions as if the grid is being laid out in unconstrained space. Since fragmenting a grid item can increase its size, if a "content-sized row" is broken across fragments, increase its size as needed in the subsequent fragment so that it remains large enough to contain fragmented items that span only that row. For the purposes of this heuristic a "content-sized row" is a row with a content min track sizing function or a fraction row in an auto height grid. Other row sizes are not recomputed following the adjustment. Note that this algorithm can easily cause unnecessary overflow. For example, if the fragmentation heuristic comes into effect anywhere in a fixed height grid with a fraction row the rows are guaranteed to overflow the grid. Peter
[css-grid] sum of fractions < 1
Mats Palmgren   Sat, 26 Apr 2014 18:36:43 +0000

www-style > April 2014 > 0432.html

Received on Saturday, 26 April 2014 18:37:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

After the recent change[1] in Flexbox that flex factors should be treated as percentages when their total sum is less than 1, I'm wondering about the corresponding case for Grid. If the total sum of fractions in a track is less than 1, should they be treated as percentages? http://dev.w3.org/csswg/css-grid/#fr-unit (the Note there seems wrong at the moment) Cheers, Mats [1] http://dev.w3.org/csswg/css-flexbox-1/issues-cr-2012#issue-30
Re: [css-grid] sum of fractions < 1
"Tab Atkins Jr."   Mon, 28 Apr 2014 10:19:28 -0700

www-style > April 2014 > 0441.html

Received on Monday, 28 April 2014 17:20:15 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: mats@mozilla.com
Copied to: www-style@w3.org, www-style@w3.org.

On Sat, Apr 26, 2014 at 11:36 AM, Mats Palmgren <mats@mozilla.com> wrote: > After the recent change[1] in Flexbox that flex factors should be treated > as percentages when their total sum is less than 1, I'm wondering about > the corresponding case for Grid. If the total sum of fractions in a track > is less than 1, should they be treated as percentages? > > http://dev.w3.org/csswg/css-grid/#fr-unit > (the Note there seems wrong at the moment) We're tracking that already as Issue 9 in the draft: http://dev.w3.org/csswg/css-grid/#issue-55d6dc75 . Yes, we'll probably need to do something about it to match Flexbox. We haven't delved in yet to figure it out. Like Flexbox, whatever change we make is almost certain to be safe to make, as basically everybody uses integer flex factors. ~TJ
[css-grid] Indefinite free space
Sergio Villar Senin   Thu, 13 Nov 2014 16:11:32 +0100

www-style > November 2014 > 0224.html

Received on Thursday, 13 November 2014 15:11:58 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

In previous drafts[1] there was this definition of RemainingSpace (which is now called Free Space): "The max of zero and the AvailableSpace less the sum of all Grid track UsedBreadth values. This is undefined if AvailableSpace is undefined (i.e. the Grid element is shrink-to-fit or the height is auto.)" Recent versions of the specs do not mention at all what is inside the parentheses. Should consider it as incorrect from now on? >From the current specs[2], Free Space is defined as "If available space is indefinite, the free space is indefinite as well". Appart from that we now from [3] that "An indefinite available size is essentially infinite". What I understand is that in those cases we could just grow all the tracks to their maximums and that's it. Is that correct? BR [1] http://www.w3.org/TR/2013/WD-css3-grid-layout-20130402/ [2] http://dev.w3.org/csswg/css-grid/#available-space [3] http://dev.w3.org/csswg/css-sizing-3/#terms
Re: [css-grid] Indefinite free space
"Tab Atkins Jr."   Thu, 13 Nov 2014 08:43:10 -0800

www-style > November 2014 > 0227.html

Received on Thursday, 13 November 2014 16:43:58 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: svillar@igalia.com
Copied to: www-style@w3.org.

On Thu, Nov 13, 2014 at 7:11 AM, Sergio Villar Senin <svillar@igalia.com> wrote: > In previous drafts[1] there was this definition of RemainingSpace (which > is now called Free Space): "The max of zero and the AvailableSpace less > the sum of all Grid track UsedBreadth values. This is undefined if > AvailableSpace is undefined (i.e. the Grid element is shrink-to-fit or > the height is auto.)" > > Recent versions of the specs do not mention at all what is inside the > parentheses. Should consider it as incorrect from now on? No, why would it be incorrect? We rewrote all of the text from scratch, and just didn't include those examples. > >From the current specs[2], Free Space is defined as "If available space > is indefinite, the free space is indefinite as well". Appart from that > we know from [3] that "An indefinite available size is essentially > infinite". What I understand is that in those cases we could just grow > all the tracks to their maximums and that's it. Is that correct? I believe that is what happens, yes, but I'd have to review the algo to make sure. ~TJ
[css-grid] fr-unit section clarification
Manuel Rego Casasnovas   Tue, 24 Nov 2015 18:16:59 +0100

www-style > November 2015 > 0323.html

Received on Tuesday, 24 November 2015 17:17:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi, I think we should add some clarification in this section: https://drafts.csswg.org/css-grid/#fr-unit If you read this: "Each column or row’s share of the free space can be computed as the column or row’s <flex> * <free space> / <sum of all flex factors>." And you've just one track with "0.5fr" in a 800px width grid container. You might consider that the result should be: 0.5 * 800 / 0.5 = 800 But this is wrong, if you go to the section: https://drafts.csswg.org/css-grid/#algo-find-fr-size Where you can read this: "Let flex factor sum be the sum of the flex factors of the flexible tracks. If this value is less than 1, set it to 1 instead." So the good result is: 0.5 * 800 / 1 = 400 I think it'd be nice to explain it properly in the "fr-unit section" or at least link to "flex factor sum" from there. Bye, Rego
Re: [css-grid] fr-unit section clarification
"Tab Atkins Jr."   Wed, 9 Dec 2015 13:06:40 -0800

www-style > December 2015 > 0131.html

Received on Wednesday, 9 December 2015 21:07:27 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: rego@igalia.com
Copied to: www-style@w3.org.

On Tue, Nov 24, 2015 at 9:16 AM, Manuel Rego Casasnovas <rego@igalia.com> wrote: > Hi, > > I think we should add some clarification in this section: > https://drafts.csswg.org/css-grid/#fr-unit > > If you read this: > "Each column or row’s share of the free space can be computed as the > column or row’s <flex> * <free space> / <sum of all flex factors>." > > And you've just one track with "0.5fr" in a 800px width grid container. > You might consider that the result should be: > 0.5 * 800 / 0.5 = 800 > > But this is wrong, if you go to the section: > https://drafts.csswg.org/css-grid/#algo-find-fr-size > > Where you can read this: > "Let flex factor sum be the sum of the flex factors of the flexible > tracks. If this value is less than 1, set it to 1 instead." > > So the good result is: > 0.5 * 800 / 1 = 400 > > I think it'd be nice to explain it properly in the "fr-unit section" or > at least link to "flex factor sum" from there. Good catch. I added a note, explaining that it was similar to Flexbox. ~TJ
[css-grid] Fragmenting Grid Layout: what happens to grid gap at break boundary?
Mats Palmgren   Fri, 18 Dec 2015 03:29:59 +0100

www-style > December 2015 > 0245.html

Received on Friday, 18 December 2015 02:30:36 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

https://drafts.csswg.org/css-grid/#pagination There is a typo under the first bullet item: "flex items" should be "grid items" I believe. I also need clarification on what should happen with grid gaps at break boundaries. Should they be suppressed? (and by "grid gaps" here I mean the spacing between rows added for grid-row-gap and/or align-content) /Mats
Re: [css-grid] Fragmenting Grid Layout: what happens to grid gap at break boundary?
"Tab Atkins Jr."   Thu, 17 Dec 2015 19:03:11 -0800

www-style > December 2015 > 0246.html

Received on Friday, 18 December 2015 03:03:59 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: mats@mozilla.com
Copied to: www-style@w3.org.

On Thu, Dec 17, 2015 at 6:29 PM, Mats Palmgren <mats@mozilla.com> wrote: > https://drafts.csswg.org/css-grid/#pagination > > There is a typo under the first bullet item: "flex items" > should be "grid items" I believe. Yup. > I also need clarification on what should happen with grid gaps > at break boundaries. Should they be suppressed? > (and by "grid gaps" here I mean the spacing between rows > added for grid-row-gap and/or align-content) We haven't edited that section since we added grid gaps. I suspect they should be suppressed, like margins. After all, we don't put gaps at the start or end. ~TJ
Re: [css-grid] Fragmenting Grid Layout: what happens to grid gap at break boundary?
fantasai   Tue, 19 Jan 2016 14:41:45 -0800

www-style > January 2016 > 0125.html

Received on Tuesday, 19 January 2016 22:42:14 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, mats@mozilla.com
Copied to: www-style@w3.org.

On 12/17/2015 07:03 PM, Tab Atkins Jr. wrote: > On Thu, Dec 17, 2015 at 6:29 PM, Mats Palmgren <mats@mozilla.com> wrote: >> https://drafts.csswg.org/css-grid/#pagination >> >> There is a typo under the first bullet item: "flex items" >> should be "grid items" I believe. > > Yup. > >> I also need clarification on what should happen with grid gaps >> at break boundaries. Should they be suppressed? >> (and by "grid gaps" here I mean the spacing between rows >> added for grid-row-gap and/or align-content) > > We haven't edited that section since we added grid gaps. I suspect > they should be suppressed, like margins. After all, we don't put gaps > at the start or end. All fixed. ~fantasai
[css-grid] Fragmenting orthogonal grids
fantasai   Sun, 28 Feb 2016 11:54:40 -0500

www-style > February 2016 > 0329.html

Received on Sunday, 28 February 2016 16:55:14 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

The fragmentation section of the spec should probably allow breaks between columns in the case of orthogonal flows. ~fantasai
[css-grid] fr units and minmax() mins
"Eric A. Meyer"   Tue, 22 Mar 2016 21:19:12 -0400

www-style > March 2016 > 0333.html

Received on Wednesday, 23 March 2016 01:19:39 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

The behavior of flex items in the 'min' position of a minxmax() is somewhat confusing to me. It's explained quite clearly, but what's explained doesn't really gel for me, conceptually speaking. To quote <https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax>: "minmax(min,max) Defines a size range greater than or equal to min and less than or equal to max. If max < min, then max is ignored and minmax(min,max) is treated as min. As a maximum, a <flex> value sets the track’s flex factor. As a minimum, it is treated as zero (or min-content, if the grid container is sized under a min-content constraint)." So if I declare: grid-template-columns: 100px minmax(3fr, 300px) 1fr 100px; ..then the third column (1fr) will flex all the way down until it reaches zero width. At that point, the second column, the minmaxed one, will start to flex narrower. The two never flex at the same time. My expectation, before reading that passage closely, was that the above CSS would cause the second column to be given `3fr` sizing until it reached 300 pixels in width, at which point it would stop growing. Thus, below that width, the second and third columns would flex and be sized at a 3:1 ratio, using whatever space was left over after the first and fourth columns were placed. Above that width, the first, second, and fourth columns would all be fixed-width, and the third would get all the flex space. Was my expectation. I have to admit the reasoning behind the current behavior eludes me. Why are flexible mins force-set to zero? -- Eric A. Meyer - http://meyerweb.com/
Re: [css-grid] Fragmenting orthogonal grids
fantasai   Mon, 11 Apr 2016 19:18:05 -0400

www-style > April 2016 > 0191.html

Received on Monday, 11 April 2016 23:18:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

On 02/28/2016 11:54 AM, fantasai wrote: > The fragmentation section of the spec should probably allow > breaks between columns in the case of orthogonal flows. Just checked this in, for consistency with multicol and because it's a good idea. It's currently marked as optional though. Will double-check with the WG on the next telecon. ~fantasai
Re: [css-grid] fr units and minmax() mins
fantasai   Mon, 11 Apr 2016 19:55:09 -0400

www-style > April 2016 > 0197.html

Received on Monday, 11 April 2016 23:55:44 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: eric@meyerweb.com, www-style@w3.org, psalas@microsoft.com.

On 03/22/2016 09:19 PM, Eric A. Meyer wrote: > The behavior of flex items in the 'min' position of a minxmax() is somewhat confusing to me. It's explained quite clearly, but > what's explained doesn't really gel for me, conceptually speaking. > > To quote https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax: > > "minmax(min,max) > Defines a size range greater than or equal to min and less than or equal to max. If max < min, then max is ignored and > minmax(min,max) is treated as min. As a maximum, a <flex> value sets the track’s flex factor. As a minimum, it is treated as > zero (or min-content, if the grid container is sized under a min-content constraint)." > > So if I declare: > > |grid-template-columns: 100px minmax(3fr, 300px) 1fr 100px; | > > ..then the third column (1fr) will flex all the way down until it reaches zero width. At that point, the second column, the > minmaxed one, will start to flex narrower. The two never flex at the same time. > > My expectation, before reading that passage closely, was that the above CSS would cause the second column to be given |3fr| > sizing until it reached 300 pixels in width, at which point it would stop growing. Thus, below that width, the second and > third columns would flex and be sized at a 3:1 ratio, using whatever space was left over after the first and fourth columns > were placed. Above that width, the first, second, and fourth columns would all be fixed-width, and the third would get all the > flex space. Was my expectation. > > I have to admit the reasoning behind the current behavior eludes me. Why are flexible mins force-set to zero? I think what you're expecting totally makes sense, but also fixing it would mean adding additional steps to the track sizing algorithm, which I'm a little hesitant to do right now... But something that's imho definitely worth investigating, so perhaps it would make sense to make this syntax invalid for the moment, so that we can figure out what to do with it in Level 2. ~fantasai
Re: [css-grid] fr units and minmax() mins
"Eric A. Meyer"   Tue, 12 Apr 2016 13:53:41 -0400

www-style > April 2016 > 0204.html

Received on Tuesday, 12 April 2016 17:54:11 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 11 Apr 2016, at 19:55, fantasai wrote: > I think what you're expecting totally makes sense, but also > fixing it would mean adding additional steps to the track > sizing algorithm, which I'm a little hesitant to do right > now... > > But something that's imho definitely worth investigating, > so perhaps it would make sense to make this syntax invalid > for the moment, so that we can figure out what to do with > it in Level 2. How are you thinking of invalidating? Forbid 'fr' units from being used in the 'min' position, or ban then from minmax() expressions altogether, or something else entirely? -- Eric A. Meyer - http://meyerweb.com/
Re: [css-grid] fr units and minmax() mins
"Tab Atkins Jr."   Tue, 12 Apr 2016 12:21:45 -0700

www-style > April 2016 > 0209.html

Received on Tuesday, 12 April 2016 19:22:32 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: eric@meyerweb.com
Copied to: www-style@w3.org.

On Tue, Apr 12, 2016 at 10:53 AM, Eric A. Meyer <eric@meyerweb.com> wrote: > On 11 Apr 2016, at 19:55, fantasai wrote: >> I think what you're expecting totally makes sense, but also >> fixing it would mean adding additional steps to the track >> sizing algorithm, which I'm a little hesitant to do right >> now... >> >> But something that's imho definitely worth investigating, >> so perhaps it would make sense to make this syntax invalid >> for the moment, so that we can figure out what to do with >> it in Level 2. > > > How are you thinking of invalidating? Forbid 'fr' units from being used in > the 'min' position, or ban then from minmax() expressions altogether, or > something else entirely? Forbid them from the min position. We already adjusted the grammar for this yesterday. ^_^ ~TJ
Re: [css-grid] fr units and minmax() mins
fantasai   Tue, 12 Apr 2016 15:23:40 -0400

www-style > April 2016 > 0210.html

Received on Tuesday, 12 April 2016 19:24:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: eric@meyerweb.com, www-style@w3.org.

On 04/12/2016 01:53 PM, Eric A. Meyer wrote: > On 11 Apr 2016, at 19:55, fantasai wrote: > >> I think what you're expecting totally makes sense, but also >> fixing it would mean adding additional steps to the track >> sizing algorithm, which I'm a little hesitant to do right >> now... >> >> But something that's imho definitely worth investigating, >> so perhaps it would make sense to make this syntax invalid >> for the moment, so that we can figure out what to do with >> it in Level 2. > > How are you thinking of invalidating? Forbid 'fr' units > from being used in the 'min' position, or ban then from minmax() > expressions altogether, or something else entirely? Making them invalid in the min position. ~fantasai
Re: [css-grid] fr units and minmax() mins
"Eric A. Meyer"   Tue, 12 Apr 2016 16:20:31 -0400

www-style > April 2016 > 0214.html

Received on Tuesday, 12 April 2016 20:21:23 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: www-style@w3.org.

On 12 Apr 2016, at 15:23, fantasai wrote: > On 04/12/2016 01:53 PM, Eric A. Meyer wrote: >> On 11 Apr 2016, at 19:55, fantasai wrote: >> >>> But something that's imho definitely worth investigating, >>> so perhaps it would make sense to make this syntax invalid >>> for the moment, so that we can figure out what to do with >>> it in Level 2. >> >> How are you thinking of invalidating? Forbid 'fr' units >> from being used in the 'min' position, or ban then from minmax() >> expressions altogether, or something else entirely? > > Making them invalid in the min position. Makes sense. Thanks! Now I have errata to file against my own writing... -- Eric A. Meyer - http://meyerweb.com/
[css-grid] Update minmax() description now that fr is invalid as minimum
Manuel Rego Casasnovas   Thu, 12 May 2016 17:52:41 +0200

www-style > May 2016 > 0110.html

Received on Thursday, 12 May 2016 15:53:15 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi, a recent change [1] in the spec makes flex sizes invalid on the min slot of minmax(): " <track-size> = <track-breadth> | minmax( <inflexible-breadth> , <track-breadth> )" However, the text defining minmax() hasn't been updated [2]: "As a maximum, a <flex> value sets the track’s flex factor. As a minimum, it is treated as zero (or min-content, if the grid container is sized under a min-content constraint)." I believe we should change this to state that as a minimum it makes the declaration invalid. WDYT? Bye, Rego [1] https://github.com/w3c/csswg-drafts/commit/4040ba7fa068905f7fe1c1bf35d665a2062acafa [2] https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
Manuel Rego Casasnovas   Fri, 13 May 2016 18:52:47 +0200

www-style > May 2016 > 0116.html

Received on Friday, 13 May 2016 16:53:22 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 12/05/16 17:52, Manuel Rego Casasnovas wrote: > a recent change [1] in the spec makes flex sizes invalid > on the min slot of minmax(): > " <track-size> = > <track-breadth> | > minmax( <inflexible-breadth> , <track-breadth> )" > > However, the text defining minmax() hasn't been updated [2]: > "As a maximum, a <flex> value sets the track’s flex factor. > As a minimum, it is treated as zero (or min-content, > if the grid container is sized under a min-content constraint)." > > I believe we should change this to state that as a minimum it makes the > declaration invalid. And not only that, also the text in the algorithm needs to be updated too [3]: "When the grid container is being sized under a min-content constraint, a track with a flexible min track sizing function is treated as if its min track sizing function was min-content for the purposes of this step." But now a "track with a flexible min track sizing function" is invalid. Bye, Rego > [1] > https://github.com/w3c/csswg-drafts/commit/4040ba7fa068905f7fe1c1bf35d665a2062acafa > [2] https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax [3] https://drafts.csswg.org/css-grid/#algo-content
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
Manuel Rego Casasnovas   Mon, 16 May 2016 16:52:17 +0200

www-style > May 2016 > 0122.html

Received on Monday, 16 May 2016 14:52:44 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 13/05/16 18:52, Manuel Rego Casasnovas wrote: > > > On 12/05/16 17:52, Manuel Rego Casasnovas wrote: >> a recent change [1] in the spec makes flex sizes invalid >> on the min slot of minmax(): >> " <track-size> = >> <track-breadth> | >> minmax( <inflexible-breadth> , <track-breadth> )" >> >> However, the text defining minmax() hasn't been updated [2]: >> "As a maximum, a <flex> value sets the track’s flex factor. >> As a minimum, it is treated as zero (or min-content, >> if the grid container is sized under a min-content constraint)." >> >> I believe we should change this to state that as a minimum it makes the >> declaration invalid. > > And not only that, also the text in the algorithm needs to be updated > too [3]: > "When the grid container is being sized under a min-content constraint, > a track with a flexible min track sizing function is treated as if > its min track sizing function was min-content for the purposes > of this step." > > But now a "track with a flexible min track sizing function" is invalid. And another issue when the algorithm terms are defined [4]: "min track sizing function If the track was sized with a minmax() function, this is the first argument to that function. Otherwise, it’s the track’s sizing function." Now that "fr" is invalid as minimum, I guess we need an exception in this rule too. Bye, Rego >> [1] >> https://github.com/w3c/csswg-drafts/commit/4040ba7fa068905f7fe1c1bf35d665a2062acafa >> [2] https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax > [3] https://drafts.csswg.org/css-grid/#algo-content [4] https://drafts.csswg.org/css-grid/#algo-terms
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
Mats Palmgren   Mon, 16 May 2016 18:19:24 +0200

www-style > May 2016 > 0123.html

Received on Monday, 16 May 2016 16:19:55 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 2016-05-16 16:52, Manuel Rego Casasnovas wrote: > And another issue when the algorithm terms are defined [4]: > "min track sizing function > If the track was sized with a minmax() function, > this is the first argument to that function. > Otherwise, it’s the track’s sizing function." > > Now that "fr" is invalid as minimum, > I guess we need an exception in this rule too. > > [4] https://drafts.csswg.org/css-grid/#algo-terms > As I read it, "sized by a minmax() function" doesn't apply for minmax(1fr,...) because the value is simply invalid. The track is sized by the (computed) value 'auto' in this case. I agree that the text could be clearer though. Perhaps replace "If the track was sized with a minmax() function" with "If the computed value of the track sizing function is a minmax() function" ? "track sizing function" is a defined term in [1] and it excludes 'fr' in the min value in a minmax(). So it should be clear that the computed value is 'auto' in that case. (linking "track sizing function" from [4] to [1] would help too) [1] https://drafts.csswg.org/css-grid/#grid-template-rows-track-sizing-function Regards, Mats
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
fantasai   Mon, 16 May 2016 15:06:26 -0700

www-style > May 2016 > 0125.html

Received on Monday, 16 May 2016 22:06:53 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 05/12/2016 08:52 AM, Manuel Rego Casasnovas wrote: > > Hi, > > a recent change [1] in the spec makes flex sizes invalid > on the min slot of minmax(): > " <track-size> = > <track-breadth> | > minmax( <inflexible-breadth> , <track-breadth> )" > > However, the text defining minmax() hasn't been updated [2]: > "As a maximum, a <flex> value sets the track’s flex factor. > As a minimum, it is treated as zero (or min-content, > if the grid container is sized under a min-content constraint)." > > I believe we should change this to state that as a minimum it makes the > declaration invalid. > > WDYT? I think it's obviously an error and should be fixed. :P Done. ~fantasai
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
fantasai   Mon, 16 May 2016 15:10:25 -0700

www-style > May 2016 > 0126.html

Received on Monday, 16 May 2016 22:10:53 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: mats@mozilla.com, www-style@w3.org.

On 05/16/2016 09:19 AM, Mats Palmgren wrote: > > As I read it, "sized by a minmax() function" doesn't apply for > minmax(1fr,...) because the value is simply invalid. The track > is sized by the (computed) value 'auto' in this case. > > I agree that the text could be clearer though. Perhaps replace > "If the track was sized with a minmax() function" with > "If the computed value of the track sizing function is a minmax() > function" ? > > "track sizing function" is a defined term in [1] and it excludes > 'fr' in the min value in a minmax(). So it should be clear that > the computed value is 'auto' in that case. > (linking "track sizing function" from [4] to [1] would help too) I'm a little confused what you mean by computing to 'auto'. Invalid syntax causes the declaration to be thrown out, not for it to compute to 'auto'... ~fantasai
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
Mats Palmgren   Tue, 17 May 2016 01:28:46 +0200

www-style > May 2016 > 0127.html

Received on Monday, 16 May 2016 23:29:18 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 2016-05-17 00:10, fantasai wrote: > On 05/16/2016 09:19 AM, Mats Palmgren wrote: >> "track sizing function" is a defined term in [1] and it excludes >> 'fr' in the min value in a minmax(). So it should be clear that >> the computed value is 'auto' in that case. >> (linking "track sizing function" from [4] to [1] would help too) > > I'm a little confused what you mean by computing to 'auto'. > Invalid syntax causes the declaration to be thrown out, > not for it to compute to 'auto'... Yeah, I meant the declaration is invalid and thus discarded, so the property (grid-template-columns/rows) gets its initial value, 'none': https://drafts.csswg.org/css-grid/#track-sizing Assuming an initial value for grid-auto-columns/rows the sizing function ends up being 'auto'. Granted, it could be some other value... https://drafts.csswg.org/css-grid/#auto-tracks Anyway, the text I suggested avoids saying anything specific about the value, or which property it came from. It just makes it clear that it's a *computed value* it's talking about, which excludes 'fr' min-sizing. /Mats
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
fantasai   Thu, 19 May 2016 16:39:35 -0700

www-style > May 2016 > 0184.html

Received on Thursday, 19 May 2016 23:40:06 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 05/13/2016 09:52 AM, Manuel Rego Casasnovas wrote: > > > On 12/05/16 17:52, Manuel Rego Casasnovas wrote: >> a recent change [1] in the spec makes flex sizes invalid >> on the min slot of minmax(): >> " <track-size> = >> <track-breadth> | >> minmax( <inflexible-breadth> , <track-breadth> )" >> >> However, the text defining minmax() hasn't been updated [2]: >> "As a maximum, a <flex> value sets the track’s flex factor. >> As a minimum, it is treated as zero (or min-content, >> if the grid container is sized under a min-content constraint)." >> >> I believe we should change this to state that as a minimum it makes the >> declaration invalid. > > And not only that, also the text in the algorithm needs to be updated > too [3]: > "When the grid container is being sized under a min-content constraint, > a track with a flexible min track sizing function is treated as if > its min track sizing function was min-content for the purposes > of this step." > > But now a "track with a flexible min track sizing function" is invalid. Removed. Thanks~ :) ~fantasai
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
fantasai   Thu, 19 May 2016 16:42:07 -0700

www-style > May 2016 > 0185.html

Received on Thursday, 19 May 2016 23:42:45 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 05/16/2016 07:52 AM, Manuel Rego Casasnovas wrote: > > > On 13/05/16 18:52, Manuel Rego Casasnovas wrote: >> >> >> On 12/05/16 17:52, Manuel Rego Casasnovas wrote: >>> a recent change [1] in the spec makes flex sizes invalid >>> on the min slot of minmax(): >>> " <track-size> = >>> <track-breadth> | >>> minmax( <inflexible-breadth> , <track-breadth> )" >>> >>> However, the text defining minmax() hasn't been updated [2]: >>> "As a maximum, a <flex> value sets the track’s flex factor. >>> As a minimum, it is treated as zero (or min-content, >>> if the grid container is sized under a min-content constraint)." >>> >>> I believe we should change this to state that as a minimum it makes the >>> declaration invalid. >> >> And not only that, also the text in the algorithm needs to be updated >> too [3]: >> "When the grid container is being sized under a min-content constraint, >> a track with a flexible min track sizing function is treated as if >> its min track sizing function was min-content for the purposes >> of this step." >> >> But now a "track with a flexible min track sizing function" is invalid. > > And another issue when the algorithm terms are defined [4]: > "min track sizing function > If the track was sized with a minmax() function, > this is the first argument to that function. > Otherwise, it’s the track’s sizing function." > > Now that "fr" is invalid as minimum, > I guess we need an exception in this rule too. I think I've fixed this. Please let me know if it's still incorrect. https://drafts.csswg.org/css-grid/#min-track-sizing-function ~fantasai
Re: [css-grid] Update minmax() description now that fr is invalid as minimum
Manuel Rego Casasnovas   Fri, 20 May 2016 09:39:56 +0200

www-style > May 2016 > 0187.html

Received on Friday, 20 May 2016 07:40:32 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 20/05/16 01:42, fantasai wrote: > I think I've fixed this. Please let me know if it's still incorrect. > https://drafts.csswg.org/css-grid/#min-track-sizing-function It seems fine now. Thanks, Rego
[CSSWG] Minutes San Francisco F2F 2016-05-09 Part I: Flexbox, Box Alignment, Grid [css-flexbox] [css-align] [css-grid]
Dael Jackson   Tue, 24 May 2016 19:35:05 -0400

www-style > May 2016 > 0208.html

Received on Tuesday, 24 May 2016 23:36:05 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Flexbox ------- - RESOLVED: Issue 1 the text for a11y is accepted. Box Alignment ------------- - RESOLVED: Apply justify-content to columns in multicol elements - RESOLVED: Make “smart safe” alignment the default for handling overflow; but put at risk with a note saying to contact CSSWG if there is a problem regarding compat. Grid ---- - RESOLVED: Keep the spec the way it is in regards to issue #3 (Abspos item placement in degenerate grids) - RESOLVED: Keep spec as is in regards to issue #24 (Drop empty tracks at ends or also in the middle?) - Rossen was tasked with reviewing issue #39, missing 'auto' changes for span>1 - RESOLVED: subgrid proposal accepted in the at-risk section ===== FULL MINUTES BELOW ======= Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics Present: Rossen Atanassov, Microsoft Tab Atkins, Google L. David Baron, Mozilla Tantek Çelik, Mozilla Dave Cramer, Hachette Livre Elika Etemad, Invited Expert Daniel Glazman, Disruptive Innovations (only IRC) Daniel Holbert, Mozilla Jihye Hong, LG Electronics (only IRC) Koji Ishii, Google Brad Kemper, Invited Expert Ian Kilpatrick, Google Chris Lilley, W3C Peter Linss, HPI Myles Maxfield, Apple Edward O'Connor, Apple Simon Pieters, Opera Florian Rivoal, Vivliostyle Inc. Andrey Rybka, Bloomberg Hiroshi Sakakibara, Beyond Perspective Solutions Simon Sapin, Mozilla (only phone) Jen Simmons, Mozilla Geoffrey Sneddon, Invited Expert Alan Stearns, Adobe Shane Stephens, Google Lea Verou, Invited Expert (only IRC) Greg Whitworth, Microsoft Regrets: Dael Jackson, Invited Expert Hyojin Song, LG Electronics Scribe: gregwhitworth Flexbox ======= <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301 fantasai: As we mentioned, pretty much everything is fixed. fantasai: We asked for people to review issue 1 and 3. fantasai: We're asking for official resolution of those two, the rest are editorial. fantasai: You're happy to review them. After resolving we would like a CR. fantasai: Anyone need more time for issue 3? dbaron: The resolution for issue 3, is it independent of percent sizing with intrinsic widths? fantasai: Good question. astearns: That is one thing that does not have a time slot, that can be breakout session. dbaron: I just want to make sure that we're not tying this to something that isn't compatible with the web. fantasai: This one I believe is about the intrinsic minimum sizes. florian: Is it flex specific? dbaron: No. florian: If there is a side convo please try to include me. hober: If the dependency graph includes the percentage issue, then we should resolve that first. dbaron: I'm not saying it does, I'm just asking. fantasai: I'm not sure... yeah I think there is somewhat a dependency so we should resolve on those together. fantasai: So issue 1: a11y wording. Rossen: Do we have text for issue 1? fantasai: Yes. <fantasai> Note at the bottom of https://drafts.csswg.org/css-flexbox-1/#order-accessibility dauwhe: Are the a11y wg happy with it? fantasai: Cynthia is, she reported it. Rossen: I think the wording is exactly how we decided it, we should be fine. I'll follow up with Cynthia and close the loop with Richard and the rest of the WG. RESOLVED: Issue 1 the text for a11y is accepted. Box Alignment ============= Application of justify-content to multicol columns -------------------------------------------------- fantasai: Tab and I went through the spec and updated the baseline alignment stuff to the best of our ability. fantasai: Anyone that's interested please take a look at it. fantasai: One open issue is whether the justify-content property applies to column boxes. fantasai: The other is the default value of overflow. fantasai: The justify-content property: in grid it justifies the tracks and in flex it justifies the flex lines. fantasai: [gives example of how justify-content works] fantasai: The goal of this spec is to allow alignment to work for all layout models. fantasai: Should justify-content apply to the columns or not? TabAtkins: No - justify-content can't because it applies to one line of things. florian: It sounds interesting, but do we have any wiggle room? fantasai: We can say that the normal value is doing what multicol already does, fantasai: for blocks it does nothing for them. <fantasai> https://drafts.csswg.org/css-align-3/#distribution-block florian: It sounds interesting to me. dbaron: It still doesn't make sense to me why it doesn't apply to block. TabAtkins: There is only one flow of stuff, so you can't justify its items - you can justify self. fantasai: If you think in terms of flex, block is like having one flex line. fantasai: There is no line in a block. dbaron: I was confusing justify-content and justify-items. jensimmons: If you specify the width of the col at 200, if we change this would you be able to do this and add the power to keep it at 200 and distribute from that fixed size? fantasai: Yes, this adds power to multi-col. florian: We cover step sizing a little bit later. dauwhe: This makes sense. TabAtkins: The mechanics are all there, this just allows you to control those gaps. RESOLVED: Add justify-content to multicol florian: Now we have column rules in the middle of column gaps TabAtkins: just like grid the things on the side are not gaps default overflow-alignment value -------------------------------- <fantasai> https://drafts.csswg.org/css-align-3/#overflow-values fantasai: The next issue is the initial handling of overflow-alignment. fantasai: We have safe and unsafe keywords, e.g. with 'unsafe' if you say center it will absolutely center it even if that causes it to overflow both sides, so the 'safe' keyword restricts overflow to the end side. fantasai: But a lot of times what you really want is true centering, except you want to keep it inside of the scrollable region. fantasai: The user wants to be able to see the content and they should be able to get to the content. fantasai: The initial behavior we're proposing is to do the unsafe behavior up until you would overflow the unscrollable container and then switch to the safe behavior. dbaron: That is very expensive on the layout engine. dbaron: I would prefer for people to have to ask for the slow path. fantasai: The people that need this won't know they'll need to change this. So it won't be useful as a default. fantasai: Only if you have overflow do you need to re-layout this. dbaron: I don't buy that there isn't overflow the majority of cases. dbaron: We can't change the default for block. fantasai: Block already does safe alignment. fantasai: This is all new stuff. fantasai: The only legacy is flex box. fantasai: Once this spec is implemented it will apply to everything and will only work if you set the alignment keywords. esprehn: I want to talk about the feature. esprehn: Someone showed a layout where the content is inaccessible, we need to solve it. dbaron: I prefer safe rather than true for that reason. esprehn: The example we had was a video in an iframe and the top was cut off and you could only scroll down. dbaron: A lot of layout issues deal with how a parent deals with its children. Rossen: Once you start nesting you're going to have very bad performance. Rossen: This sounds like a weird position: sticky-ish. TabAtkins: This is still scrollable and only goes back if you overflow out of your scrollable bounds. dbaron: I agree with Rossen. Rossen: The benefit of sticky, you can keep it on the compositor and not re-layout. shans: This is about the negative bounds, not the scrollable region. Rossen: This is how I understood it, if you begin layout and you center align some items you start overflowing you have to redo layout to fix it. shans: On resize you re-layout anyways. fantasai: [draws a diagram] fantasai: [explains drawing] fantasai: This is all about the scrollable region, when the shifting occurs and it's outside the scrollable bounds this will change the box's alignment position to allow the content to be visible. fantasai: If you have a box that is a flexbox and it has a flex item that will have an item that goes into the unscrollable area then you flag it. fantasai: This only triggers when you have overflow in the scrollable direction. florian: Is this a third value? florian: Yes it's a third value. TabAtkins: It's kinda safe. zcorpan: You want this to happen in any direction right? fantasai: Yes. dholbert: This will affect any container with any alignment props set. fantasai: I think you could probably optimize this mostly away. dbaron: I think in theory that's fine, but it will take 10 years to find all the bugs. fantasai: We would like to put it in the spec and put it at risk, we don't expect it to be implemented soon. fantasai: Our content dependency is with flexbox. fantasai: The change in behavior may look a little bit worse on some pages, but for pages (like esprehn's example) where users can't scroll to see the content, this will fix those pages. bradk: Why not just make it so that you can scroll to the content? TabAtkins: That's the idea. hober: I don't want an infinite scrollbar because someone positioned something way out on the left for cargo cult a11y reasons. dbaron: What UI do you do when the scrollbar position is somewhere random in the middle? bradk: In a non-perfect world it seems like a good solution. dbaron: I looked into implementing it about 10 years ago and realized that it was too much of a compat risk. zcorpan: It would need to be opt in. TabAtkins: People use negative margins to hide stuff off the start edge of the document. fantasai: Any other comments? dholbert: Maybe an idea to work out later, but relpos/abspos would need to be taken into account. Rossen: The point is you should not start in a positive, safe will take you to the origin of that box, we don't want to move content. fantasai: We'll make you less unsafe until you're safe. florian: If you make this the default and at risk, please be clear in the spec what to do if you're not willing to implement this. TabAtkins: We still need a name. Rossen: un-safe-ish Rossen: scrollport fantasai: Does that sound like a reasonable plan? TabAtkins: Default to unsafe and put it at risk. dbaron: What happens to flex? fantasai: It will cause a behavior change where items are aligned such that they are not fully within the scrollable area. fantasai: This will probably fix more pages than it breaks. dbaron: I'm not sure I buy that. fantasai: But it only affects things that are aligning items into unscrollable regions. esprehn: Every time we change flex, we get yelled at - let's change and see how loud the yell is. hober: Also put a note that if you change and get yelled at let us know. RESOLVED: Put it into the spec, put at risk with a note saying to contact specs if you hear from authors regarding compat. <dholbert> fantasai/tab: we'd need to also be sure this "scrollsafe" alignment thing would interact nicely with layout containment <dholbert> In particular, layout containment probably needs to block aligned things from finding their nearest scrollable ancestor <dholbert> (for the purposes of this keyword) * fantasai likes the name scrollsafe :) fantasai: We'll publish next week. fantasai: Probably. dbaron: How much do we need to add to custom layout to make that work in Houdini? Rossen: Not much I think, you would need to add the origin and it's nearest ancestor. Rossen: You're always avoiding the origin for scrolling purposes. iank: I'm trying to catch up dbaron: I think if the nearest scroller is in another writing mode. Rossen: It still has an origin. dbaron: OK, you're right. Rossen: It's implementable. Rossen: Now that I understand it, it's not that scary. <iank> This seems fine for Houdini at a first glance, in your constraintspace at the moment you know at which point you'll trigger a scroll, and can adjust off that; but I'd have to have a little more of a think. Grid ==== <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917 abspos items in degenerative grids (Issue 3) -------------------------------------------- TabAtkins: We have a couple things that we need approval first. TabAtkins: Abspos items in degenerative grids. TabAtkins: The question here was what to do when you have a grid with no tracks whatsoever and how to place abspos items as a result; they care where the grid is. TabAtkins: There is no grid items, just some abspos and the grid has one grid line but no tracks, where should this line be? TabAtkins: The spec says it's against the start edge in both axis. astearns: Does anyone have any issues? astearns: Any objections? hober: What do the implementations do? TabAtkins: Don't know. RESOLVED: Keep the spec the way it is in regards to issue #3 Repeat function with auto-fit and auto-fill keywords (Issue 24) --------------------------------------------------------------- <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-24 TabAtkins: The repeat function with auto-fit and auto-fill keywords. TabAtkins: If you have 1000px to work with and auto-fit with 10 tracks it will adjust accordingly, with auto-fill and you don't have enough columns it will drop them. TabAtkins: Which columns should you drop? TabAtkins: These columns in the middle are not being used, do you drop them? TabAtkins: We don't have a strong opinion on this, currently it's defined at the end. fantasai: We spec it currently based on what's implemented. jensimmons: Correct me if I'm wrong, I want empty columns in the middle and they don't want them to go away. fantasai: No this is for the auto-fill not auto-fit within the repeat() syntax. jensimmons: I just want to get what I've defined. fantasai: We'll do that, fantasai: But sometimes when you want to center columns and that contradicts with the amount of columns available, do you drop the tracks at the end and middle, or just the end. So we have an 'auto-fit' keyword to allow for that option. fantasai: Can anyone come up with a use case and behavior that people prefer? TabAtkins: Unless anyone has any strong opinion, we'll keep it the way the spec is. TabAtkins: Which is to drop all empty tracks. dholbert: The counterintuitive part is you can have something in col1 and col10 and then remove all the empty ones when you wanted them apart. RESOLVED: Keep spec as is in regards to issue #24 Missing 'auto' changes for span>1 (Issue 39) -------------------------------------------- <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-39 TabAtkins: The counterintuitive part is why you would ask for auto generated rows and then explicitly set them into cols. fantasai: We need very competent people to take a look at this one. astearns: Anyone? TabAtkins: We think the spec is correct, but we would like for someone to take a look. Rossen was voluntold. ACTION Rossen to review issue 39 of the grid spec <trackbot> Created ACTION-768 Subgrid ------- TabAtkins: The previous position on subgrid was complex so we removed it. That said, there are use cases that can't be done in current grid. TabAtkins: So we've put together a much simpler proposal that covers the majority of use cases. <fantasai> http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/ fantasai: Here's the feedback we got on subgrid: <fantasai> http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/ <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0141.html <jensimmons> Rachel Andrew on subgrid, her response: https://rachelandrew.co.uk/archives/2016/04/25/a-revised-subgrid-specification/ fantasai: What are the things we need to address and how simple can we get it? fantasai: There were things we could get rid of, e.g. the subgrid auto sizing itself based on its contents. fantasai: So now you can't have any overflow tracks in the subgrid. fantasai: You can have overflowing content however (due to sizing), so they are still scrollable. fantasai: It won't affect the sizing of the parent grid however. <fantasai> Current proposal - https://lists.w3.org/Archives/Public/www-style/2016Apr/0254.html TabAtkins: [shows example of the subgrid] TabAtkins: You declare an item to be a subgrid by giving it display: subgrid TabAtkins: This makes it a grid container but grid-template- columns/rows do nothing on it. TabAtkins: The children on the subgrid position themselves on the parent's grid. TabAtkins: The subgrid still lays out. TabAtkins: The margin/padding/border they get applied accordingly magically to apply the declared amount. florian: I assume this does the right thing no matter the writing mode? TabAtkins: Yes. TabAtkins: It works the same way in nested subgrids. TabAtkins: You cannot get implicit tracks from the subgrid. florian: Can you use display: contents? TabAtkins: Sure, if you don't need a wrapper at all, then use display: contents. TabAtkins: You can't set grid gaps on a subgrid. florian: Anyone implementing grid not implementing display: contents? TabAtkins: We plan to, but will take awhile because we need to refactor a lot of code. FF has an implementation of it, webkit has a prototype I think. florian: I'll write a blog post, florian: to convince everyone to implement display: contents. TabAtkins: That's the proposal. TabAtkins: Does the WG feel this is a good direction to with? TabAtkins: Overflow still applies. astearns: You were going to go over the single dimension case that this doesn't support. TabAtkins: Right. TabAtkins: Let's say you have a subgrid and your parent is 2x2 square but you don't care about the rows of the parent's grid, TabAtkins: and you don't know how many rows itself will have. TabAtkins: This particular case is easy to hit with HEADER, CONTENT, FOOTER and then you want to fill in the content with your catalog items. TabAtkins: However, this makes it very complicated to handle. TabAtkins: The case is relatively small, and you can use a nested grid to allow for this so long as track sizes are not intrinsic. TabAtkins: If people demand a lot of this we may try to address it in the future. Rossen: By current subgrid proposal, this is not possible? TabAtkins: Yes, it can't work. Rossen: Good, I think this keeps it quite simple and keeps the mental model of the grid intact and symmetric. florian: Have you heard from the authors? fantasai: Yeah, I think this addresses the majority of the issues. Wanting to interweave the subgrid lines with the parents lines is very hard, and is not covered here. fantasai: There is an issue we marked, subgrid only takes affect if it is a grid item and the grid-template properties are set. fantasai: This gives us an extension point that allows us to use subgrid to ensure that the grid properties are set to none which they don't affect and later may affect it in the future it could break it. fantasai: The goal of adding the condition is so that the grid WILL break so that we can improve subgrid later. astearns: What do you do in this case then? fantasai: Maybe just treat it as block. dbaron: You're intentionally making it not work unless things are set for extension later then you should say so it in the spec and then also suggest implementations give console warnings. dholbert: We risk authors being ok with the "broken" behavior. florian: There's always a risk of that, but grid is so central to your layout that I think if it breaks then we won't have as much compat risk. astearns: If people do depend on it, we would need to come up with another way to solve it. astearns: We basically heard from all implementors saying 'subgrid. This is crazy.', have thoughts changed? TabAtkins: Igalia said their opinion on the list, dholbert: I spoke to Mats, and he feels this is still complex as you need to keep track of overflow for the items. fantasai: We would be ok with computing overflow to visible always if that is a concern. TabAtkins: Another issue is paint order. fantasai: I expect authors to be able to control z-index from within. dholbert: With that change, it may make it simpler. fantasai: You won't have to keep track of scrollers, etc dbaron: z-index also applies to all graphical stuff as well, masks, transforms, etc. fantasai: I think everything should just work as normal unless stated otherwise. dbaron: This is odd that it's basically an element that doesn't have a box. dbaron: This is similar to an element that doesn't have a box. TabAtkins: We're getting more explicit about the box. dbaron: But does the spec on filters or mask define whether this applies to elements or boxes, thus would impact a subgrid. esprehn: I don't think we should have another table row problem again. fantasai: I agree, it should get a box and we will on purpose exclude stuff from it to ease implementer complexity. dbaron: So it gets a box? fantasai: Yes. dbaron: This is well defined how the positioning/margin/border/ padding. TabAtkins: Yes. <Rossen> plinss, so you're saying that for layout purposes the subgrid is considered empty but has a size independent of its children sizes? jensimmons: I am an author and feel very strongly that subgrid should be included with grid, and I'm hoping that this is simple enough to ship it. jensimmons: From my experience they're going to be very confused that they can't align everything to the parent grid. jensimmons: I'm not sure this will cover all use cases, mainly because haven't had the time to play with it. jensimmons: In most cases they're going to be thinking about the explicit grid, not the implicit grid and I hope that this is simple enough that vendors will implement this. fantasai: I think we can resolve that overflow is at risk and say it computes to visible. astearns: So an at-risk within the at-risk section. astearns: Is there anything more people want to add? RESOLVED: subgrid proposal accepted in the at-risk section [break=15 minutes]
[CSSWG] San Francisco F2F 2016-05-11 Part IV: CSS Color, Grid, Flexbox, Inline [css-color] [css-grid] [css-flexbox] [css-inline]
Dael Jackson   Tue, 7 Jun 2016 21:25:37 +0300

www-style > June 2016 > 0021.html

Received on Tuesday, 7 June 2016 18:26:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Color --------- - There were several actions recorded to make improvements to the spec. They were to: - add note explaining a reasonable range for C in lch() to the spec - remove commas between in the color() examples - fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to either (consistently) dci-p3 or p3 - color() fallback should be like font list fallback. - add a working-color-space at-rule, which affects the entire document - The breakout session proposed resolving to publish WD for Color and MQ4. - RESOLVED: Do black point compensation when converting from profile to another. - RESOLVED: If you accurately describe the output device's color profile in an @color-profile rule then a sane implementation will not alter your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically. Grid ---- - RESOLVED: Add allowing track list in repeat() and auto-rows - RESOLVED: Drop named lines specified on the subgrid - RESOLVED: Publish a new WD. Flexbox ------- - RESOLVED: Publish a new CR flexbox. Inline ------ - RESOLVED: Publish inline ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics *** Color Breakout Session Minutes *** CSS Color --------- Scribe: zcorpan <ChrisL> https://drafts.csswg.org/css-color/#lab-colors ChrisL: We've had discussion in the last f2f for things we've wanted to do. ChrisL: Apple have fancy screens now and want to take advantage of that ChrisL: something something colorspaces. ChrisL: XYZ is a colorspace that can describe all known colors. ChrisL: XYZ fails to do white adaptation. ChrisL: LAB sticks an axis to the white point and if you take a perfect white surface, that's 100 ChrisL: then two orthogonal channels A and B that correspond to greenish and yellowish axises. ChrisL: LAB is useful, you get it in physical measurement devices etc. Florian: In the luminosity direction, how white is 100%? ChrisL: There are different standards for standard daylight and the one sRGB uses ChrisL: (before) LAB uses D50 ChrisL: ... this is all just summarizing the spec. ChrisL: If you look in the spec, I've tried to keep the math to a minimum. ChrisL: issue about out of range numbers ChrisL: steps for how to convert ... TabAtkins: what is a reasonable range for C? ChrisL: to go from LAB to ??? TabAtkins: so conversion between a/b and c/h is just rectangular to polar ChrisL: this is using the color() function, see example 9 ChrisL: it's like @font-face ChrisL: you give it a url TabAtkins: idents is the right thing ChrisL: ident and then as many numbers as needed <dbaron> ACTION ChrisL to add note explaining a reasonable range for C in lch() to the spec <TabAtkins> https://drafts.csswg.org/css-color/#color-function <dholbert> (inside of https://drafts.csswg.org/css-color/#icc-colors ) Florian: Why only 2? ChrisL: sRGB could be added but it doesn't give us anything new. ChrisL: Happy to add it if people want it. smfr: Makes sense for consistency. ChrisL: There's a section about grayscale. ChrisL: Consider replacing the grayscale section with a grayscale colorspace. ChrisL: We had a briefer syntax. leaverou: What about thing like named color profiles ? leaverou: Spot colors. ChrisL: Does not allow overrange values. ChrisL: We've handwaved about this for a long time. ChrisL: There was a linear space that was easy. ChrisL: There's something black that's not absolute black. ChrisL: That lasted for 2 years and then they decided to use a wider gamut if you want a wider gamut. ChrisL: We should have early clipping. cabanier(?): It's quiet about that. smfr: Do we want commas? TabAtkins: No, because we want to allow alpha. TabAtkins: Need to distinguish. ChrisL: So no commas between numbers in examples. <dbaron> ACTION ChrisL remove commas between in the color() examples ChrisL: Next section is P3 and Rec 2020. ChrisL: These refs can be added to MQ4. <dbaron> ACTION ChrisL fix the currently-broken Rec.2020 reference in the spec leaverou: If one is supplied no color profile, it will be ignored? ChrisL: @color-profile foo icc profile which is treated differently. leaverou: This might be confusing in some cases. ChrisL: It will look wrong if you copy a color but not the profile. TabAtkins: Rec.2020 is not a valid ident. TabAtkins: Rec2020 works fine. ChrisL: Thank you, noted. TabAtkins: Also ascii as lowercase please. ChrisL: mkay TabAtkins: Match what MQ does. <dbaron> ACTION ChrisL fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to either (consistently) dci-p3 or p3 ChrisL: Colors in wide color space and the device with a narrower space. ChrisL: What do you do with the ones outside? ChrisL: If it's an image with a nice gradient, things can look ugly. ChrisL: You move everything proportionally so that it looks nice ChrisL: but it's handwaving. ChrisL: Maintain the relationship between colors but they're all going to match. ChrisL: It's fine for a photograph but not when you want to match up a color in an image with a css color ChrisL: Saturated is useless. TabAtkins: Can we drop it? TabAtkins: Can we only allow them to choose the ones we care about? ChrisL: yeah... think so smfr: I don't know if we want to drop absolute color metric, might be useful for testing ChrisL: "this has to have an absolute luminance of this" Florian: If you have several profiles with the same color space? ChrisL: Last one wins. TabAtkins: They cascade as a unit cabanier: This is basically unused. Can we leave it as is? ChrisL: In svg2 you have to overwrite the profile. ChrisL: Should we remove the rendering intent thing? cabanier: Just use the default. TabAtkins: Need some way to choose the default. ChrisL: Perceptual is less good for css. smfr: Why is rendering intent tied to color profile? smfr: You want to specify rendering intent ... ChrisL: The way ICC profiles work, is you have a profile for your source data ChrisL: then you have a profile for your output device ChrisL: compose those two. ChrisL: How are you going to handle out of gamut colors? ChrisL: If you select perceptual ChrisL: it's less applicable to a wide gamut screen. ChrisL: An image has an intent built in; ChrisL: you can't override it. TabAtkins: If the profile has multiple intents you can specify the one you want. Florian: If the profile has multiple, does it specify the default? ChrisL: Yeah. cabanier: We set that as the default in the product. Florian: It's ok for photos and what we should use for the rest? ChrisL: Yes. ChrisL: Named color profiles, instead of having a mapping from a number. ChrisL: You have mapping from a name. ChrisL: People can do their own ones. ChrisL: This syntax does not cope with that but can be extended to do so. Florian: color() function, either a list of numbers or a string Florian: The other extension is to allow you to name your colors. Florian: New descriptor, @color-profile foo { src:...; named-color: "myblue" 00255, ...; Florian: Maybe not necessary because of variables. leaverou: Can you rename existing colors? ChrisL: Yes. TabAtkins: Don't object but it's strictly not necessary. ChrisL: I like it but variables is enough. cabanier: Print with specific ink... Florian: Can do that with this or with variables Florian: The variable contains "foo" 00255 so it contains the right colorspace. TabAtkins: Are these profiles text files? ChrisL: No terrible binary files. ChrisL: Tool to convert to xml so you can hack and convert back. dbaron: Some security vulnerabilities. esprehn: Apple have fixed security bugs in icc. ChrisL: Should restrict to same-origin. TabAtkins: Web policy, things should default to same-origin. ChrisL: Why are people using google fonts? TabAtkins: CORS, no problem smfr: Before you download you have to wait for ICC to download, like with fonts. smfr: Need to describe what should happen before it is downloaded. smfr: Would not impl except for built-in color profiles. esprehn: Same for us. Florian: context-dependent profile esprehn: Won't implement. Florian: What do you fallback to? esprehn: Wouldn't paint, same as fonts. Florian: So everything's white? ChrisL: Flash of uncalibrated color. esprehn: Yeah. esprehn: I'd like to see that you can specify a name so you don't need to download if you already have it. ChrisL: Fonts have local() for that. ChrisL: Fine to have that here also. ChrisL: How do you name your profiles, typically don't have a unique name. ChrisL: How do i define it? TabAtkins: Platforms can define what their names are and you can put it in the spec? ChrisL: So it's different per platform? -_- TabAtkins: Here's url, here's hash. esprehn: Not a security issue, privacy issue. TabAtkins: Fingerprinting is a lost cause dbaron: You can binary test for any font. TabAtkins: Fingerprinting is not fixable. leaverou: If I'm using super-RGB color space, makes sense to fallback to sRGB until it's loaded. TabAtkins: So fallback to a known name? dbaron: Is there a dictionary of downloadable profiles we can name? TabAtkins: We can inline them in the spec, they're small. Florian: Want to point to an image to use it's profile. ChrisL: We can put an appendix of common profiles. ChrisL: Print profiles are not small. TabAtkins: In Houdini we want these to be serializable. TabAtkins: Represent something in the string OM. TabAtkins: Here's the profile, it's 700 bytes of chars. TabAtkins: The color is considered invalid until the profile is downloaded. esprehn: Not going to reparse. TabAtkins: hrm. TabAtkins: ok nevermind. ChrisL: If you have a font stack, how does it work when the primary is downloaded? esprehn: Recompute, not reparse TabAtkins: Fallback in color(); fallback is like font list. esprehn: That's implementable. TabAtkins: Must provide a fallback. ChrisL: I'm fine with that. leaverou: Want to be able to fallback to a different profile. TabAtkins: That's fine. TabAtkins: In the color profile rule you can have a list of fallback profile names. TabAtkins: Also in the color() function you can have a fallback color. cabanier: Have to always specify fallback? no optional, ok. Florian: Can you use rgba() in the fallback? TabAtkins: ya ChrisL: Open issue, blending happens in sRGB. ChrisL: Which will give you clipping problems. ChrisL: Also doing maths wrong. ChrisL: Was going to add linear. ChrisL: There's hardware support. ChrisL: You can get the right result with LAB. ChrisL: We need a thing that says how you composite things. smfr: Compositing and blending has a similar problem. cabanier: The gamut is being worked on in the canvas spec cabanier: need to specify, just 1. smfr: We can't change the default because that breaks web pages. TabAtkins: Subframes does it only work for top-most windows? TabAtkins: iframe Florian: If it doesn't say but the iframe does, does it propagate up? TabAtkins: No. You can have two iframes smfr: I can't find linear blending in the spec. ChrisL: It's an open issue. Florian: When you've done your things in your colorspace, when you've done it, what do you export it into? ChrisL: the output colorspace, whatever that is. ChrisL: LAB is convenient for this reason. Florian: If you use anything but LAB do you need to go through LAB first? ChrisL: Yeah. Florian: When that's specified, do the color math other than color blending also happen in that colorspace? Florian: If we have LAB, can I switch to it and use it for ??? ChrisL: Yes but you get different result. Florian: Yeah, that's the point. cabanier: If you render in colorspace then all colors are in the same colorspace. ChrisL: I've seen examples of interpolation of ??? ChrisL: Can we pick a placeholder name? TabAtkins: document-interpolation-color-space smfr: working-color-space? TabAtkins: yeah cabanier: You map your colors so it's fine. ChrisL: 3x3 matrix ChrisL: Don't use 8 bits. ACTION ChrisL working color space Florian: sRGB? ChrisL: Auto is sRGB ChrisL: linear-sRGB ChrisL: LAB ChrisL: Any others? cabanier: The list of working spaces can't include linear? ChrisL: Why not? cabanier: Can't implement it yet ChrisL: That's wrong. HW has it already ChrisL: Can do it in linear-sRGB with clipping cabanier: Need to change the blending spec. cabanier: So the output is bogus? ChrisL: No, it's wrong now but people are used to it. ChrisL: Yes you will get a different result, if you're not using linear space you're technically get the wrong result now. ChrisL: Additivity... ChrisL: Measure the light of two lights. ChrisL: Additivity means I can take the two numbers and get the right result. ChrisL: In linear space you get the right result with +, otherwise not. Florian: In LAB, linear matches perception, which is nice. ChrisL: Exactly. smfr: MQ? cabanier: Should match canvas. cabanier: ... p3 2020, optimal (matches the screen) cabanier: On iMac you would be compositing in p3. cabanier: The gamut most closely matches the output. ChrisL: ok so MQ. Florian: I think what's in the spec now which is TabAtkins's interpretation of what we had in the mailing list, is fine with me. Florian: If people disagree say where and why. dbaron: This is a new type of MQ. dbaron: MQ where more than one of the values can be true. TabAtkins: Yeah all the range based ones have that. dbaron: It's a set MQ rather than a discreet MQ. dbaron: Might want to describe as a different type. TabAtkins: ok ChrisL: Are they ordered? TabAtkins: Only range features have an ordering. Florian: That you can do "less than". dbaron: Color gamut sRGB means it can do all of sRGB TabAtkins: Should we add a value for "narrow" for extra-low gamut (below sRGB)? dbaron: Concerned whether we CAN calculate it, if we have information to calculate it. Florian: Should I load normal images, fancy images or super-fancy images leaverou: Percentages seems useful. smfr: No this is good enough. TabAtkins: Boolean context are true for anything other than none or 0 TabAtkins: Not (boolean) is true. smfr: You're asking about the OS, not the screen. TabAtkins: It does not talk about the output device, need to fix wording. Rossen: Present to projector. Florian: Two screens? esprehn: Every monitor has its own profile, if you move a window between two, we repaint the window, which resolves the colors again. Florian: The incentive for UAs to lie is not high, it only makes you download heavier images than you need. TabAtkins: If there are multiple screens... Florian: Why not the highest? TabAtkins: In general you want the lowest. TabAtkins: Want to see the same thing as what's on the projector TabAtkins: below CSS. Florian: There are objections that this is not restricted to RGB spaces or the screen media type. Florian: If you have a whatever colorspace, if it's bigger then p3 then you match. Florian: People have disagreed with that. Florian: Maybe add a cmyk. ChrisL: We have TVs which have ??? Florian: if you have a sucky printer sRGB is what you get. TabAtkins: We can add specific named variants. Florian: For UAs that don't output in cmyk, this has 0 impl cost. TabAtkins: We dismiss the objections and go with the current design. Florian: Happy with that. ChrisL: Publish this? TabAtkins: Intent to publish. PROPOSED RESOLUTION: publish css-color and mq4 dbaron: There's impl interest for some things but not others. dbaron: Might be worth trying to figure that out sooner rather than later. TabAtkins: Figure out what we want to impl. ChrisL: color-mod() problems TabAtkins? <smfr> https://drafts.csswg.org/css-color/#modifying-colors TabAtkins: 1) syntax is confusing and crappy TabAtkins: I agree partially TabAtkins: it's overcomplicated. esprehn: Aliasing for everything? can we not do that? TabAtkins: 2) ??? is not super useful for real-world stuff TabAtkins: Modifying one color...suggested some different operations that I want to put in here instead. TabAtkins: Replace this with something like blending two colors together. leaverou: Lightness or mix with white and black which works better. TabAtkins: Color blending, color contrast, tint and shade. leaverou: I implemented a polyfill, it occurred to me that there were lots of (((()))) like lisp. TabAtkins: The grammar is intended to reduce that. leaverou: I suggest keywords. TabAtkins: I agree. leaverou: Crazy idea, what if we can use calc(color + semi-transparent white) then it blends with alpha blending? TabAtkins: calc is for numerical things. TabAtkins: We have cross-fade as existence proof that we use a new function for specific things. TabAtkins: We need color blending for convenience and so you can ??? Florian: device-cmyk ChrisL: If you have calibrated device-cmyk. Florian: That's no problem. ChrisL: If you don't provide a fallback you get a bad color. Florian: How does it work? ChrisL: It means here are some numbers, don't mess with them at all. Florian: If we composite and alpha-blend .... ChrisL: If you use color() to do that, it looks better. ChrisL: Inks are not transparent, can't overlay them. ChrisL: Have a pattern of dots instead in a grid. ChrisL: Overlaid in different angles. ChrisL: If you have a pale yellow and then few dots of black. ChrisL: That's what device-cmyk is for. ChrisL: Don't want those black dots. Florian: Why does output to PDF file have anything to do with the screen? TabAtkins: Don't have at a distance logic in MQ Florian: If you're a headless device? Florian: OS doesn't know what to do. Florian: What does the MQ do? ChrisL: It should say yes to everything, can print to pdf in any profile. leaverou: Can we get rid of device-cmyk somehow? TabAtkins: It's implemented. ChrisL: Black point compensation. ChrisL: White is easy. ChrisL: TVs can get much darker black. TabAtkins: Can we not do something like white compensation? ChrisL: No. the spec says why. ChrisL: Same mutual axis. ChrisL: It's not pegged at 0 it's pegged at some dark. ChrisL: Certain amount at the bottom for deeper blacks. ChrisL: Do need to cope with that. ChrisL: Wording about rendering intents. ChrisL: Black point compensation matches or not. ChrisL: With or without black compensation. ChrisL: In PS it will ask if you want black compensation. TabAtkins: Which do we want? cabanier: Turn it on. TabAtkins: ok. Done? cabanier: Color conversion engine can do it for you. cabanier: Same thing happens with whites. cabanier: White stays white. RESOLVED: Do black point compensation when converting from profile to another. smfr: For print also? ChrisL: Yeah. ChrisL: Doesn't affect p3, does affect 2020. TabAtkins: Can I reformat everything? ChrisL: Sure. Florian: The only thing we haven't agreed on is the working color profile? ChrisL: Right. leaverou: device-cmyk leaverou: Stylesheet was used for printing to ebook. leaverou: Using something similar to device-cmyk. leaverou: One problem is that you specify a device-cmyk color but you want... leaverou: it would be nice to specify which profile to use. TabAtkins: Use the color() function and the cmyk profile? leaverou: Want to use device-cmyk for print. TabAtkins: What's wrong with just defining the cmyk profile in color() instead of device-cmyk? leaverou: I thought we decided to keep device-cmyk? TabAtkins: Will fix by having a decent list of predefined profiles, one of those can be device-cmyk. TabAtkins: Falling back to something you have defined. ChrisL: Seems backwards. TabAtkins: If you have a correct profile for your output device... dbaron: Is the assumption is that only print uses device-cmyk? leaverou: Never want it for screen. leaverou: Not just about PDF. dbaron: Do you want a magic profile name for device-cmyk vs other. leaverou: Want to specify colors once. ChrisL: Want to see results from impl. Florian: The printer has everything it needs to do it right. TabAtkins: Use color(cmyk) will be good. leaverou: ok that works. TabAtkins: Get a good conversion instead of a naive. RESOLVED: If you accurately describe the output device's color profile in an @color-profile rule then a sane implementation will not alter your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically. TabAtkins: We can deprecate device-cmyk. *** Return to regular meeting minutes *** Summary of breakout sessions ---------------------------- Scribe: fantasai TabAtkins: Chris went over new features adding to color. TabAtkins: General agreement on all of them. TabAtkins: In particular lab() and clb() [mistyped]. TabAtkins: And new color() function. TabAtkins: Refers to arbitrary color profile. TabAtkins: Give it whatever parameters it expects. TabAtkins: Paired with that is @color-profile rule, which lets you refer to color profiles by URLs. TabAtkins: Will have a handful of predefined ones. TabAtkins: Since a lot of color profiles are quite small. TabAtkins: Decided to be liberal in predefining common Mac and Windows profiles. TabAtkins: For less URLs. TabAtkins: Wanted to make some changes around fallback. TabAtkins: And adding fallback things to color profiles. myles: What does UA do before downloading profile? ChrisL: Uses a fallback color. TabAtkins: We have 2 levels fallback. TabAtkins: @color-profile can list fallback profiles. TabAtkins: E.g. refer to AdobeSRGB, and fallback to regular sRGB. TabAtkins: Can also fallback explicitly for specific colors. Florian: If you did neither, it's invisible, becomes invisible. TabAtkins: Also discussed color-mod function. TabAtkins: Agreed to kill it in general, and then respec color blending / tint / and shade functions. TabAtkins: Because those are useful/simple that are highly requested by authors. fantasai: Did you talk about making a cut for Level 4 that's just the really basic simple things? TabAtkins: Did, plan to publish a new WD first to get an update, then make a cut. ChrisL: There was a lot of wording about rendering intent, decided not to do, but since we had the wording, better to publish with that wording and then remove it in the next publication. TabAtkins: At the end, casually decided to drop/punt APIs for parsing/manimpulating colors. TabAtkins: Going to explore in Houdini, if necessary. TabAtkins: This isn't the right spec for it. Florian: Also went through media queries, found spec as is to be adequate. TabAtkins: Wanted to make a clarification. TabAtkins: but agreed on resolution. Florian: Editorial. TabAtkins: I believe that's it. Florian: One thing we couldn't agree on. TabAtkins: Wanted to define a working color space for compositing. TabAtkins: But we couldn't agree on doing it right now because it's very expensive to composite. Florian: Could agree on the syntax for this, but not on the list of color spaces to allow. Florian: Some are expensive but good, others are cheap but wrong, others are not well-understood by people at the table at the moment. TabAtkins: Hallway conversation with Elliott, opacity is misplaced in this spec, better moved into either Filters or Compositing spec. ChrisL: Yes. leaverou: Yes. ChrisL: But also have alpha values. <bradk> waaaa? TabAtkins: Can just move it to V&U. Everybody: What? ChrisL: Putting in Compositing seems to make sense. TabAtkins: <alpha> being <number> | <percentage> where number 0..1 [fantasai summarizes resolutions from scroll-snap breakout] Grid ---- Scribes: gregwhitworth & tantek TabAtkins: First issue is the repeating syntax. TabAtkins: The grid auto rows only allow you to set one track worth. TabAtkins: Once you have subgrid you want to repeat on more than one track. TabAtkins: So the repeat will take a track list. TabAtkins: Auto is required, but maybe the repeat function should be changed. TabAtkins: Auto is actually required because you can't control the implicit grid. TabAtkins: Now that we have a reason to add back multi-track repetition into the repeat() function but subgrid brings that back. fantasai: Not for auto fill. fantasai: Subgrid is a compelling use-case (we didn't have one before). TabAtkins: It just repeats whole tracks, when you're dropping tracks from fill you drop whole tracklists. dholbert: These are two distinct changes. fantasai: Yes. astearns: Any objections? Rossen: We'll bring issues when we get more implementation experience, for now it seems reasonable. <tantek> When you're dropping tracks from fill, you drop whole repetitions etc. astearns: Any objection to adding multitrack repetition to accommodate subgrid use-cases? Rossen: We'll bring issues with more implementation experience. astreans: RESOLVED: add in multitrack repetition to accommodative subgrid use-case RESOLVED: Add allowing track list in repeat() and auto-rows fantasai: We prefer to just drop named lines specified on the subgrid because grid-template does not apply to simplified subgrid. fantasai: We are referring to dropping name lines specified on the subgrid. fantasai: Via grid-template-columns. fantasai: Via the old subgrid you could do that. fantasai: We're proposing to drop because it adds syntactic complexity. fantasai: Possibly can apply in the future in interesting ways. fantasai: Since we're not tackling that now, let's just remove that now. TabAtkins: Any objections? TabAtkins: Does anybody still want the ability to declare new named lines on subgrids? plinss: You can't create lines in a subgrid astearns: Seems fine to drop. RESOLVED: Drop named lines specified on the subgrid fantasai: Can we publish a new WD? RESOLVED: publish a new WD Flexbox ------- fantasai: One more thing, update flexbox CR fantasai: we would like to update the CR with the issues astearns: Any objections to publishing with edits? fantasai: We're asking for people to setup the relative telecons and do the whatever whatevers fantasai: Resolution to take to CR once we generate a new draft, and action chairs/staff to setup relevant telcons. TabAtkins: I expect next week to finish bikeshed integration for echidna TabAtkins: and I expect to finish up the something akin integration for pushbutton CR. Rossen: Have resolution now? fantasai: The disposition of comments is complete. TabAtkins: Flexbox CR draft is done and ready. astearns: Any objections to doing a new CR for flexbox? <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301 astearns: strategy, call for publications at the end of long days dbaron: lol RESOLVED Publish a new CR flexbox. dbaron: And try not to break the 86 day record for slowness. Inline ------ fantasai: CSS inline has had a few small changes from various F2Fs. fantasai: Since we're publishing stuff maybe we should publish and update to the inline spec. fantasai: Proposed publishing new draft of CSS inline. astearns: I'm sorry is this the fourth one more thing. <tantek> +1 <dauwhe> +1 astearns: I'm happy to, any objections? RESOLVED: Publish inline gregwhitworth: Done for the day - Thank you Google for hosting us!!!!!!
[css-grid] fr
Jens Oliver Meiert   Mon, 17 Oct 2016 22:27:34 +0200

www-style > October 2016 > 0095.html

Received on Monday, 17 October 2016 20:28:29 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Regarding the latest Grid Layout doc, https://www.w3.org/TR/2016/CR-css-grid-1-20160929/ – the spec uses “fr” units pretty early on (mostly “1fr” in the first examples) but only shares halfway down, that is, pretty late, what these stand for. I suggest we either link the first mention to respective section or explain the unit right after the first occurrence. -- Jens Oliver Meiert http://meiert.com/en/ ✎ The Little Book of Website Quality Control: http://meiert.com/quality
[CSSWG] Minutes San Fransisco F2F 2017-11-06 Part II: Backgrounds, Grid [css-backgrounds] [css-grid]
Dael Jackson   Mon, 4 Dec 2017 19:28:35 -0500

www-style > December 2017 > 0005.html

Received on Tuesday, 5 December 2017 00:29:35 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Backgrounds --------------- - RESOLVED: Text color has no effect on background-clip. - RESOLVED: text-decorations should be considered as part of the text shape for background-clip purposes. CSS Grid -------- - RESOLVED: Option D: percentage gaps in shrink-wrapped grids contribute 0 and layout as 0. (Issue #509: https://github.com/w3c/csswg-drafts/issues/509 ) - RESOLVED: Percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases. - The request for "Equal Gutters in both axes" feature (https://github.com/w3c/csswg-drafts/issues/1116 ) was presented and those interested continued talking over lunch. ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda Scribe: TabAtkins CSS Backgrounds =============== background-flip and text-underline ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/900 fremy: It seems we always consider underlines as part of the text shape. fremy: So for background-clip: text, you draw the background only under the text of the element. Intention is you set the text to transparent, so the background layer fills in for the text. fremy: In Firefox though, the color of the text doesn't matter for the shape, but the transparency of the underline is applied as an opacity on the background. fremy: So if people use color:transparent, the underline is too, and the background under the underline becomes transparent. fremy: I don't think this makes sense... Edge is not doing this. TabAtkins: This sounds like accidentally over-applying an opacity filter... fremy: I think it would be good to specify the behavior. smfr: Related, the fill and stroke module will someday handle this, right? Should we even specify this, given that it'll be replaced? (We need to spec this for Web-compat; it's going in an appendix.) TabAtkins: So back to François's point - settle that text color shouldn't have any effect on background fremy: And that text-decoration should be included as part of the text shape. RESOLVED: text color has no effect on background-clip. RESOLVED: text-decorations should be considered as part of the text shape for background-clip purposes. <AmeliaBR> I would definitely expect background-clip: text to include the underline area. Looks like browsers do that even when the underline is from a parent element: https://jsfiddle.net/yLwq77ss/2/ CSS Transform ============= Transforms 3d contexts ---------------------- github: https://github.com/w3c/csswg-drafts/issues/1944 trchen: In CSS, having a stacking context does not guarantee an element to be a containing block for every descendant element. trchen: And being a containing block doesn't imply being a stacking context. trchen: 3d context is a stacking concept - it decides which planes need to be 3d-sorted against each other trchen: But at the same time we define 3d context of elements based on containing block trchen: Causes "3d context penetration problem" trchen: Element can be flattened by another element that's not part of its containing block chain trchen: We're working on a project in Blink to simplify compositing code, found some ill-defined corner cases trchen: Planning to have a breakout session tomorrow afternoon? smfr: Would like to have a browser vendor rep from each for the breakout tomorrow. [discuss details of the breakout] CSS Grid ======== scribe: bkardell Percentages gaps and intrinsic size ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/509 <fantasai> all options for percentage gaps listed in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096 A = contribute back-computation ratio, resolve as percent B = contribute zero, resolve as percent C = contribute auto, resolve as percent D = contribute zero, resolve as zero E = contribute auto, resolve as auto F = contribute zero, resolve as percent (for column-gap) or zero (for row-gap) fantasai: I think we agreed to eliminate C and E. lajava: We have two different issues lajava: We have undefined width and height lajava: The issue we are discussing now is for grid gaps lajava: fantasai listed different options after some discussion lajava: Our discussion from blink/webkit: we prefer to keep existing behavior: keep treating them as 0 for intrinsic size/layout (i.e. lajava is requesting option F) lajava: In the issue there is an explanation lajava: We think that what happens in Firefox is broken with that approach lajava: If we don't do that for margins, we should be consistent lajava: We have to decide from the options fantasai listed and agree to do it the same fantasai: My concern with f) in that list is that it has been a goal of grid to have symmetric behavior in both axis lajava: Related to that, we think there are issues to do that with tracks as well lajava: It's not impossible, but there is no browser doing that lajava: All of the browsers consider cols and rows differently lajava: so I'm not sure that should be important in solving for gaps - perhaps we decide not to do it for the tracks rachelandrew: There are issues teaching this to authors. Generally people understand when you say this will resolve to 0, the goal of having symmetrical gaps would be nice. rachelandrew: If we can't have them symmetrical, having the rows go to 0 makes sense. lajava: I agree with that dholbert: Are we just talking about intrinsically resized grids lajava: d) tries to resolve the same way in both axis rachelandrew: If we didn't have percentage gaps, if we changed existing behavior ...? <astearns> so rachelandrew is for F, not D jensimmons: If you had that situation in the inline direction where you didn't have an explicit width those gaps would also resolve to 0, it's just not a common use case jensimmons: If you said you want this to be 100x100px - in both directions the gap would be 10 jennsimmons: I don't know if what you are describing is that the algorithm is doing the math diff? Scribe: frremy lajava: There are two reasons we don't want back compute for the gaps lajava: Backcomputing when the percentages are close or bigger than 100% the solution isn't that great lajava: The second reason is that we decided not to do that for margins, and so we would like to work the same for gaps dholbert: Well, on that, I think margins are just a legacy thing TabAtkins: I would be opposed to anything that could yield to sizes bigger than the max size a browser can allocate TabAtkins: It's very easy to end up in such cases with back-computing Rossen: +1 Rossen: For this issue, the currently listed options are on the screen, and the github <frremy> Igalia would prefer B, D, or F lajava: Yes Rossen: Edge's preference would be to keep symmetry Rossen: If resolving in one of the pass is not possible, though, resolving to zero as usual is fine Rossen: F is therefore not a great solution Rossen: Between B and D, I would like to hear more opinions TabAtkins: B is expensive, there might be fragmentation issues Rossen: Which fragmentation issue? TabAtkins: Could contribute, but we could discuss this later when this comes up dholbert: What would happen for auto grid with percent columns? Rossen: Let's say you have a 2x2 grid that has to shrink in both dimensions <gregwhitworth> here's the example Rossen is stating: http://jsbin.com/lalayakuxe/1/edit?html,css,output Rossen: If that grid had a size, we would compute properly and things would be symmetric Rossen: but if the grid is floated, we will have to compute percentages has zero to find the size of the float Rossen: but in the second pass, we are given a choice Rossen: Either add the gaps and overflow slightly Rossen: or you can continue to resolve to zero Rossen: This is the difference between B and D lajava: Igalia doesn't mind B but the problem is that if you are auto and overflow by default, that seems counter-intuitive Rossen: The only con of D seems that some authors could be unhappy about this Rossen: but I would like to make sure that is really the case Rossen: because authors can still use other units, or give a specified size to the grid. fantasai: (reading a summary of the A-F proposals) <fantasai> A = contribute back-computation ratio, resolve as percent <fantasai> B = contribute zero, resolve as percent <fantasai> NOT C = contribute auto, resolve as percent <fantasai> D = contribute zero, resolve as zero <fantasai> NOT E = contribute auto, resolve as auto <fantasai> F = contribute zero, resolve cols as percent & rows as zero <fantasai> NOTE: only for intrinsically-sized grids explicit / stretch-fit grids always resolve <fantasai> Cons: <fantasai> A = contribution can explode grid <fantasai> B = unhappy authors with overflowing grids <fantasai> C = super broken <fantasai> D = unhappy authors missing % column-gap? <fantasai> E = even more broken <fantasai> F = B + D + asymmetrical [Rossen + florian discussing why A cannot be fixed (aka, see previous times this was discussed)] jensimmons: Using percentages for gaps for auto-sized things is not great jensimmons: because they will see their gap change size when the content changes jensimmons: so they will realize this is not what they wanted fantasai: Yeah, I can see that happening, I'm getting convinced by D too now Rossen: Proposed resolution: gaps expressed in percentages resolved and layout-ed as 0 in auto-sized directions rachelandrew: There might be a few people that are going to hit this problem if they try to replace parts of an existing layout they cannot entirely control. fantasai: But this would apply to cases where the grid is shrinkwrapped, not to cases that have a definite containing block rachelandrew: Yes, but I don't know how common that would be iank: We are at 0.1% of all pages for grid all up iank: so I guess this case wouldn't be frequent at all once you consider it has to be also using percentage gaps, in a shrink-wrapped context Rossen: But the conversation is about porting content that currently uses percentages to grids Rossen: though I don't really see how they can achieve this today in a way that works in all browsers jensimmons: I think those cases are very fragile currently, they use margins/paddings on floats jensimmons: but in those cases usually, the container has a width, even if it is 100% rachelandrew: (general feeling of doubt, but I didn't catch the exact words) dholbert: So this would only happen about floated grids, and abspos grids dholbert: but in a flexbox, you are suppose to layout as having a definite size after flexing, so percentages would work there right? TabAtkins: Correct. [rachelandrew & jensimmons talking about author's work to port existing things, ex: new york times shipping grid inside bootstraps] Rossen: So, would your doubts be enough to raise an exception today? rachelandrew: No, I just wanted to shed some light on this, we can come back on this if needed Rossen: Any objection? RESOLVED: Option D: percentage gaps in shrink-wrapped grids contribute 0 and layout as 0. Percentage tracks ----------------- github: https://github.com/w3c/csswg-drafts/issues/1921 lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows lajava: But we don't have min-content phase in the block direction, like we do for width lajava: So we would need to duplicate a second pass to make this work. lajava: So 1st we would like this recorded clearly in the spec if that is required lajava: And all browsers would have to change their implementation. florian: And why not just follow what browsers already have implemented? Rossen: The change would be relatively straightforward, it's no big deal. florian: But we would possibly break content, right? Rossen: Everything we do ends up breaking someone's content, I don't think this would be an issue here. lajava: Well, we are still unsure about what would happen in more complex cases like in orthogonal flows lajava: but at the very least it would require a second pass, once you know the intrinsic height. Rossen: Any opinion from Mozilla? Rossen: There is still time to fix, but window is closing. dholbert: I don't have a strong opinion, and Mats hasn't commented on the issue. dholbert: I don't like adding new layout steps usually. Rossen: But it's easy to know if you need to do it beforehand Rossen: only do it if you have percentage-sized row tracks. dholbert: But if it is an orthogonal flow, you have to re-layout entirely right? lajava: Yes, but this already happens anyway. Rossen: Any objection? RESOLVED: Percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases. "Equal Gutter" with justify-content ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1116 Request is for next level... fantasai: Users often want row-gaps and col-gaps to be equal fantasai: but they also want the horizontal gaps to fill the remaining space once you've put as many columns as possible in the width direction. fantasai: They can do that using justify-content fantasai: but they cannot transfer this size in the other direction. fantasai: This is basically a request for thoughts on the topic. <fantasai> https://github.com/w3c/csswg-drafts/issues/1116#issuecomment-288472394 <fantasai> Just to summarize, the example is <fantasai> definite width, auto height grid container <fantasai> auto-fill columns e.g. 100px <fantasai> auto-placed items <fantasai> place-content: space-between <fantasai> The spacing produced by space-between is not equal in both axes. jensimmons: So is the idea { row-gap: as-column-gap } ? TabAtkins: Pretty much. <leaverou> Possibly silly idea, but what if there was a unit for horizontal gap? Are fractions of that useful or only the whole horizontal gap? <TabAtkins> So far the only request is matching, but if fractions are desired later, our eventual solution for "put keywords in calc()" will handle that. (general discussion, but it was tough to minute) fantasai: The tricky thing is that two things control the gap size. fantasai: The gap property fantasai: and the alignment properties fantasai: you do have to consider both to get the desired effect fantasai: and there are interesting cases of space-evenly which creates a gap before the first column and after the last column, we will need to define what to do about that. <fantasai> the gap properties only distribute space between the columns, but alignment can do other things florian: And the proposed syntax would allow to also define alignment in the direction in which you said to copy. florian: I think we should have a more restrictive syntax that doesn't allow the impossible cases would be better florian: but I don't have a concrete proposal right now. jensimmons: Just to clarify, the alignment do not update the gap, they add a gutter right? fantasai: Yes, but visually it looks like the same thing. jensimmons: So it looks like we want something to transfer the gutter not the gap. dholbert: Maybe some align: symmetrical then? dholbert: Alignment properties already are allowed to increase a gap. dholbert: It would be possible to also shrink the gap to make it match, that doesn't sound unreasonable. <dholbert> Or possibly not shrink, but grow-or-leave-the-same (to avoid) <dholbert> *(to avoid violating author expectations that "grid-row-gap: 100px" should actually insert at least 100px of space) Rossen: Alright, I think we should probably break out to lunch, and have people interested in this proposal talk with each other. Rossen: Let's get back here at 1:30 <br type=lunch>