SVG Working Group Teleconference -- 26 Jun 2014

<trackbot> Date: 26 June 2014

<Smailus> who is on the phone

<scribe> ScribeNick: birtles

<scribe> Scribe: birtles

Proposal: Remove altGlyph, altGlyphDef, altGlyphItem and glyphRef from SVG2

ed: I sent to the mailing list tests which I ran on all the different browsers I could find

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0084.html

ed: this test was to verify that altGlyph doesn't work on normal fonts that are not SVG fonts
... I couldn't find any browser that did that
... the only browsers that supported altGlyph only did so for SVG fonts
... so since we're removing SVG fonts it makes sense to remove these as well

heycam: makes sense to me

ed: if you look at the test itself
... I wasn't sure how to reference glyph IDs so I used various ways
... but none of them worked

heycam: it might have interesting the spec actually said what the syntax was for referencing glyphs from different font formats

ChrisL: I don't think there is an approved way of pointing into a table in a binary font format
... that syntax was only ever intended for SVG fonts

heycam: anyone against removing these from SVG2?

(silence)

RESOLUTION: We will remove altGlyph and company from SVG2

<ChrisL> +1

Smailus: I agree

<scribe> ACTION: Erik to remove altGlyph and company ffrom SVG2 [recorded in http://www.w3.org/2014/06/26-svg-minutes.html#action01]

<trackbot> Created ACTION-3632 - Remove altglyph and company from svg2 [on Erik Dahlström - due 2014-07-03].

How should the following two SVGPathElement methods work when there's no path data?

ed: I did what we discussed on the last call and posted to the mailing list with various options from the browsers

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0126.html

ed: I listed a bunch of different proposals
... the email thread also had a few more suggestions
... for the first one, getPointAtLength, that returns an SVGPoint
... one suggestion from Dirk was to return undefined

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0132.html

krit: or null? does nullable return undefined or null?

heycam: returning undefined is a bit difficult from IDL
... it doesn't really happen in other APIs, generally we return null
... I would suggest that over undefined

ed: would that be stringified to 0... ?

heycam: I would suggest we change the IDL to SVGPoint? so that null can be returned as is

<krit> null

ed: so if you're expecting to get an SVGPoint back you'd have to check the return value point for

heycam: sorry, I was referring to the other method
... last time I think we discussed the pros and cons of objects with NaN members vs returning a null value
... if the object has NaN values the code would probably continue further but it might make it harder to track down problems later
... anyone prefer NaN x/y values?

ed: Dirk suggested in the mail that that might be ok

<krit> I am fine with null or SVGPoint(NaN, NaN)

Smailus: I prefer making something clearly an error

krit: if you search GitHub for these two methods you won't find any results except test cases

<ChrisL> agree, returning a potentially valid value is suboptimal (even if a second call can disambiguate it)

krit: to give you an idea how important they are

birtles: I slightly lean towards SVGPoint(NaN, NaN) but null may be ok too

<krit> https://github.com/search?q=getPointAtLength+extension%3Asvg&type=Code&ref=searchresults

heycam: Tab mentioned that there's a similarity with getBoundingBox
... in the end we settled on making getBoundingBox on an empty group return rect(0, 0, 0, 0)
... but if you called getBoundingBox on a parent of that, that 0 point wouldn't contribute to the parent's bbox

Smailus: so that's an argument for returning 0 to keep things consistent

ChrisL: there's many different things we could be consistent with

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0140.html

ed: Tab also mentioned that it's not defined if you use an distance larger than the lenght of the path

heycam: and for getPointAtLength you could use a length greater than the length of the path
... Tab said in that same mail that if you defined what happened if you passed in a length that's too large then you probably would use the same behavior
... I'm inclined for it to be 0,0 if there's no path data

Smailus: I support that

<ChrisL> ok

<ChrisL> ok but we need to include an example of that check, in the spec

heycam: you'd still need to check if there's any path data to disambiguate between 0,0 due to no path data or do to actually being 0,0

shepazu: you'd have to add a check either way
... whether that be an exception or whatever
... but it depends what is common practice these days

<nikos> for getPointAtLength it makes sense to me to return 0,0 when there's no path data as that is within the bounding box

<ed> proposal: if you pass a distance longer than the path -> return the last point on the path, if negative/zero distance -> return the first point on the path

shepazu: we should put and issue with the rationale in the spec so that when we go to LC we can get feedback on this
... we could outline both approaches

heycam: I'd be happy with an issue
... I think WebGL or some other API has a tendency for things to go to NaN

ChrisL: I agree with Doug about putting it in the spec as an issue
... then we can get feedback

<ChrisL> yes, its fine

heycam: so for the interim shall we go with 0,0?
... plus an issue outline the alternatives and rationale

RESOLUTION: getPointAtLength will return a 0,0 point if there is no path data and we will add an issue about this to the spec

ed: and when the distance is longer than the path length or negative then we use the last point / first point on the path as appropriate

heycam: you clamp the input length value to [0, length of path]

ed: the second method is getPathSegAtLength
... which returns an index to a path segment
... that currently returns an unsigned long in the IDL

krit: Rik would prefer to make it unrestricted double and return NaN when there is no path data
... I would prefer null

heycam: what about doing something like getPointAtLength where you clamp the value so you either return 0 or the last path segment?

(someone): agreed

heycam: krit what do you think?

krit: how does it compare to getPointAtLength?

heycam: it's similar in that you clamp the result at the end of the existing path
... so you clamp to the first / last segment of the path
... getPointAtLength clamps to the start / end point of the path

ed: it's only really strange when there is no real first segment if you want to be able to distinguish that case

heycam: but you can look at pathData.length or whatever it is to see if there are any actual segments

ed: yeah, that's fine, I'm ok with that

heycam: I think the same arguments apply as well where you might be doing some calculations and there's some error where you've gone just past the end of the path
... the calculation shoudn't get corrupted from that

RESOLUTION: getPointAtLength and getPathSegAtLength with clamp their input to be at the start / end of the path appropriate and so always return a valid point / path segment index

<scribe> ACTION: Erik to add text for getPointAtLength and getPathSegAtLength to describe behavior when there is not path data or when the index/length is beyond the ends of the path [recorded in http://www.w3.org/2014/06/26-svg-minutes.html#action02]

<trackbot> Created ACTION-3633 - Add text for getpointatlength and getpathsegatlength to describe behavior when there is not path data or when the index/length is beyond the ends of the path [on Erik Dahlström - due 2014-07-03].

Filter effects and blend modes for feBlend

krit: I was looking into it in WebKit and it was very easy implement all blend modes for feBlend
... I also checked with Vlad from Mozilla and he suggested it was easy to do with Moz2D / Direct3D
... I suggest we add all blend modes to SVG
... to unify across canvas/CSS/SVG

heycam: does canvas use different keywords for blend modes to SVG?

krit: no

heycam: is this for level 2 of filters?

krit: no for the current level

heycam: what is the status of the spec?

krit: there are still issues about filter regions and it still needs detailed review
... and the animation part needs cleanup

heycam: I'm happy with adding the remaining blend modes now

RESOLUTION: Add all the additional modes specified for the CSS property to feBlend

<krit> http://dev.w3.org/fxtf/compositing-1/#ltblendmodegt

heycam: are these the ones in PDF?

ChrisL: so long as the equations are in a W3C spec

heycam: are we adding keywords supported by the property but not in SVG? or adding keywords to the property?

krit: I'm adding hue, saturate etc. etc. which are already on the CSS property but not yet supported by feBlend

heycam: does PDF define additional modes?

krit: maybe. And Photoshop have more still
... but initially we wanted to stick with widely-supported blend modes

<ChrisL> yes

RRSAgent: make minutes please

- DRAFT -

SVG Working Group Teleconference

26 Jun 2014

Attendees

Contents

Proposal: Remove altGlyph, altGlyphDef, altGlyphItem and glyphRef from SVG2

How should the following two SVGPathElement methods work when there's no path data?

Filter effects and blend modes for feBlend

Summary of Action Items

Scribe.perl diagnostic output