RE: Minutes, 26 January 2011 SVG WG telcon

http://www.w3.org/2011/01/26-svg-minutes.html


- DRAFT -
SVG Working Group Teleconference

26 Jan 2011
 Agenda

See also: IRC log

Chair: Cameron
Scribe: Adrian

Contents

Topics
1. 1.1 progress
2. pointer events
3. test suite
4. rechartering
5. f2f
6. stroke-linecap on zero-length subpaths

Summary of Action Items

--------------------------------------------------------------------------------




<trackbot> Date: 26 January 2011

<scribe> scribenick:adrianba

<heycam> Scribe: Adrian

shepazu: people think we're not going to keep svg fonts in svg
 ... i don't remember deciding this

heycam: i don't remember that either

ed: i think we talked about moving to a separate specification

1.1 progress

heycam: don't think we need to spend too much time on this - haven't seen much progress on actions

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Remaining_work_for_SVG1.1F2


<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/filters.html#FilterPrimitiveSubRegion


<ed> ‘x’, ‘y’, ‘width’ and ‘height’ act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result.

ed: not a very big change
 ... i think that's enough to satisfy the concern that was raised in the first place
 ... the other change related to ISSUE-2334 was made in a separate commit
 ... my action is done and in review
 ... i think i need to send another e-mail about this

shepazu: what is blocking us moving forward with second edition

heycam: a couple of actions due for the spec itself
 ... more work is for the implementation metrics and making sure we don't have tests that don't have 2 passing implementations

shepazu: the change i'm working on, we agreed that we weren't going to add any tests, that's not a blocking action right?

heycam: it's not blocking on conversations

shepazu: obviously it's blocking in that we have to do it before we publish the spec but it's not blocking anyone else, no tests that we need to do?
 ... how long do we estimate that it will take do do everything?
 ... i ask because the issue of rechartering came up and we need to have a real estimate of when we'll be done
 ... i said one month but that might be optimistic

heycam: that sounds possible

ed: i think so too

heycam: that aligns with the f2f too

shepazu: okay, we said we didn't want to carry 1.1 work into new charter

heycam: there's not that much to do

shepazu: i'll do my action this week
 ... at the end of the telcon i want to talk about rechartering

heycam: related to your action, i saw mail from tantek - can't remember the details - something to do with pointer events and css rules
 ... seems to be exactly addressing this issue of pointer events
 ... only other actions are on anthony and chris who aren't here

pointer events

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2011Jan/0043.html


ISSUE-2364?

<trackbot> ISSUE-2364 -- Last Call Comment: SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2364


heycam: doug did you read through this mail?

shepazu: i skimmed it too, i see what he's saying

heycam: he wants to support both modes when the pointer is captured on the background

shepazu: i think we resolved to punt this in v1.1 and consider in svg integration spec and svg 2.0
 ... there's a part i need to follow up but i don't think this is a blocking issue for v1.1

heycam: so this comment isn't going to block us?

TB: i was trying to do a button using svg with fallback to png and i couldn't get this to work

<shepazu> is/??:/tav:/

heycam: this might be a slightly different issue - this is if you click on a region that doesn't coincide with the image
 ... like the transparent part

tav: okay, i thought i'd be able to use svg like a png but it didn't work

shepazu: good use case - think there are some issues to work out how html integrates with svg
 ... once we do v1.1. and move on then there will be issues around integration we can deal with

ed: sounds like svg params

shepazu: not sure, think there will be lots of issues we need to handle

heycam: so this issue we can bring up in the task force

tav: okay, so for now i can't do what i wanted to do

heycam: i'd be surprised if it's not possible - maybe we can take offline

shepazu: think it would be a good idea to discuss at some point - let's finish up this topic as it affects finishing this spec
 ... so we're not going to address the integration with html in v1.1 but we're going to address soon after
 ... for the specific thing from tantek, that's a possible way forward and we'll need to decide upon the defaults
 ... and the defaults are different in different UAs but if we're able to address all different use cases then it's less of an issue
 ... we just need to decide which defaults are correct
 ... my immediate issue is the paragraph about event propagation
 ... partly conflates separate issues

ISSUE-2396?

<trackbot> ISSUE-2396 -- Distinguish between the rendering area of an element and its interaction area -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2396


shepazu: we basically don't talk about the rendering area and the interaction area but it is a concept implicit in svg
 ... want to talk about whether introducing this concept for pointer events and hit testing

heycam: so in the definition of pointer events at the moment it talks about visible fills and the geometry - all of those regions you'd encapsulate in this?

shepazu: not in v1.1 - just explain that pointer events changes interaction area of a shape

heycam: you mean it's defined already and you want to give a name to it?

