SVG Working Group Teleconference -- 17 Oct 2013

<trackbot> Date: 17 October 2013

<stakagi> zakim ??P6 is me

<scribe> scribenick: nikos

Publish CSS Masking as LCWD

krit1: Can we publish?

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

krit1: short summary about changes
... syntax hasn't changed except one exception
... initial draft supported multiple layers of mask
... question was if it's possible to combine different masks or if it would be mask on mask
... so we delayed layers to next level until this is workedo ut

heycam: so you can only specify one layer

krit1: yes
... having multiple mask layers can be useful but how do you combine the mask?
... in webkit, you mask with each in turn
... but you might want to combine masks and then apply
... needs to be discussed more
... not worth waiting

heycam: should be possible to define the first process you said? applying masks in turn
... should be possible to compute a single mask that does that?

krit1: the problem is you always lose something
... imagine having a composite operator between the masks and then apply the result

heycam: I think it's fine to leave that to later

cyril: what is the difference compared to what svg had in the past?
... are features different or just css integration?

krit1: the idea was to have a spec for html and svg world
... yes when combined with mask-box
... no because you could do a lot of things with svg mask element that you can now do with masking using an image
... it gets easier, but not necessarily more powerful

birtles: we do have alpha and luminance masking

krit1: both are implemented in webkit as of a couple of weeks ago

<birtles> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0056.html

birtles: did you see the discussion on public-fx on how how the properties are animated?

krit1: all properties define if animatable or not
... what will work on mask properties will also apply to background properties
... mask-box-image-slice is not animatable at the moment

heycam: is the background version of image-slice property animatable?

krit1: yes it's called border-image-slice

heycam: why is the mask one not animatable?

krit1: I think it's the auto value cannot be animated
... but I think maybe it could be

RESOLUTION: publish LCWD of CSS Masking.

heycam: which group will handle publication?

krit1: I asked ChrisL to handle it

Should perspective affect object bounding box of SVG elements?

krit1: object bounding box is a construct we have in svg for a long time
... it's the union of all bounding boxes of it's children including transforms
... as an example. You have group element with child rect. Child rect has scale of 2 then bounding box of the rect will be twice as big for the group element
... CSS transforms we have a lot more properties
... importantly, persepective and perspective-origin
... the persepective has percentage values
... the spec currently says for all properties, percentage values are resolved against object bounding box
... if the object bounding box includes perspective there is a circular dependency
... one option is to stick to definition of svg 1.1

heycam: that means ignoring the transform property and all of the other perspective
... can you remind me what is the plan for transform presentation attribute and property?
... are they meant to be the same thing?

krit1: transform attribute will be presentation attribute
... that means for transform property we have cascade
... so you could just look at the presentation attribute not the whole cascade
... I don't think we should go that way though

heycam: I agree

krit1: other solution is object bounding box does not included perspective
... so that we do not have the problem resolving
... third solution - all percentage values are resolved against the viewport

heycam: do we have to consider the transform properties because we might have the individual perspective properties in that list?

krit1: I don't think that's a problem. They apply as a transform function
... no dependency on parent or child

heycam: if you have transform-origin with percentage values and transform property with list and one is a perspective
... would there be a cyclic dependency?
... what's different?

krit1: transform just takes transform functions that are multiplied together
... persepective is not an exception
... it's just another function
... I would suggest we look at the 3d part
... for getting the bounding box
... perspective property on other hand is devised from the parent
... parent perspective multiplied by transform of current element
... that's the difference
... between perspective function and property
... I don't think it's actually that useful

heycam: option 2 was to ignore perspective property when calculating the bounding box
... is that all situations (getBBox as well as bounding box for gradients for example)

krit1: it should be all situations
... the problem with option 3 is it's not intuitive
... and doesn't fit well with html world
... would also be different to transform and transform-origin

heycam: if you add a small amount of perspective and transform-origin is in a different position, that would be bad

krit1: in general perspective and 3d transforms are complex
... can wait on a resolution if people need time to digest

heycam: my feeling is that number 2 sounds like the best

krit1: I'd be in favour of 2

