- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 2 May 2018 21:39:08 -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.
=========================================
CSS Grid L2
-----------
- RESOLVED: Subgrid line names are additive to the parent grid's
line name. (Issue #2622)
- RESOLVED: Add this proposal ('auto <custom-ident>' to mean the
same as 'auto' except the line it resolves to has to be
named '<custom-ident>'.) to grid L2. (Issue #796)
CSS Grid L1
-----------
- RESOLVED: Grid items spanning fr tracks do contribute to fr track
minimums for intrinsic sizes with the addition that fr
tracks not 1 to 1 ratio get contributed to based on that
ratio. (Issue #2177)
- RESOLVED: Take option B (contribute 0 and resolve as percentage
for column and row gaps).
Overflow
--------
- RESOLVED: Ignore anonymous boxes in this case
(text-overflow:ellipsis). (Issue #2595)
Scroll Snap
-----------
- RESOLVED: Have the default scrolling behavior for nested scrollers
to have scroll snap. (Issue #2593)
CSS2/CSS2.1
-----------
- All permanent links should point to /tr/css2 which points at CSS2.1
- RESOLVED: Say we want it [CSS 2.1] to be the same shortname and
that auto obsoletes the older
CSS Fonts
---------
- TabAtkins proposed that for the fontface rule if a URL has a
fragment identifier you don't know how to deal with you treat it
as invalid (Issue #2566)
- Myles felt that there may be better ways to handle some unknown
fragment identifiers so conversation will continue in github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Garrett Berg
Elika Etemad
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Liam Quin
Manuel Rego
Melanie Richards
Florian Rivoal
Geoffrey Sneddon
Eric Willigers
Regrets:
Rachel Andrew
Angelo Cano
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Chris Lilley
Alan Stearns
Lea Verou
Greg Whitworth
Scribe: dael
CSS Grid 2
==========
Subgrid local line names
------------------------
github: https://github.com/w3c/csswg-drafts/issues/2622
fantasai: Basically we're able to give the subgrid some line names.
Should they hide the parent names or be in addition?
Originally had in addition, but wanted to check what
people prefer.
Rossen: My question is what is the multiplicity? If we have n levels
of subgrid do we need n levels of name?
fantasai: Yes.
Rossen: That's the down side
fantasai: It's just a set, though. No prioritization. You're just
adding names to the set.
Rossen: What is current matching? If there's a grid that defines
line as foo and the subgrid defines it as bar do I have to
call it foo bar?
fantasai: Either foo or bar would work. Just like if you gave it
multiple names in the beginning. We're just combining the
sets here from different levels.
<TabAtkins> `[foo bar]` already gives a line two names
Rossen: Sounds fine
Rossen: Other opinions or objections? Proposal is to keep combining.
<rego> JFTR, sounds good to me too
Rossen: Not hearing objections
RESOLVED: Subgrid line names are additive to the parent grid's line
name
CSS Grid 1
==========
Grid track sizing items spanning a flexible track
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2177
fantasai: This was a case where when Microsoft designed their
algorithm if you had an item that spanned an auto track
and a flexible track the space required to fit the item
would go into the flexible track. This is frequently used
in design where the auto track is tight to the content
only in it.
fantasai: We inherited this in algorithm. When you shrinkwrap the
grid we don't have a point at which we consider the size
of the spanning item. Flexible track goes to 0 and the
other track doesn't expand so it overflows.
TabAtkins: Manuel's picture in the first message shows the problem.
#1, 2, and 3 the grid expands to the full width of the
item. But in the 2fr columns they don't. Section 5 is the
problem. 1 auto and 1 fr. A single auto or 2 autos expand
correctly, but because the interaction of auto and fr you
don't get the good behavior.
fantasai: Rossen explained high level how to incorporate this into
the algorithm. TabAtkins and I tried to do that, but we
realized you might have multiple fr tracks or a different
ratio. We added a new section and changed how space is
distributed to try and keep the ratio as far as we can.
There are conflicting requirements like try and shrink as
small as you can. You don't always have tightest or ideal
flex, but you get close.
fantasai: We'd like WG review on if this is the right way or if
there's other ideas on how to do this.
Rossen: What you described for multiple fr tracks with a different
ratio than 1 to 1 your proposal is reasonable and what I'd
expect. From that PoV I'm fine with the proposal. I haven't
done a full review, but I won't block because I trust you
did the changes you outlined and it sounds good to me.
Rossen: Is this agenda+ to elevate awareness or do you want to
resolve?
fantasai: If everyone who wants to look has let's resolve but if
anyone wants time to review that's fine.
Rossen: Does anyone want more time to review? I personally don't.
[silence]
Rossen: Then can we resolve on the current proposal? Grid items
spanning fr tracks do contribute to fr resolution for
intrinsic sizes with the addition that fr tracks not 1 to 1
ratio get contributed to based on that ratio.
Rossen: fantasai if you've got better wording?
fantasai: looks good to me.
Rossen: Opinions or objections?
RESOLVED: Grid items spanning fr tracks do contribute to fr track
minimums for intrinsic sizes with the addition that fr
tracks not 1 to 1 ratio get contributed to based on that
ratio.
Percentages gaps and intrinsic size
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509
<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-381759138
rego: I reopened it.
rego: All browsers now support percentage in column gap in multi
column
rego: All of them are interoperable. But they're not following new
text in spec. Chrome and webkit we don't see an easy way to
follow for width so I suggest we change the text to says
something like % resolves to 0 when resolved against the base
size. Something like the indefinite size is what we should say
because the logical width is not indefinite.
rego: That causes overflow in some cases but I don't think there's a
way to do it better and changing spec text would make it match
impl.
<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873
[
B = contribute zero, resolve as percent
D = contribute zero, resolve as zero
F = contribute zero, resolve as percent (for column-gap) or zero
(for row-gap)
]
fantasai: If we go back to the options before there was option d
which was contribute 0 resolve as 0. Igalia is saying we
don't know when to resolve if it's at 0 or not because
information on whether the current size of the container
was a content-based size isn't part of what's given to
grid when it's doing layout.
fantasai: It's easier for impl if they continue tracking just the
information they have already, i.e. the size of the
container and therefore the percent resolves.
Rossen: I can't speak to other impl, in our grid impl we know if
we're doing layout for sizing and measuring the content vs
sizing when we're not shrink to fit. From that PoV I don't
think we have anything in the spec that prevents a impl from
passing this info
Rossen: Looking at current interop around this....based on the
codepen from the issue seemed like we all agree on behavior
of grid.
Rossen: rego what I hear is once we go down...if we change
resolution from b to d, contribute 0 resolve as 0, we
minimize amount of potential overflow, but also drop ability
to have percentage column gaps. Last time we discussed the
one constant feedback from webdev was they don't want to
drop the gap. It's more intuitive if you see overflow and go
and fix it rather then add values and have no effect.
Rossen: I'm not sure we're driving toward an ergonomic solution.
fantasai: Previous resolution was b and we're proposing switch to d.
Rossen: In that case I agree and misunderstood the proposal.
rego: It would be more like f.
rego: It would be like when grid resolves percent for width and
height in regular blocks they're different so same here.
Rossen: Okay, I'm with you.
Rossen: Other opinions on this?
fantasai: Proposal is to resolve the percent in column gaps but not
row gaps?
rego: Yes. To resolve the percent when the size is definite, but not
when indefinite. Width is only indefinite for intrinsic sizes.
fantasai: That gets to the point where we wanted symmetry and we
don't have that.
Rossen: Same concern as fantasai. Only thing that is symmetric is
we're talking definite vs indefinite instead of width and
height. I wasn't going to object hard, but I'm with fantasai
that we want to keep as symmetric as possible. Just because
of how flow layout works today more often then not width
will be definite and height indefinite or vice versa.
rego: There is the other issue about how percentage tracks work
where they should be symmetric and resolve always. So maybe
that's an option here. But no one is supporting the heights
for percentage rows yet. Maybe that's the way to go.
Rossen: This is option f?
rego: Option b I guess.
<rego> https://github.com/w3c/csswg-drafts/issues/1921
rego: Following what we resolved in issue #1921. It's not
implemented, but we resolved that way in the past.
Rossen: Going through 1921 resolution it makes sense, but
implementations have to catch up. Once we do we'll have
symmetric behavior. Then we need to do same thing for gaps.
That would be behavior b.
rego: For multi column it's what we're doing right now. We're always
resolving the percent because multicol only has column gap.
Rossen: Right but for grid it's both column and row.
dbaron: I'm not an expert on grid, but I felt like I liked the
original proposal from rego a bit more. There's a lot of
stuff where width and height just doesn't work the same way.
Things that happen in intrinsic width pass shouldn't effect
layout pass.
Rossen: I wouldn't disagree in general, but I would slightly
disagree in the case of grid because we've been trying for
as symmetric as possible. We had a fully symmetric
implementation and that fell through. It will require more
passes to make symmetry stable, but it's possible.
Rossen: Let's try and move forward.
Rossen: Proposal in the issue was we resolve to have a contribute 0
and resolve as percentage
Rossen: Correct?
rego: That's not what's in the issue, but yeah. That's the new
proposal to keep symmetric behavior following the tracks
resolution.
Rossen: Which is option B.
Rossen: Any opinions or objections?
RESOLVED: Take option B (contribute 0 and resolve as percentage for
column and row gaps).
CSS Grid 2
==========
Auto-placement aligning to a named line
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/796
Rossen: RachelAndrew raised this, but she's not on. fantasai can you
summarize?
fantasai: There have been several requests to do auto placement but
filter out lines that don't match a name. Right now auto
placement uses auto keyword. Add a custom ident for the
name after the auto. So auto and the name would only do
placement on lines with that name.
fantasai: This is level 2 of grid.
Rossen: Seems reasonable. I'm trying to understand primary use case
fantasai: Example is wanting to have narrow and wide columns, some
items should go in narrow and some in the wide. You name
the lines to make the distinction and then be able to
filter out the ones that match what you're looking for.
Rossen: Okay. What's behavior if I list all named lines?
fantasai: Proposal is you only have one custom ident. A line can
have many names so if it matches any name it matches.
That's the same as looking for lines. If you wanted
various behaviors you'd name the lines differently.
TabAtkins: Identical to if you spec a line name right now. It's just
giving you auto placement with same behavior.
Rossen: Sounds reasonable. What do others think?
florian: I like it
rego: Level 2?
Rossen: Yeah.
rego: Another commonly requested feature is spanning until last line
including implicit grid?
fantasai: There's another open issue on that. We don't have a
solution to please comment there.
Rossen: Objections to accepting proposal to add to L2?
RESOLVED: Add this proposal ('auto <custom-ident>' to mean the same
as 'auto' except the line it resolves to has to be named
'<custom-ident>'.) to grid L2.
Overflow
========
text-overflow and anonymous blocks
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2595
florian: Text-overflow: ellipsis works on block containers. It is
not inherited so if you have nested blocks and inner ones
overflow the ellipsis doesn't appear. It has been that way
forever. New issue is if the element you apply the
text-overflow: ellipsis to has the text directly as a child
it gets wrapped in an anonymous block. Should it display
the ellipsis there is different between browsers and
ambiguous in the spec.
florian: Spec arguably says no, but that's not ideal. Edge disagrees
but fremy says Edge is changing as well. I don't know if we
need a change or a clarification but we should say
anonymous boxes are ignored for this purpose.
Rossen: Besides wordsmithing, I'm okay with such a resolution. Other
opinions?
Rossen: Is this acceptable?
fantasai: I'm in favor of ignoring anonymous boxes here.
Rossen: Objections?
RESOLVED: Ignore anonymous boxes in this case
(text-overflow:ellipsis).
Scroll Snap
===========
Multiple nested scrollers and a "default" scrollIntoView()?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2593
TabAtkins: I suspect it's resolved at this point, but making sure.
majidvp and our other implementors that are getting our
scroll snap up to date with the spec found an
interaction. Spec defines an interaction between scroll
methods alignment and scroll snap. You try to align via
how the scroll method says and if you need to snap after
you do.
TabAtkins: Nested scrollers when you have to go multiple deep to get
the element in view: Conclusion is you first align all
the scrollers as you go down according to scroll method
alignment. If any scrollers have scroll snap you honor
that to bring them into alignment. And that's about it.
TabAtkins: Unless anyone disagrees that's what we concluded in the
thread which means no edits to the spec except we might
want to clarify the wording.
Rossen: Sounds reasonable. Any other opinions or objections?
Proposal: Have the default scrolling behavior for nested scrollers
to have scroll snap
TabAtkins: Yeah, sure.
RESOLVED: Have the default scrolling behavior for nested scrollers
to have scroll snap.
CSS2/CSS2.1
===========
Declare CSS2 as superseded
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/2589
fantasai: Proposal was to declare css 2 as superseded. However as it
stands now it's the css 2.1 spec. What we did is at the
end of the css2.1 cycle we thought having css 2 around was
bad and we merged the shortnames in. We've done that for
other specs before. So I don't think we can declare css2
superseded because we're using that short name for 2.1
fantasai: There were resolutions to make sure that various shortcuts
point to the right version. We need to make sure they're
impl. tr/rec/css2 points to old. We need webrec to move
that alias to point to same as tr/css2
fantasai: Old css2 publication should show the I'm out of date
notifications. But it's an older date of same spec so not
superseded.
florian: I agree most important is redirect. That said it's not
short names that are superseded, it's rec. We could call
the 1998 rec superseded. I'm not sure what that gets us.
fantasai: Question. I have a rec about something like css
namespaces. Then we see an error, go to cr, and then go to
rec. Do we have to make the old rec superseded?
florian: Process doesn't take into account levels.
fantasai: Not relevant.
gsnedders: I think significant thing in 2.1 was there is a change in
feature set. I think we added features to 2.1 so it's a
different document as defined by the process. It's the
presence of new features that's significant.
gsnedders: My view here is we should makes sure we have the right
base data and I don't care how we achieve that. If the
process makes no sense for what we do that's a bug in the
process.
dbaron: I'm not sure how well thought through the process is. I
think superseded came about because there were people that
wanted to make it as obsolete because there were new
versions but they didn't want to call it obsolete. This was
we don't want to mark the short name as the same thing. I'm
inclined to think we should come up with what we think
process should be. And I think we should make sure short
names redirect, not mark as superseded.
gsnedders: And that we get the correct this is out of date notice.
florian: I think we need to do that and fix the short name first.
Then we should get process fixed to say any newer rec of
the same name supersedes previous.
gsnedders: CSS 2 and 2.1 are in a slightly odd state because most
things under the same short name don't both appear in
tr.rdf. There's a bunch of things to fix around this.
florian: From the csswg pov we just need to say we want CSS2.0 and
2.1 to be the same shortname (CSS), and that newer RECs of
the same shortname supersede the old ones, and the rest is
just tooling bugs.
Rossen: I like that summary. Do others agree?
Rossen: Objections to say we want it (css2.1) to be the same
shortname and that auto obsoletes the older?
RESOLVED: Say we want it (css2.1) to be the same shortname and that
auto obsoletes the older
gsnedders: What should tr/css21 to point to once 2.2 is published?
florian: Permanent redirect?
fantasai: Or call it 2.1 forever.
florian: That's also okay.
gsnedders: But no one wants it to point to 2.1.
florian: Sure.
Values & Units
==============
Define which subresources block the DOM load event
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1088
TabAtkins: fantasai requested to figure out what spec it goes in
Rossen: whatwg?
gsnedders: We resolved in values and units.
TabAtkins: [reads]Add proposed dom events to Values & Units. Okay.
fantasai: Yes. Anne added the agenda+ I don't know why.
Rossen: I'm okay to move on. We can come back if there's a need to
resolve.
dbaron: I think there's stuff to discuss here.
Rossen: What would you like to discuss or does it stay in GH?
dbaron: GH may be fine. There's a bunch of non-interop but we have
space to converge if we agree to try and progress in that
direction. Example @import blocks if it's one level deep,
but not further and other browsers never block. I think we
should be consistent and not having different behavior at
different depths.
dbaron: But we can discuss more on issue.
Rossen: I think that's better.
<gsnedders> I think Anne added it because Domenic drafted some text
in HTML to better define what blocks the load event,
including CSS.
<gsnedders> and Domenic said "it would be great if the CSSWG was
able to resolve this one way or another, write the
tests, and move the definition into one of their specs"
CSS Fonts
=========
Unknown fragment identifiers in @font-face src
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2566
TabAtkins: Some @font-face formats let you do special things with
fragments. There might be more in the future. Question is
how should we handle font URLs in @font-face with unknown
types of fragment identifiers.
TabAtkins: Initial suggestion was ignore, but I suggested do same as
image function where if you see a fragment ID and don't
know how to handle treat the URL as invalid. You don't
know what the fragment is trying to do.
TabAtkins: Suggestion: we spec that for the @font-face rule if a URL
has a fragment identifier you don't know how to deal with
you treat it as invalid.
myles: Not sure I agree. It seems in some situations you want to
treat fragment as unknown and some others for whole is
unknown.
<myles> my client crashed
TabAtkins: Example. Browser that doesn't know what an open type
collection is. Your fragment says load the second.
Browser tries to download but you don't know what will
happen. Best situation is it sees a url that says to do
something it doesn't understand...best thing to do is to
say I don't know what to do, skip it.
TabAtkins: I don't think doing something arbitrary can be argued as
better for the user.
fantasai: Treating uninterpretable fragment IDs as invalid seems
appropriate. It's just like if you got a URL with a scheme
you can't load you treat as invalid.
myles: TabAtkins said browsers that don't understand collections
will ignore the whole thing, but I think all 4 browsers do
understand collections
TabAtkins: Yes, it was a hypothetical example. I was using it as a
stand in for a future where the fragment does something
significant and you either load it and do something wrong
or load it and have no idea how to deal with it so you
wasted bandwidth.
myles: It sounds like there is a real discussion so we should maybe
continue next week.
TabAtkins: I'm repeating from the thread so put your arguments in
there.
Rossen: Sounds like we won't get to consensus today. We'll take it
up next week.
Rossen: Thank you for calling in. Have a great rest of the day/night/
whatever your timezone is. We'll chat next week.
Received on Thursday, 3 May 2018 01:40:07 UTC