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

[CSSWG] Minutes Telecon 2018-09-05 [css-text-decor-4] [fill-stroke] [css-ui-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 5 Sep 2018 21:26:48 -0400
Message-ID: <CADhPm3uBqZ8JpHu-r6+szYHHEeC4KEoF14rJYzRDRAtPq=S_kw@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.

F2F Scheduling

  - RESOLVED: Mid-Year F2F will be in Toronto hosted by Mozilla the
              week of June 3
  - RESOLVED: Will do June 4-7, Tuesday-Friday
  - RESOLVED: CSS 4-6 (Tuesday-Thursday) and Houdini 7 (Friday)
  - Early Year F2F is likely the week of 25 February in Honolulu, but
      this isn't completely confirmed yet.

Text Decor 4

  - RESOLVED: text-decoration-skip-ink only takes 2 values, none and
              auto with auto being default (Issue #2818)
  - RESOLVED: Add normative text that states the auto value forces the
              UA to add the appropriate level of skipping (Issue #2818)


  - RESOLVED: Only accept unitless values on SVG 1.1 supported
              properties with the exception of baseline-shift (Issue


  - RESOLVED: Don't fix and explain why in the issue (Issue #1815:
              Anything that creates a stacking context should sort in
              the positioned descendants z-ordering list)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0000.html

  Rossen Atanassov
  Tab Atkins (IRC Only)
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Benjamin De Cock
  Elika Etemad
  Dael Jackson
  Dean Jackson
  Myles Maxfield
  Cameron McCormack
  Xidorn Quan
  Melanie Richards
  Alan Stearns
  Fuqiao Xue

  Tantek Çelik
  Simon Fraser
  Tony Graham
  Geoffrey Sneddon
  Lea Verou

Scribe: dael

F2F Scheduling

  Rossen: Let's go ahead and get going
  Rossen: Hello everyone. As usual, are there any extra agenda items?

  fantasai: Did we settle on F2F dates next year? I think Rachel and
            Jen would like it.
  Rossen: Settled on dates but not place. I was going to ask TabAtkins
          who is IRC only about the first meeting of next year. He
          took an action to figure out if they can host
  Rossen: TabAtkins please get back to us.
  <AmeliaBR> Dates on the wiki are still very -ish:
  Rossen: Rachel and Jen the dates are stable
  astearns: I don't think you're right. I think TabAtkins is looking
            at 2 weeks in Feb.

  <TabAtkins> As mentioned earlier today, I'm in discussion with the
              Moana Surfrider hotel right now. Plan is last week of
              Feb; 90% likely. 10% chance of 3rd week instead.
  astearns: Dates for middle meeting we're waiting on figuring out
            when CSS Day will happen. That was finalized today
  Rossen: I stand corrected. Only stable meeting is TPAC next year
  Rossen: [reads TabAtkins]
  Rossen: Sounds like last week of Feb in Honolulu...90% is high
          likelihood. Let's communicate this with people as they start
  florian: Don't buy tickets but keep room

  dbaron: May/June- I had the room in Toronto reserved for 2 weeks,
          May 27-31 or June 3-7
  dbaron: CSS Day, we were worried it would conflict with the later
          week but it doesn't. CSS Day is 13th and 14th
  dbaron: June 13 and 14
  Rossen: Provided we're likely late Feb then probably better for late
          May/early June. I would prefer June 3-7 but that's me.
  dbaron: One other reason to prefer later the earlier dates are a US
  dbaron: I don't think there are any Canadian holidays then
  AmeliaBR: Canadian holiday is the 20th
  Rossen: So settle on June 3 hosted by Mozilla?

  Rossen: Objections on the week of June 3 so dbaron can release the
          other and people can plan?
  florian: No objection. Lots of North America travel for me, but no

  RESOLVED: Mid-Year F2F will be in Toronto hosted by Mozilla the week
            of June 3-7

  dbaron: Finalize which days are what? That's Monday-Friday
  Rossen: Will need 1 day of Houdini and 3 CSS?
  dbaron: That's what I'd assume.
  Rossen: Start Monday? or Friday?
  florian: Weren't we going to merge?
  Rossen: I don't think easy to merge Houdini and CSS, but tracks in
          CSS we can.
  Rossen: In last 3 meetings even with merging we've finished the
          agenda or couldn't finish.
  florian: Okay.
  Rossen: We'll have plenty to work on.
  fantasai: Prefer later half.
  Rossen: Tues-Fri?
  fantasai: Yeah
  Rossen: Anyone opposed to that?

  RESOLVED: Will Do June 4-7, Tuesday-Friday

  Rossen: Tuesday Houdini and Wed-Fri CSS
  Rossen: Or opposite
  Rossen: In the case Houdini is shorter that can be potentially
          shorter rather then starting shorter.
  Rossen: So if we have Houdini at the end people may have free time
          if we're short
  Rossen: CSS 4-6 and Houdini 7. How does that sound?

  RESOLVED: CSS 4-6 and Houdini 7

  Rossen: Back to February.
  Rossen: It will be likely last week of February. I don't think we
          can get firmer.
  Rossen: I'm assuming it's week of 18th TabAtkins as last week?
  florian: I think week of 25th
  Rossen: Might be last full week. I don't know.
  <dbaron> TabAtkins, which February week did you mean?
  <TabAtkins> Yeah, planning on *last* week. 4 days in there (3 CSS, 1
  <TabAtkins> week of 25th
  Rossen: Awesome. Feb 25th
  <TabAtkins> not firm, don't resolve. ^_^
  Rossen: Let's stop here until TabAtkins gets a firm yes.
  Rossen: At least we scoped time frame.
  <TabAtkins> yeah, will be soon

CSS Text Decor 4

Consider adding a third value (skip?) for text-decoration-skip-ink
  github: https://github.com/w3c/csswg-drafts/issues/2818

  Rossen: We wanted xidorn on the call for this.
  Rossen: Who wants to summarize?
  fantasai: This is text-decoration-skip. Issue is we had resolved on
            'auto' and 'none' values, but there wasn't an 'on' value
  fantasai: If 'auto' means platform that will in some cases not skip.
            If author wants skipping being able to say on should be
            separate. Otherwise auto means on and loses ability to be
  fantasai: Proposal is add a new value that means please skip. I
            propose skip-ink for a name.
  fantasai: Reason is we might want shorthand in the future so skip
            values can be combined without ambiguous.

  <myles> is Xidorn here? The whole reason we're discussing this again
          is to get his input
  <xidorn> myles: I am

  florian: sgtm. I remember related topics were discussed, tried to
           look. May have missed something, but found that if we have
           this it should not skip on strike-through. Agreed never
           skip on strike-through
  fantasai: Right
  florian: Other than the shorthand conversation couldn't find
           anything against this.

  xidorn: myles asked for my opinion. I commented in the github and I
          don't think I'm the one that raised this. Probably emilio. I
          didn't have issue with 'auto' and 'none' but having
          'skip-ink' is fine. As long as we don't use 'all' or

  myles: If we wanted 3 values it would be because obey platform and
         do skip-ink would be distinct.
  myles: Last time we discussed Microsoft said wanted this on by
         default. If yes all major platforms would have skip-ink same
         as auto so if yes we don't need 3rd value
  fantasai: If we have on and off as 2 values auto should be clear
            what it does
  myles: Happy to call it what you want
  xidorn: Auto still makes sense. It can depend on how implementor
          does. Implementations can decide what script to skip.
  fantasai: If you skip on some and not others it's not on.
  myles: That's true because typographical sense. Some scripts should
         never skip.
  Rossen: There are cases to optimize for not skipping. Like for
          particular font size. There's diminishing return for
          skipping on smaller font sizes.
  Rossen: If I get xidorn that's a bit more we can take different
          heuristics on when to skip but in general skipping in auto
          should be skipping. Is that right xidorn?
  xidorn: Yeah.
  fantasai: If there's any magic under the scenes that's auto and
            that's not equivalent to on. On is always and if author
            wants they should get it
  myles: Opposite view is typographically the on value is bad to use
         and no one should use it
  Rossen: And for back compat in cases...for platforms that don't have
          feature impl then auto is great for default.

  florian: We're trying to resolve now is that the auto can mean
           different levels of skipping but not no skipping at all. Is
           that what we're trying to say?
  Rossen: Kind of. And for a platform that doesn't support skipping
  florian: Sure, then you don't support the value so no skipping is a
  fantasai: There are cases where skipping and not skipping the
            heuristic of the browser might not be what the person
            wants. If you have Arabic and position underline so it's
            exactly with the dots then not skipping becomes and issue.
            I don't think it makes sense to say the UA can decide but
            the author can't
  florian: The always-on auto is bad for a universal selector but if
           you're smart if can be fine
  AmeliaBR: Agree with fantasai there should be ability of authors to
            override heuristics. Maybe one solution is to make it
            clear the value is an override or force by the name. Make
            it clear it's not what you should normally use.
  florian: I think auto and skip-ink are reasonable
  Rossen: Let's see if can resolve on...
  florian: none, auto and skip-ink
  <AmeliaBR> So it would be `text-decoration-skip-ink: skip-ink` ?
  <florian> AmeliaBR: yes, for the sake of when we have a shorthand of
            many different kinds of skipping

  Rossen: Proposal: 3 value property which is
          text-decoration-skip-ink: none|auto|skip-ink(or skip)
  Rossen: Do we care about skip/skip-ink or can we ignore for now?
  fantasai: I think resolve now

  myles: Shouldn't be a value where browser doesn't have ability to
         make your text not ugly
  florian: Don't you think author might know better in some cases?
  Rossen: Author doesn't know device and settings so it's hard to
          predict this
  Rossen: I sympathize with myles on this one
  Rossen: Start with auto and none and if when this takes off and
          there's a huge degree of requests for skip-ink we can add
          it. Removing it is harder.
  <florian> works for me. If we have two values, it should be none and
  Rossen: So back to the two values none|auto with auto default
  myles: Great idea. If goal is let users fix browser heuristics we'll
         hear from users if heuristics are no good. Then it's a great
         time to add the value
  xidorn: I agree with myles. Once we have more feedback from users on
          use cases we may revise even differently then three keywords.
  Rossen: Objections to resolve text-decoration-skip-ink only takes 2
          values, none and auto with auto being default

  RESOLVED: text-decoration-skip-ink only takes 2 values, none and
            auto with auto being default

  florian: Do we try and craft spec wording to mean that auto is for
           typographic smart, but not do nothing. Not supporting we
           don't need to take into definition of property
  <AmeliaBR> Current definition is `auto`: UA should skip over where
             glyphs are drawn
  Rossen: Levels of not supporting. You support it but for some
          devices you want this offer for battery.
  florian: If you use @supports text-decoration-skip-ink: auto can you
           expect some level of skipping?
  Rossen: I think answer should be yes.
  Rossen: myles?
  myles: Auto is meant to let browsers have freedom. Spec can describe
  florian: Freedom, but not to not skip at all.
  myles: That's fair.

  fantasai: Needs to be clear. Currently initial value means you can
            not skip. If we say that's not possible we should be
            explicit about that
  myles: My thought is if Microsoft thinks this is right we can put it
         in spec
  Rossen: Once we have support for the property having it on by
          default is the path forward. We would support that
  Rossen: Additional resolution to make those edits?
  Rossen: Objections to adding normative text that states the auto
          value forces the UA to add the appropriate level of skipping?

  RESOLVED: Add normative text that states the auto value forces the
            UA to add the appropriate level of skipping


stroke-width and stroke-dasharray accept numbers
  github: https://github.com/w3c/csswg-drafts/issues/3057

  AmeliaBR: This is broader then the stroke properties. Background-
            SVG1 properties were defined in such a way that length
            data type was extended to allow unitless numbers as length
  AmeliaBR: Causes complications. SVG2 we changed so that things were
            explicit that value for properties from SVG1 that accepted
            unitless # as length is now explicit in syntax
  AmeliaBR: Found a couple cases not properly updated including
  AmeliaBR: eric did a review
  <AmeliaBR> https://docs.google.com/spreadsheets/d/1HRzb_-S28xq7GqYKhHbMP2YQlqWLvOWSS_twLXy-I40/edit?usp=sharing
  AmeliaBR: Spreadsheet of which properties accept unitless numbers ^
  AmeliaBR: In addition to stroke-width and stroke-dasharray which is
            a spec error there is also baseline-shift and all the new
            SVG geometry properties. Blink and webkit accept unitless
            numbers on those
  AmeliaBR: Because it's a general CSS syntax issue wanted to bring it
            to the full WG

  fantasai: This was a significant point of contention in the past
            where CSS said we need length and SVG said we want
            unitless. I think before there was a compromise and I
            don't remember it. I think CSS properties taking a
            unitless length and treating it as px shouldn't have
  AmeliaBR: You think treat as only for legacy and don't do it in any
            new properties
  fantasai: Yes
  AmeliaBR: That would affect geometry prop.
  AmeliaBR: Compromise is special parsing rules in presentation
            attribute forms where at parse unitless upgraded to length
            with px. Because that we can do things where CSS needs a
  <TabAtkins> We've got a <quirky-length> production (defined in
              Quirks spec) for handling "unitless px lengths".
  heycam: We already have a bunch of examples were presentation
          attribute accepts and CSS properties need a unit so CSS
          properties never got a unitless number. I think it's
          reasonable to not extend any other CSS properties to accept
          plain numbers in the property and just leave it as the
          properties needed for SVG, allowing those for numbers
  heycam: Not allow for anything like geometry
  myles: Aside from web compat this is a fine direction

  Rossen: Add to the discussion what TabAtkins put in IRC.
          <quirky-length> for Quirks mode does support unitless for
          length. I'm in favor of not spreading this to other
          properties or modes
  Rossen: We prefer keep attributes the way they are and all CSS
          properties to continue to support lengths as they do today
  AmeliaBR: We do have SVG1 properties where there is webcompat need
            to support. Plan for SVG was to limit to the ones from
            SVG1. Somehow this slipped through blink and webkit
            implementation for geometry properties
  AmeliaBR: baseline-shift is the other complication. Significantly
            redefined in CSS, though originally in SVG1. Not sure if
            worth switching to more CSS compat syntax or keep it with
            SVG1 syntax

  fantasai: Web compat question. If there's no content dependency we
            should eliminate. If there's content that depends on
            unitless number things in CSS properties it needs to be
            incorporated in.
  <AmeliaBR> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/baseline-shift/
  AmeliaBR: Little used property outside of certain SVG editors. It's
            showing up once in Edge's scan with unitless
  fantasai: Then we should eliminate this parsing quirk
  heycam: And I guess that's what spec required. Referencing CSS text
          already doesn't have unitless number
  fantasai: Need to update stroke, can you tag the fill-stroke spec?
  AmeliaBR: Yeah

  AmeliaBR: Proposal: Unitless number as an alternative to length will
            only be accepted in those SVG properties that were defined
            as properties in SVG1.1 except for baseline-shift
  fantasai: Accept for those with a webcompat constraint is what I
            would say.
  Rossen: Objections?
  Rossen: Unitless number as an alternative to length will only be
          accepted in those SVG properties that were defined as
          properties in SVG1.1 except for baseline-shift and those
          that have a web-compat constraint
  fantasai: I think it's: Unitless numbers quirk is limited to SVG1.1
            properties where there's a webcompat constraint requiring
            it. Required for stroke-width and stroke-dasharray. Will
            not support for baseline-shift
  dbaron: Saying 'quirk' is dangerous because it sounds like it's in
          quirks mode only
  <AmeliaBR> Revised proposal: Unitless number as an alternative to
             length will only be accepted in those SVG properties
             where there is a webcompat need. Specifically:
             stroke-width, stroke-dasharray, stroke-dashoffset will
             accept it; baseline-shift won't.

  heycam: Looking through the SVG1.1 property list and those that
          don't have a CSS property only other is stroke-dashoffset
  heycam: If people have data on if stroke-dashoffset is needed...but
          given there's only 3 properties maybe we can be clear about
          the set
  AmeliaBR: There's lots of properties where we do accept it but we
            updated syntax to say they accept number
  Rossen: Agree with what you're saying heycam but we'll have to
          discuss again. We'll either add or remove properties with
          more data
  AmeliaBR: This is one reason why don't want to make it about web
            compat but rather that they were defined in SVG1.1
  Rossen: Yes, but we don't want to broadly say all, we want to limit
          the scope.
  Rossen: We can do what heycam said where we only say 3 properties
          accept or we can go with based on data we'll add and we know
          for sure about these properties.
  Rossen: Preference?

  fantasai: I'd resolve on principle and then refine list. I think
            we'll include a lot of SVG1.1  Having this number parsing
            issue limits the future so that's why we want to limit
            where this is done. Especially where we've taken SVG
            properties and broadened them. It will be somewhat
            arbitrary. Webcompat is tightest we can pull the string
  dbaron: I don't want to resolve on a principle that requires an impl
          to experiment with removing something that's interoperable
          in order to demonstrate webcompat problems. I think if
          everyone does this for a property we should spec it that way.
  AmeliaBR: I was misleading by saying a lot of properties. I guess it
            really is only the ones we've talked about. Lots of
            attributes using CSS syntax made it seem a wider issue
  Rossen: Proposal: Only accept unitless values on SVG 1.1 supported
          properties with the exception of baseline-shift

  RESOLVED: Only accept unitless values on SVG 1.1 supported
            properties with the exception of baseline-shift


Anything that creates a stacking context should sort in the positioned
    descendants z-ordering list
  github: https://github.com/w3c/csswg-drafts/issues/1815

  florian: There is a value that corresponds to the behavior everyone
           has. We say if you start selection before element and end
           after then selection must include the element in the
           middle. Someone suggested we should exclude it. So content
           before and after, but not contained element.
  florian: As far as I can tell this is not what people impl. Only FF
           supports multi-part selections. However the none value is a
           middle ground. Browsers that support multi-part must have 2
           part selection and others must make one big selection. but
           they can exclude the middle part.
  florian: That's for none and corresponds to what people impl.
           Doesn't correspond for contain, but we could do it.

  fantasai: What's most reasonable for use case?
  florian: No use case mentioned. We are mostly interop
  myles: No use case plus interop seems clear
  florian: This is from Google. Anyone know why?
  fantasai: You can say we're leaning to not because interop and we
            have no use cases. If they come back with use cases we can
  Rossen: Proposal: resolve no fix and explain why in the issue

  RESOLVED: Don't fix and explain why in the issue

  Rossen: We'll move the remaining issue to next week. Thanks everyone
Received on Thursday, 6 September 2018 01:28:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 September 2018 01:28:15 UTC