W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes Telecon 2019-03-13 [css-scrollsnap] [css-fonts] [css-grid] [css-lists] [css-multicol] [css-text-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Mar 2019 19:34:12 -0400
Message-ID: <CADhPm3vSj6+Wi=VqXaKhe8uyUPznqG2Mk0MTW9NMF-7NrBzNHw@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.
=========================================


Scroll Snap
-----------

  - RESOLVED: Publish updated CR for Scroll Snap

CSS Fonts
---------

  - RESOLVED: Void the previous resolution and close no change (Issue
              #3675: Font-family name matching requires full Unicode
              case comparison)

CSS Grid
--------

  - RESOLVED: Make the same result for min content sizing apply to
              automatic minimums (Issue #2674: Resolving percentage
              heights of grid items during min-content sizing)
  - RESOLVED: Change the algorithm take baseline from the first grid
              content instead of synthesize from first row (Issue
              #3645: Unintentional change to grid container baseline?)

CSS Lists
---------

  - RESOLVED: Go with fantasai proposal (option a) for initial value
              of counter increment (Issue #3686: Initial value of
              counter-increment needs to be something different from
              none)

CSS Multicol
------------

  - RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/3649
              (refer to columns not tracks)

CSS Text
--------

  - There is still concern that the proposed solution for issue #337
      (Segment Break Transformation Rules for East Asian Width
      property of A) relies on a unicode property that the unicode
      consortium isn't particularly maintaining. The counter argument
      is that the subset of properties this proposal creates will
      continue to be correct, even if the definition changes. A few
      working group members will reach out to unicode contacts to
      garner more feedback to lead to a decision.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0000.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Manuel Rego Casasnovas
  Fran├žois Remy
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Greg Whitworth (IRC Only)
  Fuqiao Xue

Regrets:
  Lea Verou

Scribe: dael


  astearns: We've got enough to go on
  astearns: Thanks everybody for calling in at the weird time
  astearns: Does anyone have any extra things to add or changes to
            make?

Scroll Snap republication
=========================
  github: https://github.com/w3c/csswg-drafts/issues/3721#issuecomment-471783264

  fantasai: Made some spec clarification to make implications easier
            to notice. Clearly editorial, asking for repub
  astearns: What about the issue from jonjohnjohnson?
  fantasai: That's filed against CSSOM View spec. If that needs
            clarification I didn't fix anything in there. I just fixed
            scrollsnap

  fantasai: Updated CR
  astearns: There is a change list and DoC?
  fantasai: There was only one comment which was mine. DoC seemed
            excessive
  astearns: Should have a changes list so when we repub people know
            it's one thing
  <fantasai> https://drafts.csswg.org/css-scroll-snap-1/#changes
  fantasai: Here it is ^
  astearns: Just editorial or any test changes?
  fantasai: No normative implications. Emphasizing points on stuff we
            agreed

  astearns: Comments on updating?
  <florian> I have reviewed the change and support it.
  astearns: I see florian supports
  astearns: Objections to Publish updated CR for Scroll Snap?

  RESOLVED: Publish updated CR for Scroll Snap

CSS Fonts
=========

Font-family name matching requires full Unicode case comparison
    (reconsider FTF resolution)
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3675#issuecomment-468238875

  astearns: Got feedback maybe resolution wasn't best
  myles: Anyone on the call not at F2F and has opinions?
  chris: I wasn't. I agree most impl do full unicode case folding and
         ascii only case folding will give odd results. Myles you said
         WK hasn't adhered
  myles: True on iOS and OSX
  chris: You sure it's a big performance regression? People are saying
         it wasn't
  myles: Haven't measured because haven't impl.
  chris: But you do have the function call
  florian: At the F2F mentioned the other function is not called
           anywhere in WK codebase
  myles: I don't have anything new that I didn't bring up. We've never
         had behavior and never had compat problems. Doesn't seem need
         to slow down browser.

  AmeliaBR: Main new information is that when we resolved it was based
            on other impl doing quick look and saying I think we do
            this but in issue people who know better say no we follow
            the spec and they're concerned about changing
  fantasai: We do have concerns from i18n as well
  chris: CSS does ascii only case folding for syntax but for this the
         font name can be anything and is usually localized. But most
         scripts don't have two cases
  florian: Mostly Cyrillic and Greek?
  fantasai: No because accented Latin is also outside ascii
  florian: I think in practice concern will be less accented Latin
           then Cyrillic
  florian: It's not that it will not happen, just more common to have
           problems in Cyrillic. Could be in all sorts of places

  astearns: Interesting there haven't been reported compat issues
            given this incompat in code bases. I wonder if people
            modify to work around this
  chris: Could be, it was interesting that Android matches on a
         Latin-only xml font database, so people munge the fonts names
         to Latin there
  dbaron: People use different fonts on different platforms so there
          may be a compat issue on other platforms
  myles: Would other browsers be interested in speeding this up in
         their impl?
  [silence]
  astearns: Given issue comments I doubt this is the case.

  fantasai: Given no one is seriously concerned about performance. We
            have existing impl that are aligned and it's the right
            thing to do from i18n view it seems we should not make
            this change and keep spec as is with full unicode case
            folding
  florian: Agree and at same time I would also understand if Apple
           didn't prioritize this
  <dbaron> I agree with fantasai as well.
  myles: Like I said we don't have compat issues
  fantasai: If we had interop on ascii only and there was performance
            concerns I would understand. But apparently neither is
            true so we should do the right thing
  chris: I agree. It would be interesting to know where there are
         compat issues, like actual fonts used on the web that give
         different results without the unicode case folding. We can
         punt that to i18n and request examples
  myles: Not sure if it's worth it, but we can do it
  chris: If there are no examples then it doesn't matter and impl
         might want to use simpler. If there are examples it might
         persuade you down the line where we didn't realize we were
         disadvantaging someone. Maybe there is a community with a
         problem, maybe there isn't

  astearns: myles are you okay reverting previous and close no change?
  myles: yes
  astearns: Objections to void the previous resolution and close no
            change?

  RESOLVED: Void the previous resolution and close no change

  astearns: If new information comes up we can look at it

CSS Grid
========

Resolving percentage heights of grid items during min-content
    sizing (review last fix)
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2674#issuecomment-465490328

  <fantasai> https://github.com/w3c/csswg-drafts/commit/534f79283a4687a5f0bc722baed5792e2c54433a
  fantasai: There's some sizing rules where we decided percentages
            resolve to 0 something depending on when you're tacking
            intrinsic sizes. Clarifies the 0 basis also applies for
            automatic min size so that it ends up being definite
  fantasai: Automatic min size is a derivation of min content sizing
            so this is saying same rules for min-content sizing apply
            to automatic minimum
  astearns: Reasonable to me
  astearns: Other comments or concerns?
  astearns: Objections to make the same result for min content sizing
            apply to automatic minimums

  RESOLVED: Make the same result for min content sizing apply to
            automatic minimums

Consider setting base sizes to growth limits when sizing under
    max-content constraint
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3646

  astearns: Discussed at F2F. Didn't conclude. Is there new
            information or kick to issue?
  fantasai: Kick to issue for a bit. jensimmons and rachelandrew
            wanted to think more and I need to fold in #3648 changes
            which are related
  <jensimmons> sounds good to me
  astearns: Anything else to bring up about this?
  astearns: I'll take agenda+ off

Unintentional change to grid container baseline?
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3645

  fantasai: Error I want to revert at least. What would we expect
            baseline alignment of grid with a single item in 2nd row.
            We can use the first item in the first row for where we
            derive baseline from
  fantasai: I think we should do the baseline of the first available
            grid item even if not on first row, but wanted to check
  astearns: Prefer FF behavior. Better to take baselines we have then
            punt
  astearns: Looking through comments to see if anybody disagrees
  astearns: Only thing Javier brings up is if there's no content in
            first track you can synthesize
  fantasai: If no content in grid we synthesize.
  fantasai: Question is if we have an empty row do we look at next row?
  AmeliaBR: When first item is it grid layout order?
  fantasai: Yes
  AmeliaBR: First item in DOM is in a different row we skip over that
            and focus on rows and columns?
  fantasai: Yes
  astearns: Looks like I was confused on rows and columns
  astearns: There's an actual difference in opinion between impl

  fantasai: jensimmons rachelandrew opinions?
  jensimmons: Not really

  astearns: If the first track is empty then is the design using that
            track for space?
  astearns: In which case does aligning grid on 2nd track baseline
            void that decision?
  fantasai: If you're using it for space, we've seen cases to use
            first track to make padding, seems reasonable to use the
            content of the 2nd row in that case
  astearns: First track is for padding if grid is not baseline align?
  fantasai: We have a grid with an empty first row and content in 2nd
            row. Do we treat this grid as not having baseline or do we
            take baseline from 2nd row. That's the question
  jensimmons: How would that effect sizing of first row?
  fantasai: Doesn't. Effects how that grid aligns with other content.
            If you have grid inside a table cell and another grid next
            to it
  rachelandrew: In that example 2nd row makes sense. It does seem
                using first row as padding is the common case. Trying
                to think if other cases
  <gregwhitworth> Agreed with fantasai and rachelandrew
  astearns: If you have 2 grids in adjacent table cells and you are
            using the first row for space in the first grid and both
            have a BG color so you can see the space added if those 2
            are not baseline aligned then the content in the first is
            pushed down by the amount of first row. If you do baseline
            align the 2 table cells the first grid's space is
            maintained and push table height up in FF case. In chrome
            case space is maintained and push table cell height down
  astearns: That's the case for this in a concrete case
  [mic problems with someone]

  astearns: I think it does make a bit more sense to take baseline
            from first available content in the grid. I don't know
            that it is something that is going to be used often.
            Probably an edge case that will not come up often
  jensimmons: I think it might come up. Not sure edge case. I can see
              real world use cases for this. Not 2 grid items in a
              table cell, but 2 grid items in a grid
  astearns: Or a flex container. Or if we get to baseline aligning in
            other cases
  jensimmons: Options is align second row with other grid or...?
  astearns: Options are at moment algorithm says you take baseline of
            content in first row and if there isn't you synthesize. So
            if first row is empty spec says you synthesize a baseline.
            Considering saying take first content in grid and use that
            for baseline
  jensimmons: Result of synthesization? Just make up a line? I guess
              yes
  rachelandrew: I can think of using baseline of first content item,
                that can be explained. You can say you haven't got
                content in the first track so we're using first item
                to work out baseline. Being worked out on something
                that doesn't exist is harder to explain. As someone
                who explains this stuff to people it's easier to work
                off first item that appears
  jensimmons: Lean that way too. I can see where people would make
              separate grids, put in a grid, and then align baselines.
              At this point you can't have an empty row with a visual
              thing. But if we get to where you can style grid rows
              there's a case to show on nothingness
  astearns: Will show if there's border or BG
  jensimmons: I lean toward do the first row with content in it. That
              makes sense as an author. I think that's what
              rachelandrew is saying
  astearns: Converging on take baseline from the first grid content
            instead of synthesize from first row

  astearns: Objections to take baseline from the first grid content
            instead of synthesize from first row and see how Blink and
            WK impl take to it?
  <jensimmons> I also think this makes baseline alignment more useful

  RESOLVED: Change the algorithm take baseline from the first grid
            content instead of synthesize from first row

CSS Lists
=========

Initial value of counter-increment needs to be something different
    from none (three proposals)
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3686#issuecomment-468098431

  TabAtkins: Discussion about what to do with initial value of counter
             to handle default list item. Few possibilities from F2F,
             but couldn't decide. dbaron helpfully wrote them.
  TabAtkins: Reviewing them I believe fantasai's approach is best
  TabAtkins: Proposal: if an element has display list item default
             list item counter is incremented unless counter increment
             already says something about that item. If you want to
             pause you can set counter-increment list item 0 and it
             will work
  TabAtkins: dbaron proposal is we can pretend it always adds a
             counter increment of 1 and you just stack them if you
             repeat. So if you want to pause count you would say list
             item -1. Canceling out is useful for impl value attribute.
  TabAtkins: I don't like that because it looks a lot more confusing.
             A -1 making it not increment is interesting. fantasai's
             proposal is most similar to UA impl list via UA styles.
             Still some magic but for most part it seems UA generated
             and you can interact with it in the same way
  TabAtkins: I think we should go with fantasai's proposal and I can
             write it into the spec
  AmeliaBR: This is the version where if you want to set the list item
            to a spec value you have to explicitly say 0 increment on
            the list item?
  TabAtkins: Yes if you're doing this by yourself. You use counter-set
             to set to a value and then set the 0. Works the same as a
             normal counter you define on your own
  <fantasai> Original thread on this issue , from 2007:
             https://lists.w3.org/Archives/Public/www-style/2007Oct/0100.html

  astearns: dbaron opinion?
  dbaron: Fine with fantasai proposal
  astearns: Objections to going with fantasai proposal for initial
            value of counter increment?

  RESOLVED: Go with fantasai proposal (option a) for initial value of
            counter increment

CSS Multicol
============

pseudo-algorithm refers to "track size", terminology not already used
    in the spec
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3649

  rachelandrew: Reading spec with authors. This is the first time
                track size mentioned in spec. Aim was to unify how
                sizing works but tracks isn't useful for multicol.
                Wanted to bring up since it was added with a
                resolution. I put sample wording in the issue
  astearns: Not changing effect of resolution, just the term?
  rachelandrew: Yeah
  florian: I've looked at that and if you assume tracks=columns it's
           clear but if you leave the two terms it confuses everything
  astearns: Objections?
  <fantasai> sgtm

  RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/3649
            (refer to columns not tracks)

CSS Text
========

Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/337

  fantasai: Leftover from F2F so probably get rid of
  astearns: This is definitely a better in the room discussion. Don't
            know if we want to wait 3 months
  fantasai: I'd like to get text to CR before that but this is main
            issue blocking CR
  astearns: How do we get to resolution?
  fantasai: I think current text is fine. I don't know if anyone has
            issues. I think myles is not happy
  myles: Yep
  fantasai: Dunno where to go from there
  florian: Support current text.

  astearns: myles do you have a suggestion to improve?
  myles: Not concretely but using a solution from unicode where
         experts agree won't work well and doesn't have semantic
         meaning seems wrong direction. We would work with unicode to
         come up with classes we need
  florian: We're the only user of that thing b/c relates to how css
           and html wrap lines or source code. So if we're not doing
           effort they're not either. Solving this usefully for most
           cases is sufficient to be useful. I hear what you're saying
           but it seems like this is the perfect as the enemy of the
           good
  myles: We're using this to determine where to unbreak lines. Knowing
         if character or parts of scripts use spaces is useful for any
         text editor. And I think that, you're right that perfect
         enemy of good is not the best way to create the web but I'm
         worried we'll come up with a busted solution and be stuck
         forever
  florian: Not too worried because we're not trying to solve entire
           problem but instead a useful chunk. I think the defined
           part is safe. If we look for areas of unicode we can find
           where we should have used more but we're using a safe
           subset. If unicode does better in the future it will
           include what we defined
  myles: If we encourage authors in cjk to add new lines in source
         code we need interop
  florian: Oh yeah, we do. The part we have is safe to get interop on.
           What I mean is that I don't foresee given the subset we're
           defining I don't see us having to remove from it. Having to
           add to it maybe, but not remove.
  myles: If we're considering this solved and say to authors add line
         breaks where you want it will be wrong in many places and
         those in the future will change when we have better solution
  florian: That's the thing I think will not happen. If we later
           expand we will create new places where they can break, but
           the places we're offering here will stay. If you find such
           a thing please call it out. I think we will find other
           places in unicode where we can add breaks, but I don't
           think we'll remove from the current list. So there's no
           risk in that sense
  astearns: Risk is limited to if the current attempt at fixing a
            subset is a true subset of the eventual good solution or
            not
  astearns: I don't have a way of evaluating if what we have now is a
            true subset

  astearns: One question - does anyone know if current proposed rules
            are enough for a native Japanese author who has no idea of
            anything to do with unicode and they're just writing
            Japanese is there a set of rules for this author that
            would make sense? Can we tell them you can put line breaks
            where you want or is it complicated?
  florian: For Japanese it's mostly straightforward when writing text.
           If you're doing dingbats in the middle it gets weird. In
           text it's fine. Dingbats isn't Japanese specific, they just
           get weird.
  astearns: I have not read whole thread, it is long. Have we had
            anyone from unicode give a thumbs up that this is a safe
            subset?
  florian: Had conversation with unicode but mostly off topic because
           they didn't understand what we were trying to do
  myles: That convo the expert didn't comment about the specific
         modification in the spec right now, but said properties these
         modifications are based off of....I don't want to put words
         in their mouth but they said it was fairly broken
  fantasai: And they broke it even more recently
  myles: Seems like the wrong thing to base on
  fantasai: We're working around that by ignoring a subset of
            characters they decided to change

  fantasai: If we're gonna do anything like this, this is the set of
            properties. Alternative is ask unicode for a new prop
            which seems unlikely
  myles: Not necessarily just this purpose. Knowing if char are part
         of a script that uses space as line breaks is useful. Spec
         says [reads]
  myles: It just seems like we're patching a broken system and we
         should try and solve properly
  florian: Not just special cases. A large chunk of the spec text is
           the necessary conditionals to make sure we're in the right
           language. This new fabled unicode thing wouldn't know what
           lang you're in. That part would stay in CSS. If we're
           keying off [missed] it could be better from unicode, but
           keying from language cannot
  astearns: Agree with myles that I'm a bit worried about referring to
            a thing in unicode that they want deprecated and don't
            care enough to prevent it from having changes. If this is
            something unicode is not interested in keeping stable we
            shouldn't reference it
  florian: Therefore we don't solve?
  astearns: We work with unicode to come up with something they want
            to maintain and contribute expertise so we can come up
            with better handling that's maintained and can rely on
  florian: It's not marked as deprecated. It's in the spec they're
           theoretically maintained and they're doing a bad job of it.
           We can start paying attention and raise issues. Their
           opinion is that in current shape it's not useful, but it's
           still in the spec
  astearns: This will need to kick back to the issue for discussion.
            I'll see if we can get Ken to engage on the particular
            problem we're trying to resolve
  fantasai: Maybe reach out to other unicode people too
  astearns: Suggestions on who?
  fantasai: myles had Apple's contact. We've got other people from
            unicode. I'll try and reach out
  astearns: I think that's where we'll leave this

  astearns: Thanks everyone for calling and we'll talk next week
Received on Wednesday, 13 March 2019 23:35:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 March 2019 23:35:12 UTC