SVG Working Group Teleconference -- 15 Mar 2012

<trackbot> Date: 15 March 2012

<scribe> ScribeNick: heycam

Finishing SVG 2 requirements

CC: we left off at microdom

Microdom

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Micro_DOM

CM: I agree with Erik we should split these out

CC: should we split it and come back to it later?

ED: I've listed the ones I knew about

… the changes that I think are useful and ones I know aren't useful

CM: we don't need to look at the minor changes as requirements

ED: we could just consider this all as part of improving the DOM

… which we've already accepted as a requirement

… the changing interface names might be tricky though

… if we introduce new interfaces, we shouldn't clash with existing ones

CM: like SVGAnimationElement?

ED: yes

… some new inheritance structure

CM: we'll need to revisit inheritance structure for Web IDL anyway

CC: for SVGMatrix particularly, there's also the work from Dean

… on CSSMatrix unification

CM: I would be fine with consider these as part of DOM improvements

CC: I feel a bit uneasy about that

… improvement in general, yes, but maybe we should have some still general requirements

… the TraitAccess had a specific design

… I agree, for some of them like SVGRect we don't want to spend much time on them, but some of them we should spend a bit more time on

ED: for SVGRect, that's the same as in 1.1

… we could split up this requirement entry into chunks

… was there a specific feature you were concerned about?

… I listed the changes I was aware of compared to 1.1

… it's all the big parts, I think. if there's anything missing it's small.

… the biggest one here would be the TraitAccess interface, and perhaps SVGTimer/SVGGlobal

CM: did we already resolve not to include timers?

ED: it was the timer event

CM: we could have a discussion now about whether we want to include microdom as is

ED: it's probably not too hard to merge, but in some cases the tiny DOM doesn't take into account the complexities of 1.1

… for example arcs are missing in tiny, so the path interfaces in tiny would need changes

… for the features we've already decided to have, maybe it makes sense to merge back parts

CM: I was never a fan of the microdom design

… I don't want to accept it as a whole

… as part of the DOM improvements work that someone does/designs, it can be looked at for inspiration

CC: I'm concerned that we will miss out some useful functionality

