- 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