- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 3 Aug 2016 21:03:39 -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.
=========================================
Start adding things to TPAC agenda
----------------------------------
- Please add items to the wiki, including those that would require
joint meetings.
- gregwhitworth was actioned to find out exactly what the plan is
for Houdini at TPAC.
Ideographic character unit
--------------------------
- RESOLVED: Accept text as proposed: https://drafts.csswg.org/css-values/#ic
lh and rlh line-height units
----------------------------
- RESOLVED: Add lh and rlh with a note on use cases it doesn't
solve and a link to max-lines.
CSS Variables transition to PR?
-------------------------------
- gsnedders is going to confirm that the test suite provides
adequate coverage. If he finds that it does, the group will
vote on PR next week.
Transition to CR for Grid?
--------------------------
- RESOLVED: Take Grid to CR
===== FULL MINUTES BELOW ======
Agenda: http://lists.w3.org/Archives/Public/www-style/2016Aug/0006.html
Present:
David Baron (IRC Only)
Bert Bos
Tantek Çelik
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Florian Rivoal
Geoffrey Sneddon
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Rachel Andrew
Rossen Atanassov
Dave Cramer
Daniel Glazman
Michael Miller
Alan Stearns
Scribe: Dael
Start adding things to TPAC agenda
----------------------------------
Bert: Not that many here yet, but let's get started.
Bert: Don't forget to present+ so we know who is here.
Bert: Anything we need to talk about not on the agenda?
<bkardell> I sent a post to www-style - I'd like comments but I
don't know if it needs to be on agenda.
<bkardell> https://lists.w3.org/Archives/Public/www-style/2016Aug/0004.html
Bert: This is a reminder. TPAC is coming and we need an agenda. If
you have anything please put it on the wiki. Topics, issues.
Also think about topics for joint meetings and such. Please
look at the wiki and put your ideas here.
Bert: Address is: https://wiki.csswg.org/planning/tpac-2016
<myles> where is everybody?
Bert: That is a good question, it's vacation season.
<fantasai> Tab is on a bus. :/ He should be here in 10.
??: Is there houdini stuff planned?
Bert: That's a good question.
bkardell: Would we main stream it into CSS?
Florian: I believe there's some Houdini planned, but I think
something more official would be good. Having it off
schedule makes it hard to coordinate.
fantasai: Would it make sense on Thursday/Friday?
Florian: I think Thursday/Friday was the plan. It's unfortunate
it's not on the official schedule. The earlier we know
the better we can avoid conflicts.
<dbaron> There was certainly an email thread about planning
Houdini stuff, which I think concluded on Thursday
despite conflict with the AC.
<dbaron> http://www.w3.org/mid/BY2PR03MB192220DEF29185D440EF4D29B630@BY2PR03MB192.namprd03.prod.outlook.com
Bert: It might be hard to dedicate a room. The rooms are on a day
by day basis so fewer groups doesn't mean empty rooms. But
was can always ask.
Bert: Anyone feel like taking an action?
gregwhitworth: I suggest we wait until next week because I've sent
asks to a lot of places, but Rossen will be back
next week and we can make him find out.
ACTION gregwhitworth to follow up with Rossen and Shane about
Houdini and TPAC
<trackbot> Created ACTION-784
Bert: Anything else on TPAC?
Florian: Reminder that if you're interested in Air BnB let me
know. And if you're usually Air BnB and not interested
let me know so I know it's not slow replies.
Bert: Yes. So contact Florian if you want to share AirBnB. I have
a hotel room, so don't come to me :)
Ideographic character unit
--------------------------
<fantasai> https://drafts.csswg.org/css-values/#ic
fantasai: There's a draft definition for ic character. We can call
it ich or whatever. There is a definition in the spec if
anyone wants to review. Florian had comments that are
handled.
fantasai: ich would be maybe more clear, it's more clear though
longer
Bert: I don't have a preference. If people have they can speak up.
myles: Name aside the idea seems fine to me.
Florian: As mentioned, I like it. I had a minor comment and it's
fixed.
Bert: The text mentions used font?
fantasai: It's the font used to render that character. Whatever
font you find that character is the font you use to
measure that character. It's a frequent case that you
don't have a water ideograph and you have to go through
the fallbacks to find it and measure. Same process as
the ch unit. If you have a font without a 0 glyph you go
through fallback. Most fonts have 0 but it'll be more
common to have that with CJK.
Bert: As long as it's clear in the text it's good.
fantasai: Yep. [reads spec]
Florian: And the phrasing is identical to the ch unit.
Bert: Sounds good. Anyone think it's not?
Bert: shall we conclude?
<bradk> Maybe the unit name should be a Chinese/konji character.
Florian: I think so. For the name ic or ich no one will guess what
it means. ic is less typing. Same for most units. you can
guess mm but the rest you have to know.
Bert: I don't see strong opinions on name.
<dbaron> 'ich' is more clearly related to 'ch', but looks rather
too much like 'inch'
RESOLVED: Accept text as proposed.
fantasai: We can look at the name if someone has a strong opinion.
lh and rlh line-height units
----------------------------
fantasai: Back in 2014 there was a proposal for lh and rlh. These
would be useful. You want one unit of line height
spacing. lh is the computed line height and rlh is the
root line height. Proposal is add to V&U 4.
Florian: In CJK typography you size the height of the content as
an integer of lines. You can use it for that.
Florian: Independently they're useful and the line grid proposals
combine well with these.
myles: I'm a little confused about some of the comments. The first
line can be taller than the second are we using the used
height of the line or?
fantasai: It's what the prop value computes to.
myles: So if someone says make this 3 lines tall and it's 2 lines
tall the user will be confused.
fantasai: The only time you want the line height to be the height
of the line is if you're measuring the height of the
element. If you want the margin height to be 3 lines
tall you don't know which line to pick. If you want to
limit and element there's a proposal for max-line to
have that effect.
fantasai: This is a unit to be used for measurements in any
dimension so it's meaningless to match any specific line.
Florian: If you want just 3 lines it's the max-lines property. If
you're using this one to size a number of lines in the
content area, that's common in printing. You set the page
size and say content is 30 lines and the margin is auto.
And you use line grids to get the heights you want, but
the area is sized to a number of lines.
myles: The problem I'm worried about is if you set the content
area to be 30 lines, that doesn't mean it'll have 30 lines.
I'm trying to avoid that having 29 lines.
Florian: I think that's fine. That's something you get when you do
this. You have to be careful the content you put in or
use the line grid things. Or you have a long form
document you'll have it line up. It's a size, not a count
of lines. If you want a count you have to use other
things. But they combine well.
myles: I understand it can work correctly if you plan every glyph
of every string, but fonts fallback often. I'm worried
about adding a property where it's a common case to get it
wrong.
Bert: That's an interesting problem, but that's not what this unit
is trying to solve. It's a short hand to doing ems and
calculation.
Bert: The problem with fixing lines is a bigger problem.
Florian: I want to solve that as well.
Florian: But let's say you want to draw a border and line up the
content and size it...if you're trying to use this for a
line grid you'll fail. It doesn't do that.
myles: The difference between the user saying make this 3 lines
tall and the user doing some math is that the user has said
they want it to be 3 lines, but if the user does that
calculation the browser obeys. If the math turns out not
correct that's an error on the page author, not the browser.
<SteveZ> There is also a possibility of introducing a circularity
if LH uses actual line heights versus computed LH
TabAtkins: Note there's no concern on font fallback. If you put in
an image it may make the line something unexpected.
Florian: Or you do an H1.
Florian: Things can happen, but not font fallback.
myles: Lots of things cause this to do the wrong thing.
Florian: It's the same as if you say width is 30ch and you put an
image and so you don't have 30 characters.
myles: It's the same problem, but it is a problem.
fantasai: Main use case isn't the height of a specific elements.
It's the fragmentainer. It's not I want only 30 lines in
this element. For that you want max-lines.
fantasai: lh lets you use line height for other purposes. For
fragmentainers you don't want max-line. You want all
your pages 30 lines tall and if your content is taller
it paginates. You don't want the height of the page to
vary depending on content. This is a different use case.
We want both, but right now we're discussing this unit
that does things that max-lines doesn't allow for.
fantasai: You can technically already do this, but you do a bunch
of calc against an em but you have to go back if you
change things and it's a maintenance problem. This unit
is to make it easier.
Bert: To summarize, it's convenient on one hand. On the other the
name suggests it does something else. Is it a name thing or
deeper problems?
<gregwhitworth> I would like to know how much author confusion
would occur with this
myles: I guess I'm agreeing. The issue is not that I think this
concept shouldn't exist. I'm worried the user will see
height 20lh and the user will think there should be 20
lines.
Florian: That would be worse if called 20 lines.
gregwhitworth: I think part of the problem is the first example in
the e-mail says n lines on a page. So the example
makes it seem like it's root lines.
<gsnedders> gregwhitworth: a fair bit, because line-heights
surprise people often enough in general
<tantek> agrees with gsnedders re: line-heights surprise people
often enough in general
<gsnedders> I mean they confuse *me* as an author. And I like to
think I have a good idea about how they work.
fantasai: That is a use case where this is meant to be used. The
height of the page being 30 lines is what you use. You
want every page to be the same height and if it's filled
with text it's 30 lines. If there's images or the like
it'll paginate, but the ideal height is 30 lines tall.
So if it's just text there's no justification. For CJK
they want to be able to specify the width. It's
monospace. So on a line 100% CJK it doesn't need
justification.
fantasai: Most lines aren't 100% CJK but you want to design the
page so when it is there's no justification space.
fantasai: You assume all text content and if it isn't, which will
happen, pagination takes care of it. This isn't a case
for non-paginated content. It won't work well for I want
this to be 4 lines tall.
gregwhitworth: I'm more asking author confusion. Looking at this
I'd read it that way. I see a lot of people
expecting what myles says. You guys know the space
and if there's a large reason for it, great. I just
foresee a lot of authors thinking this solves the
max-line problem.
Florian: I tend to think people will misunderstand things in
general. People understand how heights work, though.
They're not magical.
Bert: I think we know what the problem is. Do we have proposals
for bringing the viewports together?
myles: I think if we change the name to something that describes
what it does...no one likes that. Maybe add a note in the
spec saying this is for x, if you want y use max-lines.
fantasai: I'm happy to add a note.
SteveZ: I disagree with Florian. Line height only defines the
height if it's particularly [missed]. Calling it the line
height is how it's used in CSS.
<tantek> wait how is that useful?
<fantasai> tantek, we were just discussing this for like 30min
Bert: So the question: Do we add this unit? Or do people want to
object?
Florian: I'm in favor
Bert: It's two units. lh and rlh. Do they need to be discussed
separately?
<ChrisL> +1 to both
<SteveZ> +1 for both
tantek: I'm a little bothered by what SteveZ said. I find the
justification that it is the computed line height
non-empathetic to what authors deal with. From authoring
view if you're trying to base on the line height
physically and you don't get the result you're creating
another set of those CSS is Awesome mugs.
fantasai: tantek, there are two incompatible line based heights.
One is I want this number of lines based on the lines in
that box. The second is I want it based on the ideal
size of the line and I don't care about the content.
Both have use cases. We're not handling the first one
here because you can't do it with a unit. That's the
max-lines. The second case the unit is the right way to
do it so we're adding it.
fantasai: We need both these things.
tantek: Do you have a link to where these use cases are documented?
Florian: You can start with JLreq. It documents how it's normally
done in Japanese typography using ideal empty lines and
the margins fall out of that.
<fantasai> https://www.w3.org/TR/jlreq/#page_formats_for_japanese_documents
<dbaron> maybe it's more valuable to work on line grid than to
trick developers with a unit that won't do what they want?
<dbaron> aren't many of the use cases people would want
line-height sized things actually substantially more
complicated, and probably use cases for line grid rather
than units?
<gsnedders> dbaron: that only solves the first of what fantasai
just said after that, I think.
<gsnedders> dbaron: and I think line grid is the right solution
for that.
myles: From fantasai's argument, maybe it would be valuable if we
only added both these properties at the same time.
Max-lines and this new unit so they exist together since we
need both.
<gregwhitworth> max-lines is going to be a mess to actually solve
generically
Florian: They're for different use cases. They're similar on the
surface, but they're doing different things.
Florian: I don't see why they should be coupled. We have max-lines
in various drafts already so we're late adding this one.
tantek: I think myles' reason is because there are multiple use
cases. When we introduce one authors will try to use it
for either use case and half those authors will be
disappointed and think it's buggy.
tantek: If you want features to succeed presenting both educates
the authors.
<Florian> Max-lines is already defined there:
https://drafts.csswg.org/css-overflow/#max-lines
<fantasai> https://drafts.csswg.org/css-overflow/#max-lines
Florian: max-lines is in the spec, we can point to it.
fantasai: If you want to introduce both simultaneously, we're late.
tantek: I don't understand the we're late comment. If you
introduce one expect confusion
Florian: We've introduced one. If you want both introduce the
second one.
<tantek> to be clear, I'm not objecting to introducing just one,
I'm merely adding to myles's point, and trying to set
expectations accordingly (that one-only = more likelihood
of confusion). Defer to WG to decide on that.
<Florian> This section of JLREQ talks about how pages are
traditionally sized in Japanese layout as a function of
the number of lines:
https://www.w3.org/TR/jlreq/#procedure_for_defining_the_kihonhanmen
<leaverou> so this is the standard version of -webkit-line-clamp?
<gsnedders> leaverou: no
<fantasai> leaverou, no that's max-lines
<leaverou> fantasai: I'm asking about max-lines
<fantasai> yes
gregwhitworth: I don't disagree, but max-line only says truncate,
but we haven't solved the insane problem of the
algorithm.
Florian: I agree.
gregwhitworth: I don't think we have to tie them together, but
this will need a lot of education. I'm okay if we
discuss this at TPAC, but I do think authors will
think it's solving both even if we're not.
Bert: It seems like yes we want them, but how do we introduce
them. Maybe we can leave it there and talk at TPAC.
fantasai: I'd prefer to add this and a use case showing why it
doesn't work for max-lines.
gsnedders: Will we resolve on what we're going to call it?
<ChrisL> lh and rlh
fantasai: lh and rlh
Bert: Is there a reasonable chance of better names?
gsnedders: I feel names will lead to author confusion.
<ChrisL> those names for units seem pretty clear to me.
fantasai: We don't have other options on the table. This is the
computed value.
gsnedders: I'm not objecting to the name now, but we may want to
see if someone has a better name before TPAC.
fantasai: If someone has a better name they can add an issue
<ChrisL> yes
<bradk> +1
<tantek> aside: I dislike "lh" aesthetically, as the "l" looks too
much like a "1" in many fonts
<tantek> especially in the context where you have a number
immediately preceding it
<tantek> e.g. 11lh
Bert: So do we introduce these? Any objections?
myles: I want to make sure the example links to max-lines.
Bert: fantasai can you promise that?
fantasai: Of course
myles: Then I'm fine.
Bert: Any concerns or support?
<bradk> Support
Florian: I support
RESOLVED: Add lh and rlh with a note on use cases it doesn't solve
and a link to max-lines.
Bert: We can discuss names and use cases later.
Bert: There was a second question in that thread. Do we know what
lh means when used on line height.
fantasai: Should follow the font size property example and use the
value on the parent.
Florian: Yeah.
Bert: Logical to me.
Bert: Any reason to not do that?
Bert: Okay. That's the direction we're going.
<tantek> note that the "em" unit is "em" and not "fs"
<fantasai> because "em" is a word that already exists
CSS Variables transition to PR?
-------------------------------
<ChrisL> test suite report
http://test.csswg.org/harness/results/css-variables-1_dev/grouped/
<ChrisL> https://github.com/w3c/csswg-drafts/labels/css-variables-1
<ChrisL> http://caniuse.com/#search=css%20var
ChrisL: This was me, TabAtkins is the author. It has 135 of 175
passes.
ChrisL: There aren't any inline issues in the spec
<bkardell> it seems to already exceed the PR criteria, right?
<bkardell> shipit
ChrisL: We've got all the passes we should require. In the report
it has one thing for webkit, but it should be split into
blink and webkit. Caniuse.com has green for everything
except Edge. Anyone care to implement it from MS?
ChrisL: Edge 14; CSS variables and custom properties?
leaverou: They don't support it yet.
gregwhitworth: No. Not yet.
<ChrisL> tab, what am I missing here?
Bert: If we have tests we can ask for PR
<tantek> do we have tests for every feature?
Florian: Is the test quite complete? Do we have sufficient tests?
ChrisL: It seems there's tests on each section. It seems to me
there's moderately good test coverage. It's 175 tests and
a reasonably small spec.
<ChrisL> and each section has some tests
Florian: I don't think we're lacking, but I want to make sure
someone has evaluated.
gsnedders: One way of knowing is if browsers have lots of bugs
that would be a good sign.
gsnedders: I don't know how many bugs are around variables.
ChrisL: Given everyone uses this already are we better served
moving this forward and starting variables 2 or is there a
reason to hold off?
Florian: I think we should do this, but it would be more reliable
if the author looked through the test suite and said it's
reasonable.
TabAtkins: My phone hung up on me. I haven't reviewed the test
suite [missed]
fantasai: I think if the tests from each vendor is in the test
suite there's enough coverage. If we've got all the test
from blink and webkit and if Microsoft has any tests
they haven't submitted that should be enough.
fantasai: If only Mozilla did tests and there's no other tests I'd
be concerned. But if we have all the tests from all the
vendors we're in good shape.
Florian: Either someone knows the answer or we action someone to
check and we do go to PR
ACTION gsnedders to check if Variables test coverage is from many
browsers
<trackbot> Created ACTION-785
<ChrisL> I would like to see the test coverage split for blink and
for webkit. Peter tells me this is possible
<gsnedders> ChrisL: likewise.
<ChrisL> the individual test results have the full user agent
string, so they can be split after the fact
<dbaron> (also, worth searching browser bug systems to see if
there are any interesting bugs outstanding that should be
in the test suite)
<fantasai> Actually, if only *Mozilla* submitted all their tests,
I wouldn't be as concerned... They're pretty good at
tests. :)
Bert: How much time do you need?
gsnedders: End of the week, probably.
Bert: Very nice. Then we can ask for PR soon.
Bert: Anything else ChrisL?
ChrisL: No. Thanks.
Transition to CR for Grid?
--------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/345
Bert: TabAtkins said there was one issue left.
Bert: Anyone know what it is?
tantek: Anything at risk in grid?
fantasai: A bunch. Subgrid. I think they're listed. Main thing to
discuss before is the concern about percentage grid
sizes and if that should be dropped/at risk. There
weren't strong use cases, it was added for completeness.
fantasai: That's the only open issue except fremy filled something
about baseline alignment, but we have that covered.
Bert: Sounds a bit hesitant. Are we sure we want to go to CR?
fantasai: It's been sitting around and not collecting many bugs.
It's stable enough for CR. Given the rate of issues is
CR level. 1 or 2 a month.
tantek: That's a good sign.
tantek: The question about percentage grid sizes, has anyone
indicated intent to implement?
fantasai: I think the ?? folks were looking into it and asked if
it's intrinsically sized and do we really need this.
fantasai: We had added without a strong use case.
Florian: And do the other implementors support it?
fantasai: We don't know.
fantasai: It's currently as at risk.
tantek: Okay.
fantasai: We can leave it in the spec.
Bert: The only issues are marked as at risk?
gregwhitworth: We'd like to review baseline align and the dev
looking into that wanted to know how we'd go about
that. Has there been any feedback on align content
or the items in track sizing.
fantasai: We've gotten feedback from Mats of Mozilla. There was a
handful of issues in May. It's been in the spec for
years. As far as we can tell it's covered in alignment.
If you want more time to review that's fine. I'm also
fine if we want to go to CR and file it as an issue in
CR.
Florian: If the type of feedback we're expecting is the type you
get as you try to implement that seems reasonable for CR.
Florian: One of the implications of going CR is it's a green light
to ship it.
Florian: Maybe that's a way to phrase it. Are we confident now is
the time to release this in the wild?
ChrisL: If that's the worry we'd never go to CR until we know it
could be implemented. CR to see if it can be implemented.
fantasai: CR is implemented and testing. I think we've finished
the design phrase. The feedback we're getting is this
detail in the algorithm is wrong. That kind of feedback
is what we'd expect. That is appropriate to get in CR.
fantasai: I don't think we'll get more progress until people
implement and that's when you put it in CR. We've done
as much thinking and reviewing as we can without people
implementing and testing.
tantek: I tend to agree with fantasai's summary. I'd add do we
being there are no current outstanding substantiative
issues. Is that correct?
fantasai: Yeah. There's a DoC.
<fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20160519
tantek: I take your word for it. I just wanted to ask the question.
tantek: If we have it's better to go to CR then wait.
fantasai: Issue 14 is waiting on commenter review. Everything else
is in good shape. There's no other open issues.
tantek: Great. Ship it.
Bert: Do we go to CR now?
<Florian> ship it
<gsnedders> I'm +1 on CR
Bert: Seems no objections
Bert: Some people in favor.
Bert: Anything we need to do? fantasai is doing the DoC.
ChrisL: Does the DoC have a reasonable number of responses from
commenters?
ChrisL: If not can you do a sweep up round of "please respond" We
need to show we tried.
<tantek> sorry, one more question, do we think it has received
"wide" review?
<tantek> (beyond this WG right, thanks, I figured)
fantasai: Yes tantek we've had a lot of review. We've had a lot of
comments and they're all tracked.
<fantasai> tantek, and Rachel Andrew and Jen Simmons have brought
it up with authors at various conferences as well :) I
would hope they've forwarded any feedback
RESOLVED: Take Grid to CR
<dbaron> My biggest concern is about getting stuck with algorithms
that are slow where we'd rather have higher-performance
algorithms.
<dbaron> But it's not clear to me that we aren't already stuck
with them.
Florian: Quick follow-up because I wasn't clear earlier. As per
our new rules, CR is not alone a green light to ship
unprefixed, but CR + your implementation follows the spec.
Bert: Do we need to decide anything on prefixes?
Florian: No. Just earlier I said only CR was greenlight to ship.
gsnedders: What's the test suite status?
<TabAtkins> Test Suite = lol
Florian: It exists but it's small.
Bert: Anything else we need to decide?
Bert: I guess ChrisL and I need to do something
ChrisL: One of us needs to write transition request. I've been
CCing the member only list on that.
Bert: You want the task?
<ChrisL> I can do the transition request
ACTION ChrisL to do the transition request for Grid
<trackbot> Created ACTION-786
Bert: We're at the top of the hour. Anything before we close?
Bert: See you next week!
Conversation After the Call
---------------------------
<dbaron> BTW, does grid define intrinsic sizing rules for grid, or
is that in sizing?
<dbaron> (since that's the area I'm most concerned about
performance of)
<dbaron> fantasai, see my questions above^
<fantasai> dbaron: It's in grid
<fantasai> dbaron: https://drafts.csswg.org/css-grid/#intrinsic-sizes
<dbaron> fantasai, where is "sized under a max-content
constraint", etc., defined?
<TabAtkins> The Sizing spec
<fantasai> dbaron: It's referenced as an if clause a few places in
the sizing algorithm
<fantasai> e.g. https://www.w3.org/TR/css-grid-1/#algo-content
<dbaron> fantasai: I don't see anything there that's not about
track sizes
<fantasai> dbaron: the grid container's intrinsic size is the sum
of its track sizes
<fantasai> as defined in the earlier section
<dbaron> fantasai: is there a difference between the grid being
sized under a max-content constraint and the grid tracks
being sized under a max-content constraint?
<fantasai> dbaron: no
<dbaron> (I have been assuming there is, but maybe you're saying
there isn't)
<dbaron> fantasai: maybe the end of each of the last 2 paragraphs
of https://drafts.csswg.org/css-grid/#intrinsic-sizes
should be reworded?
Received on Thursday, 4 August 2016 01:04:42 UTC