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

# Dael Jackson (2 days ago)

========================================= 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: 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: bugzilla.mozilla.org/show_bug.cgi?id=1376718 <florian> Last UI-3 Bug, Edge: developer.microsoft.com/en-us/microsoft-edge/platform/issues/13874660 <florian> Last UI-3 bug, Chrome: bugs.chromium.org/p/chromium/issues/detail?id=737452 <florian> Last UI-3 bug, Safari: 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: w3c/csswg-drafts#1735

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: w3c/csswg-drafts#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> 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: w3c/fxtf-drafts#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.

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.