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

[CSSWG] Minutes Telecon 2017-05-03 [css-writing-modes] [css-3-fonts] [css-values] [css-transforms] [css-ui-4] [css-rhythm-1] [css-flexbox] [css-sizing] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 May 2017 00:10:17 +0300
Message-ID: <CADhPm3u9P_bxNoon+fCK1DHvcNma-TepaAQZ4jJ6qu_iRhZgdg@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.

Spec Rec Next Steps

  - Writing Modes: fantasai will confirm that the proposed edits are
  - Fonts: Myles has finished changing the test font.
  - Values & Units: fantasai will confirm the DoC is ready for
  - Transforms: Rossen will ask Bogden to help smfr with edits.

FPWD and shortname for CSS Logical Properties & Values

  - RESOLVED: FPWD of Logical Properties with a short name of

Suggestion: "Overflow styling" / Scrollbar styling

  - There was a lot of browser interest in achieving compatibility
      on this feature since it's used widely enough that it can't be
      - smfr had an explainer of the implementation
          (https://webkit.org/blog/363/styling-scrollbars/) that the
          Edge folks will review to see what additional information
          would be needed to make a compat spec, which would likely
          be added to CSS UI4.
  - Anything extending beyond compat will be deferred until working
      group members have a better understanding of what's out there

Avoiding accidental double spacing

  - The issue on defining/standardizing line-height: normal
      (https://github.com/w3c/csswg-drafts/issues/1254) needs to be
      resolved before this issue can be resolved.
  - myles will write a test font to help make the test cases for
      line-height: normal more robust.

Should flex-shrinking propagate back down the flex chain?

  - fremy will file a bug on the appropriate browsers.

Porting gradient midpoints to Level 3

  - RESOLVED: Move gradient midpoint to Images L3.

Clarification about `Nx` as <resolution> value in image-set() is

  - RESOLVED: Add the x unit to <resolution> type in Values & Units 4.
  - RESOLVED: Revert the edit to image-set in CSS Images.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0004.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Robert Flack
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Michael Miller
  Theresa O'Connor
  Liam Quin
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Benjamin De Cock

Scribe: dael

Spec Rec Next Steps

  astearns: Writing modes. 2 issues. One closed yesterday. Last is
  astearns: fantasai, was my proposal to shift things acceptable?
  fantasai: I was thinking about it, but we can probably rejigger
            like you said.
  astearns: If you can make that edit asap there's nothing keeping
            us from PR.
  fantasai: Okay.
  Florian: CR first.
  astearns: Republishing first, yes.
  fantasai: These are editorial. I don't think we need CR.
  astearns: Not those, but we haven't done the edits from the last.
  fantasai: Those were dropping.
  astearns: That's fair. I'd have to look at the change list again.
  astearns: Let's do that once you get the last edit in.

  astearns: Fonts, myles was changing test font.
  myles: I think I've finished all the changes.
  astearns: You made the changes to work in Edge. There were extra
            feature requests. They're done?
  myles: Yes.
  astearns: Great.

  astearns: There were a bunch of specs, cascade, conditional rules,
            backgrounds & borders where dbaron was going to look at
            adding test from Mozilla after F2F. Can you get that on
  dbaron: Possibly, but I haven't yet.

  astearns: On conditional rules we were going to resolve CSSOM
            discrepancies. Did we at F2F?
  Rossen: No.
  astearns: I'll get that on agenda soon.

  astearns: Values & Units- Simon did changes. Anything else before
            we publish?
  astearns: Who is an editor for that?
  fantasai: I am not 100% sure. I have to double check the DoC is up
            to date. Think it was.
  astearns: I'll put you down as checking what needs done before

  astearns: Transforms. Made a lot of progress on issues, but most
            are open and awaiting edits. Who will make those?
  smfr: I need help from an SVG person. [missed]
  Rossen: If AmeliaBR gets invited expert with the group she can
          help you. If not I'll have Bogden take another look to
  astearns: I would like the work to start with Bogden. We'll get
            AmeliaBR quick hopefully, but she's finishing a book so
            I don't think we can expect editorial from her soon.
  Rossen: Reasonable. Since Bogden is part of WG we're good to go.

  astearns: Anything more on Flexbox? There were a couple issues.
  Rossen: We have some of the issues on the agenda.
  astearns: Okay. Let's go with that.

  astearns: CSS UI fantasai was reviewing test updates. Have you had
            a chance to do that?
  fantasai: I haven't.
  astearns: That's it on my list. Thanks for the updates.

FPWD and shortname for CSS Logical Properties & Values

  fantasai: The draft is, I believe, up to date with all resolutions
            so we should FPWD. We hadn't before because the draft
            was incorrect. Needs a short name. It's currently
            logical-props but we don't tend to abbreviate in short
  fantasai: I was wondering if there's a better idea.
  Rossen: We had a resolution from before to publish WD with CSS
          logical-props short name. I can dig out the resolution.

  fantasai: We haven't done FPWD so if someone has a better idea it
            would be nice to not have props.
  <dbaron> css-logical-properties? css-logical?
  <bradk> [logical]
  astearns: logical-properties is logical, but not short.
  fantasai: I'm okay with css-logical.
  <tantek> css-relativity
  fantasai: I'll note the correct term is flow-relative directions.
            We might add other mappings in the future like line
            relative. They're text based.
  fantasai: There's a certain amount of expansion in that direction
            so relative is more accurate.
  <jensimmons> css-directions?
  <dbaron> css-relative-properties?
  fantasai: We might have directions relative to the line direction.
            Or relative to the page, like inside outside.
  fantasai: Relative seems to be the commonality. flow-relative is
            in the prose. This is just that future levels may have
  <tantek> css-logical?
  Florian: We've been using physical/logical distinction quite a bit
           so if we're stuck with that it's not that bad.
  <fantasai> My top contenders are css-relativity and css-logical
  astearns: Relative confuses me with relative positioning.

  Rossen: So css-logical as the short name and proceed with
          publishing? IS that what we're trying to take?
  astearns: Objections to using css-logical as a short name for
            Logical Properties?
  astearns: Objections to FPWD?

  RESOLVED: FPWD of Logical Properties with a short name of

Suggestion: "Overflow styling" / Scrollbar styling
  Github Topic: https://github.com/w3c/csswg-drafts/issues/107

  Florian: Based on previous conversations I think we want to
           reject, but I want to check.
  Florian: Request is for pseudo elements to style parts of the
           scrollbar. I believe browsers don't want to give authors
           control since they're native UI components and therefore
           we should reject. If that's not the case let me know.
  MaRakow: I think the main interest I have from Edge is along lines
           of interop. There were suggestions of enhancements that
           I'm not sure about, but -webkit-scroll we see getting
           used on certain sites. We'd be interested in a compat
           spec to explain behaviors.
  MaRakow: I'm not certain about going beyond what's there.
  astearns: MaRakow are you interested in having webkit behavior
            specified or do you want something interoperable specced
            so everyone can do non-prefixed?
  MaRakow: The former because we see it used. Once I understand
           what's going on it would be easier to comment on second.
           But it's more if sites like gmail are using this how do
           we get interop render of gmail on multiple UAs?

  dbaron: One other question is that there are cases where devs are
          rebuilding scrollbars from scratch because they don't have
          this. That creates performance and UI problems that this
          would avoid. There are tradeoffs.
  <jensimmons> I totally agree with dbaron. Yes. All the custom
               scrollbars / forms and the slow slow JS. ;(
  * liam too, and also accessibility problems with home-made
  MaRakow: We see those too. I have less understanding of the exact
           requirements. I think a compat spec around webkit
           functionality and if the experts have any learning that
           would be valuable. I wouldn't oppose understanding
           better, but there's more expertise on the people who
           worked with existing webkit.
  <TabAtkins> I'm using ::scrollbar, ::scrollbar-track, and
              ::scrollbar-thumb on a personal website, to make a
              less obtrusive scrollbar for a minimal blogpost editor.

  fantasai: There's a lot of talk about different things related to
            scrollbars. This is about having selectors, not
            properties, for each piece of scrollbar.
  fantasai: This is about having selectors to style piece of
            scrollbar. What you guys are talking about seems broader.
  fantasai: This issue we need comments on and then we can talk
            about more things to control scrolling behavior and bars
            and stuff.
  <TabAtkins> #post::-webkit-scrollbar { width: 2px; }
              #post::-webkit-scrollbar-track { background:
              transparent; } #post::-webkit-scrollbar-thumb
              { background: #eee; }
  Rossen: I think what you said covers the GH issue. It also aligns
          with the compat observations we have.
  Rossen: It is mostly those pseudo classes effecting the way the
          experience is different between webkit and everyone else.
  Rossen: If the folks with experience on those particular
          properties can come up with an explainer or compat spec or
          anything that will help us understand we would be very
          interested in impl those, prefixed or not we don't care at
          this point as long as we achieve compat.
  <glazou> let's be serious, there have been proprietary selectors
           for that for AGES.
  <glazou> and the web is full of them
  <glazou> a lot of sites use those pseudos to "style" the
           scrollbar, in particular often for a color matching the
           corporate color
  <glazou> Orange using it a lot IIRC

  Rossen: The second part of this is once we get past styling there
          is a whole scrollbar customization people want to do like
          going into the scrollbar and adding marks like to show
          where changes are. Those are fairly advanced which people
          are hacking today. We're be interested in pursuing that,
          but it's more expensive and an advanced scenario.
  Florian: If we just get the pseudos, before we get to fancy it
           seems we would not be anywhere near done because we'd
           need to say which properties do what and what the default
           UA is. You can access the thing, but does the scrollbar
           change if you change the width of scrollbar thumb.
  * fantasai suspects making the scrollbar too narrow can be an a11y
  <bradk> Tick lines in the scroll bar could be done with
          linear-gradient background
  <jensimmons> believes what projects want the most is the ability
               to ‘brand’ it — change color, remove gradients, etc.
               Visual styling.
  <glazou> +1 to what jensimmons wrote above; exactly what I said
  <Florian> suspects that :scrollbar-track { position: absolute;
            top: 50%; } is not going to do interoperable things

  Rossen: This is where it goes back to webkit and blink supports
          that. For your question, yes they would change the
          scrollbar. We're interested in their experience in
          supporting those properties. I'm interested in hearing
          from webkit folks who are often resistant to control
  Rossen: Also they have the most experience.
  Rossen: Is there anyone from webkit who can speak to that?
  smfr: The scrollbar styling they tried to implement for itunes.
  smfr: It was a mistake to leak to web. We don't really like that
        people can style scrollbars. We won't enhance and prefer to
        deprecate it.
  smfr: Other thing is pseudo elements become artifacts because
        platform changes scrollbar. For example we don't have arrow
        at bottom of scroll for map and when you try to style it
        it's not there. That's the general take.

  astearns: So item was on agenda to close this. I don't think we
            want to close and not fix. I've heard people want more
            info about what's currently prefixed, but I don't hear
            anyone to work on it.

  fantasai: As long as Safari & Blink ship this there will be
            pressure on other browsers to impl. We need to decide if
            that will be removed or we'll have to standardize. You
            can't say we're going to deprecate. You have to either
            remove it or add it to the platform. The pressure will
            increase over time.
  MaRakow: I agree with fantasai. I'd be happy if selectors are
           removed. My goal is interop if that's achieved by
           everyone impl or if everyone removes. I'm not interested
           in prop for own merit, but interested in interop of
  astearns: I'm guessing browsers with it can't commit to remove.
  TabAtkins: Oh no. We can't remove. They're used more than possible
             to kill.
  Rossen: Can you explain them?
  Rossen: Like write an explainer or compat spec so impl that don't
          have it can add that behavior? We'd be happy following the
          behavior if we get compat.
  TabAtkins: In theory yes. I can put it at the end of my current to
             do list.
  <smfr> explainer here: https://webkit.org/blog/363/styling-scrollbars/
  Rossen: I didn't mean you personally.

  Florian: I'm curious. Would people really impl them? These are not
           properties, they're selectors. Are people really willing
           to make people able to relpos the thumb of a scrollbar?
  TabAtkins: They're restricted.
  Rossen: We're willing to impl whatever gets us interop. I'm pretty
          sure that doesn't mean having relpos and grid in a scroll
          bar. That's why we want the browsers with support to give
          us MVC of supporting that.

  astearns: smfr posted a link to a blog that desc them.
  astearns: Could someone from Edge look and see how much more would
            be necessary to get compat impl?
  Rossen: We'll review it.
  Rossen: For purposes of this topic what if we end here. We'll
          review and bring back if we need more info.
  astearns: sgtm

  Rossen: There was the question if this goes into UI4.
  Florian: That was one possibility. CSS UI hasn't had selectors so
           I'd prefer somewhere else.
  fantasai: I Think UI4 makes sense due to specificity of selectors.
  fantasai: As far as what we need for more info, we need a full
            spec for things you want to add. We need a proper set of
            standard aliases. You don't get compat...you can't say
            this won't be part of the platform. If we're not
            removing then we're adding it's part of the platform.
  Florian: The question is do we have enough info in the blog to
           make a spec. I would say we don't because it doesn't have
           a per pseudo class whitelist of properties that apply and
           if it's unusual, how? Because otherwise I can put grid in
           the scrollbar track.
  <fantasai> +1
  astearns: That's as much time as we should spend. We have
            something to start with.

Avoiding accidental double spacing
  Github topic: https://github.com/w3c/csswg-drafts/issues/938

  Florian: I think we shouldn't rehash that issue in github. I think
           we need to sort out another issue first. We had been
           talking about what line-height normal means at F2F and
           discovered we don't even know what line-height: number
  koji: There are details to get out. As long...in terms of
        line-height consistency, I think dbaron confirmed it's
  Florian: I don't think we concluded. WE said prob is, but we have
           3 behaviors on the white board. We weren't sure.
  <fantasai> diagram:
  koji: All on consistent for line-height
  Florian: No they're not.
  koji: They were.
  Florian: 2 are, one isn't.
  Florian: The black behavior does not result in the same
           line-height as blue and red.
  Florian: We weren't sure which Edge did. We didn't have full
  <dbaron> Only one of the three is consistent for line-height if
           you have font fallback
  Florian: My proposal on double spaces depending on line-height.
  koji: I think I have tests on this already.
  Florian: If you have tests, when were they shared?
  koji: In this issue.
  koji: As far as I tested it's interop.

  <Florian> https://github.com/w3c/csswg-drafts/issues/1254
  Florian: When we discussed at F2F no one knew for sure. If you do
           know, ^ is where we discussed that.
  astearns: koji can you post a link to your test cases?
  <koji> http://output.jsbin.com/xekuhu
  Florian: Okay.
  astearns: koji can you describe what it's checking?
  koji: This is a test case we discussed. 5 in the graph- first is
        line-height: normal. You can see the line-height is same. If
        you have 5 line-height options it's maybe different. You
        have 0, 1, 1.2, 1.5, 1.8.
  koji: You can see it's consistent height.
  <Rossen> https://lists.w3.org/Archives/Public/www-archive/2017May/0000.html
  <dbaron> Does this testcase have font metrics that would trigger
           the issues we discussed?
  Florian: I can't figure out which browser is what color.

  fantasai: You need a case with fallback in the line. Where you
            have difference scripts all on the same line. Have that
            trigger different fonts with different ascent & decent
  myles: You need a font with crazy high and crazy low ascent/

  Florian: I think this is a bit too tricky on the fly. Until we
           call agree what line-height: number and line-height:
           normal means it'll be hard to solve.
  Florian: If we agree enough that size is the same that could be
           enough to discuss. Documentation about behavior isn't
  koji: I thought [missed]
  astearns: I think I heard you say browsers agree on line-height,
            but not glyph-position in line-box. Correct?
  koji: Yeah. One this we agreed is to match existing impl. If they
        all agree on line-height: number I don't see problems.
  Florian: I don't think we established they agree.
  fantasai: We said impl will agree if they conform to CSS2 because
            we agreed to change CSS2 to say that the black behavior
            is not allowed. So if impl follows spec line-height will
            be that number. If impl don't follow they have to change.
  dbaron: I don't think that's what we agreed.
  Florian: I think that was a preliminary conclusion.
  dbaron: I think what we agreed only produces it if there's a
          single element. It doesn't work if there are multiple
          elements on the line when some have font-fallback.

  astearns: Did I hear myles volunteer to make test fonts?
  myles: I can do that easily.
  astearns: Thank you.

  astearns: I think we need to get past this question about what
            CSS2 will say about line height and if implementation
            will be able to match. Then figure out cases where
            that's not enough for consistent line height.
  astearns: Seems they're pre-requisite to figure out step height.
  * fantasai agrees with astearns statement

  astearns: koji is it alright to move on?
  koji: Yeah. I'll re-read the discussion.
  astearns: I would like to see progress. I'll see what I can do to
            get that going. I think myles making the fonts will be a
            big help.
  <Florian> agreed

Should flex-shrinking propagate back down the flex chain?
  Github topic: https://github.com/w3c/csswg-drafts/issues/1290

  fantasai: I think this was fremy's. I haven't dug in much.
  fremy: The issue is probably a chrome bug, but I waned to check.
  fremy: Someone made a lot of good test cases. I agree with the
         explanation he gave. What he said makes sense. But if
         you're not ready to discuss I don't know if anyone is ready.
  fremy: I can go ahead and file bugs and if it doesn't match spec
         the browsers will complain. Or we can wait. What do people
  astearns: I think you should file a bug. It's often the fastest
            way to determine if it's a spec bug or can be fixed.
  fremy: I was just trying to get feedback. Seems like it's probably
         a bug. If WG says file a bug I can.
  astearns: Anyone from Chrome with an opinion?
  TabAtkins: I can't look, so no opinion right now.

  fremy: Summary: when you have a flexbox in a flexbox and inner is
         auto. In all browsers except Chrome you size the flexbox
         normally. The fact that it's a flexbox in a flexbox effects
         size in Chrome.
  fremy: I'll file a bug. We can discuss later if they come back.
         Sound good?
  fantasai: Yep.
  astearns: We'll file a bug and see how that goes.

Porting gradient midpoints to Level 3
  Github topic: https://github.com/w3c/csswg-drafts/issues/1284

  astearns: I thought that the midpoint implementors were the same
            people, but I forgot we tasked a person in a different
            continent to implement in one browser. We do have two
  <Florian> go for it then
  TabAtkins: I'm down with it.
  astearns: Objections to moving gradient midpoint to L3.

  RESOLVED: Move gradient midpoint to L3.

Clarification about `Nx` as <resolution> value in image-set() is
  Github topic: https://github.com/w3c/csswg-drafts/issues/461

  astearns: Question if this is editorial or needs a resolution.
  leaverou: In image set it allows values of 1x that is same as
            1dppx. Even though the image example had it, it wasn't
            part of grammar. We solved that by adding an
            x-resolution. So issue was addressed. It's grammar, not
  leaverou: It's another question as to if it should be added, but
            that's V&U. As far as images is concerned grammar is on
            par with example.

  fantasai: Do we want to add this to <resolution> type?
  TabAtkins: I've been for that for a while.
  leaverou: I'm not sure it's a good idea to take a single letter
            unit for a shortcut to another unit.
  TabAtkins: We've done that. We won't use it elsewhere now.
  leaverou: Then it is a better solution to add to the <resolution>

  fantasai: We've never had alias units, so what do you get if you
            serialize it back out.
  leaverou: dppx?
  TabAtkins: It's only image resolution and webkit image set, so
             let's see what webkit does and do what they say. It'll
             be x or dppx.
  smfr: Pretty sure it's x
  * hober would be surprised if dppx worked there

  fantasai: If you put in dppx do you get out x?
  TabAtkins: In specified style no. We don't need fancy. They're
             different units with a 1 to 1 ratio. In computed when
             you canonicalize you go to probably x.
  * fantasai wants to hear dbaron's take on this
  <fantasai> https://www.w3.org/TR/css-values-3/#resolution
  <dbaron> I'm trying to think about whether "x" makes sense for all
           uses of <resolution> or just some of them.
  <dbaron> I think it's probably all.

  Florian: What if you animate from one to the other?
  TabAtkins: Over computed values and all resolutions can be
             computed to each other.
  astearns: Are we converging on using x everywhere <resolution> is
  TabAtkins: Let's leave that to testing. But do we add x to
             resolution and I'm a +1 to that.
  astearns: Do we want to resolve before we test?
  TabAtkins: Is anyone going to object based on the answer?
  astearns: Proposed resolution is add the x unit to <resolution>
            type in V&U.
  leaverou: Yep.
  astearns: Objections?

  RESOLVED: Add the x unit to <resolution> type in V&U.

  fantasai: L3 or L4?
  astearns: I'd be happy for 4.
  TabAtkins: It only has one impl.

  astearns: Since it would go in 4 it means leave the edit in images
            in place because we don't want it to depend on L4 spec.
  TabAtkins: Sure
  fantasai: It's fine because you would have the impl that supports
            L4...the testing would be part of L4 impl. It's like
            when we added q unit your lengths had more values
  astearns: Okay.
  TabAtkins: Yeah, take it out of image set. It depends on
             resolution type.
  <leaverou> agreed as well
  astearns: Then we also need a resolution to revert the edit to
  astearns: Objections?

  RESOLVED: Revert the edit to image-set in CSS Images.

  astearns: We're at time. Thanks everybody.
Received on Wednesday, 3 May 2017 21:11:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 May 2017 21:11:24 UTC