SVG Working Group Teleconference -- 08 Jan 2015

<trackbot> Date: 08 January 2015

<stakagi> zakim ??P5 is me

<heycam> ScribeNick: BogdanBrinza

First topic: transform on svg / ed

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Dec/0003.html

The link clarifies the transform as a property

though not clear how it should be applied

how to put this on fragment for example

birtles: So how to apply it to fragments?

ed: Few option - apply inside/ outide svg

if that's defined in style - apply this as part of normal SVG layout

Firefox currently the only who does that as part of layout

birtles: Useful distinction of style transform vs property

ed: suggestion - so we need to describe in SVG spec how that is supposed to work

2. we need to agree how it's supposed to work

e.g. attribute should work the same as style transform

have we discussed before the viewbox and the order of transforms on the element

for example everybody agrees that porperty should apply as the attribute

but if one has viewBox and transform - which order do those apply

ed: Would expect transform spec should define this

Dirk: can add this as it's currently does not mention SVG element

* <svg> element

SVG embedded in HTML is normal HTML element and outer transform would apply first then viewbox would apply to root element inside

tav: that is easy way to describe this

Dirk: <svg> is special because it has viewbox attribute
... but transform does nothing to <html> element

and for <svg> that might be confusing

So if I have a style on svg root that says transform: scale

in HTML context that would be scaled and in standalone context wouldn't be?

Tav: right

but from authoring perspective it's inconsistent when it applies vs when it doesn't

Tav: consider svg as a viewport on the other content, so transforms would apply outside

We should do whatever html is doing for the root element - so <svg> should act as if transform is applied as to outside element

and panning and zooming should be described in the same sense - not as changing viewport, but as a transform on the root

<Smailus> Apologize... stuck in another meeting; will be on shortly.

ed: the order of the transform does matter and there were some equations how we're supposed to zoom

Eric do you know what implementation supports transform on svg element?

As attribute only Firefox currently supports that, as style property - other browsers

<ed> http://jsfiddle.net/6pnnkoz3/5/

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Dec/0013.html

<richardschwerdtfeger> ok

<richardschwerdtfeger> next week it is

Bogdan: looking at the sample IE is the same as Chrome and Eric mention other browsers as the same

ed: the follow up is to agree that transform should apply from outside

and both cases html/standalone should work the same way

ed: would like to fix those resolutions

Any objections to have property and style attrubute work the same on <svg> element and apply outside?

(no objections)

RESOLUTION: transform property applies conceptually to the outside of <svg> element and there is no difference between prsentation attribute and style property

we can be more clear in SVG spec to call this as new feature

also might be in transform spec as well

