<trackbot> Date: 07 March 2013

<richardschwerdtfeger> scribe: Rich

<richardschwerdtfeger> erik: skip over publication status

<dino> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html

Transformation Proposal

<nikos> Zakim +61.2.9 is me

<richardschwerdtfeger> krit: at the last face to face we though it would be a go change to create a new svg matrix that is integral with other specifications so that could be used with canvas

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html

<richardschwerdtfeger> krit: they thought it was good and to evolve over time

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html#webidl-ref

<richardschwerdtfeger> the interface is quite similar to the interface proposed by D Jackson

<richardschwerdtfeger> krit: I made more compatible with SVG matrix. It has a 2 dimensional scale. it scales to the x and y axis

<richardschwerdtfeger> krit: there is one more change. for svg matrix for 2d compatibility

<richardschwerdtfeger> krit: just 2d instead of 3d

<dino> the change was rotate() to be compatible with SVG, so is only 2d

<dino> but 3d is covered by rotateAxisAngle

<richardschwerdtfeger> smfr: maybe you should take vector x, y, z

<richardschwerdtfeger> krit: just the x and y

<richardschwerdtfeger> thanks

<richardschwerdtfeger> smfr/we did not have skew z

<dino> smfr: suggest renaming to rotate(double angle, optional double originX, ...)

<dino> smfr: the fact that x,y is origin should be clear, and that the x,y,z from rotateAxisAngle is a vector

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html#the-constructors

<richardschwerdtfeger> smfr: I would like to ask the same question as David Baron. Can they take a string and slam into a transform attribute

<richardschwerdtfeger> krit: yes. takes a DOM String and does a CSS transform

<richardschwerdtfeger> Kitt: if you have an element get the transform out of it. … the pixel would not be the same.

<richardschwerdtfeger> smfr: maybe this text needs some non-normative examples. The spec. is isolated right now

<richardschwerdtfeger> krit: the specification can reference it.

<richardschwerdtfeger> krit: i happy to put more informative text in it

<richardschwerdtfeger> krit: examples like this one with a constructor with dom strings in it and the transforms.

<richardschwerdtfeger> smfr: when you are inputing a string where it the text for the conversion into the matrix

<richardschwerdtfeger> krit: that is why issue 3 is there

<richardschwerdtfeger> … I think it is ok to put an example in

<richardschwerdtfeger> krit: if we keep it I will extend the example

<richardschwerdtfeger> krit: for SVG it might not be a problem because SVG 1 is already a recommendation

<richardschwerdtfeger> erik: if you translate 2020 to 20px

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html#widl-Matrix-translate-Matrix-double-tx-double-ty-double-tz

<richardschwerdtfeger> … trying to learn the voices

<richardschwerdtfeger> :-)

<ed> Constructor (DOMString transformList),

<richardschwerdtfeger> krit: this takes double

<ed> new Matrix("translate(20,20)") something liek that

<richardschwerdtfeger> krit: yeah that works. you don't have units for the pixel

<richardschwerdtfeger> krit: one for presentation and one for CSS presentation attributes. We can't say we have a relaxed syntax for the DOM string as well.

<richardschwerdtfeger> krit: we have 2 different syntaxes at the moment - one relaxed and one strict

<richardschwerdtfeger> smfr: we can decide what people want?

<richardschwerdtfeger> krit: I don't see why the CSS wg would object to that.

<richardschwerdtfeger> erik: do we publish this?

<richardschwerdtfeger> krit: yes

<richardschwerdtfeger> RESOLUTION: SVG WG wants to publish Transformation matrix interface spec as a first public working draft

<richardschwerdtfeger> Dean: why don't we ask to publish it as a first public working draft?

<richardschwerdtfeger> thanks

<richardschwerdtfeger> ACTION: Krit mail the spec. to the effects list and have David Barron review. [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action01]

<trackbot> Created ACTION-3470 - Mail the spec. to the effects list and have David Barron review. [on Dirk Schulze - due 2013-03-14].

<richardschwerdtfeger> http://dev.w3.org/csswg/css3-transforms/

SVG2 publication status

<richardschwerdtfeger> krit: I will reference HTML5 vs. the working draft

