- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 12 Nov 2018 19:21:53 -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.
=========================================
MultiCol
--------
- The current proposal for issue #3224 (improve column-fill and make
it backward-compatible) is "if there's no min/max constraint,
and the height is specified to be an automatic size that's
equivalent to min-content, the columns balance; otherwise they
fill in order" but we need exact spec wording and a list of
possible constrants to make sure it's well-defined and sensible.
- RESOLVED: Close this issue no change. (Issue #2552: What happens
to the mbp of the empty fragment created by a spanner
being first-child of an element)
- RESOLVED: Margins between adjacent spanners do collapse (Issue
#2203)
- RESOLVED: Margins between spanners and any other non-spanning
boxes do not collapse (Issue #2203)
- The exact method on how to achieve the above two resolutions will
be resolved later; Morten has posted a detailed proposal in
https://github.com/w3c/csswg-drafts/issues/2203#issuecomment-431695940
CSS Text
--------
- RESOLVED: Add an 'anywhere' keyword to 'overflow-wrap' (Issue
#2682)
- RESOLVED: Close this issue no change (Issue #3117: Revisit
text-align shorthanding text-align-last)
- RESOLVED: Add a percent value to letter-spacing, word-spacing,
text-decoration-width, text-underline-offset that is an
inheritable proportion of font size (Issue #2165)
- RESOLVED: Add a new text-spacing:auto value, which is not the
initial value. (Issue #3229)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule
Scribe: heycam
Multicol
========
Improve column-fill and make it backward-compatible
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3224
rachelandrew: This was recently raised by Morten Stenshorne,
basically saying that we seem to have interop with
chrome/edge/webkit column-fill:auto about balancing
rachelandrew: When block-size is unconstrained, balancing is forced
rachelandrew: It says Gecko doesn't force balancing in this case
rachelandrew: and Gecko appears to follow what's now in the spec
rachelandrew: I did some digging, the spec was changed in 2012 by
Håkon, commented out some text, which led to this
interop issue
rachelandrew: Morten is suggesting that we should fix the new spec
and make it backwards compat, so column-fill:auto
forces balancing if the block size is unconstrained
florian: Another consideration here is I don't know whether we only
do this for compat reasons, or if it's use case driven
florian: The issue was discovered by trying to fix one of the
problems of what the interop impls do
florian: column-fill: auto is supposed to say “don't balance”
florian: I.e. fill the first column as much as you can
florian: Except it doesn't do that unless you constrain the height
florian: If you're in a grid, or if you have a min-height, maybe you
do want to start not balancing and take the min-height into
consideration
florian: Also suppose height was not fixed to a length, but it is
otherwise constrained, e.g. via grid...
florian: so we're trying to patch our way out of that
florian: If we start with the Gecko behavior, filling as much as you
can, then wrap, that solves that problem
florian: The fact that we have mostly interop, not full interop, we
can decide
rachelandrew: I've run into the issue of wanting to have a min-height
rachelandrew: If you have a small amount of text, and it's going to
fragment into 3 columns, without being able to do the
min-height thing, you get short bits of text
rachelandrew: but if you want to say make it at least this height
rachelandrew: That behavior is useful
florian: If you have the Gecko behavior as a starting point, you
would use max-height instead
florian: when it reaches that it starts wrapping
rachelandrew: Certainly a use case for that
dbaron: The issue you raised about grid reminds me of an issue we
talked on last week's telecon
dbaron: seems like the same thing
fantasai: I think Morten was suggesting it balances only when it's
unconstrained
fantasai: if you have a min/max height that's a type of constraint
florian: It's not what they currently do
florian: If min/max/height are all auto, but you are constrained by
being a grid item...?
fantasai: That's constrained
florian: That would work for me
fantasai: You could say if height is max-content or equivalent in
behavior, then we consider that unconstrained
fantasai: and it balances
fantasai: otherwise not
rachelandrew: That makes sense
florian: Seems to me that would work, and not be too disruptive, I'm
not convinced it's more useful
florian: Are we trying to minimize the cost of changing impls?
florian: That plus web compat plus the idea that when you give
something an auto height, it's supposed to fit it to content
florian: Balancing as part of that kind of makes sense
fantasai: Morten is also suggesting "don't ever balance" should get
its own value, not 'auto'
fantasai: The proposal is to accept Morten's suggestion that
column-fill:auto does balance only when the height is
unconstrained, which means the behavior is equivalent to
min-content
florian: I think I agree, just confused about min vs max-content
fantasai: I think they're defined to be the same thing?
florian: This is one of the cases where they might want to mean a
different thing
florian: The min would reasonably be the wrapped size, and the max
be the unwrapped size
florian: and it's the unwrapped size that makes sense here
dbaron: I think this is probably going in a direction that would be
too vague
dbaron: so not worth getting to that detail
dbaron: If you want a proposal for switching, it needs to be clear
about figuring out which case you're in
dbaron: The way you just defined it there are still ambiguous cases
dbaron: If you have a min/max height that probably isn't going to
apply in your situation but might in another ?
dbaron: If you're in a block where you have this much content, and
you have a max-height that's way down there, ...
fantasai: max-height would be a constraint
dbaron: There are a pile of situations like this
rachelandrew: I'd be happy to have a go at writing these situations
down
florian: Just to be clear the reason we're going after the Gecko
behavior is to minimize the cost of changing?
florian: or any other reason?
fantasai: It's called auto, not fill...
rachelandrew: I'll bring these back to the group after writing it up
fantasai: Current proposal: if there's no min/max constraint, and
the height is specified to be an automatic size that's
equivalent to min-content, the it's balanced
Mbp of empty first fragment split by a spanner
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2552
rachelandrew: This may well be that it is covered, not convinced in
the text
rachelandrew: When we resolved last time on 1072 about when the
spanning element is a first child, we end up with an
empty fragment, and the mbp ends up above it
rachelandrew: You get this strange issue, not specced, that if you
have mbp its gets split across the columns
rachelandrew: I don't think it's behavior people want to expect
rachelandrew: Would like it to be sure it doesn't happen
fantasai: I think the fragmentation spec doesn't allow breaks within
padding
fantasai: So it's not possible to split it across all 3 columns
rachelandrew: Is this something that should be specced?
fantasai: I think it should be defined enough in css-break-3, so
you can write a test for it
fantasai: The top mbp should all be as one unit in a single column,
the only reason to ever split is if you have a situation
where the fragmentainer is too short, you're allowed to
slice things [including line boxes and images; which
shouldn't happen due to balancing]
rachelandrew: So might not be an issue in the multicol spec
florian: If the spanner is a child of a thing with a top margin...
florian: In general it's a thing that makes sense if it's the first
thing
florian: Earlier today we added properties to opt out of this problem
rachelandrew: At the moment the behavior is not what anyone would
want
rachelandrew: so probably can close this issue, I will check this
<fantasai> rachelandrew, https://www.w3.org/TR/css-break-3/#possible-breaks
<myles> is the a web platform test for this?
<astearns> myles since the previous issue came up while rachelandrew
was creating tests, if there isn't already a test I
expect there will be one soon
<myles> astearns 👍
RESOLVED: Close this issue no change.
Margin collapsing does not make sense with column-spans
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2203
dbaron: I think there are a few different things going on
dbaron: I'm not sure which we've already solved
dbaron: One is that one thing, at the time, nothing said that the
columns inside a multicol create BFCs
dbaron: The underlying question is can margins on column spans
collapse
dbaron: 2 questions under that
dbaron: 1st is, can the margin on a column span collapse with another
column span right next to it?
dbaron: That one, we could maybe argue about
dbaron: There are believable arguments on both sides
dbaron: Other question is can a margin on a column span collapse the
first thing in the multi col part in the col span (??)
dbaron: Last time we looked at the spec, it looked like it could
collapse
florian: The spec is vague enough to read it that way
<fantasai> I like Morten's proposal in
https://github.com/w3c/csswg-drafts/issues/2203#issuecomment-431695940
dbaron: The spec defines when margins can collapse, and nothing says
they don't
dbaron: I think I would strongly like to define that the margins of
column spans don't collapse with margins of things in the
columns
dbaron: Then there's the question of can one column span's margin
collapse with another
dbaron: There's a bunch of text in the issue I haven't looked at
recently
fantasai: Morten posted a proposal, we don't have a strong
definition of the multicol layout model in the spec
fantasai: He proposes a model for exactly how the different
formatting contexts interact
fantasai: I think it makes a lot of sense. It gets us what dbaron
said, but does that by defining the multicol container as
being a BFC, and for it to contain column span and column
containers, which are siblings, and they are laid out in a
BFC, so the margins between spanners collapse
fantasai: but the spanners define their own BFCs so they don't
collapse with things in the columns
fantasai: It's quite straightforward and we should adopt it
florian: I believe we've previously resolved that does say the
margins between siblings spanners collapse, and that
spanners and content in columns do not
florian: at least in examples
Rossen: We could defer this to later on after people have had a
chance to read it
florian: or I suggest we resolve on spanners collapsing with each
other, but not content in the column
florian: but not on the mechanism to achieve this
florian: which we can do later
RESOLVED: margins between adjacent spanners do collapse
RESOLVED: margins between spanners and any other non-spanning boxes
do not collapse
CSS Text
========
word-wrap/overflow-wrap: break-word should affect min-content
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2682
summary: https://github.com/w3c/csswg-drafts/issues/2682#issuecomment-431503466
florian: We have 2 things. we have overflow-wrap:break-word
florian: which says that if the line is too long, apply line
breaking, if it still doesn't fit, break anywhere
florian: But it doesn't affect intrinsic size
florian: If you have text in a table cell that says “if I'm too long
wrap anywhere”, it has no actual effect because the table
cell is sized to the intrinsic size
florian: Same thing in flex boxes and some other situations.
florian: We should have had overflow-wrap:break-word affect
the intrinsic size
florian: However, Mozilla found it's not web compatible to do that
florian: Blink/Webkit have a proprietary switch, which does the same
thing as overflow-wrap:break-word plus it affects intrinsic
sizing.
florian: But it's on the wrong property, the word-break property,
(which is about CJK breaking and controls line breaking
all the time, not just during overflow)
florian: There is some web compat pressure to implement that,
but not an overwhelming amount, since even tho we've been
talking about this for a while, both Edge and Firefox have
thus far resisted implementing it
florian: Given that overflow-wrap: break-word should have done the
right thing, we should add a new value to 'overflow-wrap'
that does so
florian: Proposal is 'overflow-wrap: anywhere'
florian: We already have an 'anywhere' value in another line breaking
property, line-break
florian: 'line-break: anywhere' allows such breaks all the time;
'overflow-wrap: anywhere' would only if you need to break
florian: Maybe that will be enough and the web will slowly learn to
use that rather than the WebKit thing
florian: If it turns out not to be the case, we should have both,
rather than just breaks the property that otherwise makes
sense
eae: I agree with that, it makes sense to spec the right behavior
and we would support that
florian: I propose we resolve on adding overflow-wrap:anywhere, we
don't resolve on word-break:break-word, but only come back
to that if web compat forces us to
RESOLVED: Add an anywhere keyword to overflow-wrap
myles: Are overflow-wrap / word-wrap no longer going to be synonyms?
Rossen: No they are
Revisit text-align shorthanding text-align-last
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3117
fantasai: We noticed nobody implemented text-align as a shorthand
for text-align-last / text-align-all
fantasai: Wanted to check in with the WG to see if they want to keep
the spec as is
fantasai: Original behavior was they were separate properties,
depending on the impl there were different relationship
between the properties
fantasai: text-align-last only applied if text-align was justify,
in IE
fantasai: but in Gecko text-align-last applies always
fantasai: The discussion that led up to the shorthand was to improve
the ergonomics
fantasai: making it possible to set text-align-last on alignments
other than justify
fantasai: but also making it less likely that you would accidentally
have text-align-last continue setting your last line
differently from the rest of your text once you've
switched it to center or right
Rossen: You're tying it to IE's behavior?
fantasai: If we decide not to have shorthanding, it would be less
error prone to have IE's behavior than Mozilla's
fantasai: or we could decide to have the shorthanding
florian: The thing in the spec is based on WG resolutions
florian: There are subtleties when nesting bidi, different languages
florian: The spec handles that, but nobody implements
florian: I think the spec is good but only if it's going to be
implemented
dbaron: Is there going to be a compat problem if we implement this
in 2 years?
dbaron: given what exists today?
fantasai: If the text-align-last property is set earlier in the
cascade than the text-align property, then there's a
problem
fantasai: I think when we made this decision, I think we did some
kind of analysis and if people put both in, they tended to
put text-align-last second
fantasai: Don't know how true that remains, since that was a while
ago
florian: Seems plausible that the -last one come after
florian: in the meanwhile there's no interop
dbaron: Do all engines implement text-align-last?
fremy: Yes
florian: Yes but differently
<myles> https://caniuse.com/#feat=css-text-align-last
dbaron: If chromium were willing to change, others would be happy to
follow
dbaron: Changing without chromium risks people writing content for
chromium after the change
florian: Implementations aren't aligned with chromium today anyway
dbaron: Hard to know if this will be a problem or not
myles: I'd like to voice support for the shorthanding approach
fantasai: For now we keep the spec as is?
fantasai: Our goal is to get text level 3 CR by the end of the year
fantasai: which seems reasonable given the issues that are open, but
this is one of them
myles: You could always defer it
fantasai: text-align-last is already implemented so not having a
spec for it is a bit weird
florian: By reaching CR, we'll write tests and file bugs and they'll
get fixed, so it should be all great
koji: How does text-align-last differ in impls?
fantasai: The spec says text-align-last is a longhand of text-align,
but no impl of this right now
fantasai: Currently they're independent properties
fantasai: The relationship between the two varies per impl
fantasai: IE only honors text-align-last if text-align is justify,
and Gecko always honors text-align-last
fremy: We fixed that in the latest version of Edge
fremy: we didn't fix IE, we fixed Edge
Rossen: So Edge is closer to Firefox now
florian: There are more unimplemented values on this property that
will start to exhibit more different behaviors, shorthand
vs non-shorthand would do very different things
Rossen: I think as impls start to come on line with additional
support we'll discuss more of this
RESOLVED: close this issue no change
Allow letter-spacing to have unitless values like line-height
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2165
and https://github.com/w3c/csswg-drafts/issues/3118
fantasai: There are several related issues here
fantasai: One is this one, another is wrt text-decoration
fantasai: myles raised a similar issue on that spec
fantasai: Several places relating to text where we currently allow
lengths, ems are nice in these cases, you want
letter-spacing or whatever to be font size relative
fantasai: but they don't inherit as proportions of the font size
fantasai: They inherit as absolute lengths rather than a font size
fraction
fantasai: you probably also want to calc them together, so numbers
aren't great
fantasai: Percentages do fulfill this role in other places
fantasai: Other option is to add another unit like frs, that kind of
represent lengths
fantasai: But in that case you couldn't add 1px + 5%-of-font-size
fantasai: The problem with percentages is that right now
word-spacing uses them to mean the percentage of the width
of the space character
fantasai: it's also reasonable, and something that should inherit as
a relative thing
fantasai: We have absolute lengths, we have some kind of proportion
of width of space, and proportion of font size, and maybe
come up with some other things we'd want in terms of font
metrics
fantasai: This is an open ended question about how to solve this
value
fantasai: For letter-spacing, word-spacing, text-emphasis-offset,
text-decoration-width, ...
fantasai: that would allow having a proportion of the font size and
make it inheritable as a proportion
florian: The place where we have it now is line-height, as a
unitless number, which isn't great
jensimmons: Is it too late to use ems?
florian: Yes since they will resolve down to an absolute value and
inherit
florian: and it has been like that forever
florian: Continuing with unitless numbers is bad because of Typed OM
myles: This solution sucks, but don't know of others
TabAtkins: Don't use numbers for things that aren't numbers. For new
units, mint a new unit suffix, otherwise calc has troubles
florian: Is percent used in these properties for word-spacing only?
or in other places?
fantasai: So far the percentages are only used in word-spacing. The
only implementation is Gecko, and usage is very minimal
florian: If we're not stuck on that, switching the meaning of
percent, and separately having a length units for the space
width, that could be more consistent
jensimmons: So use % to mean percent of the current font size;
florian: Yeah
fantasai: We already have the infrastructure for calc() mixing
lengths and percentages and having them inherit as
percentages, so this would easily re-use that.
jensimmons: The other alternative is a new unit like em but different
fantasai: Yes
fantasai: Usability wise, percentages would be ideal here
fantasai: Would be great for line-height property, but might be a
lost cause :(
jensimmons: Would you suggest adding it to line-height?
fantasai: line-height is the only place where % calculates just
like em
dbaron: There are other places. font-size
dbaron: In general, we can describe computed values the way we want
to for percentages, and we haven't done that mostly for
length units
florian: I think I still stand by the proposal to use % for this,
and retire the use of % in word-space from its current
meaning, and introduce an sp unit to mean the width of a
space
heycam: Would it be weird that 'sp' wouldn't compute down to a length
like 'ch' etc.?
[florian/fantasai disagree over what 'sp' would do]
fantasai: I could see use cases where you want either behavior
fantasai: tab-size is an example where you might want it to become
absolute
fantasai: Right now we use bare numbers for spaces in tab-size
fantasai: Might want to have the tab size remain constant throughout
the document
florian: For tab size it's not sized in spaces, but spaces plus
letter spacing
florian: For that example it's not going to be that unit anyway
florian: I was thinking sp would work like ch
florian: so letter-spacing, word-spacing, text-decoration-width,
text-underline-offset -- have a % in all of those
<fantasai> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/word-spacing/
RESOLVED: Add a percent value to letter-spacing, word-spacing,
text-decoration-width, text-underline-offset that is an
inheritable proportion of font size
fantasai: For sp, word-spacing, the current behavior you do want it
to inherit as a proportion
fantasai: e.g. maybe you want to double the word spacing, or
collapse the word spacing to zero, or cut it in half
fantasai: and you want the proportion to inherit through
fantasai: so not sure if collapsing to an absolute length is useful
fantasai: So what we're missing here is the other type of unit
florian: We want another thing that behaves like %
florian: only for word-space?
fantasai: It might be useful for letter-spacing as well
florian: Let's bikeshed in the issue
florian: Investigate a bit more
fantasai: Confirm that Mozilla is ok with changing how they
interpret percentages on word-spacing?
dbaron: I'm ok with it
dbaron: It would be good if there were a resolution on what the
syntax for the thing we've already implemented is
dbaron: at the time we change the existing syntax to something else
Text-spacing is too strict
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/3229
myles: This is about text-spacing property, has a bunch of examples
that control spacing between script changes on a single line
myles: Desirable for mixed CJK and Latin on a single line
myles: Good typographic style says if you have a bunch of
ideographic characters then some Latin words, between those
two things should be a bit of extra space
myles: also things like because CJK punctuation tried to fit in a
whole em block there's usually a lot of white space
myles: Two punctuation characters next to each other is to push them
together
myles: This is a good thing
myles: The concern we have is that there are different typographic
design houses with different style guides
myles: and how much space to add between full width Kana vs a Latin
character, etc.
myles: So different design studios have different rules about where
they insert these spaces and how much to add
myles: We'd like to implement this property, but the definition is
very strict
myles: Lists which characters and how much space to add
myles: We understanding this came from jlreq, and that's a good
starting place, but since this is up to typographic
conventions of the platform you're on, it would be good to
loosen this for some wiggle room
myles: I've listed a few examples
florian: Without going through the examples, at the conceptual level
yes there are different opinions on spacing
florian: Some of these topics we can find agreement on, others not
florian: For people who don't care, it doesn't matter
florian: For people who do care, they will only turn it on if it's
predictable
florian: If they can't quite know what they'll get out of it,
they'll do it manually
myles: This is a property for changing general behavior, I
understand a particular publisher doesn't like the way a
particular impl or the whole web does it, and they may impl
it themselves
myles: but a ua should be able to improve the typography of the
entire web
astearns: If you loosen things, you have an inconsistency between
UAs, and authors are put in a bind
astearns: the problem you're pointing out means we need more
properties to change the way we deal with spacing to hit
those uses cases
astearns: so a publishing house could say this variation is the one
I want
myles: I don't think the proposal is contrary to that
myles: The thing that I'm aiming for is a way to have platform
dependent spacing
myles: Also having a way to have a specific well defined one, that's
great too
myles: Conceptually an auto value is distinct
florian: Could we keep the existing auto value as that? [...]
koji: I think I'm with myles in general. I agree with florian that
some people want exact typographic characteristics, but
currently we don't have anything
koji: Two things that people want. If we don't have either, better
to start with a looser definition
koji: If they say they really want some particular behavior we can
add some more strict definitions
florian: I think having an auto value would be nice for that general
case of 'I want better typo'
florian: I'm concerned that this will cause compat problems
florian: That's when you end up with 1 line in one browser and 2
lines in another
florian: I wouldn't be opposed to an auto value, but that is a
concern
florian: Make the existing values fuzzy doesn't sound great
myles: I share concern about web compat
myles: There would need to be an investigation phase
florian: Adding another value would be nice
florian: If we start changing in different browsers what they do
that sounds scary
myles: The question about whether it should be the default value, I
don't think we have information yet
florian: I suspect auto can't be default
fantasai: I would love it if auto did beautiful typography by default
drott: ...
florian: There are many things affected by this property. In the
French context, you have a space before a column, a narrow
non breakable space
florian: but not in markup
florian: This property allows you to inject the right kind of space
florian: You could give some flexibility to the browser, to choose
1/4em or 1/6em
florian: There's also things relating to collapsing white space
florian: e.g. in CJK punctuations
florian: the boundary between characters
drott: My question was how many values would we need
drott: to make it possible for the user to specify that
drott: within a run of the same script could be handle by opentype
drott: but how many additional ones would be needed
fantasai: The spec triggers the opentype features when the settings
are set
fantasai: You might want to be able to control particular spacing
operations, so we will use the right OT things, but it
won't do them automatically
fantasai: trimming/spacing controls depends on context
fantasai: and it crosses text runs in the same language
fantasai: OT can't do this for us
fantasai: but we can use OT to do the glyph transformations or make
full width be typeset half width for example
myles: So you're asking how many combinations are required to do....?
drott: One was 1/4 em ...
florian: The existing property have 15 keywords
florian: Not all combinations of them are valid
drott: For these 15, I'm trying to get an idea of how many lengths
you'd need to specify
drott: just to gage how many additional values you'd need
fantasai: If we're adding control over lengths, it would be in a
separate property, so you could switch the behavior on and
off without having to reset at every stage the length you
want to set
florian: Do we want to resolve on an auto value, which lets the UA
do whatever it feels like?
fantasai: The initial value is normal
fantasai: Happy with that or add an auto to do something
myles: Is there interop on what normal means?
florian: Yes, the initial value is what the web does today
florian: It's just not good typography
florian: For now, the auto value, isn't the default, since it's
different from what UAs do
fantasai: If you want to try having it be the initial value ...
florian: That's going to break every good typographic website
florian: If you do it on top of them doing it manually
florian: maybe the spacing between Latin and ideographic might be
web compatible?
florian: I suggest adding an auto and experimenting with it
fantasai: If they're experimenting to see with what the initial
value can do, may as well do it for normal itself
myles: Right now I think adding a new auto value is the best way
to go
RESOLVED: Add a new text-spacing:auto value, which is not the
initial value.
florian: I encourage looking at what subset of auto behavior could
move to the initial normal value
-- lunch break until 1pm --
Received on Tuesday, 13 November 2018 00:22:47 UTC