<scribe> ScribeNick: krit

Planning feature work

AmeliaBR: We do still need a strategy for SVG 2. .. getting it tidied up and a test suite
... I am finishing up the review of changes that needs testing, chapter by chapter
... ... with all the changes since SVG 1.1
... We don't seem to move forward on test and spec clean-up. I don't have a specific recommendation. Clean-up and testing SVG 2 should be our priority.

krit: Agree. Please take time to review open issues and create PRs for the outstanding changes. Can not put items on the agenda that are not ready to discuss.

AmeliaBR: Maybe someone has suggestions how we can prioritise and organise the work on SVG.

krit: Can try to find issues that can be discussed in the call in the future. Most issues don
... don't needs discussions but edits.

AmeliaBR: Not sure what we can do but assigning issues to people and request to work on those issues.
... With the work on the SVG Native spec I am getting concerned with the work on the main SVG 2 spec.

krit: More contributions and work form members is needed to continue the work on SVG 2.

Consider supporting some subset of CSS

GitHub: https://github.com/w3c/svgwg/issues/658

myles: Should we have some parts of CSS in SVG Native and if yes, which parts? Question is about complexity vs power of implementation.
... I have some thought about it.
... I could just start wait the discussion.

chris: We already have parts of CSS with the presentation attributes/properties
... keyframes and media queries are missing

myles: The draft currently says that style attribute and style element are forbidden
... I think there is a difference to using XML attributes and CSS properties. IMO those are different aspects

chris: The ways props and attires apply are different

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.

AmeliaBR: Not true in SVG 2. All presentation attributes are specified by their CSS properties
... E.g. SVG 2 would allow a comment in SVG attributes as well.

myles: That is one of the differences form SVG 1.1 to 2
... Should the rebase of SVG Native require a the CSS parser?

sairus: Could we use SVG OT as starting point?

myles: Talking about fundamentals: Not the properties that are supported is the current problem but the requirement of a CSS parser.
... I'd like to avoid a dependency on a CSS Parser.

<chris> can people hear me? I tred to speak a few times but maybe I was just being rude

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.

<chris> most of the differences don't add much functionality though

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.

AmeliaBR: You already mentioned CSS variables. So we need to use var() with a presentation attribute.
... This is strongly recommadate in SVG OT.

myles: The CSS variables work more like env()

AmeliaBR: yes, that is right
... That still requires CSS parsing rules for var()

myles: it just supports a subset and therefor is even more restricted
... We have parts that run through CSS lexer in our application but only for a few attributes.
... there are a couple of feature that are in OT that are specific to OT like color tables
... we might want to have our own subset and OT extends it.

sairus: We also need to consider features like variable fonts that may extend SVG OT.
... ditto for blend with a delta specified
... just want to mention that OT may expand SVG beyond variations

chris: Most of the stuff you can add to style don't add any value. Same for comments you could add.
... being able to specifying new presentation attributes and discussion around properties.

myles: Do you want to bring variations up for a future call?

sairus: yes. Agenda would be to discuss blend.

<chris> +1 to participatory, open ended discussion

sairus: If we include it to SVG what would the SVG community think about it
... currently just a few folks involved at this point.
... Couldn't bring it up today because I thought I didn't have a proposal.

AmeliaBR: might want to start a GitHub issue

<myles> https://github.com/w3c/svgwg/issues/677

krit: Does anyone think that style attribute is a must?

chris: Don't think so but custom properties are hard to add then

AmeliaBR: Even if we only do presentation attributes, which units would we allow?

<chris> ooh yes, calc

AmeliaBR: Fair to not support style initially.
... But we should consider adding calc to the presentation attributes.

krit: as more features form CSS we bring up, the harder it is not to require a CSS parser/lexer

AmeliaBR: Only a subset of it

krit: Objections to not support style attribute?

<don't hear any>

myles: Means SVG NAtive ignores style

AmeliaBR: yes

<chris> Amelia phrased it very well

AmeliaBR typing the proposal...

<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).

<chris> +1

