- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 May 2018 16:29:00 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Browsers do not implement transform attribute syntax as described by w3c`, and agreed to the following: * `RESOLVED: SVG attribute reflects current interop, future improvements will be in css transforms` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Browsers do not implement transform attribute syntax as described by w3c<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2623<br> <dael> krit: This is specifically about transform attribute in SVG name space.<br> <dael> krit: This is the tranform attribute for SVG name spaced elements. SYntax browsers allow is different then spec in transforms.<br> <rachelandrew> irc only<br> <Rossen_> TabAtkins, can you mute pls<br> <krit> https://github.com/w3c/csswg-drafts/issues/2623#issuecomment-388005994<br> <dael> krit: We have transform attribute that uses svg syntax. IS some ways incompat to css syntax. Since there's interop between browsers do we accept transform attribute is using sv syntax or do we force browsers to support css?<br> <dael> krit: Tests^<br> <dael> chrisl: Given there's interop we should go for that.<br> <dael> chrisl: Given we're chartered to doc what works now we have to go with situation as it is.<br> <dael> Rossen_: As an impl that just added this, having had to do all the work to support both parser and object model version I wouldn't rush to modify one or the other. Certainly not css transforms. Doc what's fully interop is very much supported by us<br> <dael> krit: Might mean we can't support css syntax in the future for transform attribute, but no indication an imple would pick that us<br> <dael> AmeliaBR: Way it's spec is that transform attribute is supposed to accept both legacy and new syntax. No one supports new css syntax. If we match current we say attribute is tied only to svg 1. Separate issue is what browsers support doesn't match what has been copied from svg 1 so still need to work to figure out what's interop and then define that in grammar. It's not a perfect match.<br> <dael> krit: Only difference as the tests show is that there's currently a requirement to have a comma or a space between numbers. That's not followed. Broader issue is do we ever want to support css transforms syntax? I don't think we can do both.<br> <dael> krit: Mostly because functions in css requiring function name and then paran. SVG allows spaces between. There's other things like SVG allows lots of separators and CSS is strict.<br> <dael> chrisl: i think we have to say for historical reasons there's differences.<br> <dael> krit: What about css transforms?<br> <dael> chrisl: means you have to use a selector to apply<br> <dael> krit: Also propose if you want new syntax you have to use a property<br> <dael> chrisl: agree<br> <dael> AmeliaBR: We lock down the attribute, no new features except those to match reality<br> <dael> Rossen_: That's our take.<br> <dael> Rossen_: To go back, is there any implications to CSS or where we need to give input? I'm not hearing changes or requirements to CSS. I would suggest if you want to discuss SVG lock down you do that with SVG and decide how to lock attribute. Are there specific questions for CSS?<br> <dael> krit: If the WG would object to that?<br> <dael> Rossen_: Group, do you object to having SVG WG define what SVG attribute should do?<br> <dael> AmeliaBR: Currently defined in transforms.<br> <dael> krit: Prob needs to stay<br> <dael> Rossen_: Take it out?<br> <dael> chrisl: Don't see need. No one is queuieng to change impl so doc what works<br> <dael> krit: Q from Rossen_ is if we spec differences in css transforms or in SVG<br> <dael> AmeliaBR: Agree with chrisl keep in same spec.<br> <dael> krit: Good idea<br> <dael> Rossen_: I don't have anything against that.<br> <dael> Rossen_: Do we need a resolution? Summary: SVG transform attribute will document what's interoperable.<br> <dael> AmeliaBR: Worth a resolution because that's a major change.<br> <dael> AmeliaBR: We've currently got ti spec the attribute accepts new and old syntax.<br> <dael> Rossen_: Okay.<br> <dael> krit: I'm fine SVG will define details. Resolve transform attribute is locked down to current interop impl is nice.<br> <dael> Rossen_: Other impl opinions?<br> <dael> krit: Webkit PoV securing status quo is preferred.<br> <dael> Rossen_: Blink or Gecko?<br> <dael> AmeliaBR: Issue was started by a Gecko contributed. He said he can make minor fixes.<br> <dael> Rossen_: dbaron are you guys okay?<br> <dbaron> oh, I thought I unmuted<br> <dbaron> I said it seems fine to me given what Robert said in the issue<br> <dael> Rossen_: TabAtkins ?<br> <dael> TabAtkins: I believe fine<br> <dael> Rossen_: Sounds like no impl object.<br> <dael> liam: Does anyone know what non-web SVG impl do?<br> <dael> Rossen_: Not sure. If any do something else and no major impl can support I'm not sure the use case.<br> <dael> AmeliaBR: as far as I know they stick to SVG 1.<br> <dael> liam: Thanks<br> <dael> Chrisl: it's not a weird syntax, they impl SVG 1.<br> <dael> liam: That was my expectation. Just checking if anyone looked.<br> <dael> Rossen_: Objections to document the SVG attribute to be as currently supported by all implementation, possibly with a note that future extentions will be made at CSS level<br> <dael> RESOLVED: SVG attribute reflects current interop, future improvements will be in css transforms<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2623#issuecomment-389582323 using your GitHub account
Received on Wednesday, 16 May 2018 16:29:04 UTC