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

[CSSWG] Minutes Telecon 2017-10-04 [css-flexbox] [css-grid] [motion]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 5 Oct 2017 21:25:15 +0300
Message-ID: <CADhPm3ucBBN9=d-gcGvVK1nQZVY084smREGCemFdrcFbdFwRsw@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.
=========================================


Flex sum < 1
------------

  - RESOLVED: Revert the previous resolution regarding flex sum <1 (as
              has already been done) and solicit dholbert's review.

Reconsidering the meaning of 1fr
--------------------------------

  - RESOLVED: Specify that custom styling of the underline overrides
              the UA-rendered underline (not just adds to it). Details
              to be determined in a separate issue.

offset-path strings
-------------------

  - RESOLVED: Computed-value normalize case of path commands (to the
              absolute version).
  - RESOLVED: Figure out details on normalizing similar commands into
              more general ones.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0003.html

Present:
  David Baron
  Brian Birtles
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Jihye Hong
  Dean Jackson
  Myles Maxfield
  Naina Raisinghani
  Manuel Rego Casasnovas
  François Remy
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Shane Stephens
  Greg Whitworth
  Eric Willigers

Regrets:
  Rachel Andrew
  Bert Bos
  Benjamin De Cock
  Tony Graham
  Dael Jackson
  Vladimir Levantovsky
  Thierry Michel
  Michael Miller


Scribe: TabAtkins

Spec rec progress
-----------------

  florian: One bug left on UI tests
  <florian> Last UI-3 Bug, firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1376718
  <florian> Last UI-3 Bug, Edge:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13874660/
  <florian> Last UI-3 bug, Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=737452
  <florian> Last UI-3 bug, Safari:
https://bugs.webkit.org/show_bug.cgi?id=173910
  <florian> To be clear on UI, there are other bugs in various
            browsers, but that's the last thing that doesn't have 2
            implementations

Flex sum < 1
------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/1735#issuecomment-332671797

  astearns: My understanding was that we had a resolution, but we had
            to revert it because there was a discontinuity.
  fantasai: Yes, we need to be continuous for a given flex item going
            from 0=>1, *and* for the flex container when its children
            do the same.
  fantasai: Previous resolution fixed the flex item, but it created a
            discontinuity for the flex container.
  fantasai: So our proposal ends up giving non-linear behavior for
            flex items when the sum is <1, but it's continuous.

  astearns: Has dholbert looked at the revert?
  TabAtkins: He hasn't commented yet, so if he's seen it he hasn't
             approved it.
  astearns: So should we wait until we get feedback?
  TabAtkins: I'd prefer to get someone invested to give positive
             feedback.
  rego: I think we should accept the proposal.
  astearns: Have you reviewed the reverted text.
  rego: No, haven't checked the new text specifically, but I want
        continuity.

  astearns: fantasai, what do you want to do?
  fantasai: Resolve to revert to the previous text unless dholbert has
            opposite ideas.
  astearns: Any objections to reverting?

  RESOLVED: Revert the previous resolution regarding flex sum <1 (as
            has already been done) and solicit dholbert's review.

