- From: Chris Lilley <chris@w3.org>
- Date: Thu, 19 Jun 2014 16:03:01 +0200
- To: SVG public list <www-svg@w3.org>
Hello,
Minutes at
http://www.w3.org/2014/06/19-svg-minutes.html
and below as text for bots
SVG Working Group Teleconference
19 Jun 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0062.html
See also: [3]IRC log
[3] http://www.w3.org/2014/06/19-svg-irc
Attendees
Present
krit, [IPcaller], ed, birtles, nikos_, Doug_Schepers,
stakagi, ChrisL, cabanier, Tav
Regrets
Chair
ed
Scribe
Nikos
Contents
* [4]Topics
1. [5]Describe <cursor> in terms of cursor property,
similar as HTML does for <font>?
2. [6]Last Call for Geometry Interfaces
3. [7]Should altGlyph's xlink:href be restricted to
document-local references?
4. [8]How should the following two SVGPathElement methods
work when there's no path data?
5. [9]Publish CR for CSS Masking
* [10]Summary of Action Items
__________________________________________________________
<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>
[11]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0079.ht
ml <-- tests are attached to here
[11] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0079.html
<heycam>
[12]http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlOb
jectApproved/interact-cursor-01-f.html
[12] 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> [13]http://dev.w3.org/fxtf/geometry/
[13] 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>
[14]http://lists.w3.org/Archives/Public/www-style/2014Jun/0233.
html
[14] 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>
[15]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.ht
ml
[15] 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
[16]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> [17]http://mcc.id.au/temp/p.svg
[17] 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> [18]http://www.w3.org/TR/css-masking-1/
[18] 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
[19]http://www.w3.org/2014/06/19-svg-minutes.html#action01]
[End of minutes]
--
Best regards,
Chris mailto:chris@w3.org
Received on Thursday, 19 June 2014 14:03:06 UTC