SVG Working Group Teleconference -- 03 Dec 2009

<trackbot> Date: 03 December 2009

<scribe> Scribe: anthony

Next Face-to-face

ED: Currently JW may have problems traveling to Australia
... looking at having the meeting in Europe
... around Jan - Feb

CL: Will he be shifting around that time?

DS: Not before Feb
... we could catch JW before he moves
... He's currently near Amsterdam
... Need to check if this is ok with him

Action Update

ED: I was doing a couple of actions
... master to publish scripts don't seem to be giving me all the right files
... I think I fixed the Java bindings
... have a couple of fixes that I would like to get into the publish version
... working on extracting test cases for getIntersectionList

CL: ACTION-2664 I worked out what the transfer codes for RGB
... I plotted those in SVG
... if you have 8 bit resolution you can't see any differences between the different RGB gamuts
... sending an email

AG: Need to complete the full page

<ChrisL> email sent - http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0054.html

AG: was going to use the Tiny script and modify it

<shepazu> ACTION-2203?

<trackbot> ACTION-2203 -- Doug Schepers to add to the 1.1 Full errata that the initial value for the root overflow property is scroll rather than hidden -- due 2008-09-30 -- PENDINGREVIEW

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2203

<ChrisL> http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/att-0054/sRGB3.svg

<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#overflow_visible ?

CL: I've updated links in the spec relating to ACTION-2664 so they point to a PDF containing the information

DS: Any feedback on 'Overflow Visible' errata?

ED: What about reference markers and patterns?
... David was complaining about when you have an SVG inside another SVG

DS: No I think it was the reverse
... I think the main change I made was to say that the root SVG element is
... now visible as declared in CSS2 overflow
... and then I said with a child element (including child SVG, pattern and marker) it's hidden
... so that action is complete

CL: I did an update on ACTION-2682

<ChrisL> Update on ACTION-2682'

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

CL: That's the latest update on the implementation report
... Erik has an action relating to types-dom-02-f
... For painting-stroke-10-t we could back out the change

<ChrisL> painting-stroke-10-t is still an issue, stroking zero length paths. no imp does this yet

CL: and leave it for the next version of the errata
... this would be the only one to roll back assuming you split types-dom-02-f

ED: We get a pass from Opera and probably Batik

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-tref-02-b.svg

<ChrisL> please run in webkit

<ChrisL> crash! excellent

DS: Crashed webkit

CL: I didn't know what 'X' meant in the sheet

<shepazu> ☠

CL: Tests almost done

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

ED: Only 3 or 4 left to review
... I will get to the IntersectionList ones soon

Params Feedback

DS: Dr Olaf sent in an email
... 1. Suggested syntax for the params URL
... It was a bit verbose, but we will have to do something like #params and name value pairs
... First change is reasonable
... 2. Rather than have explicit params to be laid out in a document. You allow the author to select and identify
... any element and then change an attribute in that
... But it's basically inventing CSS in a URL string
... the idea of params is have structured documents with exposed attributes
... and allow them to be changed by other documents
... 3. He said it was too simple and he'd like to insert fragments into the whole document
... I received similar feedback off list suggesting that params was too simple
... But it's out of the scope of params
... Should use XSLT to do stuff like that
... I don't want to increase the complexity of the specification
... These are my initial reactions to the feedback

CL: I think sticking CSS in a URI string is pretty weird.

DS: Although we had an idea of forcing a style sheet on something

CL: I wouldn't do that necessarily by URI

<shepazu> mysvg.svg#params({color1:blue; fade:0.5;})

<shepazu> mysvg.svg#params(color1:blue; fade:0.5;)

ED: Something like that

DS: I think that idea is ok, because you can have a property bag
... and it would be easy to pass in values
... I'd be open to that idea
... I don't really want to rely on the URL string only
... CSS would probably like that syntax because it's probably the only way it can be done with CSS

AG: So 'params' would be a reserved word?

DS: Yes
... I like the JSON syntax idea
... with the property bag

ED: Would that be similar to what Dr. Olaf suggested?

DS: No different. A person wouldn't need a 'param' key word
... they could access any element id

<ed> http://dev.w3.org/html5/spec/Overview.html#attr-iframe-seamless

DOM3 Events Group

DS: We decided not to meet for the remainder of the year

ED: I don't mind having meetings in the next week

DS: What about saying we do the next two telcons then work on list
... I never pushed integration spec
... because there were too many bugs with it
... I can push it before Christmas
... The tables are pretty much ready

RESOLUTION: We agree to publish the Integration specification

DS: DOM 3 Events is thinking deprecating DOMActivate
... because at this point 'click' pretty much does everything that DOMActive does anyway
... having that complicates the model
... so we are thinking of extending 'click' to cover DOMActivate completely

CL: I think it's a reasonable idea
... in practice they've almost been the same thing

DS: We should simplify it to say just use 'click'
... As long as you say 'click' just doesn't mean click
... I believe Opera implemented DOMActivate

ED: I think we have code to handle it but we don't dispatch it
... I don't object to the change
... I'd be happy having it behave like 'click'
... or have it replaced by 'click'
... There is very little code that would break in practice if we did that

DS: I think you would find more on Mobile SVG content

RESOLUTION: SVG Working Group is ok with deprecating DOMActivate as long as the accessibility people are happy with this also

Christmas Break

DS: So we were meeting for telcons next
... and then that's it until January

AG: Which date?

DS: Early. Anthony can you clarify which dates you get back from holidays

Charter

DS: I'm simplifying the charter
... and I updated it
... I will try to get the charter to you guys before the end of the year
... I want to put it in front of the AC soonish
... I've put my two deliverables in the charter
... if there is anything else that you guys think of let me know

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

03 Dec 2009

Attendees

Contents