minutes, SVG WG Sydney F2F 2015, day 1

http://www.w3.org/2015/02/11-svg-minutes.html



   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

11 Feb 2015

   [2]Agenda

      [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals

   See also: [3]IRC log

      [3] http://www.w3.org/2015/02/11-svg-irc

Attendees

   Present
          Doug_Schepers, +61.2.933.6.aaaa, Rich_Schwerdtfeger

   Regrets
   Chair
          Cameron

   Scribe
          birtles, Cameron

Contents

     * [4]Topics
         1. [5]Publication of the Accessibility mapping document
         2. [6]Adding new integer enum values in light of not
            going ahead with new SVG DOM
         3. [7]Avoiding new camelcase names
         4. [8]Attribute parsing overhaul
         5. [9]What to do with the embedded content chapter
         6. [10]What is going to happen to the SVG DOM
         7. [11]Requiring foreignObject HTML behavior
         8. [12]Requiring style sheet support
         9. [13]Drop xml:base/lang/space attributes
        10. [14]Proposal: drop the SVGPathSeg* interfaces and
            related methods/attributes
        11. [15]camelcased attributes
        12. [16]Open issues that require discussion
        13. [17]chapter styling
     * [18]Summary of Action Items
     __________________________________________________________

   <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>
   [19]http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

     [19] 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

   <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
   [20]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
   [21]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> [22]https://svgwg.org/svg2-draft/types.html#syntax

     [22] 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>
   [23]https://svgwg.org/svg2-draft/shapes.html#DataTypePoints

     [23] 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>
   [24]https://svgwg.org/svg2-draft/text.html#TextElementXAttribut
   e

     [24] 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> [25]https://svgwg.org/svg2-draft/embedded.html

     [25] 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:
   [26]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_
   integration_again

     [26] 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:
   [27]http://www.w3.org/2014/10/31-svg-minutes.html#item09

     [27] 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
   [28]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 [29]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
   [30]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
   [31]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
   [32]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> [33]http://schepers.cc/css-link-hack-in-svg

     [33] 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 [34]http://www.w3.org/2015/02/11-svg-minutes.html#action08]

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

     [35] 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 [36]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
   [37]http://www.w3.org/2015/02/11-svg-minutes.html#action10]

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

     [38] http://www.w3.org/Graphics/SVG/WG/track/users

   <scribe> ACTION: heycam add stylesheet requirements to the spec
   [recorded in
   [39]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> <svg viewBox="0 0 100 100"
   xmlns="[40]http://www.w3.org/2000/svg">

     [40] http://www.w3.org/2000/svg

   <ed> <link xmlns="[41]http://www.w3.org/1999/xhtml"
   rel="stylesheet" type="text/css" href="data:text/css,circle {
   fill:green; }"/>

     [41] http://www.w3.org/1999/xhtml

   <ed> <circle cx="50" cy="50" r="25" fill="red"/>

   <ed> </svg>

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

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

     [42] 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>
   [43]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/dropxmlat
   tributes

     [43] 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>
   [44]https://www.chromestatus.com/metrics/feature/timeline/popul
   arity/580

     [44] 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
   [45]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
   [46]http://www.w3.org/2015/02/11-svg-minutes.html#action13]

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

     [47] 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
   [48]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
   [49]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
   [50]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
   [51]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>
   [52]https://www.chromestatus.com/metrics/feature/timeline/popul
   arity/568

     [52] 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> [53]http://parapara-editor.mozlabs.jp/sandbox

     [53] 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
   [54]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

   [55]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0024.h
   tml

     [55] 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>
   [56]https://svgwg.org/svg2-draft/struct.html#SVGElementPlayback
   OrderAttribute

     [56] 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 [57]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
   [58]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
   [59]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
   [60]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
   [61]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
   [62]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
   [63]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

   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
   [64]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
   [65]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
   [66]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
   [67]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].

   <br dur=15m>

   <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
   [68]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
   [69]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
   [70]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
   [71]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>
   [72]https://svgwg.org/svg2-draft/styling.html#UAStyleSheet

     [72] 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> [73]https://www.irccloud.com/pastebin/pnDoiyiy

  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> [74]https://www.irccloud.com/pastebin/tpiC8eFU

     [74] 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

   [75]http://mcc.id.au/temp/overflow.svg

     [75] 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
   [76]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

