- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 1 Sep 2017 08:50:16 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Multicol
--------
- RESOLVED: rachelandrew to edit multicol
Writing modes
-------------
- RESOLVED: A new CR of writing modes after edits and tests.
Advanced Publishing Lab
-----------------------
- Florian will keep the working group aware of the Advanced
Publishing Lab's work https://www.kri.sfc.keio.ac.jp/en/lab/aplab.html
Inline layout
-------------
- Florian will file bugs on the spec and on browsers as a result
of his testing. Results here:
https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847
CSS Rhythm
----------
- The group discussed issues around unintentional double spacing.
- There wasn't clarity as to how bad the unintentional double
spacing is as there's no usage data.
- Florian recommended starting work on the block part of
line-height-step that everyone agrees to be useful and
robust.
- dbaron brought up some work done a while ago that may solve
use cases by no longer using line height after the grid is
laid out
https://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain
- The double spacing conversation also went into a larger
conceptual question about the viability of the spec.
- There were several concerns voices that, as the spec is now,
it's not robust enough to be truly useful.
- Some of the issues around ensuring this spec is robust and
easy to use will not be resolvable until the Inline Layout
line height issues (see previous topic) are addressed.
- There was a request to have more East Asian examples as
currently examples are all Latin which means one of the
primary use cases isn't well represented.
- Next the group reviewed a proposal from Tab & Shane
https://github.com/w3c/csswg-drafts/issues/938 to address some
of the issues around spacing and line-height. The group was
fine with Chrome experimenting with this approach, though too
many doubts were expressed to put it into the spec before more
experimentation is performed.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: Jet
Multicol
========
astearns: rachelandrew will be editor
RESOLVED: rachelandrew to edit multicol
Writing Modes
=============
astearns: Normative change to CR draft.
<Florian> https://github.com/w3c/csswg-drafts/issues/1391
astearns: Need a new CR and tests.
RESOLVED: A new CR of writing modes after edits and tests.
Advanced Publishing Lab
=======================
<astearns> https://www.kri.sfc.keio.ac.jp/en/lab/aplab.html
Florian: Advanced Publishing Lab started in Keio university
Florian: Japanese industry driving potentially a new CJKlreq.
Florian: Group wants to inform CSSWG of their requirements.
astearns: C & K in scope?
Florian: Not sure, but likely.
astearns: Please update the group as needed.
Inline Layout
=============
github: https://github.com/w3c/csswg-drafts/issues/938
Florian: From weaknesses of vertical rhythm
Florian: found lineheight issues from that investigation
<Florian> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847
Florian: I did a bunch of testing ^
Florian: Shows how browsers differ.
Florian: more interop than expected
Florian: Safari & Edge are the same
Florian: Chrome differs
Florian: Firefox differs.
Florian: When lineheight is a number or length vs. normal
Florian: refers to diagram from Tokyo discussions
Florian: (see github issue for diagram).
Florian: Can't figure out Chromium baseline alignment-
Florian: why does chrome behave this way?
Florian: We should fork the issue for general lineheight.
Florian: We need to define base behavior of lineheight.
fantasai: Because the trigger to round up for rhythm depends on
the computation of line height.
myles: And you can double spacing in some UAs not others if those
computations differ.
fantasai: Right.
Florian: My goal is general interop on lineheight.
astearns: Discuss divergence on lineheight:normal.
Florian: Can isolate individual bugs.
ACTION: Florian to file bugs with each case
fantasai: We don't have a spec for these issues.
astearns: But we have interop except for chrome
astearns: so Chrome should figure out whether there's a reason to
diverge, or whether they will fix it
astearns: and then we can spec the result of that discussion.
Florian: For lineheight:normal Chrome differs by using the top of
the tallest used fonts
Florian: will file a bug on that one.
koji: We need to see the test.
Florian: We'll debug later.
Florian: I had to find fonts with tall ascenders and long
descenders.
Florian: Firefox font metrics differ
Florian: not sure why.
<dauwhe> Zapfino is a great font to test with, due to its extreme
nature
<gsnedders> dauwhe unfortunately, licensing doesn't allow us to
use it in wpt ;P
myles: If a browser changes the metrics they read from a font,
every web page will look different. At least for us, that
would be almost certainly unlikely to happen.
Florian: In some cases Firefox is the same.
dbaron: Platform API's differ for metrics.
koji: Everyone has 3 font metrics.
Florian: Chrome & Safari same on Mac.
Florian: Chrome & Edge same on Windows
myles: Some fonts are just weird.
myles: For at least fonts on at least one platform, at least one
of the metrics of the font returned by the system API
doesn't appear anywhere in the font.
Florian: The tests aren't clear re: metrics, but does show the
divergence.
Florian: I checked the content box for inlines--also no interop.
Florian: On Chrome, doesn't depend on font metrics or lineheight.
fantasai: Spec says content box can't depend on lineheight
Florian: Firefox depends on font metrics and not lineheight.
* fantasai notes for the minutes that Florian is summarizing the
comment he linked to earlier, so details are all there
* fantasai notes for the CSSWG that fixing interop on this issue
was one of the reqs from TTML
Florian: [notes Chrome bugs]
fantasai: Is it 1 em?
fantasai: 1 em is at least predictable.
Florian: Not 1 em.
Florian: More testing needed.
<dbaron> FWIW, Gecko has 4 platform-specific font backends: (1)
FreeType (used on Linux and Android), (2) Mac (3) GDI (
Windows) and (4) DirectWrite (also Windows)
<myles> dbaron: macOS has CoreText and CoreGraphics and they may
disagree
<dbaron> myles, I think we're using CoreText
<myles> dbaron: 💯
<dbaron> myles, er, wait, there's a pointer to both objects :-P
<myles> dbaron: 💯💯✅
<dbaron> myles, InitMetrics seems to use mostly CG* APIs
<dbaron> myles, I think we use Core Text only for fonts with color
bitmap glyphs
Bert: CSS2 recommends 1em or height of the ascender to descender
<Bert> "The height of the content area should be based on the
font, but this specification does not specify how. A UA
may, e.g., use the em-box or the maximum ascender and
descender of the font. "
<Bert> (This is from CSS2)
<Bert> https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced
astearns: It differs depending on the platform font subsystem.
Florian: Firefox differs with Outlines
Florian: outline allows a lot of leeway
Florian: and Firefox diverges most.
Florian: Please review the tests.
astearns: File the bugs and have the browser engineers challenge.
fantasai: We want interop and sane behavior so file spec bugs not
just browser bugs.
fantasai: Resolve on content box height?
Florian: We have 3 behaviors, Chrome I can't figure out at all.
Doesn't seem to depend on line height or font metrics.
Florian: Firefox ....
astearns: If we file a Chrome bug, we can get interop
astearns: despite no spec.
fantasai: We should specify what the TTML folks can use.
<dbaron> I think there are probably much larger audiences than the
TTML folks who care about this.
<fantasai> dbaron, not sure who that is, but pretty sure they'd
agree on having something controllable and predictable
Florian: Using ascender/descender lengths is unpredictable.
dbaron: may be concerns re: e.g., accent marks not hanging out of
the background
dbaron: and that might be more important for Vietnamese than for
English.
Florian: Content box depending on font metrics is very
unpredictable.
Florian: We can resolve on Safari/Edge behavior re:
lineheight:normal being a bug
Florian: lineheight != normal returns different sizes
astearns: Currently not a spec violation
<astearns> but we should probably make it one
<dbaron> I think it is a violation of
https://drafts.csswg.org/css2/visudet.html#inline-non-replaced
<astearns> dbaron: fair - "The 'height' property does not apply
<to the content area>" does seem to be relevant
<dbaron> I guess it's violating the "should" that it's based on
the font
fremy: We can't resolve if we don't know what to spec.
fremy: Please file more specific issues.
Florian: We'll split the topic.
fantasai: File issues against CSS inline and CSS2.
Florian: I tested 2 ways: line stacking and with border. Same
results.
fremy: Spec proposes 2 solutions
fremy: not sure how we choose either.
fremy: I need to check Edge code
fremy: but maybe we consider line-height to be intent from authors
they want control.
Florian: interop is fixable.
CSS Rhythm
==========
scribe: fantasai
Accidental Double Spacing
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/938
<astearns> https://groups.google.com/forum/#!msg/mozilla.dev.platform/cnEN_sccXJY/1ddo5XifAwAJ
koji: I'd like dbaron to explain his opinion.
dbaron: Current approaches are going to lead to things that are
fragile wrt behavior between browsers, or even same
browser on different platforms
dbaron: where you get double-spacing of lines in unpredictable
situations.
dbaron: There are alternative approaches which would not lead to
this problem
dbaron: But I'm not interested in focusing on this right now.
dauwhe: Are you concerned about just the inline step sizing, or
all of css rhythm?
dbaron: Right now not looking at anything.
dbaron: I'm discouraging ppl from implementing this feature
because I don't think it's something that should be
implemented.
koji: Same issue as double-spacing.
dbaron: Some of the ways to solve it might be to use an entirely
different design, whereas github issue is trying to keep
the same design and trying to find small fixes for
double-spacing.
koji: Your concern is different font metrics causing different
result is the problem?
koji: Original issue was line-height normal causing problems.
Florian: There's a general problem and a specific case of that
problem.
Florian: General problem is when different font metrics or
different ways to implement line height or things of that
nature cause the layout to work just fine in one browser
Florian: and to be entirely double-spaced or randomly
double-spaced in another browser.
Florian: That's the general worry.
<dbaron> or different font availability
Florian: Within that space, this github issue identifies one case
where this happens.
Florian: If this is the only case where this happens, maybe
dbaron's worry goes away.
Florian: If there are more instances of similar worries, we'll
need lots of patches.
dbaron: Another major case is font availability, where you have a
font available on one platform and not on others.
koji: I heard one example
koji: but dbaron's concern seems to be a different case.
Florian: It's the same.
Florian: If line-height-step is a user-defined specific value
Florian: and line-height is a different user-defined value
Florian: then this is generally predictable.
Florian: If line-height is smaller than line-height-step generally
okay.
Florian: If there's one line that has a superscript and double
spaced that line it's kindof okay
Florian: but double-spacing entire the page is a problem.
Florian: If you set [various combinations, various results]
Florian: Different fonts, different ways to read metrics from the
font, different implementations of what 'line-height:
normal'
Florian: cause differences.
dbaron: I'm not sure that even line-height: <number> is
predictable, requires testing mix of elements
<dbaron> ... where some have font fallback.
fantasai: Another case that could cause problems is different line
wrapping,e.g., if superscript and subscript end up on
the same line, it could get taller.
Florian: Point of feature is normalization of line heights so a
few lines double-spaced probably okay, but all lines not
good.
Florian: Primary font doesn't have CJK and other font does, then
many lines with mix of fonts.
Florian: line-height to specific number, it's okay
Florian: but if you have spans in the middle of that, you might
trigger problem often.
fantasai: It's broken if the author sets something precisely
expecting no gaps in the general case; they'll be upset
if they see gaps.
fantasai: You won't have a case that's extremely painful for the
user.
astearns: Author shouldn't use this if they can't stand occasional
double spacing.
jet: On dev.platform, was a question of whether authors really
want this feature.
jet: Haven't heard demand from authors outside Koji here in this
room.
jet: Do people want that?
Florian: People do want vertical rhythm, absolutely.
jet: Chromium has it behind a flag, but have people been building
websites with it and saying "yes I absolutely want this"?
Haven't really seen that.
<myles> jet++
fantasai: People want vertical rhythm, but is this the feature
that will solve it?
fantasai: We want this spec to be robust and integrate with the
rest of CSS elegantly.
fantasai: I don't think this feature fits that description.
fantasai: Our goal for features we design here in the CSSWG is to
be flexible, robust, powerful, easy-to-use, and
understandable.
fantasai: We intend for them to fit within, integrate with, and
enhance the CSS system
fantasai: Not be a hacky workaround to some particular issue.
fantasai: I don't believe this feature fits that design
requirement.
fantasai: Additionally, I don't think it does a good job of
addressing the use cases.
fantasai: Absolutely, people want control over vertical rhythm
fantasai: But their problems aren't largely about lines within a
long wrapped paragraph of text being slightly off-kilter.
fantasai: The breaks in rhythm are largely introduced by
block-level interjections in the flow of text.
fantasai: Things like headings, figures, tables, and block-quotes
fantasai: This feature does not address these use cases.
fantasai: It at best allows a hack of turning these block-level
elements into inline-blocks in order to use this feature
to control rhythm.
fantasai: I don't believe this feature is well-designed.
<myles> fantasai++
<tantek> fantasai++
<dauwhe> fantasai+^+^+
astearns: I absolutely agree that block-level interjections are
also a problem, but I don't agree that they're worse
than line box stepping
fantasai: much of the jitter in line boxes is due to problems
with our line layout model, which we need to fix
koji: I thought Kobayashi-Sensei explanation in Tokyo was more
understood
koji: discussion wasn't
koji: what he said was what Alan said
koji: not sure about Latin, but for Japan.
koji: What he said was when block-level interjection is big enough
he wants other factors wins over getting back to original
rhythm.
astearns: My impression was that his opinion was that it was
acceptable but still not enough.
koji: I talked with ppl who attended, ppl agreed with me
koji: maybe translation problem.
* fantasai suggests digging up the minutes
koji: What he explained was vertical rhythm when objects intervene
koji: Should be done like justification, so that each text block
and image and blockquote are like characters in the "line
box" of the page.
koji: Each space to have equal length is more important than
returning to the rhythm.
koji: Line grid can do it, or maybe other features, but then have
to adjust grid after intervening objects
koji: but line-height-step or block-height-step doesn't have this
problem.
koji: What sensei didn't say, is making block height to step.
dauwhe: A couple things, one is that I would love to see some East
Asian examples of how this feature fixes problems of East
Asian typography.
dauwhe: Examples have been in Latin, so hard for us to see the
goal of this feature as designed.
dauwhe: Also want to say that wrt Latin typesetting in general, I
agree with fantasai.
dauwhe: Last thing we want to change is line height of the blocks.
This is the worst result, lowest priority. Prefer to
adjust spacing around blocks.
dauwhe: So I would like to see more targeted use cases for the
case of East Asian, since in Latin this solution is not as
appropriate.
Florian: In Latin text, you have ascenders and descenders so the
visual edges of the line is irregular.
Florian: Whereas in CJK if the spacing is irregular, it is very
obvious
Florian: So a small superscript that sticks out and slightly
shifts the line is really bad.
dauwhe: It's pretty bad in Latin, too.
Florian: So that is one part.
Florian: Another response is to fantasai
Florian: wrt her design goals of CSS.
Florian: Early incarnations of this feature were very much not
robust.
Florian: We have made changes to decrease its powerfulness to
increase its robustness.
Florian: I don't think it's robust enough yet.
Florian: When I'm done with fixing interop on line height, then
will look at robustness of this feature.
Florian: I'm not sure we can make this feature robust enough, but
either way this depends on how we fix interop of line
height calculations.
koji: We seem to be discussing two topics, one is fundamental
design and the other is this problem of double spacing
Florian: The design of this feature makes it easy to use in some
cases and very broken in others. If we can't fix this, we
can't use this feature.
koji: Fundamental to vertical rhythm that some authors want to
take as much step as font metrics says:
koji: if font is taller, want to take more steps, as much as
needed to fit font
koji: whereas in some cases we consider accidental
koji: and that happens in line grid, too.
astearns: Same concern about accidental double spacing of
everything is a problem both for rhythm and for line grid
astearns: and we can't take either of the proposals if accidental
double spacing of everything is prevalent enough to be a
problem.
astearns: Accidental double spacing is prime example of the design
flaw
astearns: still talking about double spacing.
koji: What if double spacing happens in line grid, too?
myles: I don't think anyone has made the argument that line grid
should ship instead of this
myles: people are simply objecting to this feature on its own
merits (or lack thereof).
Rossen: First comment about jet's comments
Rossen: What jet mentioned earlier about lack of examples /
requests, we've had a lot of requests internally
Rossen: mostly ppl building multicol based layouts
Rossen: fairly impossible to make things align in terms of line
breaks.
Rossen: To that point, what fantasai said earlier was right on the
money
Rossen: Most of the problems aren't due to lines, they're mostly
due to headings and other blocks that are not multiples of
line height.
Florian: jet's comment was looking for evidence that this
particular solution addresses the use case, not evidence
that the use case was important.
Rossen: I was hoping to know, it's been already 1.5-2yrs that
we've been working on this.
Rossen: It's certainly the case that in CJK the use cases seem to
be predominantly based on just lines and lines of text
without that much blocks or other things in the flow that
contribute to irregularity.
Rossen: In those cases perhaps line grid makes sense, maybe that's
the best thing to do there.
Rossen: At the same time, most of the objections I hear constantly
against it
Rossen: are based on the other sets of requirements
Rossen: which are for multicol block-level stuff we were talking
about.
fantasai: No, there's two sets of objections one is the
block-level concerns, the other is the robustness
concerns.
<astearns> headings are not lines?
<astearns> (I know they're blocks)
<fantasai> astearns, the reason I'm saying that headings aren't
lines isn't that they aren't made up of lines, of
course they are. But generally the problem isn't having
each individual line snap to a multiple of the base
line height, it's having the heading as a whole snap to
that multiple.
<fantasai> because for headings you don't want to have large line
heights or gaps between the lines
<fantasai> astearns, you usually want them quite tightly spaced,
in fact, because they are a larger font size
<fantasai> astearns, but you want space around them, and you want
the total space taken up by the heading -- like the
total space taken up by a figure or table or blockquote
-- to fit into the rhythm
Scribe: TabAtkins
fantasai: Part of the robustness concerns is all this non-interop
stuff for line-height in general is part of it.
fantasai: Other thing is that the way we do line-height calcs in
general creates jitter.
fantasai: So even if we have line boxes with same height, that
doesn't handle the jitter case that CJK needs us to solve.
fantasai: So even without browser variance, even with a strict
vertical rhythm, within the linebox the line moves, and
line-height-step doesn't fix that.
Rossen: Many of the requests that we (Microsoft) has had for this
style of feature are caused by interjecting blocks in
between many flowing lines of text. [myles: therefore
those aren't solved by this particular solution]
fantasai: So if your concern is within a paragraph keeping a
rhythm, we need to fix interop *and* maintain the
baseline-to-baseline height.
fantasai: Because of the way we center content in the linebox, if
the content is slightly larger but doesn't spill out of
the linebox, it'll jitter.
koji: If you solve that, even when you do, if the font-size is
different, you'll still need line-height step.
koji: So it doesn't seem to be a reason not to do line-height-step.
fantasai: The only case you need line-height-step is if, in the
middle of a paragraph, you want to double-size a
particular line because it includes larger content.
<dbaron> I could bring back line-box-contain with stepping
extensions that I think would be more robust, at least
for some values of line-box-contain.
tantek: How long has Chrome been shipping this behind a flag?
koji: A year or so.
tantek: For a feature we all agree conceptually there's demand
for, we should have seen at least a handful of
experimental demo sites using them.
tantek: We haven't seen that, or if we have, please provide the
urls.
<dauwhe> the only codepen tagged with line-height-step is by
rachelandrew
tantek: Second is, I'm increasingly concerned with shipping
features that *almost* work, but are fragile and easily
break.
tantek: Having witnessed all the float/columns confusion, having
it break easily, that makes people distrust CSS as a whole.
tantek: Would be unfortunate to have the whole concept damaged as
a result.
tantek: So that's why providing the block-level solutions might
make it *just* dependable enough to make it usable in
production.
tantek: It won't be perfect, but can it be *reliable enough*.
koji: I tried to talk to some webdevs; my feeling so far is that
the experimental flag building sites works in US, but not in
international, where pops are smaller and people are less
willing to spend effort helping standardization.
koji: So they generally say "we'll try when it ships, but can't
spend much time before that".
koji: For robustness, as far as I understand, your "robustness" is
different from fantasai's concept.
tantek: Could be.
* fantasai doubts it
koji: I think you're more about accidental jumping.
koji: I think earlier we were talking about, when we get the
future stack thing - if it gets off the grid, it accumulates.
koji: That part is design - Japanese vertical rhythm is different
from Latin's.
Florian: Earlier fantasai was saying that this feature isn't quite
good enough; while it solves locally the size of the
line, it doesn't do the position.
Florian: Earlier feature did address that, but made it more
fragile.
astearns: It solved that using the baseline ratio.
Florian: So that's a bit of the difficulty with this feature.
Florian: I haven't given up hope, but I don't know if at the end
of the process it'll still be useful.
Florian: Currently kinda useful and kinda fragile; was earlier
more useful and more fragile; will it be useful at all?
Florian: So we have a feature that's either too fragile and not
useful enough, or one that's too difficult to figure out.
Florian: Otoh, there's a simple and useful feature that solves the
block side of the problem, which we most agree isn't
quite enough.
Florian: But I don't think anybody thinks the block feature is
insufficiently robust, or not useful.
Florian: So I recommend people start on that, rather than being
stuck.
Florian: As to whether this is still useful when it's robust,
dunno.
Florian: In parallel, I think it would be nice to try and make
line-grid simpler in terms of impl.
Florian: Nobody's been willing to bite the bullet yet.
Florian: If someone can find a magic solution, prizes!
<fremy> nice summary, Florian
* fantasai is reminded of trains. New shiny stops are exciting,
but maintenance and upgrades like computerized
signaling are actually more important to a functional
transit system
<fantasai> similarly here shiny new line-height-step seems
exciting, but fixing the interop and jitter (which are
two separate problems) in line layout in general is
what will make rhythm functional
fantasai: I don't think that finding the third solution is as
impossible as you think.
fantasai: First, we need to solve the jitter problem.
fantasai: We're wasting our time if we don't solve that.
fantasai: Requirement for any solution, and it's not specific to
line-height-step or line-grid
fantasai: We just need to fix line layout.
fantasai: We need to continue and prioritize the work that florian
has been doing, to fix line layout.
fantasai: Second, we need examples of where this specific feature
is a solution to a problem.
fantasai: I think this is solving a problem of fixing line-heights
within a wrapped paragraph, by doubling the spacing of
that line, and I don't think anyone wants that in
general.
dbaron: I think one thing we should look at to address this is
having whatever the solution is be a bit more of a mode
switch than what we're looking at.
dbaron: To some degree line-grid is such a mode switch.
dbaron: 14 years ago I had a proposal for line-box-contain, in the
ED for linebox for a decade, shipping in Safari for a
bit...
dbaron: That tried to add all the detail for how to consider what
should affect the linebox.
dbaron: But to a good extent there's only three values that are
important.
dbaron: One is what we do in quirks mode, one is what the specs
say, one is what devs actually want.
dbaron: It's a little complicated, but it's in the spec, hard to
find.
astearns: So in addition to box-sizing, we should have line-sizing?
dbaron: Not where I was going.
dbaron: One of the things is that you have a property that says "I
want a line grid at a certain size". Whether it's a
full-fledged grid or a slightly weaker thing.
dbaron: I suggest that, once that grid is established and for all
the blocks that use it (presuming you can turn it off for
some descendants), we switch line layout to another mode.
dbaron: We stop stupid things, like honoring line-height on
inlines.
<fantasai> dbaron+++++++++++++++++++++++++++++++++++++
myles: +++++
dbaron: Only honor line-height on boxes. Honor border or
margin-box size on inlines, so if they actually overflow
the line, they make it bigger.
dbaron: But if you're at line-height:1.25, you don't get the 1.25
buffer on them.
dbaron: And from there we can figure out baseline alignment to the
grid.
dbaron: So I think having a non-inherited property that
establishes a line grid or step-sizing space, is better
than an inherited mode switch, like line-box-contain was,
because it serves another purpose as well.
dbaron: While it has some mode-switching purposes, mode-switches
aren't that great. Doesn't cascade well.
<gsnedders> dbaron++++++++
dbaron: Has some of the effects of a mode switch, but not all of
them.
iank: A new inline layout...
dbaron: Not that different. Still doing inline layout.
dbaron: line-box-contain had a bunch of values that were like
"block", "inline", "replaced", "text", "ruby", "glyphs"...
dbaron: When you did your linebox height calc, you looked at the
list and only considered those.
dbaron: The standard behavior is "block inline repalced" i think
<Bert> https://www.w3.org/Style/Group/css3-src/css3-linebox/#LineStacking
<Bert> (A public link:
https://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain
)
dbaron: Quirks mode is more like "text replaced" or something
dbaron: But people don't really want inlines considered at all,
you just don't want glyphs to overlap by default.
dbaron: The principle isn't complicated, it's just a new step in
line layout that controls what you consider.
dbaron: The mode switch would be about changing what you consider
in that step.
myles: I think it's still in WK prefixed...
iank: It's removed from Blink.
astearns: See if it helps enough for this use-case?
myles: Which use case? ^_^
Florian: Having discussed a variant of this for several times, I
think coming back in a few months with the same
discussion isn't helpful.
Florian: I think it's clear that koji and fantasai disagree on
whether robustness is important/etc.
Florian: I think it's important if koji could show sites using
this feature in ways that trigger double-spacing, and say
"yes, this is what the author wants".
fantasai: No, you want sites using the feature that show why this
is good, and the other alternatives can't solve it.
astearns: We want to evaluate the shipping solution, to see if it
addresses the use-case.
astearns: We have a shipping solution, we should have evidence
that it's enough for some set of people.
Florian: And specifically, I want to see these examples hit the
corner cases, without authors getting bad results.
astearns: Whether the extant examples hit the corners or not, we
can use them to push them into the corners.
Florian: Other than that, I don't think it'll be useful to have
fantasai tell koji it's not useful, and koji saying it
is...
koji: I'm saying that robustness is different between Latin and
CJK.
Florian: Sure, I'm not trying to rephrase; it's just that
rehashing the same discussion without new info isn't
useful.
Florian: In the meantime there are concrete things we can work on,
like improving lineboxes. Maybe dbaron's stuff.
Florian: In the meantime just rehashing is harmful, it blocks us
from doing useful things on this topic.
tantek: I think this conversation has brought up some new stuff.
fantasai: My and dbaron's points were brought up in Tokyo.
<gregwhitworth> Decent amount of vertical rhythm libs in CSS & JS:
http://kyleshevlin.github.io/shevy/
tantek: I think some new stuff, like examples that use it
astearns: And I think line-box-contain is new.
tantek: So I think it's not fair to say it's a complete rehash.
astearns: But I agree we need examples, "this community won't turn
on a flag" isn't a good enough response.
<dauwhe> https://github.com/w3c/csswg-drafts/issues/1257
koji: Why doesn't printed material show this?
astearns: We need examples of *this particular solution* trying to
solve things.
Florian: Looking at print doesn't help here; it illustrates there
is a problem to solve, but not that this solution in
particular solves the problem.
koji: Word isn't print - if you look at a word doc with different
installed fonts, you get a similar problem.
Florian: Usually that happens because of switching between Word
and OpenOffice, and people hate it.
Florian: I'm saying that showing examples of *other* things
doesn't help us see if *your* solution solves stuff.
koji: If you require that of every i18n feature, we'll never get
it done...
Florian: We're not asking for everything, just for controversial
things.
myles: And there's another possible solution - dbaron's l-b-c.
<myles> I meant line-grid in addition to dbaron's idea
astearns: Even without another, this particular solution has
enough controversy that we want to see successful use of
it in the wild.
astearns: Anything else to go into?
<gregwhitworth> worth noting -webkit-line-grid is on chromestatus
<gregwhitworth> none of the rhythmic sizing props are
<gregwhitworth> ^ not sure if chromestatus shows experimental flag
items or not
Proposal to adjust 'normal' to value based on line-height-step
--------------------------------------------------------------
scribe: fantasai
github: https://github.com/w3c/csswg-drafts/issues/938
koji: Yeah. There are multiple issues in here.
koji: One issue has a proposed solution, shane and tab came up
with.
koji: It's about avoiding accidental jumps.
koji: I understand it doesn't solve all, but I want people to
understand the proposal and see if it solves part of the
problem.
TabAtkins: So the ultimate problem is that when line-height is
normal, it's unpredictable
TabAtkins: So if you set a line-height-step anywhere near the
normal value, might look good on your screen not on
others'.
TabAtkins: Proposal is that if line-height is normal and result of
that would give you a light-height slightly over your
normal line-height
TabAtkins: based on some UA threshold of fuzziness.
TabAtkins: Instead of doubling spacing, reduce to line-height-step.
TabAtkins: It should hopefully correct any accidental slight
overlap that you run into.
astearns: Why UA-defined squishiness?
TabAtkins: Figure out the right value later.
*fantasai suggests (normal-1em)/2
TabAtkins: If we can agree on one later, great, but otherwise
don't want to sink the proposal by arguing over value
right now.
Florian: I believe I understand the proposal but don't understand
why it helps.
Florian: If one browser normal is slightly smaller than step, and
in other browser slightly larger, then it helps
Florian: But if in your browser it's slightly larger than normal,
but in other browser it's even more larger than normal
Florian: then you get single spacing in yours and double sizing in
the other.
Florian: So it changes the numbers that trigger the problem, but
it doesn't make the problem go away.
TabAtkins: Think set of cases that get fixed are going to be more
common than set of things that get broken.
TabAtkins: In order to get broken as you say, you need to set
line-height-step smaller than your line-height.
fantasai: Line height normal is unpredictable though.
Florian: Line height: normal isn't between 1-1.2, it comes form
the font. It might be 2.7.
Florian: Within i18n contexts it varies a lot, even though you
don't see it that much in Latin (aside from fantasy
fonts).
TabAtkins: Ignoring fantasy fonts and Zapfino.
fantasai: i18n
TabAtkins: You said there's larger variation in the consequences
of the line box size due to non-Latin character set
default fonts.
Florian: I believe so, and I think Koji claimed that before I did.
fantasai: I suspect you're more likely to get that variation in
Tibetan and Thai and other fonts that have lots of
diacritics.
myles: I agree that fuzzy matching is a good way to solve language
problem.
myles: Implementation knows exactly where all the lines go, so
implementation has all the information it needs
myles: rather more than the author even, cuz author doesn't have
font metrics.
myles: So reasonable to have implementation make lines fit well.
myles: Previous conversation needs to be resolved before we take
this though.
TabAtkins: Might want to evaluate solution with this in mind tho
koji: I agree with myles that the accidental jump issue has needs
to deal with some heuristics
koji: because in some cases we want to squash really tall fonts.
koji: Implementation can experiment and maybe a few years later we
find very good values and want to standardize it but at this
point better to experiment and get feedback
astearns: Your experimental implementation, if you can get people
to use you can get data on utility of squishiness.
koji: Does that solve previous concerns?
* fantasai thinks not
astearns: Would anyone object to experimenting with this?
astearns: 2nd, would squishiness as described make anyone more
interested in this feature?
myles: Not for us.
astearns: So this squishiness doesn't help other implementers be
interested in line-height-step, but seem to be no
objections to Google experimenting with it.
Florian: No objection to experimentation, less certain about
adding it to the spec.
koji: If not in the spec, we can't ship it.
Florian: I don't want to ship this without a flag unless we have
strong evidence that it is less dangerous than people
have expressed worries about.
Florian: Changes to the spec discussed so far don't make me
convinced.
koji: Why can't you at least suspect it helps?
Florian: I suspect it does not.
Florian: I expect it breaks some fixes some and it's a wash.
Florian: If it fixes lots and breaks few, pls demonstrate.
myles: Do we need a resolution for Chrome to experiment behind a
flag?
Florian: No, they want it in the spec so they can ship it without
a flag.
astearns: They don't need our permission to experiment, would need
permission to add it to the spec even though the
consensus of the group is not that the feature is at a
point that is OK to ship without a flag.
koji: Issue was browsers hard-coded differences in line height
calculations triggering different steps, we're trying to
solve that, so Chrome doing it doesn't help.
astearns: You didn't convince Florian, but myles seems to agree it
might help.
dbaron: I agree with Florian's concern that it seems to mostly be
moving the threshold and not actually fixing the bug.
Florian: I didn't mean that in the long run Chrome should have it
and others shouldn't add it, I'm suggesting that the only
implementation we have experiment.
myles: 100% of implementations will experiment.
Florian: Add squishiness, come back and tell us if it improves the
situation.
fantasai: Koji's pointing out that we want to find out if there's
a problem with interop. Chrome can't find a problem with
interop by itself.
TabAtkins: To simulate differences in how normal gets interpreted,
swap around the font list.
fremy: Or switch from Mac to Windows.
astearns: OK, think we're done with rhythm.
Meeting closed.
Received on Friday, 1 September 2017 12:51:12 UTC