<scribe> ScribeNick: krit
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.
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.)[End of scribe.perl diagnostic output]