- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Jul 2017 20:34:36 -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.
=========================================
TTML request for review
-----------------------
- Anyone with interest was asked to respond to the request for
review: https://lists.w3.org/Archives/Public/www-style/2017Jul/0005.html
Spec Rec next steps
-------------------
- fantasai will reply to Chris shortly in order to resolve if
Writing Modes needs one more CR cycle.
- gregwhitworth began reviewing all the Flexbox tests to establish
coverage.
CSS2 publication issues
-----------------------
- Though the group recorded several resolutions in February to
change the CSS2 publication process (recorded here:
https://lists.w3.org/Archives/Public/www-style/2017Feb/0058.html)
the new process still hadn't been fully implemented.
- This has lead to there being greater confusion as to what is
the most up to date and possibly new work occurring in
more than one place.
- There was some concern that this new process was either not the
best way forward or not well understood, so there will be a
conversation at the Paris F2F to revisit the original decision.
- In order to reduce confusion as to what is currently out there,
Bert will look through css-testing and make sure that any
changes there are merged into css22 before deleting
css-testing as well as css-source (which is currently empty).
Compatible alignments aren't always compatible
----------------------------------------------
- There were three items listed in github for the group to choose
from:
1) Exclude items with align-self: stretch and a specified
height constraint (min-height/height/max-height) from
align-content: last baseline alignment.
2) Exclude items with align-self: stretch whose specified
height constraint gets triggered such that it no longer
sizes as stretch.
3) Treat items with align-self: stretch and align-content:
last baseline as having an end fallback alignment instead
of a start fallback alignment.
- RESOLVED: Option 3 from issue.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0004.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Ian Kilpatrick
Tomoya Kimura
Peter Linss
Myles Maxfield
Anton Prowse
Melanie Richards
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Rachel Andrew
Dave Cramer
Daniel Glazman
Chris Lilley
Rachel Nabors
Jin Simmons
Lea Verou
Scribe: dael
TTML request for review
-----------------------
Rossen: Let's get going. Are there any extra items people want to
bring forward?
Rossen: Or change anything in the current agenda?
Rossen: Only extra I want to add is a heads up that ttml WG is
requesting wide review for their WD.
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0005.html
Rossen: If anyone has a chance they're depending on you.
Rossen: I skimmed the list, there looks to be ruby, inline block,
etc.
Florian: I seem to recall dbaron giving feedback on something like
this. Was it a previous call for comment?
Rossen: Might have been. This call was just today. To be honest, I
don't know. Maybe it was a previous.
Rossen: Since he gave feedback before I'm hoping he'll take a look
and either reaffirm what's supposed to happen happened or
commenting from his PoV
Spec Rec next steps
-------------------
Rossen: Writing modes.
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0003.html
Rossen: fantasai I don't know if you saw Chris's request.
fantasai: I was going to do that yesterday and forgot.
Rossen: His question was legit. He thinks everything was editorial.
fantasai: There was a minor change - viewport change to scrollport
- and I think I forgot to add that to changes.
Rossen: And you think this merits another CR recycle?
fantasai: It might require it. It's a substantive change, but it's
to the way the implementors implemented.
Rossen: Once you look can you respond to him? If we have to
restart let's do it as soon as we can.
fantasai: Yep.
Rossen: Flexbox.
Rossen: I know gregwhitworth was going over test coverage and we
were ready with...where are we with flexbox?
<fantasai> https://drafts.csswg.org/css-flexbox/issues-cr-20160526
gregwhitworth: I opened a few PRs for the changes I found. I need
to check is Christian investigated something that
wasn't interop on Linux. Based on fantasai rec I've
gone through every text to look for gaps.
gregwhitworth: I believe dbaron was going to provide some tests. I
believe.
Rossen: I think there are a few specs waiting for Mozilla tests.
Flexbox, B&B, Conditional, I think.
fantasai: It might be useful if someone from Mozilla can drop
links and then someone else can do the rest.
Rossen: Definitely. I'm not expecting dbaron to port the tests, I
was relying on him as the Mozilla liason to delegate. He's
just our main contact.
gregwhitworth: Is there a reason we're preferring Mozilla tests
over others?
Rossen: We're preferring them over having nothing.
fantasai: What I've noticed is when different vendors do tests
they cover different things. If we want a good test
suite we should bring as many tests together. Mozilla
tests are in ref test format so we need to just tag
them. But I don't know what the process is to submit it
through. It should be fairly easily.
Rossen: Moving along, thank you gregwhitworth for moving those
forward.
<fantasai> dbaron or dholbert, can you drop us some DXR links to
the Flexbox tests that haven't been submitted yet?
<dholbert> fantasai: Mozilla's flexbox tests almost all live in
https://dxr.mozilla.org/mozilla-central/source/layout/reftests/w3c-css/submitted/flexbox/
(with the exception of a few that test mozilla-specific
quirks/interactions), but I think those are all
submitted... not sure which ones "that haven't been
submitted yet" you're referring to
<fantasai> dholbert: Wasn't sure if there were any, if they're all
submitted then that's great!
<dholbert> fantasai: (looking in more detail) we have other tests
that rely on Mozilla-specific reftest extensions, like
MozReftestInvalidate, and perhaps depend on exact font
metrics (IIRC) and hence aren't suitable for
submission. Those ones live at
https://dxr.mozilla.org/mozilla-central/source/layout/reftests/flexbox/
Rossen: fantasai did you get to catch up on any of the other
specs? V&U UI?
fantasai: I only did display and align lately.
* fantasai has a DoC for Display now
Rossen: As part of this I wanted to go over CSS 2
Florian: Before that one, where are we with CSS Contain? There was
an issue on something linked from CSS contain and we were
waiting on Chris to get feedback from Ralph.
Rossen: Chris is on an airplane over a bunch of water. I haven't
seen anything on private or public list. Feel free to
refresh the mail thread if there is one.
CSS2 publications issues
------------------------
<Rossen> https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0013.html
(member only list)
Message text from fantasai:
[
I had a long conversation with plh about our proposed process
for updating CSS2.1, and he's on board. However, we've got a
bit of a mess on our hands.
What we need:
Two copies of CSS2 in the CSSWG repo:
* one to represent CSS2-REC with PR-ready errata folded in
* one to represent CSS2-updates with all errata folded in
Two copies of CSS2 on /TR, one to represent each of these.
What we have;
Four copies of CSS2 in the CSSWG repo
Two copies of CSS2 on /TR, unclear which represents what.
Actions that need to happen:
* Reduce the copies in the CSSWG repo as described above.
* Set up css2-testing and redirects per
https://lists.w3.org/Archives/Public/www-style/2017Feb/0058.html
* We also have an outstanding resolution to have a note at
the top of each section and subsection of CSS2.1 that has
been obsoleted by a later CSS module, pointing to the
relevant section(s) in that module. There is just a
generic notice atm, which is better than nothing, but
this action needs to be handled 100% and CSS2-REC
republished.
https://lists.w3.org/Archives/Public/www-style/2015Mar/0317.html
]
Rossen: There was some back and forth between gsnedders and
fantasai added it as an agenda item.
fantasai: I wanted to look at the status of css2 to make some
progress. We had a plan in Seattle with plh and that's a
summary of the plan. There was blockage to get things
published and I explained what we wanted to try to plh
in person. We're going to experiment with this process
as we discussed.
fantasai: What we don't have is the impl of the plan. The question
is who will do the things that need to be done. We need
to have 2 copies of CSS 2, one reflecting short term
what will be published and one where we will put all of
the changes we've agreed to and resolved on
fantasai: There seems to be 4 copies and that needs to go down to
2. I don't know which is which or what the state is.
Also, both of these need to be on TR. We need /tr/
css2-testing set up
<gsnedders> there's only three
fantasai: We also have a resolution of a note on each section that
has been obsoleted that points to the newer spec and
that's on both copies.
fantasai: None of this has been done so they need to be assigned
to somebody.
gsnedders: I sent a long email end of May having spoken to plh at
start of May and much of that was for Bert who had just
gone on vacation. We seem to have a complete mess where
some of the copies...the one meant to be ready to go to
PR has changes not in the experimental. I don't know
where we need to start.
<gsnedders> https://lists.w3.org/Archives/Public/www-style/2017May/0042.html
is the email I sent
Rossen: Bert can you shed some light?
Bert: The mess started in Seattle. There were 3 before that, one
which was empty- css2-source. We can delete that. Before Jan
we had 2 directories, one with 2.1 and one css2 which is the
next version. The later is the most up to date, it has all
the errata.
Bert: css2-testing was created after Seattle, but I'm not sure
what to do with it because who will decide what's in it and
when to publish? So I've been concentrating on css2 up to
date. It has all the errata.
Bert: Do we want to publish this note? I'm not sure what the
process is and how to keep people from getting confused. I'd
rather undo the note thing and publish css2.2. I think we
still have all the tests.
fantasai: My concern for CR of 2.2 is that in order to update the
rec we need changes batched so all things have a test
and implementation. Going through the updating rec
process seems what we should do instead of making more
and more css2 steps. It should be possible to maintain a
rec.
fantasai: At the least we should be able to update the rec with
changes that satisfy PR exit. But we have many changes
that won't pass and if we include them we'll never get
to publish another rec of css2.
fantasai: Seattle decision had us maintain css2 so css2.1 cycles
through editing process and gets updated. So people can
review and work on impl and understand errata that have
not gotten PR we want to have a public copy with all
errata, tested and not.
fantasai: While the ED repo is public it's better to have an
official draft on TR which is why we would have the
note. That should auto-sync from the ED when there's a
change.
fantasai: If we resolve on a change it should go to TR. That way
we'll have a copy with all the changes and a copy
working through rec maintenance.
Florian: To clarify, the thing that was css2.2 up till now keeps
the same content and becomes a note so there's a ED
version and a TR note version and then we cherry pick
items to update the css2.1.
fantasai: Yeah.
Florian: So there's no third testing thing in addition to 2.2 and
2.1?
fantasai: Yeah. We bikeshedded 2.2 to 2-testing, but it's more or
less the same thing. Updating process is different. It's
things we agreed on that don't have tests.
<gsnedders> Where did we resolve on the name?
<gsnedders> (of CSS2-testing)
Rossen: Going forward, we have 2 weeks before Paris. What can we
have actionable before then? What I see is we have
css2-source, let's leave that. css21 is no need to touch.
css2-testing for the note needs to happen so that's
actionable and there is the current version, css22, where
Bert has made changes.
Rossen: What of this can be actionable before Paris? We had a long
discussion in Seattle and we'll have a long discussion on
this in Paris and I want to avoid taking the all call, so
what of this is actionable?
<Florian> 1) delete -source
<Florian> 2) delete -testing
<Florian> 3) rename 2.2 into -testing
<Florian> 4) update TR accordingly
fantasai: We have resolutions on all of this. I linked to those.
We need to have some sense of what's going on in the
repo. If there's anything out of date we should delete.
The current css2 has all changes which means that is the
source for css2-testing as it has all changes. Then we
need a copy of the spec with only changes ready for rec.
fantasai: Those two copies need to be in the ED repo. Once we have
that we need to take the action on linking from each
section and subsection to the relevant spec if it
exists. We agreed that the next thing after clicking on
a link is a note if it was deprecated.
fantasai: And then publishing to TR. That's all actionable.
gsnedders: We don't have one copy of css2-testing because there
are changes only in css2 draft and some in css2-testing.
fantasai: So we need someone to sync everything.
fantasai: There will be 2 drafts, one with a subset of the changes.
Rossen: Let's start with this. Can we action someone to pull back
together everything in 2 versions? gsnedders or bert?
Bert: If I understand fantasai wants css2-testing to be the most
complete and css2...I don't know what that would contain
Florian: CSS2 and 2-testing should be the same.
Bert: How will we publish the next revision?
Florian: The 2.1 draft.
Bert: That's the first revision. We're going to publish the 2nd?
Bert: I propose we just delete 2.1.
Florian: We'll need something identical to 2.1+cherry picked
changes. I think that's easier to start with 2.1 and add
instead of start with everything and remove.
Florian: There should be css2 which becomes css2-testing which is
everything. Then we cherry pick things into 2.1 which we
republish.
Bert: How?
Florian: We resolve on here's a thing with tests and impl.
Bert: We have tests for 2.2, not for css2-testing. That's only a
note so we don't have tests.
Florian: I think separating that you don't like the process, the
actionable thing is to not delete 2.1 and to make sure
that between css2 and css2-testing, regardless of names,
there's only one draft left. Once we have that we have
the basis for either what we did before or the new
process.
Rossen: New process being one spec and one for changeS?
Florian: Yes.
<tantek> Rossen: do you understand what Bert is saying / proposing
vs. what Florian is saying / proposing vs what fantasai
is saying / proposing?
* tantek is now having serious flashbacks from Seattle
<Rossen> tantek, torlling is not the same as fixing the process
<tantek> Rossen: as long as no one is writing down their proposal,
we'll keep repeating history
<fantasai> tantek, we already resolved on everything.
<fantasai> it's not being implemented.
<tantek> fantasai: that's what I thought in Seattle
<fantasai> We changed the process in Seattle, and resolved on it
in February
<tantek> fantasai: that's what I remember too, hence why I'm
confused about the confusion
<fantasai> tantek, resolutions are in
https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0013.html
<tantek> however I can't find a link to an explicit step by step
process for CSS2.2 that we agreed on
<tantek> fantasai: that helps, however we still don't have a list
of steps for continued iteration
<gsnedders> Rossen: do you want me to write down a list of actions
from
https://lists.w3.org/Archives/Public/www-style/2017May/0042.html?
<dbaron> Somebody should gather the list of resolutions into a
document.
<gsnedders> dbaron: yes
<fantasai> tantek, diagram :
https://lists.w3.org/Archives/Public/www-archive/2017Jul/att-0000/css21-update-process.jpg
<tantek> fantasai++ that's a good start
Rossen: I think we resolved on this in the past. What I want to do
is see if we can action Bert or gsnedders to have some
things actionable going forward before Paris. This seems
to be repeating conversations we've already had. Let's not
repeat again and again. If we believe we resolved in the
past something that we should change let's talk about that.
Rossen: It seems the actionable part is for the resolutions in the
past we need to consolidate down to 2 working versions of
the spec, one that stable & public and the other that is
the editorial version.
gsnedders: I haven't done anything on this because I don't feel I
know the current state of the directories.
fantasai: Let's do this. Out of all of the copies of css2.1,
somebody, preferably Bert, gets one copy of css2.1
called whatever and all of the agreed changes are into
that, whither we have tests or not. We need to
defragment this.
fantasai: And then pull down a copy of css2.1 source as of the
date it was published on TR as a REC and put that in the
repo. Then we can take the changes tested and impl and
copy them into the REC source.
<Florian> +1 to fantasai
<dbaron> I think one issue with that plan fantasai stated is that
the cherry-picking requires a decent list of the changes
and their associated tests.
<fantasai> dbaron, Bert maintains an errata document
<fantasai> dbaron, the process for making a change to CSS2.1 so
far has been to edit it into the ED, write it up in the
errata document, and write it up in the Changes list
<fantasai> dbaron, so all we need to do is add annotations to the
errata document linking to the relevant tests
Rossen: It seems like we have currently the css22 which has all of
Bert's work. There's css2-testing that doesn't have
anything in it.
Florian: gsnedders said there was stuff different.
gsnedders: There are.
Rossen: Those things can be put into css22 which is the current
version. We retire css-testing for now. css2-source is
empty. After this we have css21 which is current TR and
css22 which has everything bert has worked on plus the
note. Does that sound like the action we want to give Bert
if he's willing to take it?
Bert: Let me see. Delete empty directory, deleting css2-testing
okay. css2 will become the note, that's easy, I need to just
change the title. css21 has old sources.
Florian: css2-testing can only be deleted if everything in it is
in css22. We need to verify that.
Rossen: Let's sort that out on the side. That will be part of
deleting.
Bert: I can do a comparison.
<gsnedders> Bert: I think it's missing
3ab2236828f6dc90a7a949aefad2e2ad24bbd1e4 and
a2181b24fd27c22b456fad91261405905d1ab0a3
<fantasai> gsnedders, git or hg? :)
<gsnedders> Bert: css2 is missing those commits from css2-testing
<gsnedders> fantasai: git
<gsnedders> maybe a3be294641351a82c20c27888eca6f46f40adfac too
Rossen: How about this, the action is delete any empty directories
as well as css2-testing after verifying that it would
merge cleanly with css22.
Bert: I'm afraid of a large bit of work as css21 directory has old
sources.
Rossen: We're not doing anything with 21. Just consolidate
everything into css22. Then we'll figure out next steps.
Rossen: Action is only for css22.
Rossen: css21 doesn't need to change right now.
Bert: Okay. I see problems in the future, but we'll deal with that
later.
Rossen: Is there anything else on this topic or should we move on?
gsnedders: There's other things. We need...let's not do this now.
I'll send a list of actions based off of my May email
and we can discuss on the list.
Florian: Shouldn't those happen after what we discussed doing?
Rossen: I was asking if there's anything that needs to happen
before Paris. I don't want to continue this discussion on
the call. Before we consolidate we won't have traction.
gsnedders: Css-testing isn't on drafts.csswg.org as it's not known
by the system.
Florian: We'll delete it so that's fine.
Compatible alignments aren't always compatible
----------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1556
fantasai: There's an issue where we preform baseline content
alignment on two items if their align-self allows them
to both baseline align.
fantasai: However for last-baseline we'd need both aligned to the
bottom.
fantasai: Otherwise if the boxes aren't the same size they're in
different positions. If they're start to stretch fine.
Does that make sense?
* dbaron didn't follow
TabAtkins: The important bit is for last-baseline they need to be
end or stretch aligned to be compat.
fantasai: There's two types of baseline alignment. You shrink wrap
the box around content and move the box, that's self. Or
the box can fill the area and you align the content in
the box.
fantasai: There's two different properties so we can do both on a
flex item. If you want content baseline alignment you
need for that box to be stretch to fill the whole row.
Or you can do it if they're both start aligned so they
grow downwards.
fantasai: That's fine for first-baseline alignment, the box
doesn't have to fill the whole row. For last-baseline if
it's shorter than the entire row we have a problem. We
need to evaluate what to do. Our spec says if you're
bottom or stretch aligned you can do last-baseline.
That's fine but if you have a width or max-width you're
not necessarily stretched and you're aligned to the top.
fantasai: There's 3 ways to deal with this which are in the issue.
1 is exclude items with stretch and a height
constraining. Another is that if you have align-self:
stretch and align last-baseline you get bottom aligned
instead of top aligned.
fantasai: 3rd is exclude items that are stretched only if the
constraint is triggered.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1556#issuecomment-311463877
fantasai: These are all in the issue^
fantasai: We need to pick one.
<dbaron> I don't see why the growing thing requires start
<dbaron> I also don't see how last-baseline is different for the
growing thing
Rossen: Going through our grid updates and doing this for grid
items I'm pretty sure we did similar to #1 where
constriction takes precedence over stretching. That makes
sense and is mostly consistent except able cells.
Rossen: Third seems more hacky where we're trying to make the
fallback work. Does that mean constraints are ignored and,
if yes, that's weird.
dbaron: I didn't understand a bunch of the premises.
dbaron: I don't understand why you can't combine start alignment
with last-baseline align content by aligning a different
amount. Basically first or last with an alignment that
says stick to one side says you have to move and align the
content. I don't see why that's different between first
and last
TabAtkins: Let's say you have a whole bunch of vertical space. One
is start and one is center. They're small and there's a
ton of space so they don't overlap vertically. How do
you content align that? You can't without breaking self
align.
dbaron: I agree center is more interesting. but doing baseline
alignment generally requires you grow boxes. In the case
where they don't overlap you grow them by a lot.
TabAtkins: That would be so weird. I don't think there's an
obviously correct way to choose which to grow. I doubt
anyone would expect that to happen.
dbaron: You can...okay.
TabAtkins: Elements have to grow, but this would require to grow
an unbounded amount and it's not clear which should
grow. If they share an edge they have a fairly obvious
where they grow and how much.
Rossen: In any of that, why would you decide to override the min/
max constraint?
TabAtkins: We're not. If a max is there it can make stretch not
compat with end alignment. That's why one suggestion
was stretch falls back to end.
dbaron: What does fallback align mean?
TabAtkins: If you can't fully align based on self you fallback to
something that can be adhered to. If you can't grow
enough in the left over space, we fallback to start by
default.
Rossen: Your third option you said it's end or start?
TabAtkins: Yeah. In this case if you're trying to last-baseline
align a stretch item we would do an end fallback.
Rossen: Why? Why not start?
TabAtkins: It means you can't align because if your alignments
aren't compat there's no obvious way to make it work.
Rossen: You have an item that's too small and cannot grow and you
have to decide it goes to top or bottom. You're deciding
if it's last-baseline it goes toward the bottom. Why?
TabAtkins: So it's compat and last is possible. If it goes to
start you cannot do last-baseline alignment in a
reasonable manner.
<Bert> (Seems to me that, even if you align to the bottom, there
is still a chance that is needs to grow more than
max-height to align the last-baseline...)
<dbaron> OK, I think I'm ok with your suggested option #3 now.
Rossen: I need to look at test cases.
TabAtkins: This one is simple. Last line of text in a box. One is
last aligned, the other tries to stretch but can't get
far enough. It's impossible for the box to grow so that
the last line can get down and align b/c the height
constraint. Only want to make so is that the end edges
align. If they're not sharing same vertical space you
can't reliably do a baseline alignment.
Rossen: Proposal is option #3?
TabAtkins: We prefer option 3 because it means more things can
baseline align. It's changing a currently undefinable
default. Other 2 would also work, but they break the
baseline alignment and we feel in this case it's better
to try and honor.
Rossen: All three are acceptable solution.
<fantasai> +1 to everything Tab said
Rossen: Opinions?
<dbaron> I guess #3 probably seems better than #1 and #2, although
there is the random complexity...
Bert: Is it actually a solution? It seems there are two cases
where you get conflicts. Say you have two items you want to
align to last-baseline, first is very small with small
height, second is very tall.
TabAtkins: That's a natural break of baseline and is handled.
First small one overflows upwards. Since it can't,
it'll break the alignment and sit still.
Bert: So you say the three solutions aren't 100%, they just
improve the solution.
TabAtkins: Yes. The one you brought up is unsolvable, but what
we're trying to do is solve one where an undefinable
default is causing the break. We want to make the
default a little smarter.
Bert: I'm okay with option #3.
Rossen: Other opinions?
Rossen: dbaron preference?
Rossen: Oh, I see in IRC #3
Rossen: Let's call to resolve on option #3?
Rossen: Objections?
* tantek is also ok with #3
gregwhitworth: Would anybody see authors expecting for the stretch
to still be adhered to where it goes upwards? Like
it does #3 but still stretches.
TabAtkins: This is when max-height is in play and we honor that
over other constraints.
gregwhitworth: I was just curious if an author wants the inverse.
Rossen: Authors want rainbows and unicorns but we can't deliver
them so we need to honor the constraints and have an okay
default.
Rossen: I don't hear objections.
RESOLVED: Option 3 from issue
Rossen: Please add topics for Paris. I see we're done for today.
Thank you and we'll talk next week.
Received on Thursday, 13 July 2017 00:35:38 UTC