- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Oct 2016 20:27:30 -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.
=========================================
Upcoming 2017 Meetings
----------------------
- There is a move to finalize the April/Japan dates so anyone with
conflicts should put them on the list.
Merge csswg-test into web-platform-tests
----------------------------------------
- RESOLVED: Keep our should/must/may testing in place and put it
into the web documentation.
- RESOLVED: We start the list of steps given at
https://lists.w3.org/Archives/Public/www-style/2016Oct/0088.html
keeping the test harness in working order as each step
is done. We let gsnedders and those doing the work
decide when to move steps.
url parsing contradiction between 2.1 and Syntax
------------------------------------------------
- RESOLVED: Remove CSS grammar section in CSS 2.2 and have a
pointer to CSS syntax
Definition of line-height calculations contradicts itself
---------------------------------------------------------
- fantasai will write up proposed spec text to describe Blink and
Gecko do.
The minimum and preferred width of a multicol is not defined anywhere
---------------------------------------------------------------------
- The definition is in Syntax spec.
Positioning boxes with { float:left; width:0px; }
-------------------------------------------------
- The topic will wait until next week to give people time to
review the github comments.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0089.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Vladimir Levantovsky
Chris Lilley
Peter Linss
Liam Quin
François Remy
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
Rossen Atanassov
Myles Maxfield
Theresa O'Connor
Anton Prowse
Hiroshi Sakakibara
Greg Whitworth
Upcoming 2017 Meetings
----------------------
astearns: We should start. Does anyone have anything extra to add
to the agenda?
astearns: We have definite plans for the Seattle meeting in
February so people should start making travel plans.
<jensimmons> astearns: you just said Feb — but you meant Jan, yes?
astearns: Seattle is Jan 11-13.
astearns: We're confirmed for Tokyo in April and we're trying to
fix on which day. 3rd week in April does not have
mentioned conflicts. If you have things going on that
you would like to avoid overlapping, please respond to
the thread.
astearns: Are there any April days we should avoid that people on
the call know about?
<tantek> avoiding weekends and M/F is good :)
<dauwhe> April is the cruelest month, schedule-wise
astearns: If you do come up with something please respond on this
list. We're trying get get those days fixed ASAP.
Merge csswg-test into web-platform-tests
----------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Oct/0088.html
astearns: gsnedders put this up right after TPAC. I summarized the
responses here ^
astearns: Basically, details on step 5, we have to make sure
everything is documented and the test harness must keep
working while we transition.
astearns: Any further comments on this transition?
ChrisL: What happens about reviewing? I understand there's a new
model for web platform where tests aren't accepted until
people feel they're good enough. Is that correct?
gsnedders: We have 2 review models. Through mercurial we add it to
the repo and it gets reviewed eventually maybe. Through
github the pull request only gets merged after review.
gsnedders: In web platform tests in principal we'll only merge
after the pull is approved.
<tantek> One review path for tests? Why not two review paths for
tests?
ChrisL: I guess that's clear. The tests I wrote for the spec I'm
writing I just put them in there. Should that be done
differently while we're still using the test harness? I
want tests to show up and flag bad tests.
gsnedders: In general things have gotten merged quickly in web
platform tests.
astearns: I think it makes sense to use web platform tests model
for simplicity but we'll have to step up the working
group's reviewing game to make sure our pull requests
are getting merged. We can't reply on the people
reviewing now to review CSS tests.
ChrisL: Right.
tantek: I've got a policy question. Since we're talking about
review models I heard a rumor at TPAC that only MUST are
tested in web platform tests and that's in strong
disagreement from my understanding.
tantek: I wanted to get it on the record that we as a group...my
understanding is we find it to be good policy to have
tests on any SHOULD or MUST statements in our specs.
That's my understanding.
<Florian> I agree with Tantek
tantek: If that's wrong I'd like to know.
fantasai: We accept tests for MUST, SHOULD, and MAY if the MAY is
the direction we'd like to go to. It's distinguished
using metadata. There's a flag showing what it is so
that when it is in conformance test results it shows.
<Florian> Agree with Fantasai as well.
tantek: I like that we accept tests for any MUST, SHOULD, or MAY.
That's right and we should document that explicitly for
using web platform tests. We should also push that
upstream to web platform tests in general.
tantek: I'm requesting it because the rumor was strong enough I
was concerned and I would like to push in the other
direction that we as a group have experience increasing
interop by doing tests on MUST, SHOULD, or MAY. That
should be documented and pushed upward.
tantek: That's my request.
astearns: Sounds good to me. gsnedders do you see a problem with
keeping that for our tests?
gsnedders: Not really, I don't think so.
tantek: I checked web platform tests for a policy and that
documentation is a maze. If I was a new comer I'd be
totally lost. Whomever works with that group this kind of
policy needs to be explicit in the docs.
gsnedders: That's item 3 on the list of things to do.
tantek: This is a specific improvement. I realize that the
documentation is a larger task. This is one thing that
would make a difference.
RESOLVED: Keep our should/must/may testing in place and put it
into the web documentation.
ACTION astearns put the bit about should/must/may tests in the
documentation
<trackbot> Created ACTION-797
<tantek> Thank you very much astearns. Really appreciate it.
<gsnedders> tantek: (I don't think this is worth doing on the
call, but basically my objection to small changes is
that they don't help anyone because nobody will find
them.)
<gsnedders> tantek: (objection is too strong)
plinss: Are we resolving that we're doing the migration now?
astearns: I'd like now?
plinss: We're not ready on the harness to shut down now.
gsnedders: We should follow the steps laid out on the e-mail.
astearns: Yes, I meant start the steps now.
plinss: That's fine.
gsnedders: And resolve to do each step.
<ChrisL> I would not want to put tests into a repo where we can't
get test results and run tests.
astearns: It would be better to resolve on the entire list and do
them in order. We don't need to wait on decisions for
each step.
Florian: I want to go through all the steps and I'm wondering if
we need to check if we're ready for the next one.
plinss: I'm okay with the people doing the work decide each step
is done. My concern is I don't want to move tests out of
our repo until the infrastructure changes are in place.
ChrisL: Yes, I would be concerned about that as well.
astearns: And that's what I was getting at in my summary that we
should maintain test harness on each step.
plinss: Yes, I just didn't see that explicitly listed.
astearns: Any other discussion?
astearns: Proposed resolution: we start the list of steps keeping
the test harness in working order as each step is done.
We let gsnedders and those doing the work decide when to
move steps. Obj?
RESOLVED: We start the list of steps given at
https://lists.w3.org/Archives/Public/www-style/2016Oct/0088.html
keeping the test harness in working order as each step
is done. We let gsnedders and those doing the work
decide when to move steps.
url parsing contradiction between 2.1 and Syntax
------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/412
astearns: fantasai added this a month ago.
gsnedders: We postponed it because you wanted dbaron on the call
is my memory.
astearns: And is dbaron on?
dbaron: Yeah.
TabAtkins: The issue from gsnedders is there are a few tests in
CSS2.1 that exercise URL parsing. That changed in the
syntax spec in ways brought up by dbaron and from what
I recall he was fine with those changes. It means it's
different from 2.1 and normally we backport but in this
case it would be extraordinarily difficult to do so.
TabAtkins: 1) We need to change the 2.1 test and I think gsnedders
wants a resolution he's allow to do so
TabAtkins: 2) Resolve we don't need to change 2.1 because it's too
difficult
astearns: While editing the change would be difficult would a note
make sense?
ChrisL: That's what we're doing with 2.2 right? We're removing
parts and pointing to specs
TabAtkins: I'd be for 2.2 removing CSS grammar and pointing to CSS
syntax. We shouldn't imply CSS is parseable with a
grammar approach.
ChrisL: I agree. Can we resolve on that?
astearns: Proposed resolution: to remove CSS grammar section and
have a pointer to CSS syntax.
astearns: Objections?
RESOLVED: Remove CSS grammar section in CSS 2.2 and have a pointer
to CSS syntax
gsnedders: Are we ignoring 2.1 because 2.2 draft will be different?
dbaron: In the old tests we want a syntax version of those tests
and then 2.1 can go away.
TabAtkins: I don't think we need to get rid of, but the page
testing syntax quirks there's a handful that are
slightly wrong. We can just fix those and keep the rest.
plinss: If you're changing tests so they're not 2.1 compat we
should remove those and link to syntax.
fantasai: We should backport. 2.1 should be errata-ed
ChrisL: TabAtkins said we can't backport.
gsnedders: And 2.2 will match syntax so the tests will be right by
2.2.
gsnedders: They will follow the level 2 spec.
fantasai: Okay.
astearns: It makes sense to remove 2.1 links as we update the
tests to remove confusion.
astearns: gsnedders you'll make the edits?
gsnedders: I presume so.
astearns: Anything else on this topic?
Definition of line-height calculations contradicts itself
---------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/391
astearns: There's been discussion on the issue since it was
agenda+ by fantasai. I don't know if things got resolved.
fantasai: I believe not. There needs to be some cleanup of that
section judging by antonp's comments. Issue itself
stands. antonp pointed out the intention of the spec.
astearns: You're looking for a resolution to make this change?
fantasai: Yes.
astearns: Would it make any sense to put this edit into 2.2
instead?
fantasai: Probably into both. I'm not sure what we're doing with
2.1 in terms of maintenance.
fantasai: I think it's up to Bert if he wants to maintain the
errata. We're supposed to technically.
ChrisL: There's no point in doing so. 2.2 has been published and
2.1 says don't look at this.
fantasai: That's fine.
fantasai: So it needs to be updated in level 2 and level 3.
astearns: Proposed resolution: make this change into 2.2?
fantasai: Let's call it 2. Say the line height is a box equal to
the line height value and doesn't get adjusted by
fallback fonts shifting baselines.
<tantek> if browsers are all already doing this, why not errata
2.1?
astearns: Objections to making this clarification to 2.2?
ChrisL: I'd like to check it's clear enough with Bert.
ChrisL: Is Bert on?
ChrisL: I guess we need to minute carefully.
dbaron: I think...this was prose we explicitly decided to add to
2.1 despite lack of implementation of the concept.
<tantek> yes - what dbaron is saying
fantasai: The spec contradicts itself.
dbaron: Okay.
<tantek> fantasai, that's an even stronger reason to errata 2.1.
SteveZ: Can you clarify the contradiction?
fantasai: In the first comment it says [reads]
fantasai: If the height of the inline box includes all glyphs and
half leading it'll be more than one. The last sentence
contradicts. Either it's exactly line height or it
encloses all glyphs.
dbaron: Or you determine half leading based on the expanded height.
fantasai: You do it per glyph and half is above a and the other
below d.
dbaron: I didn't think that's what you were supposed to do.
fantasai: It's not what people do or spec intent, but that's the
result of the prose.
fantasai: That's the initial comment, 3rd has a test.
dbaron: Is it worth trying to find out what implementations do?
fantasai: Blink and Gecko use first available font metrics and
it's exactly line height. It ignores shifts from
fallback fonts. I didn't test Edge.
astearns: Proposed edit is make the last clause of the last
sentence correct that it's exactly line height and
remove taking all glyphs into account.
SteveZ: My memory may be bad, but I would have thought the last
sentence was incorrect. Line height never produced a line
that was line height high so lines won't collide.
fantasai: That's because it adjusts for children. In a single
inline box where you're only dealing with fallback the
height of that box is exactly line height in blink and
gecko.
SteveZ: Should be clear it applies if there's no font change.
fantasai: Yes. It's not talking about the children.
SteveZ: If I have a list of fonts and one of those has italics
with a huge over-swing I'd like the ascenders to take
effect. That's not fallback. I don't have a font that does
all the stuff.
fantasai: I think this is a case where if you're making an
explicit change in font we'll accommodate your new
metrics. If you're falling back we don't want that to
make any changes in line height. If we changed to adjust
for the slight shifts anything trying to precisely align
text might break.
fantasai: I think this is an opportunity to fix the spec to be
consistent with implementations and cause less jitter.
SteveZ: I think the case you outlined I agree. I don't know how to
distinguish between when I have a lot of fallbacks because
nothing has everything I want. I want to use the metrics
of everything I'm using. The list if the order in which I
want characters searched for, not the metrics used.
fantasai: You want line to line height to be consistent. You
wouldn't choose very different line height fonts as your
fallbacks in your case.
astearns: In any case, I think it would make sense to have to spec
say what browsers are doing with line height. And from
the test case the fallbacks are not being taken into
account.
SteveZ: I would like to hear Bert's opinion before we decide.
astearns: How about this. fantasai has outlined the problem but
haven't come up with the text you would put into the
draft. Can you update the issue with that prose and
we'll discuss there?
fantasai: Sure.
ACTION fantasai come up with the prose fix for the definition of
line-height calculations contradicts itself issue (#391)
<trackbot> Created ACTION-798
The minimum and preferred width of a multicol is not defined anywhere
---------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/420
frremy: I discovered this because in Edge we have a strange way of
computing. When I tried to find out the spec behavior I
couldn't find it so it would make sense to decide what to
do.
TabAtkins: It looks like it is defined now in Sizing. Min and max
are defined there and it matches FF.
frremy: So it's in Sizing spec. Okay.
fantasai: It's in sizing because multicol wasn't being maintained
and this was significant stuff. We put it in sizing and
it got pushed to level 4.
frremy: That's fine. If you have it defined that's perfect.
Florian: If we do want to push in multicol I'm an editor but I
think it's better where it is now.
Positioning boxes with { float:left; width:0px; }
-------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/576
frremy: Basically this is a strange case. When you have a
float:left and it's 0px it effects the line. The problem I
have, technically you can put the float there and edge
does it but it seems like blink decided it's not big
enough to fit the float.
TabAtkins: I discussed with my team and we think ours is right
behavior. It's when the proceeding float is = or > than
size. Same size everyone agrees. When it's bigger we
shift the float and I prefer that because it matches
the general way you would define line breaking,
especially it matches the flexbox algorithm.
TabAtkins: It gives you the exact behavior Chrome has if you apply
it to inline and floats. If one thing on the line
overflows the 0px thing goes to the next place.
dbaron: We had made a bunch of edits to 2.1 that FF hasn't
implemented. That's not the best of indicators.
dbaron: I'd like a change to read antonp's reply.
Florian: In addition to the similar there's also an argument that
pushing to the next line minimizes the chance of things
overlapping.
astearns: Proposal to have this moving to the next line behavior
when the line has already consumed more than the
available space. Would it go into the box module or is
this a css 2 edit?
TabAtkins: I hadn't digested antonp reply, but from my reading 2.1
doesn't fully define and therefore should be edited.
<ChrisL> 2.1 or 2.2?
<tantek> do we not already have a documented / agreed WG policy
for 2.1 errata vs. 2.2 additions/changes?
<astearns> I believe the policy is to errata 2.1
<tantek> astearns: for all changes for 2.2?
<TabAtkins> ChrisL 2.2, sorry.
<TabAtkins> I just read whatever's at drafts.csswg.org/css2
<tantek> is just trying to understand if we're case-by-casing
everything, or if there is a general 2.1 vs 2.2 policy
dbaron: It defined the case except for what the definition of
shortening a line box.
frremy: [missed] I'm fine saying we should match Chrome and Gecko,
we should make sure we properly state it in the spec.
dbaron: This area is a little dangerous because the reasons impl
are doing things in test cases are mostly related to other
bugs, not what we're discussing.
frremy: What's the plan? Take more time? Resolve today? I'm fine
with pushing back if we need more time.
dbaron: I'd like more time to read antonp's reply.
astearns: Can I put it on next week's agenda?
frremy: Yeah.
astearns: dbaron is that enough time?
dbaron: Sure.
<dbaron> This is just the case of Anton replying here because he
saw it on the agenda, and me not seeing his reply because
I looked through the agenda before he replied.
Trying to find a topic
----------------------
astearns: We didn't do Test DoC issues because Myles wanted to be
on. There's 6 items from the TPAC agenda and 12 minutes.
Anyone see anything in the overflow that could be
usefully discussed in 12 minutes?
Florian: I think the CSS Containment Terminology question can be
removed from the agenda?
astearns: Okay. I'll take that off the list.
astearns: @apply item?
TabAtkins: I don't believe it's ready right now. I need more
private discussion before it's worth going public.
astearns: I'll take that off and wait for it to be agenda+
fantasai: We still have first/last baseline issue open.
fantasai: It needs to be resolved before we can complete alignment.
frremy: Do you have a link?
<fantasai> https://github.com/w3c/csswg-drafts/issues/210
astearns: ^
fantasai: It's a syntax and property interaction issue.
fantasai: It would be good to get thoughts/comments/reasons why
one is better. We have 3 options so far.
fantasai: Another alignment was if we should add a shorthand for
align-content and justify-content. Two 2 names were
place-content and arrange-content.
<jensimmons> link?
TabAtkins: Were did that come from?
fantasai: Another issue.
TabAtkins: I haven't seen that one.
astearns: I'm not seeing an align issue that mentions place in
github.
fantasai: I'll try and file it maybe it was just draft.
<fantasai> align-foo + justify-foo = what-foo?
fantasai: We're bikesheding.
TabAtkins: Yeah, we need to find it. I can't find it in issues or
the draft. We shouldn't discuss until it's exposed
somewhere.
<jensimmons> yeah, I’d love to help with that…
astearns: Let's put the first/last baseline issue on for next
week. We'll find the discussion about a shorthand and
maybe put that on as well.
astearns: What is the pseudo element issue?
fantasai: I don't know.
TabAtkins: There are issues with the draft to go through.
fantasai: I don't think any are ready.
TabAtkins: Right.
astearns: Table wrappers we couldn't do.
astearns: Last is clip-path
TabAtkins: I discussed with a team mate, but we're not ready.
astearns: I'll do agenda wrangling for next week. Anything else?
<tantek> appreciates astearns agenda-wrangling, especially for
items for drafts we're trying to take to CR by end of 2016
<fantasai> https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
fantasai: I posted the URL to the copy/paste issue and I'll add it
to the DoC
fantasai: Look that over, that's on the Text list.
astearns: Okay. Could this be opened as an issue on a draft?
fantasai: I believe it was filed in email but I can add it to
github. I'll do that.
astearns: Anything else?
astearns: Then I think we're done for the week.
astearns: Thanks everyone for calling in.
Received on Thursday, 13 October 2016 00:28:33 UTC