See also: IRC log
<krit> scribeNick: krit
ed: Ties in tinto disucssion
yesterday
... would get rid of const enums from SVG DOM
... might fall out of SVG DOM removal
... I prefer replacing it by simple DOMStrings
... I am concerned about new units getting new values
... we did not expose these new values
... this causes complexity in implementation. which values are
exposed, which aren't
... do we want do wait until we experimented with removing SVG
DOM first?
heycam: would be interesting what
is kept
... SVGTransform has individual enums as does SVGPath
... interested if they are used and useful
krit: no
ed: there are convertTo methods
on SVGLength for instance
... same for SVGAngle and others
heycam: preseverveAspectRatio
krit: filters have a lot of these enumeration
heycam: we should keep SVGLength around every though we remove SVGAnimated objects
<heycam> http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__convertToSpecifiedUnits
krit: don’t think that there is
heycam: there are some conversions used in SVGLength
krit: point is, people just convert to px
heycam: If you are able to remove SVGLength all together then….
krit: we should discuss enums in isolation from SVG DOM removal
heycam: yeah
ed: should we do it in addition?
heycam: in addition would be
easy
... we could have type()
... and take then IDL enum type
ed: I added a unit turn to SVGAngle which is not exposed as an enum value in Blink
krit: for SVGLength alone we have
a huge amount of new units
... which enumerations are you thinking about? In all IDL files
or all of them?
ed: everywhere
... and use new unit types
... also, there is no way to know if an implementation is
supporting certain units
heycam: could create a new
SVGAngle object
... and apply “7turns"
... and look at the unit less value and look if it is 7
krit: for a short term it is reasonable
heycam: I wonder how many improvements should we do before knowing if we remove SVG DOM or not?
krit: Implementations removing SVG DOM now, obviously don’t need to care. The spec can still be ahead and change SVG DOM in case experiment fails
ed: we have the existing method
take a number or string
... can you have multiple types on a property with WebIDL?
heycam: yes
<heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerations
krit: sure you want a string and not a enum value in the sense of WebIDL
heycam: I think you do
krit: they are still basically string with special exception handling
ed: yes, that is what i want
heycam: still wonder if it is worth to do now
ed: I think it is ok to have it in parallel
heycam: if we need to keep the
object around and have new stuff….
... .. in my proposal I had a hard cut
... I suppose it makes sense if we need to keep SVG DOM
ed: I would still go ahead with both,… experimenting with removing SVG DOM and implement the new enum
krit: so you suppoty old enums and the new? where is the benefit for you? complexity stays?
ed: so I will probably remove the old const enums and replace it with new enums
krit: if you break the old one… do you think it is worth still having enums at all? will ppl move over?
ed: seeing where the experiment
goes probably makes more sense
... ok, I’ll bring up the topic again
birtles: proposal was to add a
method to get the points of a path as an array of dicts
... we talked about details in the past… open vs closed
paths
... tow motivations: simplicity
... and performance
... in many implementations there is a perf hit from switching
from JS to native code
... with Cameron’s DOM we get a bunch of dict objects as an
array
... performance is less significant
Tav: can you handle arc?
birtles: approximations
... didn’t work out on details
Tav: how about markers
birtles: doesn’t take markers
into account just path data
... same data structure for setting and getting on path
generation
heycam: are there perf improvements with using types instead of arrays?
birtles: no
... I can still shim and implement it
heycam: do you have comparisons between my proposal and yours?
birtles: we can do that fairly
easy
... seems worth while investigating
... question if we bother at all
heycam: think it is
reasonable
... think the normalization is nice
birtles: we also do not implement normalized path segments in Mozilla
ChrisL: why?
krit: heycam: difficult to keep live objects in synch
birtles: also, it is an array of
arrays
... because of subpaths
krit: I think for normalization
you don’t care too much about precise results, but you want to
have the same amount of segments with the same order
... that is where Opera Presto and WebKit behave totally
different sometimes
shepazu: we should say how a basic shape transforms into a path
heycam: I didn’t do that yet
Tav: we had the discussion at least
krit: didn’t you do that for dash array heycam ?
<Rossen_> can somebody let me into the bldg please
heycam: yes, it would be a reason to support it
shepazu: do you have anything about animating shapes?
birtles: really do want to do that
shepazu: we are not going to make
it perfect :)
... lets pick it up another time
<Tav> http://tavmjong.free.fr/blog/?p=741
action birtles Try implementing path data array and get performance numbers
<trackbot> Created ACTION-3645 - try implementing path data array and get performance numbers [on Brian Birtles - due 2014-08-30].
ISSUE: look into shape morphing
<trackbot> Created ISSUE-2461 - Look into shape morphing. Please complete additional details at <http://www.w3.org/Graphics/SVG/WG/track/issues/2461/edit>.
<heycam> ACTION: Make topic scripts capture actions and issues too. [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action01]
<trackbot> Error finding 'Make'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
<heycam> ACTION: Cameron Make topic scripts capture actions and issues too. [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action02]
<trackbot> Created ACTION-3646 - Make topic scripts capture actions and issues too. [on Cameron McCormack - due 2014-08-30].
<heycam> ACTION: Cameron to add math for Catmull-Rom curves to the spec [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action03]
<trackbot> Created ACTION-3647 - Add math for catmull-rom curves to the spec [on Cameron McCormack - due 2014-08-30].
<heycam> ACTION-3647: https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
<trackbot> Notes added to ACTION-3647 Add math for catmull-rom curves to the spec.
<heycam> ACTION-3640: This should be done for symbol, marker and foreignObject.
<trackbot> Notes added to ACTION-3640 Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0).
<heycam> -- actions session --
<heycam> fg
<ed> bg
<ed> ^C^C^C
<ChrisL> issue-59?
<trackbot> Sorry, but issue-59 does not exist.
<ChrisL> issue-58?
<trackbot> Sorry, but issue-58 does not exist.
<cabanier> scribenick: cabanier
cam: I added a section on Catmull-rom to the spec
<heycam> heyheycam has joined #svg
<heycam> https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand
cam: syntax wise, I added just
what Doug's polyfill said
... you need 3 coordinates
... the curves take a sequence of point and the path goes from
the second control point to ???
shepazu: in my implementation,
the first point is the moveto and the last 2 points are the
same
... technically it needs an extra control point
(lots of discussion at the whiteboard)
shepazu: I suggest that we have 2 point
heycam: I think it should be a minimum of 1 point
shepazu: then it should be a
line
... I agree that it should only be 1 point
heycam: the spec at the moment, if the previous is a moveto...
ChrisL: I think there should be a
minimum of 2. (draws on whiteboard)
... you always need 4 points
... you always go between 2nd and third point
... you make up first and last by doing the tangent
... you always start drawing from the first point
... you can do a fictitious last point
shepazu: the point you start from is the last point from the previous
heycam: it's the current point
ChrisL: yes
... currentpoint is inferred
ed: what would it look like if you do a circle
Tav: would 4 points make a circle?
shepazu: I don't think so?
Tav: how do I close the path?
ChrisL: closepath will be a
straight line
... to do it smoothly we need a different symbol
... which is a new requirement
shepazu: I don't agree
... that is not the point of this
ChrisL: suppose you draw a set of CR pieces, he wants a new command that does the continuity
shepazu: so, I understand what
Tav is asking for but I'd rather not take on that requirement
since it makes the model so complex
... you can do it. we don't have it for beziers
ChrisL: I don't agree. you just get the data differently
shepazu: I would like to split it
into 2 different issues
... CR and the issue of soft closing
... I can see a reasonable additional command that closes
smoothly
... for instance 'y' and possible reuse the catmull rom
algorithm
... we rejected tangient parameter to keep it simple
... we just want point
<krit> RRSAgent: q+
Tav: in order to make a closed
path you might need to choose
... given a circle a, b,c,d you may want to consider point d to
do a smooth close to point a
... you might want to consider d to a, to draw a to b
shepazu: why do you want it to be a circle?
tav: I don't. it can be any shape
shepazu: rather than treat this a
catmull-rom curve, let's call this a smooth closed path
... and it would act differently if it was a bezier
ChrisL: not quite
shepazu: catmull rom is the only one where the previous point changes the next point
(more heated discussion)
heycam: if you have beziers it's not always possible to calculate the point
krit: why does inkscape need it?
Tav: it doesn't
krit: as an implementor, I don't need this and wouldn't implement
ChrisL: are you making an informed decision?
krit: can you do it today with bezier?
ChrisL: given an arbitrary sequence of points can you today make a smooth curve through them?
heycam: yes, we can use beziers.
ChrisL: and the group agreed to do it
krit: that doesn't really matter.
ChrisL: so you don't want new features in SVG?
<Rossen_> The circle of Tav https://onedrive.live.com/redir?resid=DA0535041C44EB4D!26327&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg
krit: I didn't say that?
ChrisL: are you opposed to new features
jwatt: are you against bezier curves?
Tav: it's about authors just
doing smooth graphs
... and I'm against it because it will be used incorrectly
ChrisL: people can do a lot of things wrong
krit: is catmull rom the best
algorithm?
... it's the most known
shepazu: and the easiest to
do
... but it's not trivial to do
krit: but you can do it with bezier unlike with line to approximate beziers
shepazu: I'd like to stay with
the resolution that we'll implement this
... everytime I mention this, people like it
... authors have asked for this
... what is the point of your objection?
... if you have a better implementation, please put it
forward
krit: I think we have primitives to do this.
shepazu: let's not waste f2f time on this
krit: there's no proposal.
... we've discussed this many times already
shepazu: that is inaccurate. you're trying to knock us back
ChrisL: we have a formula and a couple of issues
heycam: I think we should talk about the issues
shepazu: the smooth close path is a separate issue
ChrisL: agreed
shepazu: I would be ok to do a smooth closed path command
tav: inkscape has that problem,
but I don't want to distract
... a smooth bezier to catmull-rom transition
... you can get the first point from the handle
ChrisL: I propose that we'll just
address the issues
... should we add a tension parameter?
resolution: Catmull-Rom will not
add a tension parameter and will stay with the standard
... Catmull-Rom will not add a tension parameter and will stay
with the standard parameters
... should we allow less than three coordinate pairs?
heycam: if you're building up a path, you need them
<shepazu> http://schepers.cc/svg/path/dotty.svg
ChrisL: as long as we define what
it is so we don't get degenerate behavior
... one point is a straight line from the current point
... two points will give you a smooth curve
RESOLUTION: the r command will take at mimum 1 coordinate pair that will draw a straight line
ChrisL: issue 8 is no longer a
problem then
... the moving without drawing anything was solved by the
previous resolution
<ed> (for reference, issue 8 was: "Is it a problem that the command will move then pen from the current position to (x1, y1) without drawing anything? If so, should we made the first control point explicit in the command rather than implicitly taken from the current position? That would then mirror the behavior written above for how the current position is left at the second-last control point.")
heycam: I think it's more about having the implicit points
ChrisL: we now move what multiple
r commands means
... a single r with give you continuity
... by having multiple ones, you will not get the
continuity
shepazu: I don't really like that. it's a bit confusing
ChrisL: if it didn't have that behavior it would act as if it was one command
heycam: I think I prefer that each r is its own smooth curve
Tav: bezier to catmull rom needs a way to break it
ChrisL: can we agree that we don't get continuity
heycam: a new r command will not be continuous with the previous?
shepazu: I agree with that
RESOLUTION: multiple R commands will not have curve continuity between them
ChrisL: issue 9: Where should we
link to for a definition of Catmull-Rom curves so that we don't
have to redefine them here?
... there's a wikipedia with the math
heycam: there were a couple of different options
<ChrisL> http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline
heycam: mostly about the implicit begin and end points
Tav: they're mostly about how to avoid loops
ChrisL: I propose to use the Centripetal one from the wikipedia article
heycam: I think that's a good
idea
... I'm going to read up on it
... do we want the formulation that doesn't introduce the loops
and cusps?
RESOLUTION: catmull-rom will use the formula that doesn't introduce the loops and cusps
Tav: the stackoverflow with the six votes is the one we want
shepazu: can we also put in the spec on how to deform this to beziers?
heycam: we don't have to do
that
... informally, it might be good to have it
shepazu: can we call it 'p' instead of 'r'?
heycam: it doesn't really matter
ChrisL: sure
jwatt: I want more than one letter
ChrisL: people don't really care
heycam: people will just fiddle with it
RESOLUTION: the name of the Catmull-Rom command is 'p' reflecting 'points'
heycam: one final issue is that we should decide that we get the implicit points from the tangent
shepazu: wasn't there a good pdf?
ChrisL: yes, I will drop it in
<ChrisL> http://www.cemyuksel.com/research/catmullrom_param/catmullrom.pdf
heycam: this does limit the set of curves that you can produce
shepazu: I would contend that you're not looking for precision but convenience
heycam: that's reasonable
... so, at the start of the p command and the previous is a
curve, how do you determine the preceding point?
... if it's cubic or quadratic, since we have the control
point, we will use that
... if we don't, we continue the line and use the point from
the same distance
cabanier: do you need to remember an extra point?
heycam: you have to do that
anyway
... to summarize: if you have a previous command other than
'p', the implicit first point is based on the tangent just
preceding the curve
... you always know the one coming in if it's a line or
curve
shepazu: can you come back with a more concrete proposal?
heycam: I'll make an issue in the spec
<heycam> ScribeNick: heycam
jwatt: we have a need that I want
to discuss
... it stems from Firefox OS people who need performance, and
keep memory usage down -- they use icon fonts
... I'd like to move them away from icon fonts towards using
SVG
... I ran through some alternatives to make performance of
SVG-in-<img> enough for their needs
... I think we can get close to that, but one thing they want
is to be able to do what they do with icon fonts
... the color font on the <span> element they apply the
font to, can be used to style the content of the icon
... right now we have no mechanism to do that
ChrisL: not any style across that boundary
jwatt: they want to have a way to
reference out of the SVG to get a computed value
... or pass it in, either way
... they want to do it with CSS selectors, so set a property on
it
... rather than like the params spec, where you have to add
something to the query string or param elements
heycam: why?
jwatt: because that's going to be more convenient to theme things
shepazu: the way I've rethought
parameters, in the context of CSS Variables --
... params consisted of two things. the way to specify how you
pass the things into the file, the second was how to propagate
those values and use them in the file
... they're two separate problems
... I think Variables are probably good enough for the second
half
... I'm proposing we're left with the problem of the behaviour
of passing the values in, and/or having implicit
behaviour
... I don't care if parameters are explicitly declared, or if
you can implicitly extract them from the context
... both seem reasonable to me
krit: my question first is, does
it need to be <img>? can it be <object>?
... <img> has security implications
... the webapps sec wg asked us not to have selectors
... you could change the appearance of things in the document,
and thus time things
... <object> doesn't have these restrictions
... not only timing attacks, but tricking with the
appearance
shepazu: [explains the :visited style restriction]
jwatt: a mechanism other than the document reaching in and styling stuff would be sufficient
shepazu: for the SVG document to be able to say what things change under what circumstance
<ChrisL> itslike passing a bundle of computed style values across the boundary for re-use in styling the image
jwatt: essentially what they need for parity with icon fonts, is to be able to get the computed value of the color property
shepazu: currently in params you
explicitly have a name/value pair
... color=foo, foo=orange
... then in the image you use "foo"
... we could have keywords that say you want to pass in the
color and the background-color, then the SVG file says how to
use those
... my original proposal was saying name/value pairs, but now
you choose the set of values you pass in
... let's say the icon wants to use the background-color of the
page as the foreground color in the image
... and the color from the document as some accent in the
icon
... on the outside you pass in background-color and color
... on the inside you use those two things whereever you need
them
heycam: [explains how context-fill and palette variable work in SVG-in-OpenType fonts]
krit: people want to use @media queries based on width/height. not sure if passing width/height into that would help with that?
Rossen_: you could tie in the vw/vh values to that
shepazu: thinking outside the
icon use case for a second
... [draws a spark line]
... I want to pass in the values in the spark line to the SVG
<img>
... not propose that we do this, but it's the sort of thing you
could allow if you support more than just color passing
in
... two good things about icons, they take on the context size
and color
... but you can't pass in multiple styles, and they aren't
responsive
... if the icon is big I want more detail
krit: does it need to be <img>?
jwatt: for us we want it to be
possible with <img> because we are able to optimize
<img> that we can't do with <object>
... we want to be able to get rid of as much memory as possible
for small devices
birtles: if it's <object> you can do it all in script anyway
heycam: unless it's cross domain
jwatt: our people want parity. so the parameterisation that allows more than just style property mapping sounds like a bigger thing to nail down.
shepazu: I have also heard from
people wanting to use SVG as an icon that at different sizes
you get different crispness things
... when we're trying to solve icons as SVG that's another
thing to discus
<jwatt> https://svgwg.org/svg2-draft/intro.html#TermContextElement
jwatt: is it acceptable to have the context element be the <img> referencing the SVG?
heycam: I would say only if you opt in to that
krit: I agree
ChrisL: so maybe foo.svg#context-fill=currentColor
krit: can we just say the fill and stroke applied to the image? they don't do anything on image
jwatt: it's problematic if you
need an opt in
... well not sure how big a problem
... this person wants to be able to change style sheet to say
all img are fill:red
... he doesn't want to add something to each <img>
element
... I want it to be opt in in the SVG, but not in the embedding
document
shepazu: I think both
... img { context-fill: currentColor; context-stroke: red;
}
p { color: blue; }
<p> <img> ...
jwatt: what about one property
that represents the set of properties that can be
accessed
... you could have a list of the properties
heycam: will-pass-through: color, background-color;
krit: you could also list a custom property
shepazu: "parameters" might be a good name for it
ChrisL: sounds like we have agreement on a principle, can discuss the name
jwatt: what about same origin
<img>s? can we avoid the opt in from the outside?
... what about not having to write { pass-through:
context-fill, ... } for same origin images
... it would be less standardisation effort
shepazu: I'd like this to apply to other cases like <use>
krit: this is one specific use case from a pool of use cases
shepazu: I think the mitigating
factor is that what jonathan is asking for the minimal support
for context-fill use in the <img> document
... this is not going to restrict us from doing more expansive
things in the future
... this is just the simplest case of it
... so it doesn't lock us out of other solutions in the
future
krit: I tend to agree
Rossen_: I'm not sure. I wanted to get back to the opening remarks -- you're after this because of performance and memory pressure from using fonts?
jwatt: no, fonts is good. I want
embedded SVG closer to the performance of fonts.
... this is so they can do theming of icons without having to
go through each icon element
Rossen_: so the performance memory relief will come later on
jwatt: yes that's a different
thing
... if the feature parity barriers are eliminated, then there
is value in us pushing memory usage down
ChrisL: one obvious benefit from icon fonts is you get them all from one file
jwatt: you can use fragment IDs to get that same benefit
<ChrisL> yes, agreed using fragment ids
krit: presumably you share images across documents. is it safe to share these across?
jwatt: that's an implementation
detail for us to make sure it's not possible to get the wrong
images in other documents
... so for now I want to go ahead with same origin
context-fill/context-stroke with <img> being the context
element
shepazu: short of us thinking through that the expanded uses are ok, we can agree that it will be ok with <img> same origin
krit: is there something we need from the HTML WG on this?
heycam: probably not
krit: worried about others saying no after jwatt goes ahead with this
Rossen_: I wouldn't necessarily object to it, I'm just not sure if/how sufficient this is
ed: I agree with Rossen. I've used params myself for passing strings e.g. across, that wouldn't be covered by this
heycam: would we do this for all of the context-* values?
jwatt: would think for consistency it would be all
shepazu: maybe just limit it to context-fill/context-stroke for now
jwatt: I don't think the spec decisions should be driven by Firefox OS deadlines
Rossen_: if the general intent
was to probe the temperature for this, I wouldn't stop with
proceeding
... with your implementation
... push it to your nightlies, tryi t out
... to reiterate your situation, you want to start driving on
perf
... to do this you need to allow this one property
passing
... try it out
... I don't think there's strong pushback
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/no don’t want to do that/really do want to do that/ Succeeded: s/cam/heycam/ Succeeded: s/wikipedia/stackoverflow/ Found ScribeNick: krit Found ScribeNick: cabanier Found ScribeNick: heycam Inferring Scribes: krit, cabanier, heycam Scribes: krit, cabanier, heycam ScribeNicks: krit, cabanier, heycam Present: Rossen Jonathan Chris Doug Erik Cameron Tav Dirk Rik Nikos Brian Konno Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda Got date from IRC log name: 23 Aug 2014 Guessing minutes URL: http://www.w3.org/2014/08/23-svg-minutes.html People with action items: cameron make WARNING: Possible internal error: join/leave lines remaining: <heycam> heyheycam has joined #svg WARNING: Possible internal error: join/leave lines remaining: <heycam> heyheycam has joined #svg[End of scribe.perl diagnostic output]