- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Mar 2017 20:43:45 -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.
=========================================
Grid DoC
--------
- Issue #1: minmax max value
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-1)
- The group agreed that the use case was valid, but that it
should be solved in a different way then the proposal so
that the standard min/max priority can be maintained.
- RESOLVED: Reject this issue for L1 of grid.
- Issue #8: dominant-baseline should apply to grid/flex containers
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-8)
- RESOLVED: Accept text
- Issue #16: Defer subgrid
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-16)
- TabAtkins & fantasai proposed to not defer as there wasn't a
solid counter proposal.
- As the group discussed the proposal, it developed that there
was a desire to get subgrid right since no implementor had
yet implemented the partial proposal that was originally
placed in Grid in order to encourage implementation.
- RESOLVED: Move subgrid to level 2 of Grid
- Issue #17: Is fr a length?
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-17)
- RESOLVED: length & frs are not combinable, but will
reconsider if/when length & auto are combinable
- RESOLVED: Republish Grid
Driving specs to REC
--------------------
- Rossen introduced the group to the plan he and astearns
developed to help the group move specs towards REC.
- At the beginning of each call there will be a status check for
all specs that are in CR or are stable WD to see what steps
have been taken to move them to REC and give authors the
opportunity to request assistance.
- This new process will begin on either the 22 or 29 March calls,
depending on progress agreeing upon the beginning list of
specs to prioritize.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0050.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Alex Critchfield
Benjamin De Cock
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Melanie Richards
Geoffrey Sneddon
Alan Stearns
Greg Whitworth (IRC only)
Steve Zilles
Regrets:
Bert Bos
Dave Cramer
Simon Fraser
Vladamir Levantovsky
Michael Miller
Jen Simmons
Scribe: dael
Rossen: Let's start.
Rossen: As usual, any extra agenda items?
<gsnedders> I want to mention
<https://lists.w3.org/Archives/Public/www-style/2017Mar/0042.html> wrt
merging the test repos.
gsnedders: I want to mention this ^ email.
fantasai: I'd like to go over the flexbox status.
fantasai: Anything we can do to get it republished soon-ish.
Rossen: Perhaps that will be covered in agenda #5.
Rossen: If we don't cover it then we'll put it separately.
Rossen: Anything else I might have missed?
Rossen: I'm only hearing gsnedders addition
Grid DoC
========
<fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016
minmax max value (Issue #1)
---------------------------
<fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-1
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Oct/0076.html
fantasai: First open issue is #1 which is about...we got a message
from Ollie Williams explaining a case when you have
conflicting min and max constraints the min wins
generally, but this is a case where max should win.
fantasai: We closed as no change for consistency, but his use case
is valid and it would make more sense if it's possible
to express this sizing constraint where the max...in
this use case the optimal was 20% and the max was 250px
and that wasn't working out.
fantasai: This is a totally valid use case, it would be nice to
have a syntax to express it. Maybe fore next grid
release or something.
<fantasai> grid-template-columns: 1fr repeat(4, minmax(20%,
250px)) 1fr
fantasai: Here's the example^
fantasai: [explains example]
fantasai: Perfectly reasonable. We can't solve other than nest the
grid in a larger container.
fantasai: Proposal is we reject the proposal, but also request
that if the WG has a reasonable way to express this
raise an issue so we can add this.
Rossen: Comments?
rachelandrew: It's not a use case that's come up from anyone else
and I've heard lots this week. It feels like there
will be lots of little things like this. I feel
we're going to get an awful lot of this kind of use
case as people get their hands on grid.
Rossen: I would agree with rachelandrew and fantasai. Pushing this
to a different level or in the sizing spec is the path
forward. Having it punted from L1 grid sounds right.
Rossen: If there are no other thoughts we can call for resolution
Rossen: Objections to reject this issue for L1 of grid?
fantasai: We want to solve the use case, but perhaps in a slightly
different way.
Rossen: We can work it out, but not in grid L1.
fantasai: In L2 we won't invert the order of priority for min/max.
We'd solve the use case in another way.
Rossen: For sure. I'm just saying let's cross this bridge when we
come to it.
<fantasai> And I'm saying we're not crossing any bridges that
invert the order of minmax priority
RESOLVED: Reject this issue for L1 of grid.
dominant-baseline should apply to grid/flex containers (Issue #8)
-----------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-8
<fantasai> https://github.com/w3c/csswg-drafts/issues/798
fantasai: It's a CSS inline layout issue. Max was pointing out
that the 'applies to' section doesn't say it applies to
grid & flexbox and it should. I made the change to
inline but want the WG to say okay.
fantasai: Change was to CSS Inline.
<fantasai> https://drafts.csswg.org/css-inline/#dominant-baseline-property
fantasai: There's a dominant baseline prop. Link ^
Rossen: Any feedback?
Rossen: Other opinions?
Rossen: Anyone feel we shouldn't apply dominant baseline to grid
and flex containers?
fantasai: Also applied alignment-baseline to flex/grid items
RESOLVED: Accept text
<dbaron> I find it a bit curious that baseline-shift applies to
fewer elements than alignment-baseline and
dominant-baseline.
<fantasai> dbaron, that's a fair point :) I guess there's no
reason it couldn't apply to baseline alignment in
general...
ACTION: fantasai extend applies to for baseline-shift to match
alignment-baseline
<trackbot> Created ACTION-836
Defer subgrid (Issue #16)
-------------------------
<fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-16
<fantasai> https://github.com/w3c/csswg-drafts/issues/958
fantasai: He's asking to drop subgrid because he wants to see if
you can implement subgrid independently to each axis.
TabAtkins and I said if you want something you want
changed and that destabilizes the spec we'll drop it,
but so far you've just said I'm not sure about the spec.
That's our position, but we wanted to know the WGs
thoughts.
Rossen: So your opinion is not change the current spec and wait
for a counter proposal that negates or improves the
current solution?
fantasai: Yes.
tantek: Is anyone else impl subgrid?
Rossen: FF is.
tantek: Which is Mats who raised the issue.
[issue author clarification]
rachelandrew: I've commented on the thread. I'd love to see
Mats...I've written my concerns about locked to axis
and I'd love to see Mats investigation on if it's
possible to do it more like the original. It would
be a shame if he doesn't get to do that. I'm
concerned about how useful the spec will be. I don't
want him to feel the investigation would not be
useful.
TabAtkins: No one is holding up Mats but himself. He thinks we're
not open to changing and we are.
fantasai: Maybe he wants us to pull so no one else implements
until there's investigation?
Rossen: We certainly welcome the feedback. If Mats is under a
different opinion I'd love to have him join a call or
meeting to make sure he feels supported. If he has any
impl experience and feedback with the current proposal
we'd love to hear it. This is why we have CRs and call for
impl feedback.
Rossen: In the lack of concrete proposal given the work that's
gone in already to subgrid and the feedback we have gotten
I don't believe there's enough merit to remove it and say
we'll have something better, trust us.
* tantek wonders if Rossen is speaking with chair hat or MSFT hat
now
Rossen: Also, we've made significant efforts to make the symmetry
of grid in respect to rows and columns and it would be
unfortunate if we spec subgrid to favor one or the other.
Rossen: And I was speaking as a chair. I'll say if I'm using my
MSFT hat.
* fantasai doesn't have any objection to whichever way we go.
tantek: To see if I can communicate impressions from Mats, I think
TabAtkins's characterization is true, but when there's a
spec in CR it indicates a very specific direction and
there's no indication in the spec text other directions
are possible and does communicate strongly by its state.
It's reasonable for Mats to feel that way. I think anyone
outside the WG would have a similar impression.
tantek: Mats as far as I can tell is the impl that's most ahead on
this work and the subgrid is calling for impl feedback. I
think we shouldn't just prefer...even vague implementor
feedback trumps aspirational precision. I'm not asking to
replace the current spec, but it's reasonable to indicate
with spec text that there's an alternative being
investigated.
tantek: That's useful to show Mats his work is valuable and
communicate to other impl that this is useful to the WG
and welcome. And say that we are looking for alternatives
here.
tantek: That's my proposal, but of course we're in CR which brings
up should we drop.
<rachelandrew> +1 to tantek's proposal
TabAtkins: There's no alternate proposal. It's just vaguely we
should go back to thinking about independent axes. I
recall when the original subgrid came up I wanted to
push another level. It was author and dev concerns that
made us look at a simplified version for this draft. If
the group now feels it's more important to get it right
and push it, that's fine. That's my original position.
<Rossen> +1 to all of what TabAtkins said
tantek: That's fair. There is a bit of...we are learning more
about this conceptual space as we implement. There is new
info, like we just heard from rachelandrew where there is
now openness to biasing toward a correct version later.
tantek: The specific proposal would be that we either separate it
out or add at least an informative paragraph saying we're
considering an alternative design that's independent on
each axis. I agree it's vague but something that
communicates it's happening. I think you'll see more
specific proposals follow up.
TabAtkins: Mats isn't just a third policy. We can tell him please
work on this. We can point him to the minutes and
communicate.
tantek: That's part 1, but part 2 is to more implementers broadly.
TabAtkins: Igalia monitors the issues list for grid.
fantasai: Yes, Igalia & Mats follow minutes, but it's our job to
be clear to everyone, including those that only read
docs. If there's something important to tell
implementors it should be in the doc.
fantasai: Given the current state, we're shipping grid with
everything except subgrid. Given that I don't object to
putting that in L2 and doing that as a WD for comments.
fantasai: I think Mats wanting to investigate is fantastic. We
didn't do it because Igalia thought it was impossible.
It would be great if they could talk and agree it's
possible.
TabAtkins: I agree which is why this needs to start in an issue
with a proposal. I know how hard it was to think about
originally.
<fantasai> I don't think it was that hard to think about.
<tantek> I'd like to hear rachelandrew's opinion on moving subgrid
to a separate spec and spinning that up
<tantek> at this point would anyone strongly object to moving
subgrid to a separate spec?
<tantek> / level
<fantasai> I would object to moving it to moving it to a different
module, yes :) Not to a different level.
Rossen: As an impl or as a chair, I don't have a strong objection
to moving subgrid out into a different spec or keeping it
in spec with an explicit sentence that welcomes additional
contributions. I also don't see how this is any different
then any work in other specs. They are there to invite
implementation and through this implementor feedback get
specs that are more technically sounds as well as from
user PoV.
Rossen: If the only thing we're considering is an implementor that
feels unheard, please invite Mats to join us so he feels
all his ideas/objections/proposals have been heard.
tantek: I can follow up with Mats directly.
Rossen: In addition to the +1 to TabAtkins I also believe grid
would have been done earlier if we didn't have spin cycles
for subgrid.
Rossen: Based on the implementation we had with grid when the
initial proposal came through we know subgrid would be
difficult. But there was no objections to pursuing that
simple version. There hasn't been another version that
came through.
Rossen: Here we are discussing this again so it would be good to
take an option so we can push forward on REC track for
grid.
fantasai: In terms of cycles we spent on subgrid, we spent more
time talking about if it should be there or not instead
of technical. Also as an editor I spent a minuscule
amount of time on subgrid vs. the rest.
Rossen: Agreed.
Rossen: Do we want to keep subgrid in the grid spec or move it out
on its own so it can signal additional and stronger
request for feedback & changes?
TabAtkins: I think we should only move things that are unstable
and not ready for this level.
* fantasai suggests a straw poll so we can move on
<astearns> +1 to moving to the next level, for stability reasons
<ChrisL> It sounds like it is less developed than the rest of grid.
<ChrisL> so, push to next level
<tantek> ChrisL - it is, less implemented by far (like none vs 3)
<fantasai> ChrisL, I'm not sure that it's less stable, it just has
received less attention because it hasn't been
implemented yet
Rossen: Okay. We have 3 implementation and none have subgrid. I
think this speaks volumes.
rachelandrew: I think move.
rachelandrew: I really wanted it to be implemented and at the time
Igalia had the revision there was hope there would
be implementations. If we're talking changes it's
better to move so that we say we're not expecting
impl. And it tells authors we want more feedback. We
can say we moved it so we can talk about what we
need.
<tantek> +1 rachelandrew
Rossen: Let's try and have a resolution. Objections to moving
subgrid to its own module?
<astearns> next level of grid, not it's own
fantasai: I do. I don't want another module. We can move to grid 2.
<tantek> I'm fine with level 2
<gsnedders> I'm +1 on what fantasai said
<ChrisL> agree with fantasai
rachelandrew: Yes, I meant a level 2. Not a separate subgrid weird
thing.
<ChrisL> +1 to grid l2
Rossen: Okay, grid level 2. Objections to moving subgrid to level
2 of grid?
RESOLVED: Move subgrid to level 2 of Grid
Rossen: And again, tantek please reach out to Mats and make sure
he feels he's being heard and supported here.
TabAtkins: Can we please get Mats to join the WG?
Rossen: Is he not?
TabAtkins: I don't think officially. He doesn't have GitHub access.
<fantasai> We should have all the Igalia and Mozilla devs who
participate in GitHub to have edit privileges in the
repo
Rossen: So tantek you can follow up on that too.
tantek: I can ask if he wants to officially join. I'll do my best
to facilitate the communication. I can't force him to join.
Is fr a length? (Issue #17)
---------------------------
fantasai: I'm skipping issue #15. I have #17- a question about if
fr are a length.
<fantasai> https://github.com/w3c/csswg-drafts/issues/955
fantasai: We said no, but it raised if they should be combinable
in calc.
fantasai: I wanted to get a resolution and see if there's interest
in adding that
fantasai: to a future level.
TabAtkins: fr isn't a length: it's length adjacent but you can't
combine it with lengths.
Rossen: I would further that that I always thought of fr like auto
for purposes of distributing space. For that reason we
don't consider auto as combinable.
fantasai: Yet. It's been requested.
TabAtkins: And when we deal with that we can reconsider. As of now
I think we should just resolve.
fantasai: fr are not and will not be combinable with length and
percentage values. Reconsider when auto values are
combinable.
<fantasai> proposed resolution: length & frs are not combinable,
but will reconsider if/when length & auto are combinable
Rossen: Sounds good.
Rossen: Objections?
RESOLVED: length & frs are not combinable, but will reconsider if/
when length & auto are combinable
Republish
---------
fantasai: Closing today's issues, we have one open which is 15 and
we should just do an update officially.
Rossen: I'm in favor.
Rossen: Objections?
RESOLVED: Republish Grid
ChrisL: Updated CR?
fantasai: Yes.
<tantek> are we going to note imminent separation of moving of
subgrid to level 2?
<tantek> in this new Grid CR?
<tantek> can we at least make a note of that happening soon since
we have a resolution?
<fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-282771617
fantasai: And Rego wanted to confirm the behavior we got for the
replaced elements in grid is actually what we want.
Anyone with an opinion please look at his comments (link
above). If you think it's wrong, post an issue.
Otherwise we'll assume it's closed. fremy if you could
look it would be appreciated.
tantek: Quick question on grid CR. Can we include a note about the
move?
ChrisL: I assumed the republish would include the removal.
tantek: Great. That's awesome too. Thanks.
Driving specs to REC
====================
<tantek> driving specs to REC ++
Rossen: I've had multiple discussions with people from W3M, AC
members, etc. They always ask me why are we not publishing
more REC.
<fantasai> because we need more people like gsnedders
<fantasai> companies send product managers here, but not
super-awesome QA personnel
Rossen: That started a little investigative process on how to move
things forward. Are there things to expedite this.
Rossen: We've had discussions with astearns and here's our
proposal:
Rossen: If we look through all the agendas that we've had this
year alone we had discussions around almost everything
being worked on [lists ever spec discussed this year]
Rossen: Usually when we have time for discussion we're good at
filling our call time. However, not every topic helps us
move to REC. They don't come on spec work alone. We need
tests.
Rossen: Looking through the current specs, the ones that seem
closest to driving to REC are...Writing Modes is the
closest and we're waiting on final test reports.
Rossen: Text level 3, fonts 3, cascade 3, transforms L1, flexbox,
variables.
Rossen: As a P2 we have grid as the first. The rest are open to
discussion.
Rossen: So how do we move forward? This is stating the obvious, I
think.
Rossen: So how do we make progress?
<tantek> YES
<tantek> this is kinda what I was trying to do at the Lisbon f2f
<tantek> with what specs are going to CR by end of the year
<tantek> etc.
<tantek> Rossen++
Rossen: Our proposal is to dedicate all those specs as the first
item for every call until they become RESs. We've
discussed this in the past and usually the first
objections was "if there's nothing to discuss why have
them on the agenda" and it's because we're either done or
stuck on something. If we're stuck we need to figure out
how to get unstuck.
Rossen: If there's nothing to do besides tests, let's get tests
written. Perhaps we'll ask why there are no tests written
or none reviewed.
Rossen: So spending 15 minutes out of every call talking about
people not doing what they were supposed to can suck, but
it can be really productive. This is how we got SVG from
something chaotic to something organizes and in CR.
<dbaron> spending the first 15 minutes of every phone call asking
people why they haven't done any work really sucks
<dbaron> last time we did that I stopped attending the calls
<fantasai> dbaron, +1
<tantek> dbaron, true, hopefully we can minimize it to 5 min ;)
<tantek> hopefully we can reframe it as "Is there anything we can
help with on this spec?"
<ChrisL> it also sets up an expectation, so people tend to
prioritize getting stuff done ahead of the call
<ChrisL> tantek++
<fantasai> tantek, every call? the same answer almost every call
<tantek> I am not a fan of shaming or berating people about
"asking people why they haven't done any work"
<tantek> in fact I am specifically against any such shaming or
berating. totally unproductive and demotivating
<tantek> fantasai, I think it's legitimate to ask "how can we
help?" and also ok for editor(s) to say "no idea or you
can't", until they think of something that does.
<tantek> just asking the question, and respecting the editor(s)
answers would be a good start
Rossen: The same objections and comments were made with SVG. We
ask these questions because we want to ship the spec.
Those of you that ship on a regular cadence know how to do
it. This mandated progress is a way to do it.
Rossen: This is our current proposal from astearns and I.
fantasai: First, on your list of specs, I think conditional rules,
cascade and V&U should be on there.
Rossen: Cascade was there.
fantasai: Conditional rules, V&U, Backgrounds.
fantasai: Text 3 isn't even in CR. I'm in favor of working on
them, but there's things in addition to testing.
fantasai: Second comment is until there are people doing testing
as a significant part of their to do we won't make
significant progress. Most of this work is not telecon
work. It needs people that care about gathering tests.
<gsnedders> (I was basically going to say what fantasai did)
fantasai: Until we have people that have the time to do that we'll
just talk status which is not useful. That's the problem
we need to solve. We need QA people. It doesn't have to
be actual QA people, but people who can QA. It can also
be QA people. But if it's people doing this in their
spare time we won't make progress.
Rossen: In reply, once we see the testing work for a spec has
taken off we can deallocate this spec out of conference
call. Until then we need to support this work.
ChrisL: I did publish for css 3 fonts there areas missing tests. A
good 2/3 could be tested from myles' font, but it's mac OS
only font. I can't make tests. That's what I'm stuck on.
If I can get unstuck I can commit to tests. I'm asking for
help.
<gsnedders> ChrisL: I can potentially take a quick look, FWIW
Rossen: Send me an e-mail and I'll connect you with out fonts guys.
<tantek> ^^^ great example of the need help? ask for help. pattern
myles: A couple thoughts.
myles: I want to echo fantasai that the work remaining doesn't
need to be on the call.
myles: Second is I'm still fairly new as an editor so...I would
love to take my specs to REC, but I need an mentor. I'm
happy to work with ChrisL or anyone else.
* ChrisL thinks Myles is doing a fantastic job editing fonts 4,
actually
myles: Point 3, ChrisL the font I'm confident I can make it work,
I just need time. Which is kind of like point 1. The people
doing this in their spare time, it's a matter of time and
priorities.
Rossen: I totally agree. Time is the only currency we have to
spend and if we're constantly on credit we have problems.
I want to force those conversations so people can ask for
help. Given that we've made you the editor and you need
mentoring, this is the time for you to ask. If we don't
force those conversations we'll be stuck where there are
all kinds of things to do and the progress gets slower.
<fantasai> We should *absolutely* make sure that people feel
welcome to bring up any issues that need WG discussion
or help from other people. Just don't think that
dedicating time every call to testing work is useful if
none of that work is being done and there is therefore
nothing to discuss. :)
<tantek> fantasai, beyond "feel welcome", I think it's important
to signal that the group prioritizes that
<fantasai> tantek, sure
<fantasai> tantek, don't mind to have a standing agenda item
that's "Does anyone working on testing have anything to
discuss"
tantek: In response to fantasai, Rossen if we prioritize the CRs
and then the mature WD as separate clusters I think that
would help.
Rossen: Definitely. The order we came up with was initial review
of specs that seem close and stable enough in terms of not
too much in terms of changes and mostly impl in browsers.
We welcome feedback similar to fantasai's. We missed some.
We can continue to refine the list on the private ML and
continue to go forward.
Rossen: If we don't start next call, perhaps, we should start the
following. If we don't solidify the set of specs for next
week, that is.
<tantek> also we should encourage editors of CRs that need help to
prioritize their requests / issues
<tantek> over new WDs etc.
Rossen: We're on the top of the hour. This is something that will
take getting used to, but in the long run I'm hopeful and
I think we'll get good results and send good signals to
the rest of the community.
fantasai: I just want to repeat that if you want to get to rec we
need to get QA people in here, not just devs that also
write specs.
Rossen: Yes. That's noted. We'll see what can be done. As a group
we have to be able to get our specs to REC.
<tantek> fantasai, agreed, and we can also note that more broadly,
e.g. to AC/AB that we are looking for more QA help.
gsnedders: I just want to mention that the merge with
web-platform-tests will happen in under a fortnight.
<gsnedders> https://lists.w3.org/Archives/Public/www-style/2017Mar/0042.html
is the email I mentioned about that.
Rossen: Thanks everyone. We'll chat next week.
Received on Thursday, 16 March 2017 00:44:50 UTC