See also: IRC log
<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
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
<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
<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: 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
<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
<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
<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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/maybe// Succeeded: s/??/TB/ Succeeded: s/spec/test/ Succeeded: s/1.1/2.0/ Found ScribeNick: adrianba Found Scribe: Adrian WARNING: No "Present: ... " found! Possibly Present: ACITON CM Doug_Schepers P0 P1 P10 TB aaaa aabb aacc adrianba anthony anthony_work ed heycam joined plinss_ scribenick shepazu svg tav tbah trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0074.html Found Date: 26 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/26-svg-minutes.html People with action items: cameron heycam[End of scribe.perl diagnostic output]