W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2014

minutes, SVG WG Leipzig F2F 2014 minutes, day 2

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 8 Apr 2014 15:46:06 +0000
To: SVG public list <www-svg@w3.org>, SVG WG <public-svg-wg@w3.org>
Message-ID: <98BCA6BF-C255-40C3-ACCF-DAF4243C47D9@adobe.com>
Here are the minutes of the SVG WG F2F meeting for the second day in Leipzig.

http://www.w3.org/2014/04/08-svg-minutes.html

Greetings,
Dirk

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

08 Apr 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/04/08-svg-irc

Attendees

   Present
   Regrets
   Chair
          ed

   Scribe
          krit, birtles, nikos, ed

Contents

     * [3]Topics
         1. [4]buffered-rendering and will-change
         2. [5]buffered-rendering
         3. [6]z-index
         4. [7]making width/height presentation attributes on
            foreignObject
         5. [8]Resolving concerns with marker-segment and
            marker-pattern
         6. [9]Removing marker knockouts
         7. [10]'stroke-dashcorner' and 'stroke-dashadjust'
         8. [11]stroke bounding box
         9. [12]Canvas Path2D update
        10. [13]F2F
        11. [14]version number
        12. [15]Symbol with refX/refY
        13. [16]svg implementation status
     * [17]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 08 April 2014

   <krit> ScribeNick: krit

   heycam: [presentation about his proposal for new SVG DOM]
   ... ...want to improve SVG DOM... secuirty bugs in old DMO
   ... no one likes it
   ... new features are harder to add... especially looking
   forward to a new API

   <nikos> [18]http://dev.w3.org/SVG/proposals/improving-svg-dom/

     [18] http://dev.w3.org/SVG/proposals/improving-svg-dom/

   heycam: should a new API be consistent with SVG DOM or HTML?
   ... that is why I thought about new API
   ... more HTML like API without breaking content
   ... but didn't really work out
   ... eg SVGAnimatedLength stuff
   ... svg.width = something would be great
   ... but there is no way we can still keep the SVGAnimated
   object on there
   ... and have numbers as argument at the same time
   ... from there I though if we need to want a new DOM... the
   authors should have a way to use the new API and have a
   fallback for the old API
   ... to opt in to new SVG DOM should be known at element
   creatiion
   ... NS would be a way to indicate new elements
   ... SVG NS would get old API
   ... no NS (HTML NS) will get new API
   ... you can create elements without NS suffix
   ... that puts element sin the HTML NS by default
   ... null NS allows elements in XML NS
   ... I hope that the fact that there are 2 API versions of an
   element is not too big of a problem to implementations
   ... we don't want to have inline SVG stuff to get suddenly a
   new API
   ... we need to tag them differently
   ... so that old content doesn't end up with new API while the
   JS code still addresses the old API.
   ... the tricky part is the img element
   ... "image" creates the <img> element, not <image>

   krit: what about createElement("image")

   heycam: hm, need to think about it
   ... while <image> in HTML actually creates <img>,
   creareElement("image") might not
   ... [does checking and confirms]

   krit: what about innerHTML = "<image>"?

   heycam: maybe we need another flag

   ed: authors might not want to have 2 different image elements

   heycam: probably
   ... haven;t looked into the APIs
   ... so not sure if the images are compatible

   krit: both elements would need the attributes of the other

   heycam: the proposal rests on having two APIs where one gets
   dropped over time
   ... don't think it is possible to drop SVG API completely

   pdr: what about having both APIs on the same element

   heycam: that is how I started
   ... element.x = .... [see problem above]
   ... for inline SVG we would need a new root <graphics> to get
   the new API
   ... this would create a new viewport
   ... all attributes need to be lowercase
   ... same for elements
   ... maybe even do dashed limitingConeAngle ->
   limiting-cone-angle
   ... some element need to be unified like script, style, a
   ... still needs to be defined what happens when you mix SVG and
   HTML-SVG elements
   ... [explains some API specific things that do not allow to
   simply combine old and new SVG DOM]
   ... [all in his document]

   ed: you can not check equality of SVGAnimated objects in Blink
   anymore

   pdr: we broke that intently

   <ed> rect.x === rect.x will return false in blink

   krit: some one from Google said that on the mailing list
   www-svg

   birtles: yes, and bz was clearly against that
   ... we can not do it

   pdr: we made it and it makes the implementation much simpler

   heycam: going HTML allows us to avoid duplication from many
   things that didn't move up to Element
   ... like tabIndex
   ... all SVGAnimated* types get basic types like SVGBoolean to
   boolean SVGString to DOMString
   ... int -> long
   ... [explaining different lists in his proposal]

   ed: did you measure SVG DOM usage? particularly the pathSeg DOM

   heycam: I plan to do it

   pdr: we coudldn't in Blink. We wanted to do the measuring
   ... why do you keep normalized paths around? IIRC just Presto
   ever implemented normalized path with synchronization?

   heycam: yeah, we might get rid of it.

   pdr: not sure why we need normalized paths at all
   ... canvas doesn't have it

   krit: canvas paths are not that difficult as SVG paths

   heycam: [goes on with aspectratio]
   ... if there is a need for preserveAspcetRatio that can not be
   solved with CSS we may need to keep it but as string instead of
   enum

   <birtles> ScribeNick: birtles

   pdr: I like this proposal

   heycam: One of my concerns is the duplication of code and the
   burden it would be
   ... I hope it wouldn't be too much
   ... same functionality but a different API

   pdr: yes, that is a concern
   ... what about making SVG2 be a clean break altogether?
   ... why not remove backwards compatibility altogether when you
   have <graphics> as top-level?

   krit: that would lead to two implementations

   pdr: but in the future we would hope to remove the old
   implementation

   heycam: I think this proposal does that

   pdr: this maintains features like SMIL for example

   krit: in general I like this idea of SVG inheriting from
   HTMLElement
   ... I think this is worthwhile but I see the problems with
   <image> and <script> and moving elements around
   ... what I would propose therefore is, we have a resolution to
   move more attributes to presentation attributes
   ... having that, many of the features of the SVG DOM are not
   necessary therefore
   ... if you have a look at Tab's proposal for a CSSOM

   [19]http://www.xanthir.com/b4UD0

     [19] http://www.xanthir.com/b4UD0

   scribe: this defines a new object model
   ... when we go ahead with this, the CSSOM, to then come up with
   another SVG API is not the way to go
   ... we should focus on this API which affects all elements, not
   just SVG
   ... at some point this proposal will go ahead, perhaps with
   some changes

   heycam: I agree that it wouldn't be good if we had two ways of
   assigning length properties
   ... I would be hopeful that the CSSOM stuff--which is still a
   few years away since it requires Javascript features that we
   don't have yet
   ... specifically value objects don't exist yet
   ... so it will be a while before this is possible
   ... so I think we should make sure the SVG2 DOM can use these
   value objects when they are available

   krit: the mapping right.
   ... so we want to deprecate the SVG DOM at some point anyway so
   we should focus on the HTML DOM stuff

   heycam: looking at a concrete example
   ... if we have rectElement.x = "10px"; (with my proposal)
   ... and you can also do rectElement.x + 20
   ... if we were to support value objects then we would also
   allow rectElement.x = 10px

   krit: I think we don't actually want that but just want strings
   ... I think that's a problem with Tab's proposal
   ... so I don't think you can just use 10px, I think you'd pass
   it "10px"

   heycam: what part of the CSSOM API do you want to use then?
   ... are you saying that you should just be able to do
   rectElement.style.x = "10px"
   ... if we didn't promote all these attributes to properties, is
   there still something from the CSSOM we could use to represent
   this?
   ... e.g. rectElement.x = CSS.px(10)

   krit: we should work together with the CSSWG in the FXTF to
   come up with an API for everything not just SVG
   ... it seems strange to come up with all these IDLs that are
   SVG specific

   birtles: isn't the same for HTML elements e.g.
   HTMLImageElement.src

   krit: I want to limit the number of IDLs we have

   heycam: why?

   krit: why do you want to flood the platform with IDLs

   heycam: are you worried about introducing new globals?

   krit: just in general

   heycam: surely you want rectElement.x?

   krit: I don't think rect.x vs rect.style.x is a big deal
   ... it's strange to me that you have rect.width but
   div.style.width
   ... why not have the same API for both?

   heycam: but in HTML you have inputElement.value not
   inputElement.style.value?

   krit: yes, you cannot promote all attributes to style
   properties but we should promote the ones we can
   ... ones like width etc. can be promoted

   heycam: I was never 100% comfortable with what we had

   krit: why?

   heycam: the fact that all of the proposals had downsides with
   them
   ... either we had to introduce new properties names that match
   CSS but not the attribute names
   ... or we add properties named 'x' etc. that are very generic
   and only apply to SVG elements

   krit: a lot of properties can be applied to all elements even
   though they don't make sense

   pdr: krit, your point seems to be a nice-to-have
   ... holding up the proposal on the CSSOM is dangerous

   krit: yes, especially since the current CSSOM is not
   implemented in that manner

   pdr: I think tying this to CSSOM seems more risky

   krit: if we want to look at real examples, the SVG DOM is
   already rarely used
   ... so why introduce something that people might or might not
   use
   ... why work on something we're going to deprecate?

   heycam: but one reason no-one uses it today is that it's so
   hard to use
   ... if you can do rectelement.x people might actually use it

   davve: what about all the SVG tutorials on the Web that
   document the old DOM?
   ... it's really hard to change that

   heycam: if we can rely on measurements for when we can drop the
   old stuff
   ... the existence of of tutorials might lengthen the time it
   takes but as long as we can measure them, we can know when to
   drop them
   ... Alex Russell said, why not tie new features to the new DOM
   as a kind of carrot to move people over

   krit: I just think we can avoid this burden but not introducing
   a new API

   pdr: if we're already introducing a new top-level element,
   downplaying the fact that it's SVG at all, that it's <graphics>
   in HTML
   ... might help people avoid old SVG tutorials

   ed: if we do that we should change the SVG MIME type
   ... that way you could copy content from an HTML document and
   put it in a standalone document it would still work (without
   the change in MIME type the parsing differences would break it)

   heycam: a new MIME type / media type is an additional barrier
   to get things happenning
   ... since it requires new server configurations etc. and people
   can never get that right
   ... I'm not sure how much advantage there is to renaming the
   whole language to help with the mindset of "this is something
   new"
   ... I think it will be easier to convince implementors to get
   on board if it's not something completely new

   birtles: from authoring point of view I think it's nice if you
   can opt into the new DOM but just changing the name of the
   top-level element

   heycam: that won't work for standalone XML documents (due to
   attribute case sensitivity) but it will for HTML

   krit: don't underestimate the point of authoring tools, not
   only Illustrator and Inkscape, but other tools export SVG

   pdr: fair enough, I think a drastic overhaul is probably
   difficult

   krit: there are a lot of non-graphical technical products that
   export SVG
   ... but there are no tools that support SVG animations and SVG
   DOM so we could get rid of those
   ... for the same reasons I don't see tools using the new SVG
   DOM
   ... I don't think people will make use of the power of the new
   API

   heycam: I'm guessing differently that the simplicity of the new
   API will encourage people to use it
   ... do people want to script SVG at all? I think yes, they do
   ... and if they do, then I think they will want to use this

   krit: but I think people use libraries to do the scripting and
   those libraries can use the existing SVG DOM

   birtles:

   nikos: if you do this, maybe people won't feel the need to use
   libraries

   ed: I think most people will use libraries anyway

   krit: and you'll never get it right for everyone

   heycam: Tav, what do you think about the markup changes?

   krit: I think Inkscape doesn't need to care about the markup
   changes too much--just the top-level document and attribute
   case sensitivity
   ... I think the proposal needs to be more downward compatible
   with regards to case sensitivity

   heycam: if we have to change the root-level element anyway then
   browsers that don't support it won't render it at all anyway

   ed: but it will still render the text inside

   heycam: yes it will

   krit: I'm not convinced that there is enough need for this to
   justify defining a new API

   heycam: are you saying that authors should use
   setAttribute/getAttribute to access these things?

   krit: I think in the future they can use CSSOM, who knows,
   maybe people won't use that either since they're so used to
   .style.x = DOMString

   <ed> (15min break)

   <heycam> old and new API:
   [20]https://pastebin.mozilla.org/4776291

     [20] https://pastebin.mozilla.org/4776291

   <heycam> for setting transform

   <nikos> scribenick: nikos

   heycam: Ideal outcome for me is go ahead and do my proposal
   ... outcome I really want is whether we are going to do
   something like this and I should continue work or not

   pdr: CSSOM will happen
   ... Dirk's point about this change not benefiting users so
   much, getting behind CSSOM would benefit users more

   krit: I think your proposal is very sane for CSS as well as SVG
   ... I think it would be good if we could base CSSOM definition
   on it

   heycam: Dirk's future relies on promoting properties to
   presentation attributes
   ... it seems like support for that is waning

   ed: we have a topic later on about width and height as
   presentation attributes

   heycam: one thing is, I think now is the best time to do
   something about this
   ... if we wait too much longer then our opportunity will be
   missed
   ... which is why I'd like to know now whether to push forward
   on it
   ... if we assume that we promote a bunch of things, you might
   be right that .style.something might be the preferred way of
   interacting
   ... but the simplicity of .x is alluring to me

   pdr: why can't we do that as well? .x is great

   heycam: don't think DIrk wants to
   ... if we have .style we shouldn't have .x

   krit: the biggest issue is that you cannot easily compare
   right?

   heycam: yes

   krit: can you do .x = 3 + 4 or += something?

   heycam: you can make it work using a valueOf method

   krit: it would create an object first?

   heycam: this is if it is an object already

   krit: === doesn't work for blink right?

   pdr: we broke it yes

   krit: chrome or developer channel?

   ed: dev channel for sure, not sure about chrome

   krit: that was the biggest issue with your proposal

   heycam: it violates javascript semantics so not possible
   anywhere

   krit: can we upgrade property to also support taking a dom
   string?

   heycam: limitations are: you can't do equality checking. equals
   and not don't work
   ... I don't think that's acceptable as it will confuse people
   ... is your view Dirk, that if we don't need a new API for .x
   then we don't have the problem of reconciling with the old API
   ... so therefore we don't need the proposal because you don't
   need to opt in to the new DOM
   ... if we do the namespace thing without hooking in a new API
   we have lost the opportunity
   ... I guess I disagree about the importance of the string
   accessors?

   pdr: is the reason people don't use this today that it's hard
   to find?

   heycam: I think so but it's hard to prove

   pdr: I use get and setAttribute because I don't want to have to
   remember the other methods

   krit: we are stuck in this situation where each of us wants a
   part of the proposal

   ed: what do we agree on?

   pdr: everyone agrees on namespace bit? inheriting from HTML.

   heycam: you may have to do the root element name change for
   that

   pdr: we looked at doing a parser change
   ... it broke things
   ... we tried parsing svg with the html parser and there were a
   few things that didn't work

   heycam: I was just talking about whether its necessary to
   rename the root element not whether we use a different parser
   for stand alone docs

   pdr: so you can parse a stand alone document with the xml
   parser in the html namespace

   heycam: yes
   ... the bits that Dirk doesn't want to do are the things that I
   think we only have the opportunity to do now
   ... I don't what information is going to help us make the
   decisions?
   ... will anyone use the new APIs?

   pdr: I think only a small number will
   ... the number of handwritten svg files is small
   ... think that d3 etc are mostly what is used but don't know
   how to prove that

   birtles: is one thing to do the namespace change but add .x and
   .y later?

   heycam: why would people use the new things if there's no extra
   functionality available?
   ... Dirk you were asking if we can do a survey?

   krit: don't think it would be that reliable

   heycam: I'm not sure how to move forward

   ed: you want the whole thing and not just small parts that we
   can agree on?

   heycam: we might not be able to add parts later
   ... I'm not convinced that .style.something is preferred to
   .something
   ... I think I would prefer .something

   pdr: I agree but don't know why an alias wouldn't work there

   birtles: would that be forwards compatible with CSSOM?

   krit: needs approval from CSS WG but they don't know what the
   CSSOM is going to look like

   <heycam> if we made elt.x just forward on to elt.style.x, then
   I think we would want to restrict elt.x to be a string

   <heycam> and not (float or DOMString)

   <heycam> since we don't really know how other types are going
   to be handled on elt.style.x

   heycam: what individual bits does everyone agree on?

   ed: inheriting from HTML element and namespace sounds fine to
   me

   pdr: dropping crazy path API

   birtles: I generally like the graphics element

   heycam: I feel like the graphics element is a necessary evil
   for the opt in api

   krit: graphics can mean a lot of things and in the future you
   may not just have canvas or svg

   heycam: do people think it's useful to get feedback from users
   via svg developers list?

   pdr: don't think it will be accurate enough

   krit: you'll only get participation from those who want the API

   heycam: how can we decide on whether the new API stuff should
   be in there?
   ... what info do we need

   pdr: how do we prove more people will use it?

   heycam: tie in new features to the new DOM only
   ... although that doesn't mean they will have to use .x. could
   still use setAttribute

   ed: using the version attribute for switching makes sense for
   authoring tools

   heycam: don't think you can change the API based on the
   attribute
   ... when you do createElement the attribute isn't present yet

   ed: you couldn't change the namespace based on version
   attribute but you could select the API

   heycam: I don't want to have to check in every method

   pdr: write a polyfill. If usage gets high enough then switch

   krit: web animations provides a polyfill and no one uses it

   birtles: we have a few people using it. Have had good feedback

   pdr: polyfill used for shadow DOM is getting usage

   birtles: I agree that polyfill isn't enough of a measure

   nikos: might not be time to take the measurements with a
   polyfill without missing the opportunity to make the change

   ed: what about if we provide a javascript compat library?

   krit: how would they include the script?
   ... it's an interesting idea

   pdr: we've thrown around the idea of implementing svg with
   javascript
   ... rendering would come from backing objects
   ... it would be faster

   heycam: I like the idea in general of writing a polyfill for
   the new DOM API
   ... probably wouldn't give us the information needed to decide
   if we go on with the changes
   ... I can write the polyfill

   pdr: could be useful for pointing the CSSOM people in the right
   direction
   ... but it seems like a lot of work

   heycam: might not be too much work
   ... not sure how to do the namespace stuff. It's just about the
   API
   ... including the script opts in

   pdr: could use custom elements
   ... but couldn't be a root element
   ... since script exists in both namespaces maybe you could

   ed: so outcome is to write a polyfill?

   heycam: I guess so

   pdr: other outcome was the four things we agreed on

   heycam: in terms of moving forward, I still feel gated by
   deciding on what to do with the DOM
   ... if we're undecided we are basically making the decision not
   to go forward because the opportunity is limited

   birtles: we can introduce new API later easily enough. Say .x
   but only if we drop the old implementation

   heycam: so we know the things we agree on. I can write a
   polyfill for the DOM so we can get a feel. But I don't know how
   much that will help us decide whether to push forward. What's
   going to help us make that decision?
   ... the default decision is to not do it

   krit: why not write the polyfill then we make a decision at the
   next F2F

   <scribe> ACTION: Cameron to write polyfill for his DOM proposal
   before next F2F (with enough time for WG to experiment)
   [recorded in
   [21]http://www.w3.org/2014/04/08-svg-minutes.html#action01]

   <trackbot> Created ACTION-3611 - Write polyfill for his dom
   proposal before next f2f (with enough time for wg to
   experiment) [on Cameron McCormack - due 2014-04-15].

buffered-rendering and will-change

   <ed>
   [22]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/buffered_
   rendering_expansion

     [22] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/buffered_rendering_expansion

buffered-rendering

   birtles: at TPAC we discussed buffered-rendering and having an
   extra value for buffered-rendering
   ... I think the idea was that the author can control whether
   content should be re-rasterised as it's being transformed
   ... in any case, that was before will-change had been discussed
   ... and it's my understanding that will-change covers most of
   those use cases
   ... so if you're going to zoom or pan around then you set
   will-change=transform before doing so to tell the user agent to
   render once

   heycam: but it's only a hint?

   birtles: yes. buffered-rendering was too
   ... I think perhaps we don't need buffered-rendering after all.
   will-change is probably enough
   ... Takagi-san prepared some performance test cases

   <stakagi> [23]http://svg2.mbsrv.net/devinfo/devstd/panZoom/

     [23] http://svg2.mbsrv.net/devinfo/devstd/panZoom/

   birtles: there are some notes about the performance observed in
   each case
   ... one thing to note is that for the panning case, FF recently
   got faster
   ... it's my view that many of these cases can be optimised in
   the browser without extra hints
   ... some will-change would help

   heycam: will-change is good for the first few frames before
   heuristics kick in

   birtles: I spoke to Takagi-san before about different use cases
   and we wonder are there use cases where you really do prefer a
   crisp rendering over smooth performance?
   ... I wonder if we always want smooth performance

   pdr: there's memory concerns with buffered-rendering and
   will-change
   ... I can imagine there are cases where you don't want to use
   the memory

   heycam: I'm assuming heuristics in the browser will ensure you
   don't eat up all the memory

   birtles: it's a hint so the browser can ignore

   pdr: it can be jarring if you optimise for speed while
   transforming then switch to pixel perfect. Have had user
   complaints

   birtles: there is a proposal. This is prior to will-change but
   has updated
   ... the proposal was to add an additional keyword to
   buffered-rendering
   ... currently we're wondering if it's needed or if will-change
   is sufficient
   ... I would further propose that we don't need
   buffered-rendering at all in SVG

   heycam: if there's a use case for preferring dropping frames
   over smooth transitions then it could be useful

   pdr: does any browser other than Chrome implement
   buffered-rendering?

   ed: Presto did
   ... was for set top boxes that have low spec hardware. Was
   successful but was in environments where content was controlled

   heycam: I would be tempted to wait until there are stronger
   requests for the dynamic one, and if we're happy that
   will-change fulfills the smooth transition use case then stick
   with that

   birtles: I think that's fine. Takagi-san was pointing out there
   are some parallels with the SVG integration spec
   ... where we had different modes
   ... if we were to keep buffered-rendering there would be some
   alignment that would be possible
   ... could use a different strategy for buffering depending on
   the content mode
   ... but if we don't have buffered-rendering then it doesn't
   matter

   heycam: you might be able to detect a lot of that automatically
   in the implementation
   ... pdr said before he implemented buffered-rendering on Blink
   specifically for the image element

   ed: does will-change make a difference on SVG content now?

   pdr: I'd be supportive of changing buffered-rendering to
   will-change

   RESOLUTION: will drop buffered-rendering in favour of
   will-change

   krit: will-change is not purely a hint

   heycam: if you say will-change=transform you have to create a
   stacking context

   Lunch break

   <ed> ACTION: brian to replace buffered-rendering with
   will-change in svg2 [recorded in
   [24]http://www.w3.org/2014/04/08-svg-minutes.html#action02]

   <trackbot> Created ACTION-3612 - Replace buffered-rendering
   with will-change in svg2 [on Brian Birtles - due 2014-04-15].

z-index

   heycam: I was talking to jwatt recently and he was saying it
   would be good if z-index made it into the spec so that we could
   make use of all the refactoring that was done to allow z-index
   to work
   ... is anyone planning on doing the work to put it in the spec?
   ... if not perhaps I can

   pdr: is there any relation to will-change?

   heycam: in the sense that they are both related to stacking
   contexts
   ... we already have lots of things in SVG 2 that will create
   stacking contexts
   ... blending, transforms, masking, etc

   davve: what's the relation of css stacking contexts to svg
   stacking contexts?

   heycam: in svg content it's going to be the same as css

   cabanier: 2d transforms don't create stacking context in svg
   because we do many transforms

   heycam: we probably need to have an overall description of the
   rendering
   ... if z-index isn't on anyone elses plate I'll have a crack
   before the deadline
   ... the concept of a stacking context can come from the css
   spec can't it ?
   ... the overall process will be the same as CSS, but with
   specific SVG rendering steps

   <scribe> ACTION: Cameron to add z-index text to SVG 2
   specification before feature cut off date [recorded in
   [25]http://www.w3.org/2014/04/08-svg-minutes.html#action03]

   <trackbot> Created ACTION-3613 - Add z-index text to svg 2
   specification before feature cut off date [on Cameron McCormack
   - due 2014-04-15].

making width/height presentation attributes on foreignObject

   davve: this came up when I did patches for Blink
   ... I have some examples

   <davve> [26]http://jsfiddle.net/MmkYj/

     [26] http://jsfiddle.net/MmkYj/

   <davve> [27]http://jsfiddle.net/MmkYj/1/

     [27] http://jsfiddle.net/MmkYj/1/

   one uses height attribute and one uses property

   davve: in FF they are equivalent, but not in Blink
   ... svg and foreignObject are the two elements that interact
   with the CSS box model

   krit: I would like to avoid having width and height
   presentation attributes on some elements and not on others

   davve: don't think it's that odd. It makes sense for things
   that interface with the box model

   ed: I don't think accepting for foreignObject would preclude us
   from adding it for other elements later

   heycam: what about iframe and canvas?

   krit: for iframe can you override the width and height
   attribute with stylesheet?

   davve: not sure

   pdr: yes in Chrome

   <pdr> Iframe example: [28]http://jsfiddle.net/MmkYj/2/

     [28] http://jsfiddle.net/MmkYj/2/

   <pdr> Updated with style overriding:
   [29]http://jsfiddle.net/MmkYj/3

     [29] http://jsfiddle.net/MmkYj/3

   pdr: so this would apply for svg as well

   ed: there might be an existing resolution for this

   heycam: so in svg foreignObject and iframe will have x and y.
   Should they be presentation attributes as well?

   ed: according to previous resolution, yes

   heycam: I'm happy to just do it for width and height
   ... the previous resolution was about mapping many to
   presentation attributes but we never followed through

   ed: I think we should do it for foreignObject

   heycam: I think it doesn't make sense to make rect width and
   height presentation attributes without the broader set being
   done
   ... we can easily do width and height for foreignObject and
   iframe and do the others later if we want

   RESOLUTION: make width and height attributes on foreignObject
   element presentation attributes

   <scribe> ACTION: Erik to edit SVG 2 to make width and height
   presentation attributes on foreignObject [recorded in
   [30]http://www.w3.org/2014/04/08-svg-minutes.html#action04]

   <trackbot> Created ACTION-3614 - Edit svg 2 to make width and
   height presentation attributes on foreignobject [on Erik
   Dahlström - due 2014-04-15].

Resolving concerns with marker-segment and marker-pattern

   heycam: marker-start, mid and end are the existing marker
   properties
   ... I added my proposal for two additional properties
   ... marker-segment lets you place markers in the middle of each
   segment of the path
   ... marker-pattern is something more like a stroke-dasharray
   where you give a sequence of lengths and marker elements that
   are repeated without regard to the segments of the path
   ... there was some concern from Tab and Dirk that we might not
   need to have both marker-pattern and marker-segment
   ... there should be a way to do marker-segment with
   marker-pattern
   ... some of the solutions were to have instructions in the
   pattern pattern for advancing to the next segment
   ... it seemed like that might be a bit confusing
   ... so I prefer having separate controls
   ... I wanted to resolve either way

   krit: I don't think it was about having more or less properties
   ... but about control

   [Dirk draws example showing markers that are offset relative to
   the segment they are in]

   Tav: it's related to variable width stroke
   ... could add a length unit to variable width stroke so the
   position of the widths is dependent on the length of the
   segment

   [Brian draws example]

   ed: is there anything to deal with short segments that might
   not fit the author defined sequence of markers?
   ... e.g. I want those markers if the segment is > than some
   distance

   heycam: nothing in the spec at the moment to allow that
   ... similar to stroke-dashadjustment that I want to talk about
   later
   ... not exactly the same but you might want to disable dashing
   based on length
   ... I have a feeling that marker pattern where you're going by
   length than by segments is generally more useful
   ... you wouldn't come across that problem there although the
   whole length of the path may come in to play

   krit: one of the issues with marker-pattern was that you can
   have multiple layers of markers defined

   heycam: in my proposal at the moment you can only have one
   marker-pattern

   krit: how do you differ between each in the shorthand?

   heycam: it's defined (you'll have to look at the spec)

   [discussion on how the shorthands work]

   krit: if we don't make marker-pattern part of the short hand
   then there's no problem
   ... shorthand must reset all marker properties but it's not
   necessary for marker to set marker-pattern

   <heycam> thread
   [31]http://lists.w3.org/Archives/Public/www-svg/2012Nov/0023.ht
   ml

     [31] http://lists.w3.org/Archives/Public/www-svg/2012Nov/0023.html

   heycam: so the specific issue of whether marker-segment is
   useful as a separate property. What do you think?

   Tav: I'd get rid of it and use a segment reference in
   marker-pattern

   birtles: Tab thinks adding a new type is no problem

   Cameron's example: 0.5 seg url(#diamond) -20px url(#dot) 40px
   url(#dot) -20px 0.5seg

   [Discussion on various syntax options]

   heycam: is it possible to reuse fr somehow?
   ... no, it's probably a bit different
   ... but shouldn't be a problem to add a new unit
   ... do you want to make a single property, or is the offset
   more the thing you want to solve?

   krit: the offset
   ... would be ok with only having one track for marker-pattern

   heycam: that's how the spec is currently
   ... maybe we could wait to see how it's solved for variable
   width stroke and then try to bring that across to
   marker-pattern
   ... the example seems a bit complex for the simple case

   birtles: calc would simplify it

   krit: at some point I think I argued for the same syntax for
   marker-segment and marker-pattern. Then you wouldn't need the
   segment unit. marker-segment would define a pattern but per
   segment
   ... you could then use percentages and pixels to define offsets

   heycam: we have the same thing with stroke-dashadjustment where
   you can choose between repeating dashes over the whole length
   of the path or per segment
   ... might be a bit far removed, but it's as similar problem
   ... would be good if we could have a consistent way of
   selecting path or segment based control for all three cases
   (marker, variable width stroke, dasharray)

   pdr: marker-mid when you point to a marker with position, it
   doesn't seem like that's used here

   heycam: position is new. You can put marker elements as
   children of a path

   pdr: marker-mid pointing to a marker with position of -50%...
   would this be the same as what you're proposing for
   marker-segment?

   krit: you'd always end up with one segment with no marker

   heycam: you'd have to extend marker-mid to take a pattern

   krit: why not go with marker-pattern first and then
   marker-segment later?

   heycam: we could
   ... let's see how we solve things for variable width stroke
   ... so do people thing we should forget marker-segment for now?

   ed: I would suggest going with only one to begin with

   Tav: I'd put marker-segment in marker-pattern

   heycam: we can do that
   ... it's compatible
   ... do you think relative values for marker-pattern?

   Tav: I think you want to align dasharray with markers

   birtles: for variable width stroke it's absolute. It makes
   sense for variable width stroke to do it this way. There's a
   potential inconsistency there
   ... variable width stroke doesn't have the seg unit so it's
   different
   ... but don't want to have subtle inconsistencies
   ... maybe we need to revisit variable width stroke syntax
   tomorrow

   heycam: how about we say we'll drop marker-segment and leave
   marker-pattern as is at the moment pending other discussions

   RESOLUTION: drop marker-segment in favour of marker-pattern

Removing marker knockouts

   heycam: I had this grand idea of removing parts of the stroke
   around where markers are placed
   ... I was trying to find a good way of specifying the shape
   that you'd remove
   ... the classic metro map example

   Tav: important for arrow heads

   heycam: what I tried to do was not have another marker
   definition of a shape to remove from the stroke

   nikos: could you do a multi pass thing where you use the
   markers as a mask when drawing the path?

   [discussion on problems that might pop up with this technique]

   heycam: I don't really want a solution where you have to split
   up rendering of the path to ensure overlaps work

   pdr: you can achieve this at the moment using two paths can't
   you ?
   ... you have one path that defines the path. Where you want cut
   outs you place a marker. You use that as a mask when re-drawing

   [Tav draws arrowhead example]

   Tav: you have a viewport on the marker and you define a cutout
   as a path so the cutout can be any shape

   heycam: we discussed this before. One of the issues, when you
   have a clip path, is you need to invert that shape and union it
   with all the other shapes
   ... would be ok with a mask
   ... would be nice if you didn't have to define anything extra
   on the marker
   ... but this solution is more general

   pdr: what happens if there's a hole in the marker?

   Tav: it's up to you to add that hole to the clip or not
   ... for the subway case, the cutout is the center of the circle

   [discussion of the result of applying the clip to a
   curved/warped path]

   Tav: I think my suggestion fits 95% of the cases
   ... but if you want the cut of the path to be a particular
   angle then it may fail

   pdr: someone on irc was having issues drawing junctions on
   circuit markers. Seems like it's a related problem

   ed: so for the removal part, do we agree on that?

   Tav: I'd like my proposal

   heycam: I'm happy for my stuff to be removed from the spec

   krit: for overlapping path segments are we ok with having
   artifacts?

   Tav: seems like a minor case

   krit: I think users would care

   Tav: most important case for us is start and end markers, but
   it would be good for others too

   heycam: if we could solve the subway map problem that would be
   good

   <scribe> ACTION: Tav to write up proposal for clipping sections
   of path around markers [recorded in
   [32]http://www.w3.org/2014/04/08-svg-minutes.html#action05]

   <trackbot> Created ACTION-3615 - Write up proposal for clipping
   sections of path around markers [on Tavmjong Bah - due
   2014-04-15].

'stroke-dashcorner' and 'stroke-dashadjust'

   heycam: a long time ago we discussed adjusting
   stroke-dasharrays so that
   ... 1) you could ensure dashes happen at corner of paths
   ... 2) control repetition so you could have an even number and
   not end in the middle of the dash pattern
   ... I added 'stroke-dashcorner' and 'stroke-dashadjust' to the
   spec
   ... stroke-dashcorner controls whether to put a dash at every
   corner of the path and what the size of that dash is
   ... it only makes sense for paths where the corners are
   meaningful. So probably doesn't make much sense for curves

   krit: Andreas had the requirement that you want stroke on
   corners and where lines meet

   heycam: my thing is on every corner, doesn't take into account
   the angle of the corner

   krit: for the curves with smooth transition (t) you probably
   don't want a dash

   [33]https://svgwg.org/svg2-draft/painting.html#StrokeDashing

     [33] https://svgwg.org/svg2-draft/painting.html#StrokeDashing

   ed: are dashes between the corners distributed?

   heycam: that's the other property that controls that
   ... when you have corner dashes you do the dash-array only
   between the corner dashes

   ed: I think we have a resolution to allow radius on corners,
   what happens there?

   heycam: for rounded rects you don't want corner dash at the
   edge of each arc, you want it throughout arc

   ed: or maybe you don't want a corner dash at all

   krit: how do you implement it ?

   heycam: if you can't modify the code that does dashing, you may
   have to expand the dasharray out and work it out

   krit: you can't rely on the graphic library

   pdr: Skia doesn't offer this today

   heycam: you can give an arbitrary length dash array so you can
   work it out yourself
   ... there is similarity with this and the segment stuff we were
   talking about before
   ... the other property is stroke-dashadjust
   ... and that's for doing adaptive dashing or adjusting
   repetitive dashes so it fits in the space as you want

   [shows examples]

   heycam: you can use this property to say either, make dashes
   and gaps shorter to just fit in, or longer and just fit in
   ... and also whether it applies to only the dashes or the gaps
   ... might be too much control?
   ... but that's how we discussed it last time

   Tav: it would be easiest to just do both

   heycam: don't think it's that hard in any case
   ... works well in conjunction with stroke-dashcorner where you
   don't want a little bit before the corner

   krit: in illustrator we adjust the dasharray for each segment

   ed: so what feedback did you want?

   heycam: do we still want these features?
   ... and opinions on the issues in the spec

   Tav: I like this stuff, but I'm not sure you're meeting the
   maps use case of nice intersections

   heycam: I neglected to mention that when you turn dash corners
   on, dasharray gets repeated per segment rather than along the
   whole path
   ... so is it ok to leave this stuff in the spec?
   ... Tav do you want to solve the T intersection problem?

   Tav: not sure how we would solve it

   pdr: could you have something like a distribute property where
   you say dashes are two units long but you have wiggle room of 2
   to make it look nice?

   heycam: you'd have to know where the intersections are
   ... I'll leave these in the spec for the moment and if you have
   opinions on the issues let me know or we can discuss in a
   telcon

stroke bounding box

   krit: masking is the first spec that makes use of certain
   keywords such as view box and stroke bounding box
   ... we have an issue
   ... should we use the real bounding box or an approximation?
   ... looked at canvas code and it looks like it's much faster to
   do an abstraction
   ... so I'd like to get an approximation for a number of reasons
   ... is it ok if I come up with some spec text that uses an
   approximation?

   Tav: i'd like to avoid bounding box changing on walking dash

   pdr: there are use cases where it would be useful to use the
   exact bound
   ... if you're drawing the dashes yourself

   krit: I'm talking about the masking spec where you want
   something reliable
   ... we wouldn't take dashing into account

   heycam: think it's much more likely that you'd want to ignore
   the dash or you don't care about the dash

   pdr: does this approximation take into account markers?

   krit: don't think we would

   heycam: think about it in terms of getBBox and the keywords we
   added there
   ... when you say marker=true it means include all of the fill
   and stroke and markers

   pdr: what would you do for variable width stroke?

   cabanier: take the widest width?

   krit: we use object bounding box so control points of beziers
   are not what's used
   ... approximation is on the stroke, not on the shape
   ... so would people be unhappy if we use an approximation?

   heycam: don't think so

   krit: would you be unhappy if I put the definition in masking
   and not reference SVG 2?

   heycam: think it should go in SVG 2

   krit: can't reference SVG 2 unless it's CR

   heycam: think that was being relaxed

   krit: I'll put it in the masking spec and we'll see how SVG 2
   goes

   <ed> ed: I think this should be in svg2

   RESOLUTION: Will use an approximate bounding box for stroke-box
   keyword

   <scribe> ACTION: Dirk to write specification text for
   approximate bounding box that is used with stroke-box keyword
   [recorded in
   [34]http://www.w3.org/2014/04/08-svg-minutes.html#action06]

   <trackbot> Created ACTION-3616 - Write specification text for
   approximate bounding box that is used with stroke-box keyword
   [on Dirk Schulze - due 2014-04-15].

   <ed> (15min break)

   BREAK

   <Tav> [35]http://tavmjong.free.fr/blog/?p=472

     [35] http://tavmjong.free.fr/blog/?p=472

   <ed> scribeNick: ed

Canvas Path2D update

   dirk: in karlsbad we argued that it's expensive to keep path
   data live and synchronized
   ... one proposal was to use Path2D from canvas
   ... the graphic engine does optimization behind the scenes
   ... idea was to get this normalized data back
   ... and to use this for animations or whatever
   ... Path evolved to Path2D
   ... is now designed to be a library that is readable, but not
   writable
   ... the use-case the SVG WG hoped for is not there

   rik: you could turn the data back into a string if you wanted

   dirk: some graphic libs experiment with doing everything on the
   gpu
   ... so you'd jjust have a reference to the path on the gpu

   rik: is chrome working on this?

   pdr: the way is just to send the data over
   ... don't know when the normailzation happens, not sure it
   matches the format you're asking for

   heycam: the svg spec says how the noramlization works there
   ... but not how many segments you get and such

   dirk: the Path2D is just an opaque pointer to the path, you
   cannot inspect/read it

   rik: we could add a Path2D accessor on the svgpathelement

   dirk: path2D has no way of asking for its bbox
   ... chrome and firefox do have accessor for that

   pdr: when you end up drawing you cannot read it back
   ... so getting a bbox isn't going to be quite "real"

   dirk: for the Path2D yes, but implementation-wise it's not the
   case
   ... I'm not sure at this point how we could make use of it in
   svg

   ed: the use-case I see is assigning the Path2D to a path
   element
   ... e.g for boolean operations

   rik: right, unioning circles and such
   ... I think it's still useful in svg

   dirk: if you assign Path2D to a path element you might not be
   able to get a bbox from the path element

   rik: right now path2d is mostly for caching the path
   ... for canvas
   ... all graphic libs let you read the path data back
   ... so if we want to allow for getting the bbox it's possible

   pdr: why do we want this?

   rik: we want this for svg, doesn't make sense to have a
   separate api for svg and another for canvas
   ... path2d has nothing to do with canvas really
   ... we want to be able to use it everywhere

   pdr: not clear why pathlength and bbox isn't available on the
   path2d interface

   heycam: you could cache the rectangle while the path is being
   created
   ... something about boolean path operations, part of the reason
   for not exposing path data and bbox
   ... that you'd implement the intersections and such on the gpu
   ... so if we avoid exposing the path data then we can do that

   pdr: we know companies spent a lot of money on developing this

   dirk: if we don't flatten we cannot export it

   rik: think we do strokinig on the gpu

   heycam: when you say there are ananlytic solutions, what do you
   mean?

   pdr: intersection of quadratics
   ... the math behind it was quite hard

   <krit> ScribeNick: krit

   <ed>
   [36]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

     [36] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

F2F

   ed: when do we want to meet?

   krit: when is conference?

   heycam: august 27 - 30
   ... wed - sat

   krit: 2 days is not enough for us?
   ... what about splitting the meeting?

   cabanier: not sur eif I go to the conference

   heycam: can not assume that everyone is going to the conference
   ... we could do it the weekend before

   birtles: not sure if I am coming

   Tav: I go to both

   nikos: going to both as well

   Tav: have preference going before

   cabanier: me too

   heycam: I too because TPAC is close

   krit: would be in favor for before as well
   ... sat, mon, tue?

   heycam: ok

   ed: cabanier: yeah

   nikos: where do we have the meeting?
   ... london? Winchestor?

   krit: didn't someone check for university?

   heycam: we should ask

   ed: would be in favor for London

   heycam: we try Mozilla office first

   ed: 23-26th it will be without sunday

   RESOLUTION: 23-26th August next F2F

   <scribe> ACTION: heycam to check office space for London F2F
   [recorded in
   [37]http://www.w3.org/2014/04/08-svg-minutes.html#action07]

   <trackbot> Created ACTION-3617 - Check office space for london
   f2f [on Cameron McCormack - due 2014-04-15].

version number

   Tav: we decided to get rid of version numbers
   ... but for authoring tools it might be useful to have it

   krit: you can always do that

   Tav: might think will continue to use it

   krit: we have data-* attributes in HTML which can be used for
   scripting. Can you use that?

   Tav: yeah
   ... there are documents from elsewhere we want to target

   krit: there are tools removing unnecessary data

   Tav: yes

   krit: want to say you can not rely on the version number

   Tav: that is true

   heycam: what are HTML authoring tools doing for HTML5 and
   incrementally added features?
   ... lets say we have mesh gradients in SVG
   ... how do authoring tools handling that?

   Tav: you may want to have a backup for that

   heycam: do HTML tools have similar things?

   Tav: they probably have something like that

   krit: usually they don't use features that are not widely
   apployed

   cabanier: we have tools that create browser specific things

   krit: you have things like modernizer that check for that

   cabanier: the question was about authoring tools

   heycam: so they get along without versioning, so we might as
   well

   Tav: as an example paint-order... Iwant to make sure that older
   browsers can use it, but inkscape can read it back

   heycam: there is so much boiler plate and i would like to avoid
   that

   pdr: there is so much history about that

   Tav: ppl are using SVG
   ... want to convert for the future

   heycam: don't think that data-* attributes are meant for that

   pdr: what about base-rprofile, xlink NS and so on... still
   required?

   heycam: base-profile was removed
   ... you have modeled specs... so what would be the version
   number be?

   ed: how do you detect what you want to read back from the
   preserved data?

   Tav: when people write the code, we read it back in

   heycam: as an author wants to export with a set of features
   that can be displayed

   pdr: does someone do something different with versioning?
   Illustrator? InkScape?

   Tav: krit: no

   cabanier: we might for output

   krit: not for input

   heycam: there is so many stuff that is new and changes of the
   time
   ... so it is per feature rather then version attribute

   Tav: batik lets you enable certain things based on the version
   string

   ed: so are we adding it again?

   general no

Symbol with refX/refY

   Tav: Andreas asked for that
   ... it is nice to position symbols based on a bottom center and
   so on
   ... so you like to have some point
   ... markers have that already
   ... symbols are essential like markers
   ... chris mentioned that he positions at center center
   ... and positions realtive to viewport
   ... and Andreas asks if we can have something like refX/refY
   for that

   birtles: you can do it with transform-origin as well

   Tav: it would be nice not to worry about sliding things over
   ... could be stored in the symbol

   heycam: markers and symbol loosk symbol

   krit don't think so

   heycam: what are the differences

   krit: symbol is basically an SVG element which is not visible

   pdr: you mean like defs?

   <Tav> [38]http://tavmjong.free.fr/SVG/SYMBOL/symbol.html

     [38] http://tavmjong.free.fr/SVG/SYMBOL/symbol.html

   krit: no, don't think so, it has width, height and creates a
   viewport like svg

   pdr: can't you implement everything with symbol?

   heycam: it is a little bit more complicated
   ... what if we allow markers to be reference able by use?

   Tav: markers are different because they set width and height

   krit: symbols do as well

   Tav: when you look how use interacts with symbol, then this is
   different than a marker does with path

   heycam: it would be nice to measure if people use symbol

   krit: Illustrator uses symbol

   pdr: do not have use counters in Blink for symbol

   krit: to understand it, so refX and refY is used as some kind
   of offset/delta to the position it gets placed to?

   pdr: do you use symbol always with use?

   Tav: yes

   pdr: why doesn't g with translate in the symbol doesn't work?

   Tav: they clip by defautl

   ed: you can specify overflow=visible

   heycam: makes sense to avoid duplication but having this kind
   of feature is useful

   Tav: for maps it is useful

   ed: would be ok with it

   davve: what about using netagvie x and y on symbol?

   heycam: this would move it even more in the clipping region

   stakagi: I always use defs on symbols
   ... and overflow visible
   ... for non scaling feature, the symbol is not scaled

   heycam: it feels more natural to have overflow visible and the
   content is centered around center

   krit: maybe you want to have it clipped

   <stakagi> <defs><circle cx="0" cy="0" r="10" id="poi1"/></defs>
   <use href="#poi1" x="X" y="Y"/>

   pdr: icon thing

   RESOLUTION: Add refX/refY to symbol element

   <scribe> ACTION: Tav to add refX/refY to symbol [recorded in
   [39]http://www.w3.org/2014/04/08-svg-minutes.html#action08]

   <trackbot> Created ACTION-3618 - Add refx/refy to symbol [on
   Tavmjong Bah - due 2014-04-15].

svg implementation status

   pdr: there is a danger that things that are documented are out
   of date
   ... otherwise blink-dev
   ... but maybe you want to search in the list
   ... there are things that are added or taken away

   ed: what about using shepherd system to indicate implementation
   status?

   krit: it is basically relying on manual tests run by users and
   then the results get displayed in the spec
   ... webkit has WebExposed flag for new features in WebKit

   pdr: heycam we have one bug for SVG2

   heycam: we do not have a status page

   pdr: I think we can get links for the status
   ... I would not like to create another source for authors

   [general discussions about features so far in SVG2]

   trackbot, make minutes

   <trackbot> Sorry, krit, I don't understand 'trackbot, make
   minutes'. Please refer to
   <[40]http://www.w3.org/2005/06/tracker/irc> for help.

     [40] http://www.w3.org/2005/06/tracker/irc%3E

Summary of Action Items

   [NEW] ACTION: brian to replace buffered-rendering with
   will-change in svg2 [recorded in
   [41]http://www.w3.org/2014/04/08-svg-minutes.html#action02]
   [NEW] ACTION: Cameron to add z-index text to SVG 2
   specification before feature cut off date [recorded in
   [42]http://www.w3.org/2014/04/08-svg-minutes.html#action03]
   [NEW] ACTION: Cameron to write polyfill for his DOM proposal
   before next F2F (with enough time for WG to experiment)
   [recorded in
   [43]http://www.w3.org/2014/04/08-svg-minutes.html#action01]
   [NEW] ACTION: Dirk to write specification text for approximate
   bounding box that is used with stroke-box keyword [recorded in
   [44]http://www.w3.org/2014/04/08-svg-minutes.html#action06]
   [NEW] ACTION: Erik to edit SVG 2 to make width and height
   presentation attributes on foreignObject [recorded in
   [45]http://www.w3.org/2014/04/08-svg-minutes.html#action04]
   [NEW] ACTION: heycam to check office space for London F2F
   [recorded in
   [46]http://www.w3.org/2014/04/08-svg-minutes.html#action07]
   [NEW] ACTION: Tav to add refX/refY to symbol [recorded in
   [47]http://www.w3.org/2014/04/08-svg-minutes.html#action08]
   [NEW] ACTION: Tav to write up proposal for clipping sections of
   path around markers [recorded in
   [48]http://www.w3.org/2014/04/08-svg-minutes.html#action05]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [49]scribe.perl version
    1.138 ([50]CVS log)
    $Date: 2014-04-08 15:43:44 $
     __________________________________________________________

     [49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [50] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [51]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

     [51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/NS/API./
Succeeded: s/NS/API/
Succeeded: s/content/API/
Succeeded: s/SVG DOM usage?/SVG DOM usage? particularly the pathSeg DOM/
Succeeded: s/we want that functionality?/on that?/
Succeeded: s/visible?/visible/
Succeeded: s/heycam/krit/
Succeeded: s/refs/defs/
Succeeded: s/allow/specify/
Succeeded: s/refs/defs/
Found ScribeNick: krit
Found ScribeNick: birtles
Found ScribeNick: nikos
Found ScribeNick: ed
Found ScribeNick: krit
Inferring Scribes: krit, birtles, nikos, ed
Scribes: krit, birtles, nikos, ed
ScribeNicks: krit, birtles, nikos, ed

WARNING: No "Present: ... " found!
Possibly Present: Tav birtles cabanier davve dirk ed heycam https joined
 krit left nikos pdr rik scribenick shepazu stakagi svg tbah trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Found Date: 08 Apr 2014
Guessing minutes URL: [52]http://www.w3.org/2014/04/08-svg-minutes.html
People with action items: brian cameron dirk erik heycam tav

     [52] http://www.w3.org/2014/04/08-svg-minutes.html


   [End of [53]scribe.perl diagnostic output]

     [53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 8 April 2014 15:46:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:19 UTC