- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Jul 2018 05:01:13 -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.
=========================================
Fonts 4
-------
- RESOLVED: Add Chris Lilley as editor to fonts 4
CSS Display
-----------
- RESOLVED: Keep it that blockification and establishing formatting
context are independent (Issue #2673)
- As a part of the discussion for issue #2673 it was raised that
part of the reason blockification and establishing a formatting
context were requested to be linked is the earlier resolution to
make inline flow-root and inline block the same. Over the next
week people will re-look at that decision (
https://github.com/w3c/csswg-drafts/issues/1246 )
and re-open it if necessary.
- Unless there is a new issue opened, next week there will be a CR
publication request.
CSSOM
-----
- RESOLVED: Have the PR https://github.com/w3c/csswg-drafts/pull/2924
as the start of a set of constraints with Gecko
algorithm as an example in a note
CSS Overflow
------------
- RESOLVED: Keep current definition such that we could all lines in
overflow:clip descendant (Issue #2421)
CSS Text
--------
- RESOLVED: Handle percent text-indent in intrinsic size box same as
percent in padding and margin (Issue #1597)
- RESOLVED: Defer this issue (#2390: Implement or unship
word-break:break-word) for now [to Level 4]
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0014.html
Present:
Rossen Atanasso
Tab Atkins
David Baron
Garrett Berg
Oriol Brufau (IRC Only)
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Thierry Michel
Anton Prowse
Liam Quin
Manuel Rego Casasnovas
Florian Rivoal
Jen Simmons
Alan Stearns
Regrets:
Rachel Andrew
Benjamin De Cock
Chris Harrelson
Chris Lilley
Michael Miller
Melanie Richards
Lea Verou
Greg Whitworth
Scribe: dael
Fonts 4
=======
astearns: Let's start
astearns: Does anyone have any last minute changes/additions?
fantasai: Resolution for chrisl to be editor of fonts 4? Editing
fonts 3 and not fonts 4 seems like an oversight
astearns: We didn't get one, but I'm happy to now. Is myles on?
<myles> yes
astearns: myles is this okay with you?
myles: Yes
RESOLVED: Add Chris Lilley as editor to fonts 4
astearns: I believe that's in the draft already so it's now official
CSS Display
===========
Blockifications should establish BFC in block containers
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2673
TabAtkins: Oriol has been asking for if blockification should auto
establish bfc rather then occasionally explicit. fantasai
and I disagreeing because they don't happen every time
TabAtkins: If anyone disagrees and things blockification should auto
be a BFC, great let's talk. If not looking for resolution
of support
Rossen: You saying that blocification doens't force BFC?
TabAtkins: Not intrinsically.
Rossen: Example?
TabAtkins: Have to look.
TabAtkins: Any time we blockify and inline-block does not cause it
to become a FC it just goes to block
fantasai: That's true in that it does not change the display
computation. That's required by backwards compat.
fantasai: We could change to not change display and also make it a
formatting context. We do that for float abspos and others
fantasai: Right now when we do blockification in cases where new
element will establish new FC anyway. If we apply
blockification in flow blocks I don't think we'd want new
FC. Grid items currently blockify and a subgrid isn't a
new FC
Rossen: does subgrid blockify?
fantasai: If we did we'd need an exception. It has to blockify
because if it's an inline grid it becomes not an inline.
When it's a grid item...if you have an item inside a grid
that element is blockified. Blockification if it says
display inline it becomes block. inline-table become
block, inline-grid becomes block. But a subgrid isn't a
new FC because it intertwines with grid outside. Can't say
it's a new FC, but it is blockified
fantasai: I don't think we can tie these two concepts together.
block makes it a block. They almost always coincide but I
don't think the concepts are intrinsically bound and
shouldn't be tied in spec
* emilio agrees with fantasai
florian: Exception of subgrid this is an editorial twist as to if
you describe separately or together. So it's editorial.
<Oriol> But I think a BFC is desired if you have `display: inline
flow-root`. CSS DIsplay says it becomes `flock flow`, and a
future feature might blockify without forcing BFC. Then the
flow-rootness will be lost
dbaron: I think one other point in the issue from Oriol. I think
Oriol trying to put in IRC too
dbaron: Current blockification remove flow-root nature. If
blockification always makes things FC it's fine. If it
doesn't then maybe blockification rules need to be fixed so
if you say flow-root you don't lose that
fantasai: So far cases where lose flow-root is converting inline
flow-root or a run-in flow-root. In case of inline-block
we can't change how display is computed due to backwards
compat.
fantasai: Every other case where flow-root is blockified it
establishes a new FC anyway.
fantasai: We're flowing it, we're abspos it, putting it in a grid or
flexbox. These are cases where element that is a block
container it establishes a new FC
dbaron: So in subgrid it's not possible to be a new FC?
fantasai: Matter of terminology, but fundamental idea of a new FC is
there's no intertwining between new and old FC. If there's
info passed through the boundaries when you do something
like whitespace collapsing it's porous. Same is true for
display:block, margins collapse through boundary. The
contents inside and outside participate
fantasai: New FC creates a barrier without that bleedthrough. The
justification and alignment doesn't pass through the
inline-block boundary. Same as a block element with new FC.
fantasai: For a grid, if you nest a grid inside a grid same thing
applies. No interactions between grid tracks inside a
nested grid. Subgrid you do have negotiation between inner
subgrid context and outer parents and siblings. They
participate together in sizing algo
fantasai: The size declarations and names of lines on parent pass to
subgrid. There is fundamental bleeding through of the
content and the layout calc. To say it's a new FC doesn't
make sense.
dbaron: Makes sense to me. Some point earlier I thought you said
that...something about how these were still block formatting
context.
fantasai: Grid items are considered grid level, not block. They
participate in grid FC. But there is blockificaiton
process that changes display values to make them
block-like. We convert anything with a non-block outer
display to a block
dbaron: And one of the blockified things can be a subgrid?
fantasai: You run blockification on every grid item. You run it
through blockification Might be a no-op, but you run
through.
fantasai: Was we decided to do subgrid with a new type the
display-type of a subgrid needs to be declared. If you say
grid or inline grid doesn't really matter.
fantasai: Blockification process turns inline on subgrid to grid.
dbaron: I worried you said display: block could be subgrid
fantasai: No, you can't
florian: Blockification is really dis-inline-ification
fantasai: In a sense. We have outer display type which says how your
behavior is when in flow layout. Outside of flow layout
distinction between inline and block has no meaning and is
ignored. Each display value corresponds to a state.
fantasai: If I take subgrid and put it in a bfc it will not behave
as subgrid, but it'll be the fallback behavior.
<TabAtkins> Core point tho: grid items are blockified, subgrids are
grid items (by definition) but aren't FCs (by
definition), so blockification *cannot* imply
FCification in general.
fantasai: Whether declared inline or block grid it'll make a
difference in participation once in block container
astearns: Back to original issue: We have a choice of keeping things
as we are where blockification and formatting context are
discussed separate. Or we changes that blockification
implies a FC but it can be overwritten in places like
subgrid
astearns: Argument that 2 things are separate is compelling to me
because having both explicit sounds easier to comprehend.
I like that it's explicit
astearns: Argument to tie together is that there may be situations
in the future where we might forget about forcing FC in
blockification case where we need it to happen. Benefit
for the explicit call outweighs danger of forgetting to
make that call in the future.
<florian> since this makes no behavior difference, this is
editorial, and I like to leave it up to the editors to
describe it the way they want. That helps the whole prose
be coherent
<AmeliaBR> Is there any consequence of blockification that *is*
necessary for subgrid? Or can it just be that "grid-items
are blockified (and create a formatting context),
*except* for those with `display: subgrid`"?
<fantasai> AmeliaBR, inline-grid needs to be converted to grid
<fantasai> ('display' value)
dbaron: Blockification without FCification doesn't work in a block
context. In grid it's fine, but in block context it removes
the things that are supposed to be FC. I think that's a
piece Oriol doesn't like. Maybe it's that we never will use
and so it's okay. Might be worth noting.
astearns: Make sense to call that out in all current cases you need
the 2 in a block context
<Oriol> Yes, the problem is with flow layout
<fantasai> dbaron, I missed exactly the sense of what you said, and
the first sentence of the minutes doesn't make sense...
* dbaron thinks the minutes are right
<fantasai> ... ok, I think I understand. Disagree somewhat, though.
<myles> are we discussing a behavior change, or just wording in the
spec?
<astearns> myles just wording, afaik
Rossen: fwiw, from impl experience we've had this model inside our
engine since IE9. During style computation we independently
decide inner layout type, outside layout placement (where
you will be placed), and 2 auxiliary ones, based on the
layout placement and type we compute if you're a BFC and if
you require a stacking context.
Rossen: What I can tell you is they're all independent. But I don't
see why we should unless from inline-block PoV we have to.
fantasai: Address point from Oriol and dbaron where if you happen to
use blockification for block level items
question...example is an inline-block when blockifies
turns into display:block which is porous. Argument is
inline-block should be a block flow-root and a new FC. Not
convinced of that being the expectation.
fantasai: I think that's part of why it's not in CSS
2.1...distinction between block, block layout, and bfc is
not huge. inline-block vs a block do form a pair.
fantasai: Formatting context establishment is a side effect because
they just want this as a block to be a FC, not something
they specifically needed.
<Oriol> I think it may be OK if inline-block doesn't become a
flow-root, but if you explicitly specify flow-root, you
shouldn't lose it
fantasai: I'm not sure what you would expect, but becoming
display:block isn't necessarily unexpected. If you said
inline flow-root it's clear you wanted that but we're
getting into fiddly cases and we decided inline-block and
flow-root are identical
dbaron: I think this is a negative side effect of that. Prob fine
for inline-block, but weird if flow-root.
dbaron: I think I'm okay just concluding here
astearns: And close no change dbaron ?
dbaron: I think no change and a note pointing out that it isn't
great if if you do blockification without FC and people used
flow-root explicitly
astearns: Need to ask Oriol if he's okay closing with a note.
<Oriol> OK, but note that if a future feature allows blockification
without BFC, then it will be more difficult to change
astearns: And would anyone else objects to resolve no change except
adding a note
fantasai: 3 ways forward, to be clear.
fantasai: 1) close no change FC and blockification are independent
fantasai: 2) blockification implies FCificiation so inline-block
converts to block flow-root and we will need an exception
for subgrid
fantasai: 3) revert resolution where we said inline-block and inline
flow are identical and say they're independent and have
same behavior except if you blockify.
fantasai: That lets you when you blockify inline flow-root it
becomes display: flow-root
<dbaron> I'd be fine with (3) based on this discussion but I don't
know why we made that resolution to begin with.
astearns: We're 30 minutes on this issue. My preference would be
close no change and raise a new issue on inline-block and
inline flow-root
fantasai: We had an issue and resolved on the current. Only reason
to re-open is if people want option 3 which gets you
independence for blockification and FCification but also
clarifies the inline flow-root.
astearns: Reopening that with this in mind makes sense and doesn't
change how we'd resolve here.
fantasai: Fair enough
astearns: I'd like to close this.
astearns: Let's resolve that blockification and establishing FC are
independent and we will add a note on the flow-root issue
which can become a github issue to change our previous
decision
<Oriol> Works for me
fantasai: This is last open issue before CR so we need to open the
issue or go to CR
astearns: Objections to keep blockification and establishing FC are
independent
RESOLVED: Keep it that blockification and establishing FC are
independent
astearns: Anyone think we should take up an issue about inline-block
and inline flow-root?
florian: Rather not
dbaron: Don't know context of original decision so hard to know
<fantasai> dbaron, discussion at
https://github.com/w3c/csswg-drafts/issues/1246
astearns: Let's leave at that this week. Those in the discussion
please decide if open new issue.
Rossen: Should we resolve on to CR?
astearns: Let's give another week and go to CR next week.
CSSOM
=====
Replace steps of set a CSS declaration with some constraints
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/2924
emilio: Issue is that the latest resolution on how set property
behaved: it always appends to end of declaration so it's
sane with logical prop. It's a nightmare of webcompat and
perf for Gecko and Blink
emilio: We turned it off in Gecko and backed out in Blink. xidorn
had this proposal to let a set of properties in a logical
group and in a UA dependent way that's in same logical group
it need to appear after so setProperty behaves correct
emilio: I think frremy...what xidorn did in gecko which we haven't
landed is that if you get to the case where a prop and
there's another from the group that defers we append the new
prop
emilio: xidorn proposes to define in terms of constraints which I'm
okay, but prefer define properly. Only reason not to do is
proposal from frremy. We need to decide if we're fine
resolving like this or if fine to say it's constraints and
UA can do what they want or define algorithm in spec
frremy: From what I recall my proposal was pretty in line with
constraints. I'm fine with them as defined. Good to have UA
experiment. If it's fine we can refine further. Fine to go
with xidorn proposal for now. It makes a lot of sense.
emilio: Okay
astearns: I agree, emilio. It's good to have things properly defined
once we have impl experience and can determine the
constraints. Happy starting with the PR and adding
emilio: People fine with gecko algorithm as an example?
florian: Sounds okay
astearns: As a note?
emilio: Pretty much.
astearns: Objections to having the PR
https://github.com/w3c/csswg-drafts/pull/2924
as the start of a set of constraints with gecko algo as an
example in a note?
frremy: Sounds good
RESOLVED: Have the PR https://github.com/w3c/csswg-drafts/pull/2924
as the start of a set of constraints with Gecko algorithm
as an example in a note
astearns: Anything else on this?
CSS Overflow
============
How does max-lines interact with hidden content?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2421
florian: This started much broader and we're almost done. Just a
corner case we haven't decided explicitly.
florian: The broad topic is which lines do we count when we have
max-lines and a decedent or BFCs or a child also with
max-lines. We resolved we skip when you nest max-lines.
Resolved for most of overflow. Remaining bit is
overflow:clip
florian: overflow:clip is not a BFC so it implies you could the
lines inline overflow:clip. I think close this with no more
changes needed.
Rossen: Is the issue different if overflow:clip is applied to
max-lines container?
florian: This is on descendant
Rossen: How is it different then when on max-line container?
florian: On container it doesn't do anything special and overflow
not terribly relevant.
Rossen: But then you can extract same thing happens with child.
florian: So you're okay no change?
Rossen: Yes
astearns: We could lines in descendant with overflow:clip, but only
not overflowing?
florian: Count all the lines
Rossen: Overflow:clip doesn't effect count of lines
florian: Right
astearns: Gotcha
astearns: Objections to keep current definition such that we could
all lines in overflow:clip descendant?
fantasai: I think this is correct. Might be initially confusing but
it's the right model
RESOLVED: Keep current definition such that we could all lines in
overflow:clip descendant
CSS Text
========
Percentage of 'text-indent' against intrinsically sized box?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1597
florian: Had previous discussion about text-indent and % and we
resolved which element to resolve % against. Not that
discussion. This is what do we do when intrinsic sizing. If
indent grows the size and depends on the size we've got a
loop
florian: I think we got close to consensus but ran out of time. I
remember that no one had a use case for % text-indent on an
intrinsic size thing so easiest is to say % resolves to 0
and there's no loop.
florian: Alt is min-content. That works for me too. I don't think
this is use case driven.
florian: Only thing to push us toward not-0 is people might want
large negative % to hide stuff. Dunno if done much with
text-indent. So I'd go with 0, but min-content is okay
<Rossen> +1 to 0-
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%3B%20text-indent%3A%2050%25%22%3EThis%20is%20a%20test
dbaron: I think normal thing in these cases is we resolve to 0
during intrinsic-width computation and then resolve width
during layout. Is that what you mean with 0?
dbaron: I think that's how we treat % padding and % margin.
<Rossen> what David said ^
florian: I think that's fine
astearns: Prop: Handle % text-indent in intrinsic size box same as %
in padding and margin
Rossen: This is current behavior as well, we resolve % against
containing block so we can't resolve them during intrinsic
sizing.
astearns: Other opinions?
<dbaron> (I think this is also what Mats was asking for in the
issue.)
<tantek> what Rossen said
astearns: Obj?
RESOLVED: Handle % text-indent in intrinsic size box same as % in
padding and margin
fantasai: % padding and margin on a child of the element
dbaron: I think it's the same as on that element
fantasai: No if you set explicit width resolves correct
Rossen: Not really. Element is being intrinsically size. That's the
same so text-indent can't resolve just like you can't do
min-width etc.
fantasai: But when you do resolve it's the size of the element, not
the size of the parent. Which is different then margins
and padding which look at parent
Rossen: Don't see how child comes into play. But let's move on.
We're on same page
Implement or unship word-break:break-word
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2390
fantasai: I think it's that we have issue open about adding
non-standard word-break:break-word to CSS. Not
word-break:break-all. This allows you to wrap if you run
out of room. Should have a property with same behavior
where word-wrap:break-word effects intrinsic size of
element
<tantek> can we get intent to unship by whoever supports it if it's
not a compat problem?
fantasai: We were asked to add new value word-break:break-word for
web compat and we pushed back because it's confusing. We
said we'd add value if FF and Edge found themselves
compelled for web compat to impl. They have not so far. To
not go down that path we made word-wrap:break-word have
the same behavior that they would have gotten from
word-break:break-word
* myles is not following
<tantek> myles does Safari/Webkit support word-break:break-word? And
if so, can you unship?
fantasai: I recommend close no change for the moment. If our
attempts to stem the webcompat problem is not successful
we'll assume Edge or FF will file an issue saying we need
this.
astearns: tantek asked on IRC [reads]
fantasai: For the moment I don't think we should ask. We should give
time for impl to catch up with word-wrap:break-word
behavior change so authors can use that in place of
word-break:break-word
fantasai: I think we need to give a year or 2 before we ask blink
and webkit to unship so the web can adapt to standards
compliant way.
florian: Also a chance this transition will be less painful since in
browsers that don't have it, the least bad fallback is to
use the property we recommend.
florian: But we can't unship until we ship alternative.
<emilio> Gecko just implemented, fwiw
<dbaron> emilio, implemented what?
<tantek> emilio: oh well, sounds like we're screwed then
<fantasai> dbaron, https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
<emilio> tantek: dbaron: The new behavior, I mean, sorry:
https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
tantek: I wanted to comment that the process that we should wait on
compat is orthogonal because compat has nothing to do with
what authors want. Compat is are we screwed by what's in the
past. If we're screwed waiting won't change it. If we're not
waiting can make it worse. If you're serious about dropping
you need to do it asap regardless of if the authors have an
equivalent feature. You won't avoid compat in the future by
introducing a future feature. The reasoning is poor
<astearns> +1 to tantek
florian: We're inbetween. This is sufficiently used...
tantek: Is it on the record? I want blink and webkit to say here's
why we can't unship. Let's not presume unshippability
florian: I think we have it. Need to find it
frremy: It was discussed at a F2F and Google said won't unship.
tantek: Do we have a % number to justify not unshipping?
frremy: I think they did.
tantek: If they did did they give us a % for if it drop below
they'll unship? That's what we need for this to be numbers
based
<Rossen> +1 to tantek
fantasai: Blink contacted site owners asking them to change. Site
owners didn't want to change because they needed specific
property behavior. We need time for that.
<tantek> emilio can you link the FF impl bug or FF intent to ship?
<emilio> tantek: https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
fantasai: florian was saying that we're in-between. Usage is not
high enough that Edge and FF need to impl, but too high
for chrome and blink to unship. Gecko has implemented new
property behavior and not non-standard thing
fantasai: We need to wait for that change to deploy across browsers
so site authors will change and then reduce web compat
impact and then let them unship
<fantasai> https://github.com/w3c/csswg-drafts/issues/2390#issuecomment-380422690
<tantek> where is the commitment to implement the new property/value
behavior from others?
<tantek> is FF the only implementation?
astearns: We're overtime. Whether or not we can get unship for
non-standard...Well, this issue is impl or unship so I
think we can resolve not to add non-standard property but
unship question is in the air.
fantasai: My recommendation is we close or defer this issue so it's
not sitting
tantek: Let's defer
frremy: Defer to next level. I like this
florian: Defer good
astearns: Objection to defer this issue for now?
RESOLVED: defer this issue for now
Received on Thursday, 19 July 2018 09:02:13 UTC