- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:29: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.
=========================================
Values and Units
----------------
- astearns requested review of his calc() clamping tests from
implementors:
https://github.com/w3c/csswg-drafts/issues/434#issuecomment-341267463
Contains
--------
- RESOLVED: Use principal box as the box to which we do paint
containment clip. (Issue #1809:
https://github.com/w3c/csswg-drafts/issues/1809 )
- Discussed whether style containment should be affecting pagination
controls within the element. Tab will clarify what style
containment is supposed to accomplish in principle so that this
issue can be resolved accordingly.
- RESOLVED: Create new counter scopes at style scoping root for
style containment.
- The suggested way to address issue #1457
(https://github.com/w3c/csswg-drafts/issues/1457 )
would be that 'contain' would apply to neither inline nor ruby.
Line Grid
---------
- The group reviewed dbaron's proposal to comprehensively address
line spacing:
https://github.com/dbaron/css-line-spacing/blob/master/explainer.md
- The group wanted to make sure that it covered all necessary use
cases, but a preliminary pass suggested it would.
- No one was ready to completely replace existing spec test with
this proposal, but it will be used when attempting to fix the
current spec.
Line Heights (CSS Inline & CSS2.1)
----------------------------------
- RESOLVED: Take florian's proposed change to definitive line
heights:
https://github.com/w3c/csswg-drafts/issues/1801#issuecomment-328707794
- RESOLVED: Take florian's proposed change for line-height normal:
https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-328704733
- RESOLVED: To define first available font more strictly in the
fonts model and leave it undefined in 2.1
(https://github.com/w3c/csswg-drafts/issues/1798 )
- RESOLVED: Change the wording such that 2.1 is saying you should
define the content area based on the first available
font and only that font.
(https://github.com/w3c/csswg-drafts/issues/1804 )
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
Scribe: TabAtkins
Values and Units
================
Negative calc() clamping
------------------------
github: https://github.com/w3c/csswg-drafts/issues/434
astearns: I wrote some tests, and modified them before I checked
them in, and now they're bad tests.
astearns: As far as I can tell, we have no interop at all. EVery
browser clamps at a different time, depending on whether
the animation goes up or down...
astearns: So I want impls to check on it.
Contains
========
Scribe: fantasai
To which box does paint containment clip?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1809
TabAtkins: Whenever element generates more than one box?
TabAtkins: Which box do we clip to?
TabAtkins: Suggestion is principal box, that sounds great to me.
fantasai: The principal box is the box that contains the content,
seems like the right call.
florian: List markers?
TabAtkins: They get clipped if they're outside markers.
fantasai: Just like for 'overflow: hidden'.
dbaron: Table captions?
fantasai: Table wrapper box is principal
RESOLVED: Use principal box.
Clarify style containment
-------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1872
TabAtkins: Question is, why does style containment restrict break
properties?
TabAtkins: Reason why I have these things set is I want to ignore a
style tree for style computation purposes.
TabAtkins: Should be able to completely ignore that subtree.
TabAtkins: Break property if allowed to work would violate that.
TabAtkins: Break properties propagate up.
fantasai: They don't affect computation tho.
TabAtkins: But they affect layout further up the tree.
fantasai: break-inside doesn't propagate up, only forced breaks do.
fantasai: Also sounds pretty bad in terms of fragmentation if you
can't honor 'break-before: avoid'.
TabAtkins: Avoiding breaks should work, yeah...
fantasai: ...
florian: Since contain property is ahead of css-content, should put
the bookmark-* / string-set prose into the css-content spec.
dbaron: I'm trying to understand model of possible optimizations
here.
dbaron: I don't see anything for which this is relevant
dbaron: Still doesn't feel like style containment to me.
fantasai: Also if disallowing break-*, then why not margin-*?
dbaron: It seems like you're trying to introduce something but not
really worked out what.
dbaron: Maybe write out what that optimization is to make that clear
dbaron: and discuss others.
fantasai: Also pretty sure if break-* needs to be disallowed the
margin-* collapsing should also... but that sounds more
like layout containment.
Scoped Counters
---------------
github: https://github.com/w3c/csswg-drafts/issues/1887
TabAtkins: If you have a style scoped element, which says counters
are scoped to the subtree
TabAtkins: does counter-increment create a new counter?
TabAtkins: Or does it increment the existing counter from the
outside?
<fremy> +1 on this one
TabAtkins: I think it should implicitly create a new counter scope
at the style scoping root.
fantasai: And so counters() would reveal a new level of counter?
TabAtkins: Yes.
TabAtkins: Don't want to fuss with the subtree when calculating
counters further down in the document.
fantasai: So you're disagreeing with Oriol's comment?
TabAtkins: Yes.
astearns: Write a test?
astearns: So proposed to implicitly create new counter scopes at
style scoping root for style containment.
RESOLVED: Create new counter scopes at style scoping root for style
containment.
Becoming a formatting context root
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1457
TabAtkins: We addressed this a bit in the past, text we had was bad.
TabAtkins: Layout containment needs a formatting context root
TabAtkins: wanted to say that the element ends up being an FC root
somehow
TabAtkins: only a few places where that's difficult.
TabAtkins: Some are easy:
TabAtkins: flow root, table, flex, grid, all satisfy condition.
TabAtkins: For display: flow, becomes flow-root
TabAtkins: Next issue is with ruby.
TabAtkins: Ruby is effectively inline element.
TabAtkins: Wanted to create a ruby inline block flow-root thing.
florian: We don't have that yet. If it's not useful, do we really
want to add it?
TabAtkins: Better to fill the boxes, so this is consistent and
defined.
fantasai: How about saying layout containment doesn't apply to
inlines, ruby or otherwise? If you want it to apply,
turn it into an inline block.
Xidorn: Create a wrapper box?
TabAtkins: Wrapper boxes are scary and bad.
fantasai: We have block ruby, it just creates a wrapper.
TabAtkins: Make something block-like, either inline-block or block
or something.
fantasai: For most of these layout modes, the FCR-ification doesn't
have much effect. Layout is fundamentally the same
fantasai: but for inlines and ruby, it's a very significant change
to layout
fantasai: I'd rather say that layout containment just doesn't apply
here, so the author is making an explicit decision about
the layout change they're getting, rather than getting
such a significant side-effect from a “performance tweak”.
TabAtkins: My two constraints for this problem is that contain
should work on ruby because it works on inline, and that
whatever effect it has should be possible to get without
using 'contain' for its side-effect.
florian: Suggestion is to apply contain to neither inline nor ruby.
fantasai: That is my suggestion, yes.
astearns: We don't have contain and inline ruby.
astearns: Is there a use case for contain on inlines?
fantasai: You can't get that. It turns into inline-block.
astearns: So if we choose not to apply contain to inlines, what do
we lose?
TabAtkins: Just that authors have to take an extra step of declaring
inline-block.
fantasai: I'm arguing that's a feature, not a bug.
fantasai: If the author wants to have an inline-block, should be
explicit about it. If they didn't, then they're not going
to be happy anyway.
TabAtkins: Internal table elements?
florian: We already resolved they don't apply.
Line Grids
==========
Scribe: eae
Topic: https://lists.w3.org/Archives/Public/www-style/2017Oct/0013.html
<dbaron> https://github.com/dbaron/css-line-spacing/blob/master/explainer.md
dbaron: Based on the discussions we had in Paris. We were talking
about rhythmic sizing and the connections to line box
contain. We've also had the line grid module which was
designed to address many of the same issues and rhythmic
sizing.
dbaron: What I've been trying to do is look at the two and come up
with a minimal viable product for line spacing in css and
address existing concerns about line spacing.
dbaron: I've tried to separate out the important pieces, as
described in doc linked above.
dbaron: Some people have raised concerns that I have addressed in
the doc, others have raised concerns that I did not address.
dbaron: Not interested in talking about naming. More interested in
important use cases and what developers and designers really
need form line spacing.
dbaron: That requires distinguishing what existing tools actually do
versus what developers actually want.
dbaron: Figuring out what we need for line-spacing in css requires
more knowledge about what these requirements are than I
know. I think we have people in this room that know more
about this than I do.
dbaron: People are welcome to read and comment on the doc. There is
also a github page.
dbaron: More importantly, I want to determine what the requirements
are.
florian: I'm not the ultimate expert but have thought about it a
fair bit. All use cases I want to address are equally
addressed by your proposal.
florian: If it is a simplification I'm all for switching to it.
There are tweaks that might make it better but lets leave
that to the side for now.
florian: Fundamental problem shared with line grid.
florian: From my point of view, if it helps implementation I'm in
favor of this proposal over line grid.
dbaron: I don't now what the key differences are. I don't think
implementability was a key factor.
florian: I didn't notice anything I missed during the removal
process.
iank: Is a line grid shared between formating contexts?
dbaron: I think it is shared.
florian: Issue I want to tackle later.
dbaron: I think a lot of the key use cases are driven by things that
are pretty separate.
fantasai: One thing that was dropped which we might be able to
re-add later was to have every other or every third line
snap to the line grid.
fantasai: Not super important right now but is issue that comes up.
fantasai: For instance if you have different font sizes, i.e. line
with smaller text size that takes up 1/3 the space.
dbaron: I think of that as establishing a new grid.
florian: Don't think it is especially critical.
myles: You're totally right, making an inner line grid that has a
size of 1/2 is common and something we should eventually
support.
dbaron: Some ways to approximate it. You could establish a new line
grid.
dbaron: In order to snap baselines you need to be careful in how it
relates to the other grid.
myles: Voicing weak support for your proposal. We haven't seen broad
adoption of existing line grid spec. If this can get better
support I like it
florian: Reverse question. Does switching to this increase the
chance of getting it? What are we gaining?
dbaron: One thing we're gaining is the changing of the line hight
model itself.
florian: I'd argue we should add that as a separate thing as people
might want it without the grid.
dbaron: Agree but syntax will be tricky.
fantasai: From what I understand from previous discussion: there are
a variety of different levels of strictness re aligning to
grid behavior.
fantasai: 1) I want a sane inline model, no grid.
fantasai: 2) Concept of really strict line grid, like physical pages
where you can see things from the other side or facing
pages. Multi-col in general. Where you want text to align
across columns. Being stricter about grid in those cases
is more important.
fantasai: 3) If you gave a large single column of text and an
intrusion then a consistent set of margins is more
important than covering an integral number of grid items.
Readers might not see whether it aligns to a grid in this
case, so consistency in width of margins might be more
noticeable. In those cases having a strict grid isn't
desirable.
fantasai: We might need both approaches.
fremy: Whether we'll be more likely to implement. Questions around
BFC. Flexible columns snap to grid, how would that work?
Needs to be cleared before we proceed.
florian: On agenda for later.
iank: Echo your concerns. As it stands I can't say whether we're
happy with this proposal. Seems okay but we'd want to limit it
with regards to bfc, flexbox etc. When line hight changes etc.
Lots of remaining issues.
koji: I agree with fantasai that it should be available without
grid. I also agree that we need a strict grid model.
koji: I think dbaron's proposal is a little different. We need a
less strict model as well. I think the flow model works better.
astearns: Any other concerns or comments on David's proposal?
nmccully: I also agree that it seems like a good proposal. I have
concerns about baselines defined in other specs and how
they relate. You mentioned dominant baselines being used
to align, other specs talk about other baselines and flow.
I have use cases that need support for setting different
baselines. Being able to specify the baseline to snap to
the grid.
astearns: Those use cases are next on the agenda.
fantasai: I think that David's proposal can handle this. Allows use
of first or last baseline, you also have the option to use
hanging baseline, etc using alignment-baseline property.
You cannot have it align the alphanumeric baseline with
the cap height though, for instance.
koji: Question to David. The item 4 in your proposal looks like a
possible solution to double spacing?
dbaron: I think the changes to the line height calculation reduces
the double spacing problem depending on ... hard to say if
it fully solves it but in many cases when used well it'll
solve it.
dbaron: E.x if you're going to set a large line height it'll solve
it more than a small line height. You're now applying the
height on the line as a whole rather than the little pieces
thus less likely to exceed height. If small line height more
risk.
florian: If you're setting the size of the grid independently from
the size of the font then it increases the risk. The
problem isn't there in your proposal,
koji: That item 4 can then be applied to line-grid or rhythmic
sizing? It's a general approach?
fantasai: Yes.
fantasai: No syntax for it in the proposal but the feature could be
made generic by adding such syntax.
<fantasai> This is listed as the first Open issue
koji: Thanks.
astearns: I think it would be interesting to try to apply that to
the rhythm model and see what comes from it.
* fantasai agrees with koji & astearns on this point
astearns: More comments or should we go on to use cases?
*silence*
astearns: Both the line grid and the rhythm proposals should take
David's explainer into account.
fantasai: I think we should try to fix the inline layout problem,
helps everyone regardless of grid. This is the #1 priority
in relation to fixing inconsistent line heights in a
paragraph.
fantasai: We should continue to work on line-grid and rhythm,
as both solve different use cases that people want.
fantasai: block step size is probably easier, would work on that
first, before line grid.
fantasai: We should go through use cases and get a clear idea.
florian: Question. Do we want to try to resolve on replacing
existing line grid with David's proposal? Or should we
postpone that decision until after.
fantasai: Should put note in spec to point to the alternative.
myles: We shouldn't resolve to replace existing spec without first
going through fixing to existing spec.
fantasai: We need to fix the inline model, need a loose grid and
need a strict grid.
fantasai: We have a step sizing proposal and a line grid proposal.
Would work on step sizing next as it is better understood.
Then to line-grid later.
koji: ok
nmccully: Have a couple of use cases for grid snapping. I looked at
the baseline spec, and there are a couple of overloaded
terms. There is central but it is not obvious whether which
opentype baseline it maps to.
nmccully: Depending on the font and the font design are going to be
quite different.
nmccully: Projecting, for CJK layout the relevant metrics are the em
box. Differ from bounding top/bottom.
nmccully: Mapping between latin and CJK font metrics are overloaded
and the interaction between western and CJK content is not
up to designer. Would like to see more baselines or
explicit ones for Japanese fonts to allow pairing between
CJK and Latin with layout as expected. Would like these
baselines to be available for all fonts.
nmccully: These baselines are critical for aligning. The metrics top
center and bottom are then snapped to a grid.
nmccully: There are different snapping behavior beginning to be
supported in css. The possibilities where you snap lines,
whether body grid with 14pt and letting with 21pt and a
title between two paragraphs where it is larger. You want
to center that on two grid lines. The options of how you
position glyphs within that tall line, whether you
consider the taller one to be the line-hight or the large
one.
nmccully: You're aligning glyphs within a line and the taking the
line and aligning it to the grid. Each visible in
different types of design. All possible variations might
not be possible with the proposal.
nmccully: Snapping the first line of a paragraph, two use cases. 1)
Body text paragraph followed by smaller size one, first
line is snapped to grid smaller ttype one is not.
Following one is re-snapped to grid. Subtleties around
what you do with the smaller line. Whether it is centered
or
nmccully: ...two examples. First one is snapping to the top. Second
one snapping to center.
nmccully: Is not an even leading amount in first case.
nmccully: Both cases have adjacent flow that is top aligned in main
column.
nmccully: This type of snapping, two flows snapping to grid, is one
of the goals of this proposal
florian: Would this be solved using a line grid on the larger block
and disabling it for the smaller one?
fantasai: If you know the relative sizes of the fonts you can make
that work.
fantasai: In the first case you'd have a zero margin or line gap as
needed, the second case you'd have that plus half the
difference.
florian: You align the stepped block on the dominant baseline.
fantasai: If you're able to align baselines that is easy to do. If
you are in a context without relationship and UA can't do
baselines alignment you'd have to compute the margin.
myles: Are everything you've shown here is common and valuable and
are things the css spec need to support?
nmccully: Yes, I don't think any are edge cases.
koji: I agree that em top/bottom are important. Can't comment on
line grid at the moment. em top and em bottom are not well
defined today.
koji: I wish we defined it better and how it relates to dominant
baselines.
koji: When we tried to do underlines for CJK there was no font
metrics we could use for it. We computed em top and em bottom.
Are not defined.
koji: This might be a good opportunity to finally define them
clearly.
nmccully: I agree. One of the things we did in OpenType was to add
metrics like this. ICF box top/bottom and em top/bottom to
allow type designers to specifying them for layout engines.
nmccully: Agree that having the metrics available is essential for
layout engines.
koji: It's great to have the metrics, is ill defined.
myles: If you don't have them, you synthesize?
nmccully: Yes, have synthesized in engines I've worked on.
<koji> The OpenType algorithm to synthesize em box is here
https://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox
<nigel> sorry to throw this in from another room, but if you can
define em top and bottom, how about defining the content
rectangle height? https://github.com/w3c/csswg-drafts/issues/814
* fantasai notes https://drafts.csswg.org/css-inline/#baseline-synthesis
probably needs some review from competent people
myles: It seems that none of the three proposals have anywhere near
enough details to explain the difference between the grids.
nmccully: Would greatly improve matters if line-heights and glyph
placement were more controllable.
nmccully: The existing baselines aren't sufficient, glyphs can shift
today, being more explicit is important even if that
requires adding more baselines.
nmccully: Defining how layout engines should use these baselines to
position glyphs needs better definition. Smaller group
should discuss this.
Meta Bug for Line Height (CSS Inline & CSS2.1)
==============================================
github: https://github.com/w3c/csswg-drafts/issues/1796
florian: This is a meta issues, many issues linked from it. Want to
work on that css 2.1 doesn't define how line height is
calculated. It tries to but contradicts with itself.
florian: I've written a bunch of tests to see what browsers actually
do. Much more interop between browsers than expected.
florian: I'm not talking about which font metrics are used. Separate
discussion.
florian: I'm also not talking about when we have multiple inline
elements within a line. Several fonts with different glyphs
within a line, how are they aligned? That is what I'm
talking about.
Position of the baseline inline-level boxes with non-normal line-height
-----------------------------------------------------------------------
florian: There are two general cases where line height is normal or
has a value, resolves to specific size. Then there is
normal.
florian: In case where it is a size, you get exactly that size. Not
clear from spec. Some spec text suggest it should be union
of that per font, no browser does that.
florian: The baselines from the first font is used and everything
else is aligned from there. Not what the spec says but it
is what all UAs do. That is good.
astearns: Is it worth resolving to change spec to match that?
florian: Yes.
florian: Have proposed wording. If enough people have looked at my
tests to verify them I'd be happy to resolve.
florian: We have to be very specific when patching css 2.1
florian: Happy to craft detailed diff if we agree on the high level
issue.
eae: Matches our behavior.
myles: We should just make the change and revisit if it causes
problems.
florian: The specific proposal is listed in issue 1801 at the bottom.
[
When the value of the line-height property is something other
than normal, determine the leading L to add, where L =
'line-height' - AD of the first available font. Half the leading
is added above A of first available font and the other half
below D of first available font, giving the glyph and its
leading a total height above the baseline of A' = A + L/2 and a
total depth of D' = D + L/2. Glyphs from fonts other that the
first available font do not impact the height of the inline box.
]
<florian> https://drafts.csswg.org/css2/visudet.html#leading
dbaron: I was still looking at the previous issue.
florian: One is about size, the other about alignment.
dbaron: I think that seems reasonable. You might even want to say
height or baseline of the inline box.
dbaron: There might be some cases where that is not what we do but
think that is for normal line height. Seems reasonable to me.
astearns: Next step would be?
florian: Resolve if we agree.
astearns: And then we can review that pull request?
RESOLVED: Take florian's proposed change to definitive line heights.
Height of an inline-level box with line-height:normal using primary
and fallback fonts
-------------------------------------------------------------------
github issue: https://github.com/w3c/csswg-drafts/issues/1802
florian: CSS 2.1, in some cases, claims that line height normal
behaves the same way as defined with a specific value.
Probably between 1 and 1.5. Not what browsers do. What UAs
do is take all fonts that are used, plus the first font,
even if not used. That is what everybody does. Not what CSS
2.1 claims.
dbaron: I have a vague memory of gecko doing something odd in some
cases. If there is a simpler impl I'd be happy to change.
florian: Only case I could find that skipped first font if unicode
range is used for the first font. Chrome and Gecko have
different behaviors. Other then that and the case where the
first font' doesn't have the space glyph there is full
interop.
astearns: Has anyone reviewed these tests?
florian: fremy said he did.
astearns: Is Edge fine with taking this change? And Chrome?
eae: Yes.
myles: Let's do it!
dbaron: Go ahead, trying to figure it out will take awhile.
astearns: Any objections?
dbaron: I'm pretty sure the gecko behavior is too weird. Might be
worth having test coverage.
florian: There is 2.5 browsers doing one thing, 1.5 the other.
RESOLVED: Take florians proposed change for line-height normal.
dbaron: Want to go back to line height normal. In some cases we use
different font metrics.
dbaron: The text in the proposal was very specific about the metric.
florian: Will update it to be more clear about the specifics and
that the font metrics in question isn't defined.
dbaron: What metrics are used should be looked at separately. Will
add comment.
<dbaron> FYI, I did figure out the crazy Gecko behavior I was trying
to remember:
https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-342349505
Behavior differences when the primary font does not contain U+0020
------------------------------------------------------------------
github issue: https://github.com/w3c/csswg-drafts/issues/1798
florian: We discussed whether the first font in the fallback list
should count as the first available font even if it doesn't
have a space glyph. We did not specify whether it should
also apply to line height.
florian: Safari, Edge, and FF half the time considers it even if it
doesn't have a space glyph.
florian: Safari and Chrome do not.
fantasai: The “first available font” should have a strict consistent
definition across specs.
florian: Is not consistent across implementations.
florian: Happy to change if implementations are willing to change.
florian: I don't really care strongly, arguments on both sides.
florian: Are edge and safari ok with that?
fremy: I didn't run all of the tests but I think we do the same
thing?
florian: So there are three compat implementations?
florian: The first available font wording is used in 2.1 just not
defined.
astearns: Might be acceptable to not test the presence of space in
2.1
florian: Define it in fonts3 and then have that definition apply to
all cases where we mention first available font
Proposed Resolution: To define first available font more strictly in
the fonts module and leave it undefined in 2.1
RESOLVED: To define first available font more strictly in the fonts
module and leave it undefined in 2.1
Height of the content area of inline level boxes
------------------------------------------------
github issue: https://github.com/w3c/csswg-drafts/issues/1804
florian: All browsers agree that the size of the content area
depends on the size of the primary font, even if no
characters from the primary font are used.
florian: The specification doesn't define the behavior, say "may do
A or B".
florian: Should remove "may do A" as no browser does that.
florian: Suggest we remove suggestion saying that one may do
something that nobody does.
dbaron: Would argue it should be a SHOULD rather than MUST instead
of a MAY.
myles: Content area also depends on the line-gap property
florian: Just depends on font metrics.
florian: Spec says "do whatever you want, here are two suggestions".
Doesn't mandate a specific metric.
myles: Shouldn't say ascent or decent, have specific meaning.
dbaron: I don't think this ones includes line gap, only asc+dsc.
florian: There is a paragraph saying that if more fonts are used the
height of the area isn't defined but we suggest... I
propose we remove that.
Rossen: What about overflow?
florian: People don't do that for background I think.
Rossen: I'll follow up with a test case.
astearns: Let's continue making tests given the number of questions
raised.
fantasai: This is about where the background is painted for inline
elements, very specifically about backgrounds.
Rossen: I might be miss-reading the issue.
fantasai: The question is how tall is the background painted behind
the text. Can't set overflow on inlines. Has to be set on
containing block.
florian: I'm not an editor for any of these specs, there will be
pull requests not in spec.
florian: Would like to move forward.
Proposed resolution: Change the wording such that 2.1 is saying you
should define the content area based on the first available
font and only that font.
RESOLVED: Change the wording such that 2.1 is saying you should
define the content area based on the first available font
and only that font.
[end of day]
Received on Tuesday, 5 December 2017 00:30:11 UTC