- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 09 Jan 2015 08:36:26 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes for the telcon are here: http://www.w3.org/2015/01/08-svg-minutes.html and below as text. [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 08 Jan 2015 [2]Agenda [2] http://lists.w3.org/Archives/Public/www-svg/2015Jan/0009.html See also: [3]IRC log [3] http://www.w3.org/2015/01/08-svg-irc Attendees Present [IPcaller], ed, heycam, Doug_Schepers, stakagi, +1.425.463.aaaa, birtles, krit, Rich_Schwerdtfeger, cabanier, nikos, Tav, Thomas_Smailus Regrets Chair Cameron Scribe Cameron Contents * [4]Topics 1. [5]SVG 2 assessment 2. [6]SVG Hinting * [7]Summary of Action Items __________________________________________________________ <trackbot> Date: 08 January 2015 <stakagi> zakim ??P5 is me <heycam> ScribeNick: BogdanBrinza First topic: transform on svg / ed <ed> [8]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0003.htm l [8] 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> [9]http://jsfiddle.net/6pnnkoz3/5/ [9] http://jsfiddle.net/6pnnkoz3/5/ <ed> <svg style="transform:scale(2)"> <ed> <circle cx="50%" cy="50%" r="25%" fill="blue"/> <ed> </svg> <ed> [10]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0013.ht ml [10] 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 [11]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> [12]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.ht ml [12] 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 [13]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 [14]http://www.w3.org/2015/01/08-svg-minutes.html#action03] <trackbot> Error finding 'Get'. You can review and register nicknames at <[15]http://www.w3.org/Graphics/SVG/WG/track/users>. [15] 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 [16]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 Summary of Action Items [NEW] ACTION: Bogdan Get the SVG 2 issues document on the wiki with Doug's help [recorded in [17]http://www.w3.org/2015/01/08-svg-minutes.html#action04] [NEW] ACTION: ed to call out transforms working the way we resolved as new feature [recorded in [18]http://www.w3.org/2015/01/08-svg-minutes.html#action01] [NEW] ACTION: ed to get tests that would show what implementations are doing with transforms in fragments now [recorded in [19]http://www.w3.org/2015/01/08-svg-minutes.html#action02] [NEW] ACTION: Get the SVG 2 issues document on the wiki with Doug's help [recorded in [20]http://www.w3.org/2015/01/08-svg-minutes.html#action03] [End of minutes]
Received on Thursday, 8 January 2015 21:37:03 UTC