[CSSWG] Minutes Telecon 2017-09-06 [css-align] [css-ui] [css-values] [css-fonts]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Align

  - RESOLVED: Publish updated WD of css-align

Spring and summer (July-ish) f2f planning for 2018

  - RESOLVED: 1st week of July 2018, likely in Sydney, actual
              location TBD

Review of the optional test failures in the css-ui-3 test suite

  - RESOLVED: Leave spec as-is, no changes. Accept all current
              requirements as listed in issue (Github:
              https://github.com/w3c/csswg-drafts/issues/1770 ).

Should viewport units still depend on scrollbar width for

  - RESOLVED: Drop the requirement to subtract scrollbar size from
              vh/vw units for overflow scroll.

@font-face unicode-range and first available font

  - RESOLVED: Change spec text to read first available font that
              would match the U+0020 (space) character. (This change
              will be applied to both Fonts 3 and 4)


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0007.html

  Rossen Atanassov
  Tab Atkins
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Dean Jackson
  Tomoya Kimura
  Myles Maxfield
  Theresa O'Connor
  Naina Raisinghani
  Fran├žois Remy
  Florian Rivoal
  Alan Stearns
  Shane Stephens
  Eric Willigers

  Rachel Andrew
  David Baron
  Benjamin De Cock
  Daniel Glazman
  Tony Graham
  Chris Lilley
  Anton Prowse
  Melanie Richards
  Lea Verou
  Greg Whitworth

Scribe: fantasai

Spec Rec Next Steps/Extra Items

  Rossen: Anything to add to the agenda?
  fantasai: I had a few items. First was publish an updated WD of

  RESOLVED: Publish updated WD of css-align

  fantasai: Next topic was this grid issue (1777), don't want to
            resolve now, just bring it to everyone's attention to
            discuss next week.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1777
  Rossen: Is the first the link?
  fantasai: Grid issue where Sergio reported that current behavior
            of 1fr implying min of auto is confusing. It's fairly
            significant and I want to discuss next week.

  scribe: dael

  fantasai: 3rd is V&U issue I think we should close no fix. It's a
            request for adding pi radians.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/309
  fantasai: This one ^
  Rossen: I'll try and add to end of agenda. We have a shorter one.
          Unless there's anything else from you, does anyone else
          have extra issues? Especially from APAC friendly call only
  Rossen: Okay, I'll take that as no.

Spring and summer (July-ish) f2f planning for 2018

  shans: Can we refer to month not season?
  Rossen: Okay. I believe this is July/Aug 2018.
  shane: We...I believe we took on responsibility to host and looked
         at a number of options. Sydney is looking most viable. Down
         side is it's winter, but it's about the same as summer in
         San Francisco.
  fantasai: You could try co-hosting with Mozilla if you want Canada.
  shane: Yeah, it was within Google we couldn't find Canada. If
         there's a strong feeling Canada is better we can keep
         looking. I'll always prefer local.
  Rossen: If the host prefers Sydney, will there be any members that
          couldn't make that?
  <Florian> If (location == France) { any date is fine } else {
            prefer beginning or end of summer, not middle }

  Rossen: I believe our last discussion was referring to this as
          late July. Maybe early.
  nainar: Options in the doodle are all of July.
  fantasai: Did we want to consider August?
  nainar: We can.
  shane: There's no reason not to. We have a room hold in July but I
         think we would be fine for August.
  astearns: We tend to lose Europeans in August.
  Rossen: August will be harder for me.
  Florian: From a based in Japan perspective early summer or late
           summer is easier. Early July or late Aug.
  Rossen: Okay.

  scribe: fantasai

  Rossen: August is in the middle between the April meeting and TPAC.
  shane: When is TPAC?
  Rossen: Late October.
  <dauwhe> TPAC: October 22-26
  shane: Late August seems too close to TPAC vs Berlin.
  <fremy> Slight preference for early July myself.

  Rossen: [asks a question, missed the question]
  Rossen: Should we at least sort out dates? Maybe early July?
  <Florian> I don't think either of the location makes a difference
            as to the date. 1st half of July works for me.
  Rossen: Hosting options seem to be Sydney, and maybe Canada.
  Rossen: Any objections to 1st half of July?
  shane: I would nail down the week, because of holidays in Sydney.
  shane: 1st week of July would be better.
  Rossen: So 1st week of July is better for hosting in Sydney.
  Rossen: Does anyone have any hard objections? Otherwise we'll
          resolve on 1st week of July.

  RESOLVED: 1st week of July 2018, likely in Sydney, actual location

  fremy: Since we're resolving Sydney and this is APAC call, many
         people in Europe aren't here to comment
  Rossen: We can rediscuss next week if needed
  * fantasai thinks SF or LA would be good options, direct flights
             from just about everywhere we have members.

  Rossen: Wrt April F2F in Berlin, we need to know how many people
          interested in the venue hotel
  <astearns> https://wiki.csswg.org/planning/berlin-2018
  Rossen: If so, please add to planning wiki.

Review of the optional test failures in the css-ui-3 test suite
  Scribe: dael
  Github: https://github.com/w3c/csswg-drafts/issues/1770

  Florian: During the previous F2F I reported about the test suite
           status. Close to done and passing. Optional tests don't
           pass for a lot. tantek suggested we review.
  Florian: In the GH issue you have the list of what fails and why.
           First list is nothing passes, second is only 1 passing.
           Short summary I think we're okay. Most of these are may
  Florian: I think that's fine.
  Florian: There's a bunch of failing may tests, but there are a few
           that aren't and we can talk about.

  Florian: First is outline 005 which says the outline should follow
           the border edge. It fails in all browsers. In Safari this
           happens when outline-style is auto.
  Florian: I think this is fine. This is a thing we knew about when
           we decided. I feel okay with that.
  myles: What are you proposing here?
  Florian: I'm suggesting this is all fine. Or we decide this
           optional fails are bad. I don't think we need a change,
           but tantek suggested review so I'm going through the
           list. Does that sound good?
  fremy: It does to me.

  Florian: First is currently all browsers in most cases don't round
           the outline when the border radius is round. Safari does
           it when it's auto. Are we happy with spec as-is?
  Rossen: Spec is should?
  Florian: Yes.
  Rossen: Okay. Anyone unhappy with this? If not we can move on.
  Florian: Right.

  Florian: Next 4 are outline 13-16. FF passes 13, everyone fails
           the rest. If you put a negative outline and if you put a
           large one and it meets in the middle. The spec has error
           handling to keep the outline from disappearing when it
           meets itself.
  Florian: Everybody that's failing fails differently. This is a
           should. I think this should stay, it's a rare error case.
           Most browsers do bad, FF less bad. So it sounds
           reasonable to me.
  Rossen: Unless anyone objects we can move on.

  Florian: Text overflow 18. Spec suggests when you have text
           overflow ellipsis, when the user selects the ellipsis the
           spec suggests the user selects the test behind the
           ellipsis. This is a should. Suggested behavior seems more
           friendly. Is this misguided?
  Rossen: This borders with editing and we shouldn't define editing,
          but I'm fine with a should.
  hober: Should is a stronger verb.
  Rossen: Are you suggesting may?
  hober: I think we should file bugs on the browsers.
  Florian: I think I have filed bugs on most of this.
  Rossen: Let's continue unless there's a strong reason to not have
          a should.

  Florian: Next ones are resize tests. Normally resize only applied
           to overflow something not visible. We have a may to allow
           applying to a long list of other things. Safari and
           chrome do iframes. No one does anything else. Bugs are
           filed. This is may. I'm fine as is.
  fantasai: Fine to me.
  Rossen: Looks good. Next is cursor?

  Florian: Yes. Cursor takes url pointing to an image. In newer
           specs we have url or a list of other options. You may
           support these in addition to image. No one supports. It's
           a may.
  Rossen: We're fine on the edge side.

  Rossen: Next is cursor text 002.
  Florian: If you have horizontal text the text should be vertical.
           If you have transform rotate the cursor can angle to the
           text rotate. It's a may.
  Rossen: Sounds reasonable. It's a more advanced feature.
  Florian: Could happen on svg with a path. It opens the door.

  Rossen: Okay. There 4 more optional tests with 1 pass? Can we go
          through those as a group?
  Florian: Since we have one pass, 3 should and 1 may I'm okay with
           a blanket this is fine.
  Rossen: I think everyone can go individually. I want to be mindful
          of time.
  Florian: Understand.
  Rossen: So 4 optional test, FF passes 3, Safari passes the 4th.
  Florian: And the last two are subcases we've discussed.
  Rossen: If no objections we can call all of those resolved so this
          issue is resolved and closed.
  fremy: 21 is weird. [reads] I don't know how you'd do it, but FF
         does. All the other ones I'm fine.
  Rossen: I didn't catch all, but it didn't sound like an objection.
          Does anyone object or want something different?

  RESOLVED: Leave spec as-is, no changes. Accept all current
            requirements as listed in issue.

CSS UI status update

  <Florian> https://github.com/w3c/web-platform-tests/pull/6934
  Florian: CSS UI status update.
  Florian: One PR for one test with a should that passes in 1
           browser. Once someone approves all except 2 tests pass in
           2 implementations. I've filed bugs on those two. I'll
           paste in IRC.
  <Florian> Remaining CSS-UI Bugs on mandatory requirements with
            less than 2 implementations: https://pastebin.com/vu1CCTMv

Should viewport units still depend on scrollbar width for
  Github: https://github.com/w3c/csswg-drafts/issues/1766

  Rossen: Can anyone take this?
  TabAtkins: I'm here.
  TabAtkins: This may not be decided yet. Core of the issue is, vw
             and vh we specified that if you do overflow scroll on
             root scroller we take into account size of scrollbar so
             100vw fills the visual viewport
  TabAtkins: FF has broken code for this, Servo isn't planning on
             doing it. We, Chrome, don't do it either. dbaron is
             asking if we can remove that so vw and vh are based on
             ignoring scrollbar. My original obj is that destroyed
             usefulness of these and we decided it would default to
             no scrollbar size.
  TabAtkins: After we thought more for layout you don't need...I
             don't think many if any vw cases need 100 to be
             exactly  the right size. You can use flexbox or gird
             for similar or better. For other things with viewport
             limits such as scaling fonts, they're fine with a
             little off.
  TabAtkins: I could be convinced that vw are lower fidelity.

  fantasai: I'd ask around a bit more. I can imagine wanting
            something to fill the viewport when you click. Doing
            layout of sizing of tables if they're too big to wrap
            them in their own scrollbar. I can see cases.
  TabAtkins: I'd like to see examples that aren't solved in other
             ways. I should look at the table case again.
  smfr: The author of the webkit blog came asking about this He
        wanted his viewport to be full bleed and 100 vw was
        triggering full scrollbars.
  smfr: This is only an issue for always on scrollbars.
  TabAtkins: I suspect that's why it didn't make it into webkit and
             then chrome inherited that code.
  TabAtkins: You seem to be arguing we should keep spec as-is so it
             can respond to scrollbars?
  smfr: Not necessarily. Independently we should think of ways to
        solve this.
  fantasai: We should solve it with these units. If we don't how do
            we fix this? Another unit?
  Rossen: fwiw we don't support in edge or ie either. I'm in support
          of what TabAtkins said and his rationale. At the same time
          I sympathize with fantasai were if we're going to have
          units to enable this, this is the unit.
  Rossen: Sounds to me like none of the impl have it and the only
          one with it wants to drop and it's broken. If we allow
          scrollbar styling that would have more severe effects for
          how we resolve scrollbar width. What are we doing.

  Rossen: Options are vw always resolved to full viewport ignoring
          scrollbars. For most scenarios you know how big the
          viewport is and if you care about scrollbars you can do
          calc and subtract some pixels.
  myles: You can do better with dino's proposal from the last f2f.
         One of those variables can be the scrollbar width.
  Rossen: Even better. Love it. That's a great option once we have
  Rossen: Those are the options I see, what do we do?
  myles: Sounds like there's agreement to drop.
  <fantasai> :(
  Rossen: Agreed. Obj?
  <fremy> fine with dropping

  RESOLVED: Drop the requirement to subtract scrollbar size from
            vh/vw units for overflow scroll.

  myles: Can we do #5 first?

font-feature-settings property should be reset by font shorthand
  Github: https://github.com/w3c/csswg-drafts/issues/1349

  many: thought we resolved that
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Aug/0042.html
  Rossen: It was agenda+ on Aug 2 and I guess it wasn't removed.
  <fantasai> "- RESOLVED: All font-* properties are reset by the
             font shorthand, except font-presentation and

@font-face unicode-range and first available font
  Github: https://github.com/w3c/csswg-drafts/issues/1765

  myles: fremy do you want to take this?
  fremy: Basically one dev on our team impl unicode range for font
         face and realized if you want to follow spec you compute
         based on first available font that matches any character.
         So any font could be that and you need to download every
         font which defeats the purpose. All browsers only care
         about the space character. Proposal is to reflect that in
         spec so first available font is the one that would match
         the space character.
  fremy: Shouldn't be controversial.
  fantasai: I don't think intention is first font to match every
            character, it's any character. So if the font has that
            character in it. The impl seem to be using the space
            assuming that a font that includes any glyphs at all
            will at least has one for U+0020.
  myles: The spec says "any character" so proposal is to change to
         read "the space character"
  fremy: Correct.
  myles: Fine with us.
  TabAtkins: It implies first font that doesn't have a unicode range
             or has one so that doesn't mean anything how it's
             written. So, sure. If space is what people are relying
             on it's not a bad choice.

  Rossen: Do we have a proposal?
  fremy: Proposal is the first available font that would match the
         U+0020 (space) character
  Rossen: Webkit is fine it sounded like. Objection to this proposed
  myles: Not an objection, but this text is in both fonts 3 and 4 so
         this will go into both.

  fantasai: I'm not sure that is actually the issue. It seems to be
            a side effect.
  Rossen: What is the actual issue?
  fantasai: I think the interesting thing here is that...
  fantasai: The issue is talking about a font that has glyphs that
            don't match its unicode range so it has no glyphs that
            will be used, but it's used as first available font.
            Should that font not be used in the font list because it
            will never be used.
  fremy: Main reason is we don't want to change the font unit when
         we change the font. It does not depend on contents.
  fantasai: Question is regardless of the content you define a font
            that doesn't have any glyphs. The overlap is 0 glyphs.
            No space, no character. Should that be used for the
            definition and that's not clear.
  TabAtkins: Problem is you have to then download fonts
             speculatively. And that's an author error. If you say
             it covers a certain range we should believe you.
  fantasai: If that's the case and we're saying we'll base on
            unicode range, if we change this definition the unicode
            range has picked out the characters that don't use the
            space so you wouldn't use the test font.
  TabAtkins: But browsers do that.
  fantasai: Edge and chrome are different.
  TabAtkins: Blink and webkit are same.
  fremy: Edge doesn't support unicode range right now. When we tried
         to fix we ran into this.

  Rossen: I'm going to go back to proposed resolution and as if
          there are any alternative proposals and, if not, we can
          take that text to both fonts 3 and 4. Which means 3 resets
  fantasai: Do we have anyone from Mozilla or results from them?
  Rossen: Sounds quiet.
  Rossen: I don't think we have anyone.
  fantasai: I'd suggest we get feedback.
  Rossen: We can resolve tentatively.
  Rossen: We have 3 implementations. We can take a resolution and go
          back if there's more evidence.
  fremy: On the test case FF behaves same as chrome and safari.

  Rossen: Objections to changing text to read "first available font
          that would match the U+0020 (space) character"
  fantasai: I'm getting different results on FF then on chrome
  fantasai: In FF all 3 red boxes are same height. Chrome has the
            middle shorter.
  Rossen: Linux?
  fantasai: Yes.
  fremy: On windows it's the same. If it's not Ariel then the test
         case doesn't work.
  fantasai: I think it would be good to find out what Mozilla is
  <fantasai> I have Arial installed
  Rossen: Mozilla will have the ability to re-raise. In the presence
          of new information we can reconsider.

  RESOLVED: Change spec text to read first available font that would
            match the U+0020 (space) character.

  <Rossen> https://github.com/w3c/csswg-drafts/issues/1777
  <Rossen> https://github.com/w3c/csswg-drafts/issues/309
  Rossen: We've over time. fantasai did have two issues ^. Please
          take a look so we can discuss next week.
  Rossen: Thank you everyone for joining. We'll talk next week.

Received on Thursday, 7 September 2017 12:09:43 UTC