- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 30 Aug 2022 19:32:33 -0400
- 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.
=========================================
CSS Color
---------
- RESOLVED: Specify how none is carried across color space conversion
to a related component on the other side (Issue #7536:
Missing info about Premultiplication and Undefined values)
- RESOLVED: Allow color-contrast() to specify the algorithm and
level, by taking an algorithm function as an arg (Issue
#7356: It should be possible to specify the contrast
algorithm for color-contrast())
- The group didn't like either proposal in issue #7359
(color-contrast() should distinguish foreground and background)
and instead wanted to bikeshed around using slashes or brackets.
SVG Parameters
--------------
- RESOLVED: Adopt SVG params spec as ED (Issue #6988: Provide a way
to pass theming colors (and potentially other info))
- There are concerns about cross-origin iframes and ensuring this
doesn't add a security leak. Additional discussion will be
required as the spec progresses.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/30
Scribe: TabAtkins
CSS Color
=========
Missing info about Premultiplication and Undefined values
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7536
chris: We have some stuff about how to convert colors
chris: First, nones get replaced by zero, because you need a number to
convert
chris: We also have text to interpolate, which says if one has none
it takes the value from the other
chris: This avoids interpolating an achromatic to chromatic where it
starts from an essentially random color
chris: These assume the space you're specified and interpolated in
are the same
chris: If they're not, the conversion happens and you lose the info
chris: There's also the issue that if you're using two different
color spaces, what to do?
chris: If you have one in LCH and one in HSL, do you copy the hue
angle even if it's a different color?
chris: It starts not making sense unless the values you're comparing
nones for are in the same color space
chris: Then the question was, do we want this anyway?
chris: We started with saying that sometimes the channel was NaN
chris: and I was convinced to change it to none
chris: for consistency we added it everywhere, including in places no
one asked for it
chris: that's extra testing, what's the point, etc
chris: it does help in some cases - if you have two in the same polar
color space, it helps
lea: For none to resolve, you clearly need to convert to the same
color space
lea: no question
lea: but there's a question of how to convert if both colors can have
none
lea: I don't think having none everywhere created new problems, they
exist even if it's only present in hues
lea: We need to figure it out regardless of if it's allowed in RGB,
etc
chris: I don't think that transporting nones from one color to
another when they're in another color space is *useful*, it's
just the only thing to do from the spec text
chris: but it doesn't make a lot of sense
florian: Do you have an idea of the solution?
scribe: fantasai
TabAtkins: I disagree that it doesn't make sense when they're in
different color spaces
TabAtkins: if you take achromatic HSL into chromatic LCH
TabAtkins: it's ...
TabAtkins: if you wanted to maintain intent of none behavior, I think
answer is convert using the same rules, and remember the
noneness and apply it on the other side of the conversion
miriam: That only seems possible with hue, though, right?
TabAtkins: Powerlessness extends across conversions, right?
TabAtkins: If your hue is none and you convert to RGB ...
miriam: If your R, G, or B is none and you convert to hue, how do you
do the conversion?
chris: To restate, you take which component names have none, then you
do the conversion, and if that component name exists in the
result ...
chris: If you convert hsl to lch, they both have hues
chris: but if you convert to profoto rgb, then no place to put it
TabAtkins: If you have zero chroma, should be same as ???
TabAtkins: so need to some manual mapping of what coverts to what as
nones
TabAtkins: but e.g. polar to rectangular or vice versa wipes out the
info
lea: Even if going from HSL to LCH, ...
lea: Do we really want none^2/2?
TabAtkins: Treat none as zero, convert it over, remember that the hue
was zero, and then none it
lea: So would need to remember that hue in HSL and LCH relate
TabAtkins: chroma and saturation should also map
TabAtkins: lightness should map
TabAtkins: If we want to maximize author friendliness of original
intent, we need to set up a map of which channels can
carry noneness into other profiles
lea: How would that work with custom profiles?
TabAtkins: Probably can't do it with custom profiles
lea: Another suggestion is to ditch none altogether and handle
achromatic colors specially, same as how we handle transparent
colors specially
lea: it's not as elegant
TabAtkins: Only objection there is one of the uses for none is to
handle things without chroma that do have a definite hue
TabAtkins: e.g. things like white and black, they have undefined
chroma as well
TabAtkins: so they don't go from zero chroma into bright chroma red
dbaron: It would probably be useful to look the mapping from
basically a table that shows what components in this color
influence what components in this other color
dbaron: for example, when converting HSL to LCH, which components of
HSL influence L in LCH, etc.
dbaron: that might be useful
dbaron: It sounds like you want to transfer noneness in some cases
beyond where it's strictly ok?
TabAtkins: Less probably
dbaron: My intuition is it would strictly be okay only where the
inputs to the value were the ????
dbaron: I think
TabAtkins: Might be, not 100% certain
dbaron: Do more than that, but look at these tables and see what you
want to do
dbaron: Assuming you want to go down that path
chris: In general, prefer ...
chris: but if I have a none alpha, and I convert to zero, and then I
get transparent black, then ...
TabAtkins: We only pre-multiply during transitions right?
TabAtkins: idk if we've specified more clearly
chris: We have
TabAtkins: sRGB is stored pre-multiplied?
chris: No, but when you interpolate you pre-multiply
miriam: But at that point you've already done the replacement
dbaron: Is it possible you want the math for none to be different for
different places where you can put a none?
chris: I think good thing about Tab's proposal is you don't have to
handle none through the entire calculation chain
chris: just put it back at the end
dbaron: Was suggesting for alpha cases, but maybe you want to treat
it as 1 rather than zero
TabAtkins: Yes, when you do conversion you turn it into a number, and
that's already in the spec
dbaron: Ah, I thought someone said it's always zero
chris: It is
TabAtkins: Even for alpha?
lea: Maybe alpha should be 1
TabAtkins: Alpha isn't involved in color space conversions
lea: For HSL and LCH, for example, I think basically all components
influence all components, it's just that some components
influence some other components more
lea: hue and lightness still influence every component, because not
1-1 mapping
dbaron: That was my intuition, especially once you're converting
between d50 and d65 then you're definitely
TabAtkins: My intention was to put a table of what components map
across, only a handful to worry about
TabAtkins: all the hue-ish things, all the red-green-blue-ish things'
Rossen: That's the action out of this issue?
TabAtkins: Proposed resolution is we specify how none is carried
across color space conversation to a related component on
the other side
Rossen: objections?
RESOLVED: Specify how none is carried across color space conversion
to a related component on the other side
<dbaron> (I do wonder how the stability of this relates to stability
of other features in color 4.)
Specifying the contrast algorithm for color-contrast()
------------------------------------------------------
scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/7356
lea: Since there are problems with every contrast algorithm known
right now
lea: wcag2 is well known but with big problems
lea: There's a study linked in the issue that shows it has something
like 40% false results
lea: We suspect the reason in practice people don't realize how bad
it is is because the colors you feed in aren't random, they're
already "probably readable", so this is a second line of defense
lea: but once it's baked into a css algorithm it'll be used to
generate color pairs without author intervention
lea: so if it's this bad, we can't use it
lea: otoh, APAC is positioned as a successor, but has issues
lea: Patent filed for it, unclear if it's usable
lea: weird note about licensing for web-based usages
lea: and the author has been rather difficult to work with, got a
temp ban from w3c
lea: There are some other algos, chris probably knows more, they also
generally don't produce great results
lea: So it should be possible to specify the algorithm
specifically, rather than picking a default
lea: but even if we make it mandatory, that's not a solution, authors
will learn an invocation and we won't be able to shift away
fantasai: So not shipping yet, but we still need to add keywords
lea: Not keywords, some kinda function since the levels are different
for each algorithm
chris: Re: the patent situation
chris: At a certain maturity level you can lodge an exclusion
chris: In this case the patent was disclosed but not excluded
chris: the actual disclosure has some wording about license
restrictions
chris: the patent policy does not allow such restrictions
chris: it needs RAND as well as free
chris: W3C patent people say it's unenforceable
chris: so currently it seems to be royalty-free
florian: The patent disclosure period has elapsed, and there was no
exclusion
una: Agree its important to specify the algorithm
<dbaron> +1 to "should be able to specify the algorithm" (pending the
details, which are in other issues!)
una: Wanna be able to use new algorithms in the future
una: Yesterday we also talked about letting the browser decide the
auto algorithm
una: If wcag2 is the current default, we want the browser to be able
to update to new ones
una: I think this can be done if there's no keyword (or auto?)
una: and a keyword means the user always wants a specific algorithm
una: Seems like best of both worlds for usability and ability to be
specific for contrast algorithm
una: tldr, should be able to specify contrast algorithm but also
should be able to say auto
flackr: If the user has told the browser they have a color
deficiency, can the UA take that into account and select a
contrasting color based on it?
<una> good question, Rob
chris: People with atypical color vision don't have reduced contrast
sensitivity
chris: with exception of red-on-black
chris: where they're actually better
chris: re the "function instead of keyword", it's because the
different algorithms use different numeric ranges
dbaron: Responding to una
dbaron: maybe pushing a little outside this issue
dbaron: I am skeptical of anything where we ship something and later
change what color is produced
dbaron: People will evaluate whether they've succeeded in their
design not just by writing a contrast(), but also by looking
at it and making sure they like it
<florian> +1
dbaron: If we go and change the colors later, people will probably be
unhappy and pages will be broken
una: This is why I think it should be an option
una: but authors should generally be using a specific algorithm
una: but an option could be to let the browser decide, if they don't
care as much about a particular combo
dbaron: I think once we ship the feature it'll be hard to change
florian: Agree, we'll be dealing with less fully-informed authors and
teams, who will show the result to someone in approval who
won't be caring about code, just result, and even if it's
well-intended it might look wrong alter
florian: Even if you told them it could be different that wouldn't
matter
una: I'm afraid if we ship the current contrast algorithm people
won't update their code, and pages will be stuck on bad results
miriam: I agree that's a useful use-case and what I'd expect
miriam: I think it would be useful to recommend to authors to put the
algorithm into a custom prop so it's easy to update later
fantasai: Given how broken wcag2 is, we're asking a lot of people to
bake wcag2 into their page, and they won't update their
code ever
fantasai: if wcag2 is the only thing we have to offer and we don't
have the ability to auto-upgrade it
fantasai: then even 5 years from now people will be teaching that you
use the wcag2 algorithm
fantasai: seems harmful to the web and we shouldn't be shipping it as
a solution
fantasai: If we wanted to go down the auto-updating path and ship
now, we could ship a more limited version that only gives
white or black
fantasai: That's basic, but it solves a useful problem
fantasai: text is readable
fantasai: But for this issue, I think we do need the ability to
choose an algorithm
fantasai: not just because we want authors to change what they use
over time, but they also might actually want a specific
algorithm, from design or legal perspective
fantasai: In the future we might have an excellent algorithm, but the
laws in XYZ might require contrast that conforms to wcag2,
I want to be able to say I want the color that conforms to
awesome-algorithm and wcag2.
fantasai: So not just one algo, but 2+
fantasai: In the case of "most contrasty one", you can only have one,
but in "reach at least this level" we can offer multiple
fantasai: I agree that using a function makes most sense so we can
put appropriate scale info in
fantasai: so for this issue proposal is to add one or more algorithm
functions to color-contrast() arg
fantasai: that accept the numeric level
<lea> #7357 is the issue fantasai is referencing
fantasai: and this should be one of the prelude args
castastrophe: So much +1 to that
<lea> needless to say, +1 to everything fantasai just said
castastrophe: From design system perspective, people aren't likely to
update this code frequently
castastrophe: so having generic name function with a default
algorithm that we can update as we go along...
castastrophe: I don't know if we've changed defaults under the feet
castastrophe: We've done that a lot in design components, using the
bad default for now until we figure it out
fantasai: I agree with that, but that's a different issue about the
default
fantasai: for the purpose of this discussion we're assuming it must
be specified explicitly
castastrophe: was thinking about generic name
fantasai: Name is color-contrast(), and you'd say like color-contrast(
wcag(...), black, white)
una: So this issue is about always requiring a specific
color-contrast algorithm
fantasai: For now, we can discuss optionality later
una: Definitely +1 on making it possible
una: I would like a world where it's not required
una: we'll discuss that later
<fantasai> default algorithm issue
-> https://github.com/w3c/csswg-drafts/issues/7361
chris: We can always relax it later if it's required now
fantasai: So proposal is we add to color-contrast() a number of
specific-algo functions accepted as one of its arguments
dbaron: clarifying - saying the level is optional. Does that mean if
you don't give a level you get the most contrasty choice, and
if you do you get the first color that meets the level?
chris: Yes, that's already what the spec says
Rossen: Objections?
lea: What's the reason to get the most contrasty pair? why not just
default to a reasonable level?
Rossen: That's another issue, we'll discuss that later
RESOLVED: Allow color-contrast() to specify the algorithm and level,
by taking an algorithm function as an arg
una: What if none of the color values work?
chris: If you give a target and you run off the end of the list,
you'll get either white or black, whichever is better
color-contrast() should distinguish foreground and background
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7359
chris: Most of the algos, you give two colors, and they generally
denote one of them is lighter and the other is darker
chris: At least APCA, and some others, requires you to say which is
the text and which is bg, and if you swap you don't get the
same number
<dbaron> (when skimming the list of algorithms you referenced... I
only saw APCA that cared which was fg/bg)
chris: wcag2 doesn't care
fantasai: Two proposals in the issue
fantasai: both of them are suggesting an over/under keyword
fantasai: One of them puts it as first arg color-contrast(over
white, ...) meaning white is bg
fantasai: this follows same pattern as gradients
fantasai: Downside is because arg is a color, it looks like part of
the color list
fantasai: Other suggestion was to use keyword as divider
color-contrast(white under ...)
fantasai: argument against was it felt a little backwards about which
keyword you used
<fantasai> https://github.com/w3c/csswg-drafts/issues/7359#issuecomment-1158668669
lea: The way the comma works, it tends to have higher precedence than
just words
lea: so using a word to separate from a comma-separated list, it
looks like you have one big first entry in the list
lea: But that's a problem with the current syntax
<dbaron> +1 to lea about comma versus space precedence
una: Have we considered a slash rather than comma? like `red over /
<color-list>`
una: seems to make it easier to separate
castastrophe: I love that solution
castastrophe: like the natural language read of "color over"
castastrophe: +1 to slash
dbaron: Suggest bracketed list
dbaron: grid tracks do this
<chris> +1 to a slash or some other way of grouping the list
una: My first thought was bracket list
una: Just think it's more of a convention to use the slash
<astearns> so `red over [<color-list>]`
lea: Issue with nested function...
TabAtkins: Not function, just brackets around the color list
lea: Oh, that's different
lea: We have a precedent of using slashes to separate parts within
comma list, in backgrounds, so using it here with opposite
precedence...
TabAtkins: That was going to be my objection as well
<chris> looks like an array: white over [red, blue, violet]
fantasai: suggest we bikeshed over lunch
<br dur="1h 10m">
SVG Parameters
==============
scribe: una
SVG parameters
--------------
github: https://github.com/w3c/csswg-drafts/issues/6988
dholbert: Proposed feature to allow SVG images to be customized using
CSS
dholbert: Suppose you have a button with an SVG image as its bg, and
you want to be able to dynamically make it look different
when its hovered/disabled/etc. or theme style
dholbert: the only way to do that now is to have several different
copies of the SVG image
dholbert: there's no way to restyle an SVG image based on state
dholbert: Tab has a proposed spec via letting you specify CSS
variables in-url as a part of the fragment identifier as a
part of the SVG image's URL
<bramus> Spec URL: https://tabatkins.github.io/specs/svg-params/
dholbert: Basic idea is in the fragment identifier you can specify
the name of a CSS variable that will be exposed inside the
SVG image
dholbert: You can set the initial value inside the SVG image
dholbert: normally css variables have no initial value, this changes
that
dholbert: so the embedding document sets the initial value and
embedding file can observe or change it
dholbert: If you're looking at the SVG file directly there is default
dholbert: use case = icons in Firefox toolbar
dholbert: We would like to be able to use it for icons of Firefox
add-ons (to be able to hover them and have them respond to
themes)
dholbert: Right now our proprietary version we have for our own
iconography is turned off because we don't want add-ons to
create icons
dholbert: we want to advance Tab's spec or something else if there
are concerns
TabAtkins: In favor of adopting, but discussed interaction with
@property's initial value, this will probably override
smfr: Sounds similar to related discussion around allowing dark and
light mode popping into SVG
smfr: sounds like this will work in SVG for both image and iframe
smfr: In iframes, SVG can exfiltrate this data that's passed in, but
may be ok because its under control of parent frame
dholbert: One concern about cross-origin iframes
dholbert: Worried about scenario where you have content that uses
background property, expecting a color to be passed in, and
the surrounding content passes an attacker controlled image
dholbert: for that reason, I think we should avoid cross-origin
iframe usage
smfr: Agree - slightly concerning that an SVG could be made to load
an external resource that could be part of a security exploit
smfr: so I agree with limiting to same-origin
dholbert: If you're using it in an iframe, there's already ways to do
the same thing - if we spec this for images you would also
expect it to work similarly in an iframe
emilio: Not sure about whether it should override @property initial
value
emilio: that has sensible behavior, using CSS-wide keywords
emilio: I'm not sure I'm a fan of passing stuff via the URL
emilio: i.e. if you have a bunch of icons, you can have a single
place where you define the props you're passing down to them
emilio: You can put all your values in a CSS variable and pass those
down, but I would have preference to having it be a CSS prop
on the embedder element instead of as a part of the URL
TabAtkins: Objection to that is it works fine on an image or iframe
element, but its less likely to work well if you're
specifying CSS background-images that expect property
names to be passed
emilio: You can't use it in different URL values (can't pass different
params to different URL values in the same element)
emilio: May not have come across that use case but I do believe its
important
TabAtkins: I'd be fine with both if that's okay
emilio: Feels like a bit of an abuse of the URL to stash things in
the URL
fremy: I actually liked the opposing argument initially (I'm not sure
why we want to restrict this to SVGs)
<fantasai> +1 fremy
fremy: I think people use variables assuming they are controlled by
the page - if we are changing the opt-in, we're changing it
from something author controls to something URL controls
fremy: wrt initial value if you specify a keyword from a param or a
URL, if that is specified, that would enable the mechanism to
use the externally supplied value - 1st benefit is that its an
opt in
fremy: You explicitly say this property is a color (for example) and
you only get a color as a result
fremy: You can protect yourself against invalid syntax
TabAtkins: The premise that this opens you up for attack because this
changes your expectations for what syntax of a variable
value will be is invalid usage and will screw up your
property
TabAtkins: In that case, it would make something valid that you would
rely on being invalid, but not in the normal case
fremy: You might be relying on the initial or fallback value and
assume that it'll never cause an issue
fremy: so that's a problem
<dbaron> (I think fremy was talking about var() functions that
provide a fallback value.)
<fremy> (what @dbaron clarified is correct, I was mentioning authors
using var(--non-existent, default) and hitting default right
now)
TabAtkins: I suppose that's true, I was trying to avoid a double
handshake because its more work, but I'm not opposed to it
if it makes the cross-origins concerns less
<fantasai> fremy++
emeyer: As an author, I've run into the situation more than once that
I've had to inline SVGs to do this same thing
emeyer: Makes sense for performance reasons if you want to refer to
an SVG only once
emeyer: Have mashed my teeth before about wanting to adjust the fill,
as an author I would be very interested in having a CSS
property way of saying "this is what I want to pass into this
resource"
emeyer: i.e. I'm only transitioning <color> or <opacity> for this SVG
-- these are the properties I want to pass in
emeyer: would be super useful for that
emeyer: However doesn't help with background SVGs and there needs to
be a way to address that as well
emeyer: very useful to be able to say what properties I want to pass
(ie. `pass-property: all`)
TabAtkins: I propose we address emilio's and other concerns by saying
we add a property that takes custom element names and
potentially values to pass to the resource and any images
used by the resource but also use the existing syntax in
the spec
TabAtkins: you wouldn't be able to flag non-custom properties
TabAtkins: the values of arbitrary properties aren't sufficiently
defined
TabAtkins: i.e. if you wanted to pass stroke value you have to define
it
emeyer: As an author, that's a bummer but I understand the limitations
emilio: Do you mean completely override?
TabAtkins: Same name override
emilio: When fremy was talking about typing things, nothing stops you
from doing that
emilio: just because they get validated at computed value time,
doesn't mean you can't type it
miriam: Not understanding cross-origin security concerns
miriam: It seems to me custom properties are already considered
insecure because as a user I can change them
miriam: Already don't allow custom props to be used in a way that can
be a security issue
fantasai: The example that was given is: you're expecting to get a
background color, someone passes a URL to an image they
control, now its loading in your context with your
permissions
dholbert: The part that's not possible is suppose this is embedded
content from a secure site, they specify a bg that's
different if you're logged in or not, have a css property
if you're logged in, an attacker can identify if you're
logged in if updating the property sends them a ping
astearns: I seem to remember we have extensions to the URL function
and things we want to add to it in the future - do these
play well ?
TabAtkins: Yes, it does
astearns: Would we need to add keywords?
TabAtkins: If we're doing a different type of parameter we can add
keyword to express that
emilio: Depending on whether we make this handshake or not, you can
already pass a lot of data in the URL hash in the iframe
emilio: You could already right now use a custom property that isn't
defined as such
emilio: I don't think its the most concerning of risks
emilio: On an iframe you can already have script read the hash out and
polyfill this for iframes right now
emilio: We'd need to evaluate the risk, how many cross-origin pages
use custom props in a way that could be dangerous
emilio: If we double handshake it should be fair
emilio: Still on the fence passing it in the URL hash vs. CSS function
emilio: URL hashes have meaning right now
TabAtkins: SVG syntax defines other things i.e. viewbox and media
fragments in SVG hash
emilio: If there is precedent, it makes me more comfortable with it
TabAtkins: For it to be a problem you'd have to have a property with
parameter
<dholbert> emilio: see
https://css-tricks.com/svg-fragment-identifiers-work/#aa-syntax-for-html
ydaniv: Still trying to understand use-case of loading an image: the
concern is if you specify the URL for an image it will be
loaded by that image instead of an expected color
dholbert: In an iframe, not a problem for svg image
fremy: If you assume there's a security bug in the browser triggered
by running a resource you'll still manage to trigger it
dholbert: Any time providing external data into a document you have
this potential issue
lea: 2 things - if we end up requiring a double handshake, can we
just require it on cross-origin images and not everywhere?
lea: I think its important to find use cases of cross-origin images
<fremy> +1 on lea's point, CDNs are popular
<flackr> Just have to establish that it's un-credentialed right?
lea: Also - we need to make sure different uses of hash can be
combined
lea: Hash is used for many things today
lea: Need to preserve these capabilities, and in the future we might
be using hash for even more different things - something to
consider
chris: We already use viewbox and you can combine it with other hashes
TabAtkins: Potentially only requiring double handshake for
cross-origin is what I wanted to aim for as well
TabAtkins: Your other point about cross-origin images - I definitely
agree we should be able to address cross origin SVGs in
some way
TabAtkins: un-credentialed
emilio: cross-origin SVGs aren't the issue because they can't do a
lot of things, its cross-origin iframes
emilio: The problem is loading an SVG iframe not an SVG image because
its a different security model
fantasai: If it's loaded as an SVG image it's not a security issue --
if it's loaded as an SVG iframe the security model is more
relaxed and we'd have to have some cross-origin security
<smfr> <img src=foo.svg> loads the svg in “Secure animated mode”:
https://svgwg.org/specs/integration/#secure-animated-mode
<ydaniv> <object> also problematic
<dholbert> ydaniv: <object> is effectively a synonym for <iframe>
from a capabilities/security-model perspective, IIUC
<TabAtkins> yeah when we say "iframe" we generally mean "any of the
elements that can load an active document"
fantasai: emilio made a point that passing all this via URLs isn't
great because you have to repeat it every time for each
image
fantasai: You aren't able to have shared information across the
multiple images
fantasai: The other bit of feedback was fremy - if we're doing this
in a URL mechanism why are we restricting it to SVGs, why
not expand it?
fantasai: Do we want to design a syntax that can we used I other
formats as well
fantasai: i.e. non-CSS resources
TabAtkins: This is a CSS feature, don't care about other resources
fantasai: Suppose word documents want to be able to interpret URLs
and support media fragment syntax
fantasai: Discussed limiting passing of parameters in cross-origin
context when loaded as an iframe but not worrying about
that if loaded as an SVG image
fantasai: emilio brought up issue if you're passing the parameter and
declaring the param vs. changing the initial value of the
property in that document which are very different
fantasai: fremy brought up issue that the image should be receiving
this info and be able to or required to type the incoming
property data
fantasai: so if you're trying to pass an image to a var that's
expecting a color it'll fail
<lea> it's important that it sets the initial value, not just setting
the property, so SVG can provide fallback values via
var(--prop, fallback)
<fantasai> lea, I don't think that's an issue with setting initial
value vs setting the value
<fantasai> lea, if the author defined the property with an initial
value, they should get that value when the parameter is
not set
<fantasai> lea, the question is if the parameter overrides that
initial value (and is represented by 'initial' keyword) or
if it is just setting the property to a different value
(like declaring it on root); I think the second is more
appropriate
astearns: You want us to adopt this as an editors draft?
dholbert: Yes
dholbert: At a high-level, it seems nobody is objecting to the
overall idea but we should add property syntax to more
concisely address list of passed in custom properties
astearns: anyone have concerns and wants to address why we shouldn't
adopt this?
<silence>
astearns: Proposed Resolution: Adopt this as an editors draft and
start working on these issues
TabAtkins: I'm happy to do it
TabAtkins: Would like co-editor, dholbert volunteered as co-editor
fremy: Last thought I had was we have to consider use case of
single-origin: What happens if you also use the address in the
address bar?
fremy: you could also introduce your variables in a website you don't
control the origin
TabAtkins: You could just load an SVG directly, we don't know if its
single or cross origin
TabAtkins: Would consider that cross-origin for safety
TabAtkins: if its an SVG we don't care as much, if its an iframe,
choose safety
<TabAtkins> https://tabatkins.github.io/specs/svg-params/#using
RESOLVED: Adopt SVG params spec as ED
<dholbert> \o/
Received on Tuesday, 30 August 2022 23:33:15 UTC