Styling the ::spelling-error marker
-----------------------------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/1828

  florian: In Pseudo 4 we have ::spelling-error and ::grammar-error.
           The spec doesn't say that the browser is supposed to use
           these to put their own markers.
  florian: So technically it's valid for your outlines to *add* to the
           browser UI, not replace.
  florian: So the spec needs to state that...
  florian: Maybe do UA stylesheet to mandate what they look like by
           default, or just say that the UA one has to use
           ::spelling-error
  <fantasai> +1 to Florian's proposal
  <fantasai> to require that UA styles are expressed in this manner
  TabAtkins: Don't mandate the UA style, let it do whatever. But
             definitely mandate that it replaces.

  myles: The existing markers don't necessarily map to something in
         CSS, so we can't do it precisely in the UA stylesheet.
  myles: For example, the MacOS style is under-dots with a gradient
         inside, and we try hard to make sure there's never a partial
         dot.
  <fantasai> I don't think making sure there's never a partial dot is
             incompatible with CSS
  <fantasai> CSS doesn't mandate dot spacing, leaves it up to the UA
             so that it can do exactly these things
  florian: Okay, so how to specify it?
  florian: Any property specified, it shuts down the native one?
  florian: That seems too much, they might just want to do the color.
  myles: Adjusting the color of our dots isn't possible. It should be
         just like 'outline'.
  TabAtkins: Agreed.
  fremy: Yes, it should also have a value that means "native", just
         like outline.
  tantek: Agreed as well, it's also like borders - the natives might
          look more special than you can get with built-in stuff.
  tantek: The key aspect here is normative text that says "if you draw
          it normally, don't draw it when CSS specifies one".
  <dbaron> Tantek was also pointing out to me that what myles
           described with the dots sounds like a new underline style
  astearns: And we can agree on that text regardless of whether UAs
            can specify something today.

  florian: So is that sufficient? If you set color, does that count as
           "CSS-drawn"?
  <fantasai> "Any styling provided by the author must override, not
             duplicate, any particular aspect of the UA's default
             styling, even if the exact characteristics of that
             styling are not expressible in CSS."
  myles: That seems like a clear intent that they want a pink error,
         should switch to the CSS one.
  florian: So what happens then? What style?
  TabAtkins: The default one.
  florian: The default is "none".
  <tantek> "text-decoration-style:system-spelling-error"
  fantasai: Can't change the default value - it's 'text-decoration',
            used more widely than just ::spelling-error.
  * fantasai thinks ppl need to hear tantek's comment
  fremy: We can say that the default pixel is "1px wavy red" in the UA
         stylesheet, and the browser is free to render whatever way it
         wants...
  fremy: Say that if you don't override anything you get the UA
         rendering, but if you override something you get the other
         values defined in the spec.
  <tantek> or even just text-decoration: system-spelling-error
  <tantek> since it may affect color/style/etc.
  <tantek> and there may be no way to decompose the
           system-spelling-error "look" into components
  <tantek> same with text-decoration: system-grammar-error
  <tantek> just thinking off the top of my head
  <tantek> please consider these proposals with a grain of salt. or is
           that sand. I forget.

  florian: Model after outline-style:auto which lets UA do whatever,
           or is the same as solid. We could do something similar
           here, with text-decoration-style: auto, which can do what
           it wants, or fall back to wavy.
  florian: Only problem is that then you can use the spelling-error
           style on any element.
  TabAtkins: Is that a problem?
  florian: No, I think it's useful, so you can do your own spelling
           marking in JS or something and have it match with native.
  <gregwhitworth> this sounds like possibly an option for env()
  <gregwhitworth> env(spelling-error)
  astearns: So it sounds like we want to add a system-spelling-error
            style for text-decoration.
  <tantek> haven't through through the connotations for the cascade,
           but similar to outline right?

  myles: We have a new concern, and have the WK person implementing
         this.
  Daniel: So are you proposing these for each of the error types?
  florian: Just the two.
  TabAtkins: We only recognize two with pseudo-elements so far.
  * fantasai notes that offset is planned for L4
  Daniel: Sounds great to opt into the system-spelling one.
  Daniel: What if they want to style the errors and achieve the look
          of the system one.
  Daniel: So on Mac the spelling errors are always drawn beneath
          existing text decorations, so if you have underlines, the
          spelling markers are put below them.
  Daniel: How do you achieve the same effect?
  florian: No problem here, I think. The underline isn't set on the
           spelling error, it's set on some parent element. The
           spelling error decoration is set on ::spelling-error.
  <dbaron> maybe somebody should write up what the proposal is and we
           should come back to it once people had a chance to read and
           ask questions?
  <astearns> +1
  Daniel: I specifically mean if you just want, say, a black wavy
          underline, but definitely underneath the existing underline.
  fantasai: We have a control for that in Text level 4.
  florian: text-underline-offset.
  <florian> https://drafts.csswg.org/css-text-decor-4/#underline-offset
  Daniel: Okay, so that would allow offsetting.
  fantasai: Yeah. The "auto" value is different though - "auto" just
            means "UA decides on the offset appropriately", and can
            use text information or something.
  fantasai: Currently can't pay attention to other decorations to
            avoid overlapping, we would need another value for that.

  astearns: So we're going to resolve that if the ::spelling-error has
            t-d styles, we'll use CSS drawing for that, and override
            the system-level decoration.
  dbaron: I think that might need to be specific to certain properties.
  dbaron: Don't want it to happen just if the selector exists, want
          specific properties to be specified.
  florian: The proposal was to have a text-decoration value of
           "system-spelling-error" that gives magic rendering, and if
           that gets overridden, it uses CSS rendering instead.

  TabAtkins: So back to what dbaron said in the chat, can we get the
             actual new proposal in the issue, and resolve on it next
             week?
  <gregwhitworth> I must have missed this - but who is asking for this?
  <gregwhitworth> ^ the feature as a whole
  astearns: Yeah, can we resolve to just do the UA overriding?
  <tantek> ok with that

  RESOLVED: Specify that custom styling of the underline overrides the
            UA-rendered underline (not just adds to it). Details to be
            determined in a separate issue.

  ACTION Florian to propose text to resolve issue 1828
  <trackbot> Created ACTION-864

  <florian> fantasai: if I propose text to add system-spelling-error
            and system-grammar-error to text-decoration, should I do
            that as a PR to level 3 or 4?
  <florian> fantasai: I'd prefer 3, since level 4 is a semi-empty diff
            spec that doesn't even have the relevant properties. But I
            am not sure how much you're trying to wrap up level 3

