W3C

- DRAFT -

SVG Working Group Teleconference

19 Jun 2014

Agenda

See also: IRC log

Attendees

Present
krit, [IPcaller], ed, birtles, nikos_, Doug_Schepers, stakagi, ChrisL, cabanier, Tav
Regrets
Chair
ed
Scribe
Nikos

Contents


<trackbot> Date: 19 June 2014

<heycam> Zakim: [ is me

<scribe> scribenick: nikos_

<scribe> scribe: Nikos

Describe <cursor> in terms of cursor property, similar as HTML does for <font>?

ed: Dirk you got a response on the ml. does it address the question?

krit: I think it does

ChrisL: url form wasn't widely implemented and tended to be platform specific. We wanted to support standard graphics format. At the time there wasn't an x and y on the cursor property. So we added an element that allowed x and y to be specified
... since then x and y was added to the property, but spec wasn't updated
... picked up recently
... current definition in CSS means we probably don't need cursor element in SVG
... I was making tests today
... from my testing IE still only supports .cur files and nothing else
... FF supports png with x and y but x and y must be < 32
... which isn't in the spec
... and there needs to be a fall back or image won't be displaed
... need to test on other browsers
... I sent to the zip to the mailing list
... I'm hoping that we can drop the element from SVG

heycam: Do you know what implementation status is of cursor element?

ChrisL: you'd need to look at the 1.1 test suite
... we did have tests for that
... including a test for a raster file
... we have a direction here but not enough data to make a decision right now

krit: webkit and blink do support property and the element
... and are using kind of the same code path with the exception of the SVG DOM

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0079.html <-- tests are attached to here

<heycam> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/interact-cursor-01-f.html

<ThomasSmailus> FYI, I'm on chat only.

heycam: I just dropped a link to test in 1.1 test suite
... the relevant one is the bottom right rectangle
... just tried in FF and Chrome and it's showing the fallback

krit: does work in webkit
... not sure why it doesn't work in Chrome

ChrisL: I think it disappears on the middle spot because it's an anchor
... probably not a great test because the image looks like a standard cursor

krit: a crosshair means the test is not passing
... the image is something else
... should be a magnifying glass
... I don't think the cursor element is very popular anyway

ed: do we want to resolve on anything now?
... or wait for more testing?

krit: I don't want to deprecate it, I just want it to be the same as the cursor property

ChrisL: I don't see anything to change in the spec unless we decide to delete the whole element
... which might be a long term goal

shepazu: one thing we could change - cursor property requires you point to a cursor element
... we could allow it to point to an arbitrary element in svg

ChrisL: how would that help?

heycam: currently the cursor element doesn't allow graphical elements inside it
... requires href

ChrisL: given property allows the hotspot to be set I don't think we need this element at all

ed: I agree

ChrisL: and it should be possible to point to some svg fragment

krit: css3 ui spec I think only allows images

ChrisL: it's a uri and svg is an image

krit: I'm saying the css 3 ui spec doesn't allow a cursor property to reference a cursor element

ChrisL: can you give a reference in the spec?
... <quotes spec>
... seems to allow referencing the cursor element

heycam: it's a bit wishy washy though

ChrisL: it just mentions resource... doesn't have to be a raster
... so do people agree we should do more testing and long term remove the element?

krit: yes and yes

<ThomasSmailus> remove which element?

ChrisL: I also think we should be pushing for png to be used more widely as the raster format

<ChrisL> and svg as the vector format

Last Call for Geometry Interfaces

<krit> http://dev.w3.org/fxtf/geometry/

krit: This spec is mostly unchanged

<ChrisL> has there been much review?

<ThomasSmailus> If the cursor property completely replicates the cursor element, then its ok with me; we (for techincal diagram applications) need the ability to change the cursor in the image, to reflect a 'state' the SVG diagram is in.

krit: there were some changes in the naming translateBy -> translateSelf

<ChrisL> implementations?

krit: it's more descriptive
... changes in is2D()
... the rest stayed unchanged with some bug fixes
... the editors think it's ready for LC

<heycam> ThomasSmailus, yes, the cursor property should be able to do everything you need without the need for the <cursor> element as well

ChrisL: is there any implementation and have you had much review?
... I saw fantasai say it was going to fast
... so have people looked at it ?

krit: FireFox implements most parts of it
... and source code was reviewed
... I'm looking at implementing in WebKit
... we've created a test suite and published initial tests

<ChrisL> in that case, +1 to LastCall now

krit: will publish more tomorrow

heycam: I haven't looked since last week
... but I assume you made changes we discussed?

krit: I did

ed: I sent one comment which needs to be addressed. But not opposed to going to LC

krit: I think your comment needs to be addressed more in the context of SVG
... we can talk about it next week

heycam: in IDL for DomRectList I think you shouldn't use Array class there
... we need to overhaul how they will work in the DOM
... so you should hold of using for the moment

krit: what are the issues?

heycam: makes an object that is kind of like an array but not quite
... and I think most are opposed to the idea
... so just remove [Array Class] on DOMRectList interface for now

krit: I'll do that before publishing then
... Mozilla currently implements with [Array Class]
... hopefully they can change

RESOLUTION: Publish Geometry Interfaces Last Call pending removal of [Array Class]

ChrisL: we also need CSS WG to make a decision as well right?

krit: yes

<heycam> http://lists.w3.org/Archives/Public/www-style/2014Jun/0233.html

Should altGlyph's xlink:href be restricted to document-local references?

ed: this came up in a discussion about referencing
... and going over which svg elements can reference external content
... Anne is fixing up some fetching spec hooks for svg
... we weren't sure about this element

krit: working on fetching model for svg that can be used on all elements.
... Erik noted that he wants to be able to select an element from a document using a url fragment
... and wants to support this for css image
... there is the question of what security model do you have in place of objects referencing outside the document
... we want to have the same model for resources of image
... elements could cross reference other elements from other documents. FF does this already.
... as Erik pointed out some elements can only reference within the document
... this restriction does not apply in FireFox
... we think we can do the same fetching model for resources and images for all elements
... so all elements could reference outside of the current document
... would make spec much simpler and unify implementations
... my point is that we should not force elements to just reference within the same doc

ChrisL: I agree that's a good idea
... in svg we didn't use bare fragment identifiers
... we made it a uri so if it was restricted in one version it was easy to update
... overall I think the decision of whether it points inside a doc or not was a bit arbitrary
... so in general I think your plan is a good one

ed: my question about altGlyph in particular is because we removed SVG fonts from SVG 2
... makes it a bit difficult to use altGlyph
... multiple steps will be required to do what you want
... doesn't seem like good design

heycam: do we want to keep altGlyph around?
... does anyone implement it ?

ChrisL: in some sense CSS fonts has replaced it
... think that's a better way to go than altGlyph

heycam: I agree
... we had a discussion in Sydney talking about a replacement feature for specific glyphs of a font
... and all the issues you'd have with the x and y list of numbers
... if we had that feature at some point in the future
... then I think that would be the way to go

shepazu: some people are using altGlyph - we got an email from decotype
... who are using it to render arabic glyphs in a way that is combinatorial in arabic
... which you can't do in the font file

ChrisL: yeah
... the way they're doing it you can't do in opentype

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

ChrisL: there does need to be a way to say use glyph index xxx
... it's not clear that CSS3 lets you do that
... say this particular span of text uses these specific glyphs

heycam: going back to the external reference. I think it makes sense to allow most of those things to load up an external document
... but I'm wondering about the animation element?
... should that be allowed to target a resource document?

krit: they could. the question is what happens?
... we'd need to specify what happens when an external document is referenced
... could just make it have no effect

heycam: but you'd still need to fetch which is the important thing
... I think it would be ok to do that

ed: I'm not against allowing altGlyph to reference externally but I think we should consider a better method of supporting that functionality

heycam: I don't think anyone implements it

<ChrisL> opera presto did. Not the blink based one though

ed: Opera Presto did but only for SVG glyphs
... I'm happy to create some tests to verify

heycam: if we think it's the right thing to do then it would be good to demonstrate that it's not implmement
... I think we want a replacement for altGlyph at some point

<scribe> ACTION: Erik to write tests to determine whether altGlyph is implemented [recorded in http://www.w3.org/2014/06/19-svg-minutes.html#action01]

<trackbot> Created ACTION-3631 - Write tests to determine whether altglyph is implemented [on Erik Dahlström - due 2014-06-26].

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

ed: these methods don't describe what to do if there is no path data

ChrisL: is it feasible to raise an exception or return NaN?

ed: it's possible but not spec'ed. THe methods don't currently throw

<ChrisL> 404 Path Not Found

<heycam> null or NaN?

krit: were there concerns on the mailing list about returning NaN?

<heycam> new DOMPoint(NaN, NaN)

heycam: some people like NaN because the function can keep going
... others prefer it to stop working immediately and not continue with arithmetic

<ChrisL> new NyanCat (Nan, Nan, Nan, Nan, Nan, Nan, Nan, Nan, Nan, Nan, Nan)

krit: alternative is to throw an exception

heycam: I think throwing exception and returning null are pretty similar in terms of the function stopping because most won't check for null return values

<ed> for reference, the two methods being discussed: getPointAtLength and getPathSegAtLength

heycam: I'm talking about the one that returns a DomPoint
... getPointAtLength
... Erik did you check what implementations do at the moment?

ed: no

cabanier: getPathSegAtLength should return NaN and getPointAtLength should return null

krit: In WebKit we return 0 for getPathSegAtLength and (0,0) for getPointAtLength
... think Blink would be the same

heycam: we were talking about bounding boxes recently and for elements with no geometry did we decide to return a (0,0,0,0) bounding box?

nikos: we did

heycam: so maybe we should be consistent with that?

cabanier: it feels different to that

heycam: I don't have a strong opinion on this but would like to know if there's consensus among implementations

cabanier: Mozilla throws an exception I think

krit: that should change

<heycam> http://mcc.id.au/temp/p.svg

krit: would getPathSegAtLength throw?

heycam: here's a test

<heycam> Firefox - exception, 2**32-1

krit: it seems we have different behaviour across browsers
... can someone test IE?

<ed> opera presto says "undefined" for getPathSegAtLength

nikos: unexpected call to property or method on IE10

krit: getPathSegAtLength returns 0 on IE

heycam: so everyone is slightly different

ed: I think returning DomPoint(0,0) and 0 would be fine

krit: I don't mind

ChrisL: if you return that how can you tell the difference missing path data or a valid index?

heycam: you could try to index into the pathSegList
... is it a common enough that that we need to worry about it?

ed: is there an agreement on what should happen? should we take it to the list?

krit: take it to the list and pick it up next week?

<krit> http://www.w3.org/TR/css-masking-1/

Publish CR for CSS Masking

krit: there hasn't been feedback for four weeks and LC period ended today

ChrisL: no comments at all?
... was there actually a review?

krit: we got a lot of comments in the first LC and on the working draft
... but no comments on recent LC

ChrisL: sounds fine then. You can go to CR in that case

RESOLUTION: Publish CSS Masking CR

Summary of Action Items

[NEW] ACTION: Erik to write tests to determine whether altGlyph is implemented [recorded in http://www.w3.org/2014/06/19-svg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/06/19 13:59:57 $

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 http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/webkit do support/webkit and blink do support/
Succeeded: s/stuff/spec hooks for svg/
Succeeded: s/piont/point/
Succeeded: s/return a number/return NaN/
Found ScribeNick: nikos_
Found Scribe: Nikos
Default Present: krit, [IPcaller], ed, birtles, nikos_, Doug_Schepers, stakagi, ChrisL, cabanier, Tav
Present: krit [IPcaller] ed birtles nikos_ Doug_Schepers stakagi ChrisL cabanier Tav
Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Jun/0062.html
Found Date: 19 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/19-svg-minutes.html
People with action items: erik

[End of scribe.perl diagnostic output]