See also: IRC log
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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 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].
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 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].
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> 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 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].
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>
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
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
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
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
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
<krit> file:///Users/dschulze/Documents/svgwg/build/publish/coords.html#InterfaceSVGAnimatedTransformList
krit: I added a bit of normative text to SVGAnimatedTransformList
<krit> 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 --
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
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> 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 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].
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: 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 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].
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 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].
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> 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
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> 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 http://dev.modern.ie/ and then Tools > RemoteIE
<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 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> https://github.com/w3c/svgwg/issues/18
<ed> https://github.com/w3c/svgwg/issues/20
<ed> ^ would like these two resolved
<ed> https://github.com/w3c/svgwg/graphs/commit-activity
<Rossen> 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> http://www.w3.org/Graphics/SVG/WG/track/actions/3724
RRSAgent: make logs public
RRSAgent: make minutes
<scribe> Chair: Erik
RRSAgent: make minutes
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/nikos/krit/ Succeeded: s/the spec/other specs/ Succeeded: s/you/then you/ Succeeded: s/Jan 19-21// Found Scribe: Cameron Found ScribeNick: heycam Present: Rossen Bogdan Nikos Cameron Frederick Dirk Erik Tav Satoru Jun Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals Got date from IRC log name: 12 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/12-svg-minutes.html People with action items: amelia cameron dirk erik[End of scribe.perl diagnostic output]