- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2022 17:46:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `SVG Parameters spec`, and agreed to the following: * `RESOLVED: Adopt SVG params spec as ED` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: SVG Parameters spec<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/6988<br> <una> dholbert: proposed feature to allow SVG images to be customized using CSS<br> <dbaron> Scribe+ una<br> <una> dholbert: suppose you have a btn 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<br> <una> dholbert: the only way to do that now is to have several different copies of the SVG image<br> <una> dholbert: theres no way to restyle an SVG image based on state<br> <una> 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<br> <bramus> Spec URL: https://tabatkins.github.io/specs/svg-params/<br> <una> 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<br> <una> dholbert: you can set the initial value inside the SVG image<br> <una> dholbert: normally css variables have no initial value, this changes that<br> <una> dholbert: so the embedding document sets the initial value and embedding file can observe or change it<br> <una> dholbert: if you're looking at the SVG file directly there is default<br> <una> dholbert: use case = icons in Firefox toolbar<br> <una> 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)<br> <una> dholbert: right now our proprietary version we have for our own iconography is turned off bc we dont want add-ons to create icons<br> <una> dholbert: we want to advance Tab's spec or something else if there are concerns<br> <una> TabAtkins: In favor of adopting, but discussed interaction with @property's initial value, this will probably override<br> <smfr> q+<br> <emilio> q+<br> <fremy> q+<br> <astearns> ack smfr<br> <una> smfr: sounds similar to related discussion around allowing dark and light mode popping into SVG<br> <una> smfr: sounds like this will work in SVG for both image and iframe<br> <una> smfr: in iframes, SVG can exfiltrate this data that's pased in, but may be ok bc its uner c ontrol of parent frame<br> <una> dholbert: one concern about cross-origin iframes<br> <una> 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 control image (?)<br> <una> dholbert: for that reason, i think we should avoid cross-origin iframe usage<br> <una> smfr: agree - slightly concerning that an SVG could be made to load an external resource that could be part of a security exploit<br> <fantasai> smfr: so I agree with limiting to same-origin<br> <una> 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<br> <astearns> ack emilio<br> <una> emilio: not sure about whether it should override @property initial value<br> <una> emilio: that has sensible behavior, using CSS-wide keywords<br> <una> emilio: I'm not sure I'm a fan of passing stuff via the URL<br> <una> 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<br> <una> 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<br> <una> 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<br> <una> emilio: you cant use it in different URL values (cant pass different params to different URL values in the same element)<br> <una> emilio: may not have come across that use case but I do believe its important<br> <emeyer> q+<br> <una> TabAtkins: I'd be fine with both if thats okay<br> <una> emilio: feels like a bit of an abuse of the URL to stash things in the URL<br> <astearns> ack fremy<br> <una> fremy: I actually liked the oposing argument initially (im not sure why we want to restrict this to SVGs)<br> <fantasai> +1 fremy<br> <una> fremy: I think people use variables assuming they ?? - if we are changing the opt-in, we're changing it from something author controls to something URL controls<br> <dbaron> s/??/are controlled by the page/<br> <una> fremy: initial value if you specify a keyword from a param or a URL, if that is specified, that would enabel the mechanism to use the externally supplied value - 1st benefit is that its an opt in<br> <una> fremy: you explicity say this property is a color (for example) and you only get a color as a result<br> <una> fremy: you can protect yourself against invalid syntax<br> <emilio> q+<br> <una> TabAtkins: the premise that this opens you up for attack bc this changes your expectations for what syntax of a variable value will be is invalid usage and will screw up your property<br> <una> TabAtkins: in that case, it would make something valid that you would rely on being invalid, but not int he normal case<br> <miriam> q+<br> <una> fremy: you still use the value and assume that itll never cause an issue<br> <una> fremy: so thats a problem<br> <fantasai> s/still use the value/might be relying on the initial value/<br> <una> TabAtkins: i suppose thats true, i was trying to avoid a double handshake bc its more work, but i'm not opposed to it if it makes the cross-origins concerns less<br> <fantasai> fremy++<br> <una> q?<br> <astearns> ack emeyer<br> <dbaron> (I think fremy was talking about var() functions that provide a fallback value.)<br> <una> 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<br> <una> emeyer: makes sense for performance reaons if you want to refer to an SVG only once<br> <fantasai> s/initial/initial or fallback/<br> <fremy> (what @dbaron clarified is correct, I was mentioning authors using var(--non-existent, default) and hitting default right now)<br> <una> 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"<br> <una> emeyer: i.e. im only transitioning <color> or <opacity> for this SVG -- these are the properties I want to pass in<br> <una> emeyer: would be super useful for that<br> <una> emeyer: however doesnt help with background SVGs and there needs to b e a way to address that as well<br> <una> emeyer: very useful to be able to say what properties i want to pass (ie. `pass-property: all`)<br> <una> 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<br> <una> TabAtkins: you wouldn't be able to flag non-custom properties<br> <una> TabAtkins: the values of arbitrary properties aren't sufficiently defined<br> <una> TabAtkins: i.e. if you wanted to pass stroke value you have to define it<br> <una> emeyer: as an author, that's a bummer but i understand the limitations<br> <una> emilio: do you mean completely override?<br> <una> TabAtkins: same name override<br> <astearns> ack emilio<br> <astearns> q+<br> <una> emilio: when fremy was talking about typing things, nothing stops you from doing that<br> <una> emilio: just bc they get validated at computed value time, doesn't mean you cant type it<br> <astearns> ack miriam<br> <una> miriam: not understanding cross-origin security concerns<br> <emilio> q+<br> <una> miriam: it seems to me custom properties are already considered insecure bc as a user i can change them<br> <ydaniv> q+<br> <una> miriam: already dont allow custom props to be used in a way that can be a security issue<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to react to miriam<br> <una> fantasai: the example that was given is: youre expecting to get a background color, someone passes a URL to an image they control, now its loading in your context with your permissions<br> <una> dholbert: the part thats not possible is suppose this is embedded content from a secure site, they specify a bg thats 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<br> <una> 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 ?<br> <una> TabAtkins: yes, it does<br> <una> astearns: would we need to add keywords?<br> <astearns> ack astearns<br> <una> TabAtkins: if we're doing a different type of parameter we can add keyword to express that<br> <una> 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<br> <una> emilio: you could already right now use a custom property that isn't defined as such<br> <una> emilio: I don't think its the most concerning of risks<br> <una> emilio: on an iframe you can already script read the hash out and polyfill this for iframes right now<br> <una> emilio: we'd need to evaluate the risk, how many cross-origin pages use custom props in a way that could be dangerous<br> <una> emilio: if we double handshake it should be fair<br> <lea> q+<br> <una> emilio: still on the fence passing it in the URL hash vs. CSS function<br> <una> emilio: URL hashes have meaning right now<br> <una> TabAtkins: SVG syntax defines other thigns i.e. viewbox and media fragments in SVG hash<br> <una> emilio: if there is precedent, it makes me more comfortable with it<br> <bramus> s/thigns/things/<br> <una> TabAtkins: for it to be a problem you'd have to have a property with param<br> <dholbert> emilio: see https://css-tricks.com/svg-fragment-identifiers-work/#aa-syntax-for-html<br> <astearns> ack ydaniv<br> <una> ydaniv: still trying to understand usecase 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<br> <fantasai> dholbert: in an iframe, not a problem for svg image<br> <una> fremy: if you assume there's a security bug in the browser triggered by running a resource you'll still manage to trigger it<br> <una> dholbert: any time providing external data into a document you have this potential issue<br> <astearns> ack lea<br> <una> lea: 2 things - if we end up requiring a double handshake, can we jsut require it on cross-origin images and not everywhere?<br> <una> lea: i think its important to find use cases of cross-origin images<br> <emilio> q+<br> <fremy> +1 on lea's point, CDNs are popular<br> <una> lea: also - we need to make sure different uses of hash can be combined<br> <flackr> Just have to establish that it's uncredentialed right?<br> <una> lea: hash is used for many things today<br> <una> lea: need to preserve these capabilities, and in the future we might be using hash for even more different things - something to consier<br> <una> chris: we already use viewbox and you can combine it with other hashes<br> <una> TabAtkins: potentially only requiring double handshake for cross-origin is what i wanted to aim for as well<br> <una> TabAtkins: your other point about cross-origin images - i definitely agree we should be able to adress cross origin svgs in some way<br> <una> TabAtkins: uncredentialed<br> <una> emilio: cross-origin SVGs arent the issue bc they can't do a lot of things, its cross-origin iframes<br> <una> emilio: the problem is loading an SVG iframe not an SVG image bc its a different security model<br> <astearns> ack fantasai<br> <emilio> q-<br> <una> fantasai: if its loaded as an SVG image its not a security issue -- if its loaded as an SVG iframe the security model is more relaxed and we'd have to have some cross-origin security<br> <una> fantasai: emilio made a point that passing all this via URLs isnt great bc you have to repeat it every time for each image<br> <una> fantasai: you arent able to have shared information across the URLs<br> <fantasai> s/URLs/multiple images<br> <una> 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?<br> <una> fantasai: do we want to design a syntax that can we used i other formats as well<br> <una> fantasai: i.e. non-CSS resources<br> <una> TabAtkins: this is a CSS feature, don't care about other resources<br> <ydaniv> <object> also problematic<br> <una> fantasai: suppose word documents want to be able to interpret URLs and support media fragment syntax<br> <una> 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<br> <dholbert> ydaniv: <object> is effectively a synonym for <iframe> from a capabilities/security-model perspective, IIUC<br> <astearns> q?<br> <una> fantasai: emilio brought up issue if you're passing the parameter and setting the param vs. changing the inital value of the property in that document which are very different<br> <TabAtkins> yeah when we say "iframe" we generally mean "any of the elements that can load an active document"<br> <una> fantasai: fremy brought up issue that the image should be recieving this info and be able to or required to type the incoming prop data<br> <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)<br> <una> fantasai: so if you're trying to pass an image to a var thats expecting a color itll fail<br> <una> astearns: you want us to adopt this as an editors draft?<br> <una> dholbert: yes<br> <una> 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<br> <una> astearns: anyone have concerns and wants to address why we shouldnt adopt this?<br> <una> <silence><br> <una> astearns: Proposed Resolution: Adopt this as an editors draft and start working on these issues<br> <fantasai> lea, I don't think that's an issue with setting initial value vs setting the value<br> <una> TabAtkins: i'm happy to do it<br> <una> TabAtkins: would like co-editor, dholbert volunteered as co-editor<br> <fantasai> lea, if the author defined the property with an initial value, they should get that value when the parameter is not set<br> <una> 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?<br> <una> fremy: you could also introduce your variables in a website hyou don't control the origin<br> <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<br> <una> TabAtkins: you could just load an SVG directly, we dont know if its single or cross origin<br> <una> TabAtkins: would consider that cross-origin for safety<br> <una> TabAtkins: if its an SVG we don't care as much, if its an iframe, choose safety<br> <TabAtkins> https://tabatkins.github.io/specs/svg-params/#using<br> <fantasai> RESOLVED: Adopt SVG params spec as ED<br> <dholbert> \o/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6988#issuecomment-1203033606 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 August 2022 17:46:15 UTC