07:16:25 <RRSAgent> RRSAgent has joined #svg
07:16:25 <RRSAgent> logging to http://www.w3.org/2014/04/07-svg-irc
07:16:27 <trackbot> RRSAgent, make logs public
07:16:27 <Zakim> Zakim has joined #svg
07:16:29 <trackbot> Zakim, this will be GA_SVGWG
07:16:29 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:16:30 <trackbot> Meeting: SVG Working Group Teleconference
07:16:30 <trackbot> Date: 07 April 2014
07:16:49 <ChrisL> zakim, remind us in 8 hours to go home
07:16:49 <Zakim> ok, ChrisL
07:18:57 <ChrisL> interesting font demo http://www.babelstone.co.uk/Fonts/ThrorsMap.html
07:24:06 <ChrisL> http://libregraphicsmeeting.org/2014/program/
07:26:14 <davvel> davvel has joined #svg
07:27:11 <heycam> Chair: Cameron
07:27:22 <heycam> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda
07:30:53 <Tav> Tav has joined #svg
07:31:06 <birtles> Scribenick: birtles
07:31:13 <birtles> Scribe: birtles
07:31:31 <birtles> Topic: Charter
07:31:38 <ChrisL> http://www.w3.org/Graphics/SVG/2012/charter
07:31:41 <birtles> ChrisL: our charter has expired just recently
07:31:48 <birtles> ... that's not a problem
07:32:04 <birtles> ... it was pointed out that it was expiring
07:32:11 <birtles> ... but there seemed to be no concern
07:32:21 <birtles> ... I suggest we ask for the same charter as the current but with minor updates
07:32:34 <birtles> ... if we've added/dropped specs, changed WG liaisons
07:32:44 <birtles> ... we need update that
07:32:50 <birtles> ... I suggest we drop liaison from XML Core
07:33:01 <birtles> ... they're not developing any new features, at least none we care about
07:33:07 <birtles> ... we might want to add some new liaisons
07:33:14 <birtles> ... now sure about Oasis, not sure if we're doing anything there
07:33:23 <birtles> ... we've got EPUB but we might want to add the interest group
07:33:34 <birtles> ... there seems to be a lot of activity there at the moment
07:33:40 <birtles> ... we should get requirements from them
07:33:50 <birtles> ... they are mostly feeding into CSS but they might have some for us
07:33:57 <birtles> ... most of the other groups are still going
07:34:07 <birtles> ... we have ICC but I wonder if we should have OpenICC too
07:34:12 <satakagi> satakagi has joined #svg
07:34:22 <birtles> ... it's an organisation but not as formal as ICC
07:34:34 <birtles> ... we have MPEG listed (for SVG-in-OpenType)
07:34:48 <birtles> ... but the rest looks ok but we can drop  the Hypertext Coordination group
07:35:02 <birtles> heycam: not sure about the P&F WG
07:35:09 <birtles> ChrisL: we should keep that liasion
07:35:16 <heycam> s/not sure about/what about/
07:35:29 <birtles> ... the work on accessibility in happenning in the SVG WG
07:35:56 <birtles> krit: our charter is not compatible with the PF WG
07:36:05 <birtles> ... the work should go on there, our goals are not aligned
07:36:11 <birtles> heycam:  we discussed that recently in the telcon
07:36:21 <birtles> ... and said it doesn't really matter where it happens
07:36:40 <birtles> ... but some on the mailing list said that it would be better if those specs where published by bother groups
07:36:45 <birtles> ... like we do for FXTF
07:36:48 <birtles> ... for patent coverage
07:36:55 <stakagi> stakagi has joined #svg
07:38:12 <birtles> heycam: the proposal was for there to be a join TF but the documents would be published under the PF WG
07:38:18 <birtles> ChrisL: what was the reason?
07:38:27 <birtles> heycam: for simplicity and since that item isn't under our current charter
07:38:32 <birtles> ... but given we're rechartering...
07:38:40 <birtles> ChrisL: we do have an item like that under our charter
07:38:43 <birtles> krit: yes
07:38:59 <birtles> ChrisL: there has been other work on accessibility that is going into the SVG spec itself
07:39:04 <birtles> ... what do they want? another note?
07:39:22 <birtles> ... does their document add new features?
07:39:42 <birtles> heycam: I think the primary purpose is to describe the mapping of SVG features when you don't use aria-role
07:39:47 <birtles> ... in HTML they have a table for that
07:39:51 <birtles> ... I think they want that for SVG
07:40:00 <birtles> ChrisL: why don't we just add it to SVG?
07:40:07 <birtles> krit: for HTML I think it's a separate spec
07:40:13 <birtles> cabanier: I think they have both
07:40:19 <birtles> krit: there is some separate document
07:40:44 <birtles> ChrisL: if they want to write a non-normative document with guidelines that's fine
07:40:53 <birtles> ... I'm concerned about them changing SVG
07:40:59 <birtles> heycam: I think it would be normative text
07:41:12 <birtles> krit: I would be concerned if we need to join PF WG just to work on this doc
07:41:24 <birtles> heycam: if there's a TF there should be public mailing list
07:41:36 <birtles> ChrisL: it should be a public mailing list
07:42:33 <birtles> heycam: so should we go back and add this to our charter since we're rechartering?
07:42:41 <birtles> ChrisL: I think that sounds good
07:42:54 <birtles> ... what's the title of the document
07:43:05 <birtles> heycam: SVG2 Accessibility User Agent Implementation Guide
07:43:46 <birtles> ... there is a stub document
07:43:58 <heycam> https://github.com/SVG-access-W3CG/new-note-draft/blob/master/svgaccess.html
07:44:41 <birtles> ACTION: ChrisL to update the charter
07:44:42 <trackbot> Created ACTION-3601 - Update the charter [on Chris Lilley - due 2014-04-14].
07:44:56 <birtles> ACTION: ChrisL to talk to Michael Cooper about UAG
07:44:56 <ChrisL> deliverables www.w3.org/Graphics/SVG/2012/charter
07:44:56 <trackbot> Created ACTION-3602 - Talk to michael cooper about uag [on Chris Lilley - due 2014-04-14].
07:45:10 <birtles> ChrisL: here's a link to the previous charter's deliverables
07:45:14 <birtles> ... it listed SVG2
07:45:22 <birtles> ... what about SVG Parameters
07:45:30 <birtles> ... has that gone away since CSS variables came about?
07:45:45 <birtles> heycam: SVG parameters can do slightly more but I'm not sure there's enough push to do SVG parameters as well
07:45:54 <birtles> ... can be have a section on things we might work on
07:46:04 <birtles> ChrisL: yes, we can have "will work on if time" specs
07:46:14 <birtles> ... SVG integration: we still haven't published that
07:46:23 <birtles> ... there has been discussion of that recently
07:46:43 <birtles> krit: I don't think it has sufficient security support to publish a FPWD yet
07:46:52 <birtles> ... we need to fix the issues first then we should publish it
07:46:56 <birtles> heycam: so it should stay in the list
07:47:48 <birtles> ChrisL: for color management we will keep it in SVG2 for now since the separate spec hasn't been taken up by CSSWG yet
07:48:41 <birtles> ... join work recommendations...
07:49:18 <birtles> ... what about css animations and web animations, does one replace the other or do both get published in parallel?
07:49:25 <birtles> krit: yes, both in parallel
07:49:32 <birtles> ChrisL: then we should add web animations here
07:49:57 <birtles> nikos: we should update the links to the compositing spec
07:50:05 <nikos> http://www.w3.org/TR/compositing-1/
07:50:54 <birtles> birtles: we should also probably add animation elements: https://svgwg.org/specs/animation-elements/
07:51:03 <birtles> ... it's paused at the moment
07:51:20 <birtles> ... but we decided it should go under the SVGWG
07:51:53 <birtles> ChrisL: tiling and layering, did that get added to SVG2?
07:52:02 <birtles> heycam: part of it has, like the iframe stuff
07:52:16 <birtles> ... the media query stuff has been shunted off to the CSS working group
07:52:34 <birtles> stakagi: the zooming module is yet to be added
07:52:42 <birtles> heycam: I think that is covered by the media query work
07:52:51 <birtles> ... is there anything else?
07:52:56 <birtles> stakagi: that's all
07:53:06 <birtles> heycam: so there's no separate document for tiling and layering since it is all in other specs?
07:53:34 <birtles> stakagi: not at this stage
07:54:06 <birtles> heycam: do we need to say where previous items have ended up?
07:54:14 <birtles> ChrisL: that can be in a separate document linked to from the charter
07:54:18 <birtles> ... how about vector effects?
07:54:26 <birtles> ... nothing has happened in the last two years
07:54:35 <birtles> ... are implementors interested in it?
07:55:29 <birtles> pdr: what about the non-scaling stroke discussion
07:56:10 <birtles> ChrisL: we currently have that as the only vector effect, less interest from browsers in doing the full flexible syntax
07:57:00 <birtles> krit: I don't think it's going to happen in the near future
07:57:13 <birtles> ... the current priorities are performance and interoperability
07:58:01 <birtles> (discussing the element-based syntax for vector effects from SVG 1.2 full)
07:58:11 <birtles> ed: there is a standalone spec for this too
07:58:22 <ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
07:58:44 <birtles> ChrisL: there are a number of new elements similar to fe but ve
07:59:01 <birtles> krit: but many of these things can be done with vector-effects/paint-order
07:59:12 <birtles> ChrisL: we seem to be carving off canned effects and putting those in directly
07:59:16 <birtles> ... which is better than nothing
07:59:27 <birtles> krit: we have currentFill etc. are now in SVG2 right?
07:59:30 <birtles> heycam: yes
07:59:37 <birtles> ChrisL:  so should we just drop this for now?
07:59:44 <birtles> heycam: my preference it to keep pushing forward with canned effects
07:59:53 <birtles> ... since it's easier to handle from an implementation point of view
08:00:10 <birtles> ... the element syntax feels heavy weight and I think has held back filter effects adoption
08:00:15 <birtles> krit: I agree, the elements worry me
08:00:33 <birtles> ChrisL: is it easier to implement...
08:00:52 <birtles> heycam: it's easier to implement both because the set of features covered is smaller but also you don't have to track changes to all these different elements
08:01:33 <birtles> ed: so the path reversal is in Path2D?
08:01:45 <birtles> ... I think having a javascript API for this is useful I think
08:01:52 <birtles> krit: does that need to be native though?
08:02:37 <birtles> Tav: it would be good to be able to share path edges in a declarative way
08:02:55 <birtles> ... the other thing we most often get asked for is offsetting the stroke
08:03:09 <birtles> heycam: last time we discussed path referencing was at TPAC last year
08:03:18 <birtles> ... and Cyril had a proposal for a piece command using an ID reference
08:03:25 <birtles> nikos: that didn't actually give you shared edges
08:03:44 <birtles> ... it let you re-use path edges but it didn't actually share them
08:04:04 <birtles> ChrisL: so let's remove vector effects as a separate work item
08:04:41 <birtles> ... rename SVG accessbility item to the SVG2 User Agent Implementation Guide
08:04:46 <birtles> ... about graphics API?
08:05:25 <birtles> heycam: I think that was Doug's idea of an API like canvas that could either produce immediate canvas or declarative graphics
08:05:34 <birtles> ChrisL: that's clearing not happenning so let's drop it
08:05:37 <birtles> ... connectors?
08:05:52 <birtles> Tav: I worked on it a little bit
08:05:59 <birtles> ChrisL: should we keep it around?
08:06:02 <birtles> Tav: yes, I'd like to
08:06:08 <birtles> ChrisL: layout (new)?
08:06:27 <birtles> heycam: I wrote up the requirements but I haven't had a chance yet... might do in the next 2 years though, I'd like to keep it
08:06:36 <birtles> ChrisL: SVG Glyphs for OpenType Font
08:06:54 <birtles> ... the group has formed and passed its work onto the ISO group and then shut down
08:07:05 <birtles> ... so we should just keep it as a liaison
08:08:41 <birtles> ... so remove SVG Glyphs for OpenType Font line item
08:08:47 <birtles> ... pagination and slides?
08:08:59 <birtles> heycam: that was part of the SVG print spec?
08:09:11 <birtles> ChrisL: I saw something about that in the Inkscape meeting
08:09:22 <birtles> Tav: I had a number of people asking about multi-page SVG
08:09:26 <birtles> ... there's demand for it
08:09:52 <birtles> ... I did my presentation with JessyInk which splits up the graphic into slides
08:11:39 <birtles> ChrisL: there is clearly a need for it
08:12:00 <birtles> Tav: I might work on it
08:12:16 <ChrisL> http://dev.w3.org/SVG/modules/mae/master/MediaAccessEvents.html
08:12:18 <birtles> heycam: if someone might work on it, we should keep it
08:12:28 <birtles> ChrisL: media access events
08:12:32 <birtles> ... none of the editors are in the WG
08:12:40 <birtles> ... the spec hasn't been updated for 6 years
08:12:50 <birtles> ... it appears to be totally different to what's happenning in the WebApps WG
08:12:55 <birtles> ... we should drop it
08:13:12 <birtles> heycam: should we publish as a note?
08:13:24 <birtles> ChrisL: yes, publish as a note and drop
08:14:37 <birtles> ACTION: Cameron to publish media access events as a note
08:14:38 <trackbot> Created ACTION-3603 - Publish media access events as a note [on Cameron McCormack - due 2014-04-14].
08:14:47 <birtles> ChrisL: we have Japanese text layout requirements
08:14:54 <birtles> ... that is now published and is finished
08:15:04 <birtles> ... I don't think it needs to be on the charter now since it's done
08:15:32 <birtles> ... since there are now other requirements docs that are coming out (Latin text - EPUB, Indic etc.)
08:15:56 <birtles> ... I think it's difficult to get all the requirements
08:16:04 <birtles> ... but we're not involved in these
08:16:19 <birtles> heycam: are these mostly to do with text or do they involve graphics too?
08:16:28 <birtles> ChrisL: it's mostly text
08:17:14 <birtles> ... anything else to add?
08:17:21 <birtles> heycam: what about the maintenance ones?
08:17:27 <birtles> ... should they continue to be there?
08:17:31 <birtles> ChrisL: yes, they will
08:17:41 <birtles> heycam: can we remove the completed ones?
08:17:50 <birtles> ChrisL: we should keep them since we might need to publish updated versions
08:18:07 <birtles> ... any other documents to add?
08:18:12 <birtles> krit: what about the geometry API?
08:18:33 <birtles> ... Rik, someone from Opera, and I are working on another API
08:18:45 <birtles> ... it hasn't been published as a WD yet
08:18:48 <ed> s/someone from Opera/Simon Pieters from Opera/
08:18:52 <birtles> ... it's an FXTF spec
08:19:01 <krit> Geometry interfaces module: http://dev.w3.org/fxtf/geometry/Overview.html
08:19:05 <birtles> heycam: in the decision policy section in the charter
08:19:18 <birtles> ... we talked about asynchronous decision making recently
08:19:28 <birtles> ChrisL: I have wording prepared for that
08:19:43 <birtles> ... would that be suitable?
08:19:46 <birtles> heycam: sounds good
08:20:15 <birtles> ChrisL: there's a roadmap page on the wiki
08:20:52 <ChrisLilley> ChrisLilley has joined #svg
08:20:54 <ChrisLilley> https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
08:24:03 <birtles> ChrisL: we need to, as a group, keep it up to date
08:24:11 <ChrisL> ChrisL has joined #svg
08:25:04 <birtles> Topic:  ISSUE-2364: SVG2 has not yet defined whether a root element can act as a proximal event target
08:25:30 <birtles> ed: the question is "should the SVG root be a target for pointer events"
08:25:33 <birtles> ... we never defined it
08:25:44 <birtles> ... we purposely made it undefined in 1.1
08:25:57 <birtles> ... we said "we should define it properly in SVG2"
08:26:11 <birtles> ... (it relates to whether you can click the viewport)
08:26:18 <ed> https://svgwg.org/svg2-draft/interact.html#PointerEventsProp
08:26:41 <ed> https://svgwg.org/svg2-draft/interact.html#hit-testing
08:26:46 <birtles> ... actually section 17.5.1 ^
08:26:48 <birtles> ... last paragraph
08:27:12 <birtles> "This specification does not define the behavior of pointer events on the rootmost ‘svg’ element for SVG images which are embedded by reference or inclusion within another document, e.g., whether the rootmost ‘svg’ element embedded in an HTML document intercepts mouse click events; future specifications may define this behavior, but for the purpose
08:27:12 <birtles> of this specification, the behavior is implementation-specific."
08:27:19 <birtles> ... this wording is from the 1.1 spec
08:27:47 <birtles> krit: is SVG image something you embed in the HTML document?
08:28:12 <birtles> heycam: for <img> the whole rectangle it needs to capture clicks on the whole rectangle
08:28:19 <birtles> ed: this is about inline sVG
08:28:39 <birtles> ChrisL: clearly the wording here is confusing
08:28:48 <birtles> heycam: we should define both scenarios anyway
08:29:08 <stakagi> iframe?
08:29:54 <birtles> ed: we need to define the behavior for all scenarios
08:30:10 <birtles> krit: should this definition go into SVG2 or is it fine to have in the SVG2 integration spec?
08:30:24 <birtles> heycam: some stuff still should go in SVG2 such as standalone SVG documents
08:32:02 <birtles> ... the other cases (inline, reference by image, iframe etc.) should probably be covered in the SVG integration spec
08:32:25 <birtles> ... what do implementations do at the moment for top-level document?
08:32:41 <birtles> ed: I think it differs... I think you can use pointer-events but the default setting is different
08:32:52 <birtles> ... I've mostly tested inline
08:33:44 <birtles> ACTION: Erik to prepare spec text for pointer-events on root SVG elements for SVG2 and SVG Integration spec and make edits
08:33:44 <trackbot> Created ACTION-3604 - Prepare spec text for pointer-events on root svg elements for svg2 and svg integration spec and make edits [on Erik Dahlström - due 2014-04-14].
08:33:58 <birtles> ed: do we need to introduce new keyword values?
08:34:06 <birtles> ... bounding box is probably not the right word
08:34:08 <birtles> heycam: probably
08:34:57 <birtles> ... would it be safe to have pointer-events on the root SVG element catch events by default?
08:35:11 <birtles> ed: it's currently not defined
08:35:21 <birtles> krit: It might already work like that
08:35:29 <birtles> ed: we need spec text anyway
08:35:53 <birtles> ... if I find we need a new keyword I'll propose one but I think it's preferable if we don't
08:36:22 <birtles> heycam: looks like it already does that in Firefox and Chrome
08:36:25 <birtles> krit:  and webkit
08:36:32 <birtles> ed: so we just need to define that
08:36:39 <birtles> (break)
08:45:08 <birtles> topic: SVG Sizing
08:46:56 <heycam> presentation https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/
08:48:44 <birtles> davvel (David Vest): I prepared some slides to introduce the problem
08:48:59 <birtles> ... it's about integration of SVG/CSS, how to compute the viewport size
08:49:06 <birtles> ... both the inline case and the external case
08:49:14 <birtles> (goes through the slides)
08:49:50 <birtles> ... case 1: SVG has no fixed width/height, but has a fixed size container
08:50:32 <birtles> ChrisL: I understand what Firefox does, but not why the other browsers using the containing block
08:50:54 <birtles> davvel: I think it's because the default width/height of the SVG is 100%
08:51:09 <birtles> ChrisL: so they're assuming the percentages are CSS percentages when the spec says they're not
08:51:33 <birtles> davvel: Case 2: width only with viewbox
08:51:53 <birtles> ... (i.e. intrinsic ratio)
08:52:28 <birtles> ChrisL: I think Firefox is doing what the spec says
08:52:34 <birtles> pdr: the specs are inconsistent here
08:52:59 <birtles> ... there's no correct solution since there are several contradictory specs
08:54:05 <birtles> davvel: Case 3: external reference, intrinsic ratio, specified height
08:54:14 <birtles> heycam: did you test with iframe (test case uses object)?
08:54:18 <birtles> ... it might differ
08:54:34 <birtles> davvel: I did test with iframe and yes, the behavior was different but I think it should not be
08:54:55 <birtles> ... the results here are totally different
08:55:44 <birtles> ... I've been using the CSS replaced element algorithm as the starting point and SVG and providing input to this algorithm
08:56:45 <birtles> (goes through slides about intrinsic size, ratio etc.)
08:57:18 <birtles> pdr: how do browsers calculate the intrinsic ratio? using the viewBox as you say?
08:57:25 <birtles> davvel: mostly, IE sometimes doesn't always
08:58:56 <birtles> s/sometimes doesn't always/sometimes doesn't/
09:00:12 <birtles> (discussion about the Web compatibility of percentage width/height and why these percentages were defined to be different to CSS percenatges)
09:05:30 <birtles> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=668163
09:06:54 <birtles> pdr: I think this proposal is based on the assumption that NOT mapping SVG width/height to CSS properties is not web-compatible
09:07:00 <birtles> ... and I'm not sure if that's still the case
09:09:22 <birtles> ChrisL: there was also a push to map more attributes to properties for animation purposes
09:10:12 <birtles> davvel: it would be good if we don't have to map width/height to properties
09:10:46 <birtles> (continuing with presentation)
09:14:22 <birtles> krit: with your proposal, the SVG inline case is the same as the SVG image case
09:14:40 <birtles> heycam: what of the comments Jonathan Watt made was, "does that really make sense"?
09:15:04 <birtles> ... for externally referenced files is it sensible to say "this document should take up such-and-such a percentage of where it is embedded"
09:15:14 <birtles> ... since you might embed it in different places
09:15:31 <birtles> ... I think this proposal makes it eaiser for authors to understand what's going on
09:15:41 <birtles> ... but I'm not sure it makes sense
09:16:27 <birtles> davvel: in the Webkit/Blink test suite if you have a percentage on an externally referenced SVG it uses it twice
09:16:36 <birtles> ... IE does it too
09:16:49 <birtles> krit: I like that this proposal lets you choose between the different behaviors
09:17:18 <birtles> ChrisL: also auto is a new value so there shouldn't be a compatibility issue
09:17:33 <birtles> pdr: I think auto is somewhat confusing but if this gets us consistent behavior I'm in favour
09:18:19 <birtles> ... I actually support the presentation mapping. I *didn't* agree with your reasoning for it, but I support the mapping
09:20:37 <birtles> (discussion about the original problem case)
09:21:07 <birtles> heycam: I think in this case the author doesn't want the image to fill up the whole containing block, they should have to mark that up specifically
09:21:23 <birtles> pdr: do you think they wanted 350px150px in that case?
09:21:35 <birtles> heycam: no, I think they didn't say what they wanted
09:21:52 <birtles> davvel: but in that case an iframe would be 350px150px
09:21:59 <birtles> heycam: and it would be good to be consistent with that
09:22:08 <ed> s/350px150px/300x150 px/
09:22:31 <birtles> ... there are no other cases where without an explicit indication the content fills up the whole containing block
09:23:29 <birtles> pdr: there seems to be consensus that davvel's proposal seems good
09:24:05 <birtles> birtles: I find the mapping of width/height to be helpful from a authoring point of view
09:24:27 <birtles> ChrisL: I want SVG to be scalable by default
09:24:47 <birtles> pdr: so this proposal is different is that by default it would fit to 350px x x150px
09:25:15 <birtles> s/is that/in that/
09:26:27 <birtles> krit: I think the behavior is not always great for the user but the consistency is important
09:26:45 <birtles> pdr: what changes are required for this to happen? any changes to CSS?
09:26:52 <birtles> davvel: no
09:27:40 <birtles> ed: what about the changes to CSS 2.1 where it is currently suggestion but should be a requirement?
09:28:32 <birtles> (currently the used value of width in 10.3.2 is undefined and then subsequently defined)
09:29:01 <birtles> ChrisL: I'd like to run it by Tab since I've heard him talk about this before
09:29:36 <davvel> davvel has joined #svg
09:29:51 <birtles> ACTION: ChrisL (or pdr) to get Tab's feedback on davvel's SVG sizing proposal
09:29:51 <trackbot> Created ACTION-3605 - (or pdr) to get tab's feedback on davvel's svg sizing proposal [on Chris Lilley - due 2014-04-14].
09:33:39 <birtles> heycam: if percentages can be resolved to something, can they give you the intrinsic size of the SVG?
09:33:46 <birtles> davvel: no, that's what we want to get rid of
09:34:17 <birtles> heycam: can percentages in an external document be sensibly used when you don't know where it will be embedded?
09:35:22 <birtles> ... it might not always make sense, but I think it's preferable to be consistent
09:35:34 <birtles> ... I don't think there's any other reasonable thing to make those percentages mean
09:36:42 <birtles> ChrisL: if you want to make some SVG is scalable, then you put a viewbox and you either say nothing for width/height or use width:auto;height:auto
09:36:48 <birtles> davvel: that's right
09:37:09 <birtles> ... for the width it will go as big as it can
09:37:15 <birtles> ... and for the height it will use the intrinsic ratio to calculate it
09:37:52 <birtles> ChrisL: if you want to make something a fixed size then you simple say width:3.5in etc. and it will work as expected
09:37:55 <birtles> davvel: right
09:38:18 <birtles> ChrisL: they are the only use cases that matter
09:38:28 <birtles> ... percentages other than 100% never made sense
09:40:12 <birtles> ... the third use case is to make stuff which does not preserve its aspect ratio (e.g. backgrounds)
09:41:56 <birtles> (discussion how this is possible with preserveAspectRatio and 100% width/height etc.)
09:42:03 <birtles> ChrisL: we need a test suite with all the permutations
09:42:15 <birtles> davvel: I already have that
09:42:47 <birtles> birtles: are they in a format we can automate?
09:43:02 <birtles> davvel: I've used the web platform system for <object> tests
09:43:51 <birtles> ChrisL: are you familiar with the CSS system (Shepherd etc.)? It's pretty neat
09:44:30 <birtles> ... I've spoken to Peter Linss about this to do one-off conversions so that the database of properties includes SVG properties
09:44:37 <birtles> heycam: I think he may have already done this
09:44:54 <birtles> ChrisL: then you can go from properties to the tests that cover them
09:46:19 <birtles> heycam: for the case where containing div has width/height auto (and auto all the way up), and SVG has no width/height but has a viewbox, what is the behavior?
09:46:34 <birtles> davvel: it will use the viewport width
09:47:54 <ChrisL> ChrisL has joined #svg
09:48:03 <davvel> davvel has joined #svg
09:49:32 <birtles> heycam: how far is IE from this proposal?
09:49:44 <birtles> davvel: currently pretty far
09:50:30 <birtles> RESOLUTION: Unless there is feedback to the contrary (e.g. from Tab), accept David Vest's SVG sizing proposal
09:51:18 <birtles> Topic: overflow, clip on viewport creating SVG elements
09:51:30 <birtles> ed: this came from from a webkit bug
09:51:42 <birtles> ... it relates to whether or not you can specify overflow:visible on inline SVG
09:51:49 <birtles> ... which I think IE does by default
09:51:59 <birtles> ... which is different to other browsers which clip by default
09:52:05 <birtles> heycam: what is the initial value for overflow?
09:52:10 <birtles> ed: it's complicated
09:52:19 <birtles> ... lots of cases
09:52:34 <ed> https://svgwg.org/svg2-draft/masking.html#OverflowProperty
09:53:19 <birtles> ... if you have a standalone SVG document, currently all browsers clip to the viewport
09:55:43 <birtles> ... do we want to allow SVG to apply overflow to standalone documents?
09:55:54 <birtles> heycam: does HTML have an equivalent?
09:56:10 <birtles> ... if you replace the SVG document with a paragraph that has some overflow
09:56:22 <birtles> ... what if you put width/height properties on the root <html>
09:56:34 <birtles> ... what does that mean for things rendered outside that?
09:56:41 <birtles> davvel: the default is visible
09:56:44 <birtles> ed: that's the default in CSS
09:56:58 <birtles> heycam: then we should do that same
09:57:28 <birtles> pdr: is that Web compatible?
09:57:47 <birtles> krit: the question is really whether it should be controllable or not, not what the default should be
09:59:52 <birtles> ... in SVG we have clip and overflow and the clip property clips to the viewport as its initial value
10:00:18 <birtles> ed: I think it only applies with overflow:hidden etc.
10:00:24 <birtles> krit: I think they're independent
10:01:29 <birtles> ... so even if you say overflow:visible it will still be clipped due to the clip property
10:01:43 <birtles> ... and CSS masking removes this
10:02:01 <birtles> ... so it allows the use case ed brought up
10:02:18 <birtles> ... so we need to do more work on the definition of the overflow property
10:02:42 <davve> davve has joined #svg
10:03:18 <birtles> ed: the second thing I wanted to ask was about overflow:auto in SVG is defined to mean visible
10:03:43 <birtles> ... but in CSS it is suggested to clip to the region and use scrollbars
10:04:14 <birtles> heycam: it makes more sense to treat it as hidden rather than visible since in CSS you never paint outside the region since you have scrollable regions
10:04:47 <birtles> ed: how do we want to treat overflow-x/y?
10:05:06 <birtles> ... these are independent so you can have overflow in just one direction
10:05:17 <birtles> heycam: CSS defined some combinations of overflow that don't make sense
10:05:25 <birtles> ... do we want those in SVG?
10:05:59 <birtles> ... I think you can have both visible/hidden but some combinations of scrollable don't make sense
10:06:27 <birtles> ... I would like overflow-x/y to be useable in SVG
10:07:43 <birtles> (break, lunch: 1hr)
10:14:54 <Tavmjong> Tavmjong has joined #svg
10:45:19 <nikos> nikos has joined #svg
10:49:59 <ChrisL> ChrisL has joined #svg
10:51:10 <cabanier> scribenick: cabanier
10:52:19 <cabanier> ed: IE has the root as visible
10:52:39 <cabanier> ... other say SVG root overflow should be hidden
10:53:27 <heycam> in Firefox's UA style sheet:  svg:not(:root) { overflow: hidden; }
10:53:40 <cabanier> krit: that is strange because the spec says overflow hidden
10:53:54 <cabanier> ... we should say that all svg should say hidden
10:54:16 <cabanier> heycam: I think if we can get away with adding new rules
10:54:29 <cabanier> ChrisL: it's the only way to add a new value
10:54:51 <cabanier> heycam: so IE allows overflow visible on the root?
10:55:15 <pdr> Blink's UA styleshee as wellt: svg:not(:root) { overflow: hidden }
10:55:16 <cabanier> ... for outer most svg elements that are inline
10:57:19 <cabanier> krit: the spec says that the root should be visible so IE is correct
10:57:29 <ed> https://svgwg.org/svg2-draft/masking.html#OverflowProperty
10:57:51 <ed> https://svgwg.org/svg2-draft/intro.html#TermRootmostSVGElement
10:57:52 <cabanier> ed: no, this is for the root-most/outer-most element
10:57:54 <pdr> Previous discussion on this from 2008: http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0347.html
10:58:16 <cabanier> ... it doesn't necessarily mean the same thing
10:59:45 <cabanier> ... we want to be able to allow to override overflow
11:00:10 <cabanier> ... at the moment, firefox, chrome and webkit all do overflow: hiddne
11:00:18 <cabanier> cabanier: can you override it?
11:00:22 <cabanier> ed: yes
11:00:38 <cabanier> ... in IE you can say
11:01:01 <cabanier> ... in other browser you can specify it but it doesn't work
11:02:12 <cabanier> heycam: exactly how the spec defines this will depend on the next topic
11:02:30 <cabanier> resolution
11:02:37 <cabanier> s/resolution/
11:03:52 <cabanier> RESOLUTION: outer-most svg elements of inline fragments will be overflow: hidden by default
11:05:44 <cabanier> RESOLUTION: overflow should not be ignored for outer-most SVG elements for both inline and standalone cases
11:06:50 <cabanier> heycam: we talked about scrollable viewport in switserland
11:06:59 <cabanier> ... to do zoom and pan
11:07:09 <cabanier> ... to have scrollable viewport
11:07:34 <cabanier> krit: we had requests from google to have scrollable content
11:07:53 <cabanier> pdr: how is this applicable to mobile browser
11:08:47 <cabanier> heycam: this is for all elements
11:08:53 <cabanier> cabanier: so not just the root?
11:09:07 <cabanier> heycam: inner SVG elements
11:09:23 <cabanier> krit: not on symbol for instance, only viewport creating elements
11:09:45 <cabanier> pdr: my concern is that this is a graphics format
11:09:58 <cabanier> heycam: you can do this to with foreignobject
11:10:47 <cabanier> ChrisL: scrollable has historically been a difference between css and html
11:10:52 <cabanier> pdr: I agree
11:11:07 <cabanier> ChrisL: it would be good to be able to request scroll bar
11:11:22 <cabanier> ... I've seen people create scrollbars in svg
11:11:53 <cabanier> heycam: maybe people used to write whole applications in svg
11:12:37 <cabanier> ed: today scroll and hidden means the same
11:13:29 <cabanier> ... if we allow scrollbars, does CSS do anything with that
11:13:41 <cabanier> heycam: the specs don't say anything
11:13:58 <cabanier> ed: maybe it's up to the user agent to decide
11:14:16 <cabanier> krit: it's up to the UA to decide
11:15:10 <cabanier> pdr: will the width have the ... (?)
11:15:29 <cabanier> krit: filters can paint outside the boundingbox
11:15:34 <pdr> The issue of what determines the width: which bounding box do we use?
11:16:05 <cabanier> heycam: if you have contents that will scroll, you'd have to anticipate that
11:16:28 <cabanier> ... today you can have scrollbars on a standalone doc
11:16:43 <cabanier> ed: but not inside the document
11:17:20 <cabanier> davve: there is something with background
11:18:04 <cabanier> heycam: is anyone thinking it's bad idea to have scrollable viewport
11:18:29 <cabanier> ed: would it ever be a pannable viewport, or would it be the default
11:19:31 <cabanier> heycam: css needs a way for viewports to scroll beyond their viewport region
11:19:47 <cabanier> ... that might be a way to do arbitrary panning
11:20:11 <cabanier> ... panning could use viewport scrolling, but not just yet
11:20:17 <cabanier> ed: can we put that off?
11:20:23 <cabanier> heycam: that's ok for me
11:24:14 <cabanier> RESOLUTION:  svg:svg elements should allow overflow: scroll to create scrollbars
11:25:33 <cabanier> krit: where does the origin of this viewbox come from
11:25:55 <cabanier> pdr: I don't think there's a way to set it to negative
11:26:10 <cabanier> heycam: if you have a viewbox [10 10 20 20]
11:26:29 <cabanier> krit: maybe we don't want scrolling but panning
11:27:01 <cabanier> cabanier: how about the size of the scrollable area
11:27:08 <cabanier> krit: yes, that needs to be decided
11:27:23 <cabanier> pdr: what is the bounding box of this thing?
11:27:32 <cabanier> ... html has the inner and outer box
11:27:54 <cabanier> ... or something to that effect
11:28:35 <cabanier> heycam: we still need to define what those CSS properties such as offset width means for SVG
11:28:55 <cabanier> krit: maybe take viewport?
11:29:31 <cabanier> heycam: maybe we don't need to delve into the details
11:31:12 <cabanier> heycam: how about for outermost inline SVG elements?
11:31:27 <cabanier> ed: every browser clips today
11:35:22 <cabanier> heycam: maybe overflow isn't the right thing to cause this clipping to happen
11:35:44 <cabanier> ... maybe there should be no way to affect the rendering
11:35:54 <cabanier> ed: do we want allow that to happen?
11:36:19 <cabanier> heycam: if scrollbars can appear (?)
11:36:38 <cabanier> ed: is there ever a use case to not have scroll bar
11:36:56 <cabanier> heycam: would you ever want the content outside of a short SVG to be painted?
11:37:15 <cabanier> ChrisL: maybe if you have a symbol?
11:37:30 <cabanier> Tavmjong: we talked about this in a telecon
11:37:43 <cabanier> ... andreasa asked for that
11:38:00 <cabanier> ChrisL: scroll bars in symbols would be bad
11:38:17 <cabanier> heycam: we need to have some wording there
11:38:47 <cabanier> ed: today we imply that there should be scroll bars for standalone svg elements
11:39:03 <cabanier> heycam: we still need some wording for short svg's to be clipped
11:41:33 <cabanier> RESOLUTION: overflow property on root svg elements still controls if there should be scrollbars but there should be a clipping rectangle that
11:42:12 <cabanier> ... is the size of the svg element's viewport
11:43:04 <cabanier> ed: the current spec says that within SVG content the value 'auto' means visible
11:43:09 <cabanier> ... should we change that
11:43:43 <cabanier> heycam:  it might be if we can come up with a solution
11:44:05 <cabanier> ... for instance if the appearance of scrollbars makes things narrower
11:44:25 <cabanier> ... noone's using auto today so it would be safe to use it
11:44:44 <cabanier> ed: do we want to keep the spec or should we change it?
11:45:03 <cabanier> heycam: if we allow for scrollable viewports it makes sense to change it
11:46:58 <cabanier> ... for viewport establishing elements where scroll bars don't make sense, overflow:auto would be visible
11:47:33 <cabanier> ... for svg:svg, auto will mean scrollbars will appear if the overflow region is bigger than the viewport
11:48:08 <cabanier> pdr: why are marker and pattern different?
11:48:36 <tbah> tbah has joined #svg
11:48:39 <cabanier> ... we are adding special cases for certain elements
11:49:00 <cabanier> heycam: one reason is that these elements are not rendered directly
11:49:48 <cabanier> krit: it makes it more compex for instance on patterns. because you have to calculate how you tile them
11:51:50 <cabanier> heycam: how about mask?
11:51:58 <cabanier> pdr: yes, that wouldn't make much sense
11:52:39 <cabanier> krit: how about 'element()' in firefox, would it copy the scroll bars?
11:52:50 <cabanier> heycam: I believe so ye
11:52:56 <cabanier> s/ye/yes
11:54:18 <cabanier> heycam: we need to add a bunch of spec text to make sure that a pattern with overflow:hidden does the right thing
11:55:04 <cabanier> heycam: I worry about getting the coordinate system right
11:55:19 <cabanier> pdr: maybe it's best to get some implementor feedback
11:55:30 <cabanier> heycam: you can have an issue in the spec and wait for that
11:56:49 <cabanier> ACTION: ed to figure out the overflow behavior in SVG
11:56:49 <trackbot> Created ACTION-3606 - Figure out the overflow behavior in svg [on Erik Dahlström - due 2014-04-14].
11:58:22 <cabanier> heycam: we need to work out or put an issue in the spec whether that patterns have scrollable viewports
11:59:13 <cabanier> topic: bbox for text calculations
11:59:21 <ed> http://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html
11:59:27 <cabanier> ed: we discussed this on a call but didn't come to a conclusion
11:59:34 <cabanier> ChrisL: I had some comments
12:01:13 <cabanier> ... the full glyph cell is not the ink bounding box
12:01:28 <cabanier> heycam: is it origin + ascent + descent
12:02:00 <cabanier> ChrisL: full glyph cell is adding rectangles, is to use all
12:03:09 <cabanier> ... do we need bounding boxes for hit detection and text selection? I think not
12:03:31 <cabanier> nikos_: how about negative advances?
12:04:05 <cabanier> ChrisL: the advance is separate from that
12:06:56 <cabanier> ...
12:08:15 <cabanier> heycam: it sounds like we do need different bbox's because some glyphs might go over and you don't want to select them
12:08:38 <cabanier> ChrisL: in practice people put transparent rects on top of the text
12:08:39 <ed> http://jsfiddle.net/L7pgW/18/
12:08:44 <cabanier> ed: I made some examples
12:09:21 <cabanier> krit: the italic is the browser?
12:09:29 <cabanier> ed: yes.
12:11:03 <ed> http://jsfiddle.net/L7pgW/22/
12:13:17 <cabanier> ed: this is a case where the gradient is started where the character starts
12:14:22 <cabanier> ... filters have this issue too
12:17:45 <cabanier> heycam: we talked about these for stroke/mask bbox
12:18:10 <cabanier> ... should we extend this to extent for ink coverage
12:18:52 <cabanier> tbah: what you might want it the bbox and the (?)
12:23:54 <cabanier> ... (conversation about using em to size a gradient)
12:28:47 <cabanier> ed: as an author I would expect the gradient to fill the bounding box
12:29:12 <cabanier> heycam: do we have interoperable behavior?
12:29:27 <cabanier> ... for what the size of the bbox is?
12:29:30 <cabanier> ed: no
12:30:15 <cabanier> heycam: the dictionary to getbbox can included stroke and markers but not for the ink coverage
12:30:40 <cabanier> ... one option is to union the ink region and the glyph cell
12:31:01 <cabanier> ... the other is just to get the tight bounding box
12:32:08 <cabanier> ... it's possible to extend the dict for horizontal and vertical
12:40:35 <cabanier> ...
12:40:48 <cabanier> ed: I would like getbbox to return the ink coverage
12:41:04 <cabanier> ... most of the time you want to know what is drawn
12:41:14 <cabanier> heycam: we already have that information
12:41:27 <cabanier> ed: yes, you need to know where things were
12:41:40 <cabanier> heycam: we use the lose ink bounds
12:41:50 <cabanier> ... which might be more expensive
12:42:35 <ed> s/which might be more expensive/the tight glyph bounds might be more expensive/
12:45:26 <cabanier> ...
12:46:18 <cabanier> heycam: we should do the union of the glyph boxes and the ink coverage
12:47:02 <cabanier> tbah: that should catch the majority of the use cases
12:48:16 <cabanier> how about japanese text
12:48:30 <cabanier> ... all glyphs are the same size
12:49:54 <cabanier> ACTION: getBBox  and resource bounding box (for gradients, mask, etc) to return the union of the glyph cells and ink extends by default.
12:49:54 <trackbot> Error finding 'getBBox'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
12:50:12 <cabanier> RESOLUTION: getBBox  and resource bounding box (for gradients, mask, etc) to return the union of the glyph cells and ink extends by default.
12:50:33 <cabanier> heycam: do we allow control to get just the ink extends?
12:52:00 <cabanier> ed: can we reuse the same method?
12:52:14 <cabanier> ... we have a method called getTextExtend
12:52:55 <ed> https://svgwg.org/svg2-draft/text.html#__svg__SVGTextContentElement__getExtentOfChar
12:54:27 <cabanier> ... do we need to make getBBox more complex or rely on these methods
12:55:14 <cabanier> heycam: are you leaning towards not extending getbbox?
12:56:39 <cabanier> ed: if so, we should be able to do the same on gradients, for instance gradientUnits="some_new_value"
12:57:31 <cabanier> ...
12:57:58 <cabanier> heycam: maybe we can ignore that for now since it complicates the API
12:59:35 <cabanier> nikos: most cases where you want the tight box, you might want to hit test against it too
13:00:04 <cabanier> ed: I could go with a clarification
13:01:44 <cabanier> RESOLUTION: for now we won't provide APIs for a tight ink bounding box on text for getBBox or gradient object bounding box or hit detection
13:02:35 <cabanier> ed: are text decoration part of the bbox?
13:03:25 <cabanier> krit: CSS had discussions on this
13:03:47 <cabanier> ... right now css doesn't gradients, just color
13:04:24 <cabanier> heycam: the boundingbox in that case is the element
13:04:39 <cabanier> ... an underline could go outside of the element
13:05:20 <cabanier> ... it makes sense to include them
13:05:36 <cabanier> krit: then there would be 2 definitions of bounding box
13:05:50 <cabanier> heycam: I don't want decoration to be painted differently
13:06:45 <ed> https://svgwg.org/svg2-draft/text.html#TextDecoration
13:10:32 <cabanier> RESOLUTION: text decoration to be included in the bounding box calculations
13:12:40 <krit> http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling
13:14:37 <heycam> http://dev.w3.org/csswg/css-inline/
13:14:47 <cabanier> (krit discussing issue with text baselines, etc)
13:15:40 <ed> ACTION: ed to do spec edits for bounding boxes of text elements: give the union of full glyph cells and the painted area, and include text decorations in the bbox (change for getBBox too)
13:15:40 <trackbot> Created ACTION-3607 - Do spec edits for bounding boxes of text elements: give the union of full glyph cells and the painted area, and include text decorations in the bbox (change for getbbox too) [on Erik Dahlström - due 2014-04-14].
13:15:53 <ChrisL> ideographic = descender depth
13:15:53 <ChrisL> alphabetic = 0
13:15:53 <ChrisL> central = (ascender height - descender depth) / 2
13:15:53 <ChrisL> middle = x height / 2
13:16:10 <ChrisL> these seem good fallback definitions we could reuse
13:18:44 <cabanier> ACTION: krit to talk to Alan Stearns about adding fallback baseline calculations to the CSS line layout spec and if they will stay in the spec
13:18:44 <trackbot> Created ACTION-3608 - Talk to alan stearns about adding fallback baseline calculations to the css line layout spec and if they will stay in the spec [on Dirk Schulze - due 2014-04-14].
13:34:51 <nikos> nikos has joined #svg
13:40:51 <heycam> Scribe: Cameron
13:40:53 <heycam> ScribeNick: heycam
13:41:03 <heycam> Topic: white space in attributes
13:41:07 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AttributeWhitespace
13:41:28 <heycam> ed: I went through all the attribute types we use in SVG, made a big table summarising
13:41:41 <heycam> ... I was looking for whether trailing/leading white space is allowed and ignored
13:41:43 <heycam> ... comparing with HTML5
13:42:02 <heycam> ... it's inconsistent, but at least for some of the numerical types it should be possible to make it consistent
13:42:15 <heycam> ... we discussed this in a telcon, and I went over it once more to add test cases for each of the subsections
13:42:25 <heycam> ... we could go through each type by type and see the test cases
13:42:32 <ed> http://jsfiddle.net/wxJa9/
13:42:40 <heycam> ... this is for <number>
13:42:49 <heycam> ... there aren't many of these in HTML
13:42:57 <heycam> ... the only ones I could find are on <input>
13:43:23 <heycam> ChrisL: is HTML5 the right thing to be comparing to here?
13:43:35 <heycam> ... and not CSS properties?
13:43:43 <heycam> heycam: these are all non-CSS property attributes we're looking at
13:44:13 <heycam> ed: this example is inconsistently handled across browsers
13:44:21 <heycam> ... HTML5 has different constraints for validators vs browsers
13:44:39 <heycam> ... for the content to be valid, it has to be a proper number in the right format and without any garbage or white space
13:44:48 <heycam> ... but for display, it strips away the white space and junk
13:44:58 <heycam> ... and returned in a correct form if you ask for it in the DOM
13:45:09 <heycam> ... even in HTML5 this example doesn't work the same way across browsers
13:45:15 <heycam> ... for integer values it's a bit more consistent
13:45:32 <heycam> ... in the first section I listed the browsers I tested
13:45:54 <heycam> ... Firefox/Chrome/Presto did not allow white space and garbage; IE did allow white space and garbage
13:47:00 <ed> http://jsfiddle.net/hxz46/
13:47:04 <heycam> ... that's the SVG test case
13:47:25 <heycam> ... here Firefox/Chrome do not allow the white space and garbage; IE allows white space but not garbage, Presto allows both
13:47:34 <ChrisL> <input type="range" step="  500e-3nord" min="0" max="10"/> works
13:47:39 <heycam> pdr: in these examples this is not stripping white space in the middle
13:47:49 <heycam> ... so only leading and trailing white space
13:47:54 <heycam> ... is that your intention?
13:48:43 <heycam> ed: we could add tests for those
13:49:29 <heycam> ... so the first question is do we want to allow white space and garbage
13:49:57 <heycam> ChrisL: for garbage, that would probably have different levels of support
13:50:01 <heycam> ed: the HTML5 parsing algorithm does allow it
13:50:13 <heycam> heycam: so IE is the only one following the spec
13:50:54 <heycam> krit: for things that just take numbers, WebKit/Blink are accepting
13:51:03 <heycam> ... that's how we do the parsing in SVG
13:51:16 <heycam> ed: I looked at the functions in Blink, and it's passing a flag whether to allow it
13:51:36 <heycam> ChrisL: if HTML5 defines what to do with numeric attributes, then following the exact same algorithm makes it convenient
13:51:48 <heycam> ... it's slightly worrying that only one browser implements that
13:52:03 <heycam> ed: there are only a handful of HTML attributes that take a float
13:52:19 <heycam> ... for integers it was much more consistent
13:52:19 <ed> http://jsfiddle.net/6BQGF/
13:52:32 <heycam> ChrisL: the thing that worries me is that if there's only one browser implementing it properly, that requirement will be dropped
13:52:58 <heycam> ed: that is the test for integers
13:53:20 <heycam> ... white space and garbage is allowed across all browsers
13:54:28 <heycam> ... negative values for width doesn't work in some browsers, but that's different from the white space handling
13:54:37 <heycam> ... anyway, all browsers allowed white space / garbage
13:54:40 <heycam> pdr: HTML doesn't have lists like SVG
13:54:48 <heycam> ... is there any danger there?
13:54:50 <heycam> ed: for SVG lists, I think generally white space is allowed
13:55:12 <heycam> pdr: I'm wondering if we use that algorithm for a specific number, but for a list that doesn't allow commas...?
13:55:34 <heycam> krit: I would be in favour of allow leading / trailing white space
13:55:43 <heycam> ... to allow garbage at the end is a bit strange
13:55:52 <heycam> ChrisL: it means you constrain what you can later add
13:56:05 <heycam> ed: I guess that's why there are different conformance classes in HTML?
13:56:14 <heycam> krit: do we want to allow browsers to be less restrictive
13:56:21 <heycam> ... we don't need to enforce it...
13:56:33 <heycam> Tav: I'd like to avoid the situation where it renders well in the browser but then imported in Inkscape it doesn't work
13:56:50 <heycam> ed: I think the main thing I found was that there are some minor inconstencies whether leading white space is allowed in SVG
13:56:59 <heycam> ... so it seemed like a good thing to check everything
13:57:09 <heycam> pdr: for the trailing garbage, I disagree
13:57:22 <heycam> ... why follow something different from HTML?
13:58:00 <heycam> ChrisL: what if we have an attribute like x="4e10" and we start off as an integer, what if we want to extend that later?
13:58:06 <heycam> ... to accept scinot?
13:58:22 <heycam> ed: note that you still get the "4"
13:58:23 <heycam> pdr: I see
13:59:41 <heycam> ... when the HTML folks made this decision, how did they handle this future constraint?
13:59:52 <heycam> ChrisL: maybe since it's only a handful of elements it wasn't a problem
14:00:43 <heycam> heycam: what is the benefit here?
14:00:48 <heycam> ... simplifies implementations slightly
14:00:52 <heycam> ... what about for authors?
14:01:01 <heycam> ed: had a bug reported where white space was allowed in firefox but not in chrome
14:01:11 <heycam> ... can't remember which attribute it was
14:01:15 <heycam> pdr: I think it makes sense to align
14:01:30 <heycam> cabanier: if you only want one algorithm, then you're going to need to accept trailing garbage then
14:01:48 <heycam> ChrisL: to be clear, the two objections aren't "no I'll tie myself to the mast" objections, they're just worries
14:02:04 <heycam> ... worry about it being dropped from HTML, and future constraining extensions
14:02:13 <heycam> ... but if the group agrees they want to do that I'm fine with it
14:02:51 <heycam> ed: next is length values
14:03:00 <heycam> ... IE allowed white space, no garbage; others don't allow anything
14:03:09 <heycam> ... for enumerated values, everyone agrees no white space or garbage
14:03:53 <heycam> heycam: I feel like length parsing is more like CSS parsing
14:04:03 <heycam> ... so white space seems good to allow
14:04:07 <heycam> ... what about CSS comments?
14:05:43 <heycam> ed: so for number and integer, stripping leading/trailing white space and trailing garbage, being consistent with HTML5, is my first proposal
14:06:04 <heycam> krit: who doesn't allow garbage in SVG integer attributes?
14:07:52 <ed> http://jsfiddle.net/Gaw2P/
14:08:37 <heycam> ed: compare to the bottom right subtest
14:08:41 <heycam> ... which is numOctaves="1"
14:09:31 <heycam> krit: in Safari we don't render the 5th one
14:09:34 <heycam> ... what does that indicate?
14:09:38 <heycam> ed: it doesn't use any fallback value
14:11:17 <heycam> heycam: I think if we have some implementations that accept the white space and garbage and others not, then we'll eventually all converge to that behaviour
14:11:22 <heycam> ... so may as well jump to that state now
14:11:29 <heycam> krit: I'm OK with accepting leading/trailing white space
14:14:57 <heycam> pdr: go for browser compatibility instead of parser compatibility?
14:15:08 <heycam> krit: well, the browser uses a parser...
14:15:11 <heycam> pdr: spec parsers
14:15:37 <heycam> ed: I think it's mostly consistent in disallowing the garbage
14:15:41 <heycam> ... in transform lists for example
14:15:52 <heycam> krit: for numbers I would be skeptical because of that exponential number example
14:15:58 <heycam> ... for integers we only have a few attributes
14:16:02 <heycam> ... so is it worth it?
14:16:13 <heycam> ed: there are other cases where white space is allowed when the spec says no
14:16:21 <heycam> krit: I am supporting the white space
14:16:36 <heycam> ed: to be clear, I don't want to allow white space everywhere
14:16:45 <heycam> ... for enumerated values, like accumulate="none | sum"
14:16:53 <heycam> ... I guess we could allow white space
14:16:55 <heycam> Tav: but HTML does not
14:17:12 <ed> http://jsfiddle.net/eT7jz/
14:17:29 <heycam> ed: all browsers agree there not to allow white space
14:18:45 <heycam> krit: safari allows the white space there
14:18:50 <heycam> pdr: I wouldn't have expected that to be different from chrome
14:19:00 <heycam> krit: but the HTML spec doesn't want white space
14:19:18 <heycam> ... I think it's strange, but acceptable, to not allow white space in enumerated attributes
14:19:39 <heycam> ed: we imported a few attributes from HTML5, the boolean values for controls="", default="", etc. on <video> and <audio>
14:19:45 <heycam> ... we currently don't have anything like that
14:19:47 <heycam> ... in SVG
14:19:52 <heycam> ... so it makes sense to follow SVG there
14:19:56 <heycam> krit: filter effects too
14:20:04 <heycam> ed: they don't allow white space or values other than the attribute name itself
14:20:12 <heycam> krit: I think it's strange it doesn't allow true/false
14:20:28 <heycam> ed: for url values, all values allow leading/trailing white space, which is stripped
14:20:32 <heycam> ... the spec currently says it's not allowed
14:20:39 <heycam> ... so I think we should allow it there
14:20:47 <heycam> ed: xlink:href=""
14:20:59 <heycam> ... we now have <video src=""> too
14:21:26 <heycam> pdr: what about a data URL that's not base64 encoded
14:21:31 <heycam> ... with trailing white space. that's an actual difference.
14:23:11 <heycam> ed: I think white space is stripped there
14:24:14 <heycam> RESOLUTION: URL attributes will be parsed like in HTML, by stripping leading/trailing white space.
14:24:56 <heycam> pdr: I think not allowing garbage is ok for length etc.
14:25:24 <heycam> ... what about for attributes that we later promote to properties?
14:25:29 <heycam> krit: you would start to allow white space
14:25:33 <heycam> ed: but that's ok, it's more relaxed
14:26:08 <heycam> RESOLUTION: We will allow leading/trailing white space on integer,number,length,angle but not trailing garbage.
14:28:43 <heycam> ed: the rest of the data types, leave them as they are
14:29:01 <ChrisL> ChrisL has joined #svg
14:29:13 <heycam> ACTION: Erik to update attribute parsing according to these resolutions.
14:29:13 <trackbot> Created ACTION-3609 - Update attribute parsing according to these resolutions. [on Erik Dahlström - due 2014-04-14].
14:30:46 <heycam> Topic: Media queries in switch
14:30:53 <heycam> ChrisL: was the previous discussion in favour of this?
14:30:56 <heycam> heycam: yes I think so
14:31:16 <ChrisL> good
14:32:24 <heycam> [heycam explains what media="" would allow]
14:32:31 <heycam> pdr: why not fix media queries in CSS to allow this kind of switching?
14:32:42 <heycam> ChrisL: selector syntax is not really designed for doing switch cases like this
14:32:50 <heycam> ... we already have these test attributes, that we inherited from SMIL
14:32:57 <heycam> ... seems a natural extension to those
14:33:26 <heycam> ... this gives them a simple way to combine media queries with <switch>
14:34:49 <heycam> davve: the <switch> element has really low usage
14:34:54 <heycam> ... is there a use case we want to cover by this?
14:35:03 <heycam> krit: you could do the same with classes...
14:35:17 <heycam> pdr: this is somewhat torturing the <switch> statement's intentions
14:35:29 <heycam> krit: I don't want to encourage people to use <switch>, really
14:37:05 <heycam> pdr: the example that estelle is showing is a proposal that is copying a <picture> element example, but doing it in SVG
14:37:10 <heycam> ... isn't this duplicating?
14:37:16 <heycam> ... that doesn't seem like a good idea
14:37:38 <heycam> heycam: if this is the same thing as the <picture> element can do maybe we should just have that
14:37:52 <pdr> http://coding.smashingmagazine.com/2013/06/02/clown-car-technique-solving-for-adaptive-images-in-responsive-web-design/
14:38:05 <nikos> nikos has joined #svg
14:38:12 <ChrisL> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/struct-cond-01-t.html
14:39:12 <heycam> heycam: one difference is that the <picture><source> elements have to refer to external resources
14:39:16 <heycam> pdr: they could be data: URL encoded
14:40:58 <heycam> birtles: we were discussing having media="" on <iframe> too
14:41:16 <heycam> birtles: not sure if it's possible to get into cyclic dependencies with <switch> and media=""
14:43:55 <heycam> pdr: in this blog post they have SVG-as-image referencing external background-images, and I don't think that would work in implementations
14:45:07 <heycam> pdr: I think this blog post is saying why have <picture> when SVG can do this already, but I think <picture> is going to happen
14:50:37 <heycam> pdr: so if we have <picture> in SVG in the future, I don't think we should extend <switch>
15:00:25 <heycam> also http://coding.smashingmagazine.com/2014/03/05/rethinking-responsive-svg/
15:02:44 <heycam> heycam: so I guess there are a few ways to handle this use case
15:02:48 <heycam> (a) extend <switch> with media=""
15:03:05 <heycam> (b) write style sheets with media queries, as you can do currently, but with a bit of duplication within them
15:03:19 <heycam> (c) extend @media in CSS to allow switching, to avoid the duplication
15:03:28 <heycam> (d) extend <picture> to allow subtrees, so you don't need to use external references
15:10:35 <heycam> ed: there is <style media=""> too
15:13:20 <heycam> [some discussion about avoiding fetching resources in non-condition-matching branches]
15:15:43 <ChrisL> f) keep inviting new responsive elements and then rejecting them until the heat death of the universe
15:16:49 <Zakim> ChrisL, you asked to be reminded at this time to go home
15:17:42 <stakagi> resource piorities?
15:22:38 <birtles> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
15:24:59 <Zakim> Zakim has left #svg
15:27:06 <heycam> heycam: if preventing loading external resources is something important for the use case, then (b) and (c) aren't appropriate here
15:27:12 <heycam> ... (a) and (d) are
15:27:24 <heycam> s/and/or/
15:35:02 <heycam> ACTION: Cameron to reply to www-svg mail to say what can be done with existing @media queries and if <picture> exists in SVG
15:35:03 <trackbot> Created ACTION-3610 - Reply to www-svg mail to say what can be done with existing @media queries and if <picture> exists in svg [on Cameron McCormack - due 2014-04-14].
15:35:21 <heycam> RRSAgent, make minutes
15:35:21 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/07-svg-minutes.html heycam
15:36:20 <heycam> Present: Cameron, Rik, Dirk, Chris, Satoru, Erik, Brian, David Vest, Tav, Nikos, Philip Rogers
15:36:22 <heycam> Chair: Cameron
15:36:24 <heycam> RRSAgent, make minutes
15:36:24 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/07-svg-minutes.html heycam