W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-22 Part III: Backgrounds and Borders, CSS Align & CSS Tables, CSS Cascade, Summer F2F, SVG Paths [css-backgrounds] [css-align] [css-tables] [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Feb 2020 19:51:34 -0500
Message-ID: <CADhPm3s7=SLQD=gQWQJgSV8GEfrd5uMk2UZQDfeX3j2bkpftrg@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.

Backgrounds and Borders

  - RESOLVED: Have the computed value of the background / image layer
              properties match the number of items in the specified
              value of the property itself, not the reference property
              (Issue #4135: Number of layers in getComputedStyle
  - RESOLVED: Apply the rule for computed value list length of
              background properties to all other similar list
              repeating properties like masking, transitions,
              animations. (Issue #4135)
  - RESOLVED: Close no change (Issue #2675: Background-size with
              "<length-percentage> auto" and gradient image is not
              interoperably implemented)
  - RESOLVED: Closed WONTFIX (Issue #2426: Prevent CSS keylogging)
  - RESOLVED: Close no change [leave background-size in the spec]
              (Issue #3742: 'background-size' at-risk)

CSS Align & CSS Tables

  - RESOLVED: vertical-align operates in the block-axis of the table
              cell (Issue #4033: vertical-align on orthogonal table
  - RESOLVED: The inline axis of an orthogonal table cell is sized
              *after* the baseline alignment of the non-orthogonal
              cells in that row (Issue #4033)

CSS Cascade

  - jensimmons introduced Miriam Suzanne's proposal for custom cascade
      origins which is intended to make it easier for authors to
      handle specificity in CSS:
  - The proposal was well received and everyone appreciated the work
      done and believed it should continue. Proposed to work in WICG,
      then merge back into css-cascade-5.
  - Some specific feedback was:
      - Need to think through the interaction with !important and if
          there needs to be sub-origins.
      - The name needs bikeshedding as "origin" is already a loaded
      - It may need to be combined with other proposals to solve all
          the use cases.
      - Want to avoid a similar situation to the z-index wars with
          everything trying to be the style that shows.

Summer F2F

  - Proposed dates are Mon-Thu, week of July 27, Houdini on Monday

SVG Paths

  - RESOLVED: Add path-length as a CSS property and make pathLength
              map to it (SVG Issue #773: Path length in CSS)


Agenda: https://wiki.csswg.org/planning/galicia-2020

Scribe: heycam

Backgrounds and Borders

Number of layers in getComputedStyle results
  github: https://github.com/w3c/csswg-drafts/issues/4135

  fantasai: There's some inconsistency in how many layers we put in
            these properties
  fantasai: The suggestion is to take the computed value's list length
  fantasai: If you have a long list for background-image, but a short
            list for background-position
  fantasai: when you return getCS, do you use the original list
            length, or the number of images?
  fantasai: I think we should use the number of values specified
  oriol: In Chromium, this information is lost in the computed style
  oriol: Inheriting onto children, the information is not inherited
  TabAtkins: This is a Chrome bug
  TabAtkins: we should do the right thing and match Firefox here
  fantasai: Let's do that, and clarify the Backgrounds spec
  fantasai: which just says list, not how many items
  fantasai: so clarify to the specified number of items
  <fantasai> https://drafts.csswg.org/css-backgrounds-3/#background-repeat
  <fantasai> Computed value: list, each item a pair of keywords, one
             per dimension
  <fantasai> list -> "list of the specified number of items"
  <fantasai> or something
  <fantasai> list (of the number of items specified)

  RESOLVED: Have the computed value of the background / image layer
            properties match the number of items in the specified
            value of the property itself, not the reference property

  dbaron: Other properties? transitions
  dbaron: All of these cases are repeated lists where you key off one
          list to determine what happens
  dbaron: but I think in all cases that is the right thing
  dbaron: Transitions used to have two different types of lists
  TabAtkins: That's in V&U now
  <fantasai> Not in Values. Values just has
  <fantasai> https://drafts.csswg.org/web-animations-1/#animating-properties
  dbaron: backgrounds, masking, transitions, animations
  dbaron: sounds like the relevant list here

  <fantasai> ACTION: fantasai fix animation types of CSS Backgrounds
  <RRSAgent> records action 1

  RESOLVED: Apply the rule for computed value list length of
            background properties to all other similar list repeating
            properties like masking, transitions, animations.

Background-size: <length-percentage> auto and gradient image
  github: https://github.com/w3c/csswg-drafts/issues/2675

  fantasai: Proposal to resolve no change
  fantasai: there's some non-spec-compliant rendering
  fantasai: I don't think the spec is wrong

  RESOLVED: Close no change

Remaining Backgrounds issues

  fantasai: Going through remaining open Backgrounds issues
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3742
  fantasai: One case involving some SVG edge case

  fantasai: Another one about CSS keylogging
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2426
  fantasai: Don't know what to do with that issue
  TabAtkins: This is not even a Backgrounds-specific issue
  astearns: There was pushback from Mozilla on taking the fix
  AmeliaBR: Worth mentioning that the issue here isn't specific to
            CSS, the problem is with JS frameworks that reflect the
            content of an input as an attribute that is constantly
            updated by JS
  AmeliaBR: then CSS attribute selectors can expose that
  AmeliaBR: There are many steps involved in creating this keylogger
  AmeliaBR: not sure CSS is the weakest link

  astearns: We can either close this issue no change, or we can make
            this issue be not a Backgrounds issue
  astearns: Lacking any idea to move forward, I'm inclined to close
  TabAtkins: Fairly confident there's nothing we can do apart from
             eliminating attribute selectors
  fremy: Sounds like a framework bug
  dbaron: In the past we have considered selectors that work on form
          control values
  dbaron: but you probably shouldn't be including untrusted CSS in
          your website
  TabAtkins: I will write the rationale for closing


'background-size' at-risk
  github: https://github.com/w3c/csswg-drafts/issues/3742

  fantasai: This one weird case of SVG that doesn't have a size or
            aspect ratio
  fantasai: I don't think we should mark the entire property at risk
            for this
  fantasai: Worst case, if it's the last thing blocking REC, we can
            make the case it's a bug that will some day get fixed
  chris: Are you saying it is correctly defined but implementations
         haven't implemented correctly?
  fantasai: I believe so
  chris: I'm prepared to argue to leave it then

  RESOLVED: Close no change

CSS Align & CSS Tables
  Scribe: TabAtkins

vertical-align on orthogonal table cells
  github: https://github.com/w3c/csswg-drafts/issues/4033

  florian: If we have a table-cell which is orthogonal to the table,
           and you vertical-align it, what does that mean?
  florian: "vertical" isn't a great word in the first place, but is it
           "vertical" in the table, or in the cell?
  florian: Related, how does that interact with the justify/align
           properties that are also trying to shift the table cell
  fantasai: There are two types of properties here. *-self, which
            apply to the box itself in its context, and *-content,
            which apply to the contents of the box relative to the box.
  fantasai: vertical-align is like the *-content properties
  fantasai: When we drafted up the Align spec, we said that
            "align-content: normal" looks up vertical-align and does
            what it says.
  fantasai: (for table cells)
  fantasai: That works as expected for non-orthogonal cells. But for
            orthogonal ones, which writing mode is it using?

  fantasai: The *-content properties work in the container's writing
            mode (the table cell). But vertical-align probably applies
            in the table's writing mode.
  fantasai: So one option is that vertical-align doesn't apply to
            orthogonal cells.
  fantasai: Second is vertical-align applies when align-content is
            "normal" and in the appropriate (table's) axis
  fantasai: Third is that both align/justify-content is potentially
            affected by vertical-align, and you use the writing mode
            of the table to figure out which property on the table cell
            cares about vertical-align.

  fremy: Third was the behavior of EdgeHTML.
  fremy: vertical-align worked the same whether you had table cells or
         inline blocks.
  fremy: In both cases it cared about the line's direction, not the
  fremy: Complication with tables is just that, at the end, you have
         to alter the size of the cell to make them all the same
         height. But before that, the algorithm is identical to
         inline-blocks in a text line.
  fremy: So based on that, I think it makes the most sense for
         vertical-align to work the same in both, applying in the axis
         of the line.
  fremy: Downside is that you lose some control here; you can't
         necessarily apply the place-* keywords because vertical-align
         has already added magic padding to align things.
  fremy: Possibility is that if you say "*-content: normal", you do
         the normal vertical-align stuff, but if you say any other
         keyword, vertical-align has no effect.

  florian: Initially I thought this was counter-intuitive, as
           vertical-align on table-cells doesn't *seem* to do the same
           as alignment; because of the extra padding added, it felt
           like it wasn't shifting boxes, it was shifting the content
           of the box.
  florian: So if that's your model, you might think that it should
           align in the cell's writing mode, rotated relative to the
  florian: So it's a little counter-intuitive to me, but
           vertical-align is anyway, and the underlying model is
           sensible. So as long as we get *-content to actually work
           on table cells, you can achieve whatever result you wanted.
  florian: If vertical-align was the only property we could use, we
           might want something different, but as the spec stands it
           seems okay.

  dbaron: A lot of legacy table stuff maps into vertical-align or
          text-align depending on writing-mode. Does this cause them
          to ever act on the same axis?
  fremy: I think so, yes, for any orthogonal cell.
  florian: I think it's a problem that previously you used text-align
           and vertical-align to control everything, and having them
           always be perpendicular was good, but now we have the
           *-content properties which definitely are perpendicular.
  dbaron: I think that's not *great*.
  florian: vertical-align and text-align are already parallel for
           orthogonal inline-blocks
  dbaron: They're a bit different because table-cells have a special
          behavior for vertical-align.
  fremy: Using the *-content properties you get full control. The old
         properties didn't always give you full control anyway.
  fantasai: I think dbaron's issue is valid. The model of
            vertical-align requires that the content is smaller than
            the table cell and you add padding.
  fantasai: In text-align, you rely on the fact that the linebox fills
            the table cell. Text-align shifts content within the line
  fantasai: vertical-align doesn't have stretch, it aligns you to some
            spot, and only applies if the item is smaller than the
  fantasai: So basically orthogonal cells won't be affected by
            vertical-align at all, since the linebox will fill the
            full height.
  TabAtkins: Yeah, I think that's what we expect actually.
  florian: Another possible model is that the vertical-align applies
           first, then you vertical-align the tight bounding box of
           the text.
  dbaron: Too many fundamental model changes for an edge case.
  florian: So we're saying that text-align applies in the only axis it
           can possibly make sense, and vertical-align applies in the
           table's writing mode.
  (parallel directions)

  TabAtkins: So what happens today?
  fremy: Orthogonal cells don't work at all in Chrome or Safari,
         EdgeHTML used the behavior we're discussing, and Firefox has
         broken sizing behavior.
  <AmeliaBR> If anyone else wants to look at current browser behavior,
             I made a test:
             Chromium currently ignores `writing-mode` on a `td`.
             Firefox supports them, though it's weird. It uses the
             table's definition of top/bottom for `vertical-align`
  dbaron: So my preferred suggestion is that both vertical-align and
          text-align work on the cell's writing mode.

  fremy: Either case is potentially weird. I think it's weird to not
         follow the same model as inline-block.
  fremy: Maybe come up with a lot of examples and see what looks most
  florian: I think from an author point of view what dbaron proposed
           makes more sense.
  florian: You've still got the two properties, they just rotate
  fremy: Still a difference - you'd have to redo row layout here,
         where in the "just stretch it" model you don't.
  dbaron: You need to redo layout once you discover the final row
          height anyway, for percentages.
  florian: Every time I've used orthogonal table cells I've tripped
           over this, and wanted dbaron's behavior.

  fremy: So if I do make that change, would anyone want to implement
  dbaron: Which change?
  fremy: That vertical-align and text-align both work in the cell's
         writing-mode, so you have to do a second layout pass.
  dbaron: You do a second pass, and it can only increase the height.
  fremy: Yes
  dbaron: In principle this seems reasonable, we have a bunch
          orthogonal cell bugs that haven't been a priority.
  TabAtkins: I can volunteer Aleks to look at this, yeah
  fantasai: The inline axis of an orthogonal cell is sized *after* the
            baseline alignment of the non-orthogonal cells in that

  RESOLVED: vertical-align operates in the block-axis of the table
  RESOLVED: the inline axis of an orthogonal table cell is sized
            *after* the baseline alignment of the non-orthogonal cells
            in that row

CSS Cascade

Custom cascade origins
  github: https://github.com/w3c/csswg-drafts/issues/4470

  <jensimmons> Slides: https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC
  jensimmons: Possibility of custom cascade origins, controlled by
  jensimmons: Part of a larger convo, which could be called "modernize
              the cascade"
  jensimmons: Why modernize? Some folks argue that specificity was
              designed for a simpler time, when one or a small number
              of people wrote the CSS for a site. Today CSS is
              maintained over years by large teams, and the cascade
              gets really hard.
  jensimmons: If a dev gets a ticket, they can't really re-architect
              the whole page's cascade to fix that one thing.
  jensimmons: Lots of ways people attack this.
  jensimmons: (1) just do it right the first time
  jensimmons: (2) OOCSS, SMACSS, BEM, etc
  jensimmons: (3) Only ever use one class, to give identical
                  specificity and remove the cascade.
  jensimmons: (4) overuse !important
  jensimmons: (5) CSS-in-JS, ignoring cascade again
  jensimmons: Problem there is no way to control order CSS is loaded.
              No wonder the cascade is confusing!
  jensimmons: (6) just inline-style everything, screw selectors
  jensimmons: Why not use specificity as designed?
  jensimmons: IDs increase specificity, but can only use it once per
  jensimmons: Not great for components.
  jensimmons: Element selectors work well for simple defaults, but too
              dependent on doc structure, and hard to use otherwise.
  jensimmons: So leaves a lot of these teams only using classes,
              attributes, and !important
  jensimmons: [shows example]
  jensimmons: [Tailwind CSS]
  jensimmons: [everything is inline, with no cascade]

  jensimmons: A lot of possible ideas here too, web components,
              scoping, etc.
  jensimmons: A project I did last year is how to protect CSS from
              this hate.
  jensimmons: So we put together a hard-core course on teaching the
  jensimmons: Miri Suzanne did a deep dive into the history/etc.
  jensimmons: She began thinking about how we could change CSS to
              modernize the cascade and work better.
  jensimmons: One of her ideas is to extend selectors, in #4690.
  <astearns> https://github.com/w3c/csswg-drafts/issues/4690
  jensimmons: Another idea is to allow authors to make custom cascade
  jensimmons: I didn't really know what a cascade origin was until
              Miri taught me.
  jensimmons: [describes the cascade origins]
  <fantasai> See https://www.w3.org/TR/css-cascade-4/#cascade-origin

  jensimmons: Proposal is for custom origins. Say, create 3 named
              origins (get !important variants automatically that work
              as expected), and put styles in the chosen origin to get
  jensimmons: So use case.
  jensimmons: Reset styles in one origin, design system in another,
              then one-off overrides into a third.
  jensimmons: Or split apart the design system: reset -> defaults ->
              patterns > layouts -> components, all distinct origins.
  jensimmons: Or CMS Core -> CMS Extensions -> Base theme -> site
  jensimmons: Or a team trying to rewrite their CSS. Can't fix it all
              at once, but could put all their old code in one origin,
              and put their new code in a higher origin, to piecemeal
              fix it as they go.
  jensimmons: Or Bootstrap -> 3rd party -> ad networks -> actual site
  <florian> Is totally sold on Jen & Miriam Suzanne's idea. I think
            It's brilliant.

  jensimmons: Advantages?
  jensimmons: Could help with specificity wars between frameworks and
              author styles.
  jensimmons: Could put !important back into its proper role, rather
              than being abused just to get a second origin.
  jensimmons: Or just using origins as a type of !important; might be
              just as annoying?
  jensimmons: Pulled some use-cases from Twitter (already mentioned)
  jensimmons: So what do you think? Want to pursue?
  <myles> jensimmons that was an awesome presentation, i understand it
          so much better now, thank you so much

  emilio: I'm a bit confused about !important.
  emilio: If you want ad networks on an origin, and your styles on a
          higher origin, the ad networks could still override
          everything with !important style. Maybe that's not what you
  emilio: Second, it may be invalid, but IDs *can* be repeated on the
  emilio: There are ways for authors to use cascading origins that
          have better behavior - web components.
  fantasai: They're really hard to use
  TabAtkins: Web components doesn't solve any of Jen's use-cases, tho.
  iank: We should add declarative shadow roots
  emilio: When we discussed custom element default styles behavior,
          Apple was strongly against. Unsure if they'd still have
  hober: I'll talk to Ryosuke/Antii, see if they have feelings on
  <emilio> Though ++ to declarative shadow roots

  florian: I think it's a brilliant idea.
  florian: We've had the luxury of multiple origins here in CSS,
           letting us design through problems. Authors haven't had
  florian: I think it would be great. Almost want to stop talking
           about whether or not to do it and just start talking
  florian: Even as a single author this seems useful.
  fantasai: I also want to say I love it.

  dbaron: I'm also a big fan.
  dbaron: There are multiple choices we could make about !important.
  dbaron: Don't have to say they go in the opposite order. They could
          go in the same order, or be configurable, etc.
  <fantasai> +1
  dbaron: Maybe have the !important right after the normal origin.
  dbaron: So lots of options we could choose between, or let authors
  <fantasai> essentially an origin can encapsulate its !important level
  <AmeliaBR> +1 to dbaron says. Definitely don't want !important to
             automatically do reverse order.
  fantasai: Along those lines, might have an origin with sub-origins.
  fantasai: Which might have its !important held within the larger

  bkardell: First, thanks for bringing it up.
  bkardell: I've had these same conversations and I think this is
            really healthy.
  bkardell: To discuss what people are actually doing, rather than
            just relying on education
  bkardell: I think CSS-in-JS does have an order...
  jensimmons: They can, but don't always
  bkardell: With regard to web components, they don't solve all
            problems, but they do solve some. They're already .2% of
            the web archive, despite only getting the last impl this
  bkardell: Do we really rely on origin for UA level? I thought we
            kept them low specificity.
  TabAtkins: We don't use IDs, no, but we do freely use attribute
             selectors, which can easily clash if it wasn't for the
             origin difference.
  <fantasai> yes, we really rely on origin for UA level
  <fantasai> made fixes to the origin code in Gecko, can assure you it
             exists :)
  bkardell: I do believe we're missing something here. I don't know if
            this addresses or exacerbates the problem. At some level
            it addresses their complaints, but by doubling down on
            what they're complaining about.
  jensimmons: Agree.

  TabAtkins: I totally like this idea
  TabAtkins: Had similar thoughts, but never did the use case
  TabAtkins: Definitely agree we should pursue this, and the use cases
             made me absolutely sure we should pursue this

  heycam: I think it's very important for us to try to address these
  heycam: A little of a shame that it's taken several years after
          people started complaining, but glad we're addressing it
  heycam: What I like about this is that it's so simple, and slots
          into the existing model.
  heycam: Not super sure about whether it really will capture all of
          these use-cases, or might need more discussion with real
          proponents of CSS-in-JS to see how well it works.
  heycam: I'd want to be more sure this is the right way to go for
          solving that.
  heycam: But see the other use-cases anyway.

  astearns: I agree this is very nice it slots into our model, but a
            little concerned it's not the general author model.
  astearns: You had to learn about the concept anyway.
  astearns: So as Tess said, "origin" is an overloaded term, maybe we
            can come up with something else?
  [various suggestions]
  <dbaron> "style sources"?

  fantasai: Some discussion about this addressing all the cases; I
            don't think it does, but it addresses quite a few, and
            addresses the organizational layer of many projects.
  fantasai: So I think it fits well with how people put together their
  fantasai: There's other places in the cascade where specificity gets
            unwieldy. I don't think web components is great here; it
            adds a *ton* of encapsulation, not always what you want.
  fantasai: Another proposal was scoped styles in CSS, which might
            also help in addition.
  fantasai: They let you say "within this sidebar, these styles win
            over other things, regardless of specificity".
  TabAtkins: I think declarative shadow dom addresses a lot of the
             problems with web components; I'd like to explore that
             more seriously first before we add something that is 98%
             identical to web components's model, but with 2% weird
             differences that make impl complicated.

  <bkardell> if we had this, would we need leaverou's zero specificity
             pseudo still too?
  <fantasai> bkardell, you wouldn't need it for an entire swath of
             styles, but would likely still be useful locally, for
             specific selectors or parts of selectors
  <leaverou> bkardell: I believe so. This is great, but sometimes you
             need more fine-grained control. E.g. when theming
             *within* the same origin

  emilio: I agree this is neat. Is there a concrete proposal? Is that
          at the stylesheet level, or allow 3rd party styles to choose
          their origin, etc?
  emilio: Depending on details it might solve some use-cases but not
  emilio: Also need to figure out how this interacts with shadow dom.
  emilio: Shadow DOM introduces a stack of origins; introducing this
          naively makes it a matrix, which is harder.

  AmeliaBR: Echo Emilio's concern that we need details to see exactly
            how this sort of thing works.
  AmeliaBR: Coming up with specific proposals and cross-reffing them
            with specific use-cases would be helpful.
  AmeliaBR: So we should work from the use-cases to what features we
            actually need.

  fantasai: For "how do you control", an easy way to think of it would
            be the person importing the stylesheet be able to say what
            level it imports at.
  fantasai: And within each level, maybe you can have sub-ordering.
  fantasai: Can add an analogous nesting block that lets you specify
            the layer within a single file.
  fantasai: Using numbers to establish the ordering might work if
            there's only one controller; multiple controllers gives
            you the z-index wars.
  emilio: My concern with numbers or letting stylesheets choose their
          own levels becomes a z-index fight.

  florian: One thing I'm a little concerned is how we figure out the
           syntax to have a migration path toward this from legacy CSS.
  florian: In particular, a syntax ignorable by old browsers is bad
           because the cascade will be all mushed up; but making it
           hide rules from old browsers means they'll just miss a lot
           of code.
  florian: Writing everything twice is bad, but not having an upgrade
           path is bad.

  faceless2: What if you had two toolkits, importing the same
             stylesheet at different levels?
  TabAtkins: Same as importing a style sheet twice, it's just present
             in both places
  TabAtkins: all cascades together; effectively later one wins

  jensimmons: So got a lot of good issues and concerns.
  jensimmons: I do think it's worth looking deeply at the solutions we
              might need for the complete set of problems, not just
              what this particular solution could address, so we can
              tell if this is a good idea in the totality of a
              complete solution.
  <bkardell> +1 to talk about "this set of problems" for sure
  jensimmons: I've even convinced myself that if we ship this today by
              itself, it could get abused pretty badly.
  jensimmons: (similar to people abusing Flexbox to do grids)
  jensimmons: Putting this on Twitter, I got a lot of trepidation from
              folks. Powerful tool, could be bad.
  jensimmons: But I got that people who really knew CSS the most
              thought this was a terrific idea.
  jensimmons: I think it does require some teaching, but it's not that
  jensimmons: So I'm hearing a tentative "yeah, this is good", but I
              think there is a bigger metaproject to modernize the

  jensimmons: Also, Miri has been very active in Sass to push CSS to
              be a feature-full language; did crazy things with Sass
              variables back in the day.
  jensimmons: So I'd like to invite her as an IE.
  <hober> yes please
  <bkardell> supports more IE's
  <dauwhe> +1 from afar
  [unminuted non-technical discussion]

  astearns: So sounds like interest in the room, try to move proposal
  fantasai: Where to put it?
  TabAtkins: Suggest putting it in WICG until it gels, then merge it
             into Cascade 5.
  jensimmons: And I want to get some highly-skilled authors involved
              in the convo too, so hopefully WICG works there.

Summer meeting dates

  <AmeliaBR> We now have conflicts both weeks of July 20 (AB meeting)
             and July 27 (Tantek doesn't want Monday, Rachel Andrew
             needs to be in UK by Friday)
  <AmeliaBR> https://wiki.csswg.org/planning
  <AmeliaBR> If we move to the following week, FYI Monday Aug 3 is a
             holiday in Canada.
  [Proposal is Mon-Thu, week of July 27, Houdini on Monday]

SVG Paths
  Scribe: emilio

Path length in CSS
  github: https://github.com/w3c/svgwg/issues/773

  TabAtkins: SVG has a pathLength attr supported on <path>
  TabAtkins: It allows you to override the length of the path
  TabAtkins: allows you to set up e.g. exactly 100 dashes or such
  TabAtkins: otherwise you'd need to do a bunch of math or use JS
  TabAtkins: Given you can set the path in CSS
  TabAtkins: it seems reasonable to let you set it in CSS as a
             property alongside
  TabAtkins: In terms of signals, we got positive signals from WebKit
             and Blink
  heycam: Seems fine too

  AmeliaBR: Originally in svg1 it only had an effect on `<path>`, in
            SVG2 it affects all shapes
  AmeliaBR: I think implementation of that is pretty good
  AmeliaBR: but we don't have good implementation of what it actually
  AmeliaBR: So we do have some concerns on our last svgwg discussions
  AmeliaBR: so want to followup with proper testing and ensure we have
            interop to deal with some patterns
  AmeliaBR: but kind of a separate issue of whether it should be a
            pres attr
  AmeliaBR: It makes sense to be consistent with the stroke properties
            and such
  AmeliaBR: One complication is that this is the first time we use an
            attribute in mixed-case form
  AmeliaBR: Recommendation is that it becomes hyphenated
  AmeliaBR: and the mismatch will just be a legacy version
  TabAtkins: That's my exact suggestion
  TabAtkins: and also that means that the style object gets the
             camel-case object, which is nice

  emilio: Do we need to do something for stuff that takes a path
          function, like shapes and such?
  TabAtkins: Nothing else lets you go along the path
  astearns: motion-path
  TabAtkins: but that allows percents which provides this
  astearns: For shapes I could see using pathLength to short-circuit
            some stuff, but it doesn't seem a big use-case
  TabAtkins: That's not how pathLength works, it just resets the
             length in the calculations
  myles: Doesn't motion-path allow you to describe infinite-length
         paths or something like that?
  TabAtkins: It allows you to define ray() but there's a definition
             for what 100% means
  fantasai: Like for gradients
  <AmeliaBR> Motion path is one thing where distance along a path is
             relevant. That was one of the original uses in SVG (for
             the SMIL motion path)

  heycam: An alternative would be to allow percentages in
  heycam: would make it similar to other CSS things
  myles: So one of the nice things of path-length would be that you
         can animate it to have your dashes grow and stretch along the
  myles: If you have a bunch of percentages you need to animate them
  AmeliaBR: Getting percents in stroke-dasharray would be nice, right
            now they're valid but don't have a useful interpretation
  AmeliaBR: kinda separate from other use cases for path-length
  faceless2: Path-length is not only about dashes but also precise
             text positioning around a path
  chris: The generating tools have an idea of how long the path is
  chris: and by setting it the implementation just agrees to scale it
  astearns: Objections to resolve?

  RESOLVED: Add path-length as a CSS property and make pathLength map
            to it
Received on Thursday, 13 February 2020 00:52:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:13 UTC