shepazu: yeah, i want to make sure implementers are happy it's a reasonable distinction to make
 ... i guess i'll go ahead with it and you can decide if it's reasonable

heycam: as part of this action?

shepazu: yes
 ... i'll be talking about event propagation and hit testing - the main question is does the svg root intercept pointer events and i believe that's what we decided to punt on in svg 1.1
 ... should i say it will be addressed later or not mention it?

heycam: i think you should call it out
 ... addressing the issue was about whether pointer events affect these elements and if the answer is we're not deciding yet then pointing that out is part of the action

test suite

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html


heycam: here's the implementation matric - we're down to 30 tests that don't have two implementations
 ... better than before but not zero
 ... we need to know whether we'll have other implementations in the report and if so which
 ... because once we know what we have we can start analysing the failing tests to see what to do with them

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html


heycam: this is the previous implementation report for the last publication of the spec

shepazu: why don't we contact gpac

heycam: i can do that

action heycam to email cyril about gpac implementation results

<trackbot> Created ACTION-2931 - Email cyril about gpac implementation results [on Cameron McCormack - due 2011-02-02].

heycam: even with gpac in there i suspect we won't get to zero
 ... at next week's call we should discuss what to do with tests that don't have 2 passing implementations
 ... issues in the agenda

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0054.html


heycam: test-align analysis
 ... this was the test that had chars from different scripts to different baselines and i said i'm not sure if the test is correct

<heycam> http://dev.w3.org/cvsweb/~checkout~/SVG/profiles/1.1F2/test/png/text-align-07-t.png?rev=1.3&content-type=image/png


heycam: i did some more investigation - i think the test is okay; that it's reasonable for the characters to hang from different baselines
 ... this is the reference image for the test at the moment
 ... wasn't clear to me if the spec required this behaviour but i read through and compared to css3 linebox
 ... not sure if anyone read this mail but i point out some differences between svg and css baseline alignment
 ... at least one property has changed name - not a good thing - something to discuss in fx task force

shepazu: so someone passed this?

heycam: don't think anyone does

anthony: think abbra does
 ... not sure if this is going to be in the css3 spec - might need to check

heycam: i think it will - at the moment what's there supports our test
 ... we could possibly remove the test but it's the wrong way to go about things

shepazu: is the wrong thing but might be necessary to move forward

anthony: not very clear you need to go to the CSS spec

heycam: my analysis was that the test is okay, still a little bit of alignment to do between svg and css3 about the name of the property values but that doesn't affect the test
 ... i assume this test is going to end up in the list of ones we don't know what to do
 ... in IE i think this was listed as a pass but that was before the reference image was updated

ed: i think the latest IE snapshot shows the same as firefox

action adrianba to check with patrick about whether IE ran against the latest version of the test

<trackbot> Sorry, couldn't find user - adrianba

heycam: next is text selection tests

action adrian to check with patrick about whether IE ran against the latest version of the test

<trackbot> Created ACTION-2932 - Check with patrick about whether IE ran against the latest version of the test [on Adrian Bateman - due 2011-02-02].

<heycam> http://www.w3.org/mid/20110120035126.GP31087@wok.mcc.id.au


heycam: this is about text-tselect01
 ... a test for text selection - firefox doesn't do text selection so we fail but as i was testing webkit in safari the test asserts that separate text elements shouldn't be selected together
 ... but in safari any text element is part of all the text in the whole document

ed: what version of safari - the one i have does what the test expects
 ... cannot get multiple lines on top but can the bottom but that's expected

heycam: same version - i can get it to select from the top all the way to the bottom

ed: not for me - strange

tav: in the test you see the text looks like a para - how do you know the order the text is supposed to be in

heycam: not defined in spec since it's not expected to be possible - suspect safari uses the document order
 ... my feeling is that it's reasonable to allow selection across different elements so i would rather the test not fail implementations
 ... in future versions we can define precise order

tav: that can lead to strange things if the order isn't specified
 ... could be security issue if you paste into something else

heycam: can already make characters appear in different order
 ... wonder what happens in adobe reader if text not laid out in order
 ... would be hard to say the order is as displayed not document order

ed: testing webkit nightly and does select across blocks but not reliable

heycam: wanted to get feedback on whether the failure is reasonable or if we can remove part of the test

ed: i raised an issue a long time ago - we weren't doing 1.1 at the time - the discussions back then suggested no agreement on selecting across elements was a good idea
 ... something we should consider - not sure changing the test here is a good idea at this point
 ... might be a good thing to allow in the future

heycam: probably not a huge deal - don't think the webkit guys are going to remove this just because the test remains

ed: it's one of the old tests - in the suite for a long time
 ... could rewrite the selection to be like html

