SVG Working Group Teleconference -- 07 Sep 2010

<trackbot> Date: 07 September 2010

<anthony> Scribe: anthony

<scribe> ScribeNick: anthony

Media Access Events

CL: This came up at SVG Open
... people trying to sync with video
... and found there were not sufficient events

JCD: Ericsson said they were happy with it as it is
... Ikivo were happy with it as well

CL: The next question is if we start standardising it, it needs to work with HTML

JCD: I think to bring it (HTML) video up SVG you need to add synchronisation
... I think MAE is completely orthogonal to sync

ED: There are buffering events

CL: The next thing we need to do
... is draw up a table
... of what HTML has what MEA has

DS: Don't forget the progress events
... which HTML 5 uses
... the way progress events are defined is you can change some the semantics around

CL: Does HTML 5 use that?

DS: Kind of
... and so does XHR

CL: So XHR uses the progress events? to use different things?

ED: I thought it was XHR 2

CL: It strikes me if we want to pick this up again
... we need to do a comparison of what is around
... and explain the use case
... of why this is needed
... show why it is useful for HTML 5 to have these

<ed> http://www.w3.org/TR/html5/video.html#mediaevents

DS: Before we try to push this any further with SVG
... we should communicate with the other groups
... Web Apps WG, HTML WG, Media Annotations WG, Media Fragments WG
... and that we are moving forward on this spec
... based on need in markets and implementer experience
... and it would be nice to synchronise our efforts
... and hopefully other groups and technologies could benefit from this spec as well

<cyril> CC: you should also indicate that it is somehow implemented (GPAC has a bit of them)

DS: oh and the public FX taskforce

ED: Who is going to communicate with all the groups
... what is the message we are going to send out

JCD: I need to go through and try to understand what's happening
... Before I can say anything, I need to spend some time alone to go through it

<ChrisL> tracker, status

<ChrisL> trackbot, status

