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

[CSSWG] Minutes Telecon 2018-12-12 [css-grid-1] [css-text-3] [css-fonts-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Dec 2018 20:14:53 -0500
Message-ID: <CADhPm3sinNYw9a6E=UafLM1EdUQA+atZFSgahafAzvMzKSA1_Q@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.
=========================================


Upcoming Telecons
-----------------

  - The group will have a call on 19 Dec, but not 26 Dec or 2 Jan.

Grid
----

  - RESOLVED: Return computed value for getComputedStyle() for these
              properties [grid-row-start/etc] (Issue #2681)
  - RESOLVED: Fully specify the first 2 bullet points and leave it at
              that for this level (Issue #3201)
      - Bullet points:
          - Check interpolation type per track, rather than for the
              entire list, before falling back to discrete. I.e. a
              length-percentage track can animate between two values
              while an adjacent auto track flips discretely to
              min-content.
          - Allow discrete interpolation of line name changes
              independently of track sizes.
  - RESOLVED: Use the normalized value to serialize
              grid-template-areas (Issue #3261)
  - The plan is to request republication of Grid next week so anyone
      interested in review should look over the spec.

CSS Text 3
----------

  - myles and anyone else interested will review issue #337 (Segment
      Break Transformation Rules for East Asian Width property of A)
      for discussion on next week's call.
  - RESOLVED: Publish a new WD of Text L3

CSS Fonts 4
-----------

  - The proposal to add an @partial rule to serve as a way to
      overwrite a parts of an @rule (details here:
      https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-442167124 )
      was interesting to the group, but there needs to be more use
      cases to argue that there is a larger need that justifies this
      change.
      - Either way, the original use case of being able to override
          some values on the @font-feature-values

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0016.html

Present:
  Rachel Andrew (IRC Only)
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Manuel Rego Casasnovas
  Florian Rivoal
  Alan Stearns
  Lea Verou

Regrets:
  Chris Harrelson
  Nigel Megitt
  Jen Simmons
  Greg Whitworth

Scribe: dael

Upcoming Telecons
=================

  astearns: Let's get going. Does anyone have any extra agenda items?
            We'll do publish text 3 after item #4
  astearns: My extra is, is there anyone on the call that will not be
            able to make 19th Dec or 2nd Jan that hasn't already
            mentioned it?
  chris: I won't be able to.
  leaverou: Me neither.
  Rossen: Probably not the 2nd. 19th is fine

  astearns: I'm inclined to meet next week, but not the 2nd.
  astearns: How does that sound?
  <Rossen> sgtm
  myles: Great

Grid
====

gCS() of grid-row-start/etc properties should return used values?
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2681#issuecomment-396441751

  fantasai: We discussed and resolved to accept the change, keep issue
            open, and don't do edits until implementation commitment
  fantasai: Currently these properties return computed, but authors
            pointed out that there is no way to get used.
            Straightforward way as gCS() to return that value.
  fantasai: We decided it's a good idea, but no one agreed to
            implement. So WG said we agree but won't put edits in.
            That's from the end of May. I wanted to check where we're
            at now. Is that something anyone is interested in impl?
  astearns: Mats said there could be performance issue in returning
            used when call is made

  fantasai: The answer is deafening silence so I'll take that as a no
  florian: How do we make sure we don't forget?
  fantasai: There's a note in the spec
  astearns: Saying we could make change if there's implementor
            interest?
  fantasai: Something to that effect, yeah
  <fantasai> note
https://github.com/w3c/csswg-drafts/commit/77b8f93eb5b30c408bdd8ca91e4d4d61b3605570

  astearns: Alternative is not to use used and close off this. Find
            some other way to solve this problem.
  fantasai: Right, we'd need a new API
  astearns: Not hearing implementation interest.

  astearns: Objections to not returning the used value in gCS for
            these properties?
  Rossen: Returning computed values always?
  astearns: Yes
  astearns: New resolution that we return computed value for these
            properties in gCS
  astearns: Objections?

  RESOLVED: Return computed value for getComputedStyle() for these
            properties

Interpolating track listings
----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3201

  fantasai: How do we interpolate track listings. Current definition
            is basic, there are options to make it nicer
  fantasai: Asking WG what do they want to put in here.
  fantasai: I've tried to ping people for opinions but I'm not getting
            info

  TabAtkins: The templates have a lot of different information and
             being inconsistent in one part means you have to do the
             whole thing discretely. Options in issue for level of
             granularity. More fine then one difference makes thing go.
  TabAtkins: 3rd point is the only no go to me. All others are
             reasonable to me if someone likes them
  astearns: There is reasonable to TabAtkins. There's also willing to
            implement. Do we have both?
  TabAtkins: I'd have to ping Igalia folk.

  rego: I think we don't have support for animations on these
        properties in blink
  fantasai: What would you like spec to say?
  rego: I don't know how complex the different options will be. We can
        have something better here, but not sure how it can be done
  fantasai: Okay. I think Mozilla is in process of implementing this.

  Rossen: Is the 3rd option...
  fantasai: The options are checkboxes, not radio buttons. Just to be
            clear
  Rossen: Trying to figure out what Brian was talking about in terms
          of current differences between Gecko and Blink and his
          preference for less granular fallback
  Rossen: Looking through options it sounds like if we allow discrete
          independent of tracks we solve this. They both sound fine
  fantasai: I would like this closed by next week
  Rossen: I'm trying to figure out implications of 3rd. If we need it
          at all. Since we have Igalia who is interested in trying
          that in Blink perhaps we can try and resolve now. Or push to
          next week. Either is fine.
  Rossen: I'm trying to tease apart technical implications.
  rego: We can discard the 3rd one. That one property depends on
        another doesn't seem good idea. Other 2 I don't have opinion.
  Rossen: I think the first 2 are straightforward and doable. 3rd I
          have reservations.
  Rossen: If this is acceptable for now we can try and do that.

  Rossen: fantasai is the idea we want all 3?
  fantasai: The idea is we want this defined.
  Rossen: Good. Take one by one? I think first 2 are
          non-controversial. 3rd we can leave it or fork it
  fantasai: We can resolve to do first 2 and not 3rd. These are the
            options I can think of we have to decide yes/no on each
  astearns: And 3rd is something we can add later if it proves
            feasible.
  fantasai: Prob possible
  Rossen: Good to see what that 3rd option blocks in terms of use
          cases. First 2 will solve a lot of use cases. We can wait
          and see if 3rd is required.

  astearns: Proposal: Fully specify the first 2 bullet points and
            leave it at that for this level
  astearns: Objections?

  RESOLVED: Fully specify the first 2 bullet points and leave it at
            that for this level

How to serialize the strings in grid-template-areas?
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-446018130

  <fantasai> https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-436830050
  fantasai: This issue is well illustrated by ^ comment
  fantasai: grid-template-areas takes a series of strings and assigns
            names to different areas. When re-serializing that back
            out do we normalize things that are equivalent like
            compressing whitespace or do we return original string
  TabAtkins: Already not returning original, we have compressed
             whitespace. It's how much compression is okay. Should we
             do more tracking of original author like keeping number
             of dots in the slot

  myles: Can't imagine an impl that stores original string
  Rossen: Make it available to things like dev tools. It's there. Not
          sure if it's required and useful. I think that's the
          discussion
  TabAtkins: 2 comments above linked eric made a table of who returns
             what.
  <fantasai> table
https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-435698461

  astearns: One argument to normalize is to make it easier for script
            to parse. Handling string as spec they have to impl
            browser's normalization to get useful information
  emilio: Other hand this is only string that would get normalized.
          All others we just store and return the string. This is
          special
  Rossen: What's an example of other properties?
  TabAtkins: Every other property that takes string takes text or a
             name. This is one place where it's a string for
             non-string purposes
  <dbaron> I think there might have been one other case recently where
           we did normalization inside a string...
  <dbaron> (or maybe it was this one)
  Rossen: That's why asking for example. This is the only snowflake
          where we're defining behavior and not something simpler
  Rossen: I think current normalized format seems reasonable
  emilio: Arguments for both. Either you make it easier for script to
          parse it or just reserve right thing useful for editors.
          Don't have strong preference, but we need interop
  Rossen: Not sure what you mean by editors. WYSIWYG type things are
          using script APIs so that would be also easier
  myles: Another axis is for an impl [missed]
  myles: This is speed vs memory trade off. If don't store original
         you can build it but that's slower

  rego: On the dev tools or the CSS editor you can set one thing and
        after it's applied you get something different. That's an
        issue reported in chromium. When you use repeat we're only
        returning computed values because we're not storing. That's a
        similar issue
  Rossen: Your point is right on. Had this discussion at length with
          repeaters. I had a similar argument for keeping normalized
          computed for same purpose so you can represent a repeat.
          Consensus at that point is if you're building an editor you
          have enough source information to rebuild that knowledge and
          use the used values to infer what engine processed.
  Rossen: I think consistency is something we should value between
          repeat and this one. In which case we'd have to stick with
          normalized version

  astearns: emilio are you back?
  emilio: Yes, I'm fine with whatever decision we take. Rossen's
          argument is fine

  astearns: Proposal: Use the normalized value to serialize
            grid-template-areas
  astearns: Objections?

  RESOLVED: Use the normalized value to serialize grid-template-areas

Publishing
----------

  astearns: Was this a grid issue sweep for publishing?
  fantasai: Not yet, but hoping by next week. If interested in review,
            these edits need to go in and there's one or two items
            open with small details
  fantasai: There's 2 significant issues with auto-sizing which will
            need to remain open. Everything else should be able to be
            closed over next few days and I'll compile DoC
  astearns: Please look at grid

CSS Text 3
==========

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

  fantasai: This issue started as being about using [noise issues]
  fantasai: Using language information for doing break transformation.
            As I edited that in I ran into problems around emoji.
            They're wildly inconsistent about which characters are
            which East Asian Width and that's what we use to determine
            if line break is transformed
  fantasai: To work around that we're taking a subset of emoji with a
            width of n or w and treating as ambiguous
  fantasai: This issue is about if it's okay to make that change. If
            we don't characters like smile face has one behavior
            around line break and grinning face has a different
            behavior
  <fantasai> https://unicode.org/cldr/utility/character.jsp?a=1F600&B1=Show
             vs https://unicode.org/cldr/utility/character.jsp?a=263A&B1=Show
  fantasai: Sent email to author of East Asian Width spec to ask why
            it's inconsistent and they said they don't recommend this
            for emoji and use the emoji property so that's sorta what
            we're doing
  <chris> It sounds like Unicode spec should be fixed

  astearns: I'm not clear on koji's comments. Seems he's against. His
            last comment about troubles win over benefit
  myles: Is email to unicode guy public?
  florian: No
  myles: Would love to read
  florian: I'll check with him before forwarding
  florian: Not sure I understand koji either. We need to define
           somehow. East Asian Width of unicode is messy so I'm not
           going to be surprised if we come back. Pushing back means
           leave undefined or what?
  fantasai: [reads unicode email]
  myles: Did we explore emoji related properties?
  fantasai: That's what we did here.

  astearns: Divining koji's intent. "Even though there are cases it
            looks strange it's interop, right" So is there interop
            behavior?
  fantasai: Not sure how interoperable this set of rules are. Mozilla
            implemented previous line break transformation and not all
            impl had. I do think case of line break transformation in
            emoji I don't think we have a web compat problem if we
            make an exception. I think we get weird results either way.
  fantasai: Purpose of transformation rules is to make it easier to
            format source code of doc rather then put all text that
            can't have spaces on one line. If rules are unpredictable
            that's not helpful. Should treat all smileys same.
  florian: I checked, there is no interop
  florian: And that comment was about processing of line breaks
           entirely
  astearns: "that comment" being which?
  florian: Suppression of space introduced by line break is done by FF
           and not by Chrome.

  astearns: Given all this I think remaining question is if anyone is
            interested in implementing this change
  Rossen: It sounds like koji is not interested in implementing based
          on comments
  florian: I don't get if he disagrees with implementing this feature
           in this way or if he doesn't want to implement the entire
           feature.
  florian: Given Chrome doesn't impl feature and I can't tell if he's
           against implementing...
  myles: I won't implement until I do another pass through spec and
         try and understand
  Rossen: Try to cover when koji is on?
  florian: Possibly. Is everyone up to speed on this feature in the
           first place?
  astearns: I'm not sure a quick summary on the call is right. myles
            is going to look through spec to get up to speed. Maybe we
            leave this open. It's in the spec and we have issue with
            intent to keep in but leave it to review and raise
            objections.
  astearns: I know we just closed an issue where we left it in that
            state for 6 months but coming back in Jan might let people
            get up to speed
  fantasai: Or next week
  myles: I could have something to say by next week
  astearns: Let's leave to next week. I'll ping koji to clarify his
            comments

Text 3 publication
------------------

  astearns: Publish now or leave until next week?
  fantasai: I think we should do it now.
  astearns: We did a CFC so most up to date is good
  astearns: Objections to publishing a new WD of Text L3?

  RESOLVED: Publish a new WD of Text L3

CSS Fonts 4
===========

font-display says it's valid in @font-feature-values but it isn't
    an at-rule
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-442167124

  TabAtkins: A while back got a request to override font descriptor
             for fonts they don't control. Specifically Google fonts.
             Google fonts control that and due to caching don't want
             arbitrary things in there. Idea is add font-display to
             font feature values which kinda adds additional
             information and we can expose that
  TabAtkins: Right now font-feature-values doesn't take descriptors.
             Needs minor spec edits for that.
  TabAtkins: myles objected because seems ad hoc. We want to define
             additional font-face, but they cascade atomically. Rather
             then trying to come up with special fix for this one
             problem we thought why not try and fix the general
             problem and have a way to explicitly extend these @rules
  <myles> i didn't "object"
  <myles> just said it would be a shame if we did it
  TabAtkins: In thread had proposal for @partial rule that looks like
             an @rule where partial is the first ident. Whatever is in
             there is matched with the appropriate @rule and override
             what's in it with the partial. @partial font-face and
             then put the descriptor. Font family or a weight or what
             have you. Changes the font display value of font-faces
             loaded from another source
  TabAtkins: Only a handful of atomic cascade now, but this lets you
             handle that override case
  TabAtkins: Proposal in thread if we want it. Probably a new WD,
             doesn't fit in Fonts spec. I'm happy to edit and pursue
             if people are interested, but want interest before more
             time

  leaverou: How to determine which @rule it overrides?
  myles: The way this would have to work is each @rule has to opt in.
         By default none get a change and we opt in @rules. When it's
         opted in it would have to spec how the partial rules match
         with the base @rule. For Fonts there are 3 descriptors that
         would match, different for other @ rules
  TabAtkins: Font-family has to match and the partial has to be equal
             to or less restrictive match on style, stretch, and
             weight descriptors.
  TabAtkins: If you only want the bolds you can specify that, or you
             can allow for everything
  TabAtkins: Defined by each @rule when it claims I'm allowed to be
             extended. Rules are ad hoc for what the @rule does

  chris: I agree with this belonging in separate spec. Also have
         questions on how matching works. I understand how it works
         for each @rule differently, but I'd like a definition that
         says see each @rule for matching and there's a common term
         the @rules can refer to.
  chris: Seems generally useful, but I'd like more examples and where
         it won't work, like I assume not on @supports
  <fantasai> The contents of @supports already cascades
  chris: I think it's great, it's really interesting
  <chris> kind of like inherit applies to non-inheritable properties,
          which is also a bit weird :)

  dbaron: This feels like it's a confusing mechanism to me. Applies to
          some but not other @rules. Applies to those that don't
          cascade and turns them into cascading @rules
  dbaron: I think it's confusing enough that some do that and some
          don't. What TabAtkins said about @font-face where it
          interacts differently also sounds weird and confusing
  <fantasai> +1 to dbaron
  <leaverou> +1 to dbaron as well
  dbaron: I feel it might be better handled as extensions to each
          @rule that needs this mechanism. Feels like a variant, not a
          new @partial rule
  TabAtkins: That's what it is, I'm just unifying it under one name to
             be recognizable. The stuff after the @partial is what
             that @rule wants to do its extension grammar with
  chris: I think as unified as possible on extension mechanism is
         better than duplicating half the @rules
  myles: That's the direction I was going to mention
  myles: 2 pieces, one to open a closed block and add stuff. Then
         there's the specific idea of the fonts problem where
         different people want to change different parts.
  myles: Such a general solution would solve this use case. I don't
         think this use case is sufficient for this complicated thing.
         If there are other use cases the combination of them could
         motivate.
  astearns: As long as solutions are generalizable. I'd like to see
            other rules we'd want to open and see if enough similar.
            I'm a little scared with each rule can define how
            overwritten with partial rule
  TabAtkins: All reasonable.

  TabAtkins: The particular use case for fonts is strong. I'd like to
             address that. If we're not going for general until we
             find more things, I'd push to solve this use case
  myles: Rather than giving up I think somebody should do research to
         see if there are use cases. We're asking the question, not
         answering it
  astearns: I think general solution merits a bit more work. Will need
            non-font use cases so we can evaluate general solution
            outside this thing that needs to be solved. Agreed we need
            to solve this and we should take time to see if general
            solution is the way to do. More specific @rules is a rats
            nest we've added to for decades and normalizing would be
            good
  fantasai: I don't think a generic rule is normalizing anything.
            Agree with dbaron that if we're going to do it...we might
            decide on a specific syntax, but the @rule should be named
            after its @rule and not be generic
  TabAtkins: I don't care about @partial font-face or
             @font-face.partial I just want to see partials as a thing
  <myles> @partial font-face @partial-font-face @font-face-partial
  <myles> @font-partial-face ????
  <myles> @key-partial-frames
  TabAtkins: Let's look at use cases, see if we can find decent ones
             for other cases of extension. Maybe there's a good reason
             to extend something like keyframes.
  astearns: Alright. Sound good to everyone?
  astearns: Alright, thanks.

  <leaverou> Besides use cases, I'm also a bit concerned that we are
             introducing a mechanism to override that is so completely
             different than the cascade and completely breaks with
             reordering. I was wondering if we can somehow "match" the
             defined font-face rule and override it in a more
             cascade-like manner
  <fantasai> +1 to leaverou's comment about making sure this behaves
             like a cascade
  <astearns> leaverou: can you add your comment to the issue?
  <leaverou> astearns: ok!
  <myles> leaverou: i think you're right
  <myles> leaverou: i've ranted about this before, one of the biggest
          problems with @font-face from an implementor's point of view
          is that it is trying to handle the things that are already
          handled by selectors and properties
  <myles> leaverou: implementing a second cascading system that's
          separate than how selectors would be a disaster
  <myles> leaverou: you are soooooo right.
  <leaverou> Ok, comment posted :)
https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-446683982

CSS Inline
==========

Should first/last baseline values of `vertical-align` belong to
    `alignment-baseline` or separate longhand?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/861#issuecomment-408323378

  fantasai: Issue is scoped, but don't know how to make decision. I
            don't have arguments in favor of either version.

  astearns: That's it for the week. We'll meet next week. Thanks
            everyone for calling in.
Received on Thursday, 13 December 2018 01:15:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 December 2018 01:15:51 UTC