See also: IRC log
<heycam> krit, FX topics will be right after the agenda rearrangement discussion this morning
<krit> heycam: will call in around 10am
<krit> heycam: will there be a video conference?
<heycam> krit, there will -- you'll need to use the link that simon provided in his mail, rather than the link I gave
<krit> K, thanks
<heycam> krit, FX is moving to Thursday morning now, sorry
<heycam> so that Dean can be here
<heycam> so we'll be in the usual room after all
<SimonSapin> krit: ping me when you want to call in
<birtles> I'm waiting to see what the agenda is for CSS for today before I decide if I should stay or not
<birtles> I also realised I didn't send the minutes from yesterday
<heycam> birtles, ok
<heycam> there is a special url to go to generate a previous day's minutes
<birtles> heycam: cheers
<heycam> birtles, yeah so you go to say http://www.w3.org/2015/08/24-svg-irc,minutes
<heycam> so the IRC log url plus ",minutes"
<heycam> I don't know whether that will upload the generated minutes to the expected URL though
<ed_work_> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp&l=102 (for SVGSVGElement.viewport)
<birtles> yeah, I can't manage to get the minutes to be uploaded
<heycam> birtles, ok; maybe just attach the HTML to the mail, then, so it still has some URL
<birtles> heycam, I can't get the regular plain text version so I was just going to make up my own plain text version that is similar to the usual one... but is that going to break your tool that scrapes the minutes emails?
<heycam> birtles, no it'll be fine
<ed_work_> just add ,text to the end of the minutes url, should work?
<heycam> but good point; the tool will expect the normal minutes url so I guess it'll miss them
<heycam> I'll do something manual to add it after you send it
<birtles> yeah, adding ,text doesn't work
<krit> SimonSapin: ping
<SimonSapin> krit: Do you wanna join CSS or SVG?
<krit> no FX today?
<heycam> krit, it got moved to Thursday
<krit> ok, SVG then
<krit> birtles: Do you know what Animations 2 will be?
<krit> birtles: on the agenda of CSS WG tomorro
<krit> birtles: on the agenda of CSS WG tomorrow
<birtles> krit: I think it ended up being Wednesday afternoon
<krit> birtles: yes, but what is it? WebAnimation 2 or CSS Animations 2?
<birtles> krit: https://wiki.csswg.org/planning/paris-2015#wednesday
<birtles> krit: CSS Animations 2
<krit> birtles: who suggested it? Is there a draft?
<birtles> krit: Shane and I. Yes.
<birtles> krit: https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html
<TabAtkins> https://drafts.csswg.org/css-animations-2/
<krit> thanks
<shane> krit: Tab's link is wrong.
<birtles> TabAtkins: the one we want to ask about tomorrow is a later version than that
<krit> k
<TabAtkins> birtles: You should be pushing it!
<birtles> TabAtkins: pushing it?
<TabAtkins> To the repo
<birtles> TabAtkins: I want to get the ok that this approach is ok
<birtles> (also I don't have write access to the css repo)
<TabAtkins> Shane does!
<shane> we wanted to talk about whether we could stop being a delta specification first, I think?
<birtles> yeah, I wanted to ask how I should write it with regards to linking to Web Animations
<krit> birtles: shane: So version 2 will mostly be set up CSS Animations on top of WebAnimation and add animation-composite
<birtles> krit: yeah, basically + animationcancel I think
<shane> birtles: were we going to propose a simple exposure of groups too?
<birtles> and any other features that get added along the way... e.g. there are some discussions about extending timing-functions recently
<shane> or hmm I guess not as that isn't in a WebAnim WD yet...
<birtles> yeah, maybe not, depends on the timeframe for animations-2
<krit> could you add a simple example for 4.5. Animation composite order please?
<krit> (to the draft)
<birtles> krit: yes, of course
<krit> looks great. Not necessarily easy to understand right away from reading it but this is editorial
<heycam> (krit, you can call in whenever you want)
<krit> heycam: is there an agenda for today?
<heycam> krit, yes there are a few topics on the wiki
<heycam> krit, we can discuss them whenever
<heycam> trackbot, start telcon
<trackbot> Date: 25 August 2015
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
<ed_work_> https://svgwg.org/svg2-draft/struct.html#issue62
ed: issue 62 in the structure
chapter is about SVGSVGElement.viewport
... currently Blink is just returning an SVGRect filled with
zeroes
... Firefox does not implement it
... my proposal would be to drop the attribute
krit: did you check the usage of
it?
... I thought I saw it was used
ed: I've seen people try to use
it but then use fallbacks to get the information another
way
... using innerHeight etc.
Tav: if it were implemented, would it be useful?
heycam: it's never been clear to me what viewport should return, so I don't know
ed: yes, so figuring out what
it's supposed to return is a question
... the problem in Blink was that it was hard to get the right
values at the right time
... so you could return something but it might not be the
correct values
heycam: Edge does return a rectangle with some values in it
BogdanBrinza: if it were useful I think we would have heard about it
<ed_work_> https://code.google.com/p/chromium/issues/detail?id=395838
<ed_work_> https://bugzilla.mozilla.org/show_bug.cgi?id=503855
krit: not implemented in WebKit
cyril: if you animate the viewBox would you expect to see the values in .viewport?
heycam: I think it's an open
question what viewport was intended to return
... it's not clear
[some discussion about what viewport might mean]
Tav: so is this related to pAR?
krit: with pAR the viewBox size
is different from the viewport size
... I think the point where it would be useful is if you want
to put say a background rectangle covering the window
heycam: testing in Edge, the .viewport.{width,height} just return whatever value would be returned by .{width,height}.baseVal
<krit> https://www.irccloud.com/pastebin/38EnSIQu/
krit: what does Edge return for .viewport for the inner <svg>?
<BogdanBrinza> http://jsfiddle.net/boggydigital/mh0tgwn7/2/
heycam: so currently you can get
all this information by looking up x/y/width/height property in
the SVG DOM
... and for exposing the size of the window that the outer
<svg> is fit into, you can look up
window.innerWidth/innerHeight
... and I can't think of any other useful values to return. so
I suggest just removing it.
RESOLUTION: We will remove SVGSVGElement.viewport.
<scribe> ACTION: Erik to remove SVGSVGElement.viewport. [recorded in http://www.w3.org/2015/08/25-svg-minutes.html#action01]
<trackbot> Created ACTION-3815 - Remove svgsvgelement.viewport. [on Erik Dahlström - due 2015-09-01].
<ed_work_> https://svgwg.org/svg2-draft/struct.html#issue58
ed: right now, you can point a
<use> to pretty much anything, and it will just clone
that subtree with anything that's in it
... Blink is currently filtering out some elements from when it
builds the shadow trees
... so foreignObject is not included, for example
... my question is should this be something that we
specify?
Tav: so you can't have clones of video playing
ed: right now I know if you have video inside foreignObejct, you get the wrong position
heycam: what's the reason for disallowing these elements?
ed: first, not all aspects of
what cloning means is still not clear
... whether the clones are "linked" somehow
... and the spec was not clear on what should happen
... if you have some kind of interaction, would that update all
instances?
heycam: I think this will fall
out of how we define use in terms of shadow trees
... so it will be clear what's meant to happen, though not sure
if that will be the desirable behaviour or not
ed: Blink builds the cloned tree, then strips out the disallowed elements
heycam: so that could affect how CSS selectors match things in the tree?
ed: yes
heycam: so maybe force them
display:none instead?
... when we define in terms of web components it's very likely
these will be independent cloned subtrees
... since shadow dom doesn't support the kind of unified tree
that SVG tried to have
... if that's the case, then the videos etc. will all be
independent, and there should be no problems
ed: ok. in that case I'll just remove the issue, and reword it to mention expected behaviour with independent clones
cyril: I saw a small issue about unknown elements -- in embedded content it has a mention of not rendering unknown elements
<BogdanBrinza> sample: http://jsfiddle.net/boggydigital/gcthq51u/show/
BogdanBrinza: I'd like to discuss each of these issues
<BogdanBrinza> chapter: https://svgwg.org/svg2-draft/linking.html
BogdanBrinza: no discussion needed for issues 4 and 5 in the chapter
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue6
BogdanBrinza: currently
transforms on svgView does something weird
... in Chrome/Edge it's consistent, and looks like it's scaling
from the 0,0 of the original image
... in Firefox it looks like it's applying from the 0,0 point
of the viewBox transformed image
... in the sample I've pasted, it's the third picture
heycam: the question then is what's the order of the viewBox transform and transform attribute transform?
BogdanBrinza: yes
heycam: I would expect the order to be the same as if you had <svg viewBox="..." style="transform: ..."> in the document itself
BogdanBrinza: I think Firefox's
behaviour makes more sense
... the spec also doesn't mention anything about
transform-origin
... that's issue 7
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue7
BogdanBrinza: without
transform-origin, the usefulness of this is limited
... harder to get the transform you want
... so I think we should support transformOrigin at least in
the view spec
... if we do want to continue allowing transform(), I suggest
we should bring along those other features like
transform-origin
heycam: if you don't specify in transform-origin, would it be relative to 50% 50%
BogdanBrinza: yes I would say it
should match what happens on the root <svg> element, so
50% 50%
... the other one is perspective
... I would say either add transform-origin/perspective, or
remove transform
heycam: supporting perspective here sounds a bit more complex
BogdanBrinza: with my implementor
hat on, I would be worried about that complexity
... I would be fine with the current set of view spec features,
so not adding transform-origin/perspective for now
... unless we hear demand for it
RESOLUTION: We won't add transform-origin/perspective values for view specs.
yet
RESOLUTION: viewspec's transform applies after performing the viewbox transform
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8
BogdanBrinza: this says spaces
are not allowed, and semicolons separate fragments "may" be URL
escaped
... it looks like spaces are accepted in the browsers
... at least in Firefox/Blink/Edge
... for URL escaping, it doesn't work in Blink but does in
Firefox and Edge
heycam: I think we don't need to
talk about escaping
... that happens at a layer before the spec cares about
it
... I'm fine with allowing spaces since everyone does
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8
scroll down from that to the second issue 5
BogdanBrinza: xywh allows pixels
(default) or percents
... how do these map to SVG units?
heycam: I think xywh applies at
the CSS image level
... so percentages should resolve against whatever size of
image that CSS is going to tile/position/etc. from the
background-* properties
... not sure what the right term is
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue9
BogdanBrinza: when referencing a
specific view, the spec talks about getting the view of the
closest ancestor SVG element displayed in the viewport
... what is the expected effect if the closest ancestor svg is
not the root element?
heycam: I'm not sure just updating the inner <svg>'s viewBox etc. attributes gives you useful behaviour
BogdanBrinza: it's a bit confusing that it applies to the inner <svg>. the position of the <view> element in the document would affect what's happening
RESOLUTION: The view element always applies to the outermost <svg>, even when inside an inner <svg>.
<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue10
heycam: this about whether missing viewspec values get set to their initial value, or whether the document's value is used
ed: I think you get strange
results if you blow away everything
... I think you don't want to do that usually
... and you just want to override one of them
... if you blow off the viewBox for example it's going to be
very strange
BogdanBrinza: looks like we agree that it should override specific attributes then
RESOLUTION: Missing viewspec values use the values specified in the document, not resetting them back to their defaults.
<ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg
<ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg
TabAtkins, where is it defined that url() values in properties are resolved against the document's base (as given by <base>)? and does this apply to every property that takes a url()?
<BogdanBrinza> http://pastebin.com/vpYSzfZm
<scribe> ScribeNick: heycam
<tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html
tkonno: this presentation will
udpate you on the proposal for zoom features for media
queries
... Takagi-san sent an email to www-style with this draft
spec
<TabAtkins> heycam: https://drafts.csswg.org/css-values/#relative-urls
tkonno: for changing style and
contents according to zoom ratio
... we've written a polyfill
... we'd like to bring this initial draft to an editor's
draft
... let's go through some use cases
... two use cases here: mapping, and high resolution
photos
... at KDDI we're interested in mapping using SVG
... for mapping, when the map is zoomed out, the user wants to
know only the overview of that area
... otoh, when the map is zoomed in, the user wants to know the
detail of the area, such as some landmarks
... as you know, map content is made up from different
layers
... base map, plus other layers on top
... if the content layers are switched according to zoom, the
user can get the appropriate information
... the function to switch the content layer is essential for
mapping
... second use case is high resolution photos
... here's an example from MS
... this is a smoothly zoomable high resolution image
... when zoomed in, it uses a high resolution image
... currently, these use cases are realized by massive.js or
standards other than web standards
... so we'd like to realize these use cases using web
standards
... so how can we do this?
... the min-zoom feature is a new media feature
... its value (ZoomRatio) is a threshold
[see presentation for example code]
scribe: I'll explain what's meant
by "zoom" here
... zoom functionality is divided into two types: one is the UA
native zoom, and the other is the web app's zoom
... UA native page zoom affects the initial viewport size
... pinch zoom is also something controlled by the UA, but this
doesn't affect the viewport size
... it behaves like a magnifying glass
... as for the web app's zoom, CSS Transforms can control the
scale of the contents
... so the zoom should be represented as a combination of UA's
zoom and the web app's zoom
[formula in the presentation relating the device pixel size and all these zooms]
tkonno: not sure whether all 6 of
the types of zooms I've listed in the presentation are
useful
... for the mapping use case, document-zoom is the useful
one
... for the other zoom types depends on the use cases
heycam: and for the high resolution image use case?
tkonno: document-zoom too
... the zoom property has already been included in the CSS
Device Adaptation spec
<cyril> http://www.w3.org/TR/css-device-adapt/
heycam: not sure if people implement CSS Device Adaptation, so not sure I would worry about compatibility with it
tkonno: so I think only
document-zoom is needed for our use case
... so that includes pinch zoom and CSS Transforms
cyril: what about currentScale?
heycam: I imagine that, viewBox transform, etc. would all be included, since you're including transform property
tkonno: so why do we need
document-zoom feature?
... a web page might have map content in an iframe. the user
might zoom in the whole web site, not just transform the
embedded element
... but the user could also just scale the iframe's
contents
... so I'd like to know if the concept is acceptible, and
whether the document-zoom feature proposal specifically is
acceptable?
BogdanBrinza: at the last F2F, we
had some private discussions about the use cases here. we agree
the use cases are valuable.
... the way we've been thinking about this is focussed on the
performance
... for the zoom features, you want to have this as late in the
pipeline as possible
... at the display level, if possible
... in terms of types of zoom feature, I'm not sure I agree we
need more than one type
... the resulting content, in any form, would have the
transform available on it
... either you transform the whole document, or an iframe, or
just one element -- the content you care about will have a
transform available
... so I don't think we need many zoom types
... so selecting the zoom for a specific element itself
birtles: in the proposal,
document-zoom is the only one needed
... the only reason for proposing (1) was for consistency with
CSS Device Adaptation, but per discussion, that's not
important
BogdanBrinza: the other comment
is that there are various other display time conditions you
might want to target
... inertia of scroll, for example; hide elements based on the
speed you're panning currently
birtles: that'd be an orthogonal media feature?
BogdanBrinza: yes. there might be
others.
... but yes, we find it acceptable to discuss this further
birtles: konno-san previously summarised discussion up to now in a wiki page, at TPAC 2 years ago there was an action on someone to think about all the different types of zooming
<nikos> scribenick: nikos
<scribe> Scribe: Nikos
heycam: one of the two remaining open issues in types chapter is what getCTM should do whne called on root svg element
and what getScreenCTM should do altogether
scribe: it's really the same
issue
... getCTM gives transform from current element to closest
ancestor svg or viewport establishing element (maybe)
... though not clear what happens if you call it on outermost
svg element
... you have viewbox, transform property, etc
... all of these things may or may not be intended to be
included in the result
... I made some test cases
... linked on the agenda page
... first is when svg element has no attributes
<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015/Agenda
<heycam> http://mcc.id.au/temp/ctm.svg
<heycam> http://mcc.id.au/temp/ctm-viewbox.svg
<heycam> http://mcc.id.au/temp/ctm-transform.svg
<heycam> http://mcc.id.au/temp/ctm-currentScale.svg
scribe: FF returns null when you
call getCTM on root element
... all others return something, but differ on what transforms
are included
... first example in Chrome returns identity, in IE11 identity,
same in Safari I think
... that's the simple case - no features that would have a
transform
... so at least we're getting a reasonable result there
... second example - with viewBox attribute
... Chrome appears to give transform that implements the
viewBox - incorporates pAR
... Safari also gives useful values
... so I think all the browsers that implement it are including
the viewBox
... next one is with the transform property applied
... I think some browsers don't do transform as a presentation
attribute on svg elements
... Chrome doesn't included it, Edge is the same
... Safari is also identity matrix
... so no one is including the transform property
... but the transform property is kind of new and getCTM is
old
... finally, the currentScale value, Chrome also doesn't
included that
... but Edge and IE11 do
... Safari does not
... are there any other transforms that I've forgotten about?
that work on the root element?
... perhaps the ones that come from the view fragment.
BogdanBrinza: CSS zoom property?
heycam: don't think we implement
that
... thought it wasn't clear what zoom was supposed to do
BogdanBrinza: legacy IE and Chrome supports it
heycam: So what thing should be
included in the getCTM?
... is the answer all of these things?
... if you think about what getCTM means for other elements in
the document. It means give me the transform up to some
thing
... so my feeling is that including all of the viewBox and
transform properties would make sense
... transform is the one that no one includes currently, but I
think it makes sense to include it
BogdanBrinza: doesn't make sense to include all others but not transform
cyril: I guess you want it to be
consistent if you copy the SVG into another file
... there's localisation of the transform
<heycam> https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getCTM
heycam: One way I was considering dealing with getScreenCTM was to take all the transforms from viewport establishing elements and multiply them together to give the screenCTM
BogdanBrinza: when would you want to use this?
heycam: one thing might be with mouse events - transform clientX,clientY by getScreenCTM should give you window co-ordinates right?
BogdanBrinza: that's done by
screenX,screenY
... I really can't imagine a scenario
heycam: one thing I've done
before is create some UIs
... and have some content that is at a fixed size and position
in the window irrespective of zoom and pan, etc
... these days you'd probably take that out of the svg document
and use position:fixed
BogdanBrinza: I can't see why you
would want to keep something in the SVG file that must be
relative to the screen
... any scenarios in InkScape?
Tav: ... can't think of anything
heycam: I think the only two
viable options are to return a matrix that includes all the
transforms, or none of the transforms
... talking about getCTM here
... getScreenCTM has a more clear meaning
... I haven't done testing with getScreenCTM to ensure all
these transforms are included
BogdanBrinza: I would argue for
having all of the transforms
... the transforms have meaning and that's what would be
expected from getCTM
heycam: I agree
<heycam> RESOLUTION: getCTM will return a matrix with viewBox, transform property and currentScale/currentTranslate included
cyril: If you take an svg element
with a viewBox and nest it within another svg element with the
same attributes, the CTM is the same for the inner and outer
SVG
... I just tested this
... in Chrome
<heycam> ScribeNick: heycam
<scribe> Scribe: Cameron
nikos: as much as I hate bringing
up old conversations.
... previously we said marker { overflow:hidden } would be
removed from the UA style sheet
... creating markers around (0,0) seems useful
... the issue is how much content would that break? do we want
to go ahead with this?
Tav: I think the decision was a bit wishy-washy
heycam: and overflow:hidden is uniformly applied to markers in implementation?
nikos: yes
heycam: perhaps let's not tempt fate then
nikos: so keeping overflow:hidden
for markers and symbol, not the nicest option, but should be
the one to go with
... we talked about this for symbols recently -- since we have
refX/refY, that helps
heycam: and you can always stick overflow:visible on
Tav: Chris was for it, at the time
heycam: I'm happy to leave it as it is
RESOLUTION: We will leave overflow:hidden in the UA style shet for marker and symbol
nikos: there's a section in the
Rendering chapter defining the "initial clipping path", as
being on the <svg> element as a result of
overflow:hidden
... the term doesn't get used anywhere really
... there's one reference to it in the coords chapter
... but it doesn't say much
Tav: was that to avoid a huge clipping path?
nikos: no, it's just a term that's defined that isn't used
heycam: just get rid of it
<ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg
ed: here's an example showing
HTML <base> element applying inside an SVG file
... it shows a selection of SVG element using some kind of URL
resource
... we have <image>, the first example
if it says "base" it is using the base to resolve the url
scribe: for the textPath example,
it will show upside down text if base is applied
... for the a element, just look at the URL if it has
"resources" in it it's using base
... for the last one, green means using base
ed: so Firefox support
<base> for all of these cases
... for Blink, it works in some cases, not all -- textPath is
not using base
... there might be a bug for the fills, it should show red if
base is not applied, but it's showing blank
https://drafts.csswg.org/css-values/#relative-urls
heycam: so according to the spec, all url() values resolve against the document's base (if inline style sheet), or the style sheet url (if external style sheet)
<TabAtkins> No, against the *element's* base (for inline)
<TabAtkins> (which usually is the document's base)
ok. yeah, considering xml:base.
<TabAtkins> yeah
TabAtkins, does CSS have any value syntax that means "reference to element with an ID in the document"?
to use in place of url(#x)?
like element(x)?
<TabAtkins> element() takes an id selector in the first place
<TabAtkins> element(#x)
ooh
ok
<TabAtkins> But it's an <image> value.
<TabAtkins> Not for arbitrary usage.
oh
<cyril> https://tools.ietf.org/html/rfc3986#page-28
<cyril> the important section is section 5
BogdanBrinza: does anybody disagree with just following the existing CSS rules for resolving relative URLs?
heycam: no, that's the behaviour I would prefer. I don't want special behaviour for SVG properties.
<ed_paris> https://svgwg.org/svg2-draft/struct.html#issue61
[Bogdan shows an example of background-image:url(#) resolving against a base URL that points to a PNG]
RESOLUTION: fill:url(#something) is resolved against the base URL, just like other CSS properties.
<scribe> ACTION: Erik to add a note to the spec for authors to beward of url(#localid) resolving against the base URL. [recorded in http://www.w3.org/2015/08/25-svg-minutes.html#action02]
<trackbot> Created ACTION-3816 - Add a note to the spec for authors to beward of url(#localid) resolving against the base url. [on Erik Dahlström - due 2015-09-01].
ed: next is xml:base
<ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg
ed: this is more inconsistent
across browsers
... Blink doesn't seem to apply xml:base anywhere
BogdanBrinza: Edge is the same as Chrome
ed: Firefox is applying it everywhere
<birtles> https://code.google.com/p/chromium/issues/detail?id=341854
heycam: I would be happy to remove it
birtles: from Anne's comments in there, since Blink has already removed it, it sounds like it should be removed from DOM/HTML
<birtles> specifically comment 12
RESOLUTION: Remove xml:base.
<TabAtkins> +1
<BogdanBrinza> pasting example we've used to check CSS # resource resolution: http://pastebin.com/AZmNc7EC (uncomment placehold.it and comment svg to switch between the two)
<BogdanBrinza> http://pastebin.com/AZmNc7EC
<ed_paris> https://css-tricks.com/tight-fitting-svg-shapes/
<scribe> Meeting: SVG Working Group Paris F2F 2015, day 2
<scribe> Chair: Cameron
<scribe> Scribe: Cameron, Nikos
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ass/add/ Succeeded: s/I'm/tkonno: / Found Scribe: Cameron Found ScribeNick: heycam Found ScribeNick: heycam Found ScribeNick: nikos Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: heycam Found Scribe: Cameron Found Scribe: Cameron, Nikos WARNING: "Scribe: Cameron, Nikos" command found, but no lines found matching "<Cameron, Nikos> . . . " Continuing with ScribeNick: <heycam> Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Scribes: Cameron, Nikos, Cameron, Nikos ScribeNicks: heycam, nikos Present: Cameron Tomo Tav Nikos Brian Cyril Erik Bogdan Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015/Agenda Found Date: 25 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/25-svg-minutes.html People with action items: erik[End of scribe.perl diagnostic output]