minutes, Linköping 2015 SVG F2F Day 4

http://www.w3.org/2015/06/12-svg-minutes.html


   [1]W3C

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

                               - DRAFT -

                          Linköping F2F day 4

12 Jun 2015

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2015/06/12-svg-irc

Attendees

   Present
          Rossen, Bogdan, Nikos, Cameron, Frederick, Dirk, Erik,
          Tav, Satoru, Jun

   Regrets
   Chair
          Erik

   Scribe
          Cameron

Contents

     * [4]Topics
         1. [5]Whether writing-mode should have a presentation
            attribute
         2. [6]shadow trees on text content elements and text
            positioning attributes
         3. [7]how textPath works with path seg lists
         4. [8]adding pathLength to textPath
         5. [9]Add x/y/dx/dy to textPath
         6. [10]transform-origin on SVG elements
         7. [11]Impact of CSS Transforms Level 2 on SVG
         8. [12]definitions in Transforms Level 1
         9. [13]SVGTransformList
        10. [14]Coordinates chapter
        11. [15]pAR defer
        12. [16]blending with backdrop of multiple fill/stroke
        13. [17]publishing another WD of SVG 2
        14. [18]F2F planning
        15. [19]Upcoming TPAC meeting
     * [20]Summary of Action Items
     __________________________________________________________

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Whether writing-mode should have a presentation attribute

   heycam: adding a presentation attribute would violate our rule
   of not adding any new presentation attributes

   Tav: I think it should have one

   krit: it shouldn't be a problem implementation wise

   ed: I would prefer having it, for consistency

   heycam: text-orientation is the third one that works together
   with direction and writing-mode

   Tav: add that too then
   ... we treat everything as presentation attribtues anyway

   krit: for us it's a white list so we would need to add these
   things to a list

   heycam: a middle point would be to add presentation attributes
   for all properties that have an effect on SVG elements
   ... but we'd need to go through all properties to decide

   Rossen: I would prefer not having presentation attribute for
   witing-mode
   ... if we have a white list of allowed presentation attributes,
   I'd like that to be defined in an automated way
   ... so that if CSS gains new properties we don't need to update
   the list of presentation attributes
   ... doing one off things seems random, but having all
   properties as presentation attributes seems like overkill

   Tav: we need something in the spec now

   heycam: yes I plan to add a list to the Styling chapter

   <scribe> ACTION: Cameron to present a few different ways of
   defining the list of presentation attributes to support
   [recorded in
   [21]http://www.w3.org/2015/06/12-svg-minutes.html#action01]

   <trackbot> Created ACTION-3806 - Present a few different ways
   of defining the list of presentation attributes to support [on
   Cameron McCormack - due 2015-06-19].

shadow trees on text content elements and text positioning attributes

   heycam: we had a bug filed with something putting x and y
   attributes on a text and a shadow tree on a tspan
   ... do the x and y attributes apply to the shadow tree
   contents?

   ed: was there a test case?

   heycam: can't find the test right now

   ed: don't know how blink would deal with this
   ... you could also put the text positioning attributes on
   shadow tree contents

   heycam: maybe that argues for assigning the x/y to the shadow
   tree characters

   Tav: you do have take the shadow tree contents into account
   when say text-anchor:middle centering
   ... would there be a place where you replace the content?
   ... I guess we just have to define a default behaviour and let
   the user figure it out

   heycam: OK I will make the x/y apply to characters in the
   shadow tree as I write up the text layout algorithm

   <scribe> ACTION: Cameron to attempt to make text positioning
   attributes apply to shadow tree content [recorded in
   [22]http://www.w3.org/2015/06/12-svg-minutes.html#action02]

   <trackbot> Created ACTION-3807 - Attempt to make text
   positioning attributes apply to shadow tree content [on Cameron
   McCormack - due 2015-06-19].

how textPath works with path seg lists

   ed: SVG 2 has added a d attribute to textPath
   ... previously you could only link to a path
   ... and I think the spec currently says that if you have both
   href and d that it picks the d
   ... it's implementing SVGAnimatedPathData now too, which is
   where the pathSegList accessors are
   ... the spec says that if you href to a path, it should be
   exposed through those APIs
   ... and I don't think that's a good idea
   ... if you really want the other path element that defines the
   textPath, you can just go grab that
   ... and use the same methods there
   ... instead of trying to make some magic here
   ... so I think textPath should only return the d attribute and
   nothing else

   heycam: I agree

   nikos: yep

   Tav: sounds good

   RESOLUTION: pathSegList on textPath should only reflect the d
   attribute, not the href'ed path

   <ed>
   [23]https://svgwg.org/svg2-draft/text.html#TextPathElementDAttr
   ibute

     [23] https://svgwg.org/svg2-draft/text.html#TextPathElementDAttribute

   <scribe> ACTION: Erik to make pathSegList on textPath only
   reflect the d attribute, not the href'ed path [recorded in
   [24]http://www.w3.org/2015/06/12-svg-minutes.html#action03]

   <trackbot> Created ACTION-3808 - Make pathseglist on textpath
   only reflect the d attribute, not the href'ed path [on Erik
   Dahlström - due 2015-06-19].

adding pathLength to textPath

   ed: if you link to a path, then that path can have pathLength
   ... not sure if we have other cases where we have d attributes
   and pathLength?

   krit: is it really required to have pathLength on path?

   ed: it's not required, just asking if we should have it
   ... if you want, you can link to a path element, and that works

   krit: yes, if you want it, you can do that
   ... I wouldn't add it

   Tav: if you want to align something exactly you can always
   reference a <path>

   RESOLUTION: We won't add pathLength to <textPath>

Add x/y/dx/dy to textPath

   Tav: if we're not adding the others, no reason to add this

   ed: I thought it was already possible to do this?

   heycam: you can put them on a parent tspan, and it has the
   expected effect, but you can't have them on the textPath

   Tav: you can already do this effect on tspan parent, so just
   leave it at that

   heycam: I agree. let's not try to improve these text
   positioning attributes any more.

   RESOLUTION: We won't add text positioning attributes to
   textPath

transform-origin on SVG elements

   [25]https://lists.w3.org/Archives/Public/www-style/2015Jun/0109
   .html

     [25] https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html

   heycam: that's my proposed spec wording to handle this -- using
   a UA style rule

   krit: so for SVG elements you'll get a default value of 0 0

   heycam: for non-outer-<svg> SVG elements

   krit: WebKit and Blink already use UA style rules to do this
   ... our rules might not be fully correct
   ... the one that Cameron posted should be OK

   Rossen: and leave the initial value as it is?

   heycam: yes

   Rossen: the other way to do this is auto
   ... which is the usual way the CSS WG handles this kind of
   thing

   heycam: I don't mind auto either

   Rossen: we'll discuss this in CSS

Impact of CSS Transforms Level 2 on SVG

   ed: there's some implementation work going on in Blink for this

   krit: the Transforms 2 spec just adds the rotate, translate,
   scale properties and defines how they interact with transform

   ed: right now the spec says that percentages are resolved
   according to the containing block, is that what we want in SVG?

   krit: border box in SVG is complicated
   ... we have the transform-box property which lets you switch
   between bounding box and viewport

   ed: doesn't say anything about that here

   krit: that's in Transforms 1

   ed: whether or not these properties should be made presentation
   attributes, too
   ... rotate would clash with rotate on text

   krit: transform and transform-origin are presentation
   attributes

   heycam: I don't think we support transform-origin as a
   presentation attribute

   krit: but in WebKit/Blink we do
   ... I do not expect any problems with SVG here
   ... it's a good question to ask whether to make these
   presentation attributes

   Tav: if you have transform and rotate? ti's determined what
   happens?

   krit: yes, the order is fixed
   ... rotate is always applied before transform

   heycam: I would say don't add presentation attributes for these
   right now
   ... and otherwise I don't think any other SVG considerations
   apply

definitions in Transforms Level 1

   heycam: I spoke with takagi-san yesterday about this
   ... he has prepared some diffs to the Transforms spec for the
   definitions needed for reference
   ... he has prepared some diffs to the Transforms spec for the
   definitions needed for reference from the non-scaling features
   of SVG
   ... he wanted to know whether they should go in Transforms
   Level 1 or 2

   krit: it should be 2

   heycam: I suggest then to email Tab with the definitions, and a
   reminder of the discussions we had in Sydney, and he can add
   them to that spec
   ... then we can reference them from SVG

   [26]http://svg2.mbsrv.net/devinfo/devstd/CSS_Transforms_Diff/

     [26] http://svg2.mbsrv.net/devinfo/devstd/CSS_Transforms_Diff/

   Tav: there's an issue with preserve-3d in there
   ... suppose you have a box, you rotate the box, the
   vector-effect would make each of those sides the same, you
   flatten it, you can't do anything after that

   krit: there is a term in the spec for applying effects until
   the point that you flatten
   ... vector-effect is not intended for use with 3D transforms

SVGTransformList

   <krit>
   file:///Users/dschulze/Documents/svgwg/build/publish/coords.htm
   l#InterfaceSVGAnimatedTransformList

   krit: I added a bit of normative text to
   SVGAnimatedTransformList

   <krit>
   [27]https://svgwg.org/svg2-draft/coords.html#InterfaceSVGAnimat
   edTransformList

     [27] https://svgwg.org/svg2-draft/coords.html#InterfaceSVGAnimatedTransformList

   krit: we have the transform animVal and baseVal
   ... for the transfom attribute
   ... now that we have the transform property, the question is
   what do you get if you get/set baseVal
   ... what I wrote here is that the SVGTransformList always just
   reflects the attribute
   ... not the style value

   heycam: we discussed this before and that's the behaviour we
   agreed on

   -- fika --

Coordinates chapter

   krit: in this chapter we have some definitions that need
   updates
   ... the first is "canvas", which says there's a physical space
   with a virtual infinite bounds that things can be drawn on
   ... and "SVG canvas" is an instance of "canvas"
   ... but that definition doesn't add any value
   ... the problem here is really "SVG viewport"

   "The viewport within the SVG canvas which defines the
   rectangular region into which SVG content is rendered. See the
   discussion of the SVG viewport in the chapter on Coordinate
   Systems, Transformations and Units."

   scribe: which implies the content is clipped to the bounds
   ... especially if you have overflow visible, that's not the
   case
   ... the question is how do we define "SVG viewport" and what
   does it do
   ... as in CSS, it's something like a containing block, that is
   a reference for sizing some content

   Rossen: can't you define it as a rectangle for clipping if
   overflow is set appropriately

   krit: there's also another definition "initial clip path"

   Rossen: that's pretty much your viewport then

   nikos: what about the rectangular region that maps to the view
   box

   krit: vice versa

   nikos: it's just defining that space

   krit: the change to make across the spec is to only use "SVG
   viewport", not "viewport"
   ... if you define viewport as a boundary, that can be used for
   clipping if overflow:hidden, or gives the boundaries for
   overflow:scroll
   ... it's the rectangle viewBox is mapped to
   ... and it's the box that percentages are resolved against
   ... is that something we can agree on?

   Rossen: does need to be rectangular?

   krit: that's the current definition

   Rossen: currently

   krit: so currently it has to have width/height
   ... so I would define it as a rectangular boundary

   Rossen: at some point we're going to have to deal with round
   displays

   krit: right. that would still, even for round displays, have an
   a width/height extent

   nikos: round with a different coordinate system?

   krit: CSS WG is talking about that, with polar coordinates;
   just for positioning

   nikos: so the polar coordinates just map to a position

   krit: yes, still a cartesian coordinate system
   ... but positions are mapped from polar coordinates
   ... any objection to remove the term "canvas"?

   nikos: there are a lot of areas in the spec where you want to
   say something that you're rendering on to

   Tav: and to make it clear that it extends infinitely

   krit: do we need this reference to physical media and computer
   memory?

   nikos: make it more abstract than that

   krit: the spec generally only references canvas and viewport,
   not SVG canvas and SVG viewport
   ... I think the idea here was to have ad istinction between
   host rendering and SVG rendering, but nowadays that doesn't
   matter

   nikos: wasn't to distinguish from HTML <canvas>?

   heycam: no that was before this text was written

   Rossen: other specs doesn't reference SVG canvas

   krit: the SVG viewport defines initial clipping for overflow
   property
   ... do I need to mention specific values of overflow?

   Rossen: no

   krit: then we have a definition of viewport coordinate system
   and user coordinate system
   ... and that viewport space = viewport coordinate system, and
   user space = user coordinate system
   ... we should just have single terms for these things
   ... the Transforms spec uses "local coordinate system", which
   I'd actually prefer

   ed: is there a difference?

   krit: no

   ed: I'd prefer local too, then

   Tav: the term "user units" is used a lot everywhere
   ... there's a history of using that term, even outside the spec

   krit: would you suggest Erik replacing all user * things with
   local *?

   ed: user sounds custom, local coordinate system sounds pretty
   clear

   nikos: local is generally the term that's used, I think

   krit: can we agree to change?

   nikos: I agree in theory but we do have keywords like
   userSpaceOnUse

   krit: CSS transforms already defines user coordinate system =
   local coordinate system
   ... there is some wording about establishing viewports and the
   "viewport coordinate system"
   ... for me, that's redundant, you map the coordinate system
   between parents and children

   Tav: aren't percentages are in terms of viewport coordinate
   system?
   ... throughout the spec if you say percentages of the viewport,
   you don't need the term "viewport coordinate system"

   krit: my guess is that it wants to distinguish between
   transforms that apply to content, and transforms that apply to
   the host document

   Tav: is that term used anywhere else in the document?

   krit: yes, introduction, painting, coords

   nikos: in the vector-effects section, you could just say nested
   viewports couldn't you

   krit: I'll work something out for that section and propose it
   ... next, the Initial coordinate system
   ... it says there is a viewport coordinate system and a user
   coordinate system and they are initially identical, and origin
   is at the top left
   ... not sure if this should be part of the rendering chapter,
   or to keep it here
   ... these definitions could do with some trimming

   nikos: I think it makes sense to have it there

   krit: I'd still like to reduce the text, it's a bit verbose
   ... and now, the "initial viewport"
   ... we have a few use cases of SVG, as a root document, or
   embedded, or inline, ...
   ... all these scenarios need to be specified somehow
   ... didn't find what viewport units means for a root document
   ... if width/height are auto, we don't have intrinsic
   size/ratio
   ... what's the size of the viewport then. usually it's the size
   of the window, right?
   ... which brings us to the initial of not defining what the
   initial containing block is
   ... vw and vh units need that to resolve against
   ... the containing block is usually the size of the window,
   when you test it
   ... how does CSS define the size of the ICB?

   Rossen: it's defined as the first fragment, whether it's a page
   in a print media, or the size of the window, in a continuous
   media
   ... we can just refer to the same things as CSS
   ... I think it's section 9.5 or something
   ... the initial value of width/height properties are auto,
   which will resolve to 100% of the ICB

   krit: when we have intrinsic ratio, and no sizing, that would
   also resolve against the ICB, yes?

   Rossen: yes

   krit: if you have intrinsic sizing, then the viewport would
   definted by the intrinsic sizing, which is not necessarily the
   same size as the ICB
   ... now, we come to the section about embedding SVG content
   ... the "establishing an ew SVG viewport" section, and
   "intrinsic sizing properties" section, which both try to define
   this but fail
   ... I would keep "establishing a new SVG viewport', which just
   says which elements do that
   ... "initial viewport" should reference an algorithm we define
   in the "intrinsic sizing properties" section
   ... plus of course everything for the root SVG, in case of not
   being hosted in a document

   ed: because it's duplicated information?

   krit: at the moment, embedded content is defined in multiple
   places
   ... I just want to put all the sizing information in the one
   place
   ... now, for embedding
   ... we had the presentation from David Vest in Leipzig
   ... which I won't go through now
   ... it's pretty simple generally
   ... you always have the containing block, which defines the
   sizing (or not) depending on the value of width/height on the
   root

   [shows some examples]

   krit: if you have an intrisic ratio, but no width/height, what
   should happen?
   ... it falls back to the replaced element algorithm?

   Tav: can you work offline with Rossen on this?

   krit: sure

pAR defer

   [28]http://mcc.id.au/temp/defer.svg

     [28] http://mcc.id.au/temp/defer.svg

   heycam: so in Edge, defer is not supported, in Firefox it is,
   in Blink the effect is basically "always defer"
   ... i.e. pAR on <image> is ignored when referencing an SVG
   image

   krit: if you have an image with pAR on it, Blink and WebKit
   would follow it, but not the overriding one on the <image>

   ed: I think defer is kind of useless

   krit: I think the whole negotiation process is useless

   ed: defer is ignored in all pARs other than on <image>

   <ed>
   [29]https://svgwg.org/svg2-draft/coords.html#PreserveAspectRati
   oAttribute

     [29] https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute

   heycam: removing defer altogether, and making it a parse error,
   is probably safe

   ed: I agree

   krit: I don't care, removing it or not

   ed: the bug fixes that would be needed are unrelated to defer

   RESOLUTION: We will refer the defer keyword from pAR;
   encountering it would be a parse error.

   <scribe> ACTION: Cameron to remove pAR's defer keyword.
   [recorded in
   [30]http://www.w3.org/2015/06/12-svg-minutes.html#action04]

   <trackbot> Created ACTION-3809 - Remove par's defer keyword.
   [on Cameron McCormack - due 2015-06-19].

blending with backdrop of multiple fill/stroke

   krit: I looked at what photoshop, illustrator, and some other
   tools are doing
   ... they support multiple fills and strokes, they will be drawn
   on top of each other
   ... can also support a blend mode
   ... but they also blend with the backdrop
   ... where we said we would isolate them
   ... so I would suggest that we remove this isolation
   requirement

   Tav: how does that work?
   ... render the second blended with the backdrop that already
   has the first fill blended into it?
   ... and if you isolate it?

   nikos: then you only blend among the fills
   ... if you specify opacity on the shape at all, it will become
   isolated

   krit: yes normal isolation requirements apply

   nikos: is there a way to control the isolation within the
   fills?

   krit: no

   <krit> Rossen:
   [31]http://dev.w3.org/fxtf/compositing-1/#csscompositingrules_C
   SS

     [31] http://dev.w3.org/fxtf/compositing-1/#csscompositingrules_CSS

   RESOLUTION: Multiple fills and strokes are not isolated; they
   are all blended with the backdrop

   <scribe> ACTION: Dirk to update the Painting chapter about
   multiple fills/strokes not isolating [recorded in
   [32]http://www.w3.org/2015/06/12-svg-minutes.html#action05]

   <trackbot> Created ACTION-3810 - Update the painting chapter
   about multiple fills/strokes not isolating [on Dirk Schulze -
   due 2015-06-19].

publishing another WD of SVG 2

   heycam: let's publish another WD after this week of edits

   all: ok

   RESOLUTION: Publish a new WD of SVG 2 next week

   <scribe> ACTION: Cameron to organise another SVG 2 WD
   publication [recorded in
   [33]http://www.w3.org/2015/06/12-svg-minutes.html#action06]

   <trackbot> Created ACTION-3811 - Organise another svg 2 wd
   publication [on Cameron McCormack - due 2015-06-19].

F2F planning

   ed: Google are hosting CSS in Sydney
   ... they asked us whether we would like to meet there too

   Rossen: there will most likely be a Houdini meeting next to it
   ... the feedback from the CSS WG that's worth pulling forward
   is that there were a number of members found travelling to
   Australia expensive
   ... especially those travelling on smaller (or their own)
   budget
   ... that was the one pushback
   ... Shane as one of the organizers put a number of hotels in
   the planning wiki
   ... it's worth looking and booking in advance, especially for
   hotels

   nikos: we were thinking that if you were coming to Sydney, we'd
   (Canon) would offer too
   ... but Shane got in first
   ... I don't know how convenient that would be if people are
   already going to Google
   ... our office which is a 20 minutes train ride out of the city

   Rossen: unless Google has a problem to host this for the extra
   couple of SVG days, I don't see why we'd change location
   ... it's very nice of you to offer
   ... but since they have offered, and we are already there

   krit: are the dates fixed already?

   Rossen: we at least resolved on the week

   <Rossen> [34]https://wiki.csswg.org/planning/sydney-2016

     [34] https://wiki.csswg.org/planning/sydney-2016

   Feb 1-5

   heycam: so SVG would be just before or after the weekend around
   that

   Rossen: would prefer to meet on the weekend, to avoid extending
   the trip further

   so either Jan 30-31, or Feb 6-7

   depend on which end of the week houdini is meeting

   Tav: would prefer a third SVG meeting day
   ... to make it worthwhile coming

   RESOLUTION: Tentative resolution that we meet for 3 days either
   right before or right after the CSS/Houdini meetings in Sydney

Upcoming TPAC meeting

   ed: unless I have some funding I probably won't come

   Tav: I'm definitely not going
   ... as it'd only be a day and a half of SVG, based on prior
   experience, everyone's tired by the end of Friday

   <shane> Houdini Jan 30-31 I think.

   heycam: I probably can't come now

   krit: I won't be there

   Rossen: so without the chairs, and half of the regulars not
   there

   ed: do we want to have a meeting somewhere/somewhen else?

   Tav: another option could be Paris, after CSS

   Rossen: for me that's a hard no
   ... I've got CSS, Houdini, then vacation
   ... which is already planned
   ... this time CSS is meeting Tue-Thu, not sure why that is,
   then Houdini is Fri/Sat

   <Rossen> [35]https://wiki.csswg.org/planning

     [35] https://wiki.csswg.org/planning

   Rossen: so Aug 25-27, followed by Houdini 28-29

   krit: I will be at both of those
   ... I could attend an SVG meeting before then
   ... first, the Australians/Japanese, would you be able to
   attend?

   stakagi_: for me no problem

   ed: could also do Pittsburgh? though there would be more people
   in Paris.

   nikos: I couldn't get there before 25th

   krit: I couldn't go to Pittsburgh, as I have to fly to the US
   two weeks later

   Rossen: we could organise something in Seattle?

   krit: my trip might not be flexible
   ... so in Paris would be Aug 22-24?

   ed: I'm booked that weekend

   krit: we could just have a spec hacking session

   heycam: so right after Houdini seems like the dates best for
   most people, except Rossen

   Rossen: so that would be Aug 31 - Sep 2

   RESOLUTION: We cancel the TPAC 2015 SVG meeting.
   ... We will tentatively try to meet in Paris after CSS/Houdini
   in Aug/Sep.

   -- lunch --

   RRSAgent: remind me in 4 hours to do something

   <BogdanBrinza> To test IE11 on Mac/Linux go to
   [36]http://dev.modern.ie/ and then Tools > RemoteIE

     [36] http://dev.modern.ie/

   <krit> BogdanBrinza: it is just so much easier to ask you to
   check it :P

   <krit> heycam: Does FF nightly use the UA style sheet rule for
   transform-origin currently?

   <krit> found it

   <krit> : svg.css:57;

   <krit> : :not(svg)0px 0px 0px;

   <shepazu> ACTION: Amelia to look at SVG spec for references to
   <use> element, to make sure there is no confusion about
   implementation/accessibility. [recorded in
   [37]http://www.w3.org/2015/06/12-svg-minutes.html#action07]

   <trackbot> Created ACTION-3812 - Look at svg spec for
   references to <use> element, to make sure there is no confusion
   about implementation/accessibility. [on Amelia Bellamy-Royds -
   due 2015-06-19].

   <ed> [38]https://github.com/w3c/svgwg/issues/18

     [38] https://github.com/w3c/svgwg/issues/18

   <ed> [39]https://github.com/w3c/svgwg/issues/20

     [39] https://github.com/w3c/svgwg/issues/20

   <ed> ^ would like these two resolved

   <ed> [40]https://github.com/w3c/svgwg/graphs/commit-activity

     [40] https://github.com/w3c/svgwg/graphs/commit-activity

   <Rossen>
   [41]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess
   ment#Embedded_Content_.28Bogdan.29_.5Breadiness_4.5D

     [41] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Embedded_Content_.28Bogdan.29_.5Breadiness_4.5D

   <Rossen>
   [42]https://github.com/w3c/svgwg/graphs/commit-activity

     [42] https://github.com/w3c/svgwg/graphs/commit-activity

   <nikos> Trackbot, ACTION-3724?

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

   <trackbot>
   [43]http://www.w3.org/Graphics/SVG/WG/track/actions/3724

     [43] http://www.w3.org/Graphics/SVG/WG/track/actions/3724

   RRSAgent: make logs public

   RRSAgent: make minutes

   <scribe> Chair: Erik

   RRSAgent: make minutes

Summary of Action Items

   [NEW] ACTION: Amelia to look at SVG spec for references to
   <use> element, to make sure there is no confusion about
   implementation/accessibility. [recorded in
   [44]http://www.w3.org/2015/06/12-svg-minutes.html#action07]
   [NEW] ACTION: Cameron to attempt to make text positioning
   attributes apply to shadow tree content [recorded in
   [45]http://www.w3.org/2015/06/12-svg-minutes.html#action02]
   [NEW] ACTION: Cameron to organise another SVG 2 WD publication
   [recorded in
   [46]http://www.w3.org/2015/06/12-svg-minutes.html#action06]
   [NEW] ACTION: Cameron to present a few different ways of
   defining the list of presentation attributes to support
   [recorded in
   [47]http://www.w3.org/2015/06/12-svg-minutes.html#action01]
   [NEW] ACTION: Cameron to remove pAR's defer keyword. [recorded
   in [48]http://www.w3.org/2015/06/12-svg-minutes.html#action04]
   [NEW] ACTION: Dirk to update the Painting chapter about
   multiple fills/strokes not isolating [recorded in
   [49]http://www.w3.org/2015/06/12-svg-minutes.html#action05]
   [NEW] ACTION: Erik to make pathSegList on textPath only reflect
   the d attribute, not the href'ed path [recorded in
   [50]http://www.w3.org/2015/06/12-svg-minutes.html#action03]

   [End of minutes]
     __________________________________________________________

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

Received on Friday, 12 June 2015 15:20:31 UTC