- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 21:03:15 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Contain
-----------
- RESOLVED: Style containment works on internal table boxes,
size containment does not work on internal table boxes,
other containments only work on table cells.
- RESOLVED: CSS Contain to CR
Scroll Anchoring
----------------
- RESOLVED: Request to graduate from WICG to CSSWG
Testing user agent stylesheets
------------------------------
- There was general agreement that there should be test for UA
stylesheets.
CSS Inline: Line Height Calculations
------------------------------------
- RESOLVED: Add leading to union of ascent and descent.
- RESOLVED: Replace definition of 'line-height: normal' with
vaguer definition, errata CSS2.
- Investigation on what browsers do and what we all should do
will continue.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: surma
CSS Contain
-----------
Florian: Last issue was what to do if contain is on an internal
table element
<Florian> http://www.w3.org/mid/55BA836C.6060404@mozilla.com
Florian: We have different containment modes, each needs an answer
for which tables parts. Style containment: should apply.
paint containment: should apply. Size containment: should
never apply
dbaron: Including cells?
Florian: Including cells! We could make it work, but it would be
undefined behavior. We could define it, but probably not
worth it.
Florian: If we say size the call as if empty, and then do in-flow
content is not an operation that currently exist.
Florian: The use case for containment on cells is for
spreadsheet-style sites. You could do the cells
independently and place them on the grid.
iank: Does paint containment make sense on table rows?
Florian: Why not.
Florian: I’d also be okay with allowing it on cells, but not rows.
[general agreement]
<fremy> @Florian @iank Right now I doubt because the background
color of the table row is clipped by the cells which can
come from other rows due to spanning
dbaron: We need to define how paint containment works with
collapsing borders.
Florian: As a general rule we should disallow containment if the
implementation is not obvious.
iank: So paint containment on the table or the cells, but not on
rows.
Florian: Yes.
Florian: The same for layout containment.
iank: Same for size containment?
Florian: Yes. Only style containment on all elements.
<Florian> proposed resolution: style containment works on table
parts, size containment does not work on table parts,
the two other kind of containments only work on table
cells
<astearns> fremy: OK with this?
<fremy> yes
fantasai: Fixed tables dont have any of this weirdness, right?
dbaron: Content can be bigger. I think it gets clipped, but it can
be bigger.
Florian: Are we interested in this nuance?
dbaron: I am not.
RESOLVED: Style containment works on table parts, size containment
does not work on table parts, the two other kind.
RESOLVED: CSS Contain to CR
TAG review of scroll anchoring
------------------------------
Github issue: https://github.com/w3c/csswg-drafts/issues/676
<rbyers> Video: https://blog.google/products/chrome/taking-aim-annoying-page-jumps-chrome/
rbyers: Gave a presentation on it at TPAC.
rbyers: Wanted it to be opt-out, not opt-in.
rbyers: This is a feature to avoid jumping while the page is
loading. We talked about it at TPAC. We didn’t want it to
be opt-in, so we needed to make sure the heuristics are
good. We have written all the details in the spec. Shipped
in Chrome 55. We see it used on 10% of pages views on
Android. The pages that use it hit the heuristics 5 times
per page load.
rbyers: We wanted to check if theres other interest. We can still
make changes.
[general signals of interest]
rbyers: People didn’t notice they had this problem. Now that
Chrome corrects it, it might get worse in other browsers.
rbyers: Should we warn on console about hitting the heuristics?
rbyers: We are careful about spamming warnings
dbaron: I‘d want this to work when I resize a window, too. That
shouldn't issue a warning.
[rbyers checks if it is tied to resizing too]
Rossen: Let say you have implemented snap points. How much can be
built on top of this.
TabAtkins: Nothing.
rbyers: This lets you customize what is considered an anchor. Snap
points set the anchors.
Florian: Is this writing-mode aware?
rbyers: It should be
Florian: The interesting part is that the implementation is
complex, but the api is small, so changes can be made in
the future to the heuristic.
fantasai: We should publish a FPWD through CSSWG
TabAtkins: Since Google is a member of the group, any Googler can
continue work on the draft, even if the person
themselves is not a member of the group. Correct,
ChrisL?
ChrisL: I think so, yes.
ChrisL: If they are not a member, tho, what if they start doing
whatever they want.
astearns: We take them off as an editor.
fantasai: Its better for the editor to be a member of the group
for access to all the tools etc.
fantasai: No requirement of him showing up to meetings etc.
rbyers: We’ll ask him to join.
Rossen: This is in WICG, no? What is the migration process?
Florian: We just did it
Rossen: Not sure that is the case.
astearns: We don't have a clear handoff process.
Florian: We take the spec, put it in our repo.
rbyers: We’ll ask cwilso how to migrate.
Rossen: We’d like to know as well for future WICG migrations.
There used to be a high bar, I don’t want to just ignore/
circumvent that.
TabAtkins: Worst case I’ll be co-editor
astearns: It could be nice to have the editor on calls to have
their expertise.
RESOLVED: Request to graduate from WICG to CSSWG
Testing user agent stylesheets
------------------------------
GitHub topic: https://github.com/w3c/web-platform-tests/issues/5625
astearns: Should we have tests for UA stylesheets?
dbaron: It’s a good idea. But some results might be an issue
against the HTML spec rather than the UA.
fantasai: Maybe the UA stylesheet statements should migrate to HTML
xidorn: test cascade level?
dbaron: There are a lot of known issues where what's in the UA
level vs. the pre-hint level doesn't match the spec, since
the reverse engineering didn't really consider that, I
don't think.
astearns: So general agreement?
[yes]
CSS Inline: Line Height Calculations
------------------------------------
scribe: fantasai
github topic: https://github.com/w3c/csswg-drafts/issues/1254
[This is a grossly-exaggerated diagram of the discussion below:
https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0008/IMG_20170421_173959.jpg
The boxes represent glyphs from two different fonts
whose baseline metrics don't quite match up,
so their ascent/descent from the shared baseline differs.]
Florian: We were trying to do things that depend on normal and it
didn’t match reality.
dbaron: Spec says that when you have glyphs from multiple fonts,
where the fonts have different ascent and descent, the
glyphs end up with different boxes.
<jet> see Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1358377
[dbaron draws Chinese character and capital B, to represent glyphs
from two fonts]
dbaron: spec says that when you draw the background you use the
lowest bottom and the highest top
[dbaron draws misaligned boxes, representing the two different
fonts that are triggered by fallback]
[dbaron labels height of tallest top to bottommost bottom as
"content box"]
dbaron: You add half of the leading to each side (top/bottom) of the
box.
[dbaron draws leading on each glyph; shorter glyph gets more
half-leading on each side than taller glyph]
[dbaron labels distance from topmost edge of leading to bottommost
leading edge as "line box contribution"]
dbaron: Spec for normal says to use a value between 1.0 and 1.2 as
normal line-spacing.
dbaron: This is not the Gecko behavior.
dbaron: This is what the spec says.
Florian: Spec contradicts itself.
dbaron: Spec describes this behavior, and then says "therefore you
get X" where X is not what you get out of this behavior.
[confusion about earlier resolution from yesterday]
Florian: The other option was to reduce this line box contribution
to just the value of the leading
Florian: which was, iirc, what Safari does,
(which is what Florian and fantasai thought we had resolved on
yesterday)
myles: We never add padding to individual boxes. We do ceiling and
flooring and then add leading at the end.
dbaron: I'm fine with resolving on this, does make this other
issue simpler.
myles: I thought we resolved already.
Florian: dbaron and Alan thought we resolved the other way.
<astearns> the previous resolution was RESOLVED: fix the erroneous
conclusion in section 10.8
dbaron: 3d paragraph on 10.8.1 says to add half leading to each
glyph. We're saying to add it to the content box.
fantasai: Content box is not well-defined.
dbaron: It's in 10.6.1.
fantasai points at the spec
dbaron: I guess it's not actually defined.
dbaron: So define that you add leading to union of ascent and
descent.
fantasai: What's an em box?
RESOLVED: Add leading to union of ascent and descent.
dbaron: The thing we resolved gets you 15px lines, but only if you
don't have a <span> in your line.
dbaron: What we're talking about is per inline box fragment.
dbaron: Goal was to make lines 15px high.
dbaron: This resolution will accomplish that given font fallback,
as long as you have no markup whatsoever and every line is
just a single box fragment.
dbaron: The moment you have both markup and different font
fallback in the different elements, it fails.
dbaron: If you have for example:
Get a taxi with <span>京B</span>
dbaron: Now you're computing the line-spacing for first piece
separate from second piece.
* fantasai is so happy to have this lecture by dbaron <3
koji: In Blink, we use primary font to resolve content box.
dbaron: We decided not to do that because wanted to consider all
the glyphs.
myles: If you have an element ... your entire line is that element.
myles: What's primary font vs secondary font?
koji: If this is the example and no stying on <span>
koji: Then these two have same font family, then primary font is
the same.
koji: Even if this span starts from different font family, use the
same font.
dbaron: So you're saying you use the first available font.
koji: If line height is not normal, yes.
myles: Are you saying that you ignore the metrics of the
non-primary font?
koji: yeah.
myles: That's not what WebKit does.
myles: At least I don't think so.
koji: When we say we compute only once per inline box fragment,
compute is based on which fonts?
Florian: Union of all the boxes
[more confusion]
[dbaron redraws]
dbaron: Let's say these are 16px glyphs and you want 20px line
height
dbaron: With union thing, we take the tallest top of glyph, and
lowest bottom of glyph:
dbaron: Distance here is 19px
dbaron: To get to 20px, we add .5px to top and to bottom.
dbaron: In some ways this isn't great, because it gives you
baseline jitter when you have font fallback
dbaron: If you use only the primary font and not the others, you
will not get baseline jitter.
Florian: But you may get overlap.
Florian: I think baseline jitter is preferable to overlap.
dbaron: Generally the variation is not a lot, so unlikely to get
overflow in most cases.
dbaron: Unless you push your line height really close to 1.0.
astearns: ?
myles: If you a really big paragraph, many lines of text, and one
line in the middle has a character from a fallback font.
dbaron: That will push the baseline of that line down, because
centering union within the line height (19px) rather than
just the primary font (16px).
myles: Webkit does that; we just have a little bit of jitter.
dbaron: One other factor here...
dbaron: If we did only primary font, line-height-step would give
you evenly-spaced baselines
dbaron: But if we don't, then even line-height-step won't give you
evenly spaced baselines.
myles: So the problem then is that if you use line-height-step,
this middle line with the character, might trigger a
double-spaced line.
astearns: Sounds like maybe previous resolution, we don't want
anymore.
dbaron: Also could consider whether content-box should use primary
font.
dbaron: Let me finish.
dbaron: Explanation:
dbaron: There's a value called normal
dbaron: In theory this is a number
dbaron: But actually this is not what Gecko does.
dbaron: Font has a metric that says what they think the line
spacing should be.
myles: Field is called line gap.
dbaron: You could get the metric from the font and apply it to the
glyph in that font, and then do the same with the other
font to the other glyph.
dbaron: And that would be easy with the previous behavior with
per-glyph leading instead of union leading.
Florian: Could do per-glyph leading and union it.
dbaron: What gecko does is more horrible.
dbaron: Gecko for line-height: normal
dbaron: Does per-glyph bounding box computation without external
leading
dbaron: Then unions that with external leading of the primary font
added to the glyph height of the primary font.
dbaron: I don't think this was intentional.
dbaron: So Gecko will take union of glyph boxes, and then unions
that with leading box of the primary font.
fantasai: Maybe not so bad, gets you more regular spacing line to
line, while still trying to avoid overlap by considering
union of all glyph areas.
Florian: I thought Koji had brought up earlier that for some
languages there are very tall glyphs, and you may have
that kind in the fallback.
Florian: So might have something very tall and has external
leading to get that to look nice.
Florian: In these cases glyph can go beyond ascent and descent.
Florian: Are these font metrics reliable?
myles: Let's not discuss that.
astearns: So...........
Florian: So spec says "line height number is like a number, you
just get to pick the number". This is not true.
koji: Says use value that's appropriate to the font.
koji: ...
koji: Second sentence is very questionable.
dbaron: The sentences might have been written 10 years apart, as
we edited CSS2.
koji: “font of the element” is not defined.
koji: Earlier paragraph says UA may take all the fonts used in the
element.
koji: This sentence doesn't make sense to me (second sentence)
koji: so I ignored it.
koji: You read second sentence.
myles: Should be fonts, not font, of the element.
Florian: That's an improvement, but still undefined.
<tantek> Indeed this has felt underspecified to me too
Florian: Based on it, but based how?
astearns: Vague is better than wrong.
astearns: Let's resolve to remove wrong parts.
[Florian quotes spec]
discussion of prose
[Spec is all wrong]
[Need to replace the entire definition]
[alan asks where new prose goes]
fantasai: Errata CSS2, define in css-inline-3
myles: The reason we're discussing all of these computations is
because if they were to differ you might get double spacing
with line-height-step.
myles: Because font metrics differ between browsers *and*
platforms, will still get differences.
Florian: Because we don't have a foundational model from which to
discuss issues.
koji: Changing definition for non-normal case is easier... doesn't
change layout.
koji: Just changes glyph position within the line
koji: but if we change definition of normal, might break lots of
sites.
astearns: Well, we need to change the definition in the spec in
any case, because it's not matching what browsers do
astearns: So proposed resolution is to remove wrong definition of
normal, and replace with more accurate definition
fantasai: Will need to be vague.
astearns: Any objection to a vague but not wrong definition of
'line-height: normal'?
RESOLVED: Replace definition of 'line-height: normal' with vaguer
definition.
dbaron: Basically need to say that 'normal' does something based
on the font that overrides algorithm for number.
myles: Say all the fonts may be consulted, and line gap of all the
fonts may be consulted.
ACTION fantasai: make wording
<trackbot> Created ACTION-849
Florian: Previous resolution, koji said it's not what they do.
dbaron: Matches Safari, not blink or gecko.
dbaron: Makes rhythm better wrt what spec previously said, but
worse wrt blink/gecko
dbaron: Also only helps if you have no elements.
[discussion of what's better than what]
dbaron: It could lead to glyph box overlap where there wasn't
before.
dbaron: You could end up now with negative half-leading
dbaron: Because before leading would definitely be positive.
astearns: My understanding was that we were going to size on the
content box.
dbaron: content-box is should, not definite.
astearns: need to discuss content box...
astearns: Does that affect the previous resolution?
dbaron: Other factor with content box
dbaron: tend not to have padding and border, but backgrounds is
common.
dbaron: Whether to include fallback glyphs in content box...
dbaron: Do you want fallback glyphs to potentially overflow
content box?
dbaron: Or do we want to make sure content boxes are consistent
across multiple elements?
koji: I would really want to make heights of lines consistent.
Don't care so much about positioning within the line.
Florian: If we don't do the resolution we've just taken, the line
height may be bigger than the one you asked for. With
this resolution, if you say line-height: 20x, you always
get 20px
[koji doesn't believe this, so Florian is trying to explain it
again]
...
<tantek> There is an inevitable design tension between "do exactly
what I said" and maintaining a strict rhythm, and
avoiding overlapping pixels / text. Not sure how that
tension can be resolved in a predictable way. Especially
with cross-platform/browser font differences, font
substitutions etc.
<tantek> I don't have a specific suggestion, but I'm curious what
methodology the group uses to try to resolve this tension.
<fantasai> tantek, in general we tend to go with "make it
readable" over "make it pretty"
<tantek> fantasai, I agree with that. I'm more wondering about the
"[ CSS is Awe ] some" type problems
[There are several diagrams on the board now
https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0008/IMG_20170421_173959.jpg
Blue one represents "use the primary font for size and position"
Black one is "apply leading to each glyph and take union of all"
Red one is "union glyph boxes and apply leading (could be
negative)"
In blue and Red cases, could get overflow...
in blue case the overflow is all wrt primary font. Red case clips
a bit from tallest and lowest bits of the combination]
dbaron: Red and blue will both give consistent line sizes, but
blue will give consistency even when you have <span>s
[Florian summarizes and asks Rossen, who suspects they don't
ignore fallback so probably black or red]
[dbaron notes this is for non-normal values]
astearns: We should have description in CSS2.1 with what browsers
do, so we're actually describing reality.
ACTION Rossen Verify what is done by each browser (by checking
Edge and putting on WG to-do list for everyone else)
<trackbot> Created ACTION-850
astearns: Anything else?
Meeting closed.
Received on Saturday, 27 May 2017 01:03:49 UTC