- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 12:53:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `grid-gap`, and agreed to the following resolutions: * `RESOLVED: add gap shorthand` * `RESOLVED: Tables are not changed` * `RESOLVED: Add gap properties to align spec` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: grid-gap<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1696<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1036<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1036<br> <dauwhe> TabAtkins: we decided that grid gutter should be reset by shorthand<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <dauwhe> ... authors have given feedback that the opposite is true<br> <dauwhe> ... so are annoyed to reestablish their gutters<br> <dauwhe> ... so we propose to change that, and stop resetting gutters in shorthand<br> <dauwhe> fantasai: that's the basis of that<br> <dauwhe> ... the other issue is 1969<br> <dauwhe> s/1969/1696/<br> <dauwhe> TabAtkins: the grip prop is already complex<br> <dauwhe> ... worst case is having some gutters you didn't intend<br> <dauwhe> ... a proposal to handle this and other author feedback is to rework how we handle gutters<br> <dauwhe> ... rename them and apply them to all layout modes where it makes sense<br> <dauwhe> fantasai: we had originally designed them for multicol<br> <dauwhe> TabAtkins: didn't make sense for column gap to be reset by grid<br> <dauwhe> fantasai: so we undo the link, undo grid prefix<br> <dauwhe> ... make colgap and rowgap apply to flex containers<br> <dauwhe> ... this is highly desired<br> <dauwhe> TabAtkins: they want min spacing between flex items and flex lines,<br> <dauwhe> fantasai: one comment is can we have one set of properties to make it easy to learn<br> <dauwhe> astearns: is it hard to change flex distro algo?<br> <dauwhe> TabAtkins: it's easy<br> <dauwhe> fantasai: as a last point, nice to obsolete border-spacing<br> <dauwhe> ... controls spaces between cells, and it inherits<br> <dauwhe> TabAtkins: it's the only layout property that inherits<br> <dauwhe> fantasai: if we could redesign, it wouldn't inherit, and would be logical<br> <dauwhe> TabAtkins: normal would be zero by default, in grid and flex, and 1em in multicol<br> <astearns> q?<br> <dauwhe> ... because all the gridgap stuff has shipped, so we have to keep<br> <Rossen> the gap property is coming! https://lemontree.se/wp-content/uploads/2014/10/titles-Mind-the-Gap-Large.jpg<br> <dauwhe> ... only thing we break will be grid gap reset<br> <dauwhe> fantasai: we need shorthand for column gap and grid gap<br> <dauwhe> Florian_: column-gap would be shorthand for grid-column-gap etc<br> <dauwhe> fantasai: none of them inherit<br> <dauwhe> bdc: there's a proposal for a new gap shorthand?<br> <dauwhe> fantasai: the proposal is to alias grid-row-gap<br> <dauwhe> astearns: it's not temporary<br> <dauwhe> fantasai: it might be permanent<br> <dauwhe> ... the goal is to use column-gap and row-gap, and have a shorthand for the two of them<br> <dauwhe> fremy: track-gap<br> <dauwhe> fantasai: people are using shorthand more often<br> <dauwhe> ... we'll have to run some data, but we might be able to remove the longhands<br> <dauwhe> TabAtkins: one less alias to maintain<br> <dauwhe> Florian_: weird to use grid stuff to reset your flex<br> <dauwhe> SimonSapin: they would be aliases?<br> <dauwhe> TabAtkins: one is shorthand of the other<br> <dauwhe> fantasai: page-break properties are shorthands of the break-* properties<br> <dauwhe> SimonSapin: so these would be shorthands with one longhand each<br> <dauwhe> TabAtkins: they'd both access the same underlying value<br> <dauwhe> SimonSapin: what happens in CSSOM?<br> <fantasai> SimonSapin, https://www.w3.org/TR/css-break-3/#page-break-properties<br> <dauwhe> astearns: sounds like there are 3 things<br> <dauwhe> ... 1 changing what's set by grid shorthand<br> <dauwhe> ... 2 adding connection between the various gaps<br> <dauwhe> ... 3 is some shorthand for all this<br> <dauwhe> TabAtkins: 4 doing table cleanup<br> <dauwhe> ... but it would be nice to have everything use same gaps<br> <dauwhe> astearns: are there any objections to changoing grid shorthand to not reset column and row gaps?<br> <dauwhe> Resolved: change what grid shorthand resets<br> <dauwhe> dbaron: who will be first to implement?<br> <dauwhe> Rossen: we'll do it<br> <dauwhe> bdc: might not break anything<br> <dauwhe> astearns: will only change behaviour if they set gaps, used shorthand, etc<br> <dauwhe> rachelandrew: most people are not using shorthands<br> <dauwhe> plinss: they do whatever you tell them to :)<br> <dauwhe> astearns: so edge is willing to go first?<br> <fantasai> s/whatever/pretty much whatever/<br> <dauwhe> ... we're yet to release the updated grid<br> <fantasai> s/them to/them to do at this point/<br> <dauwhe> Rossen: I wish we didn't have to do the aliases<br> <dauwhe> astearns: the second thing: any more discussion on column-gap and row-gap applying to all layout modes with gaps?<br> <dauwhe> astearns: there will be a communication issue<br> <dauwhe> iank_: which layout modes?<br> <dauwhe> TabAtkins: multicol, grid, flex, and maybe table<br> <dauwhe> fantasai: multi-col, grid, and flex all respond to the column-gap and row-gap properties<br> <dauwhe> dbaron: which property has the normal value?<br> <dauwhe> TabAtkins: column-gap and row-gap<br> <dauwhe> ... for multicol it will be 1em, which is no change<br> <dauwhe> astearns: what does column-gap normal due in grid and flex?<br> <dauwhe> TabAtkins: Zero<br> <dauwhe> s/due/do/<br> <dauwhe> dbaron: column-gap already has a normal value<br> <dauwhe> astearns: we're adding normal to row-gap<br> <dauwhe> dbaron: this is renaming thing for grid back to the old multicol things<br> <dauwhe> TabAtkins: yes<br> <dauwhe> dbaron: same syntax?<br> <dauwhe> TabAtkins: yep<br> <dauwhe> ... adding normal keyword to row-gap<br> <dauwhe> fremy: do we need grid-row-gap and grid-column-gap<br> <dauwhe> ... they are not interoperable<br> <dauwhe> TabAtkins: why<br> <dauwhe> fremy: in the sense that lots of browsers don't support grid<br> <dauwhe> ... so there are not a lot of websites that use grid, and they were made in the last six months<br> <dauwhe> TabAtkins: maybe,<br> <dauwhe> fremy: to me this is a breaking change<br> <dauwhe> TabAtkins: if they are using grid-column-gap etc it will break things<br> <dauwhe> ... we need to look into how often they are use<br> <dauwhe> ... default to safe answer of aliasing them<br> <dauwhe> Rossen: can we resolve?<br> <dauwhe> astearns: any other comments on using these in grid, flex, and multicol<br> <fantasai> I agree with Tab, let's keep the aliases for now but look into dropping them<br> <dauwhe> dbaron: this is new feature for flex?<br> <dauwhe> TabAtkins: this is the most requested feature for flex<br> <dauwhe> bdc: the gap shorthand property is part of this resolution?<br> <dauwhe> astearns: we will have a shorthand, we're just not sure what it's called<br> <dauwhe> fantasai: we don't have to figure it out now. one thing at a time<br> <dauwhe> fantasai: proposed resolution; existing column-gap and new row-gap with same syntax apply to flex, grid, and multicol, and alias to current props<br> <dauwhe> dbaron: is handling of percentagges between the two consistent?<br> <dauwhe> Florian_: multicol didn't have percentage until recently<br> <dauwhe> ... not implemented yet<br> <dauwhe> ... spec says % should work in multicol<br> <dauwhe> TabAtkins: the definitions are identical<br> <dauwhe> astearns: no concern?<br> <dauwhe> TabAtkins: they're the same<br> <dauwhe> astearns: any objection?<br> <dauwhe> Resolved: column-gap and row-gap apply to flex, grid, and multicol<br> <dauwhe> bdc: we could use gap as the shorthand<br> <dauwhe> TabAtkins: do we have three letter properties?<br> <dauwhe> astearns: options for shorthand are "gap" or pre=existing "grid-gap"<br> <dbaron> the only 3-letter properties in Gecko are 'top' and 'all'. A whole bunch of 4-letter ones, though...<br> <dauwhe> astearns: we have to maintain grid-gap as shorthand, but that could be a discoverability problem<br> <Rossen> https://lemontree.se/wp-content/uploads/2014/10/titles-Mind-the-Gap-Large.jpg<br> <dauwhe> astearns: the proposal is to add a shorthand for column-gap and row-gap that is just gap and aliased to grid-gap<br> <dauwhe> fremy: I don't know if we have a shorthand aliased to a shorthand<br> <glazou> LOL<br> <dauwhe> myles: the question isn't that you have it, it's that you can do it :)<br> <fantasai> s/Resolved/RESOLVED/<br> <dauwhe> astearns: any objection?<br> <dauwhe> fantasai: I think it's unnecessary aliasing, but I won't object<br> <dauwhe> Rossen: there's probably not a ton of content out there,<br> <dauwhe> ... I would prefer not to ship grid-gap at all<br> <dauwhe> ... I don't mind aliasing the grid ones for a while<br> <dauwhe> ... given this is six months of a feature, I'd be surprised if we couldn't do this<br> <dauwhe> rachelandrew: I'll update all my stuff. I've already tweeted :)<br> <dauwhe> fantasai: rachel and Jen can get the information out there<br> <dauwhe> ... but they can't create a forcing function for people who've already been trained<br> <dauwhe> ... but microsoft can do this<br> <dauwhe> Rossen: that means interop pain for us<br> <dauwhe> fremy: I'd rather not write a bunch of aliasing code that we're going to remove in six months<br> <dauwhe> fantasai: it's not going to be difficult for you, it will be difficult for authors<br> <fantasai> s/difficult/annoying/<br> <dauwhe> Rossen: I don' think this is a q of implementaiton<br> <fantasai> s/authors/authors during the transition/<br> <dauwhe> ... we'll decide about aliases internally<br> <fantasai> s/microsoft can do this/microsoft can do this by not shipping grid-*-gap/<br> <dauwhe> ... I won't promise we'll ship without grid-column-gap etc, but<br> <dauwhe> astearns: the hope is that we're early enough that we can eventually remove<br> <dauwhe> Rossen: we'll ship very soon<br> <dauwhe> Florian_: grid is unusual in that most browsers shipped in a very short time<br> <dauwhe> ... even though it's only six months, but a lot happened in those six months<br> <Rossen> s/we'll ship very soon/when we ship/<br> <dauwhe> iank_: the main compat risk is chrome mobile(???)<br> <fantasai> TabAtkins, can you run a search on occurrances of grid-row-gap and grid-column-gap?<br> <dauwhe> astearns: proposed resolution: add gap shorthand<br> <TabAtkins> fantasai, probably<br> <dauwhe> RESOLVED: add gap shorthand<br> <dauwhe> astearns: do we want to talk about tables?<br> <dauwhe> fantasai: we have a solid proposal<br> <dauwhe> TabAtkins: a single convenient interface to everything that can have gaps<br> <dauwhe> dbaron: the weird thing about border space being inherited<br> <dauwhe> ... applies only to table with border-collapse : separate<br> <dauwhe> ... border-collapse is inherited<br> <dauwhe> ... most tables will be separated<br> <dauwhe> fantasai: unless you are setting column-gap or row-gap on a table already, then there's no effect<br> <dauwhe> ... the new propoerties don't inherit<br> <dauwhe> dbaron: if applies to table, then will apply to sides of columns, and row gaps apply to tops/bottoms<br> <dauwhe> fantasai: we're not saying border-spacing reads out from column-gap<br> <dauwhe> ... if the value of column-gap is normal, then look at border-spacing prop<br> <dauwhe> dbaron: that would be weird if it applied inside, but not around edge<br> <dauwhe> ... the full value plus padding on table element<br> <dauwhe> fantasai: actions are to have these acts to apply only to the interior<br> <dauwhe> dbaron: I think that's a bad idea<br> <dauwhe> TabAtkins: either don't apply at all, or affect outside?<br> <dauwhe> fantasai: this is low-priority<br> <dauwhe> TabAtkins: it applys to every table<br> <dauwhe> astearns: one solution is to not change tables<br> <dauwhe> ... that's my general rule: don't mess with tables<br> <dauwhe> fantasai: fallback issue<br> <dauwhe> ... table displays are used for fallback in flex/grid<br> <dauwhe> ... since it acts similarly<br> <dauwhe> ... we will have authors using flex or grid model with these gap properties<br> <gregwhitworth> q+<br> <dauwhe> ... in implementations that don't support them, they will fall back to table<br> <dauwhe> ... but they don't support new gap properties<br> <dauwhe> gregwhitworth: so it won't matter<br> <dauwhe> iank_: I find this strange because we're not messing with table<br> <dauwhe> s<br> <gregwhitworth> ack gregwhitworth<br> <dauwhe> astearns: proposed resolution: don't have the new gap properties apply to tables<br> <dauwhe> TabAtkins: where do these properties go<br> <dauwhe> RESOLVED: Tables are not changed<br> <dauwhe> TabAtkins: align is the best place<br> <dauwhe> ... it only applies to things taht are content-distributed<br> <dauwhe> ... grid and flex will have sections pointing to this<br> <dauwhe> astearns: and multicol<br> <dauwhe> rachelandrew: same as any of the align stuff<br> <dauwhe> Florian_: we need to fix grid, but just add it to other spec<br> <dauwhe> TabAtkins: we need a section in grid<br> <dauwhe> Florian_: in flex maybe not<br> <dauwhe> astearns: nothing to correct in flex, just informative<br> <dauwhe> RESOLVED: Add gap properties to align spec<br> <dauwhe> Rossen: how far along is this spec?<br> <dauwhe> fantasai: trying to get to cr<br> <dauwhe> astearns: I think we're done with gaps for now!<br> <dauwhe> ... are there other grid issues?<br> <dauwhe> Rossen: Do we want to go over many of them?<br> <dauwhe> ... we don't have to discuss all of them now<br> <dauwhe> astearns: keep remaining grid discussion to 30 minutes<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1320<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1319<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1036#issuecomment-320241018 using your GitHub account
Received on Friday, 4 August 2017 12:53:19 UTC