offset-path strings
-------------------
  GitHub: https://github.com/w3c/fxtf-drafts/issues/225

  ericwilligers: When you animate a path string in SVG using both
                 upper and lowercase commands, there's no way to read
                 it back out. But CSS can do so.
  ericwilligers: So we have a proposal to normalize the path strings
                 to a canonical representation during animation.
  ericwilligers: Related: You're not allowed to animate between
                 different commands even if they're very similar, like
                 H (horizontal line) to L (any-direction line).
  ericwilligers: There was a suggestion that we should allow it.
  ericwilligers: There was little UA participation of this in SVGWG
                 tho, so bringing it up here.
  shane: I don't think anybody thinks its a *bad* idea, but just low
         use-cases for explicit promotion.
  ericwilligers: So I'd like to ship offset-path and d, and it's more
                 useful if you can animate them.

  TabAtkins: So three proposals:
  TabAtkins: 1) animate path(), affecting motion-path and d (this
                already has a resolution on it)
  TabAtkins: 2) When animating, normalize abs and rel commands (upper
                and lowercase) to a single canonical form (uppercase,
                specifically) so you can animate "h" and "H".
  TabAtkins: 3) When animating, normalize "families" of similar
                commands into a single canonical command, so H/V/L all
                become L, etc, because they're just convenience
                syntaxes for each other and not significant
                differences that should stop animation.

  shane: Animation of path() in SVG is pretty underspecified in SVG2
         right now.
  shane: It says that 2 property values can only be interpolated
         smoothly when the paths have the same structure (same number
         and type of command).
  shane: "type" isn't really specified - could mean individual
         commands, or ignoring abs/rel, or in families.
  shane: It's hard to say what SVG2 *intends* to specify here for
         interpolation.
  shane: I think you want normalization to reflect interpolation
         behavior.
  shane: If we said today that we wanted path() to animate between two
         lines, it should promote between any two line types.
  shane: Eric suggests shipping the de facto SVG behavior now, iterate
         on it later. I'm a little afraid of being able to change that
         later.
  shane: I think the current behavior is poor for authors. If you
         wanna do any animation you have to fall back on tools, and
         those tools don't exist today.
  dino: I think we need to define an animation between two paths of
        any type.
  dino: If what we come up with conflicts with what's about to ship,
        defined in SVG1, that would be sad, but I don't think it would
        be a horrible break.
  dino: In general I think we should give authors a better experience.
  TabAtkins: I think if we ship current SVG and then upgrade later,
             it'll just make things start animating, which is a minor
             break and probably fine.
  shane: But also would change computed style - we'd want eventually
         to normalize eagerly in computed style.
  TabAtkins: Ah, that's more of a change than I thought.
  <birtles> I think there's precedent for this with `transform` (i.e.
            we define rules for animating between different types of
            transforms and we also normalize to matrix() in computed
            style)
  <birtles> normalizing in computed style also makes parsing the value
            a lot easier for authors
  <birtles> there are a lot of SVG scripts hanging around that only
            deal with the subset of path commands the author could be
            bothered to deal with, since there are just too many
            otherwise

  fremy: I'd like to have Bogdan around.
  shane: One of Bogdan's concerns was no use-cases; we completely
         disagree. As soon as you try to path-animate, you run into
         this. It's basically every single use.
  shane: He also thought it might prevent them from doing certain
         types of OS acceleration.
  shane: We've implemented generic path animation before, it's more
         expensive, but not something we should consider a concern I
         think.
  TabAtkins: I think B commands are significant - you get different
             animation behavior whether you animate a B or resolve it
             away. It seems useful to keep.
  shane: I do think we shouldn't add or remove commands, just promote
         to the most general.
  shane: And then we could maybe have magic for when the number of
         commands don't match, like transforms do with matrix().
  shane: We have an impl of that, and it works pretty well.
  astearns: So should we resolve on the abs/rel normalization today?

  RESOLVED: Computed-value normalize case of path commands (to the
            absolute version).

  astearns: And it sounds like we're interested in normalizing similar
            commands, but don't yet have consensus on details.
  shane: Should we open something on the CSSWG tracker?
  astearns: Yes.
  <myles> shane: if you make a new issue, can it include videos for
          things like that TabAtkins was talking about with the
          bearing commands?
  <shane> myles: for sure
  <shane> or at least code demos

  astearns: Anyone object to the general idea of normalizing similar
            commands?

  RESOLVED: Figure out details on normalizing similar commands into
            more general ones.
Received on Thursday, 5 October 2017 18:26:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:26:10 UTC