- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 15:58:23 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Flexbox
-------
- RESOLVED: Accept the proposal to have width/height influence
min-content contribution of shrinkable flex items
[https://github.com/w3c/csswg-drafts/commit/4225207523013fe3d5689b1b37ca4df5142437c3 ]
(Issue #2353)
max-lines & block-ellipsis (CSS Overflow)
-----------------------------------------
- fantasai and florian introduced their proposal to create two new
properties, max-lines and block-ellipsis, which combine into a
shorthand line-clamp.
- The goal of these properties is to serve as a replacement for
-webkit-line-clamp while removing some of the behavior
people don't like, thus allowing browsers to alias
-webkit-line-clamp to line-clamp.
- Generally this was favorably received though there were
requests to add more examples and notes as well as to ensure
that there won't be breakage when an implementor switches
from the current -webkit-line-clamp behavior to line-clamp.
- An issue will be opened to ensure that the extension path for
these features is clear before this can go into a full WD.
- RESOLVED: Continue this work in Overflow as an ED
- RESOLVED: Copy text-overflow from UI3 to overflow-3, move
text-overflow from UI4 to overflow-4.
- RESOLVED: Having max-lines not apply across BFC boundaries (Issue
#2429)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Christian Biesinger, Google, observer
Brian Birtles, Mozilla
Oriol Brufau, Observer
Tantek Çelik, Mozilla
Monica Dinculescu, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Simon Fraser, Apple
Jihye Hong, LGE
Koji Ishii, Google
Dael Jackson, Invited Expert
Ian Kilpatrick, Google
Rune Lillesveen, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Naina Raisinghani, Google
Manuel Rego, Igalia
Florian Rivoal, Invited Expert
Richard Rutter, Clearleft
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Shane Stephens, Google
Surma, Google
Majid Valipour, Google
Lea Verou, Invited Expert
Eric Willigers, Google
Scribe: dael
Rossen: I want to thank the hosts. It's been an awesome venue. Vlad,
thank you for organizing and TYPO was a great host.
Flexbox
=======
Min-content sizing currently too smart to be web compatible?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2353
fremy: The issue was that... by default when you can shrink could
shrink to the min-content. Web expected specified width to
be considered as well. I reviewed the change and it seems
right, but the summary was missing details.
fremy: Still means you have elements that could shrink further but
will not. I'm fine with the change how written.
Rossen: What's the summary?
fantasai: We made the min-content contribution of the flex item
consider specified width and height.
cbiesinger: Does it match what min-width: auto computes to?
fremy: Spec changed the minimum size all the time. Width works
anyway.
fantasai: If we changed how 'min-width: auto' works it would
change how it shrinks down.
fantasai: We had to do it through the min-content contribution
rather than 'min-width: auto' because the web depends
on it.
Rossen: Proposed resolution is accept this change?
fremy: The width and height property does affect min-content
contribution, right?
fantasai: Yeah.
cbiesinger: We don't implement intrinsic size computation per spec.
Does anyone?
Rossen: We're close. We had reworking recently and since we were
close to shipping we had to pull back due to unexpected side
effects. This is part of the changes.
Rossen: So, kind of.
cbiesinger: You find it web compat?
fremy: We won't know until we do this fix and try again.
cbiesinger: I should prioritize?
Rossen: Yes fingers crossed.
Rossen: Objections?
RESOLVED: Accept the proposal
[https://github.com/w3c/csswg-drafts/commit/4225207523013fe3d5689b1b37ca4df5142437c3 ]
CSS Overflow
============
max-lines / block-ellipsis / -webkit-line-clamp
-----------------------------------------------
<fantasai> https://drafts.csswg.org/css-overflow-3/#max-lines
<fantasai> https://drafts.csswg.org/css-overflow-3/#block-ellipsis
fantasai: There's been a need to have the -webkit-line-clamp
property specified and implemented.
fantasai: Problem with it is it has a lot of problems. Clamps
container but overflows visibly after the ellipsis. It
puts ellipsis after any character. It requires old flexbox
display in webkit.
<fantasai>
https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
fantasai: florian and I tried to figure out how to have a feature
that does mostly what webkit-line-clamp does but less
broken and builds on features we want.
fantasai: Decided it might make sense to split the control to number
of lines and ellipsis. So we filled out max-lines definition
and added a separate block-overflow property.
fantasai: Spec I'm sure isn't perfect but wanted to review and get
feedback and support for folding this into main draft.
fantasai: Way max-lines works: specifies the number of lines and it
only applies to block containers. Counts number of in-flow
line boxes and forces a break. That triggers standard
fragmentation behavior and the content acts much like if
it was display:none.
fantasai: We wanted max-lines to work across block boundaries. For
example, you want to break after 10 lines but you don't
know how many paragraphs there will be.
fantasai: Open issue as to whether we want to cross BFC boundaries.
fantasai: max-lines skips over other types of content like a table
or flex/grid. We jump over it, effectively.
astearns: Do not count it?
fantasai: Yeah.
florian: Tables and flex and grid can be fragmented but it would be
more complicated and not use case driven.
fantasai: That's an overview of max-lines. We added block-overflow.
It inserts content into the line box before a forced or
unforced region break.
<dbaron> Is there a way to do block-overflow indicators based on a
height rather than a number of lines?
florian: Region break terminology is a little unfortunate.
fantasai: It depends on css-break not css-regions. It's just a third
type of break (others being page and column).
florian: We should fix that word to make them not think it depends
on css regions. It would work with regions if we have them,
but it doesn't require you to impl regions.
fantasai: Naming is a bit confusing, but should be fine in general.
fantasai: When you combine the features max-lines causes a break and
then block-overflow adds the ellipsis. For text-overflow
you don't remove the content, you just hide. Right now we
allow doing that here, but going forward as we have regions
and want ellipsis between we can't just remove the content
because you want the content in the next region.
fantasai: Spec is written to specify that you move the content to
make space for ellipsis and if there is no next region you
can do it as a visible paint time, so that UA can reuse
text-overflow behavior. Slight behavior difference since
when you click on ellipsis it goes through to the content
that's behind it, and also if you actually move the content
it can change height of line.
fantasai: But those seem like small differences, so for now it seemed
better to leverage existing text-overflow behavior instead
of forcing the better behavior. But both are allowed in the
spec.
florian: There is an issue about picking one.
florian: In respect to the amount of text you remove to place the
ellipsis, you find the point to remove based on the same
rules as line-breaking, so we honor those properties here.
fantasai: If you allow line breaks at this point it's a reasonable
point to cut and move on, instead of after every letter
as WebKit does.
florian: And that should limit misinterpretations of where to slice
text.
fantasai: line-clamp is just a shorthand for both properties.
myles: When would you use block-overflow without max-lines?
fantasai: When there's overflow fragments in the future. At this
point in the impl of CSS, max-lines is the only way but
once we have multiple regions you can use this as well.
Rossen: Thank you for starting this work. Few comments. I recently
had some experience implementing -webkit-line-clamp. You
started by saying it's not really good. I would argue that
point, I think for what it does and the way it's built from
impl PoV it's straight forward. It doesn't require heavy
fragmentation logic when you break or trigger any orphans or
widows.
fantasai: Neither does this.
fantasai: It creates a forced break which is not subject to the
break avoid conditions.
fantasai: We thought about that.
astearns: There is a note about that in the spec.
Rossen: Okay, that's important.
Rossen: Apart from history the one thing that I was curious about is
when do you foresee a usage of max-lines without
block-ellipsis?
fantasai: I want the first 3 lines of my paragraph in all caps or I
want the first 16 lines to be full width and the rest in
two columns.
florian: This is the first step where this says 5 lines and discard
the rest. In the L4 we'll be able to put the rest of the
content somewhere. Be it from regions or another approach.
This was designed to be compatible with all the future
options we've considered so far.
Rossen: So this introduces a new fragmentainer that applies to
anything. Now I can add max-line to a table cell. But it's
not really a region so I can't use region APIs.
florian: If we as a WG decide we want to implement Regions we can
do that. This is designed so that if we revive Regions it
works; and if we do the overflow fragments proposal,
it also works.
dbaron: I think the model Florian described doesn't have the right
graceful degradation properties to be extended in the future
to different styles for different fragments. If the model
right now is you get these lines and the text disappears if
we add this where you get these lines and then you style it
will degrade in older browsers where you get these lines and
the rest disappears.
florian: We do have @supports and that can help, but yes.
fantasai: With overflow fragments you can also do max-lines as the
style on the first fragment of the chain, so it won't
take effect unless we're doing overflow: fragments.
florian: Another way is to require another property where it doesn't
turn things into a fragmentainer, it only applies to things
that are, and then have a value that means throw this away.
That seemed like overkill at this level
dbaron: It seems like an important usecase if to break the block at
a certain height, not a certain number of lines and it
doesn't address that.
florian: We aimed for a smaller subset. If we re-introduce the
property I just mentioned you can use it with max-lines or
max-height and it works.
florian: To an early comment from Rossen that the nice thing to
invoke all in -webkit-line-clamp...what does it do when
there is a float in the middle?
Rossen: Currently it overflows if your float fits. People use
-webkit-line-clamp and if it clips it clips. Intended usage
is not to put your entire article and have it overflow,
usually people use it mostly for shortening text so it looks
nice and has card-based layout with titles you can nav from.
florian: If we ignore funkiness of being in an old-style flexbox...
the main trouble is if you apply it to just text it does a
job that's close to what's wanted, but it's not extensible.
This is.
Rossen: I'm just correcting the overstatement that it's bad. I'm not
pushing for -webkit-line-clamp
cbiesinger: Spec says -webkit-line-clamp is an alias of line-clamp
but line-clamp applies to more. So would
-webkit-line-clamp on a flex container be ignored?
florian: The intent we had was to write it knowing that it's not
quite right and wait for people with impl experience to
tell us what is the least amount of strange things we need
to do for web compat.
cbiesinger: We have to make -webkit-line-clamp make it not be not a
flex container perhaps.
fantasai: Interesting idea.
florian: I hope we can spec web compat with minimal craziness.
cbiesinger: Have to do something about it though.
Rossen: Currently -webkit-line-clamp doesn't allow 0.
fantasai: 0 or negative int are invalid and cause declaration to be
ignored. In max-lines and in line-clamp.
Rossen: We've discussed in the past about ellipsis moving toward
being a pseudo element. For the block ellipsis I hope we can
still go through that path.
fantasai: Think so.
florian: Whatever the pseudo element is the initial value is normal
and you can override that. We'd need to figure out exactly
how it should work.
TabAtkins: And there's a further note about letting an actual
element force itself to be an ellipsis.
fantasai: I want to get there eventually, but we have to start
somewhere.
Rossen: Apart from these comments, what do people think? Would this
attract impl interest?
eae: We'd want to do this.
myles: It's an interesting idea.
myles: We don't want to have 2 separate incomparable
implementations. I'm a little worried because it's not
exactly the same it won't work well. I'm comfortable moving
forward with this with the idea that if this requires a
second impl we should change css property to not require.
florian: I understand. I'm hoping the amount of differences can be
limited and scoped to aliasing
fantasai: We don't want to need different implementations for
-webkit-line-clamp and line-clamp.
florian: Not for layout differences. I just want things like if you
need that weird webkit property for flexbox.
Rossen: The simplicity of how webkit works where you layout flex
item and count and then redo your layout with max lines
allowed and then you re-layout with just those lines. This
isn't layout. If you don't have full fragmentation and
handling of breaks so everything around fragments sensible
you have to do more work. What myles is saying I don't
believe will be true. You can't do property aliasing and
have -webkit-line-clamp. I don't believe it can ever be this.
<fantasai>
https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
fantasai: We're expecting if you have a -webkit-line-clamp you have
to create a separate impl of this and then remove
-webkit-line-clamp and have it alias to this. The code
inside your browser cannot be extended to this, but once
you impl this you should be able to get rid of the old
thing. We're hoping this is an acceptable substitute.
There are issues around -webkit-line-clamp and the behavior
changes are that we fixed those.
TabAtkins: That it's not a fragmentation container is the thing that
makes it hardest to work with.
florian: It is simple to impl, but not good.
Rossen: I'm not defending -webkit-line-clamp, I'm pointing out that
the impl of this will be very different.
myles: I'm worried that because they're different enough we won't be
able to remove original impl. If we need 2 impl of same
feature that's not good.
florian: I'm concerned but hopeful.
fantasai: We've been getting requests for block ellipsis that
doesn't suck.
myles: Some behavior changes are okay. Issue is about breaking
websites. We're comfortable with not exactly the same.
fantasai: Goal is to not break websites unless they depend on the
lines after the ellipsis being visible or the ellipsis
being after every character, both of which seem undesirable
even now.
florian: We'll need to see. We can't answer for sure until we try
and impl.
TabAtkins: This is so unambiguously better.
tantek: It's clear that it's better. Does it satisfy a superset of
the use cases?
TabAtkins: Yes, but fantasai listed the "use cases" not satisfied by
this and they're all bad.
fantasai: They're things people have complained about.
florian: It is possible that some website depends on things behaving
badly.
tantek: You won't know until someone impl. But us arguing won't make
a difference until we try.
fantasai: Do people want to impl this spec? There are individual
issues, but we just put this proposal in the ED. We can
make it dependent on some issue.
fantasai: It hasn't been in a WD
fantasai: max-lines was not written, it was just waiting for text.
florian: Do we want to pursue this?
TabAtkins: We have a concern about it counting BFC. Or orthogonal
flows it would count into....that should be carved out,
maybe other, perhaps exempting BFCs.
florian: That's the first issue on out list.
dbaron: I have mixed feelings. It seems like it's based on a future
model in your heads, but it doesn't offer a good extension
path.
fantasai: florian said we could make 'continue: discard' a required
part. We can put that into the shorthand but if you use
max-lines you then have to set 'continue: discard' to get
useful behavior. In that case, if you leave 'continue: auto',
it overflows.
florian: Max-lines would do nothing.
fantasai: We can think about what to do there. There are interesting
things we can do like shorten the container but not clip.
tantek: Sounds like you accept the concern but don't need to solve
it right now.
fantasai: Sounds like that would solve it. It is solveable.
florian: We can open an issue on it.
tantek: Open it as a blocker for WD.
florian: I don't know if this was implied in your comment, but as
spec now it's meant to be compatible with future, but
doesn't need it to work.
florian: I'm not sure if you were saying that.
tantek: He was talking about creating a new compat problem.
fantasai: I prefer to have a 'continue' step folded in. I think it
would make max-lines more powerful.
florian: I'll file the issue.
tantek: I think overall I like the direction and I'd like to add to
it. I'd like to see more explanation of the relationship and
differences to text-overflow. There's one reference right
now and if you're new to text-overflow you need to have a
better explanation of when to use each or together.
florian: More notes more examples.
tantek: If you put this here, which I think you should, I suggest
moving text-overflow here to be right before the
block-overflow definition.
fantasai: Makes sense.
tantek: I think text-overflow is simpler and gets people to look at
it first, see if it fixes the use case, and then move on if
it doesn't.
fantasai: Makes sense.
myles: I'd like to hear more about what you think the future is for
this.
florian: As a first bit, the 'discard' value is part of regions and
the other thing [overflow fragments proposal] the CSSWG is
considering. Regions has a property to control what happens
to the last region in the change. It's that property we've
re-purposed with more values. There's a rough sketch of that
in Overflow 4. Once you overflow we create a clone and put
the remainingt there.
fantasai: You can discard the extra content, let it overflow the box,
or clone the box and fill that--and each of those clones
can be individually styled. There's also a value that turned
it into a paging thing so that the box once you run out of
content it makes a paginating mechanism.
florian: That last is most exploratory.
fantasai: That's a bunch of brainstorming. We might not get all of
those but it looks toward that.
florian: Clone overflow and discard are realistic. Paginate might
not be.
myles: When you clone the box how do you place?
fantasai: Sibling in the box tree.
myles: Special selector to select?
fantasai: Yeah.
myles: That's a little worrying.
fantasai: It's a rough sketch in L4. But this is compatible with
everything we've considered so far: both that proposal and
Regions.
myles: I'm worried we reinventing regions.
fantasai: This is a tool that can expand to help regions or help
fragmentation.
myles: We should make a note that this should work well with regions.
fantasai: It does.
<TabAtkins> Let's not let architecture-astronomy over region-ish
things prevent us from just Finally. Solving.
Block-overflow.
astearns: I don't look at this as a thing that will flower into some
duplicate this. It is just some fragmentation tools that
will work in any fragmentation context we've considered.
myles: If you'll use the super-special selector and wanted 3
clones...?
florian: If you do max-lines or max-height on the element it gets
cloned and that applies to all clones.
astearns: This is a separate feature.
florian: That's the vision, but not necessary for this level.
myles: When and if that happens proposal should be clear on
interaction with regions.
fantasai: Yeah. I think it's clear.
florian: I suggest you look at L4. It's not well defined enough to
be implementable, but it can give you a sense of what we're
aiming for.
florian: We don't have to head toward that specifically because it
would also work with regions.
Rossen: [missed]
florian: We considered it but making max-lines apply to columns is
weird
Rossen: max-lines per column?
florian: Once there's a pseudo element to target columns why not?
myles: I'm a little worried because it seems like the direction is
re-impl stuff.
florian: Trying to use things that exist.
myles: As long as when it happens the relationship is well defined
it's fine.
Rossen: We have a request by dbaron to open an issue and address it
before we move into a WD. I'm assuming florian will file
that.
fantasai: There's a handful of issues to discuss, but we want a
resolution that we're putting this in the spec.
tantek: I'd like to see text-overflow folded in before WD.
florian: We can resolve to move text-overflow to Overflow. I think
we should put the UI3 definition into overflow 3.
Rossen: Objections from moving text-overflow out of UI 3 and into
overflow 3?
RESOLVED: Copy text-overflow from UI3 to overflow-3, move
text-overflow from UI4 to overflow-4.
florian: Do we resolve as a WG to pursue this?
Rossen: There's the issue dbaron wanted.
florian: I want to know if this is a thing we're interested in do.
fantasai: Or do we remove the text from the ED.
<tantek> +1
Rossen: Back to next steps. I've heard a number of people supporting
this and also a number of concerns before they really
commit. I think it's net positive.
fantasai: Question is does the WG like this and leave it in the ED
or remove it from the ED.
TabAtkins: Yes.
eae: Yes.
Rossen: Other browsers?
tantek: We've seen demand for more text-overflow like features. I
agree there's a need.
fantasai: Do you want the text to be removed or in?
tantek: I haven't heard anyone say they don't like it. I'm in favor
of optimistically letting editors put something in the ED
for review.
florian: Do we need a resolution to keep working on this?
fantasai: If the WG doesn't want us to work on this we shouldn't put
time in. If the goal is to have us work on the issues and
then people say they hated this from the beginning, that's
not useful. I just just want approval to have the properties
in this draft in this order.
Rossen: Objections to continuing this work in the ED?
florian: My reading from the Mozilla bugzilla there is interest.
fremy: What I don't understand is why is this in overflow?
florian: We had to put it somewhere.
TabAtkins: Overflow is in the property name
tantek: From a webdev view it talks about what you do when things
overflow.
fantasai: Can we leave it in the ED? Can we get a resolution? If
people don't want it in the ED we can put it in an
unofficial draft.
fremy: Looks like fragmentation.
fantasai: It uses fragmentation, but doesn't describe it so, no.
fremy: I don't care, leave it in overflow.
RESOLVED: Continue this work in Overflow as an ED
Which descendants are skipped in max-lines?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2429
florian: Within the broad topic of what's skipped, when you're
counting lines do we cross BFC boundaries? Yes we shouldn't
count inside obviously insane things like orthogonal flows,
but what about basic BFCs?
dbaron: What sorts of BFC are okay?
fantasai: We excluded scroll containers. Orthogonal flow are insane.
florian: Nested BFCs. [gives example]
dbaron: Other then the display:flow-root that exists to create a
BFC, others?
fantasai: Align-content is probably okay. Triggers BFC when not normal.
dbaron: Which axis?
fantasai: Vertical.
Rossen: Is anyone implementing?
fantasai: Don't think so.
iank: In your implementation we skipped all this for line counting?
Rossen: Yes.
Rossen: Also when you start reasoning it becomes insane. What would
it mean on a grid?
TabAtkins: Those are all excluded.
TabAtkins: There's several in the issue.
florian: Table caption is another I'm not sure.
fantasai: We skip tables.
iank_: Someone uses display:flex it triggers a formatting context
and it will display a part.
florian: If you have a BFC that's not excluded and it's not what you
wanted you make it a flex.
TabAtkins: align-content makes me think we want it to work. We want
to do it on an align content thing
dbaron: When something with align-content is fragmented what happens?
fantasai: I don't think we define that yet.
...
fantasai: I'm not sure that's what we want. If you have a box
supposed to be centered and it's fragmented I don't think
you want each of them centered.
TabAtkins: Regardless, boxes don't have size.
fantasai: They do.
TabAtkins: Fragments have size.
fantasai: Box has computed size.
florian: Different topic.
<fantasai> The fragments eat up the computed size, they don't each
get 100px if you specify 'width: 100px'
Rossen: Is there a reason why you wouldn't want to make the easier
part work, get a model that makes sense, and then extend?
florian: I'm not against get rid of BFC.
Rossen: I'm sympathetic to exclude all BFCs, get stable, and then
see what we can include. But until we're they're we're
hypothetically speculating.
TabAtkins: Easier to cut off BFCs.
Rossen: Also that will make it more compatible with -webkit-line-clamp.
florian: Yeah.
Rossen: Prop: Having max-lines not apply across BFC boundaries
RESOLVED: Have max-lines not apply across BFC boundaries.
<br type="15min">
Received on Tuesday, 29 May 2018 19:58:52 UTC