W3C home > Mailing lists > Public > www-style@w3.org > November 2018

[CSSWG] Minutes Lyon F2F 2018-10-22 Part II: Multicol, CSS Text [css-multicol] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 12 Nov 2018 19:21:53 -0500
Message-ID: <CADhPm3vKHeptEYc8dHqi1Sz68Zsr544=fXb6_qKkGXCrFk42Vg@mail.gmail.com>
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.


  - 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
  - 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

CSS Text

  - RESOLVED: Add an 'anywhere' keyword to 'overflow-wrap' (Issue
  - 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)


Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: heycam


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
  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
  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
  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

  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
  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
  florian: Earlier today we added properties to opt out of this problem
  rachelandrew: At the moment the behavior is not what anyone would
  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
  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
  florian: The spec is vague enough to read it that way
  <fantasai> I like Morten's proposal in
  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
  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

  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
  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
  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
  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
  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
  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
  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
  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
  fantasai: This is an open ended question about how to solve this
  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
  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
  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
  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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:11 UTC