heycam: in html if you have perspective and call getClientRect
... how does that work with perspective, etc

krit1: main difference is that getClientRect does not included transforms

heycam: is there no function for getting actual bounding box with transforms in html?

krit1: transform doesn't modify the layout

<krit1> shepazu: speak!

shepazu: you're talking about whether perspective should change getBBox()?
... Dirk you were saying no?

krit1: correct
... perspective on child element comes from the parent. Problem is that perspective can have percentage values that need to be resolved against object bounding box. But object bounding box needs the percentage values to be calculated
... bounding box inclueds the size of transformed children, but not the transform on the actual element

s/is modified by/inclueds/

shepazu: I'd like to see it written up

krit1: we need a solution for resolving the dependencies

heycam: the issue is when you use percentage values in transform-origin and the percentages are relative to the shape you are transforming. But the perspective can change the bounding box of the shape being transformed
... so there's a cyclic dependency

shepazu: there's an internal way of getting the bounding box right?
... but that's not what we're exposing to the user
... we are exposing a convenience function

heycam: the issue isn't calculating the bounding box. The issue is having the percentage values influence the bounding box
... this isn't the case for regular transforms or html content

shepazu: I'd like to see a diagram of this to clarify

krit1: the browser has this problem internally
... we could move discussion to the mailing list? I tried to explain on public-fx

shepazu: there's the bounding box - the internal calcualtion of this
... and the return value of the get bounding box function exposed to users
... they don't have to return the same result
... we could introduce a change to affect this
... I'll try to explain
... let's say we have a new bounding box function getBBox2
... it can return whatever we want because there's no dependency chain

krit1: it can't be calculated internally
... we expose exactly what we calculate internally

heycam: implementations at the moment. If they supported 3d transforms on SVG. There is no way to mathematically resolve the percentage values

shepazu: I think we're talking about two different issues

[heycam summarises]

krit1: let's continue on the mailing list

Confirm location and dates for 1st F2F of 2014

heycam: Dirk you've been co-ordinating with CSS?

krit1: CSS group is happy to meet for half day as I said previously
... fx on second half of 29th Jan
... SVG on 30-31 Jan
... in Seattle
... I've booked the rooms

RESOLUTION: SVG WG will meet in Seattle 30-31 January 2014 with FX half day on 29th January

SVG Glyphs in OpenType specification

heycam: There was a second coloured fonts meeting which Chris was at
... he sent a summary to the list
... that was one of the reasons Sairus wanted the spec stabilised
... the spec will serve as introduction to the discussion for ISO in January
... so that was the point of moving the community group draft to spec text

cyril: Chris is saying there are 4 proposals
... Microsoft's, Apple's, etc

heycam: Google and Apple are bitmap formats
... Google is something like embedding PNGs
... Microsoft has solid coloured filled vectors

cyril: in terms of process. There's a call for proposals in ISO
... how does the community group satisfy the requirements?

heycam: someone needs to write up a document addressing how the specification matches each requirement
... there are requirements around lower power devices
... it seems the list of requirements covers all the bases

http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0020.html

cyril: I think normally one is picked to continue and the interesting parts of others are merged in

nikos: there's already been some merging - Microsoft palettes into SVG in OT

heycam: one font could have the palette table plus Microsoft's multi coloured glyph table and SVG and use the palette in both

krit1: benefits of the other proposals are that they are easy to implement in the font system
... but they do not have animations or things like that

nikos: but there's no way to specify a colour that wasn't already defined in the font?

shepazu: Does Adobe have a position?

krit1: I'm not sure. Sairus is obviously working on SVG in OT but I don't know if it's personally motivated or on behalf of the company

cyril: who will be representing SVG in OT at the MPEG meeting?

heycam: I'm not sure
... in San Jose so convenient for Sairus

cyril: meeting is 13th-17th
... I will be there

- DRAFT -

SVG Working Group Teleconference

17 Oct 2013

Attendees

Contents

Publish CSS Masking as LCWD

Should perspective affect object bounding box of SVG elements?

Confirm location and dates for 1st F2F of 2014

SVG Glyphs in OpenType specification

Summary of Action Items

Scribe.perl diagnostic output