- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Sep 2017 19:06:37 -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.
=========================================
Flexbox
-------
- RESOLVED: Take this edit
(https://github.com/w3c/csswg-drafts/commit/5c66e72c402c427c7b0aa2bdbeca38bb16fb5133
)
as soon as dholbert gives approval.
- RESOLVED: Publish an updated CR of Flexbox.
Meta bug for line height
------------------------
- Implementors were requested to review the tests and assertions
Florian has compiled
(https://github.com/w3c/csswg-drafts/issues/1796#issuecomment-328713658
)
in order to work toward an interoperable line height.
Test for orthogonal flows in table cells
----------------------------------------
- The use case Florian was testing for is a valid use case and the
spec authors will need to edit the spec to clarify that it's
possible.
Radians considered useless without π
------------------------------------
- RESOLVED: Close issue #309 no change.
Font metrics calculation on elements which writing-mode doesn't
apply to
---------------------------------------------------------------
- RESOLVED: Add a clarifying note referencing cascade and then
close issue #1782.
Reconsider the meaning of 1fr
-----------------------------
- Conversation will continue on github, though there was a slight
preference expressed on the call to leave fr units as-is.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0026.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Thierry Michel
Anton Prowse
Jen Simmons
Alan Stearns
Lea Verou
Regrets:
François Remy
Melanie Richards
Geoffrey Sneddon
Greg Whitworth
Scribe: dael
astearns: I think we should start.
astearns: First item, any extra things to add to the agenda?
[silence]
fantasai: Is grid issue from last week on? I don't have the agenda
up.
astearns: There is an issue on the meaning of fr unit.
fantasai: That's the one.
Spec rec next steps
===================
astearns: Thanks Chris for run down on several items.
astearns: I'm on the hook for V&U tests. Anyone else have an
update to any item on the list?
astearns: I will follow-up over email to make sure we have up to
date ideas of where things are.
<florian> the thing I said when nobody could hear is that UI is
almost done: there are 2 (sets of) things that are still
failing the test suite: cursor:auto, and svg with no
fixed size as a cursor.
Flexbox
=======
Intrinsic sizing with ∑flex < 1 is broken
-----------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1735
fantasai: There was an error in the algorithm for flexing for
intrinsic size. We look at flexing algorithm in combo
with min/max sizes so we give container enough space so
when flexing algorithm takes place min/max are
respected. The error was when flex values add up to less
than one.
fantasai: TabAtkins and I proposed fixes, we think are correct.
We're happy to edit them in. If anyone wants to review,
great. We're pretty confident.
dbaron: Are implementors signed up to make these? Well, does
change match existing impl?
fantasai: Current implementations don't account for the flexing in
calc of intrinsic. For grid we have impl that do that.
This change is fixing a behavior that doesn't seem
right. I think chrome is the one that does that...I
don't remember other impl.
dbaron: My worry is if somebody tries to impl do websites depend
on old behavior?
fantasai: There's 2 steps of impl. 1 is if you have the algorithm,
tweak it. That would be to grid where I don't think we
have any dependency. I think for sure we should fix
that. For flexbox the algorithm overall isn't
implemented so changing the algorithm won't affect
implementations.
fantasai: dholbert has volunteered to implement the algorithm, but
he hasn't gotten to it.
TabAtkins: They implement a simpler version of the algorithm and
they are consistent in that, but it's wrong and
dholbert is offering to fix that.
fantasai: And that will make it more consistent with grid.
dbaron: And if dholbert succeeds will other impl follow?
TabAtkins: Yes, we will.
<TabAtkins> (Re: compat, we implement an *almost* correct version
of this for Grid already, the tweak to fix it only
changes grids with a sum of fr < 1.)
<TabAtkins> (Our Flexbox impl is currently the "simple and dumb"
version, which matches what Firefox currently does for
both Grid and Flexbox; if dholbert fixes in Gecko and
it sticks, we're happy to change ours to match.)
astearns: Has dholbert reviewed this proposed change?
TabAtkins: We pinged him, he hasn't yet been able to do a full
review.
fantasai: It's not difficult to do, it's a tweak to some math.
Largely it's a question of did we get the math right.
astearns: I'd be okay with getting it edited in, but I'm a little
concerned no one has checked the math. I'd be happier if
someone looked and said yea or nay.
fantasai: We can resolve and say it takes effect once verified.
astearns: But that doesn't get us closer to publication.
fantasai: It does b/c if we get replies today or tomorrow we can
get it into pipeline.
astearns: Does it make sense to publish even if this doesn't make
it?
fantasai: Yeah, there's a ton of changes. This is a CR so changes
publishing takes 6 weeks. Might as well start.
Chris: If it takes 6 weeks is dependent on how good DoC and
changes are and availability of Ralph and plh.
fantasai: DoC is compiled.
astearns: Any other comments on resolving or resolve pending
dholbert?
fantasai: I'd prefer to get resolutions in place b/c that will get
things rolling.
Chris: I agree.
astearns: You propose to resolve we take this edit as soon as
dholbert gives a thumbs up. Objections?
RESOLVED: Take this edit as soon as dholbert gives approval.
Publication of Flexbox
----------------------
<fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160526
fantasai: Here's the DoC^
fantasai: Two open issues. This one we resolved and another
jensimmons and I found. We should fix that, but we
should publish first since that one needs some thinking
and discussion. I'd like to publish with this open and
plan to fix in next round.
Chris: That's fine. We can put that in the request. Issue 2 & 4
don't have coloring. There was an objection on one issue in
GH and astearns asked if it was formal. Is changes up to
date?
fantasai: I believe it is, I'll check.
Chris: Okay, thanks. +1 to publication.
astearns: Other opinions?
fantasai: Changes is up to date.
Chris: Great.
astearns: Objections to publishing an updated CR of flexbox?
RESOLVED: Publish an updated CR of flexbox.
[cheers]
fantasai: I'll finish the edits.
Chris: I'll start writing the transition.
Meta bug for line height
========================
Github: https://github.com/w3c/csswg-drafts/issues/1796#issuecomment-328713658
astearns: I wanted to introduce this work because I think it needs
more review. I'd like dbaron and others to look at this
nest so we can have useful discussion and start
resolving things to make line height more interoperable.
florian: I think the result of my testing is we're more interop
then I thought. Spec is wrong. I think there's 2 places
we're not. One is how browsers fetch font metrics, there
are differences and I didn't try and understand them.
florian: One other exception is what happens with the first
available font when the space character is excluded from
unicode. We did resolve there recently, but I think we
went a bit too fast. I made test cases for every
assertion, so please go review. If you agree with me I'll
make PR for the spec. If you don't I'll look.
Chris: There's a commonly used trick where you use unicode to get
a swash ampersand and rely on a second font after the swash
first font.
florian: I think your trick only works in chrome.
Chris: Generally in FF too.
florian: Please look at my test cases and tell me where it's
wrong. In FF it goes with random stuff and speed of load
changes what you get. I have a test case.
Chris: Okay, I'll go review.
florian: Please everyone go review and based on that we can have a
spec that matches impl and impl that match each other.
astearns: Anyone else have something on this topic?
astearns: Thanks florian for doing this.
Test for orthogonal flows in table cells
========================================
Test: https://github.com/w3c/web-platform-tests/pull/6969#issuecomment-328598209
florian: Back at Tokyo I mentioned a few things with writing modes
that weren't impl especially with orthogonal table flows.
florian: The two things we have are if you set a max height on a
table cell in a vertical writing mode within a horizontal
writing mode table, is that supposed to work? I would
assume so, but that's not reliable. I'm not good enough
on tables to know if there's a spec that asks it to work.
florian: Do people know if that is somewhere?
[silence]
astearns: fremy and gregwhitworth sent regrets.
* fantasai considers that a Tables issue
dbaron: We did discuss about...was it min or max prop on table
cells in Paris? I think we decided it shouldn't do
something.
florian: That was min and I'm talking max. If you have a wrappable
line should it wrap?
dbaron: Yeah, the orthogonal thing makes it harder. There's a
piece to ignore, but which.
florian: If you have a long chunk of text in a table cell it's
possible to make it wrap is my expectation. I do not know
if there's a spec that agrees. I know we don't have
interop. Only one wraps.
fantasai: Your use case is totally valid and useful, so if we can
we should make that work.
<fantasai> florian, is the first one filed as an issue? So I would
file it as an issue against tables and say "This should
work"
florian: Other one is something I haven't written...
florian: This is when you start setting the height on the table
itself and see if that does anything.
<florian> https://wptest.center/#/json:{%22title%22:%22UntitledTest%22,%22html%22:%22%3Ctable%3E%3Ctd%3Exx%20xx%3C/td%3E%3C/table%3E%22,%22css%22:%22table%20{\r\n\theight:%20100px;\r\n\tborder-spacing:%200;\r\n}\r\n\r\ntd%20{\r\n\tpadding:%200;\r\n\tfont:%2050px%20/%2050px%20ahem;\r\n\tcolor:%20green;\r\n\twriting-mode:%20vertical-rl;\r\n\tbackground:%20red;\r\n}%22,%22jsBody%22:%22%22,%22jsHead%22:%22%22,%22watches%22:[],%22watchValues%22:[]}
florian: second test case ^
florian: This too behaves differently in edge and ff.
florian: If no one has table specs loaded in their brains we
shouldn't solve here. There is lack of interop, there is
a preferable behavior, so we should try and make that
possible and see if there's a spec that says it.
florian: I can write a spec test, but I don't know the specs well
enough to know if it's there.
astearns: Since fremy isn't on I think we should action him.
florian: He raised this and said he didn't know.
fantasai: Writing modes spec says rules for layout are analogous,
but I don't know what the rules for layout are. It does
mean the analogy needs to be taken into account.
florian: I don't know if analogy is sufficient. In the table
layout algorithm where it says what's into account or is
it logical/physical width and height...I don't think
that's all clear.
florian: I don't think writing mode is clear enough to define on
css table or 2.1 not written with that in mind. There's
the terminology for it.
astearns: Sounds like fantasai says it's not defined in writing
modes and it's probably not in tables
<fantasai> https://drafts.csswg.org/css-writing-modes-3/#orthogonal-flows
fantasai: Writing modes says [reads] parent controls positioning,
but child controls sizing, what width and height means.
Tables are more complicated an may need diff set of rules
florian: Yeah, it's something in tables about to determine table
width you get width of every cell.
fantasai: That was probably fine when we said do magic in 2.1, but
looking at grid may help us figure out tables 3.
astearns: This is part of what we're doing table spec is to find
this not interop and defining something.
astearns: I do think it's on fremy and gregwhitworth to figure out
what table spec should say.
florian: I'll ask for permission to remove my current pull and
make a new one with this.
astearns: Thanks for test cases.
Radians considered useless without π
====================================
github: https://github.com/w3c/csswg-drafts/issues/309
astearns: Looks like we want approval to close no change.
fantasai: Basically the argument is you need pi to use radians,
but we have turns to you can divide by 2 and use turns.
<fantasai> turns = TaURadiaNS
Chris: +1 for closing. I think it's very clear.
Chris: The reason we have radians is people can spit it straight
out without converting to degrees first.
astearns: And that there is no impl that wants to add makes me
think we should close.
<florian> +1
astearns: Obj to closing no change?
RESOLVED: Close issue #309 no change.
Font metrics calculation on elements which writing-mode doesn't
apply to
===============================================================
github: https://github.com/w3c/csswg-drafts/issues/1782#issuecomment-328222293
astearns: There's a proposed change and I think dbaron had a
comment this might be covered?
fantasai: Possible.
dbaron: There is text in 2.1 saying applies to doesn't effect
computed unless it explicitly says it does.
fantasai: That's fair. Do we need to clarify in spec?
dbaron: Possibly. That also feels like it should be in L3.
fantasai: There isn't a L3 of that chapter.
dbaron: It's in definition of computed value which I think would
be cascade. I didn't really look at that.
dbaron: Actually, it's in. I think it's okay.
fantasai: You recommend close no change?
dbaron: I think so unless someone sees something else?
astearns: Would a note make sense?
astearns: For impl clarity?
fantasai: I can change the proposed text into a note and reference
cascade.
astearns: Objections to add a note?
dbaron: sgtm
fantasai: If there's a suggestion on section, we can figure that
out. I might stick it in module interactions.
astearns: Sounds alright.
RESOLVED: Add a clarifying note referencing cascade and then close
issue #1782.
Reconsider the meaning of 1fr
=============================
github: https://github.com/w3c/csswg-drafts/issues/1777
fantasai: There were good comments. I need to dig through those.
So, thanks for commenting.
astearns: Does anyone have an opinion that has not commented on
github?
TabAtkins: I haven't dug deep. I need to spend time thinking about
it.
* tantek also needs more time to understand implications
<tantek> Without having looked into it deeply, I would tend to go
with with Rachelandrew's analysis
jensimmons: I'd like to have an opinion, but I feel like I need
examples to understand impl and I haven't done that.
fantasai: Right now, as overview, min size of a grid container can
take starts with min track sizing and if there's extra
space the tracks will expand until reach max. Right now
fr has an impl min of auto which by default is the min
content, but if they have min width or height it uses
that. Max track is the flex unit.
fantasai: Same is true in height. Proposal is instead of using min
for fr, we use 0 so content will overflow track if it
can't shrink to 0
TabAtkins: Reason for current is it matches with flexbox. If you
say flex 1 you start with min-width of auto. This works
the same way unless you override.
fantasai: Where this becomes confusing is when they use track
sizing for a large amt of content which they expect to
get clipped or shrink and we're enforcing a min on that
content.
TabAtkins: I feel it's a lot like the confusing part of flexbox
where the min of height is the auto and that's
something larger then intended.
TabAtkins: It's the blow up in a good way where you don't lose
anything, but it's unexpected.
TabAtkins: This is exactly us porting the flexbox behavior.
fantasai: That's the background. We can all look more deeply and
discuss on GH.
astearns: Thanks to rachelandrew and fremy for already commenting
there.
astearns: Anything else on this?
jensimmons: Thanks for the info, that makes it clear. My first
take is I hesitate to do this b/c the way fr works
right now is incredibly useful. I can see the want,
but I don't know if it's right. We'd break stuff if we
do this, but the way it's written is also the most
useful way to use fr.
jensimmons: I think education may be right instead of a change.
astearns: Thanks jensimmons. Sounds like we should have a few more
examples in the issue going through impl of actual
email. I think we should take this to GH and come back
in a week or two.
astearns: I believe that's it for the agenda.
astearns: Reminder TPAC is coming. Register before Oct 7 to get
the lower price. Anything else for the agenda this week?
astearns: Everyone gets 15 minutes back!
Received on Wednesday, 13 September 2017 23:07:39 UTC