<richardschwerdtfeger> erik: put an action on me to make that happen

<richardschwerdtfeger> erik: I will contact the appropriate people to make it publish

<richardschwerdtfeger> nikos: Any idea why my changes would not result in a notification?

<ed> ACTION: erik to follow up on getting the SVG2 WD published, run linkchecker etc [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action02]

<trackbot> Created ACTION-3471 - Follow up on getting the SVG2 WD published, run linkchecker etc [on Erik Dahlström - due 2013-03-14].

<richardschwerdtfeger> Rich: Can I touch the spec. since you are taking it to public working draft

<richardschwerdtfeger> krit: can we reference a specific version in Mercurial?

<richardschwerdtfeger> erik: wait until we get this published

<richardschwerdtfeger> nikos: Once publication has happened, we will need to remove highlighting for changes since last WD 1, in preparation for editing for WD 2

<richardschwerdtfeger> erik:

Pseudo stacking context for 2D transformations

<richardschwerdtfeger> smfr: do not address to day and leave on mailing list

<richardschwerdtfeger> erik: OK

Masking

<richardschwerdtfeger> krit: all masks are clipped at the moment

<richardschwerdtfeger> krit: I would like to ask if we could skip this binding and use the bounding box. … an unbound mask

<richardschwerdtfeger> Krit: only place - filters are bound.

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#MaskElementXAttribute

<richardschwerdtfeger> smfr: I don't have any problems with masks being unbounded.

<richardschwerdtfeger> krit: the default value matching is 10%

<richardschwerdtfeger> erik: ah ok

<richardschwerdtfeger> smrf: I think this important in HTML where you may be masking and the content overflows and you don't want the content to get clipped by the mask

<richardschwerdtfeger> krit: the clipping could effect the content

<richardschwerdtfeger> erik: to me it sounds better to use the unbounded one but I guess that is something to look at to see how much content is effected

<richardschwerdtfeger> erik: guess not that much

<richardschwerdtfeger> krit: how do we get data as to whether content is effected in a negative way.

<richardschwerdtfeger> erik: this does not affect explictly set x, y with height.

<richardschwerdtfeger> krit: yes

<richardschwerdtfeger> erik: I guess one way to look at it would be see what authoring tools output.

<richardschwerdtfeger> erik: I don't think there is going to be much of a problem

<richardschwerdtfeger> krit: do we want to get to a resolution or delay that

<richardschwerdtfeger> erik: I think it would be fine to have the spec. allow it and deal with any concerns at the next draft

<richardschwerdtfeger> krit: next version should be the last call

<richardschwerdtfeger> erik: do you see any problem along that or the other way around

<richardschwerdtfeger> krit: there is the property called mask .. maskclip but this does not apply to the mask element

<richardschwerdtfeger> erik: I don't have a strong opinion

<richardschwerdtfeger> erik: any objections to having unbounded masks?

<richardschwerdtfeger> RESOLUTION: allow unbounded masks and see what we get back from last call

<richardschwerdtfeger> krit: CSS X, y, and height . Is it ok that we don't specify them in SVG2 and not in this specification?

<richardschwerdtfeger> erik: I think that is probably fine

<richardschwerdtfeger> erik: so at the moment there is nothing to reference

Filter Effects

<richardschwerdtfeger> @support rule for filter effects extension

<richardschwerdtfeger> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#support-condition-filter

<richardschwerdtfeger> krit: I put this on the mailing list

<richardschwerdtfeger> erik: Ok so follow up with the discussion on the mailing list

Make filter regions unbound

<richardschwerdtfeger> krit: the only problems as we have some filter effects that produce infinite boundaries

<richardschwerdtfeger> krit: things like lighting filters or inputs could be effected

<richardschwerdtfeger> krit: this filter has a drop shadow

<richardschwerdtfeger> krit: we still have the 10% margin and everything outside gets clipped awayu

<richardschwerdtfeger> erik: I agree this problem has been up for discussion a number of times

<richardschwerdtfeger> erik: for example feFlood has unbounded output, so can just fill the viewport e.g