Summary of Action Items

   [NEW] ACTION: birtles pauseNaimations and onPauseAnimations do
   not effect CSS animations [recorded in
   [77]http://www.w3.org/2015/02/11-svg-minutes.html#action32]
   [NEW] ACTION: birtles to specify something simple and
   consistent for timeline start in Web Animations. [recorded in
   [78]http://www.w3.org/2015/02/11-svg-minutes.html#action29]
   [NEW] ACTION: Cameron to investigate whether |symbol {
   overflow: hidden }| UA style sheet rule is needed [recorded in
   [79]http://www.w3.org/2015/02/11-svg-minutes.html#action34]
   [NEW] ACTION: Cameron to investigate which HTML elements like
   <link> we might want to also allow in SVG [recorded in
   [80]http://www.w3.org/2015/02/11-svg-minutes.html#action07]
   [NEW] ACTION: Cyril don't stop [recorded in
   [81]http://www.w3.org/2015/02/11-svg-minutes.html#action20]
   [NEW] ACTION: ed Define viewport for external document when an
   element references an element in this document [recorded in
   [82]http://www.w3.org/2015/02/11-svg-minutes.html#action31]
   [NEW] ACTION: ed Map xml:space to whitespace property values in
   CSS3 Text [recorded in
   [83]http://www.w3.org/2015/02/11-svg-minutes.html#action17]
   [NEW] ACTION: ed Remove xml:base/space/lang from the SVG DOM
   interface [recorded in
   [84]http://www.w3.org/2015/02/11-svg-minutes.html#action12]
   [NEW] ACTION: ed Remove xml:lang in favor for HMTL lang
   [recorded in
   [85]http://www.w3.org/2015/02/11-svg-minutes.html#action15]
   [NEW] ACTION: ed to add usage counters to blink to measure
   usage of animVal / baseVal [recorded in
   [86]http://www.w3.org/2015/02/11-svg-minutes.html#action01]
   [NEW] ACTION: ed to measure usage [recorded in
   [87]http://www.w3.org/2015/02/11-svg-minutes.html#action28]
   [NEW] 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
   [88]http://www.w3.org/2015/02/11-svg-minutes.html#action02]
   [NEW] ACTION: ed Write tests and come back to the SVG for
   xml:base [recorded in
   [89]http://www.w3.org/2015/02/11-svg-minutes.html#action16]
   [NEW] ACTION: Erik to do the attribute lowercasing [recorded in
   [90]http://www.w3.org/2015/02/11-svg-minutes.html#action19]
   [NEW] ACTION: Erik to verify that the SVGPathSeg interface use
   counter values are correct and to drop the interfaces if they
   are [recorded in
   [91]http://www.w3.org/2015/02/11-svg-minutes.html#action18]
   [NEW] ACTION: hey cam add stylesheet requirements to the spec
   [recorded in
   [92]http://www.w3.org/2015/02/11-svg-minutes.html#action10]
   [NEW] ACTION: heycam Write tests and come back to the SVG for
   xml:base [recorded in
   [93]http://www.w3.org/2015/02/11-svg-minutes.html#action14]
   [NEW] ACTION: heycam add stylesheet requirements to the spec
   [recorded in
   [94]http://www.w3.org/2015/02/11-svg-minutes.html#action11]
   [NEW] ACTION: heycam Reference integration spec and update
   conformance class for HTML support on foreignObject [recorded
   in [95]http://www.w3.org/2015/02/11-svg-minutes.html#action09]
   [NEW] 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
   [96]http://www.w3.org/2015/02/11-svg-minutes.html#action03]
   [NEW] ACTION: heycam to mark classname as deprecated (issue 4
   in chapter 3) [recorded in
   [97]http://www.w3.org/2015/02/11-svg-minutes.html#action24]
   [NEW] ACTION: heycam to put this in the presentation attribute
   section [recorded in
   [98]http://www.w3.org/2015/02/11-svg-minutes.html#action26]
   [NEW] ACTION: heycam to resolve issue 2 in Chapter 3 [recorded
   in [99]http://www.w3.org/2015/02/11-svg-minutes.html#action23]
   [NEW] ACTION: Heycam to specify that convertToSpecifiedUnits
   should throw an exception if converting to percentage with
   0-sized viewport. [recorded in
   [100]http://www.w3.org/2015/02/11-svg-minutes.html#action25]
   [NEW] ACTION: heycam update presentation property table
   [recorded in
   [101]http://www.w3.org/2015/02/11-svg-minutes.html#action33]
   [NEW] ACTION: krit to do testing around currentScale, CTM,
   transform, viewport, etc. on 'svg' element [recorded in
   [102]http://www.w3.org/2015/02/11-svg-minutes.html#action27]
   [NEW] ACTION: nikos to merge 2.5 into 2.7-2.9 [recorded in
   [103]http://www.w3.org/2015/02/11-svg-minutes.html#action22]
   [NEW] ACTION: nikos to rework chapter 2 and incorporate
   references to external specifications [recorded in
   [104]http://www.w3.org/2015/02/11-svg-minutes.html#action21]
   [NEW] ACTION: Reference integration spec and update conformance
   class for HTML support on foreignObject [recorded in
   [105]http://www.w3.org/2015/02/11-svg-minutes.html#action08]
   [NEW] ACTION: TabAtkins Allow templates in SVG which needs HTML
   parser changes [recorded in
   [106]http://www.w3.org/2015/02/11-svg-minutes.html#action06]
   [NEW] ACTION: TabAtkins convince Hixie to make the HMTL parser
   changes + x/y presentation attributes on the canvas,...
   elements for SVG [recorded in
   [107]http://www.w3.org/2015/02/11-svg-minutes.html#action05]
   [NEW] ACTION: TabAtkins to talk with pdr and dmitri about how
   to describe <use> with web components [recorded in
   [108]http://www.w3.org/2015/02/11-svg-minutes.html#action30]
   [NEW] ACTION: TabAtkins write the SVG layout spec [recorded in
   [109]http://www.w3.org/2015/02/11-svg-minutes.html#action04]
   [NEW] ACTION: Write tests and come back to the SVG for xml:base
   [recorded in
   [110]http://www.w3.org/2015/02/11-svg-minutes.html#action13]

   [End of minutes]

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 12 February 2015 05:35:40 UTC