- From: Chris Lilley <chris@w3.org>
- Date: Mon, 10 May 2010 18:04:01 +0200
- To: www-svg@w3.org
Hello www-svg,
Minutes at http://www.w3.org/2010/05/10-svg-minutes.html
and below as text for tracker
SVG Working Group Teleconference
10 May 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html
See also: [3]IRC log
[3] http://www.w3.org/2010/05/10-svg-irc
Attendees
Present
ed, ChrisL, anthony, jwatt, Patrick
Regrets
Chair
SV_MEETING_CHAIR
Scribe
patrickd
Contents
* [4]Topics
1. [5]Use and CSS selectors
2. [6]second edition updates
* [7]Summary of Action Items
_________________________________________________________
<trackbot> Date: 10 May 2010
<ed> trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 10 May 2010
<scribe> scribenick: patrickd
<ed> Agenda:
[8]http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063
.html
[8] http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html
Use and CSS selectors
<ed>
[9]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/struct-use-hover.sv
g
[9] http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/struct-use-hover.svg
<ed>
[10]http://lists.w3.org/Archives/Public/www-svg/2010May/0006.html
[10] http://lists.w3.org/Archives/Public/www-svg/2010May/0006.html
patrickd: in terms of the <use> and css selectors, we see that in
the test each browser has a different behavior
ed: spec says that use instances are not part of the DOM tree
... Would be OK with going with something in SVG 2.0 specification
CSS2 selectors can be applied to the
original (i.e., referenced) elements because they are part of the
formal
document structure. CSS2 selectors cannot be applied to the
(conceptually)
cloned DOM tree because its contents are not part of the formal
document
structure.
patrickd: that part of spec, indicates that none of the styles
should apply to use instances
... which means that webkit has it right
ed: webskit just appears to have some refresh bugs perhaps
... Think opera has it implemented as it's specced in SVG 1.1; Opera
is applied to the original but not the shadow instances
ChrisL: Shadow tree is not addressable through selectors
... Firefix expands things into place; so things that are there
should not be there
ed: use can sometimes propegate the style into the use tree
patrickd: where would we go with this in SVG 2.0
ed: Add new kind of <use> element, or add attributes controlling
whether or not it applies to <use> or shadow trees
ChrisL: It's a change to the underlying model; if the DOM is there
vs. the DOM is not there.
... Current model is that you cannot select shadow tree elements; it
sounds like extra selectors
patrickd: Or a slector synta
... What is this for?
ChrisL: A lot of grahics libraries have symbol libraries; the
decision was made that we weren't going to have pre-built symbols.
This was the basic use case. Re-usable stuff
... The thing that it misses; there is only one instance in the
document tree; you can change the original copy and all of them
change, e.g.
... But you can't but a 'handler' on an instance.
... But these are SVG 2.0 changes
patrickd: How you fix this in SVG 2.0 without backwards
compatability
ChrisL: Introcue new element, replaced in place as reference instead
of shadowed.
... A little bit like using XSLT or XBL in place.
patrickd: What I will do is update that test to reflect the spec'd
behavior
<ed> ISSUE-2323?
<trackbot> ISSUE-2323 -- Consider aligning SVG*List interfaces with
other arraylike types -- RAISED
<trackbot> [11]http://www.w3.org/Graphics/SVG/WG/track/issues/2323
[11] http://www.w3.org/Graphics/SVG/WG/track/issues/2323
<ChrisL> Topic; ISSUE-2323
ed: Was going over making tests for SVGElementInstance and found
some minor inconsistencies on how we define our list interfaces
... Ify you compare them to the array syntax in ecma script, we
differ quite a bit
... Some of our list interfaces use getItem; while nodeList you use
item; which also allows you to use the array interface
ChrisL: Did this come across because we specified it in IDL and then
ecmascript came later?
ed: Probably some historic reason for it. Just noticed the
SVGElementantInstanceList is the same as NodeList, but all others
use getItem.
... No length accessor; etc; there is the number of items; it makes
it harder to use
... Would like to align this with nodeLists for SVG 2.0 and we alias
the numberOfItems property with length
patrickd: So make them consistent within and with ecmascript array
ed: Do we want to keep list interfaces is the follow on question
... we do have code that will support this and we could put in place
pretty fast
ChrisL: Do you see this a problem
JW: It's a nightmare; I have used this many times in the wrong way
patrickd: What does it mean to have a change vs. a new feature in
SVG 2.0?
ChrisL: If it is spec'd accordingly, then both versions will work
but it is a higher cost implementing
patrickd: So because you want to have it work both ways, there may
be a higher cost to implement it
... On the general subject of SVG 2.0, what to do about version
number? Does this control behavior?
ChrisL: We tentatlively tried it but then backed off
<ChrisL> hasFeature is sort-of great
ed: hasFeature is not really working well?
... There are some slight differences in how far an implementation
actually implement it
ChrisL: Granularity are too coarse and too fine, differently across
browsers
ed: e.g. Firefox does support filters, but the hasFeature does not
indicate that they do
jwatt: Perhaps we should change that and just state that it's
supported
... Hard to tell when the spec doesn't say or even give advice on
hasFeature
ed: In my experience, when I want to see if something works, I want
to check DOM interface existance
... hasFeature isn't reliable enough
patrickd: But what about hasFeature with <switch>
... HTML should potentially incorporate this'
... we need to have the high level SVG 2.0 vision and the high level
backward compatability story first
ed: People will run into more pain without having this new feature
than they would otherwise
patrickd: I disagree; because if they discover that it works one way
in one browser, they will still have to code it differently for the
other browser anyway
ed: In a way you are right; there will be libraries that cover that
small difference
... I think going forward, it will be better to make everything
consistent. It doesn't change what's there, it just adds new stuff.
ChrisL: I think you need to write a whitepaper on future proofing
and backward compat principles
jwatt: Our biggest problem on identifying change impact, is we don't
have any indication of how much it is use on the web
... It would be great if MIcrosoft had a method of geting
information about usage
patrickd: It would seem that we could contribute there, but we are
caught with limitted SVG assets today, vs. what we will see in a
year or so
ed: Opera's system should still be available as well
<scribe> ACTION: patrickd: Write a whitepaper on versioning, future
proofing, backward compatability and SVG 2.0 [recorded in
[12]http://www.w3.org/2010/05/10-svg-minutes.html#action01]
<trackbot> Created ACTION-2782 - Write a whitepaper on versioning,
future proofing, backward compatability and SVG 2.0 [on Patrick
Dengler - due 2010-05-17].
ed: Still would like to make the change
<scribe> ACTION: ed: Write up new list interface proposal and submit
test cases for SVG 2.0 [recorded in
[13]http://www.w3.org/2010/05/10-svg-minutes.html#action02]
<trackbot> Created ACTION-2783 - Write up new list interface
proposal and submit test cases for SVG 2.0 [on Erik Dahlström - due
2010-05-17].
second edition updates
<ed> [14]http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2
[14] http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2
patrickd: I will review the struct-dom tests on the wiki
ed: Anthony, do we have new tests that you reviewed?
<ChrisL> anthony?
<ed> shapes-polyline-02-t.svg
<ChrisL> shapes-polygon-02-t.svg
<ChrisL> shapes-grammar01-f.svg
<ChrisL> shapes-grammar01-f.svg passes in batik, opera - fails in
firefox
<ChrisL> new test in the last couple of hours
<ed>
[15]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-grammar01-f
.svg
[15] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-grammar01-f.svg
patrickd: I will review this one as well
ed: Can we mark the reviewed as accepted?
ChrisL: Yes, I will do it now
... Those need to get added to the tests, but not the errata.
... I proposed some wording in email. Link incoming
<ChrisL>
[16]http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/006
4.html
[16] http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0064.html
patrickd: All agreed that new language around contentTypeStyle is
good, so chrisl will check in
<ChrisL>
[17]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/styling-elem-02-b.
svg
[17] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/styling-elem-02-b.svg
ChrisL: Might be easier to remove the test
patrickd: I say remove i
<ChrisL> resolved: remove styling-elem-02-b.svg
ed: New Topic semi-colon separator
<ed>
[18]http://www.w3.org/mid/201005061734.12398.Dr.O.Hoffmann@gmx.de
[18] http://www.w3.org/mid/201005061734.12398.Dr.O.Hoffmann@gmx.de
ed: Can SVGFragmentIdentifiers be animated with using semi-column
without esacping it
ChrisL: Should modify this such that animated semi-color separated
attributes required to be escaped
ed: We should get a proper test case for it
<scribe> ACTION: ed: Create Test Case for Animating
SVGFragmentIdentifier [recorded in
[19]http://www.w3.org/2010/05/10-svg-minutes.html#action03]
<trackbot> Created ACTION-2784 - Create Test Case for Animating
SVGFragmentIdentifier [on Erik Dahlström - due 2010-05-17].
<ChrisL> escape the ; with an NCR and use the same test we use for
viewbox meet and slice
patrickd: Cancelling SVG WG Telecon because of holidays
<ChrisL> patrick are you ok witj making minutes and sending them
out?
Summary of Action Items
[NEW] ACTION: ed: Create Test Case for Animating
SVGFragmentIdentifier [recorded in
[20]http://www.w3.org/2010/05/10-svg-minutes.html#action03]
[NEW] ACTION: ed: Write up new list interface proposal and submit
test cases for SVG 2.0 [recorded in
[21]http://www.w3.org/2010/05/10-svg-minutes.html#action02]
[NEW] ACTION: patrickd: Write a whitepaper on versioning, future
proofing, backward compatability and SVG 2.0 [recorded in
[22]http://www.w3.org/2010/05/10-svg-minutes.html#action01]
[End of minutes]
--
Chris Lilley mailto:chris@w3.org
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Received on Monday, 10 May 2010 16:04:55 UTC