heycam: yeah, in html you can have the same issue with absolutely positioned elements
 ... maybe not a common issue there

ed: what do people think - change the test or leave it?

heycam: if there aren't any other opinions i think leave it

tav: leave it and do in v2.0

<heycam> http://www.w3.org/mid/20110120041158.GQ31087@wok.mcc.id.au


heycam: let's move on to next text-tselect02 - question not about text selection

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-tselect-02-f.html


heycam: again in safari, link to the test itself
 ... think in safari the hebrew chars were shown as missing glyphs because of the font - want to know if it's okay to consider the test passed if it shows missing glyphs

ed: think it's better to add fallback with WOFF or system font
 ... bad to not show the glyphs
 ... we could say if you don't support bidi then skip it

heycam: did you raise a question about directionality?

ed: it was about baseline

heycam: sort of the same, directionality of the glyphs is going to be based on tables in the font - if you use the missing glyph characters should they be bidirectional and layout bidi or all do ltr

ed: i think missing glyph in this test doesn't make the test useful

heycam: how about i add some system font fallback and a woff font
 ... that would address the issue here but it might still come up

ed: yes, this would make it less of an issue

<scribe> ACTION: heycam to add font fallbacks to text-tselect02 [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action01]

<trackbot> Created ACTION-2933 - Add font fallbacks to text-tselect02 [on Cameron McCormack - due 2011-02-02].

heycam: next is struct-image-02

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0061.html


heycam: this is a test firefox fails because we don't claim to support feature string
 ... means support all the static things in the spec - there are a couple of things we don't support
 ... maybe it's better to test a narrower feature string - it's odd to test the feature string in the test
 ... we could fix the string to pass the test but we try to be conservative about this

shepazu: not for 1.1 but we talked about having discrete feature strings e.g. do you support text anchor on tspan - text.tspan.textanchor
 ... we're doing this kind of thing in dom l3 events
 ... think we should do this in svg 2.0
 ... not in 1.1 timeframe

heycam: so question is whether we can change the test to more specific feature string - i.e. not one that means did you do all of svg

ed: okay with me - think we should avoid using the old old feature strings org.w3.*

heycam: it seems strange to test the feature string when the test actually tests if it the feature works

<scribe> ACTION: heycam to change struct-image-02 to use a better feature string test [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action02]

<trackbot> Created ACTION-2934 - Change struct-image-02 to use a better feature string test [on Cameron McCormack - due 2011-02-02].

heycam: final one is animate-elem-81 - doesn't really require discussion - was hoping chris would be here so i could remind him to run the test
 ... i made the changes here based on the discussion last week
 ... just need chris to retest abbra to verify that it now fails which is what i expect the result to be
 ... i'll send mail on that

rechartering

<shepazu> http://www.w3.org/Graphics/SVG/WG/charter/2010/


shepazu: this is the current charter
 ... there is a current trend in writing charters to leave out the milestones since they tend to get out of sync quickly
 ... and for us to maintain more up-to-date milestones on the site or wiki
 ... are you inclined to do this since we missed every milestone?

heycam: seems reasonable

shepazu: does mean more work for the chairs - team contacts could but...

heycam: yeah, i think that's fine for us to do this

shepazu: we could look at automating this but let's not get ahead of ourselves
 ... just like a resolution on if we'll move the milestones into the wiki

ed: that means we can keep them more uptodate and more reasonable than the charter which goes out of date

shepazu: this is the current _draft_ charter
 ... many changes - need to emphasise the fx task force

heycam: need to mention the documents we're working on jointly in fx

shepazu: will split deliverables into joint and ones we're doing
 ... will change telcon to once per week
 ... change meetings to 2-3 per year
 ... often have 4
 ... will leave it at 3-4

heycam: will be fine if we choose to have fewer

shepazu: we're running out of charter at end of month - in order to get extension we need to show effort in trying to recharter
 ... i'll make some changes and would welcome feedback in next couple of days if you can

heycam: concerned about some of the docs that are listed and don't have much work on them
 ... does it make sense to have two lists - core and others
 ... how does it reflect on us to keep listing documents that don't make progress

shepazu: mostly held up because more work was needed on 2.0 than expected
 ... e.g. composites almost ready to go

anthony: yes, mostly, just haven't put aside the time to do more

shepazu: filters ready soon, colour management ready soon too, maybe we just need to have a couple of dedicated telcons on to get them done
 ... would look good in 2011 to get more to Rec during the year, obviously after 1.1
 ... unusual number of specs to have
 ... now that people are paying more attention to svg that's both good and bad

heycam: lots there considering size of the group
 ... can we divide them up?

adrianba: the css divides into high, medium, low priority