<scribe> ACTION: ed to call out transforms working the way we resolved as new feature [recorded in http://www.w3.org/2015/01/08-svg-minutes.html#action01]

<trackbot> Created ACTION-3691 - Call out transforms working the way we resolved as new feature [on Erik Dahlström - due 2015-01-15].

<ed> #svgVIew(viewBox(...))

ed: If you specify svg viewBox as attribute in style and transform all on root element

how would that apply - in what order

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.html

this came as complaints from some old testsute

correction: the above combination is of transform and fragment, not style attribute

if you give transform fragment syntax and make this apply inside svg element

this might be confusing on how this is supposed to work

ed: the spec doesn't clarify how this is supposed to work especially in combination with viewBox

currently if you specify fragment that would override transform you had, same should apply to viewBox

what implementation support tranform on the root?

ed: I would guess this would work like html root

we need to know implementations that support transforms in fragment declaration and how this interacts with attribute

ed: the worry is real usage - transform + svgView syntax

how likely we'll see somthing like this?

so we'd like to see what we all are doing here at the moment

<scribe> ACTION: ed to get tests that would show what implementations are doing with transforms in fragments now [recorded in http://www.w3.org/2015/01/08-svg-minutes.html#action02]

<trackbot> Created ACTION-3692 - Get tests that would show what implementations are doing with transforms in fragments now [on Erik Dahlström - due 2015-01-15].

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

SVG 2 assessment

BogdanBrinza: I have a document that I want to put somewhere
... Rossen and I put this together
... we spent some time looking at the issues/actions
... we tried to put some "readiness" of different parts of the spec
... I want to put this document in front of us soon
... there are some big parts that have more problems/instability than others
... so I'd like to get some more attention to them
... the first chapter with the most issues is the Document Structure chapter
... specifically, <svg>, <desc>, <title> and Conditional Processing
... looks like it has lots of issues
... the next one is Text, and specifically shape-inside property
... next is Painting chapter, particularly dashing
... it looks like the new properties added have some issues that need resolving
... the last big one is Paint Servers; it doesn't have any particular area that sticks out, but the first half has a bunch of open issues
... I can put this spreadsheet on the wiki
... it would be worth looking at the specific issues and working to resolve them
... around 50 issues
... I'll follow up with specific issues on the mailing list

Zakim: ack

shepazu: I have some experience with wiki tables, if you send me the document I'll convert it into a wiki table quickly

BogdanBrinza: off topic, we also made some progress on SVG Hinting
... with some specific proposals

krit: I added/opened some issues on the GitHub page for the spec
... so that's also an option

shepazu: yeah, I think it's a good idea to have this spreadsheet that summarises everything. but we should break it out.
... those things we all agree, we should break out to individual issues on the spec

ed: Bogdan, you went through the spec; did you mostly look for issues called out in the spec? or were you looking for reviewing / finding issues outside of those already mentioned?

BogdanBrinza: both
... we looked at the spec with fresh eyes
... there's a correlation; if there were issues called out on a section, then there were concerns we had already
... this came up particularly in the Painting chapter
... those comments will be in the spreadsheet

ed: to the group: how do we want to handle FIXMEs in the spec? issues in the spec, or a bug tracker?

heycam: I put issues inline in the spe

spec

scribe: but I don't mind them being tracked in GitHub issues or whereever

Tav: I like them being in the spec

krit: that's fine, but for issue discussion it's not good

ed: the issue numbers change too

heycam: we can keep the inline notes and link them to whereever we're having the discussion

Tav: I'll be spending more time on spec editing over the next month

<scribe> ACTION: Get the SVG 2 issues document on the wiki with Doug's help [recorded in http://www.w3.org/2015/01/08-svg-minutes.html#action03]

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

<scribe> ACTION: Bogdan Get the SVG 2 issues document on the wiki with Doug's help [recorded in http://www.w3.org/2015/01/08-svg-minutes.html#action04]

<trackbot> Created ACTION-3693 - Get the svg 2 issues document on the wiki with doug's help [on Bogdan Brinza - due 2015-01-15].

SVG Hinting

BogdanBrinza: one thing Chris Lilley mentioned was how implementations depending on scale factors, non-integer pixel scaling issues
... one of the way to improve that was making sure paths/lines end up at integer pixels when you start or end the line/path
... that by itself would address a large body of the feedback
... likewise, we do want to prototype something to better align shapes
... including nearby shapes
... using some simple heuristics, e.g. if the shapes are grouped together with <g> you might try harder to ensure they're rendered at the same pixel

shepazu: for example if there are two states with a common border, you want to signal that they share a common border if they're transformed

BogdanBrinza: instead of signalling, you could know this by the document structure and ordering
... so an implementation detail on how we can improvde the rendering without requiring additional markup

shepazu: you're saying do it automatically. would that be implementaiton specific? or would we specify that when things are grouped/transformed together, you should use this algorithm to make sure the pixels align

BogdanBrinza: the latter is definitely preferable
... before speccing, prototyping would be good to see how well it works

shepazu: speccing for interoperability, which would be great, in addition to implicit signals we should have an explicit signal because when you're structuring a document you're structuring for different reasons
... you could need to have shapes in different groups for certain reasons

BogdanBrinza: I would agree with that, yes
... we've been looking at a look of CSS/HTML compat issues
... authors are trying to align things but don't get it exactly right
... but yes some authors might want explicit control for this

shepazu: or just optimise according to different signals than the default

Tav: would be good to have before and after images

- DRAFT -

SVG Working Group Teleconference

08 Jan 2015

Attendees

Contents

SVG 2 assessment

SVG Hinting

Summary of Action Items

Scribe.perl diagnostic output