<richardschwerdtfeger> krit: there can be problems. I would write a proposal where there could be problems and with a solution for that. Is it worth it for me to do that or is it too difficult to be specified

<richardschwerdtfeger> erik: we have a sort of unbounded filter region already with filterUnits=userSpaceOnUse, requires impls to optimize otherwise perf is really bad

<richardschwerdtfeger> erik: I think it would be much of a problem to run a similar filter on this

<richardschwerdtfeger> krit: can you and I work on that?

<krit> ACTION: ed and krit to work together on an unbound filter proposal [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action03]

<trackbot> Created ACTION-3472 - And krit to work together on an unbound filter proposal [on Erik Dahlström - due 2013-03-14].

<krit> ACTION: krit to work together on an unbound filter proposal [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action04]

<trackbot> Created ACTION-3473 - Work together on an unbound filter proposal [on Dirk Schulze - due 2013-03-14].

Publication of new WD

<richardschwerdtfeger> Erik: I don't have any problems with publishing a new working draft

<richardschwerdtfeger> Rich: would like to get tabindex out in a public working draft

<richardschwerdtfeger> rich: never mind

<richardschwerdtfeger> :-)

<richardschwerdtfeger> RESOLUTION: publish a new working draft of the filter effect spec.

<richardschwerdtfeger> ACTION: krit create the public working draft [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action05]

<trackbot> Created ACTION-3474 - Create the public working draft [on Dirk Schulze - due 2013-03-14].

<scribe> scribenick: cabanier

Referencing the HTML spec

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0055.html

richardschwerdtfeger: I started working on tabindex

… we found a number of interesting points that we need to agree on

<richardschwerdtfeger> 1. Do you agree that the way event listeners are registered in SVG and HTML

<richardschwerdtfeger> should be the

<richardschwerdtfeger> same? -- both should support `element.addEventListener("click", ...)` and

<richardschwerdtfeger> `element.onclick = ...`. (The latter needs some spec work still, but

<richardschwerdtfeger> implementations all support this.)

richardschwerdtfeger: this discussion, should we follow the same scheme for eventl listener like html

… how are they registered in svg 1

<ed> rich, did you see my response here: http://lists.w3.org/Archives/Public/www-svg/2013Feb/0061.html (please keep technical discussions on the www-svg list)

krit: it should not be different

ed: it should work the same, yes

… did you see my reply

… I responded to some of your points

richardschwerdtfeger: I didn't see that

<richardschwerdtfeger> 2. There are some inconsistencies between the events SVG defines to fire

<richardschwerdtfeger> > and those in HTML. We need to be harmonizing these and

<richardschwerdtfeger> > should do it for SVG 2.

… number 2, there are inconsistencies. we have focus out in svg 2 but HTML has onblur

… should they be consistent or should there be a mapping

krit: onfocus is already used. can we have them in parallel or should we map them?

richardschwerdtfeger: not sure.

ed: it should be possible to map them. they are different event

<richardschwerdtfeger> This is about SVG not having the focus and blur events, right? I think SVG

<richardschwerdtfeger> should have them. Feel free to add a complete list of the inconsistencies

<richardschwerdtfeger> you found.

richardschwerdtfeger: since we're sharing the same dom, should we have the same events?

krit: so, if onfocus fires, onblur should fire too

richardschwerdtfeger: yes.

… SVG didn't have keyboard focusable events

krit: blur is for mouse

richardschwerdtfeger: we do have the anchor

… what do we want to do for that?

… should the spec say that they're the same

ed: they are 2 different events

… I don't see a problem with allowing both and then mapping them so old and new content

… one might fire after the other

richardschwerdtfeger: OK

… so maybe only 1 event listener

ed: no, you can have listener for both events

… I'm not sure if they're connected right now but they could be

richardschwerdtfeger: where would the event stop. would it go outside the svg container?

ed: with an iframe?

richardschwerdtfeger: we have an svg doc in a html doc. the onblur in the svg is not processed. does it go up?

ed: if the svg is inline, yes, it should

richardschwerdtfeger: …(?)

… if we have onfocus out and onblur and nothing captured them, only onblur would get out because onfocus is not recognized by the parent

<ed> not sure that's correct

