- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 12 Nov 2018 19:22:12 -0500
- 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.
=========================================
Off-Topic
---------
- RESOLVED: Proposal accepted.
Flexbox
-------
- The inclination was to allow align-content to apply to single-line
flex containers (Issue #3052) but TabAtkins is going to gather
usage data to determine if that's web compatible.
CSS Inline
----------
- Please add preferences for the rename of initial-letters to issue
#2950.
- Discussed spacing above initial letter, see slides at
https://lists.w3.org/Archives/Public/www-archive/2018Nov/att-0000/initial-letters-margin-slides.pdf
- RESOLVED: If the initial letters container has no border or
padding then the glyph content above the alignment point
for initial letter is not considered for layout. (Issue
#719)
- RESOLVED: Note to be added that the default behavior may change in
the future. (Issue #719)
- RESOLVED: The margin box of the initial letter must be inside the
content box of its container. (Issue #719)
- RESOLVED: Add an example that shows default overlap. (Issue #719)
- RESOLVED: Initial letter does not increase the height of the line
box. (Issue #719)
CSS Overflow
------------
- RESOLVED: Intrinsic block size only affected by forced breaks
(Issue #3214)
- RESOLVED: Ellipsis string is non breakable. (Issue #3213)
- RESOLVED: There is no interaction between ellipsis and
::first-line or ::first-letter. (Issue #2906)
- RESOLVED: Edit in Mats proposed solution from issue #2905.
- Text from above resolution's github:
- flow the block as if block-overflow doesn't exist
- if it caused overflow, then shorten the available space to
accommodate the size of an ellipsis and flow the last
line again
- repeat 2 until there is no additional overflow or the line
is empty
- during painting, render an ellipsis in the reserved space
in the last line (same as a text-overflow ellipsis)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule
Off-Topic
=========
Scribe: fantasai
Rossen: The topic is off-topic.
Topic: Off-Topic
ChrisL: The topic is me reminiscing a little, thinking back to
January '97
ChrisL: when I first started this Working Group, chaired the Working
Group.
ChrisL: Thinking back to like 2001, when the first TPAC was.
ChrisL: I was thinking back to the last time I was here in Lyon,
which was TPAC 2012. That was when I met Lea.
ChrisL: I was remembering back to other meetings, the one in Paris
in particular, which was the first time we came back to the
meeting together when we were dating.
ChrisL: And now we're back in Lyon.
ChrisL: So that's very happy for me.
ChrisL: *walks over to Lea and kneels*
ChrisL: Will you marry me?
LeaVerou: Yes!
*applause*
Rossen: Thank you, Chris.
fantasai: Chris, you to go back and do that again, because I have to
take a photo.
glazou: That was not off-topic at all.
?: Do we have a resolution?
Rossen: By the power vested in me...
glazou: Resolved!
RESOLVED: Chris's proposal accepted.
Flexbox
=======
Scribe: eae
Investigate applying align-content to single-line flex containers
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3052
TabAtkins: align-content for a flexbox: you can do align-content on
a muiltline flexbox but a single line flexbox does not
respond to align-content
TabAtkins: Instead we have a behavior where we stretch the line
always. Not super happy that we made that choice.
TabAtkins: The problem is there are cases where we'd like to use
alignment for single line flex container. Specifically
for things like baseline alignment.
TabAtkins: By the current definition we can't do anything about it,
it is always stretching. We can't add in the fake margin
to cause it to align.
fantasai: The lines are stretched but the individual items aren't,
if you want to baseline align you can't do that.
TabAtkins: Only moves the line, not the items.
fantasai: The proposal is to make it apply also to single line flex
containers, would allow more alignment options for
flexboxes. Nogood reason it isn't allowed already.
Main concern is whether it is web compatible.
TabAtkins: Use cases, baseline alignment, no reason why a single
line shouldn't be allowed to align but a multi-line does.
florian: A similar use case is when making lines, requires wrapping
for alignment to work. Declaring it to wrap has caused it
to work, I don't need wrapping but it isn't causing any
problems. What's the problem with having to declare wrap.
TabAtkins: Not consistent with not wanting wrapping.
cbiesinger: Makes sense but please explain baseline align items vs
lines
jensimmons: The idea that long term that people have to know that
wrap is needed isn't ideal. Better to have something
that works for single line.
TabAtkins: Compat risk is in two cases, single line row of flex
containers and non-auto cross size. In auto cross sizes,
will shrinking to the size of the elements anyway.
fantasai: If you did self alignment which pushes everything to the
top and everything is shrink wrapped and the flex
container is taller, you then have extra space, in this
case align-content can have an effect where it didn't
before.
TabAtkins: Auto-height won't have the problem.
TabAtkins: Fixed height will
TabAtkins: A column flexbox whose columns are all fixed with would
have changed behavior with this proposal
TabAtkins: Those are likely to be rare cases.
fantasai: We probably want to run a use counter on this before
committing to it.
florian: Either that or chrome tries it and reports back.
astearns: Preferences?
cbiesinger: I'd rather do a use counter
TabAtkins: I'll open a crbug.
astearns: Collect data and report back?
TabAtkins: Yes
astearns: Objections?
astearns: We'll wait on data.
dbaron: Are we going to revisit once we have data?
astearns: Yes
CSS Inline
==========
Better name for initial-letters property
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2950
fantasai: Still open issues around better name for initial-letter
property
fantasai: My favorite so far out of the proposed ones is
initials-span
fremy: Why not drop caps?
florian: Also raised caps
astearns: Caps treatment?
fantasai: Not only caps
<fantasai> Also ideographic chars
astearns: We've spent a lot of time on this before without coming to
an agreement, still an open issue. Preferences should be
expressed on the issue.
Spacing above initial letters
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/719
dauwhe projects
https://lists.w3.org/Archives/Public/www-archive/2018Nov/att-0000/initial-letters-margin-slides.pdf
dauwhe: We've been trying to sort our issues around spacing around
initial letters.
dauwhe: This gets somewhat complicated especially as it can have
ascenders and marks extending outside. Runs the risk of
overlap. Something had to be done. The idea is to define
boxes that helps us explain initial letter.
dauwhe: One is visual box which is the bounding box without padding
and borders.
dauwhe: You see at the bottom here and initial letter and the ascent
mark extends outside.
dauwhe: Initial letters have alignment requirements
jensimmons: Are these diagrams explanations of what we have in the
spec or what you are proposing?
fantasai: What's the relationship between the top of initial letter
and the top of where it's placed.
fantasai: If you have a paragraph and the second paragraph with an
initial letter, has to ensure enough space between the
two. We don't want content to overlap. We don't want to
add too much space or it'll look bad.
fantasai: Initial letter spec has a lot around how letter is aligned
with other content in the paragraph and talks about how
the bottom edge is aligned and excluded. Sometimes there is
a descender, if there is a second line we don't want the
descender to blend into the second line. Open questions
around what happens at the top.
fantasai: Such as a border or the previous paragraph. Trying to
answer the question about how to create space around the
top.
dauwhe: We have the spacing box, no padding and border, same as the
visual box. It there is padding and border we have the
union, taking the larger of the physical box and the border
box, hopefully becomes clearer with some examples.
dauwhe: We have four cases depending on padding border on the
initial letter itself or the containing box.
florian: This is initial letters 3
dbaron: Can we not have margin collapsing?
iank: That bit is pretty magical
florian: Isn't most of the dread around margin collapsing around
margin collapsing through, which we're not doing here?
Should be fine?
iank: This introduces what looks like margin collapsing for
inlines, which we do not do today
jensimmons: Margin collapsing where you use the ability for authors
to remove margins?
dbaron: The container is a block which can have margin collapsing
with many things already
dauwhe: Case 4a, no border or padding on initial letter or
containing block.
iank: This is avoiding something earlier in the tree without a
border?
iank: Say the previous box, nested five times in, has a border. Is
it shifting down to avoid that border?
florian: This is collapsing the ascender with the margin
iank: This is participating in margin collapsing?
fantasai: Yes, we're not going to get sensible results if we don't
do that.
fantasai: We set margins on our paragraphs to get enough space
between our paragraphs. If there is ascent authors don't
want to create more space if it fits within the declared
margin.
fantasai: That is not what you typographically want.
florian: In the example currently on the screen you wouldn't be able
to tell them apart.
fantasai: If you have sections which don't start on their own page,
which happens often, and you're expecting three lines
worth of spacing between sections you want that to always
be three lines worth, regardless of ascents on the initial
cap. But also want to make sure it doesn't overlap with the
previous section if it is taller, so needs to be able to
extend the margin.
dbaron: My worry about this is that it probably more than doubles
the engineering complexity of initial letter. Adding margin
collapsing, my gut feeling, is at least 2x the engineering
cost.
dbaron: It's more stuff, nothing in initial letter was all that
complicated, was a relatively simple feature up until now.
Margin collapsing is very complicated and performance
sensitive.
astearns: Is it possible to have a solution without margin
collapsing solving the non-overlap case.
fantasai: Would require you as an author to know the distance
between cap-height of glyph and glyph bounding box. Would
work but be font specific.
dauwhe: ...and authors would have to do it for each letter
So font *and* character specific.
myles: The ascent is sticking out of the box, why is this different
from any other case where text is outside it's layout box?
fantasai: In this case we potentially have a lot of extra content
outside of the box.
fantasai: We *could* say that we don't care if we overlap the ink
with the previous line, but it's not great.
florian: Latin scrips don't stack up a lot, other writing systems
have cases where there is a lot of stacking and potentially
more ink overlap.
florian: Line-height often reserves space for this, in this case we
align with the top of the bounding box so anything that
reaches out reaches out far
myles: My response to fantasai's point, by default in css, we
overflow and don't clip.
fantasai: By default we try not to have it be unreadable.
TabAtkins: Can and should do it as a generic case where you never
have ascents running into previous content. Would make
initial-letter simpler if it wasn't a part of
initial-letter, but generic for all inline content.
fantasai: If we were to do it for text in general we'd take a
different approach.
florian: You don't want to do it in a small feature
fantasai: You're more likely to run into problems here, it's a
bigger chunk of ink that would overlap than a normal line
of text
fantasai: People don't tend to run into this for normal text and
writing systems with more stacking tends to have a taller
line height for that reason.
TabAtkins: Can we settle on a simpler model that pushes it down to
avoid ink overlap?
fantasai: In that is likely to be less of a problem, I would
recommend to have it potentially overlap, and have authors
address it with ample margin, rather than introduce extra
spacing due to the ascender, which would require
per-font-per-character margin tweaking by the author to
get consistent spacing, which they would require.
TabAtkins: I like it
astearns: Do we want to raise an issue around dealing with this
problem in a generic case?
fantasai: Case of line boxes is a little different. With lines of
actual text, rhythm is important and the text is smaller.
Not convinced that you'd want to have the same solution.
astearns: Is there anything with meaning in this proposal for
initial letter?
fantasai: I think it's really a question of how. If the working
group objects, it puts a strict constraint in what we can
do.
iank: I think people are going to need implementation experience to
see how much work this would be. If David is saying this will
be complex that scares me.
florian: Should we put a note in the spec about that?
florian: Do we specify the behavior as described, overlap with
preceding content, and also put in a note explaining the
thing dauwhe presented and say "this is what we really
want, if you want to implement go ahead"
iank: The only thing that scares me there is that for some
implementation this would be easy, for others hard.
astearns: Clarify in spec what would happen with insufficient margin.
fantasai: We would have to be clear that the proposal being
considered for the future changes behavior, it wouldn't
just add a new feature (switch).
dbaron: I'd be curious if other implementors have same reaction as I
as with regards to margin collapsing complexity. Another
example, what if you have a float that is anchored within
the block with the initial letter but before the initial
letter, how does the collapse of the margin influence the
tentative collapse of the float?
iank: In our current layout implementation there is no way we could
implement this sanely. In our new one, maybe. I agree, very
complex
futhark: If you have an imaginary margin for the initial letter
collapsing as if it was a block, if you change the font,
you'd reflow and layout the text before we know the margin.
dbaron: In the presence of floats you don't know if the initial
letter is at the top of the box as the float might push it
lower. A lot of complexity
iank: Super scary!
astearns: Sounds like we're not willing to make any changes to the
current spec
fantasai: We need to agree on some desired behavior. What behavior
we're going for?
myles: My proposal would be to use the layout box of the glyph for
the layout behavior and not consider the bounding box.
astearns: What I remember you saying, don't move the content down.
fantasai: Would lead to more correct behavior in most cases, much
more tangible than the alternative. If we went with the
other approach, where ascenders take up space, authors
will have to compensate with negative margin per glyph.
And we'll never be able to go back and fix it.
fremy: If you draw a border around it then everything needs to fit
inside of it.
...
fantasai: Inline blocks are laid out differently from inlines.
koji: If the glyph overflows the inline block that doesn't work
fantasai: cap-height is used for sizing and positioning of the
initial letter.
fantasai: But it doesn't dictate the size of the initial letter box,
which includes glyph ascent
fantasai: Initial letter box by default sizes to the glyph bounding
box. Ascent bounding box would have a lot of undesired
extra space around it in typical cases.
koji: David's proposal is very similar to this
fantasai: Does not change how inline boxes background are is
painted. Here, the background area of the inital letter box
coincides with the glyph bounding box
heycam: What is meant to happen when you don't have as many lines of
text as the height of the initial letter?
fantasai: Defined in spec, clearing. The initial letter is part of
the first line, everything below that is an exclusion
area, everything will wrap around it, even if it is the
next block. Like how floats work. However initial letter
in the next block will clear previous initial letters.
heycam: The exclusion area also includes the descenders?
fantasai: There isn't anything special about descenders. Any glyph
area below the first line, all considered exclusion area.
iank: If you have two paragraphs and they're nested. What happens
them?
fantasai: If one of them is a BFC then BFC might get narrower, same
as for floats or exclusions.
fantasai: The proposal on the table, if border or padding is used
then the initial letter must be contained within the
paragraph.
astearns: If the initial letters container has no border or padding
then the glyph content above the alignment point for
initial letter is not considered for layout?
astearns: Objections?
dauwhe: In general, content area includes everything up to ascent,
why did you phrase it as you did?
fantasai: Ascent would be much too high for some fonts.
astearns: Second option, that fantasai was against. If we assume
that the author would add enough space to avoid overlap
that would require negative margin and by font specific.
fantasai: You could have more slack there, with the negative margin
approach it's more strict, different amount of space per
character, per font. The negative margin is specific to
the font and the glyph. That's really, really bad.
astearns: dauwhe are you okay with default to overlap?
dauwhe: I'm totally fine with that, majority of use-cases would not
be affected. Would only apply to a minority of content.
astearns: Any other objections?
RESOLVED: If the initial letters container has no border or padding
then the glyph content above the alignment point for
initial letter is not considered for layout.
<myles> ("alignment point" usually means "cap height")
RESOLVED: Note to be added that the default behavior may change in
the future.
<fantasai> the margin box of the initial letter must be inside the
content box of its container
RESOLVED: The margin box of the initial letter must be inside the
content box of its container when there is borders/padding.
astearns: Any other initial letter topics?
fantasai: Going back to dbaron's initial question. Be clear about
whether it is created space between the top of the first
line and the container. Whether the line box itself is
increased or if a different kind of height is added?
[dbaron points out it is detectable by how vertical-align: top
behaves: if the item is aligned to the top of the first line or
to the top of the raised cap]
<fantasai> I think in Sydney we decided the top of the first line
minus the raised cap, so suggest we resolve on that
RESOLVED: Add an example that shows default overlap
<fantasai> proposed resolution: initial letter does not increase the
height of the line box
astearns: What mechanism pushes everything down then?
fantasai: The initial letter itself is able to take up space. The
initial letter box itself takes up space.
astearns: Does that satisfy your question David?
dbaron: Could you say what you proposed yourself again?
RESOLVED: Initial letter does not increase the height of the line box
fantasai: I think that's it for initial letter. We have other inline
layout stuff, though.
CSS Overflow
============
Intrinsic sizing of elements with continue:discard
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3214
florian: Intrinsic sizing, currently the spec says that, in the
block direction, is from the beginning of the content to
the first forced or unforced break.
florian: That is problematic in that we don't know where the first
unforced break is until layout
florian: Would suggest we change it to the first forced break. From
start of content to first forced break.
dbaron: Two thoughts, one is that I hope the content that is after
the first forced break contributors to the intrinsic size of
something. Not sure what but should contribute to something.
florian: Only talking about the discard case now.
dbaron: For discard that seems reasonable, for some other cases min
and max content would do different things. Min content would
look at first break opportunity, while max-content looks
until first forced break
astearns: In cases where there is a fixed height then discard
florian: We should only consider forced breaks only for the purpose
of intrinsic sizing, for other purposes the spec stays
unchanged.
fantasai: I think this makes sense.
RESOLVED: Intrinsic block size only affected by forced breaks
<fantasai> it would be problematic I think for the 2nd fragmentainer
and beyond, but for the first fragmentainer it's doable
and reasonable
<cbiesinger> why is it important to compute block-axis intrinsic
size before layout? in most cases we can't do that
anyway?
Long block ellipsis strings
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/3213
florian: I have a paragraph with lorem ipsum, the width is very
narrow, we line clamp it and have ellipsis. What should
happen when the ellipsis itself is longer than the line.
One option is to consider the ellipsis unbreakable and have
it stick out.
florian: The alternative, it is wrappable, and wraps up into the
previous line.
myles: How does the implementation know which line to start on?
florian: I feel it is an edge cases that will rarely happen, first
option seems a lot easier.
TabAtkins: The wrapping behavior doesn't solve the problem of it
being too wide
florian: Do we need to solve the problem where it could wrap. I
suggest we don't.
florian: If in the future we want to allow wrapping, then we give
it a pseudo-element which we assume has 'white-space:
nowrap' and the author can override that if they need.
florian: Third way is leave it undefined, don't like it.
TabAtkins: Should be similar to have we do ellipsis now, remove
enough characters until it fits
fantasai: This seems easier, don't have to care about the many ways
of doing wrapping.
fantasai: I think the proposed resolution is to go with the first
option
Proposed resolution: ellipsis is treated as unwrappable and will
extend outside
TabAtkins: It's not great to overflow but at least you can see it.
astearns: Objections?
RESOLVED: Ellipsis string is non breakable.
block-overflow, ::first-line, and ::first letter
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2906
florian: If you have max-lines 1 your ellipsis string will be on the
first line, will it be styled by the first line style? If
it is long enough to extend to start will it be styled by
first-letter?
RESOLVED: There is no interaction between ellipsis and ::first-line
or ::first-letter
TabAtkins: When I've seen this sort of thing show up in printing it
is not styled as drop caps or first line, distinct style
fremy: If you say max-lines 1 you don't need first-line in the first
case?
Allowing (or not) alternate ellipsis behavior for block-overflow
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2905
florian: A part of the spec that says it's undefined. Gives two
options. You layout your text and insert your ellipsis and
remove content up until it fits. Properly insert text and
you redo layout.
florian: Then there is a may. If you are time-pressed there is an
easy way, inserted the same way as text overflow. Does not
affect layout, paint time effect.
florian: Not great that spec allows two different behaviors.
florian: There is a next level of spec that allows other behaviors.
Should we remove the may and make the correct behavior
mandatory?
florian: Mats suggested that we might want to do an intermediate.
You do the right thing when removing content but the
insertion of the ellipsis is allowed to be a paint time
effect.
astearns: If the ellipsis removes the entire last line would that
change the line-height?
florian: Would retain a strut to preserve line height.
heycam: What happens with interactions like bidi reordering?
fantasai: I would imagine that the ellipsis would be bidi isolate
heycam: Also other interactions?
fantasai: If the ellipsis is rendered in a font that is taller than
the line it is rendered onto the line would be taller
which could cause that line to be dropped
florian: That problem doesn't necessarily need solving.
heycam: Removal of glyphs, back up to however many glyphs needs to
be dropped.
florian: How far you're allowed to back up, if you have hyphenation
or in japanese where you can break anywhere. Line wrapping
opportunities.
myles: So not glyph based at all?
florian: Not half glyphs, at least one glyph, often more
astearns: Proposal as I understand, remove content as required to
ensure enough space, leave a strut as needed, and then add
ellipsis at paint time?
heycam: Logically trim of pieces of the DOM that won't be rendered?
florian: You don't drop the line wherever, reuse the same logic as
used for line breaking or fragmentation. Consider the last
line to be shorter to allow for the ellipsis.
astearns: Would this be better for screenreaders?
florian: That is one case.
astearns: Any concerns about removing content and then paining
ellipsis?
astearns: Mats said:
- flow the block as if block-overflow doesn't exist
- if it caused overflow, then shorten the available space
to accommodate the size of an ellipsis and flow the
last line again
- repeat 2 until there is no additional overflow or the
line is empty
- during painting, render an ellipsis in the reserved
space in the last line (same as a text-overflow
ellipsis)
florian: Repeat is potentially needed to reflow. Proper layout for
removal.
astearns: One additional thing: If the line is empty, preserve the
height.
astearns: Any concerns?
heycam: I don't like the searching and dropping bits to adjust the
line height.
florian: Tempted to say yes, haven't thought about it in detail.
florian: Would look a bit odd if you had a Japanese word with ruby
that has been dropped but still have a large gap above the
line
florian: I do think we should make it narrower, don't want large
gaps. Not common but would look really bad.
florian: Not taking to CR anytime soon, edit it in and then revisit
once speced?
RESOLVED: Edit in Mats proposed solution from issue 2905.
Received on Tuesday, 13 November 2018 00:23:06 UTC