- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 May 2018 20:09:58 -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: Add fr unit support as min arg inside minmax for Grid
L2. (Issue #2611)
- Having a three value syntax for minmax (Example:
minmax(5em, 2fr, 250px)) will be considered later and separately
from the rest of Issue #2611.
- RESOLVED: Accept the edits in
https://github.com/w3c/csswg-drafts/commit/f33560757fcb0c55b8b6b8e2308eb24a92f1e6dd
around subgrid and grid-gap (Issue #2285)
Text Decor
----------
- RESOLVED: Accept the proposed changes (to skip unicode punctuation
characters for emphasis marks with a few exceptions)and
follow up with unicode [on why there are exceptions]
(Issue #839)
- RESOLVED: updated publication of css-text-decor-3 CR
CSS Display
-----------
- RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
(A block container that establishes a new block
formatting context is considered to have a used display
value of flow-root.)
- RESOLVED: Defer to css-pseudo-4 to address [interaction between
display:contents and ::first-line] as part of more
rigorously defining ::first-line cascading/inheritance.
(Issue #1310)
- RESOLVED: Defer #1810 and #2365 to later.
- There are only a few issues remaining for CSS Display so the
editors plan to request CR possibly as early as next week.
Anyone planning to do a spec review before that transition
should do so soon.
CSS Text 3
----------
- RESOLVED: Accept the proposal in Issue #2682 (make the existing
word-wrap/overflow-wrap property affect intrinsic sizing)
CSS Contain
-----------
- RESOLVED: Accept the edits:
https://github.com/w3c/csswg-drafts/commit/94982e838a558e6c66516b3b13e403eae32e27ad
[to clarify various meanings of 'formatting context']
(Issue #1457)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0035.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Thierry Michel
Anton Prowse
Liam Quin
Melanie Richards
Florian Rivoal
Eric Willigers
Regrets:
Tab Atkins
Benjamin De Cock
Manuel Rego
François Remy
Dirk Schulze
Alan Stearns
Lea Verou
Scribe: dael
CSS Grid L1 & L2
================
Applying 'justify-content' content distribution is in the wrong place
in the overall grid sizing algo
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2557
Rossen: I think Manuel sent regrets. fantasai can you take this?
fantasai: There was a bunch of discussion on github since adding to
agenda, so I need to go back over before I could describe
where it's at.
[agenda wrangling]
[debate if can do agenda item #2 without leaverou]
[we can't]
Allow fr units as min
---------------------
github: https://github.com/w3c/csswg-drafts/issues/2611
fantasai: Based on rachelandrew's comment I say we allow length or
percent but not content based keywords
<fantasai> https://github.com/w3c/csswg-drafts/issues/2611#issuecomment-386469857
fantasai: We limited what you can put in min position of minmax in
L1 because the requests came late. One of the use cases
was I want fr with a cap of 250px
fantasai: We wanted that to work. Figured out it's straight forward
if there's not content based keywords.
fantasai: Open questions are 1) do we want to allow this, I think
yes. 2) allow percent in max position and I think we
should. 3) Should we allow content based keywords in max
position- no clear use case and complex to impl so I think
start with no
fantasai: 4) Do we want to allow a 3 argument minmax where you have
some kind of explicit min like a content keyword or a
length and then an fr unit in the middle and a max in the
top.
Rossen: Let's go separate. fr unit as a part of minmax first and see
if we can resolve. Then 3 value.
Rossen: Are there additional comments or ideas about support of fr
units?
Rossen: Proposed addition of fr unit support inside minmax for Grid
L2. Objections?
RESOLVED: Add fr unit support as min arg inside minmax for Grid L2.
<fantasai> minmax(1fr, 250px) is accepted
Rossen: Secondary issue is should we allow an additional 3rd
functional value in the middle of min and max used for
flexing and how that behaves
<fantasai> question is now minmax(5em, 2fr, 250px)
Rossen: Additional comments?
Rossen: What's the primary use case for 3 value?
fantasai: Right now you can control min or max of fr unit, column
has to be at least this, but I want 1fr. Or you can say
1fr but cap. You can't do both. You might want a 0 minimum
and you want 1fr and a cap of 250px
Rossen: Basically you want...I see an example...min 5em, max 250px,
and then 2fr in this case will...
fantasai: We can come back to this.
Rossen: Yeeeeeaaah...I'm not sure.
Rossen: Why isn't that covered by min width?
fantasai: In a sense it is. You can't do min width on column
Rossen: Ah this is for columns
fantasai: Yeah, since fr have implicit auto minimum if you set min
width on any items we'll use that. So you can kind of get
there.
rachelandrew: I've had people ask for this. That's the advice I gave
is put something on item.
Rossen: It's achievable using items as a spacer and fr as the min.
Rossen: I'd be happy to come back. I want to think a bit more on
this.
Rossen: If others are ready?
[silence]
Rossen: Should we come back to this?
fantasai: We'll close this and consider the 3 value syntax in the
future.
subgrid and grid-gap
--------------------
github: https://github.com/w3c/csswg-drafts/issues/2285
<Rossen> https://github.com/w3c/csswg-drafts/issues/2285#issuecomment-387255908
fantasai: Initially when we created subgrid we said you can't
control the gaps in the subgrid. Request was to be able to
control. What we're doing is we added text to explain. If
the subgrid's gap value is different then parent we add
fake margins to the edges of the items adjacent to one of
the gaps.
fantasai: We're kind of doing this for outer edges of items on
subgrid.
fantasai: Using the same technique we're handling the differences in
grid-gaps. afaict this is the behavior authors want.
Allows gap control, simple from impl view.
<fantasai> https://drafts.csswg.org/css-grid-2/#subgrid-gaps
fantasai: It's checked in and you can read text here ^
fantasai: This is a question of does it sound good to everyone?
Rossen: I did read this ahead of the call. Doesn't seem difficult to
impl. Valid use cases. I support.
Rossen: Other opinions?
Rossen: Objections to proposed edits?
RESOLVED: Accept the edits.
<Rossen> https://github.com/w3c/csswg-drafts/commit/f33560757fcb0c55b8b6b8e2308eb24a92f1e6dd
Rossen: These the edits?
fantasai: Yeah
Text Decor
==========
Characters to skip for emphasis marks (text-emphasis)
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/839
fantasai: We discussed and resolved to skip punctuation for emphasis
marks because that's default expected. There was
discussion with i18n. I checked in edits to impl that
decision.
fantasai: We skip characters in punctuation from unicode with a
handful of exceptions.
fantasai: I asked florian to talk to typographers in Japanese
community. florian recommended adding another character.
fantasai: Definition is straight forward. There's symbols in unicode
punctuation so we're effectively re-categorizing. Things
like @ aren't really punctuation.
<fantasai> https://drafts.csswg.org/css-text-decor-3/#text-emphasis-style-property
fantasai: Definition at end of ^
fantasai: That's where we're at.
tantek: If we're going to diverge from unicode can we at least file
a bug against unicode to say we think you made a mistake and
we're patching it in CSS. To give them strong feedback.
Elsewise seems bad to diverge.
chris: Agree.
tantek: I'm not saying it's wrong, I'm saying push the disagreement
upstream.
fantasai: Happy to explain, but because I think unicode general
category is required to be stable I don't think unicode
will be able to fix.
tantek: Let's not assume failure. Let's try.
Rossen: Okay. It's a valid point. Let's give them the feedback.
Thanks tantek.
<dbaron> Unicode has split categories in the past
<liam> [the feedback may help Unicode in future too]
florian: I'm in favor of this. As fantasai mentioned I reviewed. I
reviewed and discussed details with Japanese people and
according to them it's very subjective. The conclusions
fantasai came to are in line with the rational they gave.
Rossen: Great. Any other opinions?
Rossen: Objections to accepting?
RESOLVED: Accept the proposed changes and follow up with unicode
Request to update css-text-decor-3 CR
-------------------------------------
Rossen: Objections?
Rossen: What's in this update?
fantasai: There's a DoC and changes list.
Rossen: Awesome
Rossen: People can go look
<fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013
fantasai: DoC^
fantasai: Quite a lot
<fantasai> https://drafts.csswg.org/css-text-decor-3/#changes
fantasai: Changes ^
fantasai: DoC is colorful so may have questions, but everything
should be accounted for
chris: There's no objections. There's a few with no commenter
response but as long as we made an effort.
fantasai: Yeah
Rossen: I'm not hearing objections to update css-text-decor-3 CR
RESOLVED: updated publication of css-text-decor-3 CR
chris: fantasai you'll raise an issue on transitions GH?
fantasai: Yes.
florian: fantasai do you want updated WD of L4 too? Or later?
fantasai: I think L4 needs more work before it's publishable.
CSS Display
===========
'flow' inner display type should never establish a BFC
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1550
<fantasai> https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
fantasai: Comment ^
fantasai: We made an edit "a block container that establishes a new
block formatting context is considered to have a used
display value of flow-root."
fantasai: We believe this is editorial and we wanted to flag the WG
to confirm it's editorial
[everyone reads]
<dbaron> I think this may be hard to know until somebody tries
implementing this...
Rossen: You're saying a block container establishing a new fc inner
display is flow-root
fantasai: Used inner display of flow-root
Rossen: Unless multicol?
fantasai: I don't think we have a display type for multicol. It
would presumably have same. We're not changing computed
value, just used. Currently that's just a concept. Only
effect of flow root is it establishes a BFC.
florian: I think multicol is described as establishing BFC and I
think I filed a bug saying that's weird.
Rossen: Editorial part seems fine.
Rossen: I'll re-read the spec for multicol.
Rossen: This particular one seems good.
fantasai: Multicol is difficult because it's a new type of FC. It's
not really BFC but there's no display that aligns to it.
fantasai: I'm wondering what dbaron is concerned about.
dbaron: I just think...I'm not aware of an impl and I think it's
complicated and there will be side effects you discover once
anybody tries to impl
fantasai: At the moment I think no effect on impl. Only time it will
start to have an effect is if we start to expose used
values through OM
Rossen: As it stands...
fantasai: That's the intent. If there's a different effect on impl
it's not editorial.
Rossen: At the moment it's editorial because there's no impl.
Rossen: Objections to accepting the proposal
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
<rachelandrew> ED of multicol says "A multi-column container
establishes a new block formatting context, as per
CSS 2.1 section 9.4.1."
<Rossen> rachelandrew, right, the BFC part is understood, the inner
display value is what will be interesting to define...
since it's not really a flow-root
<rachelandrew> there's no other mention - was trying to find the
issue florian mentioned - which I think is this one
https://github.com/w3c/csswg-drafts/pull/1588
<florian> rachelandrew, I was not referring to that issue
<florian> rachelandrew, I was thinking about this one:
https://github.com/w3c/csswg-drafts/issues/2582
Interaction of 'display: contents' and ::first-line
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1310
fantasai: Proposal is defer to pseudo spec.
Rossen: I support it.
dbaron: Flip is display: contents is new and ::first-line has been
around since css 1
Rossen: Then it's easier to spec in ::first-line
dbaron: I don't think that's true. I proposed in the past removing
::first-line and first-letter...they're very complex
fantasai: Part of the issue is inheritence and cascade of
::first-line and that's underspecified. I think solving
here means we have to solve in pseudo first so it makes
sense to solve together.
fantasai: Either way both features are impl. It's a question of
which spec do we tackle in.
tantek: Impl with scare quotes. I'd be interested in seeing any
interop tests
fantasai: It's impl for other things, just not this combo of things.
florian: Regardless of history, fantasai's point there's a
dependency means we can push it there or be stuck. We can't
just define in display. So I support the proposal.
Rossen: Objections to defer to css-pseudo-4 to address as part of
more rigorously defining ::first-line cascading/inheritance.
??: Which spec depends on which?
fantasai: Defining interaction of display: contents and ::first-line
is both. display:contents has no open issues. ::first-line
has "someone please define inheritence" and defining how
they combine requires that.
fantasai: Proposal is defer the interaction definition to pseudo
spec so that it can hold until inheritence is defined
better.
emilio: I would say claim ::first-line and display:contents is
[missed] I think we need to define ::first-line earlier
because if people want features that mess with layout modal
emilio: I think if we want to start defining more complex features
that mess with layout modal we should define these things
earlier rather then later.
Rossen: I sympathize. Only counter argument is that for the more
complex features/layout systems it's not uncommon that we
would push other horizontal features to the specific areas
so that they define their own extension rather then trying
to lump into one spec.
Rossen: In this case I'm inclined to push complexity of
display:contents to ::first-line into pseudo because it will
take longer to define and no reason to hold back
display:contents for ::first-line.
emilio: Agree, but shouldn't defer defining infinitely.
Rossen: Agree. If you have time to work on that people would support
it.
emilio: Fair enough.
Rossen: Other opinions about this? If not we can try and resolve
tantek: Only other thing...to make interaction a CR blocker. I'm
fine with the proposal if we define that defining it blocks
CR.
fantasai: Not okay
Rossen: Why is that the case?
tantek: If you've impl ::first-line then the interaction is a new
thing introduced by this spec and therefore must be defined
or it's an outstanding issue which we're not to have when
enter CR.
florian: Assuming that other then display:content ::first-line was
well defined I'd agree. But it's not so I don't.
<fantasai> +1 to florian
emilio: Yeah I think the...
<emilio> I think the undefinedness is on ::first-line
tantek: Whether or not it's well defined adding another thing makes
it worse. We have to force resolution.
fantasai: It'll be forced when trying to move pseudo to CR. It's on
the to do list.
Rossen: tantek your point is on the record. We're not close to CR.
Once we're close we'll try and untangle.
tantek: I'm worried about another semi-broken feature but I accept
your approach
<fantasai> tantek, it's already introduced, so putting it in CR is
just doing our best to document reality
Rossen: Objections?
RESOLVED: Defer to css-pseudo-4 to address as part of more
rigorously defining ::first-line cascading/inheritance.
Clarify element tree definition
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1810
fantasai: Most information on how the DOM interaction is speced
somewhere. It would be nice if we were more coherent and
had an overview somewhere. But the interactions are
defined so this is editorial issue
fantasai: I'm not even sure what parts go into display spec. We have
to figure out how to fit all the parts together to make
understandable.
fantasai: Proposal here is not to tackle that, but defer this and
#2365 to later rather then block.
Rossen: Reasonable.
Rossen: Other opinions?
Rossen: Objections?
RESOLVED: Defer #1810 and #2365 to later
Publication
-----------
fantasai: That's it for display. There's 3 more editorial issues. At
that point we should be done with display unless we get
more issues.
fantasai: Planning to compile DoC and changes and ask for CR maybe
next week. If you want to review spec now is a good time
to do that.
Rossen: Fantastic. I support fantasai CTA to please look at display
spec. It's been a while since work started and it's so big
for functionality we should have it done sooner rather then
later.
CSS Text 3
==========
word-wrap/overflow-wrap: break-word should affect min-content
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2682
fantasai: Issue is that...there's a number of cases where authors
are frustrated with elements being bigger then they ought
to be. Some are because they put overflow:scroll. Other
set are related to I thought I told the text to be able to
wrap if it needs to, why is element so big
fantasai: That's the word-wrap/overflow-wrap:break-word which
doesn't effect min-content.
fantasai: There was discussion about word-break:break-word from
webkit that does effect intrinsic size. We decided we
wouldn't add that unless FF or Edge said they needed.
fantasai: proposal is to solve several things. Give the authors the
behavior that they're expecting so content can shrink down
in the way they expect since right now if you're auto
sizing the width is too big to break. It also means we can
address reasons for the other syntax existing without
adding the other syntax.
fantasai: Having the syntactic mess is an awful situation to get in.
florian: Canonical example is when there is a piece of text in a
table cell with a long word and the put the
overflow-wrap:break-word and the word stays long.
fantasai: It's probably getting more frustrating because effects
min-content in grid or flexbox. You put a URL in and say
you can break, but it pushes out 1fr column for no good
reason. It's not just in table cells. Flexbox and grid are
relying on the min-content size.
florian: Overall if we can do this it's a good idea. Can we or do we
break compat with negative effects? I'm not too pessimistic
but want to make sure.
fantasai: It's a concern in general, but I think there's enough
cases where changing behavior gets authors to where they
want more then it breaks. Cases that will break is when
you set overflow-wrap to a place where it allows breaking
but then you're not expecting a break.
fantasai: Most layouts aren't dependent on longest word. They asked
for wrapping. I think more likely to fix then to break.
??: Seems fair
Rossen: To be clear blink and webkit have this?
fantasai: Under a different syntax. We've pushed back on adding that
syntax. Only difference between them is how the effect
intrinsic sizing. It's small but super confusing for
authors. Even if they weren't syntactically similar it's
still confusing to think in terms of intrinsic size
Rossen: word-wrap:break-word you take all breaking content?
fantasai: Just in min size
florian: word-break controls other things as well, so with
word-break:break-word you can't do that. With this approach
you could.
Rossen: Just wanted to clarify expectations.
Rossen: Other opinions? Sounds reasonable way forward. Have to see
what interop looks like
Rossen: Or compat risk rather
florian: Yeah
fantasai: Yeah
fantasai: Authors will be happy if we fix this. This is a major
source of frustration with grid and flexbox. Sometimes
allowing breaks...things get too big
Rossen: I'm with you.
Rossen: I'm mostly worried about older content in tables and whatnot
out in the wild. All the sudden we introduce an adverse
effect. But I'll let blink and webkit engineers spearhead
since they have this behavior.
Rossen: Objections?
RESOLVED: Accept the proposal in Issue #2682
CSS Contain
===========
Establishing independent formatting contexts
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-380357179
fantasai: There was an action to clarify what a formatting context
is and how established.
<fantasai> https://drafts.csswg.org/css-display-3/#formatting-context
fantasai: re-wrote the definition ^ and added a definition for
independent formatting context. Example ruby isn't really
independent. Inline isn't independent of block.
fantasai: Created the new term, did a lot of edits. Independent is
what css-contain is trying to do.
<fantasai> changeset is
https://github.com/w3c/csswg-drafts/commit/94982e838a558e6c66516b3b13e403eae32e27ad
florian: I reviewed it, I like it.
Rossen: Anyone else review?
Rossen: Anyone want to review before resolving?
[silence]
Rossen: Objections to accepting the edits
RESOLVED: Accept the edits
Rossen: That's it for today. Have a great day, talk to you next week.
Received on Thursday, 24 May 2018 00:10:56 UTC