W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minute Telecon 2017-08-16 [css-sizing] [css-align] [css-fonts] [css-text] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Aug 2017 20:58:45 -0400
Message-ID: <CADhPm3s+=vPd91MwZy2fPFqa6ByHCjemeks3f+1Sm=ygZNENbA@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.
=========================================


Intrinsic size of replaced elements incorrect
---------------------------------------------

  - RESOLVED: Close the issue (https://github.com/w3c/csswg-drafts/issues/794)

Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------

  - fantasai will make a blog post to get feedback on this issue
      (https://github.com/w3c/csswg-drafts/issues/1611 )

Fonts
-----

  - Myles wasn't on the call so all resolutions are pending his
      review and chance to object.
  - RESOLVED: Descriptors will be called color-<integer>
  - RESOLVED: Define family without leading 0s
  - RESOLVED: Move CSSFontFeatureValuesRule to L4 Fonts
  - RESOLVED: Move the font-language-override property to fonts L4
  - RESOLVED: Property name is font-variant-emoji (Issue 1092)
      - The values for font-variant-emoji will continue discussion
          on github. The options raised on the call were:
          - monochrome | chromatic
          - symbol | graphic
          - plain | rich
          - plain | graphic
  - RESOLVED: Close issue 1144 no change

Definiteness of flex items' main size depend on flex-basis's
    definiteness
------------------------------------------------------------

  - Edge & Firefox will review their code in order to discuss this
      topic next week.

Baseline self-alignment may affect the intrinsic size contribution of
    the alignment subject
---------------------------------------------------------------------

  - fantasai requested review of her edits for this issue (edits in
      green): https://drafts.csswg.org/css-grid/#algo-content

Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------

  - The group agreed that the shorthand would be good, but shouldn't
      be called 'size'. However, there wasn't time to come up with a
      different name.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Aug/0016.html

Present:
  Rachel Andrew
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Anton Prowse
  Melanie Richards
  Jen Simmons
  Geoffrey Sneddon
  Lea Verou
  Greg Whitworth

Regrets:
  Rossen Atanassov
  Brad Kemper
  Alan Stearns

Scribe: dael

Spec Rec next steps/blockers
============================

  Chris: Let's go
  Chris: Any added agenda items?

  Chris: Anything to report?
  Chris: I didn't see an email. If anyone has anything to say?
  [silence]

Intrinsic size of replaced elements incorrect
=============================================
  github: https://github.com/w3c/csswg-drafts/issues/794

  fantasai: There's a definition in the sizing spec about what the
            min and max content size of images are. We defined to
            account for sizing constraint in opposite axis. We're
            defining by reference to css 2.1
  fantasai: dbaron wanted these keywords to represent actual
            intrinsic size. I spoke with him and he said given the
            way impl behave in grid he's unhappy about defining it
            that way but it is okay. As far as the definition dbaron
            wants we can add another set of keywords if authors want
            to express that.
  fantasai: Seems unlikely as an author want, but might be useful
            for Houdini things.
  Chris: dbaron?
  dbaron: I think that's a reasonable summary.
  fantasai: If everyone is happy with the state we can close as
            we've defined the sizing.
  Chris: Objections?
  Chris: Anyone need time to think?

  RESOLVED: Close the issue

Should last-baseline's fallback alignment be safe or unsafe?
============================================================
  github: https://github.com/w3c/csswg-drafts/issues/1611

  fantasai: We discussed at F2F, wanted more feedback. I don't think
            we got any.
  fantasai: We need feedback from authors to know if there's a
            reason to do one or the other. Implementor-wise either
            way is doable.

  Chris: How do we plan to solicit that feedback? Twitter poll?
  fantasai: I feel this is a niche case that's hard to describe in
            twitter.
  fantasai: If you were to have a bunch of last baseline aligned
            items that are taller than the row they're in, would you
            want them to break the last baseline alignment or
            overflow to the top?
  fantasai: We understand, but that's hard to convey.
  Chris: It needs a blog with illustrations. Does anyone want to
         write such a thing?
  <tantek> blog post + illustrations > twitter poll
  Chris: As a group we're bad at getting high quality user feedback.
  fantasai: We've tried and largely it's no response. I can write a
            blog post on our blog. We don't have a commenting system
            that's functional. I can use css3.info as commenting.
  <tantek> hey I can help with the functioning comment system, if
           someone wants help with their blog
  <tantek> we have standards for that in #social now :D
  Chris: Sure. It can also be linked to and tweeted.
  Chris: Anything else to say?

  ACTION fantasai make a blog post to get feedback on
         https://github.com/w3c/csswg-drafts/issues/1611
  <trackbot> Created ACTION-860

  <rachelandrew> re: author feedback I think it is hard to get
                 feedback on stuff if authors can't think up a use
                 case for the thing - I'd write about the fallback
                 alignment but I've not come up with a situation
                 where I might end up in that situation. I try and
                 write these things so people think " I might need
                 to do that and here is a problem I can see".

Fonts
=====

@font-palette-values uses illegal integer descriptor names
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1523

  Chris: Is Myles on?
  TabAtkins: I can summarize the issue I think.
  TabAtkins: This is about numeric descriptors? Yeah. Per css syntax
             you can't have numeric property names. It's not
             necessarily a problem to change, but it's not 100%
             clear we want to vs using a name that is an ident.
  TabAtkins: I don't have strong opinions, but this doesn't parse
             successfully right now.

  Chris: There was discussion on that earlier today. Suggestion
         is...the thing that says the number of palette entries is a
         uint16. Is there a way to declare the pattern?
  TabAtkins: Same as custom property. Defining a family of
             descriptors is what's needed here. There's no way
             around that.
  Chris: Could you give the syntax for that?
  TabAtkins: It's not anymore tricky than variables where I say use
             the pattern for the name. --* where * is anything
             following restrictions. It's a number-* and we put in
             restrictions and prose.
  TabAtkins: That's orthogonal because no matter what we need to
             accept an arbitrary number of descriptors. However,
             current syntax per spec doesn't parse.
  Chris: That's the worst problem. I'm assuming no one is arguing to
         change syntax for numbers. I've seen people argue against
         that.
  TabAtkins: Myles says leave as number and change syntax spec.
             That's fine, but it needs to have full agreement of
             implementors. Or should we go back and say make these
             an ident family instead of a number family.
  TabAtkins: I want a change to syntax approved by a wider set of
             people.

  Chris: Which way do we want to go with this? I don't think Myles
         was against renaming descriptors. It's more cumbersome but
         eh.
  leaverou: How about we step back and think if those are good names
            for the descriptors. I think something like color-1...
  TabAtkins: I agree. I don't think the numbers are very good
             either. color-1 is more explicit.
  leaverou: And seems reasonable to reserve int for something more
            substantial.
  <fantasai> in favor of the readability argument
  Chris: I'm hearing an argument against raw int. Does anyone like/
         dislike color-n?
  <tantek> is also in favor of the readability argument
  fantasai: I'm in favor for the readability argument from leaverou
  <Bert>: I'd rather not change the syntax. Allowing numbers as
          idents takes away some opportunity for error checking and
          I wonder what happens with APIs that expect CSS property
          names...
  Chris: Objections?
  Chris: I see IRC support.

  RESOLVED: Descriptors will be called color-<integer>

  fantasai: What about leading 0s?
  Chris: If it's int you could put it in hex I guess. We don't want
         a thing where color-1 and color-01 are different.
  <tantek> interesting. because color:#1; color:#01; color:#001 are
           all different :P
  <tantek> just saying, not theoretical
  <leaverou> tantek: Indeed. #1 and #01 are invalid
  <tantek> leaverou: meh, they do stuff in browsers :P
  <leaverou> tantek: Not in CSS.
  Chris: TabAtkins is there a problem?
  TabAtkins: Depends. Easier if we define that the family of
             properties is int without leading 0s. It's possible to
             do the other way. It's not a huge deal to discard extra
             digits. It seems like that would make it more annoying
             in a theoretical prospective. Other places with family
             we compare on exactness.
  Chris: I like canonical. I prefer we say what the canonical form
         personally.

  Chris: Other views?
  fantasai: If you have canonical it has no leading 0s because we
            don't know how many 0s to use.
  Chris: Exactly.
  plinss: It would probably sort badly.
  Chris: Correct.
  Chris: Is there a use case to sort descriptors? They might type in
         odd orders so they override. So it's reasonable they should
         append.
  plinss: I'm not overly concerned. Hand authors won't be concerned.
          It's tooling.
  TabAtkins: It also depends on you have at least 10 values. Most
             palettes are smaller.
  Chris: That's correct.
  Chris: That we've seen so far anyway.
  TabAtkins: It's a matter of tooling and they can improve.
  Chris: Objections?

  RESOLVED: Define family without leading 0s

  Chris: Should we leave room for Myles to object?
  TabAtkins: Yes, absolutely. Myles should feel free to object since
             he's not here.

The CSSFontFeatureValuesRule interface has only one implementation
------------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1713

  Chris: This only has one impl. This looks like a prime candidate
         to move to fonts 4.
  Chris: We've moved the OM to fonts 4 in effect.
  Chris: Has anyone got great news that they'll impl or should we
         punt?
  Chris: Objections to moving to L4?

  RESOLVED: Move CSSFontFeatureValuesRule to L4 Fonts

  Chris: Again, myles can object in the next few days.

The font-language-override property has only one implementation
---------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1714

  Chris: Any plans for implementing this?
  fantasai: Any status on font override descriptor?
  Chris: It was added. But if the property is moved the other stuff
         would be too. other stuff=descriptor
  fantasai: Great. Is the descriptor more wide implemented?
  Chris: I don't think so.
  fantasai: If there aren't impl with the descriptor moving to L4
            makes sense.
  fantasai: If the descriptor was there it seems less work to impl
            the property.
  Chris: I think Gecko is only impl for both.

  Chris: Objections?

  RESOLVED: Move the font-language-override property to fonts L4

font-presentation doesn't have a great name
-------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1092

  Chris: It's if you present emoji as visual emoji or text.
  Chris: There has been some discussion on this. Who wants to speak
         to this?
  * tantek thought emoji was text. or do you mean ASCII7 text?
  fantasai: There were suggestions in the issue. I think we should
            pick one.
  Chris: Yes, tantek emoji are text, but you can present a smiley
         face as a graphic or smiley-face-emoji (or something like
         that) Unicode allows both.
  TabAtkins: It's a monocolor glyph or a colored glyph for this.
  <dbaron> I'd suggest maybe the property name isn't being very good
           at describing what this does...
  Chris: Oh. That's different actually. Unicode values are text and
         emoji which is weird. Shouldn't it be chromatic and
         monocolor? I hadn't got from text that it's black and white.
  <TabAtkins> +1
  <leaverou> +1
  Chris: dbaron agrees with me.
  dbaron: I was thinking it was the name of the property.
  Chris: It's the name of the property we're bikeshedding. There are
         various suggestions.
  <dbaron> not the names of the values?
  <dauwhe> examples for the confused:
https://typography.guru/journal/unicode-8-emoji/

  TabAtkins: I know someone suggested font-emoji. monochrome and
             color seem reasonable.
  <leaverou> +1 for monochrome and color. monochrome is also
             consistent with the MQ value
  fantasai: If you have multi-color fonts they're not monochrome.
  TabAtkins: Truuuuuuuue. Are they painted like normal text or tiny
             images.
  Chris: It's a strange way to present it.
  Chris: If we have values that are monochrome and color it seems
         font-variant-emoji would be reasonable.
  Chris: That's my personal pick.
  <Chris> font-variant-emoji: monochrome | chromatic
  fantasai: Makes sense to me.
  fantasai: It's definitely better. Unless someone has a different
            preference we should resolve.
  <leaverou> what about symbol and graphic?
  TabAtkins: Property name is an improvement.
  <tantek> agreed with the change to monochrome - much more
           descriptive than "text"

  Chris: Support on property name, still discuss values.
  Chris: leaverou suggested symbol and graphic
  fantasai: I like that.
  TabAtkins: I'm not sure I like symbol. Graphic or image is good
             for full color.
  <tantek> line-art
  leaverou: Line-art and graphic?
  TabAtkins: It could be fully filled pictures.
  fantasai: Glyph vs graphic?
  Chris: They're both glyphs.
  leaverou: Rich and plain?
  <dauwhe> plain and fancy :)
  TabAtkins: Plain's not bad.
  TabAtkins: Plain and image maybe.
  TabAtkins: We have ideas. We can continue value name in the thread.
  Chris: Let's resolve on property and leave values for bikeshedding.

  RESOLVED: Property name is font-variant-emoji

Override (Emoji) Variation Selectors
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1144

  fantasai: Some discussion about having font-variant-emoji give the
            default presentation for emoji in the text. Text can
            have a variation to say display as graphic or text and
            that overrides the font-variant default.
  fantasai: This was opened to say the author should be able to
            override the text and they suggested syntax was to add
            an override keyword.
  fantasai: Is this a feature we want? If so, is this the syntax?

  TabAtkins: I'm not seeing the use case in the github issue. We
             often let specific override general here.
  Chris: I agree with TabAtkins. This is a lot like changing what
         the text content is which is not styling's job.
  fantasai: I'm also skeptical there's a use case. One I can think
            of is in the user style sheet. I would lean toward not
            adding unless there's a clear use case.
  TabAtkins: I'm seeing a bunch of specific use of the override
             character and I want to fix that. I suspect the use of
             the override is nil. That can be added in the future so
             no loss on not doing it now.
  Chris: Right...

  Chris: I also see Crissov asking us to liaise with unicode. Does
         he think they have a different solution? I can't follow the
         argument.
  fantasai: His original idea was it's a text transformation that
            inserts the variation selector, but I don't see why we
            care.
  fantasai: I'm not seeing a strong use case and I think we should
            close until we get an actual use case.
  Chris: Suggesting close no action?
  fantasai: Yeah, with that we would reconsider with an actual use
            case.
  fantasai: That made it worth implementation and testing time.

  Chris: mmmmm.
  Chris: I also see Roel asking about using this in general. Do we
         have an answer for him for how to do that? It seems like a
         separate sub-issue.
  fantasai: Is there a reason they won't be controlled by this
            property?
  Chris: Yeah, they're not variation selectors to do that. At the
         moment if you support color glyphs and this format you just
         display in color and maybe the user wants monochrome. That
         sounds more style-like.
  Chris: I guess I could ask him to re-raise that as a separate
         issue.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-291458684
  fantasai: This comment ^?
  fantasai: That's a good question because is the current feature
            restricted to emoji or effect all glyphs?
  Chris: Right. I'm not fully up on variation selectors.
  fantasai: If font-variant-emoji effects more than emoji we need a
            different name.
  Chris: That one is only emoji according to unicode.

  ACTION ChrisL ask Roel to re-raise
         https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-291458684
         in a separate issue
  <trackbot> Created ACTION-861

  Chris: Myles had agreed to this and wanted to add the override. Do
         you think he'd be okay with closing it?
  Chris: I see Myles removed the needs edits. I'm feeling less
         comfortable about just closing. What's the sense of the
         people in the room? Do we close and let Myles object?
  TabAtkins: I believe so. I've read through more and the
             justification of the override is really choosing the
             defaults.

  RESOLVED: Close issue 1144 no change

Definiteness of flex items' main size depend on flex-basis's
    definiteness
============================================================
  github: https://github.com/w3c/csswg-drafts/issues/1679

  fantasai: The grid has a behavior where we calc size of rows and
            columns which could depend on content we then do a pass
            to layout the items. So if the grid item is stretch or %
            it will resolve, as will any child.
  fantasai: Seems like there are impl of flexbox with a similar
            effect where a flex item is considered definite even
            though spec says if flex-item size depends on content
            the % wont' resolve. TabAtkins and I are happy to define
            what impl want, but we need to know if this was
            intentional or not. It does require another pass.
  fantasai: Basically, we want impl to say what they want us to put
            in the spec.
  TabAtkins: Specifically Firefox and Edge.
  gregwhitworth: I was going to ask for another week if possible.
  gregwhitworth: I was going to look into our code more. Unless
                 Gecko has feedback now.
  fantasai: Next week is good.
  Chris: Sounds good gregwhitworth. ANyone from FF, can they do
         input?
  fantasai: dbaron CCed dholbert.
  Chris: Great. We'll defer.

Baseline self-alignment may affect the intrinsic size contribution of
    the alignment subject
=====================================================================
  github: https://github.com/w3c/csswg-drafts/issues/1039

  fantasai: This one is an issue where the handling of baseline
            alignment in terms of how it effects intrinsic track
            sizing wasn't well specified. I checked in changes, I'm
            asking for review at this point.
  <fantasai> https://drafts.csswg.org/css-grid/#algo-content with
             <ins> as green text
  fantasai: I just wanted to announce that. Impl should see if they
            fix the issue. The changes are green text in the spec.
  fantasai: Just a request for review. Hopefully resolve next week.
  Chris: We'll leave the agenda+ on this one.

  Chris: We have 10 minutes left. What would people like to do?
  fantasai: There was a sizing issue.

Adding a 'size' shorthand for 'width'/'height'
==============================================
  github: https://github.com/w3c/csswg-drafts/issues/820

  fantasai: Suggestion we should have a shorthand for both width and
            height.
  fantasai: Obvious would to use a size property. Problem is we have
            an @page size descriptor and they behave just like
            properties.
  Chris: It shouldn't be a problem for a descriptor and property to
         have same name. We have that, right?
  TabAtkins: No.
  TabAtkins: You have a width and a height descriptor on @page rule.
             You also have a size, but it does not behave like this
             proposal.
  <dauwhe> @page { size: 6in 9in }
  fantasai: Options are come up with another name or deal with that
            they have the same name and this might be a little awk
            in some impl.

  plinss: Size descriptor, does that interact with width and height?
  TabAtkins: Orthogonal.
  fantasai: Not really. Page size is a size in which you put the box
            and width and height desc the content box.
  plinss: I'm wondering if we can't redefine the size in the page
          [missed]
  fantasai: Size defines the margin box and width/height are content
            box.
  TabAtkins: And the part of the grammar exists in the size
             descriptor. You can put @page { size: 6in 9in } and it
             looks exactly like the size shorthand for width and
             height.

  <gregwhitworth> How much is @page size descriptor used? Anyone
                  know?
  <tantek> good q gregwhitworth
  <gregwhitworth> I know whatever we call this shorthand it will be
                  used a ton
  <Chris> in print stylesheets, obvs. for paper selection I imagine
  <fantasai> gregwhitworth, it's used a lot in the printing world
  <fantasai> gregwhitworth, e.g. by CSS->PDF it's almost always used
  <gregwhitworth> good to know fantasai

  Chris: So we've talked ourselves to this won't be a conflict.
  TabAtkins: No, the opposite. There will be a conflict.
  Chris: Got it.
  fantasai: I feel like it's probably okay. But it is a question
            where impl will have different handling for parsing in
            size when it's parse in for @page and that could be
            tricky.
  TabAtkins: It's tricky for impl and confusing for authors if they
             use @page rule.

  Chris: Can we come up with a different name?
  <gregwhitworth> dimension?
  TabAtkins: I'm kind for box property. That makes it easy to fold
             box sizing into the short hand.
  fantasai: I don't think you want a size property that resets box
            sizing. People set box sizing and just want to leave it
            and pretend that we had border-box sizing from the
            beginning. If you have a shorthand that resets it it
            won't be useful.
  <jensimmons> +1 to what Elika just said
  <tantek> fantasai's observation is correct IMO
  <tantek> what fantasai said is the path of least surprise
  TabAtkins: Sometimes. Sometimes they want to reset it and doing it
             in one property is great. But I see your argument.
  Chris: I tend to agree with fantasai.
  Chris: There's 4 minutes. Any bright ideas?
  Chris: Sounds like not.
  Chris: Anything to talk about in 3 minutes?

  <gregwhitworth> We have cx and cy
  <gregwhitworth> why not wh?
  <gregwhitworth> I don't like it, but...
  fantasai: We definitely have authors who want this shorthand to
            exist, so we should figure out something here and do it.
  Chris: gregwhitworth was that serious or trolling?
  gregwhitworth: I don't know.
  <TabAtkins> Those names are legacy from svg, we'd never name them
              that fresh
  gregwhitworth: I can't think of anything besides dimension and
                 size that make sense.
  Chris: I agree with TabAtkins. We have those because we were going
         for short attribute names.

  Chris: Okay. no bright ideas.
  Chris: Let's leave it open.
  Chris: We'll discuss on Github.
  <fantasai> area?
  <gregwhitworth> proportion
  <fantasai> looking through http://www.thesaurus.com/browse/size
  <gregwhitworth> lol, same here fantasai
Received on Thursday, 17 August 2017 00:59:50 UTC

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