shepazu: i can look at what css does

heycam: i'd like to not say we're doing all of this

shepazu: i'll look at css and model on that
 ... please review, see if i missed anything or anything needs to be added - otherwise i'll update and then we can discuss

f2f

<shepazu> http://www.w3.org/Style/2008/css-charter


heycam: hotel information available soon - also please send agenda requests
 ... over the next week please send what you'd like to be discussed to the list

stroke-linecap on zero-length subpaths

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0041.html


heycam: sent this mail the other day - one of the changes we made in second edition was to make zero length subpaths take their stroke-linecap as a square if it is set to square
 ... previously only if it was set to round would it draw a circle
 ... we added square but some of the wording changes confused zero-length subpaths and zero length paths

<heycam> M 10,10 h 0 h 0

heycam: i think we want to draw for zero length subpaths but not zero length path segements

<heycam> stroke-linecap="square"

heycam: we don't want this to draw two line paths - it's a single subpath so you should only get linecap on the end

<heycam> CM: i suggested one of two changes

<heycam> CM: either fix that sentence to say zero length subpaths

<heycam> CM: or to remove it altogether, since it's redundant with another part of the spec

<heycam> CM: Erik said he preferred to keep and fix the sentence, so if there are no objections I'll do that

<heycam> ED: yeah I sent an email saying I prefer to change the implnote.html sentence, because if you remove it you have quite a bit of wording to say what to do with zero length path segments and orientation, and spreading it out in the spec

<heycam> ED: you could put a link instead...

<heycam> CM: I think it's fine just to fix it up, it's the smaller change

<heycam> ED: I agree, and I agree with the change itself

<heycam> ACITON: Cameron to make the change for zero length subpath linecapping in http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0041.html


<heycam> ACTION: Cameron to make the change for zero length subpath linecapping in http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0041.html [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action03]

<trackbot> Created ACTION-2935 - Make the change for zero length subpath linecapping in http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0041.html [on Cameron McCormack - due 2011-02-02].

<shepazu> http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html


shepazu: off topic but want to note that the first draft of touch events is published
 ... would be useful for people to review with an eye to svg

ed: we added some experiemental support for touch in svg in android opera
 ... you can register for touch events in svg - not working great yet but is interesting and would be good to have touch in svg

shepazu: spec doesn't specify html or svg - want to make sure something you're aware of and can track

heycam: meeting adjorned - thanks everyone

Summary of Action Items
[NEW] ACTION: Cameron to make the change for zero length subpath linecapping in http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0041.html [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action03]
[NEW] ACTION: heycam to add font fallbacks to text-tselect02 [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action01]
[NEW] ACTION: heycam to change struct-image-02 to use a better feature string test [recorded in http://www.w3.org/2011/01/26-svg-minutes.html#action02]
  
 [End of minutes]

-----Original Message-----
From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Cameron McCormack
Sent: Tuesday, January 25, 2011 11:12 PM
To: public-svg-wg@w3.org
Subject: Agenda, 26 January 2011 SVG WG telcon

Below is the agenda for the SVG WG telcon on Wednesday 26 January 2011
at:

    1130 San Francisco                                                          
    1430 Raleigh                                                                
    1930 UTC                                                                    
    2030 Stockholm                                                              
    0630 Sydney (Thursday)                                                      
    0830 Auckland (Thursday)                                                    
                                                                                
Agenda:                                                                         

* SVG 1.1F2 progress                                                            
  http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Remaining_work_for_SVG1.1F2

* Test suite results
  http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html


  30 remaining tests without two passing implementations.

  - test-align-07-t analysis
    http://www.w3.org/mid/20110120024739.GJ31087@wok.mcc.id.au


  - text-tselect-01-b
    http://www.w3.org/mid/20110120035126.GP31087@wok.mcc.id.au


  - text-tselect-02-f
    http://www.w3.org/mid/20110120041158.GQ31087@wok.mcc.id.au


  - struct-image-02-b
    http://www.w3.org/mid/4D37C064.1030805@jwatt.org


  - animate-elem-81-t
    http://www.w3.org/mid/20110121030008.GN17374@wok.mcc.id.au

    (Needs running in Abbra again.)

* stroke-linecap on zero-length subpaths                                        
  http://www.w3.org/mid/20110118225137.GA12109@wok.mcc.id.au                  

* Role Attribute LC                                                             
  http://www.w3.org/mid/op.vpjq7isxgeuyw5@localhost                           

* XBL 2.0
  http://www.w3.org/mid/20110121060247.GA30306@wok.mcc.id.au

  http://www.w3.org/mid/4D3B9533.9070608@w3.org


-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 26 January 2011 21:09:16 UTC