- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:52:01 -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 Align
---------
- There was agreement on behavior, but disagreement about the
correct way to describe intrinsic sizing so interested parties
will work together over a break. (Issue #1431)
Logical Properties
------------------
- frremy brought up some confusion he's running into implementing
logical properties and how they are exposed in CSS properties
and animations in hopes that the spec can be simplified.
However, the group still felt the spec minimized author confusion
so should stay as-is.
- RESOLVED: Fix unicode-bidi to be non-animatable, and make sure
all propdefs are using the proper terminology.
(Issue #2751)
Overflow 3
----------
- RESOLVED: discarded content is treated as display:none, not laid
out (Issue #2860)
- RESOLVED: block-overflow value can be set in the line-clamp
shorthand (Issue #2860)
- RESOLVED: Add the longhands to the spec in whatever form editors
find convenient to *describe* the functionality, and add
a note requesting implementation of just the shorthand
for now. (Issue #2860)
- RESOLVED: After these edits, publish a new WD of Overflow.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
CSS Align
=========
Scribe: tantek
Should justify/align-self on abspos elements apply when offsets are
'auto'?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1429
dbaron: First one I wanted to bring up was probably this one,
about how magical do we want the initial values to be
dbaron: One of the cases where I was disagreeing was in some ways
some of these new properties are better than the old way
of doing things, and I don't feel that strongly about
this one. But there are some cases where it would be
relatively simple to make these properties work in more
cases, but it means making the 'normal' or whatever initial
value do today's behavior
dbaron: This one in particular is about justify-self and align-self
on abs pos elements
dbaron: this is not static position stuff, this is actual absolute
positioning
dbaron: IDK maybe this is kinda the same as earlier
fantasai: We discussed early justify-self align-self on a abspos
element when ...
TabAtkins: This is about one offset not being ...
fantasai: Per 2.1 the 2nd offset is computed after you compute
the width
TabAtkins: In other words like an auto margin
fantasai: Yeah
dbaron: My perspective, I've never particularly liked auto margins
as a mechanism, and these properties ought to override them
fantasai: Specific examples?
dbaron: e.g. ...
dbaron: Maybe it's ok, I'm ok with this one, but I've kinda
forgotten what we resolved here
dbaron: I'm ok with it
dbaron: There was one other one I thought was worth discussing,
and I need to find the list of issues again
intrinsic sizing in the block axis
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1431
dbaron: I think this came up in two issues
dbaron: Layout regarding intrinsic size ...
dbaron: I objected ... IDK if I'm the only upset about this
TabAtkins: IE already does layout while computing block layout
sizes so they get correct values for column wrapped ...
dbaron: Even if it is possible, we should only do it when it
is absolutely necessary
dbaron: If an alignment thing can happen after layout,
then we are better off describing it as something
that happens after layout
dbaron: instead of describing computing the intrinsic size
TabAtkins: There are other things that want this sizing
TabAtkins: such as sizing a float at all
TabAtkins: Me and fantasai already went to / want to express this
TabAtkins: customLayout already expresses ...
iank: No it doesn't
dbaron: Basically, what do you think about describing block direction
alignment as computing the intrinsic size in the block
direction and doing the alignment vs doing the layout and
aligning the result
Rossen: In our case we align only after a layout
Rossen: In general the cases of layout are measuring, arranging,
and aligning - for us
Rossen: and aligning only happens naturally after arranging
Rossen: which is what you are referring to as layout
Rossen: and measuring is what you refer to as intrinsic sizing
Rossen: ...
astearns: Do you mind if the spec says you get those block direction
measurements for arranging?
fantasai: We are talking about the sentence about baseline alignment
can influence the ...
Rossen: Yes
fantasai: If you say it doesn't increase the size of the intrinsic
box, then the size of the box won't increase
fantasai: In order to accommodate the content it will overflow
Rossen: In this case, what we would do in the cases where we need
to stretch, we do the normal pass of computing intrinsic
and doing layout
Rossen: and then do the actual alignment, and then based on the
alignment stretch, similar to what you do with table cells
Rossen: Sometimes this means we have to go and do one more pass
inside
Rossen: sometimes when you do the stretch because of alignment,
you have to relayout inside such items as well
Rossen: We are already doing it, pretty much everyone is doing it
Rossen: I don't think we have a way out of this
dbaron: I thought we were talking about a different sentence
dbaron: I thought it was the sentence "Values other than stretch
or normal cause non-replaced absolutely-positioned boxes
to use fit-content sizing for calculating auto sizes in
the affected axis."
dbaron: It used to describe ..., now it is saying you use
fit-content sizing ...
fantasai: Since min-content and max-content are the same in the
block axis, that's what you get -- either/both
dbaron: But you're using fit-content size which is not a function
of the other dimension
dbaron: but if you're doing it for layout, your layout is a
function of measurement in the other axis
fantasai: That sentence is a bit of shorthand. Could have written
out that in inline-axis it's fit-content and in block
axis it's max-content
fantasai: but I don't particularly see the point since they're
equivalent statements
dbaron: The fit-content size of a block is the result of layout
at what width?
TabAtkins: Do you have an answer to that question for min-content
instead?
dbaron: No
dbaron: Intrinsic sizes come before layout
dbaron: I think you defined it somewhere but I don't remember where
the answer was
dbaron: It doesn't particularly make sense to me so I have trouble
remembering it
fantasai: At what size depends on the rules of alignment in the
... axis
fantasai: The rules for layout says you lay out in the containing
block minus the margin, border, padding... then depending
... 100% of that remaining space, or shrink wrapped
fantasai: ... or block size, and then that becomes the size used
fantasai: ... and then when you do alignment ...
fantasai: [missed]
<fantasai> Rules for abspos say that you find the inline size using
the containing block size, offsets, margins/borders/
padding, etc. Take the remaining space, lay out into that.
astearns: dbaron do you have alternate wording that you would be
satisfied with?
dbaron: I think I liked what was in this section before
dbaron: If you are aligning in the block direction, you do layout,
and then you align the result
astearns: Seems reasonable to me
astearns: fantasai you were using the phrase the content-based size
astearns: rather than intrinsic size
fantasai: Intrinsic sizes are content-based sizes
fantasai: the size of an image is an intrinsic size
<fantasai> To find the content-based (intrinsic) size in the block
axis, you need to lay out the content into the inline
size to find out how tall it is
<TabAtkins> https://github.com/w3c/csswg-drafts/commit/7d1efdc3e96a94a6a426016d8752a2ddcd10af59
Rossen: Intrinsic sizes are well defined in the inline direction,
and in the block direction (too soft to hear)
Rossen: Talking about intrinsic sizes in the block direction...
Rossen: I think what dbaron is suggesting makes sense, which is
you layout and then you align
Rossen: I don't know what it means to align then layout
TabAtkins: My issue here is that the text before we made the change
was effectively identical
TabAtkins: We didn't change the concept at all, we just made a
copy/paste error
TabAtkins: Before we said ..., now we said ..., but that didn't
change the meaning of the sentence at all
dbaron: I think there might have been something else before a prior
edit
astearns: If archeology, then we table this for now, and work on
whether there was previous wording that was better or
can we improve it now some other way
Rossen: Can we whiteboard it at the break
fantasai: No argument about behavior, just terminology
TabAtkins: Happy to fix terminology offline
astearns: Any other alignment issues
dbaron: I don't think so, but the thing we discussed is why I was
unhappy with 2 or 3 of them
astearns: Table this for now
Logical Properties
==================
Scribe: TabAtkins
Simplifying logical properties
------------------------------
frremy: I was looking at logical props, and the more I tried to
work on this and discussed with internal devs, the more
we realized how crazy the whole thing is
frremy: We never had the concept of ordering properties within
a declaration block before, but now we need it
frremy: For margin-top vs margin-before, etc.
dbaron: We explicitly decided to depend on that when we went with
this proposal.
frremy: And then it goes further - you don't know the mapping
until you compute writing-mode/etc
frremy: And if you're animating these values, their meaning can
change.
frremy: If you're animating margin-top and margin-start, and in
the middle of the animation change writing-mode, they
might change directions completely
frremy: Implementing this is very tricky - doable, but tricky.
frremy: So I get the value of these logical props. I don't think we
need to have both of them working together at the same time.
frremy: Why do you need margin-left and margin-start both working
on the same element?
frremy: I think pages generally use one or the other.
frremy: So can we instead use something like using margin-before,
margin-left never applies?
fantasai: margin-inline-start is used in the UA style sheet, so
your proposal would make physical margins *never* work
on any element with those margins applied.
frremy: Edge doesn't do logical yet, and this works
fantasai: We used to do it with magic, but we don't want the UA
stylesheet to be magical if possible.
fantasai: The point is that we don't want authors to have complicated
rules to reason about, and changing behavior like this is
troublesome for them.
frremy: I think it's confusing now.
fantasai: It's confusing for the implementor, less confusing for the
user. We value the user's confusion over the UA's
confusion.
frremy: I just think the complexity of having these mapped properties
that can change at runtime, in the middle of animations,
isn't worth the complexity.
emilio: Animations get canceled when the element turns display:none,
right?
emilio: Can we do the same when writing-mode or direction changes?
dbaron: I don't think that's needed. Style changes during animation
already requires you to recompute style.
dbaron: True of changing fontsize when you're animating a length in
ems.
dbaron: This is a little bit different, but not *very* different.
frremy: I see the point, but it's much more difficult for us.
myles: An animation example, the content author is animating a
logical
property and switching writing mode, so the margin that
animates changes. That seems expected...
astearns: Part of the example is animating left and start at the
same time.
myles: My second point is that according to caniuse, we have wide
interop on this.
frremy: In Chrome the props don't have the right name and different
values...
fantasai: Being fixed now.
frremy: If people are fine with the current model, I'm fine with
letting it go, but now that Blink is trying to follow the
spec, I think it's a reasonable time to discuss this.
Rossen: So wrapping around your proposed simplification - you're
saying if you have a logical prop you don't look at physical
anymore?
frremy: yeah
Rossen: So if I have margin-inline-start:10px, and margin-right:5px,
depending on writing mode I may or may not pay attention to
margin-right?
florian: No, it's a kill switch. You don't pay attention to -right
at all.
Rossen: Ah, okay. So it's per-element.
Rossen: What does that mean for cascade? If I say margin:inherit,
what happens?
frremy: You still cascade/compute normally.
Rossen: So inheritance is not affected, what I would expect.
Rossen: So say we have margin-right:2em...
frremy: I think computed style would still be two different things,
but used style would merge them
Rossen: So you have both logical and physical props resolved to
computed values.
Rossen: From which point you have to start animating.
Rossen: So I have any logical property specified, all the physical
ones are excluded from animations...
fantasai: No, they animate, they just don't do anything.
Rossen: Okay, cool. So they've animated. Now we do layout.
Rossen: So we say "I have a logical value specified, so I don't pay
attention to physical ones".
florian: So the killing is per-group? margins, separate from padding?
frremy: Yes
florian: What about ones that are linked? overflow and background?
frremy: They're separate
florian: Okay, so just the shorthanding relationships.
fantasai: I think it's reasonable for the author doing not doing
vertical text, just dealing with English and Hebrew,
to use margin-top/bottom, but then depending on what
they're doing, using margin-left or margin-inline-start.
fantasai: I think it is bad if, as soon as they apply a
margin-inline-start, it'll turn off margin-top and
margin-bottom.
frremy: They can switch to block-start and block-end...
fantasai: I think this is a bad model, we decided explicitly against
this before.
myles: I agree with fantasai in her assertion that authors wanting
to use only logical or physical isn't right - we've seen a
lot of UIs that are only for horizontal, and fantasai's exact
example happens
dbaron: Also, if it's a large project, you'd have to get every
component to use the right property, and they might be
used in other contexts...
myles: And there are 3 browsers that all implement this, so impl
complexity doesn't seem like a very strong argument
Rossen: We've had unexposed logical props since IE9.
Rossen: So this isn't about what's not possible, it's about how
they're exposed in CSS properties and animations.
Rossen: I think François is only saying that when you expose the new
properties via css it's problematic.
heycam: I agree that we could probably have come up with a better
model, though I'm not too interested in changing now.
heycam: But one suggestion is to have two completely separate sets of
props, and for layout purposes you add them together.
fantasai: Which is incompatible with what's shipping today.
frremy: Okay, I was getting the temp of the room, but people don't
seem too happy about it.
heycam: I agree that the OM implications aren't the best.
Writing Modes
=============
Animating writing-mode/direction
--------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/2751
birtles: Like François says, animation is tricky because they share
the same computed properties
birtles: and animations works on computed values, so you need to do
mapping to computed properties before you animate
birtles: This is different to font-size
birtles: There the dependency is between property *values*, but here
it's a dependency between properties themselves
birtles: In gecko, we distinguish between properties from animation,
and changes from OM.
birtles: Re-resolving that mapping in response to animation change
is harder than in response to OM change
birtles: So it does add significant complexity
birtles: I think if we say they're not we still need to update the
mapping from OM, and that's some complexity, but much less.
<fantasai> Actually, writing-mode, direction, and text-orientation
aren't currently animatable anyway
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#direction
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#propdef-writing-mode
florian: Any use-case for animating?
[TabAtkins tries to imagine a use case, other people say it's not
very credible use case]
heycam: Why are direction and unicode-bidi excluded from all
shorthand?
TabAtkins: They shouldn't have been in CSS in the first place,
they're really content attributes
fantasai: They're already described as "animatable: no"
florian: It's unclear whether that's the old meaning of "no"
(meaning "discrete"), or the new sense (meaning not
animatable)
fantasai: Currently unicode-bidi says "discrete" and the rest say
"no", which doesn't make a lot of sense
astearns: So the proposed resolution is to take
direction/writing-mode/unicode-bidi and make them not
animatable
shane: This'll be confusing for authors if they do put them in
keyframes
fantasai: Authors already shouldn't be using direction or
unicode-bidi in stylesheets
shane: That's a good argument in general, then!
RESOLVED: Fix unicode-bidi to be non-animatable, and make sure all
propdefs are using the proper terminology.
frremy: With this resolution, I'm much happier about the previous
topic.
Overflow 3
==========
max-lines is not forward-compatible
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2860
florian: Issue raised by dbaron
florian: The way we've specified, max-lines automatically makes the
thing into a fragmentainer that discards the leftover
content.
florian: The problem is that in experimental L4, we have a property
that lets you turn arbitrary elements into fragmentainers.
One possibility is discarding, another is the content goes
into an auto-generated pseudo-element sibling.
florian: So if someone is trying to use L4 to say "3 lines in first,
put rest in cloned element", it'll work in browsers that
work in L4, and discard the content in L3 browsers.
florian: The way fantasai and I propose to solve this is to backport
the property only with "auto" and "discard", and max-lines
is changed to only apply to fragmentainers.
florian: So if you turn on continue:discard, max-lines will work,
otherwise it won't.
heycam: This has some implication on the names of values in
block-overflow, right? Maybe "clip" should be "none"?
heycam: block-overflow property has ellipsis/clip
heycam: But clip sounds like something you want to apply to the
fragmentainer concept.
florian: Yeah, these are different, but if you think the names are
confusing, I can't disagree that bikeshedding might be
useful
florian: Additionally, shorthanding...
florian: We have max-lines (triggers fragmentation breaks after X
lines), block-overflow (at that fragmentation break, insert
ellipsis or not), and a shorthand called line-clamp, which
sets both.
florian: To make it easy to use, line-clamp would also set
continue:discard, making it a fragmentainer.
florian: And to set it all in one go, you could set the
block-overflow part in line-clamp
florian: So `line-clamp: 3 ellipsis`, etc. would be valid
Rossen: Is this model... if I have `max-lines: 2` and `widows: 3`,
what happens?
fantasai: It triggers a forced break, so any avoid-break controls,
like break-inside/widows/etc are overridden.
Rossen: So it disables all of the smarts
fantasai: To an extent.
fantasai: If you have max-lines:5, and a float next to it, the
triggering a forced break after the five lines,
widows/etc doesn't affect where we break in-flow
fantasai: But once we do that, there's no forced break in the float,
it's just told where the container's size is. If there's
content there, widows/etc applies.
Rossen: Second question, what happens to discarded content?
Rossen: Assume we have abspos element used for a sidebar. Its left
position depends on static position, with top:0, but it
comes somewhere at the end of content.
Rossen: So if max-lines discards the linebox that the abspos's
anchor is in, what's the static pos?
fantasai: Open issue. I'm happy to perform layout in the discarded
parts, tho.
fantasai: Main reason to not do layout are for performance. But
most use-cases are small amounts of content, or that
you're gonna dynamically reveal anyway.
fantasai: So my inclination is to say we do layout, and if there's
problems with that in the future we can change it.
Rossen: If we continue to layout it'll be fine, even if subsequent
fragments aren't the same size...
Rossen: I think in most cases UAs can optimize away without having
to do full layout
Rossen: Even for purposes of object model, if I ask for bounding
rect of something after the limit, do I get anything?
florian: The discard behavior that we're talking about already
exists in regions, in the last region. There's a switch
there.
florian: For the purpose of the discussion, this is same switch.
fantasai: We're replacing that property.
florian: Right, we renamed it here.
Scribe: fantasai
TabAtkins: I don't think we can do layout
TabAtkins: Because the absence of those lines can affect other
layout on the page
TabAtkins: Such as how other floats position
TabAtkins: A later or longer float...
Rossen: Fragmentainers are BFCs.
TabAtkins: Oh, ok.
TabAtkins: I suspect there are some things that would make it
problematic
TabAtkins: because we're changing the size of stuff
Rossen: Things that are problematic
Rossen: Obvious we're trying to hide this from render and hit test
Rossen: Computing static position for elements
Rossen: Fulfilling OM calls in subsequent content
Rossen: Also whatever needs to happen in such cases is whatever is
already supposed to happen in Regions
myles: You could potentially happen position: relative thing that's
farther down and moves up
Rossen: Similar issue with static position
florian: Doing the layout would be problematic because stuff would
interact with stuff below
florian: I don't think this is the case.
florian: E.g. in multicol, the content in subsequent columns doesn't
impact content below the first columns
florian: We just place it differently. In this case we don't place
it all
florian: You need to do layout within the columns to do the layout of
the content in the columns. You don't need to position the
columns then
TabAtkins: 4 lines of content, down in 20th line, static positioned
abspos
TabAtkins: Container is shrunken down, you have to do full layout?
florian: Yes.
florian: But that layout isn't going to impact the rest of the page
florian: You might see the top half of content if it's above the
fold, but it won't disturb subsequent content
iank: It seems like doing a layout would be too much work for
something like static pos
Rossen: For the same purposes, we have to figure out what to do for
a11y
TabAtkins: Can still be in AT
Rossen: There's visibility: hidden; and display: none
florian: Currently specified as display: none. Can change if needed
Rossen: If already done that way, then we don't care
Rossen: In that case would say don't do layout
heycam: Related things, like selections that go into the laid out but
not actually rendered frames or boxes, might be a bit tricky
Rossen: You can't for same reasons for AT
Rossen: If you consider the content that goes inside of the max lines
[Rossen draws on the board <f max-lines=5>]
Rossen: In here you have whole bunch of text with other things
Rossen: What Florian's saying is that you do layout, consume some of
this text
Rossen: And then pretend that there was a <span display=none> on the
rest of this, and that's it
Rossen: You cannot hit test here, you cannot expose to A11y
Rossen: Just as if span with display: none
Rossen: If this is the model, makes sense. Less computationally
intensive
Rossen: Just need to verify that it's acceptable to a11y
Rossen: Once you hit your max-lines, you're done
heycam: I think I would prefer that.
florian: I think that's what's in the spec, but didn't work out the
implications
iank: Also need to figure out what to say for CSSOM APIs
Rossen: This is mostly sorted out by display: none
myles: Ian's comment about laying out all that stuff so figuring out
static pos not worth it makes sense
heycam: This would be the first time when we would have some
fragments of a box be display: none and others not.
Scribe: TabAtkins
astearns: Hearing consensus that we're going to take what's proposed
in the issue
astearns: Clarify that the discarded content is display: none, and
what are the implications of that.
fantasai: So first is that discard content is display:none, not laid
out
RESOLVED: discarded content is treated as display:none, not laid out
fantasai: Second is that block-overflow value can be specified in the
line-clamp shorthand.
fantasai: It currently takes a number and affects max-lines and
block-overflow; right now block-overflow is reset-only.
RESOLVED: block-overflow value can be set in the line-clamp shorthand
fantasai: Third is to add continue:[auto|discard] to Overflow3, make
max-lines depend on the element being a fragmentainer
(such as from continue:discard), and making
continue:discard be set by line-clamp.
heycam: What are the implications of being a fragmentainer? What if
continue:discard without max-lines?
fantasai: It establishes an FC, and causes the element's overflow to
be discarded. This is a new feature
astearns: Take the element's height, and whatever lines fit into
there, it's like max-lines:X for that number.
florian: So the effect is very similar to multicol with hidden
overflow columns.
koji: What happens to abspos?
astearns: Gone, same as previous topic.
TabAtkins: It's the same as a one-column multicol, except all of the
oveflow columns are display: none
astearns: So an auto-height would have all the content unless there
was a forced break
Rossen: Selection, works on dom ranges, in the absence of actual
element computed to display:none, selection would go into
that range.
florian: Selection is a thing, yes, but depends on what you do.
Rossen: Like caret selection, if you get to the segment that's
discarded it'll continue into there.
Rossen: But a display:none element just gets skipped over.
florian: This is like a multicol with visibility:hidden in the later
columns, your caret will go into there.
heycam: So this means selection code will have to ask what line it's
in.
myles: So previously selection depended on DOM and computed style.
Now it also depends on layout.
astearns: Anyone want to revisit the display:none issue, or leave it
as it is and think thru the selection issues?
Rossen: In any script-based editor, they're laying out a magazine and
want an article to be five lines, they continue navigating
thru content, suddenly their cursor goes into the void.
florian: You already have to depend on layout. If you press down,
you need layout to know what character you'll be going down
into on the next line.
myles: News website is common use for max-lines. In this facility,
you'd get the first paragraph or so of the article.
myles: If the selection included the missing parts and they copied,
it either wouldn't contain the display:none part and depends
on layout, or it would contain parts that they don't see.
heycam: Don't we already have this with text-overflow?
florian: Yeah.
florian: If selection is a domrange, you can make it cover the
discarded part. But the copy operation itself can be smart
and skip over.
heycam: So this isn't just about recasting existing functionality.
Now I have to worry about implementing continue:discard
without max-lines, and worry about other work...
florian: If you have max-lines:3e6, it also basically is a
fragmentainer, but unlikely to actually trigger the forced
break.
heycam: I have a div with continue:discard and a fixed height,
I have to worry about dropping more stuff.
koji: I understand you saying it's similar, but defining limits by
number of lines but also by height is different code.
florian: But max-lines *already* says you're a fragmentainer that
discards things, so continue:discard isn't new code.
myles: Back to selection. If user does select with mouse, they'll
drag over the discarded part, if we want to keep that out
of the selection we need multirange
florian: No, it's the same as today if you drag over a display:none.
One range, but copy can skip the discarded part.
astearns: It's not possible to set continue directly from the
shorthand. Is there any concern that 'continue' by itself
might have applications that are separate from max-lines,
so that it's weird that line-clamp will override?
fantasai: In that case you'd probably want to not use line-clamp,
but use max-lines directly
Rossen: If the height of your element with continue:discard depends
on its siblings, like it's a grid item, every time you adjust
the height you have to relayout everything inside.
Rossen: And by doing so you might bring stuff in which is now
affecting your width.
fantasai: The way fragmentation is defined is that min-content and
max-content is constant across all fragmentainers.
fantasai: That should remain true for discarded content.
fantasai: And we should make that clear.
Rossen: I'm concerned about relayout that has to pull content up
because of resizing due to siblings e.g. in grid rows
TabAtkins: It's the same as if you put a multicol in the grid
Rossen: I have two grid items, one with continue: discard. The one
that is not sets the height
Rossen: You have to go and re-layout the second one which is
continue: discard, because you don't know what's next
Rossen: If that was a normal grid item, you'd have laid everything
out, but now you have to juggle thing.
TabAtkins: This is exactly the same as a multicol
TabAtkins: It's not a new thing.
astearns: So are we at the point we can decide that continue is a
property?
Rossen: Any other option?
fantasai: We can define line-clamp as if the longhands existed,
but not expose them yet, so L4 would introduce continue.
TabAtkins: So if we did that, if you just want ellipsis, you'd have
to say `line-clamp: infinity ellipsis`?
florian: Yeah
fantasai: And note that as soon as we started doing this, authors
were asking for "as many lines as fit into <length>";
that's what 'continue' does
fantasai: My preference is to put these three into the draft now,
but with a note asking implementors to just implement
'line-clamp' shorthand right now; but because we do need
to figure out these interactions we should go ahead and
keep them in the draft to help work them out.
fantasai: So any concerns about implementability can be figured out
later
astearns: So proposed resolution is to add the longhands to the spec
in whatever form you find convenient to *describe* the
functionality, and add a note requesting implementation
of just the shorthand.
skk: In this context, ruby is a line?
fantasai: It's part of a line.
myles: So if you said max-lines:1, you don't just get the ruby
text...
fantasai: And we'll revisit in TPAC
astearns: Objections?
RESOLVED: Add the longhands to the spec in whatever form you find
convenient to *describe* the functionality, and add a
note requesting implementation of just the shorthand.
Publication
-----------
florian: Can we do a new WD?
fantasai: We didn't do one after Berlin because of David's concern
about forward-compat.
astearns: Any objections to publishing a new WD of overflow with
all these edits in place?
RESOLVED: After these edits, publish a new WD of Overflow.
<br dur=15min>
Received on Tuesday, 24 July 2018 23:52:57 UTC