- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Tue, 13 Nov 2018 20:00:03 +0100
- To: daelcss@gmail.com
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CAERejNY3wkXZp4qcXg2k42OKb9ARfhk4o_fRfm3SmkGVZJcmfA@mail.gmail.com>
It's great to see that the CSSWG not only resolves on CSS changes but also
brings people together!
Congratulations Lea and Chris! I wish you the very best for your future!
Sebastian
On Tue, 13 Nov 2018 at 01:25, Dael Jackson <daelcss@gmail.com> wrote:
> =========================================
> 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 19:00:46 UTC