<scribe> ACTION: Cyril to update the list of differences between MicroDOM and SVG 1.1 to help with DOM improvement proposals [recorded in http://www.w3.org/2012/03/15-svg-minutes.html#action01]

<trackbot> Created ACTION-3249 - Update the list of differences between MicroDOM and SVG 1.1 to help with DOM improvement proposals [on Cyril Concolato - due 2012-03-22].

RESOLUTION: SVG 2 will not merge the MicroDOM as is but will use it as input into the DOM improvement designs

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Relaxed_document_error_handling_.28lacuna_values_etc.29

Relaxed document error handling

CM: I think that's a good idea

ED: me too

RESOLUTION: SVG 2 will have relaxed document error handling (with lacuna values etc.) as defined in Tiny 1.2

CC: we should look at ones we skipped now, before going on to the late requests

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups

display of InkML trace groups

http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html

CC: reading the email again, I wonder if we didn't have an action to ask charles about specific features/changes

… the email conclusion says "it would be fantastic if SVG could be used to display InkML trace groups"

… but it doesn't propose anything

http://lists.w3.org/Archives/Public/www-svg/2011Oct/0108.html

CM: two requirements I can tease out of this

… one is buffered-rendering

… the other is like variable stroke width, but not necessarily varying just stroke width, also opacity

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering we have resolved

<ed> and http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Replicate

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width might also be related

CC: we said we would not accept replicate without use cases and author/implementor interest

… so this seems like a use case

… and author interest

… but we still don't have implementor interest

ED: I would want more details

<krit> http://www.w3.org/TR/InkML/

… it's not clear how the InkML would map into SVG

CM: the InkML traces are sequences of points with a pressure value

ED: I'm unclear how you would use it together with SVG

… somehow to connect the two

CM: whether it's a new element?

ED: or maybe a DOM API

… but the request isn't clear on that

DS: maybe we should ask for more clarification

… InkML is a big spec to require

CC: his derived requirements are efficient DOM rendering, and variable stroke width

CM: but not varying opacity?

RESOLUTION: SVG 2 should be able to display InkML trace groups by some means, perhaps by using buffered-rendering and variable stroke width, not necessarily varying anything

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Connectors

Connectors

TB: there is interest in Inkscape to support connectors

… but the group that indicated interest hasn't done any work on it

DS: is that were you specify points? and you get nice paths along these points?

TB: no

<cyril> http://dev.w3.org/SVG/modules/connector/SVGConnector.html

TB: basically you have objects that are connected by lines, and the connectors say which object you start on and which you end on

… a way of building up diagrams

… Inkscape has support for automatic routing connectors

… you can say this object is connected to this other object, and it will draw a line between them

DS: with connection points?

TB: yes

… one nice thing is that you can say to have the line avoid certain objects, so the lines route around it

CM: I think we've avoided talking about path routing in the past

… beacuse there are many path routing algorithms you could want

DS: I would be interested in having the semantics in SVG

<cyril> http://www.w3.org/2009/09/30-svg-minutes.html#item05

<cyril> this is the minutes from a previous discussion on connnectors

ED: we've just talked about simple lines for the rendering

… but a way to have the author specify anything nicer

… the reasoning was that if you just have the links and no visual output, there's less incentive to use it

… because you don't get much for free except the semantics

… otoh if it's ugly nobody might use it

… but I could see using it for simple cases

TB: if there's a way for the author to override the simple line, it might give the incentive to use it

… I think this is also good for accessibility

DS: in that case the semantic is important

CC: from a different perspective, you can already do connectors

… diagrams, reconnecting objects, you can already do this with JS

… so you might expect to see examples on the web

… I'm wondering if this is a good use case

… I'm not hearing interest from browser vendors

… maybe the use cases aren't strong enough for browsers to be interested

DS: it depends how you see the SVG documents

… browsers see them as images you can script, not necessarily as the semantics behind it

… so it's not as important to add the connection semantics

… I think it's OK to say that we want the semantics so that certain tools can use it, but not necessarily a requirement to draw the connection

CC: if it's only about semantics, I don't see why it needs to be in SVG itself, it could be a separate language

ED: I think it would make sense to have this as a module

DS: the question is who would use the module?

… special tools that try to visualise connections?

… or would browsers render the connections?

… tools like Visio would give the user a choice to modify the paths, but if we have an algorithm that would not be possible

CM: the spec just requires a straight line between the two points

DS: but how often do you want to draw just a straight line?

CC: I think if we want to work on this in the module that's fine, but I'm worried it would hold up SVG 2

RESOLUTION: SVG 2 will not have connectors, but we will continue its work as a separate module/spec

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Enhanced_text_support

enhanced text support

<ed> http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties

CM: I think David wanted different sized glyphs to be aligned on a baseline other than alphabetic

ED: I know these baseline properties aren't implemented well cross browser

… they might satisfy David's use case

CM: my guess is that these baseline properties will allow you to do this

GA: I believe it's in the CSS3 line layout module

ABC

data: text/html,A<span style='font-size:200px'>B</span>C

CC: I think the requirement is OK

ED: I think it is handled by these properties, and the requirement is OK

http://dev.w3.org/csswg/css3-linebox/#dominant-baseline-prop

RESOLUTION: SVG 2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties

Hit-testing on image alpha

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hit-testing_on_image_alpha

DS: we talked about pointer events some time ago

… hit testing is related to that

<krit> https://developer.mozilla.org/en/CSS/pointer-events

CM: it was going to go into CSS UI but it got deferred

<krit> http://wiki.csswg.org/spec/css4-ui#pointer-events

CM: I think it would be fine to handle this alpha image pointer events in SVG if CSS doesn't get to it

… I would be happy with this if there aren't unsolvable security problems

CC: would this be on gradient opacity too?

… it would be a new property or attribute?

… you can't change the current behaviour

CM: or extend the pointer-events property with new values

<ed> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

ED: yes having an alpha cutoff was discussed at some point

… I think we should look at the previous discussion

… I'm a bit worried about the security aspects of it

RESOLUTION: SVG 2 will support pointer events sensitive to alpha, subject to security constraints

<ed> http://www.w3.org/mid/4DC60BB0.1000500@w3.org is part of the thread on pointer-events alpha

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_a_.27key.28.29.27_keyword_for_animation_triggers

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27timelineBegin.27_attribute_on_the_.3Csvg.3E_element

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27playbackOrder.27_attribute_on_the_.3Csvg.3E_element

<scribe> ACTION: Cameron to mail Brian asking his opinion on these open animation requirements [recorded in http://www.w3.org/2012/03/15-svg-minutes.html#action02]

<trackbot> Created ACTION-3250 - Mail Brian asking his opinion on these open animation requirements [on Cameron McCormack - due 2012-03-22].

- DRAFT -

SVG Working Group Teleconference

15 Mar 2012

Attendees

Contents