- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:46:52 -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.
=========================================
Text Track
++++++++++
Repeated Headers and Footers
----------------------------
- Florian introduced an idea for generalizing the repeat-on-each-page
behavior of table headers and footers to other elements.
It seemed to need more work before being adopted as a WG work item.
CSS Text 3
----------
- The usage data is too high on word-break: break-word for Chrome
to remove it, so group is waiting on Edge folks to reply about
adding it for compat.
- RESOLVED: Put an issue in the spec about whether overflow-wrap
should apply regardless of whitespace.
- Xidorn/i18n were actioned to see if breaking punctuation but English
is a case used in Chinese, to see whether it is necessary to
support that case as well. (Apparently line breaking tailorings
are expensive to add to certain commonly-used libraries.)
- RESOLVED: add line-break: break-all to the spec, definition depending
on i18n report on required behavior(s)
CSS Rhythm
----------
- In trying to solve the issue to avoid double spacing, bugs were
filed on other specs to fix inconsistent on confusing behavior
that was making this problem harder to solve.
- The group agreed that they should make step-sizing safer, but
they did not reach an agreed approach to addressing the issue.
CSS2
----
- RESOLVED: Fix the erroneous conclusion in section 10.8 (in
reference to https://github.com/w3c/csswg-drafts/issues/391)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split the morning of the 20 April on two
tracks: FX and Text.
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Brian Birtles, Mozilla
Bogdan Brinza, Microsoft
Rick Byers, Google
Tantek Çelik, Mozilla
Emil A Eklund, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Simon Fraser, Apple
David Grogan, Google
Jihye Hong, LG Electronics
Dean Jackson, Apple
Toru Kawakubo, Vivliostyle
Ian Kilpatrick, Google
Vladimir Levantovsky, Monotype
Chris Lilley, W3C
Myles Maxfield, Apple
Jack Moffitt, Mozilla
Shinyu Murakami, Vivliostyle
Xidorn Quan, Mozilla
Florian Rivoal, Vivliostyle
Hiroshi Sakakibara, BPS
Simon Sapin, Mozilla
Alan Stearns, Adobe
Shane Stephens, Google
Surma, Google
Lea Verou, Invited Expert
Jet Villegas, Mozilla
Philip Walton, Apple
Johannes Wilm, Vivliostyle
Scribe: iank
Text Track
++++++++++
Repeated Headers and Footers
============================
<astearns> https://specs.rivoal.net/css-repeat/
Florian: Tables are special, table headers and footers repeat
across headers.
Florian: Sometimes you want this on other things apart from tables.
Florian: So based on a need in a vivliostyle project, we'd like to
generalize this, and can be applied to things other than
tables.
Florian: So the stand-in name is repeat-on-break.
Florian: Only applies to one element, ignores other elements which
have this property.
Florian: First repeatable footer will move to the bottom, first
repeatable header will move to the top.
Florian: This follows tables, that the basic idea.
Florian: So we've implemented this, its early, but its possible,
we find this useful, I'd be interested in having an
editors draft.
Florian: Most useful if you do a lot of fragmentation.
Florian: Parts of the tables spec could be offloaded to this.
plinss: If we can explain the current magic of tables with a UA
stylesheet instead of auto?
Florian: I remember thinking about this, I can't remember why we
went for auto.
Florian: I'll need to think slowly through it, but if it can be
done, why not?
Florian: One advantage of the auto keyword it allows you do to a
lvl 0 implementation.
plinss: I don't know what your syntax looks like, but would be
nice.
Florian: <explains syntax>
<fremy> @plinss @Florian: The conversation diverged but I wanted
to mention that I don't think you can get rid of auto and
define this in a UA stylesheet. Because one can set
display of table-header-row on any kind of element, and
the author doesn't set the new property yet still get the
repeated behavior right now. So there must be some magic
to tie the two together somehow.
<astearns> thanks, fremy
<fremy> @astearns: No problem, I'll send feedback on github
Tantek: Repeating headers and footers were dropped from HTML,
nobody implemented this, and it got dropped....
Florian: Prince, vivliostyle, and anntenahouse all implement the
repeating headers and footers.
tantek: Do any of those members participate in that WG?
Florian: I'm confused as to why HTML WG talks about layout.
fantasai: The HTML spec right now shouldn't be specifying that.
fantasai: CSS spec should specify how that renders.
Florian: I'll check that, it is implemented.
tantek: But not in any browser.
Florian: I disagree with interactive, vivliostyle is interactive.
Florian: Either most/all don't have this.
tantek: If I was looking at this from an outside perspective, this
is incubation.
fantasai: I don't think we generally do this.
Florian: The incubation approach sounds reasonable, but don't want
to do this in WICG.
tantek: Not saying this should be in WICG, I think we should do
this (incubation) in CSSWG.
Florian: ED is relevant topic, globally sane approach, FPWD is
without any time commitment this is something most folks
would be able to implement.
astearns: I suggest b/c of time constraints, we don't discuss
incubation.
Florian: Realizing that this isn't a group commitment to do this -
would folks like an ED.
<dauwhe> Prince will repeat thead/tfoot/caption on every page, but
otherwise requires using page margin boxes for repeating
elements
<dauwhe> Lots of people ask Prince for such functionality, though
astearns: I would like gregwhitworth & fremy to look at this, as
they are revamping tables spec, would like to get their
opinion if we'd have this as an ED.
fantasai: I think we need the whole group's opinion.
astearns: I'm very interested in how this works with grid layout.
Florian: Yes, but with caveat we don't know how grid fragmentation
works.
fantasai: Would this apply to a grid-item?
Florian: <discussing how this may work with grid>
fantasai: We do placement before we do layout in grid, because you
need to know how wide the columns are, i.e. know which
column something is in.
Florian: Will that work when pages have different sizes?
fantasai: Gets trickier, but you still need to know content of
whole grid.
fantasai: Intrinsic constraints, carry through across all pages.
Florian: It seems there are cases with grid where you would want
this to work.
Florian: I'm not entirely convinced we want to fragment the grid.
fantasai: ok, thats a different thing (discussion).
Florian: Not sure if we want to do this, may need to figure out
grid fragmentation first.
Florian: But we are time-boxed, doesn't sound like we can resolve
on ED yet.
ACTION: Florian to talk with gregwhitworth & fremy about how this
interacts with table spec.
<trackbot> Created ACTION-848
<tantek> FYI: in general I'm in favor of a fairly low political
bar for starting an ED, but we should consider, per
incubation, if it is something that we wouldn't mind
seeing it prototyped
<tantek> i.e. ED = start incubating, and IMO FPWD should mean we
have sufficient evidence of incubation (e.g. prototypes
that seem to at least somewhat work as expected)
Florian: For the record had a 10s conversation, TabAtkins said
looks ok.
iank: We'll look at this from a blink perspective at some stage.
CSS Text 3
==========
Scribe: rachelandrew
word-break: break-word
----------------------
<fantasai> https://drafts.csswg.org/css-text/issues-lc-2013#issue-94
fantasai: The first issue we were waiting to hear back from
Microsoft on word-break: break-word
Florian: Google is finding it impossible to remove.
fantasai: As an aside, no-one understands any of the white space
properties, and I don't know how to make it better /
easier to understand; I can't come up with anything.
Florian: If we add it it would be for webcompat reasons which
makes it doubtful we can rename it.
iank: Our use counter for this property is that we are at 20% of
every page load.
fantasai: Seems we are over the threshold, so this feature needs
to be added somehow so Firefox and Microsoft can have that
ability, whether authors would be willing to switch over
to a better name.
Florian: We did a bit of whiteboarding on a better name yesterday.
iank: I'm just looking to see if it is feasible to add a use
counter.
tantek: We had an open bug on implementing at Mozilla, it has
caused compat issues in the past but there are old
complaints but no new ones.
fantasai: If Mozilla isn't under pressure to add it, and Edge
isn't then we can at least try to come up with something
better and phase that in. All of the line breaking
properties are very confusing.
tantek: It needs to be a lot better or we may as well stick with
compat.
<tantek> our bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1296042 to implement "word-break: break-word"
fantasai: The usability problem is we have the same keyword on 2
different properties meaning different things.
astearns: I don't think we can resolve need to hear back from
Microsoft.
fantasai: Use data is high enough that it's scary.
tantek: Is this something authors are actually using, or is Word
just sticking it in or something?
terminal-style line breaking (break anywhere)
---------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1171
Florian: There are many variations on how to wrap text, one thing
is wrap everywhere, get to the end of the line break and
do a new one (terminal-style)
Florian: The main difference between this and word-break:
break-all is that the latter allows wrapping points
between letters but not punctuation
(Basically, 'word-break: break-word' treats all letters letters like CJK.)
fantasai: This value was intended for Japanese.
Florian: This doesn't do what you want if you want the terminal
wrapping.
fantasai: Right now the word-wrap property acts on letters and
symbols not punctuation.
fantasai: The line-break property deals with punctuation rules
fantasai: so we have logical separation of the two properties.
fantasai: Adding a new value to word-break is weird as that isn't
what it does.
fantasai: So we might want to add a value somewhere else, maybe
line-break: break-all.
Florian: The alt way to approach that is the overflow-wrap
property, if things do overflow and you do overflow-wrap:
break-word it allows the overflow to be anywhere.
fantasai: overflow-wrap says pick some arbitrary place near the
end of the word to wrap.
Florian: [writes on the whiteboard]
fantasai: So make overflow-wrap work regardless of the white-space
value.
fantasai: It does make sense that overflow-wrap is allowed to
apply as this is basically emergency breaking.
fantasai: We might also want to add a break-all value.
fantasai: We should add line-break: break-all and also make
overflow wrap apply regardless of the white-space value.
fantasai: I think that both behaviors are useful.
koji: Why do we need two things to do the same thing?
fantasai: Currently overflow-wrap can allow breaking or
non-breaking of a word.
fantasai: This doesn't change your intrinsic sizing.
fantasai: The other properties actually change the line-breaking
rules.
fantasai: I think the behavior you would get for adding line-break
is different to the behavior you will get from
overflow-wrap.
fantasai: We need a value that says break all, everything. But we
might also want to set the intrinsic size according to
normal line breaking rules.
koji: I think people want to change the intrinsic size, but not to
change overflow behavior.
iank What about properties that override intrinsic sizes.
fantasai: This is about how we calculate the size of overflow text.
Florian: We want at least one of the two.
fantasai: We definitely need line-break: break-all.
astearns: I have concerns about overflow.
fantasai: I think we can resolve on the one, we should keep in
mind the other question whether overflow should wrap
regardless of white space.
astearns: Resolve to put an issue in the spec for overflow: wrap
to apply regardless of whitespace?
RESOLVED: Put an issue in the spec for overflow: wrap to apply
regardless of whitespace.
astearns: To add a value to line-break that will say break
anywhere with regards to punctuation.
fantasai: Then maybe add a shorthand to make this all easier.
fantasai: break-all is one possibility, anywhere is another
possibility.
koji: It's strange because line-break is a CJK property.
fantasai: line-break is a property for different levels of
punctuation strictness in different languages.
Florian: They forbid line breaking in various places.
fantasai: word-break does letters and symbols, line-break does
punctuation.
astearns: So to get the terminal effect you would set line-break
and word-break to break-all.
koji: If we were to respond to original request it is easy, it is
just to change one thing.
koji: break-anywhere is easy, break-anywhere at punctuation is a
new thing.
myles: We would implement it at the system level.
myles: webkit doesn't want to be in the business of understanding
all this stuff.
koji: In Android we define the priority of which to support and
cut some of them.
koji: this new mechanism is more complex.
fantasai: I think it would be worth finding out if the combination
is needed in Chinese (don't break a Latin word but break
punctuation anywhere)
Florian: I think the Japanese style of document, do English words
get broken.
koji: It does get broken.
fantasai: If we find out if we need to add it then we just need to
pick a syntax.
ACTION xidorn to see if the case where you break at punctuation
but not through English words is used in Chinese
<astearns> based on that result, solve this issue with line-break:
break-all (that allows that) or with a solution that
breaks everywhere including punctuation
fantasai: I'm leaning to the syntax being line-break: break-all
fantasai: We have to pick a property, and line-break already
affects some letters word-break whereas does not deal
with punctuation.
astearns: Can we resolve to put line-break: break-all in the spec
for the purpose of the terminal use case, if it does
that use case only or if it does it with the other
property depends on investigation?
RESOLVED: add line-break: break-all to the spec
CSS Rhythm
==========
Avoiding accidental double spacing
----------------------------------
github issue: https://github.com/w3c/csswg-drafts/issues/938
Florian: This is about avoiding accidental double spacing. This
might happen if an author sets line height step to 1.3em
and the default font using line-height: normal turns
out bigger than 1.3 em.
Florian: In another font the line-height might be calculated at
double height.
Florian: The previous proposal was to make the height deterministic
Florian: but koji pointed out that line-height: normal is useful
as it avoids overlap with long ascenders and descenders.
Florian: I have a proposal for this:
Florian: when you have something with a tall line-height you want
it to be double, when it inherits this is a feature.
Florian: When you set it, you never want to accidentally make the
line-height step smaller than the natural line-height.
Florian: Sometimes you want to do it on purpose.
Florian: I'm proposing to add a safe /unsafe keyword pair
defaulting to safe.
Florian: Current behavior is the unsafe one.
dbaron: I understand but think it is a problem.
dbaron: The check is whether the line-height step is smaller than
the line-height and if so make the step bigger.
dbaron: The 2 pieces I am concerned about, 1 is that normal is a
computed value of line-height
dbaron: having that go back and influence line height step doesn't
seem as if it will work.
dbaron: We do sometimes have font metrics influence computed
values.
Florian: You need to take the line-height unit value as the lh
unit depends on it.
dbaron: So maybe that is ok, the other thing is that if you use
text for more than one font we claim you end up creating a
box of the size of the line-height around both sets.
dbaron: Creating a height that is larger than the line-height.
fantasai: That's a general problem.
Florian: Does this change what line-height normal means?
dbaron: [to the whiteboard]
https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0006/IMG_20170420_102101.jpg
dbaron: [demonstrates lining up characters on the whiteboard]
dbaron: [draws a Chinese character and a Latin letter]
dbaron: suppose these come from different fonts
dbaron: [draws the ascent and descent on the Chinese character]
dbaron: [then draws the ascent and descent on the Latin letter,
which is a little bit lower]
Florian: Which is the primary font and which is the fallback?
dbaron: It shouldn't matter as per the spec.
fantasai: I think there is a conflict in the spec.
dbaron: The number line-height is 1.26 font size 16px, so we want
a 20 pixel box round each of these.
dbaron: [demonstrates where the line-height boxes are around the
two characters]
<fantasai> (dbaron is using a numeric line height in place of
normal, because normal could result in varying line
heights; didn't want to deal with the complexity yet)
dbaron: End up with a line box height bigger than the line-height
[dbaron notes that because the ascent plus descent plus
half-leading of each adds up to 20px, but they are offset
by 1px, the total line height is 21px]
[fantasai says the CSS2.1 spec says two contradictory things, one
of which is what dbaron described]
Florian: In this case if you started with a line-height step of 30
pixels you wouldn't get double spacing
dbaron: The designer might have fonts that have the same box and
others have different boxes and get the double spacing.
Florian: For it to fail that way you need multiple fonts falling
back to each other.
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
fantasai: I think this point is really important, it is a critical
flaw in how it works.
fantasai: When you have boxes of the same height, the CSS2.1 spec
says 2 different things
fantasai: you get that result (21px including the offset) and *also*
get 20px, depending on which part of the spec you read.
fantasai: So we need to fix that
fantasai: in order for line-height-step to be at all robust and
not flaky we need to fix it to yield 20px
<fantasai> (The spec says two contradictory things, and supports
both Gecko and WebKit's interpretations depending on
which sentence you read in the paragraph describing
this)
myles: Gecko and spec agree with dbaron's example, WebKit would
calculate the height and add spacing to either side to make
it equal.
<dbaron> I don't think that's actually what Gecko does
dbaron: oh, yeah, that is what the spec says -- add the
half-leading after unioning the character heights
<dbaron> Here's the thing I drew on the whiteboard:
https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0006/IMG_20170420_102101.jpg
<dbaron> (although as myles pointed out, I was wrong)
astearns: This is one crucial instance, but initially you were
talking about making step sizing in the safe mode that
would increase itself if it encountered a large
line-height.
Florian: Where you have set your step size accidentally smaller
than the computed value of line-height.
fantasai: Can we resolve on fixing this 2.1 issue?
<astearns> fantasai there's a bug for css2 on this?
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
<astearns> then let's get that on the agenda and resolve this
separately - I don't want to move off rhythm right now
koji: How do you compute line-height normal to pixels?
<general disagreement about the spec>
dbaron: It's more like a number than any other kind of value but
it does a thing based on the font.
myles: It is based on the default font.
<astearns> the point I wanted to make that you use step sizing to
create vertical rhythm. Creating a 'safe' version that
avoids double spacing and breaks the rhythm is
counterproductive
Florian: Is there a definition for the used value of line-height,
if you have normal and know the font?
fantasai: At computed time the lh unit needs to map to an actual
value.
dbaron: I think you get it from the first available font.
Florian: The value of the line-height property, does it change
based on content on the line?
Florian: Does that property vary per line?
myles: No properties do not vary per line.
Florian: You can't change the primary font per line.
dbaron: I think Florian is talking about multiple lines splitting
the same element.
dbaron: The computed value of line-height normal is normal
dbaron: so if you are asking what lh does, when you have
line-height normal use the first available font in the
font list.
Florian: Not only is the value normal, but the value of
line-height 1.2 is 1.2.
dbaron: Let's file a spec issue.
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1253
on css-values-4
Florian: What makes this impossible?
dbaron: Spec needs to say how to compute to an abs length,
probably using the primary font.
Florian: Do you need to do layout to figure out the pixel value of
line-height?
dbaron: For the lh unit or for layout?
Florian: Not talking about the line box.
Florian: what does the UA pick the number based on?
fantasai: I think you assume this gets computed by a number and
used as that number for layout calcs, used as a length
to figure out the leading
fantasai: That conversion happens per font in the text.
myles: webkit does this.
fantasai: If you don't have a value for the entire run, how can
you work out the line-height for a single value?
myles: (answering q) We do a bunch of stuff for the width then we
calculate heights and place vertically.
fantasai: For each char you find ascent and descent, get a value,
if it is not the line-height increase or decrease on
both sides to get the line-height.
dbaron: Do you then use the normal?
dbaron: Use line-height: normal, a single element on the line, font
fallback is happening in the line, fonts have different
metrics for line-height: normal and ascent and descent ...
you take the ascent and descent, where do you get the
number for normal
myles: We don't; we take that value with no extra leading.
dbaron: Gecko includes the external leading.
Florian: How is this not a violation of 2.1?
koji: This sentence contradicts other parts of the spec.
dbaron: That sentence was written in the olden days.
dbaron: It assumes defaulting to what the font says.
<dbaron> https://drafts.csswg.org/css2/visudet.html#inline-non-replaced
koji: Describes content box height.
fantasai: The content box height has no effect on layout.
dbaron: It matters re leading around it.
fantasai: But this section is not related to line-height normal/
dbaron: It can change the size of things, because the leading
changes the content height, the middle of where the
content height is does matter to layout.
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1254
on line-height:normal definition in CSS 2.1
astearn: We're not really addressing the rhythm issue here, though
we found bugs in other specs.
Florian: Do we have an issue to define the line-height unit based
on primary font.
dbaron: Pasted such an issue earlier.
Florian: The issue I proposed is to define the same way.
koji: This is based on font metrics of the primary font in safe
mode.
Florian: When it inherits, is specified. It doesn't depend on the
font.
astearns: You set your vertical rhythm for body text but the
heading is bigger what happens.
Florian: The line step height will double to keep the rhythm
Florian: gets the unsafe value from the pixel
Florian: not magic, doing this based on a keyword, unsafe is
current behavior. safe will cause the bigger line-height
behavior.
koji: Does this change based on inheriting?
Florian: No magic with inheriting
Florian: how well this works depends on how we fix 2.1, it doesn't
make things worse.
koji: I don't see it saves much, maybe some cases people think it
is better.
fantasai: Might want a keyword on line-height-step to use line-height.
astearns: That would make double spacing more likely.
Florian: You don't want to be exactly the line-height, needs to be
just a bit more.
astearns: Step sizing could be a percentage of line-height.
Florian: Either line-height is a number and works, or it isn't.
Florian: If you want to set your step smaller than the
line-height, set it explicitly with unsafe then it will
not get adjusted up.
Koji: On web, due to small screen real estate, people set grid to
fraction (half) of the desired line height.
astearns: That happens in print as well.
koji: I understand some cases it helps, given complexity vs
benefit.
Florian: It is very frustrating when people won't use a browser if
it breaks, the outcome of not dealing with this could
cause problems with different sized fonts, in one browser
double heights might happen based on default sizing.
fantasai: Having a layout system that breaks badly when fonts get
substituted is bad.
fantasai: Double spacing is bad.
dbaron: Authors should not have to write a number in their CSS
that has to be right based on the font the user has.
Florian: The feature currently requires users pick a value.
<dauwhe> I had an example where double spacing could be triggered
purely by switching font family from serif to fantasy
dbaron: The dev currently has to write line-height 3 or 20 pixels,
Chrome might switch to double spacing based on one value,
Firefox might pick another value, a subtle difference
means you get double spacing in one browser and not
another.
dbaron: Gecko has had to reduce line-height they compute for
webcompat issues.
fantasai: We don't want more of these situations.
astearns: Should we come up with a way of making step sizing
safer, we haven't come up with a resolution on that.
css2 fixing
===========
github topic: https://github.com/w3c/csswg-drafts/issues/391
fantasai: Suggested resolution is to fix the erroneous conclusion
in section 10.8
RESOLVED: Fix the erroneous conclusion in section 10.8
Received on Saturday, 27 May 2017 00:47:42 UTC