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

[CSSWG] Minutes Telecon 2017-02-22 [css-fonts] [css-flexbox] [css-sizing] [css-text-decor] [cssom] [css2] [css-display]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Feb 2017 20:38:20 -0500
Message-ID: <CADhPm3sD3EXe_aJ=xm-rcPET8FaNybDaTLawF=qkFdp3QcXmzQ@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.

Path to CR for CSS Fonts 4

  - There was general agreement that ChrisL's proposed approach to
      trim Fonts 3 and take it to REC was a good way forward.
  - ChrisL will prepare a list of items that don't have two
      implementations or don't have sufficient tests and send it for

Use flex-order first or document-order first item's baseline?

  - TabAtkins will determine the most interoperable approach for
      order-modified document order and propose it to the group for

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

  - No one was opposed to the shorthand, however there was very low
      implementer interest.
      - Some of the low interest came from the complexity of using
          the word 'size' as it's already used in the @page rule.
  - The discussion will be tabled until there's implementor interest
      in using 'size' or a better name proposed.

Default color of text-shadow

  - RESOLVED: Tie the color of the text shadow to the currentColor
              with spec text tbd.

Serialization of CSS declaration block returned from getComputedStyle

  - RESOLVED: Have the declaration block serialize as an empty

Percentages used to compute to auto; now compute to a percentage but
    are used as auto

  -  RESOLVED: Define behaves as auto in CSS Sizing. TabAtkins and
               fantasai will write this. (In reference to

What are "form controls"?

  - TabAtkins will summarize his thoughts on GitHub on what makes a
      form control and the difference between using 'behaves as' and
      'computes to' and the group will revisit next week.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0085.html

  Rachel Andrew
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Vladimir Levantovsky
  Chris Lilley
  Peter Linss
  Michael Miller
  Liam Quin
  Melanie Richards
  Jen Simmons
  Alan Stearns
  Steve Zilles

  Tantek Çelik

Scribe: dael

Path to CR for CSS Fonts 4

  astearns: Let's start. Anything extra for the agenda?

  ChrisL: Fonts 3 hasn't been updated for a long time and it doesn't
          use bikeshed. Fonts 3 describes web fonts which is now
          used everywhere. It's on 64% of top websites. It needs to
          be a REC.
  ChrisL: It also has low level open type support. More high level
          font variant stuff is only implemented in Firefox.
  myles: It's implemented in webkit.
  ChrisL: I made a list of things in fonts 3 that aren't tested.
          Fonts 4 has more text and better description of open fonts
          stuff. It also uses bikeshed. All current discussion is in
          fonts 4.
  ChrisL: I think we need to trim from fonts 3 the small things that
          aren't reliably impl. Put that in PR. Publish fonts 4 and
          make that the current item.
  ChrisL: I think dbaron pointed out that some of the things
          fantasai wanted to push were just a title.
  ChrisL: It's an area of active interested and active impl.

  Vlad: I agree with ChrisL pretty much. One thing, font
        variations-how it's in the draft what's missing is the
        responsive layout support. Responsive is the most desirably
        feature but what we have now is static.
  Vlad: It's all nice to have, but I think we do need to put a
        little more effort to make it a usable universal solution
  ChrisL: I agree.
  astearns: Is that issue recorded?
  Vlad: I haven't, but I will. this is perfect timing because I just
        finished fonts for OFF so I have free time.

  astearns: I also think ChrisL's plan makes sense. Someone would
            need to go through fonts 3 and make decisions.
  ChrisL: I'm happy to do that. I think I have a list as a starter.
  astearns: That's one thing I wanted to clarify. We should trim
            things without 2 implementations, but also trim things
            that don't have tests and just go to PR with things that
            are interop tested. That would be fastest.
  ChrisL: There's font object stuff, yes.
  dbaron: It would be good to publish the list and see if people
          have tests.

  ACTION ChrisL come up with list of things to trim from fonts level 3
  <trackbot> Created ACTION-830

  astearns: Once we have that list we'll start the rest of the work.
  astearns: Anything else on this topic?

Use flex-order first or document-order first item's baseline?

  <astearns> https://github.com/w3c/csswg-drafts/issues/995
  TabAtkins: Previous issue noticed there's an inconsistency between
             grid and flexbox on which order of elements where we
             take to determine the baseline. Grid is very specific.
             Flexbox doesn't have a special specification which
             implies standard dom order
  TabAtkins: That's inconsistent with grid and according to a test
             browsers reasonably interoperable to use the
             order-modified order. So a fix to flex would bring us
             into agreement with grid and impl. Just need a
  astearns: Clarification. When you say order-modified order that
            could be different than visual if flexbox is set in
  TabAtkins: Great question.
  TabAtkins: Let's check the test.
  TabAtkins: Not sure at this moment. Correct answer is likely
             whichever is more interop.
  astearns: I'm happy to go with more interop.
  astearns: Other opinions?
  dbaron: Fine with me as long as you let whoever is in the less
          interop half know.

  ACTION TabAtkins determine what is more interop (on use flex-order
         first or document-order first item's baseline? issue) and
         bring to group for resolution.
  <trackbot> Created ACTION-831

  <TabAtkins> Quick test shows that Chrome uses straight
              order-modified document order - flex-direction doesn't

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

  <astearns> https://github.com/w3c/csswg-drafts/issues/820
  TabAtkins: People keep wanting a short hand to set width and
             height together.
  TabAtkins: Size would be obvious, but it's taken by @page rule. So
             should we use size anyway and it's different in a style
             context or do we have another name? There's other names
             in the thread, but I'm not a fan of any of those. My
             personal preference is we accept that @page rule is a
             different mechanic so it's different.
  TabAtkins: I'm not sure how other impl are with this, though.
  <bkardell> some preprocessors implement this and call it size
  <bkardell> nobody seems to be too confused by it or anything,
             seems like paving the cowpath makes most sense

  fremy: I don't expect this to be useful enough to be worth impl.
         But I don't mind.
  myles: That's what I was going to say. If this doesn't add new
         functionality it's pretty low priority.
  TabAtkins: There's no new functionality. There's a sub discussion
             about later handling aspect ratio at which point a
             short hand makes sense.
  jensimmons: It's true it doesn't add functionality, but it changes
              authoring experience. I think that's not minor. It's a
  astearns: [reads bkardell on IRC]
  jensimmons: It seems to be a thing people want. And I could argue
              that since it's no new functionality it's easy to impl.
  myles: Has this been done in other places?
  TabAtkins: Where we add a shorthand to agglomerate disparate
  dbaron: The @page thing is what makes this hard.
  TabAtkins: It wouldn't be trivial in chrome.
  TabAtkins: I think this is largely a failure of early OM spec, but
             we're in that situation.

  jensimmons: Would it be easier if we don't use 'size'?
  TabAtkins: It would avoid a complication.
  astearns: But then you have worse author experience because people
            have to remember the name.
  jensimmons: The question is if there's a better name and we
              haven't thought of one yet.
  TabAtkins: I haven't seen a good one yet.

  astearns: What I think I'm hearing is no one has an objection to
            using 'size' but there's no implementor lining up to
            implement the shorthand with that name.
  TabAtkins: I think so.
  TabAtkins: I think we should table until we can get implementor
             interest or a name we believe has a good chance of
             being accepted.
  astearns: I think that makes sense. Table this, look for a better
            name and/or implementor interest. If we can get more
            authors asking for size it would move implementor

  fantasai: It's worth noting inline size and block size use 'size'.
            If we use a different word we're inconsistent.
  astearns: Can you add that to the thread if it's not there?

Default color of text-shadow

  <astearns> https://github.com/w3c/csswg-drafts/issues/942
  TabAtkins: tantek did the agenda+. The core issue is easy.
  TabAtkins: The text says that shadows by default use the color of
             the ink they're shadowing. In simple text this is the
             same as saying use the color property. But in complex
             cases we're not sure we intended this. For example text
             decorations. This is probably what it was meant to
             suggest. But as written it means that multi-color fonts
             should cast multi-color shadows and that's probably not
  TabAtkins: Unless we did mean that we should amend the text
             somehow. We're not interoperable on matching text
             decoration color so we can change.
  ChrisL: I agree we shouldn't cast multi-color shadows.
  fantasai: I think going with the simple answer is the best. Most
            cases the text shadow is a specified color or happens to
            default to black.
  <SteveZ> what about white on black pages?

  dbaron: The other maybe related thing is what changes to color
          happen under selection which is also non-interop.
  TabAtkins: You're right that keeping original text shadow looks
             bad when you invert the color under highlight.
  TabAtkins: I'm not 100% sure how to handle given that the
             selection is at a smaller level then where the text
             shadow renders.
  astearns: Should we resolve on the first bit and do selection
  TabAtkins: I'm okay to leave an issue for handling selection
  fantasai: You can do whatever you want on selection for
            ::Selection selector.
  fantasai: I guess you can't...if we split test shadow into multi
            long hands you could do that.
  astearns: I wasn't talking about leaving selection as an issue. I
            meant for discussion right now separating the two things.

  astearns: Proposal was to have the color of text shadow just go to
            the color of the text and not be affected by text
            decoration or emoji color.
  fantasai: I would be more specific and say defaults to
  TabAtkins: Yeah.
  astearns: Obj to specifying text shadow uses currentColor?
  <ChrisL> sgtm
  dbaron: One comment is how this interacts with text-fill-color and
          text-stroke-color. It's possible it should use text-fill.
  TabAtkins: Those properties don't actually exist yet...
  <ChrisL> yes, it should be text-fill-color (once it exists)

  fantasai: I think more interesting question is does that give
            correct behavior on inheritance.
  fantasai: It's probably fine.
  dbaron: Other interesting thing is when you have a text shadow
          crossing multiple elements that are different colors.
  TabAtkins: mmmhum
  fantasai: If you set the color to be a color you paint those as
            one shadow. If you don't you do whatever happens in that

  astearns: Didn't sound to me like anyone objected to specifying
            text shadow uses currentColor.
  dbaron: We just need to make sure it's the right currentColor.
  TabAtkins: Yeah.
  TabAtkins: In chrome if I set text color on a parent and have
             child with different color it takes the color of the
  astearns: Can we figure this out on the call or do we need an
            action for someone to write text?
  TabAtkins: Sounds like we should resolve to go in this direction
             and we don't want multi-color shadows. Exact spec text
             to be resolved on a different call.
  astearns: Proposal is tie the color of the text shadow to the
            currentColor with spec text tbd. Objections?

  RESOLVED: Tie the color of the text shadow to the currentColor
            with spec text tbd.

  astearns: Now what to do with selection?
  TabAtkins: Given text shadow inherits down I think that standard
             cascade will handle this properly if we use
  TabAtkins: When you try and render the text now you check the
             color and render the shadow appropriately so you get a
             shadow matching the selected text color. I believe it
             falls out. I wouldn't be surprised if the inherits down
             to text nodes isn't defined throughly.
  astearns: Other opinions?
  astearns: Let's get the text for the last resolution drafted and
            then we'll see how that fits with selection.

Serialization of CSS declaration block returned from getComputedStyle

  <astearns> https://github.com/w3c/csswg-drafts/issues/1033
  astearns: Also from tantek.
  astearns: Anyone up to date on this?
  TabAtkins: Not enough to talk about it.
  astearns: fremy I see you on the thread.
  TabAtkins: I'm remembering.
  TabAtkins: We might be able to address quickly.

  TabAtkins: When you call getComputedStyle you get a declaration
             block. How do you serialize that? Firefox and Edge say
             empty string. Chrome and Webkit try and serialize it
             out as a {} block. It doesn't have a good rhyme or
             reason as to what appears.
  TabAtkins: I suspect we can standardize on FF/Edge and do empty
  TabAtkins: There's a webcompat issue reported to Firefox, but it's
             a Google property and we can get that fixed.
  myles: Why wouldn't anyone want to serialize this?
  TabAtkins: Presumably there's a reason, not sure why.
  TabAtkins: Reading the issue.
  TabAtkins: Looks like it's not a good reason.
  TabAtkins: Due to the way the Firefox vs Chrome is working it's
             triggering a really bad code path, but it's not being
             used for a good purpose. So we can evangelize and get a
             fix on our end.
  astearns: Proposed: have the declaration block serialize as an
            empty string. Objections?

  RESOLVED: Have the declaration block serialize as an empty string

Percentages used to compute to auto; now compute to a percentage but
    are used as auto

  <astearns> https://github.com/w3c/csswg-drafts/issues/1051
  fremy: I added it yesterday and if people need time we can defer.
  fremy: In CSS 2.1 if there's a percentage height that's pegged to
         something that's auto the computed value becomes auto.
  fremy: Apparently that was changed in CSS 2.2. You now follow the
         same rules as if it's auto. I don't know why we did this.
  dbaron: The change was intentional because we don't want computed
          values to depend on complicated things that contain
          layouts. Without this change the computed value of height
          depends on the display property which is complicated and
          we don't want inheritance to depend on that.
  TabAtkins: Similar to various issues about computes to vs behave
  fremy: So then we should fix all the specs?
  TabAtkins: Yeah.
  fremy: That's some work.
  dbaron: You can introduce terminology to do that.
  fremy: But you need to do it on some spec first.
  fremy: Maybe Sizing.
  TabAtkins: Probably so.

  fremy: Can we resolve on that? CSS Sizing will say something about
         when the height behaves as auto?
  TabAtkins: We can do that.
  astearns: Proposed resolution is have some text in CSS sizing that
            describes the behaves as auto behavior.
  fantasai: Is it that behaves as is undefined or behaves as auto?
  TabAtkins: Neither. Other specs that want to care about behaves as
             auto are caring about computes to auto.
  TabAtkins: We could do with a term of art here. We add a term that
             nails it down.
  fantasai: If the confusion is if the behaves as is the same as
            computed as...
  TabAtkins: That's not the confusion
  fantasai: [missed]
  <fantasai> Is it confusion over when the clause triggers or what
             happens when it does?
  TabAtkins: It's not confusion as to when it triggers, it's that
             old spec texts were written when it was computed to
             auto. There's no confusion, there's a needed spec
             update and it will be easier to be consistent with a
             term of art.
  fantasai: I don't understand still. If there's an old spec that
            said computes to auto we fix that spec.
  TabAtkins: Yes. Question is how to have all the specs that do it
             do it consistently. Solution is sizing does it and they
             link to the term in sizing. There's no possibility of
             slightly differing text.
  dbaron: TabAtkins should repeat the thing he said.
  TabAtkins: It's not confusion about when the thing triggers. Old
             specs refer to the old process. They need an update,
             but we want a consistent way to do that update. Sizing
             defines a term of art of this and when we update all
             the other specs they refer to this term and everyone is
  TabAtkins: Nothing more than we fix the specs but we use a term
             for consistent
  fantasai: Instead of referring to the value of auto we say height
            is foo...
  astearns: Instead of saying computes as auto we refer to this term.
  dbaron: There are a bunch of specs that test if the computed value
          is auto. They need to test if it's auto of a value where
          it's supposed to be threated as auto.
  fantasai: Or we define behaves as auto.
  TabAtkins: I'd rather make this explicitly clear instead of doing
             an implicit patch to every spec.
  fantasai: That doesn't make sense. You're proposing to patch every
  TabAtkins: You're talking about making a change in one spec that
             implicitly updates every other spec where when you read
             a spec you have to remember that this updated in
             another spec.

  astearns: I'd like to resolve we define behaves as auto in CSS
            sizing and action TabAtkins and fantasai to get it done.
  astearns: Objections?

  RESOLVED: Define behaves as auto in CSS Sizing. TabAtkins and
            fantasai will write this.

  <dbaron> I don't think the term needs to be "behaves as auto"; it
           could be something else...

What are "form controls"?

  <astearns> https://github.com/w3c/csswg-drafts/issues/1024
  astearns: In Seattle we discussed some things about form controls
            and decided to have spec text, but someone noted form
            controls isn't defined.
  TabAtkins: yeeeeaaaah.
  fantasai: Form control is anything that submits or could submit.
  TabAtkins: That's not the thing, though. There's a layout behavior
             that's shared by form controls and that's the thing
             we're trying to differentiate on. They're the almost
             replaced elements.
  TabAtkins: I opened an issue to figure out what this concept is.
             Then we can define which elements follow this concept.

  astearns: Boris had an additional concern that if we made this
            change to talk about this set of things he now has to
            worry about what elements are being styled instead of
            looking at elements.
  TabAtkins: Yeah, change should be a behaves as, not a computes to.
  TabAtkins: Technical wording of resolution was behaves as. It got
             interpreted as computes as. In my opinion it's not
             unreasonable to change.
  dbaron: I think in this case there was discussion that it was not
          computes to.
  fantasai: I don't remember, but what I was doing I think as I
            noted the way that computed style behaves for something
            with or without a box is different and in style
            computation layer you'll need to treat it differently.
  dbaron: getComputedStyle is not computed values.
  TabAtkins: She's talking about general computation process.
  dbaron: This cannot be computes to.
  fantasai: I'm fine to make it what it needs to be, but a bunch of
            stuff depends on this. It's not at layout level.
  TabAtkins: If you display not a form control it goes away. It
             effects other properties because the box goes away. If
             there's display none but a form control that effects
             layout because it's an inline box.
  TabAtkins: So there's still a computed value dependency, even if
             we way behaves as. You have to worry about that in
  TabAtkins: Usually behaves as it will become that in the used
             value. This you have to know it's inline up front.

  astearns: If that's true and it's also true that we can't have
            this dependency, can we still do this behaves as inline
            that we resolved on?
  dbaron: I think we can, but I'm not in front of a computer right
          now so it's hard to figure out.
  TabAtkins: We could go the other direction and make display
             contents act like display none.
  fantasai: What happens if I apply float? Inline or block? Float
            and display inline combo is not defined.
  fantasai: Same with position. There's probably a bunch of things.
  fantasai: Either way we go there's a whole can of worms here.
  <dbaron> ok, maybe we actually can't do this easily
  TabAtkins: I believe the entire thing came out as a result of
             people trying to be complicated with making contents do
             extra smart things with replaced elements. Going simple
             with display:none solves all the problems.
  fantasai: Discussion came out of "this is not defined" and we had
            a bunch of options how to define it.
  fremy: We decided on inline because that's what FF was doing. If
         they're fine to change I think we can.
  TabAtkins: Given dbaron needs time, let's re-open the issue about
             display contents computing to inline. I'll put in a
             summary and we can pick up next week.

  ACTION TabAtkins to update the issue on [css-display] What are
         "form controls"? and bring it to next week's call
  <trackbot> Created ACTION-832

  astearns: Thanks all and we'll talk next week.<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Thursday, 23 February 2017 01:46:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 February 2017 01:46:27 UTC