- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Apr 2016 21:01:33 -0400
- 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.
=========================================
'Order' on abspos
-----------------
- RESOLVED: Remove order-based reordering of abspos flex
children. For painting purposes they're treated as
having an order of 0.
Grid
----
- fantasai and TabAtkins had re-discussed the grid-template
shorthand which was removed in February and decided it was
still needed.
- There was some pushback, but a straw poll was taken and most
of the group either wanted the shorthand back in or
abstained.
- RESOLVED: Add grid-template back in.
- RESOLVED: Accept 'grid' shorthand improvements here:
https://lists.w3.org/Archives/Public/www-style/2016Apr/0249.html
- RESOLVED: Must allow fragmentation in columns if that instead of
rows is the fragmentation direction.
- RESOLVED: Change fr to invalid as the min in minmax() and add a
note we'd like to add it back at some point in the
future.
- RESOLVED: Add <percentage> to grid-gap
- RESOLVED: Mark the above as at-risk
- As there have been a lot of changes, fantasai plans to ask for
another publication shortly after she edits all the
resolutions in.
Agenda items for F2F
--------------------
- Please add any topics to the wiki
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0323.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Jihye Hong
Dael Jackson
Ian Kilpatrick
Peter Linss
Myles Maxfield
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Tony Graham
Daniel Glazman
Brad Kemper
Michael Miller
Edward O'Connor
Hiroshi Sakakibara
Geoffrey Sneddon
'order' on abspos
=================
astearns: Let's get started
astearns: It looks like a light agenda. Anything to add?
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0186.html
fantasai: Basically we had defined order applies to any abspos
children of a flex container. THeir direct parent is a
flex container. Spec says you use order and re-order all
children including abspos before painting or anything
like that.
fantasai: TabAtkins and I wrote tests and found no one does this.
It's not an important feature, it came out of the way we
wrote the spec. We're proposing to change the spec so re-
ordering isn't on abspos items. This is for flexbox and
grid. I think Matt P. did this for grid, but not flex.
fantasai: Only effect is it changes the z-order so it didn't seem
like we should take the effort to make it work.
astearns: It seems odd to have order be a synonym for z-order.
Rossen: Time past it did make sense was when computing the static
position based on the position. I too agree that we should
get rid of it and it will just confuse people.
astearns: Other opinions?
astearns: Does anyone oppose taking this out of the spec?
RESOLVED: Remove order-based reordering of abspos flex children.
For painting purposes they're treated as having an order
of 0.
Grid
====
grid-template shorthand (Issue #30)
-----------------------------------
<astearns> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-30
fantasai: Eric Meyer had posted to the list suggesting removing
grid-template wasn't always useful. TabAtkins and I
discussed and we discussed on the call. After thinking
more we think we should restore the shorthand.
Florian: Can you give a bit of the rationale to change?
fantasai: Is TabAtkins on?
<TabAtkins> one sec
fantasai: I know in Eric's case resetting at the top level made
sense and using the grid-template in several rules that
were cascaded separately. He just wanted to set the
template and nothing else. For example you might have MQ
set up and you have 3 grids depending on the MQ, but you
want auto-fill and grid-gap the same so you set those at
the top level. Grid-template doesn't reset those, it
would just do the layout of the grid.
fantasai: That's the use case and it seems reasonable.
Rossen: We discussed it last time...
fantasai: We decided we didn't have a strong position either way
and asked for more author feedback.
Rossen: What was it?
fantasai: I think one or two people wanted it back, but I didn't
get anything strongly.
Rossen: And our position was unless there's strong demand why add
it? And it doesn't sound like strong demand. Adding it
back doesn't sound like a strong request.
astearns: What we concluded before is you could accomplish the use
case using grid-rows and -columns. Is it a case of using
one property vs two?
fantasai: If you're using the template it becomes more compelling
to use the shorthand. If you're using named areas you
want to be able to use the template shorthands.
Rossen: I'm still of the opinion that I would rather work on the
shorthand.
fantasai: We're doing that too. That won't address this issue.
Rossen: Again, to me this sounds like a small habit complaint that
doesn't have strong support. Two other people doesn't
suggest huge demand. It's more than 0, but not strong.
astearns: Given that we're sampling in a short time and few
people, a couple is significant.
Rossen: Eeeh...okay.
<tantek> I would tend to trust Eric Meyer's judgment and input on
this if it doesn't present undue burden on implementers (
which I haven't heard of any yet).
astearns: TabAtkins give us your rationale.
TabAtkins: Looking closer into the use case, the things you can
only do in the grid template, the full ascii is
reasonable to read, it's frustrating it wipes out your
auto. There's no short hand for the autos.
TabAtkins: If you want to...you can only use it by variant. If you
want to short hand for one side you have to long hand
on the other. Being able to use each shorthand on the
same elements seems worthwhile.
astearns: Have you posted examples of what you would have to do
without the shorthand?
TabAtkins: Eric Meyer did.
fantasai: His didn't include template.
astearns: I don't see the auto interaction you talked about.
TabAtkins: Let me find his.
<TabAtkins> https://lists.w3.org/Archives/Public/www-style/2016Mar/0345.html
TabAtkins: In his original e-mail he is using the grid-template
shorthand on gallery 1 and 2 to give slightly different
style, but they have the same auto stuff. He's using
the long hands to set up the grid autos. It's slightly
different, but same area. He wants to set everything
once for the template shorthand and he can't on the per
element basis because he'll wipe out the auto stuff.
TabAtkins: When he had grid-template he didn't worry about how
much it resets.
fremy: I don't see a use case to use the ascii [missed] I think
it's not the whole template. Why would you want both at the
same time?
TabAtkins: Even rows and columns together is the convenience we
expect of shorthands. We don't only give the long hands.
Being unable to set the template together without
wiping out auto is frustrating.
TabAtkins: If you have a situation like this where you set grid
and have shared properties, you must do them all as
longhands. You can only use the shorthand if you set
them as the same rule. Shorthand resetting is useful,
but slightly hostile as the occasional complaint has
shown.
Rossen: I agree the grid shorthand is complex. At the same time I
don't see why we would give up on making it ergonomic and
having smarter resets so both can be achieved.
TabAtkins: That doesn't address what I was saying. The grid
shorthand resets 6 properties and can only set 3 at the
same time. If we can make that 6 it's somewhat useful,
but there's a problem where you can use the 6 longhands
separately or the single shorthand.
TabAtkins: The analogy is if the border property only came in full
longhand or border shorthand and there weren't border-
left type shorthands.
TabAtkins: That's the situation we have with grid. That's
resetting more than needed.
Florian: It's not just the amount of properties, but that the
grid-template shorthand does multiple properties at the
same time and with a syntax found nowhere else. It's that
syntax people are looking for. If it was setting the
multiple by having in one property a copy of the syntax,
there wouldn't be much value. Since you don't have that
it's useful.
Rossen: If we didn't add the grid-template now and postpone until
necessary...I would really prefer to focus on the grid
shorthand and solve it there.
TabAtkins/fantasai: It's a separate issue.
fantasai: Another thing is we had this shorthand, grid-template,
until February. We said it wasn't particularly useful,
let's drop it to avoid confusion. Since we have reasons
to go the other direction we should revert.
Rossen: Removing is harder than adding. We've been liberal with
adding things.
fantasai: It's a short hand. Shorthands aren't a lot to add.
Rossen: It's an obstruction so it's more complex.
Rossen: I've stated my reasons, we can put it to the group and go
from there.
astearns: Other opinions?
<tantek> can we just take a straw poll?
<tantek> I think we've spent enough time with numerous arguments
Rossen: We can straw poll
astearns: We can. I'm not a big fan because it's always who is on
the call and people not on the call want to be heard.
Florian: It can say if it's Rossen vs. everyone.
astearns: Okay. I suggest everyone on IRC type in add or remove.
Straw Poll:
<fantasai> add
<Florian> add
<TabAtkins> add
<jensimmons> I think we should add the shorthands back.
<astearns> add
<plinss> add
<tantek> add
<fremy> remove
<Rossen> remove
<jihye> add
<Bert> I can't decide...
<smfr> abstain
<dbaron> abstain
<leaverou> add
<alex_antennahouse> abstain
<myles> abstain
<gregwhitworth> abstain
<ChrisL> abstain
<SteveZ> do not care
<dauwhe> abstain
<bcampbell> abstain
astearns: Strawpoll looks slightly more interest to add it in.
<tantek> (only two removes :P)
<tantek> (way more than "slightly")
fantasai: All the authors
astearns: I suggest to add and work with implementors to see who
is willing to implement and get more author opinions and
use influence to get it back in. I don't know if there's
enough for a full WG resolution.
TabAtkins: That's fine.
* tantek requests a count, since it's voting season and all
<jensimmons> 9 adds
astearns: 8 adds, 2 removes, a lot of abstentions.
fantasai: 9 adds
<tantek> I see 8 abstains, 1 can't decide, 1 do not care
fantasai: I think that's adding back since our goal is for author
feedback and all authors are for adding.
<fremy> what do you consider an author?
<fremy> fantasai ^
<fantasai> jensimmons and leaverou count as authors. Eric Meyer
also, via ML
astearns: Yep. I think the way forward is to add.
astearns: Do we need a resolution?
TabAtkins: We had one to remove.
RESOLVED: Add grid-template back in.
fantasai: As an editor it is more helpful to be clear on decisions
rather than discuss and not have a resolution. The more
clear recording of resolutions the easier it is to have
it.
astearns: This is a resolution to undo the previous resolution.
I'm not sure what value the previous resolution has. In
my mind that calls into question this resolution. In any
case, we should move on.
<tantek> astearns++ for bring this to as much of a conclusion as
we can now
Improving 'grid' shorthand
--------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0249.html
fantasai: There was positive from fremy on the ML with no other
responses. We'd like to make these changes and take a
resolution.
astearns: Opinions?
astearns: Objections?
RESOLVED: Accept 'grid' shorthand improvements here:
https://lists.w3.org/Archives/Public/www-style/2016Apr/0249.html
Fragmenting between columns
---------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0191.html
fantasai: We allow implementations to fragment between multi-column.
I added that you may fragment between columns. I don't
think it is required, but they should be allowed to if
they're in the correct axis.
Florian: Why not a 'must'?
fantasai: Grid layout is complicated when there's interactions
between columns. It's harder than fragmenting between
columns. I'd like to allow implementors to do this, but
I don't want to require because I doubt we'll get the
implementations.
Rossen: When talking about fragmenting between columns, is that
the content inside the column, or pushing columns to next
fragment?
fantasai: When you have a multi-column vertical...it's about
orthogonal flows. If you have an orthogonal flow with
multi-column vertical inside a horizontal.
Rossen: You're saying the direction of fragmentation is the same
as column progression. In which case it makes sense. If
you add this to grid which is 2d it would be confusing. It
would suggest we're going to fragment in both directions
between rows and columns.
Florian: You're doing it in either not both because orthogonal is
1d.
Rossen: As long as the new suggestion is clear this is only in the
main fragmentation direction it's fine. Otherwise it
suggests a fairly complex feature.
fantasai: Yeah, yeah. It would be allow fragmenting in columns if
that instead of rows is the fragmentation direction.
Rossen: Okay. That wasn't clear.
fantasai: I'll make that clear. That's useful feedback.
astearns: Is the fragmenting between rows optional?
Rossen: If your main direction is a column.
astearns: I'm asking to tease out why this fragmenting between
columns is optional if rows isn't. The complexity
applies to both.
fantasai: We need to be able to fragment grids. This is only in
the case where a grid is in an orthogonal flow which is
a tricky case to land in. I'm not sure on implementation
complexity. It may be the same, but it may not be. If
implementors can do it, great. If not it's not critical
to handle. The grid in orthogonal is not super common.
Fragmenting rows is standard case.
Florian: I'd prefer a 'should' because 'may' indicates it's fine
either way. Or a 'must' and mark as at-risk.
Rossen: Let's start with the 'should'
astearns: I'd prefer start with 'must' and drop to 'should'.
Having inconsistencies in this case doesn't seem a good
idea.
<ChrisL> I agree, start with must an see it it gets implemented
Florian: If it's hard to implement and people don't care they
won't implement. I don't want to suggest to
implementation and even if this is easy they don't do it.
ChrisL: I agree.
tantek: yes.
astearns: Proposed resolution: Must allow fragmentation in columns
if that instead of rows is the fragmentation direction.
RESOLVED: Must allow fragmentation in columns if that instead of
rows is the fragmentation direction.
fr units are stupid as min of minmax()
--------------------------------------
<fantasai> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-40
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0197.html
fantasai: If they're in the min for minmax() they get treated as 0.
The example Eric M posted was:
<fantasai> grid-template-columns: 100px minmax(3fr, 300px) 1fr
100px;
fantasai: He expects you would get 3fr columns until the width for
fr hits 300px and it maxes. That seems reasonable. But
because how the grid algorithm works the first is a 0.
You end up with something unexpected.
fantasai: We could try and fix it in the algorithm. We're a bit
afraid to do it, but will if the WG wants. It would
involve another step. If we don't fix the algorithm we
should make fr invalid in the min position and fix the
algorithm at some point in the future.
fantasai: Options 1: figure out how to make work as expect, 2:
make fr invalid and fix in the future 3: keep treating
it as 0
Florian: If the syntax is something authors could reasonably
expect, they'll try and write it. Having invalid syntax
means it will stay in the style sheets.
fantasai: No, if it's not working as expected you'll probably come
up with something different. It's possible, but not
common. If it was a separate property then it might
stay, but because you're overwriting with a working
declaration it won't happen.
fremy: Experience suggests otherwise. Can the UA issue a warning?
TabAtkins: The warning is your declaration was dropped and your
page broke.
tantek[?]: As long as the breakage is obvious...
Florian: It is until you have MQ.
Rossen: It goes without saying that debugging layout issue is
harder than syntax. Drop for now and add later on seems
reasonable.
Rossen: Just within minmax(), right?
fantasai: Yeah.
Florian: How scary is it to fix the algorithm?
fantasai: I'm not sure, we haven't tried.
TabAtkins: It's not trivial. We haven't made a serious try, but
I've given it some thought and it's not easy. We'd have
to give it serious thought and possibly mess things up
and have some bug fixing rounds.
Florian: Then your plan makes sense.
fantasai: We could invalid it for now and figure out a proposal.
If implementors like the proposal we could add it back.
But we should make it invalid for now and we can take an
action if you'd like.
Florian: TabAtkins' clarification that it's more than a few
minutes ago helps. We should add it back at some point,
but I don't have a case for making you do it soon.
astearns: It makes sense to change. Does it make sense to make fr
invalid with a note saying in the future we may be able
to allow it in.
fantasai: Yep. That would help. It would also point out to authors
why it's not working.
astearns: And if someone has a shower thought on how to make it
fit we could capture that.
astearns: Proposal is change fr invalid in this circumstance and
add a note we'd like to add it back at some point in the
future
astearns: Objections?
RESOLVED: Change fr to invalid as the min in minmax() and add a
note we'd like to add it back at some point in the future.
<jensimmons> Yes, I see being able to do this as super helpful to
authors. A note, a clear failure path, and a serious
attempt to fix the algorithm would all be good.
grid-gap: <percentage>
----------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0385.html
fantasai: We don't have a good reason not to allow <percentage>.
It just didn't exist in column-gap. I'd be concerned
with shrink wrapping where you could get a 0 gap. But I
don't see any problems. But we don't have a strong
reason to add it and it's extra work to do.
Rossen: Use case?
TabAtkins: We haven't had one. Just someone pointed out that gaps
are like tracks. It was a filling in holes, not a I
want to do this thing.
Rossen: I'm asking because with multi-col being out there we
haven't had this request. Seems odd to add it because we
can.
<dbaron> we've gotten complaints about border-width not taking
<percentage>s, haven't we?
TabAtkins: We're inclined to reject, but we need approval.
jensimmons: It's common to set margins using <percentage>. That's
what the industry does these days. And they're not
using multicol. People aren't using it so they
haven't complained. I think people will be surprised
that you can't do <percentage> and they'll want to.
* tantek concurs with jensimmons's observations
<leaverou> I can attest to that. Multicol seems extremely
unpredictable and buggy
<dauwhe> agree with jensimmons
Rossen: We've had multicol implemented for years and it's commonly
used.
Florian: It's not
tantek: Implemented in quotes.
Rossen: Really? We should get it working.
Florian: Edge has it but not many others do. Lack of complaints
might indicate lack of use.
dbaron: Another analogy is borders don't take <percentage> and
padding and margin do.
astearns: I find it an odd inconsistency and we should add it.
TabAtkins: It requires no work on our side besides adding it to
the syntax.
Rossen: Looking at data across multicol locals and pages there's
very little data suggesting that margins and padding use
<percentage>. 96% of margin and padding are pixels.
jensimmons, I'm not sure where you're getting data, but
our data doesn't have much.
Florian: When is 4% low?
Rossen: I'm commenting to jensimmons saying a majority of the
industry is doing it.
tantek: You might both be right. jensimmons I think is talking
top-level page layout. Smaller elements have more pixel
and you'll have more style rules. I'm not sure a raw
analysis will get you the data you're looking for.
fremy: That's not how the data works. We do the data using if they
are used it at all.
jensimmons: I'm talking about people learning best practices today.
Tutorials and books teach responsive design use
<percentage> in margin for gutters is very common.
* tantek also agrees with jensimmons re: what is being taught
<Florian> I'm with jensimmons.
astearns: So...Rossen do you object to this change?
Rossen: Slightly. If everyone else wants it I'll let it go.
astearns: Does anyone else what to speak that agrees with Rossen?
* fantasai has no opinion, mainly concerned wrt implementation /
testing efforts
Rossen: No one has the use case and we're adding for the hell of
it, so let's add. Any time we add features we look for use
cases and this has none. We're adding additional complexity.
astearns: This came from a tweet saying why isn't it there. They
didn't have space to outline the case in the tweet.
jensimmons presented a use case for why people would
want to. I don't see a reason not to add it, it seems
like an oversight.
Rossen: To be clear, these will resolve how?
TabAtkins: Gaps are like tracks as far as the layout algorithm is
concerned. They're tracks you can't put something
inside of.
Rossen: So <percentage> resolves in their dimension.
TabAtkins: Yes.
RESOLVED: Add <percentage> to grid-gap
<jensimmons> in THE article that defined Responsive Web Design,
http://alistapart.com/article/responsive-web-design,
the margins are set in %s.
<ChrisL> multicol test suite has lots of missing test results
(largely untested on edge, lots of webkit fails)
http://test.csswg.org/harness/results/css-multicol-1_dev/grouped/
<ChrisL> (also, only 48 approved multicol tests out of 166)
fantasai: Sounds like we mark as at-risk?
TabAtkins: Should be.
RESOLVED: Mark the above as at-risk
Publication
-----------
fantasai: There's a few issues open, but we haven't published in a
while. I'm thinking it would be good to publish an
update. Main issues left are editorial and sub-grid. I'm
hoping to publish a draft soon.
<fantasai> https://drafts.csswg.org/css-grid/issues-wd-20150917
fantasai: We'll edit these things in this week, please take a look
over the DoC and the draft. We'd like to get everything
ready for publication in the next couple of weeks.
astearns: Before or after sub-grid is locked down?
fantasai: Let's see how it goes.
fantasai: I want to have everyone thinking about it if they need
to schedule time to do reviews.
astearns: We have 5 minutes. We had an item for
Range.getClientRects() when the range contains part of a
grapheme cluster which I'm not sure we can do in 5
minutes.
Agenda items for F2F
====================
astearns: It's coming soon. skk had an interesting topic.
astearns: We should get more things on the wiki page. sub-grid is
a good thing to add.
fantasai: Yeah.
astearns: With that I think we're done for the week
astearns: Thanks everyone!
Received on Thursday, 21 April 2016 01:02:34 UTC