<ed> events typically bubble regardless of the event type if they bubble

… the next one is: how do the document and window align between html and svg

… what if you have a reader that only supports SVG. how much of HTML do we have to implement?

… Cam, suggested the following text:

<richardschwerdtfeger> Cam suggested the following intorductory text:

<richardschwerdtfeger> >

<richardschwerdtfeger> > Conforming SVG interpreters are not required to implement HTML;

<richardschwerdtfeger> > however, some specific features of HTML are required to be

<richardschwerdtfeger> > implemented.

<richardschwerdtfeger> >

<richardschwerdtfeger> > And then later in the spec:

<richardschwerdtfeger> >

<richardschwerdtfeger> > A conforming SVG interpreter that does not also implement HTML

<richardschwerdtfeger> > must implement the following IDL fragment:

<richardschwerdtfeger> >

<richardschwerdtfeger> > partial interface Document {

<richardschwerdtfeger> > readonly attribute Element? activeElement;

<richardschwerdtfeger> > };

<richardschwerdtfeger> >

<richardschwerdtfeger> > The activeElement attribute must have the same behavior as

<richardschwerdtfeger> > described in HTML. [with a link to HTML's definition of

<richardschwerdtfeger> > activeElement]

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/www-svg/2013Feb/0061.html

<richardschwerdtfeger> Document element Interface: https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument

<richardschwerdtfeger> DOM Document element Interface: http://www.w3.org/TR/2012/WD-dom-20120405/#interface-document

<richardschwerdtfeger> HTML5 Document element Interface: http://www.w3.org/html/wg/drafts/html/CR/dom.html#the-document-object

krit: is it part of the integration spec?

richardschwerdtfeger: I posted 3 links

… we would say to add this text for SVG to the document object

… for SVG standalone, you'd have these properties

… does that make sense?

krit: I think I have an action on this

… we already relying on the document interface of HTML5

richardschwerdtfeger: so, you're referring to the document object of htmk5

krit: yes. I have an action to add the link

richardschwerdtfeger: you want this spec:

<richardschwerdtfeger> http://www.w3.org/html/wg/drafts/html/CR/dom.html#the-document-object

richardschwerdtfeger: that's the cr version

krit: ah. I think I have the wrong one then

… I'm using the partial interface

… HTML5 is relying on the definition of DOM (?)

… this is a problem. We have dom4 now

<richardschwerdtfeger> https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument

richardschwerdtfeger: this is the current spec

… I need the activeElement to be there

krit: If we say document is an HTMLDocument

richardschwerdtfeger: we have other things in here

<richardschwerdtfeger> partial interface Document {

<richardschwerdtfeger> readonly attribute DOMString title;

<richardschwerdtfeger> readonly attribute DOMString referrer;

<richardschwerdtfeger> readonly attribute DOMString domain;

<richardschwerdtfeger> readonly attribute SVGSVGElement rootElement;

<richardschwerdtfeger> };

… this is what we currently have

… and we want to add activeElement

… and it's not in DOM4

krit: is it in html5?

http://www.w3.org/html/wg/drafts/html/CR/editing.html#dom-document-activeelement

who is editing dom4?

richardschwerdtfeger: I don't know

krit: could you follow up?

<krit> s/up/up with Anne van Kesteren/ ?

https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

krit: can you follow up with Anne and other?

… ms2ger is also good

richardschwerdtfeger: for publishing, you might want to add the right link

… here it is:

<richardschwerdtfeger> http://www.w3.org/TR/dom/

… do we need title, referrer, domain in dom 4?

<scribe> ACTION: richardschwerdtfeger to ask HTML WG and Anne to add activeElement to their spec [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action06]