<scribe> ACTION: Jean-Claude to Go through the MAE spec and the HTML 5 spec for video events and report back to the SVG WG [recorded in http://www.w3.org/2010/09/07-svg-minutes.html#action01]

<trackbot> Created ACTION-2854 - Go through the MAE spec and the HTML 5 spec for video events and report back to the SVG WG [on Jean-Claude Moissinac - due 2010-09-14].

SVG 2 with CSS

CL: In SVG 1.1 the properties and the inheritance mechanism are mandatory using the attribute syntax
... but external style sheets, style element and style attribute are optional
... but now days it's being used more often
... so I think for SVG 2 we should make external CSS mandatory
... why make it optional?

DS: I have no problem with that

CL: For SVG only UAs, you don't require the box model

DS: We should have a better method for referencing external sheets than XML processing instructions

CL: Technically we have a mechanism for linking to style sheets

DS: I was thinking we should get agreement that we should make CSS mandatory in SVG 2

AG: Will you require the box model?

CL: No, so you will be required to support external style sheets and style element and style attribute all with CSS syntax
... SVG only UAs will not be required to support the box model but SVG and HTML UAs will (since they already do)
... is that clear what I'm suggesting?

JCD: I don't like optional. If the support is inside and outside, it doesn't make sense to mandate one and not th other

Resolution: SVG 2 will mandate the support for external style sheets, style element and style attributes all with CSS syntax

ED: So we had some more things to discuss on this topic
... we should make sure that the current CSS properties that don't apply should be investigated
... we should go through all of them
... see if they apply to SVG

CL: So for text shadow that is a direct alias for a canned filter
... what do we do there?
... I don't know how tightly they define it

DS: We should be able to find out what they are defining

ED: We need to go through the CSS 3 and 2.1

<ChrisL> action-2854?

<trackbot> ACTION-2854 -- Jean-Claude Moissinac to go through the MAE spec and the HTML 5 spec for video events and report back to the SVG WG -- due 2010-09-14 -- OPEN

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

<scribe> ACTION: Erik, Chris to Go through the CSS 2.1 and 3 specs to see which properties for SVG 2 might be applicable [recorded in http://www.w3.org/2010/09/07-svg-minutes.html#action02]

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

<scribe> ACTION: Chris to Go through the CSS 2.1 and 3 specs with Erik to see which properties for SVG 2 might be applicable [recorded in http://www.w3.org/2010/09/07-svg-minutes.html#action03]

<trackbot> Created ACTION-2855 - Go through the CSS 2.1 and 3 specs with Erik to see which properties for SVG 2 might be applicable [on Chris Lilley - due 2010-09-14].

ED: One other thing that I know which is implemented already is CSS 3 color syntax for fill and stroke
... we need to define it for SVG
... because it's a bit more complicated than just going through and see what applies

element() syntax

ED: Is there a spec for that JWatt?

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2010Sep/0048.html

<shepazu> ROC mentions it here, looks like a great idea

JW: It was Marcus Stange that is doing the work

<jwatt> https://developer.mozilla.org/en/CSS/-moz-element

JW: Other than that there is the blog posts that ROC linked to in the email

DS: But no spec?

JW: I guess, I don't know if there is a proposal to the CSS WG yet
... but there should be

<shepazu> http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html

<jwatt> http://hacks.mozilla.org/2010/08/mozelement/

DS: Here he writes it up a bit more

<shepazu> -moz-element(#elementID)

ED: I think this a good idea

<jwatt> there's a thread on www-style about it

ED: it would be nice to have something like this

<jwatt> http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html

DS: I don't think SVG should standardise it
... I think CSS should
... but we should support it
... part of FX work maybe
... SVG 2 should use this

JW: There is a proposal

<jwatt> http://lists.w3.org/Archives/Public/www-style/2008Jul/0335.html

JW: In there ROC has a link
... to a document

<jwatt> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

CL: This post dates EDs work on the Filters module

<jwatt> that's from 2008 though

CL: is there anything in that draft that thread is not in your module

ED: element()

CL: In particular the terminology I want to make sure that it is clear in your spec

ED: That wording is not yet in
... I do have an action from FX taskforce
... to move the filters module to the common workspace area

CL: We need to start those calls again after the summer
... In the terminology section there is some useful wording

<ChrisL> definition of "bounding box" of a CSS-formatted element, for example

ED: Any response from the CSS WG?

CL: No

ED: Guess we should just discuss that in the XF telcon

<jwatt> note that the Aug www-style discussion continues in Sept

<jwatt> http://lists.w3.org/Archives/Public/www-style/2010Sep/0000.html

CL: So it was recently agreed to extend the hash syntax
... so there is a 4 and 6 figure RGB
... way to define colour
... Apart from that there has been recent work it the taking up of vertical text
... the idea is to change one property and the text goes vertical
... and the properties all make sense
... also W3C got representation from the Indian office about Indian languages
... one of them was vertical
... they are still doing stuff about borders and backgrounds

ED: There was some discussion on whether to slice up the viewbox

CL: You can do it with a viewbox

ED: That's not defined?

CL: Not yet, individual image formats need to say what happens exactly
... Doug, is the integration spec cover CSS as well?

DS: Yes, trying to make it fairly general

CL: So one thing to put in there is, if SVG is used as a CSS border image - how the required slices are generated
... [Draws diagram on board]

JW: What happens with the edges when you're repeating and it doesn't fit the exact multiple?

CL: Up do you to design an image that works properly
... it's designed to be used for an image that has been created for that purpose

JW: There's going to be cases where that doesn't work
... [Adds to drawing]

CL: It stretches and repeats

JW: In certain cases you'd want it to space evenly

CL: In it's current state it's getting ready for CR
... this one of the ones that's expected to go to Rec fairly quickly
... and it's a good time for us to define it for SVG

ED: It is a bit more work for SVG
... to make sure it looks good

<ed> [back from lunchbreak]

Borders and Background for root SVG

CL: The SVG inside the HTML has an outside and an inside edge
... and the box model applies to the outside edge
... and the SVG formatting model applies to the inside, i.e. the content
... only undefined part is whether you get padding

<shepazu> I have an example on my blog: http://schepers.cc/css-in-svg

JW: It's formatting is defined by the replaced element
... for the purposes of CSS

CL: Is replaced element anything that doesn't use the box model

DS: I think your definition makes sense
... it's something where the normal CSS rules don't apply
... for where the rules don't apply that's replaced conent
... I have a blog post you'd like to look at
... if you scroll down to the bottom
... the two pictures
... both of those are the correct geometry as the SVG says it is
... The border should be clipped
... [Projects blog post]
... The top image has the width and height declared in the SVG
... same width and height is encoded in the object

CL: The area that SVG believes it has been given
... is the area it should render it
... If the CSS gave it a massive big top border which changed the aspect ratio it should render into that

DS: If I do 100% and 100% in the SVG width and height
... it does exactly the same thing
... and all the browsers as I tested
... did it this way
... to me this border should be clipped
... it should be as if overflow="hidden"

CL: This is why people use raster images because you get the scroll bars

ED: This is one of the reasons to have SVG work in the <img> tag
... you wouldn't get scroll bars

<ChrisL> having scroll bars obscuring the content in svg, especially for small images, makes people use animated gif or flash instead

DS: Sure <img> is convenient but you don't want script to work in <img>

CL: This is something you should be able to control
... you should be able to elect to not have scroll bars

JW: This case is a bit weird
... I don't see what people would want to put a border on the SVG

ED: You'd put a border on an iFrame
... that's what I'd do

JW: I'd be tempted say that on the root element border and stuff like that doesn't apply

ED: Unless it's inline

JCD: The problem is half of it is inside and half of it is outside

DS: We have to specify this anyway
... I can see that people want to put a border around SVG
... so that it has one no matter where it shows up

JW: I want the iFrame to take on the aspect ratio of the SVG
... but I want the SVG to take on the dimensions of the iFrame

DS: That's not where the box model is being applied here
... it's being applied to the SVG content
... it's not being declared on the object that is referencing the SVG
... it's being applied to the SVG content

JW: What do you think should be applied

DS: The border should not have geometry per say
... it shouldn't add to the amount of space that the SVG takes up
... it's purely stylistic
... SVG doesn't follow the box model
... Something needs to be specified
... I'm arguing that are two different cases
... for border and background
... then there are for stroke and fill
... I think they are different characteristics
... I can see people wanting to use border and background on the SVG root

JW: It's a bit odd

DS: Why not?

JW: Putting the width and height 100% it's going to give you scroll bars

DS: Lets say that people want to have a border on their SVG
... I actually think this is a legitimate use case
... it's easier to have a border and background if they are familiar to CSS

CL: This is exactly why we put viewport fill
... so the thing that people are already familiar with doesn't let people zoom out

DS: I would expect the background would be a flat fill

AG: I'd expect the border to operate like the vector effect for non scaling object
... where the border is always resized when zooming
... I'd expect maybe the same thing could work with background

JW: This is being parsed by the HTML parser
... you're served this as Text/HTML
... so I think what's happening here is in the current version of firefox
... it was being parsed with the old version of the parser
... but now it's being parsed with the new HTML parse

ED: I see something slightly different in Safari
... doesn't look the same as in FireFox

JW: This is to do with parser rather than the CSS model

CL: Beta 6 shows the same as Beta 4

DS: It looked different

JW: According to the HTML with SVG parsing rules it's implicitly creating a second appearance

DS: I think I figured it out
... I think it's my blog
... [Fixes blog]

JW: That looks better

ED: How are borders applied in CSS, do they go outside the content box?

CL: Yes

DS: In the second example I'm using padding
... in the first case I'm just using border

CL: It's just wrong. If I want a border around my SVG I'd expect it to be on the outside
... so you say in your post that some things should apply, do you mean them as examples or as an exhaustive list?

DS: As a list of all that apply

CL: In that case that's ok

DS: I was specifically call out things that would make sense to have

ED: If you put a border on something inside the root of a foreignObject
... would it be bigger?

CL: I'd expect the line to go all the way around the foreignObject

JW: [Draws different scenarios on board]
... my suggestion would be to set this property for SVG elements
... and it automatically just works for elements
... I think what will happen is the content area size is reduced
... which is the effectively the viewport size of the SVG

<ChrisL> scribe: Chris

<ChrisL> scribenick: ChrisL

DS: (draws on board)

JW: In all cases it stays at 100% 100%.

DS: OK if we don't show the border. It might apply
... what if they zoom out, then it shows.

JW: Huh?

ED: That is a strange behaviour

DS: Dont want the size of the SVG to be affected by the size of the border
... dont want box model to apply to svg in that way
... only the border and background, not the rest of the box model. and the padding
... Chris you are right, viewport-fill and background are different, for svg

JW: (still searching for the property that says whether width applies to content box, padding box or border box)

<ed> https://developer.mozilla.org/en/CSS/box-sizing

<jwatt> http://www.w3.org/TR/css3-ui/#box-sizing

http://dev.w3.org/csswg/css3-ui/

Name: box-sizing

Value: content-box | border-box | inherit

ED: Does this solve the examples on your blog, Doug?

CL (reads from spec) so you got this legacy behaviour as the editors not describes

JW: So ok to do this but only on the outer svg element for inline content, as the outside of it is in the box model

CL: OK to deprecate viewport-fill in favour of background, if and only if it behaves the same way including under dynamic modification or user interaction (especially zooming out)
... otherwise, having the same property but behaving differently is more confusing than having two properties which do different things

DS: I suspect that most designers would expect background fills entire viewport regardless of zoom

CL: OK, but does the background spec say that?

<anthony> AG: I agree with what Doug thinks. That's just my opinion

<anthony> CL: My point is that how the backgrounds behaves is described in terms on the box model

<anthony> ... so when they add transforms they will describe what happens with the boxes

<anthony> ... but it's only defined for the box model, so saying we want a background for our non-defined box model is undefined

<anthony> JW: The problem I see is

<anthony> ... say I have a content area

<anthony> ... and there is area without anything in it

<anthony> ... setting the CSS background property will fill just the content area

<anthony> ... where as viewport fill would fill the whole area

<anthony> ... including the area without anything

<anthony> CL: If it was 400 wide I would not have said it was 200 wide

<anthony> ... I would've said it was 50%

<anthony> ... and use Xmin and Ymin

<anthony> ... that's how I would design that case

<anthony> DS: We have viewport fill and viewport fill opacity

<anthony> ... even though it would make sense for designers to use border

<anthony> ... they would find it doesn't work they way they expect

<anthony> ED: Viewport fill and viewport fill opacity already work for all SVG elements that establish a viewport

<anthony> AG: so 1.1 has a couple of elements where that applies?

<anthony> ED: Yeah, anything that establishes a viewport

<anthony> DS: Are people completely closed to the idea of having border and background on individual SVG elements?

<anthony> ... it's incredibly useful to be able to see the bounding box of an element for debugging

<anthony> ... would much be nice to have a dashed border that changes with the size of the shape

<anthony> JW: There is another property that does a line around the object without all the box model stuff

<anthony> ED: outline?

<anthony> DS: Does it have all the characteristics

<anthony> JW: We could define it to apply to the bounding box

<jwatt> http://www.w3.org/TR/css3-ui/#outline

<jwatt> I'd be much happier to consider making the outline properties apply to SVG rather than border

<anthony> CL: In principle it sounds reasonable

<anthony> ... it gives you the ability to give you a rectangle around something that encompasses the object

<anthony> Resolution: We will define how border and background apply to SVG

<anthony> Resolution: We will keep viewport-fill and viewport-fill-opacity for zoom

<anthony> Resolution: We will investigate defining the outline property for use on SVG elements

<anthony> ACTION: Doug to To add to the integration specification how border and background properties apply to SVG [recorded in http://www.w3.org/2010/09/07-svg-minutes.html#action04]

<trackbot> Created ACTION-2856 - To add to the integration specification how border and background properties apply to SVG [on Doug Schepers - due 2010-09-14].

<anthony> ACTION: Doug to Investigate defining the outline property for use on SVG elements [recorded in http://www.w3.org/2010/09/07-svg-minutes.html#action05]

<trackbot> Created ACTION-2857 - Investigate defining how the outline property applies on SVG elements [on Doug Schepers - due 2010-09-14].

<ed> [work on actions]

<ed> http://www.w3.org/Graphics/SVG/WG/track/

<scribe> scribe: chris

<scribe> scribenick: ChrisL

pointer events

ED: Root svg element should let clicks through to the underlying content if its inline in html

<shepazu> example: http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml

embeded svg capures the clic and the surrounding context does not get it

CL does not surprise me that we don't get two events in the first testcase

DS: Spec is ambiguous.

ED: Firefox behaves differently from Webkit and Opera. IE9 not tested ast time we discussed this

CL: CSS Pointer events extends out pointer events spec to add box model stuff

DS: Some CSS developers love being able to use ponter events
... case where there is svg referenced with object, image the transparent parts should click through.

JW: In HTML a transparent background can still be targetted by events. So if inline SVG is just another element in the box model, it behave the same. opt-out is pointer events none

DS: That stops all interaction

JW: No, you can overide it for the children

DS: where is it specified?

JW: Not clear, jus went for consistency with how HTML is implemented

ED: Feedback says that is not what we want, inefficient, so we allow clicks through the unpainted area

CL: Same issue with a PNG image with transparency surely

ED: People want the stuff underneath to get clicks

JW: On bugzilla i was arguing to have events go through, but final decision was to block them

ED: target the comon case first. Mostly people want the events to go through

DS: SVG spec assumes (though poorly worded) that SVG root doesn't intercept pointer events on unpainted areas

CL: Do you have the same behaviour as Firefox for HTML/CSS pointer events on transparent background?

ED: Yes. But for SVG people expect different things.
... Background does not affect it

JCD: So even if transparent it captures events?

ED: yes

(discussion on security, and same-domain and overflow on embedded objects to capture events)

<ed> just for reference, search for "hit" in the minutes from day 1, where we discussed this topic: http://www.w3.org/2010/09/03-svg-minutes.html

CL: So Doug was saying to not hit-test on unpainted background, and Firefox says to set pointer events to get that behaviour that the spec already says

ED: Cyril tested IE9 and it has the same behaviour as Webkit and Opera. Would Mozilla be willing to chenge here?

JW: Personally yes but not my call here

<shepazu> http://www.w3.org/TR/SVG/interact.html#UIEventProcessing

JW: (reads from spec on 'painted area' which is all about grahics elements not containers)

DS: This could be improved, it mixes hit testing and event propogation
... (projects above link, points out errors)
... first bullet is about hit testing. next 3 are about order of actions for things that have been hit tested
... and failing that, text selection starts
... final sections ays, if hit testing failed, do any UI events like context menu it what what happen normally
... this was before there was a clear concept of window.
... it not about event propogation at all. its a consequence of hit testing

CL: This is a very traditional CG model from 1970s, 80s

JW: Read it as all five bullets apply to all elements

DS: So first you see if you are on a graphics element, then it propogates, then you do the actions, failing that then you do zoom and pan etc
... assuming you hit a graphics element. container elements dont get events in this way

JW: Spec does not say explicitly that container elements cant be the target of an event

ED: pointer events apply only to graphic elements
... Can dispatch an event to any element

DS: (quotes "The target element is the topmost graphics element whose relevant graphical content is under the pointer at the time of the event")
... Important to clarify this now CSS is adding pointer events

JW: If you set a viewport fill it gets no events and can't be dragged

DS: Yes. You would need to draw a rect to do that
... Its clear for inline. Opera used to have the behaviour JWatt was describing but has changed, Webkit/Chrome/IE9 have that behaviour too

JW: What is the target if there is no content?

ED: The window or the document.
... or the document element, and I'm not sure which. needs to be tested
... Onclick handler on root svg, do you expect it ever to be called?

JW: If its still inside the viewport, if there is viewport fill it should get events

ED: (drops in testcase)
... Do we have wording for where the listener is defined?
... Think html body element is special

JW: Quite likely. registers it on window I think

<shepazu> ISSUE-2364

<shepazu> 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

JW: We have bugs on our behaviour in bugzilla

<ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clicks-on-root-svg.svg

DS: More common case with mixed SVG and HRML, people do not want a giant bbox they can't click through

<jwatt> s/have bugs on our behavior in bugzilla/have had bugs asking for pointer events to target <svg> instead of letting them through/

<jwatt> https://bugzilla.mozilla.org/show_bug.cgi?id=338279

DS: For the inline case, try to select text in the overlap. It doesn't work as the SVG captures the event

CL: I agree that unpainted area should not capture events

AG: I agree

DS: SVG 1.1 is clear that only graphics elements dispatch pointer events, browsers all do that apart from Firefox

ED: Confirm IE9 has the SVG 1.1 behaviour

DS: I think HTML folks would prefer to see this behaviour too, for irregular shaped graphics. They are not boxes

CL: And can alway have pointer events bbox anyway if that is wanted
... Need to make sure the CSS guys know about thet value btw its a late addition

JW: (example, scribe missed)
... in both cases its inconvenient because you need an encosing g element to set pointer events on

DS: Pointer events section should have explicitly mentioned groups. Needs to be very clear in SVG 2
... Easier to change one browser than five ....

AG: If i have a rect that is stroked and not filled, clicking the middle gets no event

CL: Correct, default is visiblePainted

AG: vector effects needs to be clear here if the result is a path or a stroke, for purposes of pointer events

<jwatt> I'm not comfortable with saying that <svg> can't be the target of events for a few reasons:

<jwatt> for many people coming from HTML I don't think it's intuitive

<jwatt> if you want the reverse behaviour (<svg> being an event target) you still need the child <g> reseting pointer-events

<jwatt> if you have 'background' or 'viewport-fill' on <svg>, I'd expect events to be able to target it

<jwatt> having said that, I do sympathize with and accept that there are many people who don't expect or like mozilla's behavior

but neither viewport fill nor background are painted graphical objects

JW: Not painted but its visible and people expect to be able to interact with it

DS: OK so we esatablished correct behaviour for *inline* svg, bt that was not really the issue

<jwatt> I'd note that SVG 1.1 as it currently stands does not allow <svg> to be the target of an event, period

ED: when svg is standalone, and click outside painted area, event is captured and target is the svg element in four tested implementations

<jwatt> as Doug says, you'd need a rect filling the viewport to get events anywhere

ED: firefox 4.0b6pre, Opera 10.60, Safari 5, IE9 platform preview 4

CL: At al, even if pointer events are changed?

JW: Yes

ED: Spec not consistent with that

DS; Maybe the pointer events should be extended to include a background value

DS: Those comments not withstanding, SVG 1.1 spec has intuitive behaviour that is widely implemened so we should keep it

action doug to clariify the behaviour of pointer events on container elements

<trackbot> Created ACTION-2858 - Clariify the behaviour of pointer events on container elements [on Doug Schepers - due 2010-09-14].

<jwatt> I'd also note that if events go "through" <svg>, then the "put a 100% x 100% <rect> in to capture events doesn't work in the face of viewBox

DS: Microsoft has been pretty clear that they want this pass-through behaviour
... Want consistent behaviour in browsers

JW: Will talk to Roc about this

Resolution: the svg 1.1 spec is clear that pointer events only target on graphicc elements and this intuitive behaviour is widely implemented so for the inline case we will keep the same behaviour that the spec defines

JW: Okay, will go along with the majority here but uncomfortable with whether this is the right thing

DS: For externaly referenced content, its not settled yet

AG: In all cases, if something is visible and it could be targetted

<jwatt> s/will go along with the ajority here/will not stand in the way right now/

<jwatt> as stated above, I think 'intuitive' depends on who you are - if you come from SVG, sure

adjourned

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

07 Sep 2010

Attendees

Contents

Media Access Events

SVG 2 with CSS

element() syntax

Borders and Background for root SVG

pointer events

Summary of Action Items

Scribe.perl diagnostic output