- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2020 19:51:34 -0500
- 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 results) - 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 cells) - 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: https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC - 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 term. - 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) ===== FULL MINUTES BELOW ====== 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 https://drafts.csswg.org/css-values-4/#combining-values <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 non-interop ------------------------------------------------------------ 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 RESOLVED: Closed WONTFIX. '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 contents? 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 items. 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 table. 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 box. fantasai: vertical-align doesn't have stretch, it aligns you to some spot, and only applies if the item is smaller than the container. 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: https://codepen.io/AmeliaBR/pen/afcd79a788685ccee7892f733cc8251f 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 reasonable? 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 it? 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 row. RESOLVED: vertical-align operates in the block-axis of the table cell 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 authors. 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 page 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 cascade. 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 origins. 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 auto-overriding. 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 styles 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 styles <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 want? emilio: Second, it may be invalid, but IDs *can* be repeated on the page... 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 complaints. hober: I'll talk to Ryosuke/Antii, see if they have feelings on this. <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 that. florian: I think it would be great. Almost want to stop talking about whether or not to do it and just start talking syntax. 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 configure. <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 origin 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 week. 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 exploration 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 problems. heycam: A little of a shame that it's taken several years after people started complaining, but glad we're addressing it now. 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 sites. 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 vice-versa. 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 complicated. jensimmons: So I'm hearing a tentative "yeah, this is good", but I think there is a bigger metaproject to modernize the cascade. 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 forward 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 does 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 functionality 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 stroke-dasharray/dashoffset 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 path myles: If you have a bunch of percentages you need to animate them individually 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