- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 06 May 2019 21:02:35 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `Consider supporting some subset of CSS`, and agreed to the following: * `RESOLVED: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.` * `RESOLVED: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.` * `RESOLVED: Conforming renderer SHOULD ignore these features (if they don't ignore, they must treat them according to full SVG spec).` * `RESOLUTION:` * `RESOLUTION: var() should be allowed in all presentation attributes in SVG Native` <details><summary>The full IRC log of that discussion</summary> <krit> topic: Consider supporting some subset of CSS<br> <krit> GitHub: https://github.com/w3c/svgwg/issues/658<br> <krit> myles: Should we have some parts of CSS in SVG Native and if yes, which parts? Question is about complexity vs power of implementation.<br> <krit> myles: I have some thought about it.<br> <krit> myles: I could just start wait the discussion.<br> <krit> chris: We already have parts of CSS with the presentation attributes/properties<br> <krit> chris: keyframes and media queries are missing<br> <krit> myles: The draft currently says that style attribute and style element are forbidden<br> <krit> myles: I think there is a difference to using XML attributes and CSS properties. IMO those are different aspects<br> <krit> chris: The ways props and attires apply are different<br> <krit> myles: The attributes have a grammar that is specified in SVG and don't require a CSS parser. The style attribute does require a CSS parser.<br> <krit> AmeliaBR: Not true in SVG 2. All presentation attributes are specified by their CSS properties<br> <krit> AmeliaBR: E.g. SVG 2 would allow a comment in SVG attributes as well.<br> <krit> myles: That is one of the differences form SVG 1.1 to 2<br> <krit> myles: Should the rebase of SVG Native require a the CSS parser?<br> <krit> sairus: Could we use SVG OT as starting point?<br> <krit> myles: Talking about fundamentals: Not the properties that are supported is the current problem but the requirement of a CSS parser.<br> <krit> myles: I'd like to avoid a dependency on a CSS Parser.<br> <chris> can people hear me? I tred to speak a few times but maybe I was just being rude<br> <krit> myles: You can declare new CSS variables in style attribute but not in a. presentation attribute. If we match what browsers do it would expand it.<br> <chris> most of the differences don't add much functionality though<br> <chris> q+<br> <krit> myles: We would be adding dependency and complexity. We can already describe the set of features with presentation attributes. No need for style attribute that can clash with the other existing way.<br> <krit> AmeliaBR: You already mentioned CSS variables. So we need to use var() with a presentation attribute.<br> <krit> AmeliaBR: This is strongly recommadate in SVG OT.<br> <krit> myles: The CSS variables work more like env()<br> <chris> q+ again<br> <krit> AmeliaBR: yes, that is right<br> <krit> AmeliaBR: That still requires CSS parsing rules for var()<br> <krit> myles: it just supports a subset and therefor is even more restricted<br> <krit> myles: We have parts that run through CSS lever in our application but only for a few attributes.<br> <myles> s/lever/lexer/<br> <krit> myles: there are a couple of feature that are in OT that are specific to OT like color tables<br> <krit> myles: we might want to have our own subset and OT extends it.<br> <krit> sairus: We also need to consider features like variable fonts that may extend SVG OT.<br> <krit> sairus: ditto for blend with a delta specified<br> <krit> sairus: just want to mention that OT may expand SVG beyond variations<br> <krit> chris: Most of the stuff you can add to style don't add any value. Same for comments you could add.<br> <krit> chris: being able to specifying new presentation attributes and discussion around properties.<br> <krit> myles: Do you want to bring variations up for a future call?<br> <krit> sairus: yes. Agenda would be to discuss blend.<br> <chris> +1 to participatory, open ended discussion<br> <krit> sairus: If we include it to SVG what would the SVG community think about it<br> <krit> sairus: currently just a few folks involved at this point.<br> <krit> sairus: Couldn't bring it up today because I thought I didn't have a proposal.<br> <krit> AmeliaBR: might want to start a GitHub issue<br> <myles> https://github.com/w3c/svgwg/issues/677<br> <krit> krit: Does anyone think that style attribute is a must?<br> <krit> chris: Don't think so but custom properties are hard to add then<br> <krit> AmeliaBR: Even if we only do presentation attributes, which units would we allow?<br> <chris> ooh yes, calc<br> <krit> AmeliaBR: Fair to not support style initially.<br> <krit> AmeliaBR: But we should consider adding calc to the presentation attributes.<br> <krit> krit: as more features form CSS we bring up, the harder it is not to require a CSS parser/lexer<br> <krit> AmeliaBR: Only a subset of it<br> <krit> krit: Objections to not support style attribute?<br> <krit> <don't hear any><br> <krit> myles: Means SVG NAtive ignores style<br> <krit> AmeliaBR: yes<br> <chris> Amelia phrased it very well<br> <krit> AmeliaBR typing the proposal...<br> <AmeliaBR> Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute. Conforming renderer may ignore these features (if they don't ignore, they must treat them according to full SVG spec).<br> <chris> +1<br> <krit> myles: may may lead to diverging implementations. Can we make it a should?<br> <krit> AmeliaBR: problem is that you'd ask a full SVG implementation to differ functionality depending on the MIME type.<br> <krit> myles: I think that is what should happen.<br> <krit> myles: I don't think it increases implementation complexity.<br> <krit> myles: benefits outweight the cons.<br> <krit> AmeliaBR: you thinking from your perspective of a platform rendering implementation.<br> <chris> Good idea, but that also argues for a different MIME type<br> <krit> AmeliaBR: authoring tools want to write both formats and don't have 2 paths for export and may not want to implement switches to turn off features. Ditto for server side rasterisers.<br> <krit> myles: a server rasteriser would probably use a different implementation<br> <krit> AmeliaBR: requires the server to have 2 implementations.<br> <krit> myles: would like to hear what Adobe says to it<br> <krit> krit: For export it would probably not matter much. We already support multiple profiles.<br> <krit> AmeliaBR: Issue is import of SVG Native but has extra features. Should the implementation not import with this features?<br> <krit> Tavmjong: I don't think we would turn off features in import. We would support SVG Native as export though.<br> <krit> myles: Most common workflow is to open authoring tool: create the artwork, they would use a native file format and export to SVG Native.<br> <krit> myles: The file could then get delivered to an environment that requires SVG Native on opening.<br> <krit> myles: Authoring tool import would not matter.<br> <myles> s/not matter/not be the common case/<br> <krit> AmeliaBR: Question is about making a mandation that would require authoring tools to disable features on import.<br> <krit> sairus: For import, authoring tools could mention that there are features not support in SVG Native.<br> <krit> AmeliaBR: what about a spec that build up on SVG Native.<br> <krit> AmeliaBR: What if OT adds more features? Would SVG Native viewer ignore.<br> <krit> krit: I'd like to add, are SVG OT files no SVG Native documents since they are not using the same subset?<br> <krit> myles: I think color tables are unique in OT and would not require SVG Native additions.<br> <krit> myles: Presence of var() would be a parse failure.<br> <krit> sairus: Seems like SVG Native would be a golden goal but there would be a lot of circles around it and ppl would build on top of SVG Native but not use SVG Native.<br> <krit> AmeliaBR: the var() function would be support but w/o any way to declare a custom property<br> <chris> I agree with Sairus that SVG Native is going to need ICC colors down the road<br> <sairus> <path fill="var(--color0, yellow)" d="..." /><br> <krit> myles: An SVG NAtive viewer would need to understand what var() is but uses the fall back since it doesn't know the custom property<br> <krit> sairus: fill should be yellow in a SVG Native viewer<br> <krit> AmeliaBR: that is the idea.<br> <krit> myles: When rebasing to sVG 2, would be straight forward to allow CSS variables.<br> <krit> AmeliaBR: sounds like we will support CSS but with limitations<br> <AmeliaBR> SVG 2 required CSS properties: https://svgwg.org/svg2-draft/styling.html#RequiredProperties<br> <AmeliaBR> SVG 2 required CSS features: https://svgwg.org/svg2-draft/styling.html#RequiredCSSFeatures<br> <krit> chris: What do we want browser to do. If browsers are not changing, it must be a may.<br> <krit> myles: I'd suspect browsers to use the system parser.<br> <chris> ok so far<br> <krit> AmeliaBR: we can still keep the must from my first proposal<br> <AmeliaBR> RESOLVED: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.<br> <krit> RESOLVED: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.<br> <AmeliaBR> Proposed: Conforming renderer SHOULD ignore these features (if they don't ignore, they must treat them according to full SVG spec).<br> <krit> AmeliaBR: we are still debating if we should ignore style attribute when present.<br> <krit> RESOLVED: Conforming renderer SHOULD ignore these features (if they don't ignore, they must treat them according to full SVG spec).<br> <krit> AmeliaBR: we can change later depending on implementers feedback.<br> <krit> AmeliaBR: Within the presentation attributes, should we support var()? calc()?<br> <krit> AmeliaBR: I;d like to start with units and percentages<br> <krit> AmeliaBR: If we remove relative values and percentages we don't need calc()<br> <krit> myles: OT allows percentages<br> <krit> AmeliaBR: disallowing font relative units makes sense since SVG Native does not have text anyway<br> <krit> AmeliaBR: percentage support depends<br> <krit> krit: var() function would be supported for all presentation attributes?<br> <krit> sairus: Right now OT should only be set on color values.<br> <krit> myles: Reason for OT was color parsing and CSS lexer in out implementation<br> <krit> myles: we might support it everywhere<br> <krit> RESOLUTION:<br> <chris> +1<br> <krit> RESOLUTION: var() should be allowed in all presentation attributes in SVG Native<br> <sairus> (sorry, had to leave – back to my team's offsite/onsite meeting)<br> <krit> trackbot, end telcon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/658#issuecomment-489775534 using your GitHub account
Received on Monday, 6 May 2019 21:02:36 UTC