SVG Working Group Teleconference -- 11 Feb 2015

<trackbot> Date: 11 February 2015

<heycam> Meeting: SVG Sydney F2F 2015 day 1

<birtles> scribe: birtles

<scribe> scribenick: birtles

Publication of the Accessibility mapping document

<heycam> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

heycam: some of you would have gone to the telcon with the accessibility tf a couple of weeks ago to review the publication

ed: I went to the telcon and sent some review comments

<shepazu> +1 to publication

ed: it describes how to represent SVG markup in an accessible way
... it's outside of SVG so it doesn't affect our spec so much
... there's a table in the SVG spec at the moment

heycam: so that would be replaced by a reference to this document?

ed: I suppose so

<shepazu> (well, it describes the mapping of SVG elements to the underlying platform accessibility APIs

krit: I think we should keep the table to make sure that everyone knows that accessibility is important to us

heycam: shepazu, did you attend the call with the accessibility tf

shepazu: yes, I attend them all
... I wanted to be clear about what the doc is for
... it doesn't describe how to make SVG accessible
... it says which parts of SVG map to which parts of the accessibility API
... e.g. links, groups elements, what do they actually do
... as you can expect, there are very few native mappings
... because SVG doesn't have the kind of rich interaction modes that HTML has: forms, headings etc.
... but this is a good first step, lays the the groundwork for how accessibility APIs should map to SVG
... the document says, of the features that are in SVG, what are the interaction modes with the native accessibility APIs

richardschwerdtfeger: every platform that supports accessibility has an API for exposing different items
... what this document does is it says that when you put this (SVG) content in your web page, this is how you expose it to those APIs so that the accessibility technology
... can interact with it like any other software applicaiton
... so this spec is actually an extension to a core specification for all browsers
... we're doing the same thing for HTML but it just happens that the SVG one is getting out ahead of the HTML one because I happened to work on this first

shepazu: I forgot the detail about the accessible name computation
... for example, that will give you the title
... so there's a name and a description?

richardschwerdtfeger: correct
... each of the APIs has a method that will correlate to an SVG element
... and that will give you more information like descriptions

shepazu: for example, if you're using a screen reader
... you have 5 circles, each has a title, the screen reader would go through them in document order
... each of them represents a different thing
... it would go through, and say, in document order, the title for each one
... if you had a description it might also, e.g. beep, to tell you there's more information
... so you can say, "I want more information"
... so it would read the title, but not the description unless you ask for it

heycam: richardschwerdtfeger, you're looking to publish this as FPWD right?

richardschwerdtfeger: correct

krit: are there any issues that need to be discussed?

richardschwerdtfeger: I don't think so
... there are a couple of issues we need to address about *not* mapping things
... but they are already issues in the spec

shepazu: this is just a FPWD, but it's pretty complete

heycam: do we agree to publish a FPWD?

krit: agree

<shepazu> +1

<richardschwerdtfeger> +1

RESOLUTION: SVGWG agrees to publish the accessibility mappings document as a FPWD

shepazu: thanks for all your work richardschwerdtfeger

Adding new integer enum values in light of not going ahead with new SVG DOM

heycam: we made a decision a little while ago to stop adding new numeric constants to the DOM
... today it's considered a bit of an anti-pattern

<scribe> ... new APIs use strings as their enum values

UNKNOWN_SPEAKER: HTML does that
... the original SVG DOM has a lot of numeric values for enums
... that consists of a property that takes a number and a bunch of numeric constants defined on that interface
... we decided to not propagate any more usage of this
... by saying that any new enums should use strings
... but also by saying that for enums that we extend, we won't add any new numeric values
... but represent those using the zero value
... and we'd introduce a new DOM to fix this later
... but since we're probably not going ahead with that new API perhaps we should add numeric constants for the new values
... I think we shouldn't squash all those new values into the zero value

ed: so just new numbers or new constants too?

heycam: adding new numbers would fix the implementation difficulty but not the authoring difficulty

krit: I'm concerned with maintaining the list of numbers
... both in spec terms and implementation terms
... I don't think we can keep up with all the new units etc. that get coined

heycam: so krit you're not in favour?

krit: not really

ed: I'd prefer to drop the enum values and add some other method of using the new units (eg passing strings into methods that take those enums currently)
... I don't think we have useage counters for the methods that do take the numeric values

krit: could we move the whole section about the SVG DOM to a separate document?

heycam: but a lot of the SVG DOM stuff is reflecting things defined only in the SVG spec
... if people aren't enthusiastic with my proposal I'm happy with sticking with the status quo

krit: if we keep the SVG DOM, then it will get used more and more and become harder to change

ed: is it worth changing the methods that take these values into taking a string, for example

krit: you could try to disable certain APIs, not the whole API, but just one API at a time

heycam: I thought you (krit) were going to try that already?

krit: I was going to, but don't have time

ed: we do have usage counters for things like the animated types, suspendRedraw etc.

heycam: we want to know specifically for things like getAnimVal etc.
... we're not going to remove getBBox() for example

krit: it's probably safe to just map animVal to baseVal since IE does it

ed: the use of the SVG DOM is 0.04%

TabAtkins: 0.04% is still high but it would worth breaking down those numbers to find out which parts we could remove

ed: I've added use counters for path segment interfaces and those are very low
... we can certainly add more use counters but we need to know what to measure

heycam: the most important to me is the animVal interfaces

ed: SVGAnimatedTransformList.baseVal usage is very low

krit: what is used then?
... if not paths or transforms

ed: probably animated lengths

krit: everyone uses animVal
... I think we should just map animVal to baseVal

shane: I think could remove baseVal

krit: I'm not sure
... did MS get any complaints about not supporting animVal?

(some discussion about which is used more commonly, animVal or baseVal)

heycam: it would be helpful to get some usage counters on animVal / baseVal

<scribe> ACTION: ed to add usage counters to blink to measure usage of animVal / baseVal [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3701 - Add usage counters to blink to measure usage of animval / baseval [on Erik Dahlström - due 2015-02-18].

Avoiding new camelcase names

heycam: this is something we already agreed to do
... but we still have newish names in the spec that use camelCase

Tav: we have meshGradient and I think it should match linearGradient and radialGradient

heycam: that's the question: consistency with existing things vs awkwardness of updating the HTML parser

shane: I think consistency argument is a strong one

ed: I agree
... but for new attributes that don't need to be consistent with anything they should be lowercase

heycam: I think <meshGradient> could be just <mesh> since it can render by itself

Tav: in Inkscape it was easy to implement meshGradient based on existing gradient code
... implementing rendering by itself could take some time

krit: if meshes can be a shape then I think the argument for renaming to <mesh> is strong

heycam: there's still the child elements, <meshRow> etc.

roc: they could be lowercase

ed: do we want to rename it to <mesh>?

roc: yes

TabAtkins: yes

nikos: can you choose to fill it with something other than a gradient?

(no)

heycam: I checked the HTML spec and it doesn't have these names in it yet

nikos: you could have a paint server that defines the gradient and normal SVG shapes that define the mesh

krit: would that simplify things?

Tav: that complicates things

heycam: I think it's going to be pretty common to want to use the same geometry
... Tav, what do you think about renaming to <mesh> and renaming the child elements to make them lowercase

Tav: I'm not going to jump and down, but I guess it's ok

krit: I think it's confusing that linearGradient by itself doesn't render, but a meshGradient does--so renaming makes sense

Tav: so the children would be mesh-row

(no, dashes are reserved)

(some discussion about using <row> and about it being to generic)

krit: I think we agree we don't want camelCase within the mesh

RESOLUTION: Rename <meshGradient> to <mesh> and make the child element names lowercase

heycam: the remaining new camelCase names are the hatch ones (hatchPath)

Tav: so that would become lowercase

krit: can we just use normal paths...

Tav: we talked about that before and decided this was best

RESOLUTION: Rename <hatchPath> to <hatchpath>

heycam: the other new camelCase element name is solidColor
... I'm not thrilled by this element but Tav's argument is that implementing variables is more overhead
... you can also get the same effect with a gradient with a single stop

Tav: but that's really ugly in the code

heycam: assuming that element stays, can we lowercase it?

Tav: I don't care

RESOLUTION: Rename <solidColor> to <solidcolor>

ed: attribute names? camelCased?
... we have a bunch of them and we should try and avoid them if we can
... I found playbackOrder and timelineBegin

heycam: attribute names and attribute values are slightly different
... attribute names have to be handled in the HTML parser
... attribute values are more of just an aesthetic thing
... I think it would be better to make them lowercase

ed: we have a hatchTransform attribute

Tav: that follows the patternTransform and gradientTransform attribute

krit: gradientTransform maps transform so we shouldn't make that mistake again
... we should just use transform

RESOLUTION: Rename hatchTransform to transform

ed: there are other ones like hatchContentUnits and hatchUnits

<scribe> ACTION: ed to write up a list of all new camelCase attributes with a proposal of how to handle them (e.g. rename, keep etc.) [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action02]

<trackbot> Created ACTION-3702 - Write up a list of all new camelcase attributes with a proposal of how to handle them (e.g. rename, keep etc.) [on Erik Dahlström - due 2015-02-18].

Attribute parsing overhaul

heycam: my most recent change to the spec is to unify the parsing of attributes and how their grammars are defined
... previously there was a bit of a mish-mash of "this attribute is defined in terms of CSS meta-syntax, this one is EBNF etc."
... of those I think the CSS syntax is the nicest so I converted all of the attributes to use that
... so using [] for grouping, referencing CSS types etc.
... which meant I was able to remove a lot of the types chapter

<heycam> https://svgwg.org/svg2-draft/types.html#syntax

heycam: which defined a lot of the re-useable types
... I replaced the section that defined things like length, list of strings etc., with this section
... most of these are using CSS now, a couple still use EBNF because they reference other specs, or path data which is quite complex
... I've updated lists to use CSS
... one important change is that I'm not sure that we want to call into the CSS parser without flags...
... should we allow comments, escapes etc.?
... or should I make Tab add flags to the CSS parser to disable these features?

TabAtkins: unless you think it will cause problems, I think we should allow comments, CSS escapes etc.

ed: which attributes does this affect? presentation attributes?

heycam: presentation attributes already map to CSS so allow those things
... the reason I hesitate about allowing those things elsewhere is it means implementations have to update to call the CSS parser for these attributes

<TabAtkins> <path d> is basically impossible to convert to CSS grammar anyway. "h10v10" is a single <ident-token>, for example. Disentangling that is super hard.

<TabAtkins> I did it for An+B and <urange>, and it was terrible both times, and <path d> will be *much worse*.

cyril: how did you test that the new grammar matches the old?

heycam: most of them are pretty simple

cyril: are there any hard ones?

heycam: the ones that are either space or comma separates--I think I got them right
... it's not a common pattern in CSS

(discussion about whether heycam got the grammar right, seems like he probably did)

<heycam> https://svgwg.org/svg2-draft/shapes.html#DataTypePoints

<TabAtkins> To do a list of <foo> that is comma-or-whitespace, do <foo>+#?

heycam: this looks weird for CSS syntax but I think it's right

<heycam> https://svgwg.org/svg2-draft/text.html#TextElementXAttribute

heycam: this might need to change, particularly because we have the new x/y properties

krit: can you remove the number from [<length> | <percentage> | <number>]
... because it is implicitly allowed for attributes

heycam: is that right?
... properties that can take lengths can also take numbers in SVG
... during this conversion I made this explicit by adding in <number>

TabAtkins: you can also use quirky-length
... it's length or number with number meaning pixels

heycam: I'd like to make it explicit
... regarding percentages which krit brought up recently
... I haven't gone through it properly yet but I've tried to add in percentages

shane: we're exposing the path syntax in CSS with the Motion Path module

krit: but there's it's a string, it's not parsed

heycam: so is this conversion ok?

(question about formatting of attribute formatting--text chapter is yet to be done)

<krit> scribeNick: krit

What to do with the embedded content chapter

<heycam> https://svgwg.org/svg2-draft/embedded.html

heycam: this is about iframe, video, audio
... we had objections from ppl about that approach for at least the iframe
... ppl didn't like adding them to the SVG NS and we should solve these in other ways
... This has to do how we merge NS or get rid of them but that is a long term goal
... what do we do in the spec now?
... it is possible to use these futures with foreignObject
... is that maybe sufficient enough?
... We could add notes that this is a way to get video and others
... and describe how video and audio could work in SVG later

birtles: I would be interested in <box> as a light weighted version of <foreignObject>

<birtles> specifically, <box> also shrink-wraps its contents

<birtles> see discussion from TPAC last year: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_integration_again

BogdanBrinza: We implement foreingObject and box would just be a special case of fO

heycam: do you want it in SVG2 or is it ok for SVG3?

birtles: With a rapid release cycle I am ok with defer

heycam: so box would take width and height

birtles: right

roc: it is actually inline

heycam: do you have a proposal for box?

birtles: I was pesismisitic about the 2 experiments around october

<birtles> TPAC discussion: http://www.w3.org/2014/10/31-svg-minutes.html#item09

birtles: I am starting to lean more to <box> than the alternatives

roc: so you have a preferred intrinsic width
... you have a min width and the intrinsic with and this is the width you actually get
... you need to have some way of controlling the box element some kind of idea what the width

krit: why can

t that be the intrinsic width?

heycam: what happens on abs pos?

roc: it comes from the containing block

krit: could box create a initial containing block

roc: not initial but definitely a containing block
... for relative positioning
... it would still need a width constrain
... otherwise it is flying of the page what you don't want
... so you need to come up with a reasonable default

heycam: we can do that. I like <box>

roc: is it really so hard to get iframe, video, audio and element with intrinsic with to be a direct part of a SVG container
... i didn't like to have a iframe element that was different than the one in HTML

heycam: what about the NS?

roc: would be HTML

ed: what about the XML parser?

<shepazu> +1 to just use the HTML elements for iframe, audio, video, etc

heycam: you can't SVG image in and SVG context

roc: it could be svg/xml
... that does not require XML parsing
... you gonna not have a iframe video and an SVG image
... you could do all the things in XML as well, just put more code on it

ed: how do we proceed

<shepazu> (is it feasible to remove namespaces from browsers at this point? how much would it break?)

<shepazu> (I mean in an HTML/SVG context)

krit: do we do that for SVG2 or SVG3?

heycam: there are a lot of details we need to discuss

TabAtkins: we don't have to worry about this
... we don't have to care about an SVG image in an HTML document now
... allowing HTML parser for the SVG images makes it easy to use video and audio but we don't have to care about that
... all JS functions can create HTML element by adding the NS
... we can do SVG in HTML later
... and use a limited set of THML element into SVG now

heycam: so we only need to this parser change and state in the spec what an HTML element means in the SVG NS

birtles: if we can do that approach than this is enough for SVG2
... we still need to add the x,y presentation attributes on the iframe element and Ian doesn't want to do that

roc: we should force this issue
... we should stick to replaced element

birtles: that would be a good start

krit: replace elements means allowing object and embed as well

roc: well yes, we don't want to do that
... we should limit the list to a fixed set of elements and allow replaced elements later

krit: we would still depend onHTML parser changes and the x,y attributes

roc: we will need CSS terms
... like some kind of containing block

TabAtkins: would be the nearest SVG viewport

roc: we need to say if they are display: block or inline

TabAtkins: everything is implicitly position in SVG so it would be block

roc: that is fine

RESOLUTION: Allow HTML NSed elements audio, video, canvas, iframe in an SVG subtree as a child of a container element with the containing block being the nearest SVG viewport and blockyfied

<scribe> ACTION: heycam to change embedded content chapter to allow these things from resolution: Allow HTML NSed elements audio, video, canvas, iframe in an SVG subtree as a child of a container element with the containing block being the nearest SVG viewport and blockyfied [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action03]

<trackbot> Created ACTION-3703 - Change embedded content chapter to allow these things from resolution: allow html nsed elements audio, video, canvas, iframe in an svg subtree as a child of a container element with the containing block being the nearest svg viewport and blockyfied [on Cameron McCormack - due 2015-02-19].

<scribe> ACTION: TabAtkins write the SVG layout spec [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action04]

<trackbot> Created ACTION-3704 - Write the svg layout spec [on Tab Atkins Jr. - due 2015-02-19].

ed: there is an issue with the width and height properties take integers

krit: you mean the problem is a specified viewBox

ed: yes

roc: you can style with CSS

heycam: but you don't want to have half pixels in Canvas
... but it is probably a rare situation anyway

roc: I don't think there is any reason to handle video any specific way
... Canvas is special
... width and height map to CSS and nothing else happens but in Canvas these attributes also set the backing store

krit: it might be confusing that width/height are no presentation attributes but users know that from HTML already

<scribe> ACTION: TabAtkins convince Hixie to make the HMTL parser changes + x/y presentation attributes on the canvas,... elements for SVG [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action05]

<trackbot> Created ACTION-3705 - Convince hixie to make the hmtl parser changes + x/y presentation attributes on the canvas,... elements for svg [on Tab Atkins Jr. - due 2015-02-19].

<scribe> ACTION: TabAtkins Allow templates in SVG which needs HTML parser changes [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action06]

<trackbot> Created ACTION-3706 - Allow templates in svg which needs html parser changes [on Tab Atkins Jr. - due 2015-02-19].

heycam: we should also get <link> to work in SVG

ed: They might in browsers already

<heycam> ACTION: Cameron to investigate which HTML elements like <link> we might want to also allow in SVG [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action07]

<trackbot> Created ACTION-3707 - Investigate which html elements like <link> we might want to also allow in svg [on Cameron McCormack - due 2015-02-19].

krit: not sure that is the case. It didn't work for standalone SVG for me

ed: I'll test

<shepazu> +1 to letting <link> work in SVG... what about <meta> too?

<shepazu> http://schepers.cc/css-link-hack-in-svg

heycam: <meta> I want too

<heycam> sounds good to me; I'll gather a list of likely HTML elements to allow with my action

What is going to happen to the SVG DOM

nikos: have nothing specific about that
... we talked half about that in the previous session

heycam: we do the investigations with the use counters and drop SVG DOM interfaces over time

TabAtkins: most of the CSS OM stuff is going to work with SVG as well

Requiring foreignObject HTML behavior

heycam: we need to make spec say that HTML content in fO gets rendered

ed: I don't think we want to have the hasFeature for fO at all

<ed> hasFeature/requiredFeatures

heycam: we willhave a conformance class that will require HTML and another that doesn't
... the sizing of fO containing block should be in sVG2

roc: agree, there is a bunch of not clarified stuff

<scribe> ACTION: Reference integration spec and update conformance class for HTML support on foreignObject [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action08]

<trackbot> Error finding 'Reference'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: heycam Reference integration spec and update conformance class for HTML support on foreignObject [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action09]

<trackbot> Created ACTION-3708 - Reference integration spec and update conformance class for html support on foreignobject [on Cameron McCormack - due 2015-02-19].

Requiring style sheet support

Tav: we do support stylesheets but no fancy selectors

heycam: oh, that is what I want to require
... should we add a new conformance class maybe?

krit: no, we should require style sheet support
... authoring tools need to update at some part

Tav: we rely on someone else's library

<scribe> ACTION: hey cam add stylesheet requirements to the spec [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action10]

<trackbot> Error finding 'hey'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: heycam add stylesheet requirements to the spec [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action11]

<trackbot> Created ACTION-3709 - Add stylesheet requirements to the spec [on Cameron McCormack - due 2015-02-19].

Drop xml:base/lang/space attributes

ed: I have a test case that works the same way in all browsers

ed: the test case adds a <link> element and it works in all browsers I tested

<TabAtkins> http://www.xanthir.com/etc/svg.php?width=100&height=100&svg=%3Clink+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+rel%3D%22stylesheet%22+type%3D%22text%2Fcss%22+href%3D%22data%3Atext%2Fcss%2Ccircle+%7B+fill%3Agreen%3B+%7D%22%2F%3E%0D%0A%3Ccircle+cx%3D%2250%22+cy%3D%2250%22+r%3D%2225%22+fill%3D%22red%22%2F%3E

ed: this was to one of the previous topics

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/dropxmlattributes

ed: I split the proposal into several parts
... [explains more of the proposal as written in the document]

<ed> https://www.chromestatus.com/metrics/feature/timeline/popularity/580

ed: the usage of xml:base is 0

krit: and xml:lang?

heycam: so we do not support the IDL properties for those

ed: I would like to remove the IDL properties

krit: fine with me

RESOLUTION: Remove xml:base/space/lang from the SVG DOM interface

<scribe> ACTION: ed Remove xml:base/space/lang from the SVG DOM interface [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action12]

<trackbot> Created ACTION-3710 - Remove xml:base/space/lang from the svg dom interface [on Erik Dahlström - due 2015-02-19].

ed: the 2nd part is remove xml:base entirely
... and describe how the others work with the non-NSed versions
... this is a breaking change

krit: do you have data for that?

ed: no, but I still think we want to clean up the XML database

ACTION; Write tests and come back to the SVG for xml:base

<scribe> ACTION: Write tests and come back to the SVG for xml:base [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action13]

<trackbot> Error finding 'Write'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: heycam Write tests and come back to the SVG for xml:base [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action14]

<trackbot> Created ACTION-3711 - write tests and come back to the svg for xml:base [on Cameron McCormack - due 2015-02-19].

ed: I want to drop xml:line in favor for HTML line

heycam: we discussed in Switzerland
... lets remove it

RESOLUTION: Remove xml:lang in favor for HMTL lang

<scribe> ACTION: ed Remove xml:lang in favor for HMTL lang [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action15]

<trackbot> Created ACTION-3712 - Remove xml:lang in favor for hmtl lang [on Erik Dahlström - due 2015-02-19].

<scribe> ACTION: ed Write tests and come back to the SVG for xml:base [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action16]

<trackbot> Created ACTION-3713 - Write tests and come back to the svg for xml:base [on Erik Dahlström - due 2015-02-19].

ed: define xml:space in terms of the white-space property

heycam: elika agreed to add to CSS3 Text a value for whitespace with the same behavior as xml:space=preserve
... we should do all the mapping to whitespace property

REOSOLUTION: Map xml:space to whitespace property values in CSS3 Text

RESOLUTION: Map xml:space to whitespace property values in CSS3 Text

<scribe> ACTION: ed Map xml:space to whitespace property values in CSS3 Text [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action17]

<trackbot> Created ACTION-3714 - Map xml:space to whitespace property values in css3 text [on Erik Dahlström - due 2015-02-19].

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Proposal: drop the SVGPathSeg* interfaces and related methods/attributes

<ed> https://www.chromestatus.com/metrics/feature/timeline/popularity/568

ed: I added a use counter for any use of the SVGPathSeg* interfaces
... any thing that creates or uses those objects
... it's currently 0
... I'm proposing we just drop those

Tav: sure it's not a bug in the use counter?

krit: it's interesting

ed: people typically just build path strings
... the DOM interfaces are so verbose
... I don't know if we want to consider adding a new lightweight interface for manipulating path data

dmitry: I remember when trying to use this interface internally in Snap I ended up just using the string
... there was a reason why, don't remember what it was
... something was missing on the API

ed: there are other issues around it
... if we want to keep the interface, we need to add ones for the new path commands

roc: sounds great

shane: I'd like to consider a lightweight interface to share with CSS

krit: yeah

shane: because CSS is going to be defining new CSS value objects

krit: there's also the canvas Path object

<birtles> http://parapara-editor.mozlabs.jp/sandbox

RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies the use counter values are correct

<scribe> ACTION: Erik to verify that the SVGPathSeg interface use counter values are correct and to drop the interfaces if they are [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action18]

<trackbot> Created ACTION-3715 - Verify that the svgpathseg interface use counter values are correct and to drop the interfaces if they are [on Erik Dahlström - due 2015-02-19].

camelcased attributes

https://lists.w3.org/Archives/Public/www-svg/2015Feb/0024.html

ed: I went over the attribute appendix
... looking for new attributes we added to SVG 2 that are camelcased
... I found a couple
... first are canvasWidth/canvasHeight/frameWidth/etc.
... they already have an open issue in the spec
... I think we should rename them to width/height or just make them lowercase

heycam: I think for canvas we should do it like HTML, with width/height attributes giving backing store size and width/height properties for the visual size
... the other ones (frameWidth etc.) should just be dropped
... as we'll just keep the same attribute that are allowed on the HTML elements
... this is already covered by the previous resolution

ed: meshGradient has gradientTransform, let's just make it transform
... also meshGradient just got renamed to mesh

nikos: this would affect things when you use the mesh as a paint server
... gradientTransform is different from transform

krit: we can still make them the same thing, transform
... also the other gradients use the transform property for this

RESOLUTION: gradientTransform on mesh is renamed to transform

ed: next is hatchContentUnits
... I propose to keep it as is
... to match the other paint server Units attributes
... same for hatchUnits as well

TabAtkins: we could switch to units="" and contentunits=""

heycam: will they be used commonly on hatches?

Tav: yes

RESOLUTION: keep current namign of hatchUnits and hatchContentUnits

ed: next, hatch has hatchTransform
... we should make that transform

Tav: yep

RESOLUTION: rename hatchTransform to transform

ed: next is playbackOrder on <svg>
... I propose that we make it lowercase
... either with a dash between or not

krit: I agree to check with web animations first
... would be good to use the same keyword values

<ed> https://svgwg.org/svg2-draft/struct.html#SVGElementPlaybackOrderAttribute

birtles: I don't have any intention of adding that to web animations currently
... I prefer we don't add new animation features to SVG 2

krit: I don't like that we have it in SVG

birtles: but that other spec doesn't exist yet [SVG Animation Elements spec]
... playbackOrder, discard, timelineBegin; I would kind of prefer to stick them in a different spec, which describes SVG's animation features in terms of web animations

cyril: I would agree, but it doesn't exist

birtles: I don't know how important it is to have them in SVG 2

cyril: the discard element is pretty independent

ed: the timelineBegin thing, is that something that would be supported in web animations?
... beacuse that's a common feature request

birtles: yes

ed: people want to start animations while the document is loading
... for animated spinners etc.

birtles: so there's no compatibility issue there
... but there's no keyword you could borrow there either

ed: but you could define it so that it starts the timeline right away

birtles: that always happens
... it'd be just defining a dependent timeline to handle those two modes

cyril: playbackOrder is a hint
... it's not that important

krit: timelineBegin?

cyril: that's improtant
... and it maps to web animations

birtles: do whatever you like with attribute names
... it doesn't have names to match up with web animations

krit: I'm fine with lowercasing
... onLoad and onStart are not good keywords though

ed: they're very unspecific

cyril: that could be changed

ed: I'd like something that maps to event names

cyril: I think they were originally designed to map to SAX names

ed: but definitely let's not camelcase them

heycam: how about just lowercase the names for now and see if anyone has better keyword ideas

ed: ok

RESOLUTION: timelineBegin attribute name and keywords are lowercased
... playbackOrder becomes playbackorder

<scribe> ACTION: Erik to do the attribute lowercasing [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action19]

<trackbot> Created ACTION-3716 - Do the attribute lowercasing [on Erik Dahlström - due 2015-02-19].

-- lunch break --

<shane> ScribeNick: shane

Open issues that require discussion

heycam: let's start with introduction chapter. Cyril - were there things in the introduction that need discussion?

cyril: not really
... I looked at 1.1. Not entirely sure HTML5 needs to be mentioned given that it's in 1.4
... I edited 1.2 to remove mention of Macintosh file types
... old, not needed any more
... 1.4 was edited to reduce size. Didn't touch 1.5. 1.6: Moving terms & definitions to the chapter that first uses them.
... will continue doing that. A few commits not pushed yet. Doesn't need more work.

ed: do we really want to say that XVG is a language for describing 2D graphics _in XML_?

cyril: XML or other languages?

krit: markup?

cyril: SVG _is_ XML, right?

ed: sometimes

cyril: maybe can say that it can be integrated with a looser syntax?
... or just want to say it's a language for describing 2D graphics.

krit, ed: a markup language

heycam: the issues all seem like small tweaks

cyril: ISSUE 2: should we mention .svg.gz?

various: no, yes, maybe

consensus: yes

BogdanBrinza_: do we all agree that we want to move forwards to publication?

cyril: no objection

heycam: are you saying we should be a bit ruthless to get to that point?
... should see if there are any issues that really need to be solved

<shepazu> (SVG in HTML is not XML, and that is the biggest use of SVG at this point)

cyril: would like confirmation that it's OK to move the definitions

heycam: I like the idea of that. Don't like massive list of definitions

<shepazu> why not call it markup and leave it at that?

ed: I think it makes sense

<scribe> ACTION: Cyril don't stop [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action20]

<trackbot> Created ACTION-3717 - Don't stop [on Cyril Concolato - due 2015-02-19].

(correction - we won't mention .svg.gz)

<heycam> shepazu, I think calling it "markup" is fine

cyril: when I see duplicate definitions I merge and raise if there's a problem.
... e.g. bounding box

ed: different definitions of whitespace in animations and elsewhere. Fixed though.
... moving to CSS fixes it

krit: chapter 2
... I did some cleanup but I don't remember what

cyril: should move towards whole page in white and unclear areas in red

heycam: bit of work to make that change.

krit: isn't just stylesheet. Also requires markup changes

heycam: Who's editing this chapter?

nikos: done a fair few but not for a while. Not much here.

ed: some important definitions in this chapter, but would be OK to merge into a different chapter.

cyril: be careful, some definitions will move into this

heycam: wanted this chapter to be strict definition of how to paint an SVG subtree. Want references to CSS stacking order etc.

nikos: makes sense. At the moment only references SVG things, so seems a bit redundant. With external references it makes sense to capture all that in one place.

heycam: want to rework this chapter to do that then?

nikos: yes.

heycam: probably the right place to mention clip paths, masks, filters, blending

<scribe> ACTION: nikos to rework chapter 2 and incorporate references to external specifications [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action21]

<trackbot> Created ACTION-3718 - Rework chapter 2 and incorporate references to external specifications [on Nikos Andronikos - due 2015-02-19].

ed: want to mention knockout?

Tav: what's knockout?

nikos: compositing mode. Removed from spec
... still a description but no controls

heycam: I was going to add z-index

krit: I will do clipping, masking and filters

nikos: I don't mind having a first go at it
... probably best if I do it all as a first pass then we can clean it up
... is z-index mentioned anywhere else in SVG2 atm?

krit: how elements are rendered (2.5) - does this require mention of blending?
... seems we should merge 2.5 into 2.7-2.9

<scribe> ACTION: nikos to merge 2.5 into 2.7-2.9 [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action22]

<trackbot> Created ACTION-3719 - Merge 2.5 into 2.7-2.9 [on Nikos Andronikos - due 2015-02-19].

krit: we want to remove the section about clipping, masking and filtering, but some of it needs to move to other sections. e.g. overflow
... changed behaviour to be more like CSS. Do we need to describe it?
... visible by default. Some browsers already do this.

heycam: clipping and masking should still be referenced here.

krit, nikos: yeah, clipping and masking chapter should be merged into this.

Tav: would like an example of each in this spec
... so people can see what it's like without looking at the linked spec

krit, nikos: disagree

nikos: lots of issues on overflow

heycam: Chapter 3
... I've been touching this most recently
... attribute syntax summary, discussed that
... Issue 1 is resolved.

krit: issue 2 (reference discussion about lacuna values)

ed: also need to go through spec to check we have lacuna values for everything

<scribe> ACTION: heycam to resolve issue 2 in Chapter 3 [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action23]

<trackbot> Created ACTION-3720 - Resolve issue 2 in chapter 3 [on Cameron McCormack - due 2015-02-19].

krit Issue 3: wat?

heycam: needs some general wording about ???

krit

krit: Issue 4

<heycam> general wording about reflecting attributes

krit: blink removed this already (classname)
... didn't blink remove it already?

ed: don't think so

krit: do we want to remove this, or deprecate it?

ed: recommend classlist, don't know if we want to deprecate.

krit: I want to get rid of it.

heycam: me too
... have we already added a use counter for this?

ed: it's 0.32%.

krit: this might just be checking for SVG
... seen it used for this.
... so we just deprecate?

heycam: let's do that

<scribe> ACTION: heycam to mark classname as deprecated (issue 4 in chapter 3) [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action24]

<trackbot> Created ACTION-3721 - Mark classname as deprecated (issue 4 in chapter 3) [on Cameron McCormack - due 2015-02-19].

krit: Issue 5. Should just reference HTML

heycam: yeah, just need to clean up the wording

krit: HTML5 or live spec?

heycam: whatever the W3C people make us do

ed: need some definition on what focus means. So need to reference one.

heycam: Interface SVGLength. This is a long standing issue.
... SVGLength objects can convert between different units, one of which is percentages based on viewport size. If that's 0, what does it mean to convert a non-zero length to a percentage?

TabAtkins: whelp, it's infinity

heycam: just decide on some behaviour. Either 0, or throw exception, something

TabAtkins: or NaN

shane: NaN isn't right

heycam: don't really want to use NaN or infinity

shane: I think exception because you can't really use the values anyway

heycam: so throw exception if converting into % units in this case?

<scribe> ACTION: Heycam to specify that convertToSpecifiedUnits should throw an exception if converting to percentage with 0-sized viewport. [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action25]

<trackbot> Created ACTION-3722 - Specify that converttospecifiedunits should throw an exception if converting to percentage with 0-sized viewport. [on Cameron McCormack - due 2015-02-19].

krit: accessors for ch, rem, vw, vh, vmin, vmax

heycam: this is related to the slight DOM improvements we made, so you can do things like circle.cx.px (but also for new CSS units)
... if we reference CSS3 Values then there are more units. Should add accessors for those too.

shane: CSS is going to be doing this anyway.

krit: right, plus if you have to use animVal...

heycam: but you don't need to use animVal

shane: given there will be a spec that gives nice access to these, shouldn't add them

heycam: so what should we do?

TabAtkins/krit: remove them for now, ask CSS to prioritize

TabAtkins: actually it's TC39

RESOLUTION: remove unit accessors on SVGAnimatedLength

heycam: issue 11 is whether to add string accessor. Skip that too?

krit: especially because most of these length values are CSS properties now

heycam: hopefully people start to implement stuff in the CSSOM to make it easier to get at this stuff without using getComputedStyle()
... next issue (SVGGraphicsElement) - need wording to say that transform now looks up something to do with the property

ed: what do you mean?

krit: transform now stored in CSS so no DOM access. Need to reflect SVGAnimatedTransformList somehow.

heycam: discussed this years ago.
... transform's baseVal should reflect the presentation attribute for transform, and the animVal (if we can't lose it) should reflect the computed value of the transform property on the element

krit: should put this in the presentation attribute section

<scribe> ACTION: heycam to put this in the presentation attribute section [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action26]

<trackbot> Created ACTION-3723 - Put this in the presentation attribute section [on Cameron McCormack - due 2015-02-19].

krit: why deprecate nearestViewportElement?

ed: both nearest and furthest show very little usage

krit: is the peak on the graph an error? Seems strange
... doesn't fit.

ed: I've never seen this used.

heycam: let's nuke it

krit: could be useful for the video element?

ed: pretty simple to walk up and get the element you're interested in

RESOLUTION: remove nearestViewportElement and farthestViewportElement

krit: next issue is difficult (call getCTM on an 'svg' element).
... svg element has scale and translate (currentTranslate, currentScale). How does that get reflected in getCTM?

ed: resolved inside outside thing
... I think the example linked from there shows different results in different browsers

krit: then just pick the one that makes the most sense

ed: example doesn't use currentScale. Different results even with transform and viewport

heycam: needs more testing offline

<scribe> ACTION: krit to do testing around currentScale, CTM, transform, viewport, etc. on 'svg' element [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action27]

<trackbot> Created ACTION-3724 - Do testing around currentscale, ctm, transform, viewport, etc. on 'svg' element [on Dirk Schulze - due 2015-02-19].

heycam: getTransformToElement. Was wondering what happens if one element is in an iframe?

roc: getGeometry does this
... does anyone use this?

ed: nah

roc: why don't we move this to geometry utils and do it for all elements?

heycam: who owns that spec?

roc: Simon

heycam: People will want this with HTML anyway.

roc: it's actually a pain to use.
... we have conversion methods. More convenient than getting the matrix.
... so what's this used for?
... whatever it is, it's probably good for HTML as well.

heycam: converting points, e.g. from events

roc: we actually have better methods

ed: move elements around in the DOM tree

roc: geometryUtils has more convenient methods for that too
... so maybe see if it's being used, and remove it if not. If it's used, see if the usage makes sense then move.

krit: for SVG 2 we'll leave it in for now. Can deprecate it.

ed: will measure it. Can leave it in but with issue.

roc: who implements this?
... oh. we do. Damn

<scribe> ACTION: ed to measure usage [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action28]

<trackbot> Created ACTION-3725 - Measure usage [on Erik Dahlström - due 2015-02-19].

krit: that doesn't solve the issue

heycam: true, if we decide to keep it
... a minimal thing is to test what impls are doing and spec that for now.
... so we'll just update definition to fragment and move to GeometryUtils later, if we can't drop it.
... hasExtension.

ed: Gecko and WebKit check for XHTML, MathML. Blink always returns false.

krit: according to discussion on WhatWG

heycam: related to hasFeature which is what was discussed

ed: not sure it's very useful

heycam: I'd be surprised if people are calling this function

krit: let's just return false.

heycam: or remove it?
... don't think anyone is using it.

RESOLUTION: remove hasExtension

CHAPTER 4

heycam: this is ed's chapter

ed: first issue, namespaces in XML. Do we need all of it?

heycam: should have some wording about syntax. Should there be such a big focus on embedding in foreign XML namespaces?

ed: not sure what to put there, but maybe more about HTML?
... issue 2. Value column doesn't match new attribute syntax

heycam: need to figure out consistent formatting
... across the spec

ed: next. When zero is used on an outer 'svg' element, does this disable rendering? (for width, height)

heycam: good question.

ed: doesn't disable rendering. Overflow could be rendered.

heycam: is that only if you don't have a viewbox?

ed: good question.

krit: probably a special case.

ed: currently says it disables rendering. Not a change from 1.1. Let's keep it this way.

heycam: consistent with rectangles and other things
... question before: if you've got borders or backgrounds on the outer SVG, do they keep rendering?
... probably should keep rendering the box stuff and the content is disabled.
... maybe just add a note saying that the boxy stuff still renders

krit: one issue, it's not the specified value but the computed value that counts.

heycam: what happens in CSS if you have a 0 width box, and box-sizing that lets the borders appear outside?
... if you set the width of a box to 0 can things still render?

TabAtkins: yup
... box sizing still floors out at 0, so even if borders are internal they still render.

ed: issue 4 is a bout playbackOrder. Already decided to make it lowercase. How can we harmonize with Web Animations

krit: this is the one we could defer to L3, right?

shane: would like to talk about this with Brian as we have a similar problem in WA (talked about it yesterday)

krit: if we defer then you have time to figure a solution out.

ed: next issue, can we define seeking backwards so that there is no undefined behaviour?

shane: if we can figure out playbackOrder as part of Web Animations then there won't be undefined behaviour.

ed: can just link to it from here then.
... next issue already resolved.
... next, timelineBegin. Resolved on this. Should just link to Web Animations.
... next. What about when SVG fragment is within an XHTML document? Is there a single timeline for the whole document? When does it start?

<scribe> ACTION: birtles to specify something simple and consistent for timeline start in Web Animations. [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action29]

<trackbot> Created ACTION-3726 - Specify something simple and consistent for timeline start in web animations. [on Brian Birtles - due 2015-02-19].

RESOLUTION: adopt whatever Web Animations behaviour is specced and link to it from here.

ed: some paragraphs are out of place.
... svg handles same events as body.

krit: doesn't seem out of place as we're talking about svg here

heycam: I think these should be in the interaction chapter but it isn't important

RESOLUTION: Leave 'em

ed: next issue, about accessibility

krit: could add a note that these will be handled by a WG note in the future.

heycam: what's happening with the a11y appendix? It also contains waffle language like this.

krit: had an external document before. Very old though.

ed: what should we do?

heycam: this paragraph is very superficial

krit: can we just remove the section?

RESOLUTION: Drop the paragraph

ed: next issue. Let's drop the <g> example

RESOLUTION: Drop the <g> example

heycam: next issue. Not clear what 'Any element that is not contained within a 'g' is treated as if it were in its own group' means.

nikos: maybe to do with blending and compositing

heycam: can just remove this sentence

nikos: any specific point can be made in rendering chapter

RESOLUTION: remove this sentence

ed: next issue, accessibility in 4.3.1

heycam: should remove this sentence too.

krit: should just make it a note

heycam: ed can choose

ed: next issue. Term for definition elements?

heycam: things like filter, clippath, etc.
... actually, changed it. This issue doesn't apply any more.

ed: next issue, in 4.3.2 (defs).
... paragraph not needed

krit: example can go too

RESOLUTION: remove paragraph and example

<TabAtkins> ScribeNick:TabAtkins

ed: Issue 17, the discard element. Move that to animation chapter?

heycam: It's pretty animation-y to me.

ed: Agree.

cyril: Yeah, sure.

shane: We should be able to describe <discard> in terms of Web Anim.

krit: The IDL is missing for that?

cyril: I couldn't figure out how to do it.

ACTION cyril to add the IDL for <discard> and move it to animation chapter.

<trackbot> Created ACTION-3727 - Add the idl for <discard> and move it to animation chapter. [on Cyril Concolato - due 2015-02-19].

ed: Issue 19, also on the discard element
... Something about the attribute syntax needs fixing.

heycam: It's the list syntax thing. I'll fix it.

ed: Issue 20, I'll figure out if we need to import any text.

krit: Issue 21

heycam: There's a sentence in the paragraph about rendering <title> with a stylesheet, but I don't think it's easy, or maybe even possible.

RESOLUTION: Drop the offending sentence about styling <title>.

<tantek> I for one think <title> ought to be optional.

ed: Issue 22, lang needs to be defined.

heycam: <glyph> got removed, and lang links down to xml:lang. AS part of updating xml:lang to lang, should hopefully jsut work.

RESOLUTION: Remove issue 22.

RESOLUTION: Remove issue 22.
... Drop the offending sentence about styling <title>.

heycam: Issue 23 is about foreign namespace content inside of <desc>. Who does that?

ed: I'm in favor of removing the example.

RESOLUTION: Remove the example about foreign-namespace content in <desc>.

heycam: I'll look into Issue 24.

ed: I guess both 24 & 25 would be described by a11y

ACTION ed to talk to Rich about issues 24/25 (terminology around title/desc/aria stuff)

<trackbot> Created ACTION-3728 - Talk to rich about issues 24/25 (terminology around title/desc/aria stuff) [on Erik Dahlström - due 2015-02-19].

<shane> tantek: no worries, any time :)

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

ed: structure chapter issue 27
... not sure what it means
... talks about templated elements

heycam: it's kind of true, but maybe templates is not the best way of describing it

ed: I'll figure out a way to describe it
... issue 28
... defining use in terms of web components

krit: I talked with pdr and dmitri
... but I forgot what they said
... maybe Tab when you're back you can talk with pdr and dmitri and figure out how to do it?

TabAtkins: ok

shane: has use changed?

ed: we do refer to web components for event propagation

krit: and web components works a bit differently

shane: my naive understanding of old use is that you couldn't define it in terms of web components

krit: true it's still a special case

Tav: what are the differences?

krit: I think at least because it's isolated

TabAtkins: we've changed how web components work a bit too since this was written

ed: would be nice to get someone to detailed review how to do it with web components

Tav: what's the gain?

TabAtkins: reducing the number of spec concepts
... use is almost a web component, but not exactly, so that's weird

Tav: any change in behaviour?

TabAtkins: maybe minor changes in behaviour which we'd try to minimise

krit: in blink it is implemented in terms of web components

TabAtkins: allt he major behaviours should be preserved

<scribe> ACTION: TabAtkins to talk with pdr and dmitri about how to describe <use> with web components [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action30]

<trackbot> Created ACTION-3729 - Talk with pdr and dmitri about how to describe <use> with web components [on Tab Atkins Jr. - due 2015-02-19].

ed: next, issue 29
... does display prevent shadow trees from being created?

TabAtkins: no
... it'll just prevent layout/rendering
... but shadow tree is a dom concept
... depending on exactly how we define stuff, script will not run in instances?

ed: agree script doesn't run in instances?

heycam: yes

TabAtkins: yes

ed: what about audio elements?

TabAtkins: they should run just fine
... in the <template> based approach, they're inactive in there
... <use> doesn't do that, since you're pointing to an arbitrary element
... but yes once stamped out they will run

ed: issue 33

"How should @media rules work when an external resource is referenced?"

ed: I don't think SVG is clear whether there is a defined viewport when you reference something external
... some CSS things depend on having a window/size

TabAtkins: what's an example?
... the <img> element pointing to something?

ed: no, <use> pointing to something external
... we load the external document in something that's not a frame
... so some style stuff would crash on that
... we should say how that works

roc: I think the logical thing is to treat it as a display none iframe
... I hope that's what we do

<krit> scribeNick: krit

ed: can we resolve on roc's proposal?

krit: does it follow the rules of the dimension of an iframe if there is no intrinsic size or intrinsic ratio

roc: we need to define it

krit: think we should explicitly define a default intrinsic size if there is none

roc: we just need to define something

<scribe> ACTION: ed Define viewport for external document when an element references an element in this document [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action31]

<trackbot> Created ACTION-3730 - Define viewport for external document when an element references an element in this document [on Erik Dahlström - due 2015-02-19].

krit: it does also effect other elements like paint servers that reference external paint servers

ed: we should define it in a special section then. Loading maybe.
... animation in external resources should they run?

roc: we do run animations
... you want a model for external resources that we want to use for images
... images support animations so should external resources with the same rules

BogdanBrinza_: if scripts get images with external resources is that a problem?

roc: an image can not load other resources
... I think there is a strong requirement to do what external images with animations do

RESOLUTION: Animations in external resources should run

ed: next: should switch elements effect if a child element applies?
... you don't can't toggle style with a switch element

RESOLUTION: switch does not effect style

ed: next: does it make sense to implement view CSS and document CSS?
... they should I think

RESOLUTION: ViewCSS should be on window and DocumentCSS on document

TabAtkins: it is already defined on window

ed: we should remove the sentence in SVG

RESOLUTION: Remove ViewCSS and DocumentCSS

ed: next: pixelUnitsToPx/Em....
... they are useless and we should remove them

heycam: agree

RESOLUTION: Remove pixelUnitTo....

ed: next: pauseNaimations and onPauseAnimations do they use WebAnimations
... do they apply to web animations?

birtles: they don't

ed: should we deprecte them?

birtles: they are useful

<scribe> ACTION: birtles pauseNaimations and onPauseAnimations do not effect CSS animations [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action32]

<trackbot> Created ACTION-3731 - Pausenaimations and onpauseanimations do not effect css animations [on Brian Birtles - due 2015-02-19].

ed: next: getElementById
... we should remove it

heycam: agree

RESOLUTION: Remove getElementById on SVGSVGElement

chapter styling

heycam: presentaion attributes on every property we explicitly support?
... they were maybe a bad decision in the first place but it would be confusing if some exist and some don't?

roc: the confusion exists but it is not practical to solve it for every property

heycam: in SVG it is general coding style

krit: I would be careful with adding more presentation attributes

ed: I agree it comes with a cost

heycam: go back to the set of SVG 1.1 then?

krit: we added more already. Like transform-origin

ed: we should do it by case by case basis

heycam: then we should have a list in the spec
... we have a blue table with these attributes

krit: we should update the table with the new presentation attributes like x, y, width and height

heycam: and paint-order
... I will come up with a new set of all properties

<scribe> ACTION: heycam update presentation property table [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action33]

<trackbot> Created ACTION-3732 - Update presentation property table [on Cameron McCormack - due 2015-02-19].

<heycam> https://svgwg.org/svg2-draft/styling.html#UAStyleSheet

heycam: next: UA style sheet (section 5.14)
... this is the overflow hidden thing
... the svg root part should disappear
... same for image

ed: the overflow for pattern is explicitly undefined since SVG 1.1SE

heycam: so we can remove this problem

Tav: if we remove it, you run into visible all the time while now you run into it by accident

heycam: ok, can you apply a clip-path on a pattern? It is kind of a similar thing as applying overflow on the pattern

Tav: can we make the overflow visible to default?

krit: then we can not explicitly allow it in the future with defined behavior. So we should keep hidden

heycam: I agree

RESOLUTION: first rule on UA style: remove svg and image
... remove 2nd rule on UA style since width and height are presentation attributes

<heycam> Scribe: cameron

<heycam> ScribeNick: heycam

roc: style, script, symbol { display: none; }
... you could override that to display:inline?

heycam: what about defs?

roc: related to referring to display:none things
... that's an issue to discuss later
... next is transform-origin
... a non-outermost-<svg> element has transform-origin: top left

<krit> https://www.irccloud.com/pastebin/pnDoiyiy

*:not(svg),

*:not(foreignObject) > svg {

transform-origin: 0 0;

}

roc: it's slightly different from the WebKit rule

krit: for foreignObject you would have to put an html child

roc: you don't have, you could have an <svg> child of <foreignObject>

krit: do we need to define this part?
... we have some more rules too
... we have svg:root { width: 100%; height: 100%; }
... this might be because we have width/height being a presentation attribute
... in Gecko, you can set width/height attributes differently from width/height properties
... or is that not true any more

roc: we don't have width/height reflected into CSS

krit: we do

roc: so for the root element you need to override those so that the root element is displayed across the entire viewport
... ok

<krit> https://www.irccloud.com/pastebin/tpiC8eFU

krit: so this makes inner <svg> overflow:hidden

roc: we also have a rule that is specific to SVG used in a font

http://mcc.id.au/temp/overflow.svg

if you see a quarter circle, then overflow:hidden is set for inner svg

RESOLUTION: svg:not(:root) { overflow: hidden; } goes in the UA style sheet

<scribe> ACTION: Cameron to investigate whether |symbol { overflow: hidden }| UA style sheet rule is needed [recorded in http://www.w3.org/2015/02/11-svg-minutes.html#action34]

<trackbot> Created ACTION-3733 - Investigate whether |symbol { overflow: hidden }| ua style sheet rule is needed [on Cameron McCormack - due 2015-02-19].

trackbot: end telcon

- DRAFT -

SVG Working Group Teleconference

11 Feb 2015

Attendees

Contents

Publication of the Accessibility mapping document

Adding new integer enum values in light of not going ahead with new SVG DOM

Avoiding new camelcase names

Attribute parsing overhaul

What to do with the embedded content chapter

What is going to happen to the SVG DOM

Requiring foreignObject HTML behavior

Requiring style sheet support

Drop xml:base/lang/space attributes

Proposal: drop the SVGPathSeg* interfaces and related methods/attributes

camelcased attributes

Open issues that require discussion

chapter styling

Summary of Action Items

Scribe.perl diagnostic output