<trackbot> Error finding 'richardschwerdtfeger'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: rich to ask HTML WG and Anne to add activeElement to their spec [recorded in http://www.w3.org/2013/03/07-svg-minutes.html#action07]

<trackbot> Created ACTION-3475 - Ask HTML WG and Anne to add activeElement to their spec [on Richard Schwerdtfeger - due 2013-03-14].

<richardschwerdtfeger> 4. When HTML refers to tab navigation it indicates the elements that can

<richardschwerdtfeger> receive focus without using tabindex. Examples are command, input, and

<richardschwerdtfeger> anchor elements. Cam and I think this is fine if the UA does not implement

<richardschwerdtfeger> HTML and therefore won't be doing anything with <html:input> elements for

<richardschwerdtfeger> example, then it doesn't matter if they are focusable by default or not.

<richardschwerdtfeger> Yet, in terms of defining that <svg:a> is focusable by default, we might

<richardschwerdtfeger> need to get HTML to change there -- either by having a hook that we can

<richardschwerdtfeger> refer to from SVG to state that <svg:a> is focusable by default, or just by

<richardschwerdtfeger> HTML defining it so. Do people agree we should define this in HTML?

richardschwerdtfeger: we might need to html to change their spec

ed: svg tiny already does define that elements are focusable

richardschwerdtfeger: do you want to put that in our spec that certain elements are focusable?

ed: that would make more sense.

richardschwerdtfeger: are there others that are focusable in tiny?

ed: yes, you could do it on any element.

richardschwerdtfeger: we were using tabindex

ed: we can see if it can be made compatible

richardschwerdtfeger: tabindex of −1 would change the tab order

… would this change the tab order?

ed: yes

richardschwerdtfeger: so it's equivalent to tabindex 0

… so you think we should say something like that?

ed: yes

<richardschwerdtfeger> rich: so focusable is equivalent to tabindex="0" in DOM order sequential navigation

richardschwerdtfeger: do we need to say anything in the HTML spec since anchor is alreadu focusable

ed: I'm unsure. aspects in the model are not defined

richardschwerdtfeger: yes, that's the browser context

…. if we need to go to the html wg we can do that

<richardschwerdtfeger> 5. The HTML5 spec. defines how to process browsing contexts. IOW documents

<richardschwerdtfeger> in a document when it comes to sequential navigation. Do people agree we

<richardschwerdtfeger> can just refer to the HTML5 definition of browsing context? This will also

<richardschwerdtfeger> be important when we embed <iframe>s in and SVG document per the face to

<richardschwerdtfeger> face.

<richardschwerdtfeger> This was the approach I was going to take when adding tabindex.

richardschwerdtfeger: do people agree that we refer to browsing context when we do sequential navigation?

ed: yes

krit: yes

richardschwerdtfeger: ok, we'll refer to HTML5 and go from there

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/tip/default/
Succeeded: s/dino/smfr/
Succeeded: s/might/might not/
Succeeded: s| /query smfr||
Succeeded: s/public/publish/
Succeeded: s/the spec/Transformation matrix interface spec/
Succeeded: s/Ken/Dean/
Succeeded: s/SVG/SVG WG/
Succeeded: s/smfr/cameron/
Succeeded: s/cameron/nikos/
Succeeded: s/smfr/nikos/
Succeeded: s/we should highlight the changes since the last working draft/Once publication has happened, we will need to remove highlighting for changes since last WD 1, in preparation for editing for WD 2/
Succeeded: s/effect/affect explictly set/
Succeeded: s/maskclip/maskclip but this does not apply to the mask element/
Succeeded: s/reference it/specify them in SVG2 and not /
Succeeded: s/for example just be as big as ever/for example feFlood has unbounded output, so can just fill the viewport e.g/
Succeeded: s/we have some sort of unbound filter region already/we have a sort of unbounded filter region already with filterUnits=userSpaceOnUse, requires impls to optimize otherwise perf is really bad/
WARNING: Bad s/// command: s/up/up with Anne van Kesteren/ ?
Succeeded: s/yet/yes/
Found Scribe: Rich
Found ScribeNick: cabanier
Default Present: Rich, [IPcaller], ed, cabanier, hober, smfr, dino, krit, +33.9.53.77.aaaa, Tav, +61.2.980.5.aabb, nikos
Present: Rich [IPcaller] ed cabanier hober smfr dino krit +33.9.53.77.aaaa Tav +61.2.980.5.aabb nikos
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0064.html
Found Date: 07 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/07-svg-minutes.html
People with action items: ed erik krit rich richardschwerdtfeger

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.