myles: may may lead to diverging implementations. Can we make it a should?

AmeliaBR: problem is that you'd ask a full SVG implementation to differ functionality depending on the MIME type.

myles: I think that is what should happen.
... I don't think it increases implementation complexity.
... benefits outweight the cons.

AmeliaBR: you thinking from your perspective of a platform rendering implementation.

<chris> Good idea, but that also argues for a different MIME type

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.

myles: a server rasteriser would probably use a different implementation

AmeliaBR: requires the server to have 2 implementations.

myles: would like to hear what Adobe says to it

krit: For export it would probably not matter much. We already support multiple profiles.

AmeliaBR: Issue is import of SVG Native but has extra features. Should the implementation not import with this features?

Tavmjong: I don't think we would turn off features in import. We would support SVG Native as export though.

myles: Most common workflow is to open authoring tool: create the artwork, they would use a native file format and export to SVG Native.
... The file could then get delivered to an environment that requires SVG Native on opening.
... Authoring tool import would not be the common case.

AmeliaBR: Question is about making a mandation that would require authoring tools to disable features on import.

sairus: For import, authoring tools could mention that there are features not support in SVG Native.

AmeliaBR: what about a spec that build up on SVG Native.
... What if OT adds more features? Would SVG Native viewer ignore.

krit: I'd like to add, are SVG OT files no SVG Native documents since they are not using the same subset?

myles: I think color tables are unique in OT and would not require SVG Native additions.
... Presence of var() would be a parse failure.

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.

AmeliaBR: the var() function would be support but w/o any way to declare a custom property

<chris> I agree with Sairus that SVG Native is going to need ICC colors down the road

<sairus> <path fill="var(--color0, yellow)" d="..." />

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

sairus: fill should be yellow in a SVG Native viewer

AmeliaBR: that is the idea.

myles: When rebasing to sVG 2, would be straight forward to allow CSS variables.

AmeliaBR: sounds like we will support CSS but with limitations

<AmeliaBR> SVG 2 required CSS properties: https://svgwg.org/svg2-draft/styling.html#RequiredProperties

<AmeliaBR> SVG 2 required CSS features: https://svgwg.org/svg2-draft/styling.html#RequiredCSSFeatures

chris: What do we want browser to do. If browsers are not changing, it must be a may.

myles: I'd suspect browsers to use the system parser.

<chris> ok so far

AmeliaBR: we can still keep the must from my first proposal

RESOLUTION: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.

RESOLUTION: Conforming SVG Native document MUST NOT use <style> element, linked stylesheets, or style attribute.

<AmeliaBR> Proposed: Conforming renderer SHOULD ignore these features (if they don't ignore, they must treat them according to full SVG spec).

AmeliaBR: we are still debating if we should ignore style attribute when present.

RESOLUTION: Conforming renderer SHOULD ignore these features (if they don't ignore, they must treat them according to full SVG spec).

AmeliaBR: we can change later depending on implementers feedback.
... Within the presentation attributes, should we support var()? calc()?
... I;d like to start with units and percentages
... If we remove relative values and percentages we don't need calc()

myles: OT allows percentages

AmeliaBR: disallowing font relative units makes sense since SVG Native does not have text anyway
... percentage support depends

krit: var() function would be supported for all presentation attributes?

sairus: Right now OT should only be set on color values.

myles: Reason for OT was color parsing and CSS lexer in out implementation
... we might support it everywhere

RESOLUTION:

<chris> +1

RESOLUTION: var() should be allowed in all presentation attributes in SVG Native

<sairus> (sorry, had to leave – back to my team's offsite/onsite meeting)

trackbot, end telcon

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/lever/lexer/
Succeeded: s/not matter/not be the common case/
Default Present: krit, AmeliaBR, stakagi, sairus, Tavmjong, myles, chris
Present: krit AmeliaBR stakagi sairus Tavmjong myles chris
Regrets: ThomasS RevinderS
Found ScribeNick: krit
Inferring Scribes: krit

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 06 May 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)