17:00:09 <RRSAgent> RRSAgent has joined #svg
17:00:09 <RRSAgent> logging to http://www.w3.org/2014/01/30-svg-irc
17:00:59 <heycam> RRSAgent, set logs world-visible
17:01:14 <heycam> Meeting: SVG F2F Seattle 2014 Day 1
17:01:33 <heycam> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda
17:01:48 <heycam> RRSAgent, the meeting will span midnight
17:01:48 <RRSAgent> I'm logging. I don't understand 'the meeting will span midnight', heycam.  Try /msg RRSAgent help
17:01:53 <stakagi> stakagi has joined #svg
17:01:54 <heycam> RRSAgent, this meeting will span midnight
17:01:54 <RRSAgent> I'm logging. I don't understand 'this meeting will span midnight', heycam.  Try /msg RRSAgent help
17:02:02 <heycam> RRSAgent, this meeting spans midnight
17:02:32 <heycam> heycam has changed the topic to: SVG Working Group - https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda - see http://wiki.csswg.org/planning/seattle-2014 for dial in information
17:13:14 <heycam> Chair: Erik
17:13:32 <heycam> Scribe: Cameron
17:13:34 <heycam> ScribeNick: heycam
17:14:45 <heycam> Topic: Resolving dates for Apirl F2F
17:14:49 <heycam> s/Apirl/April/
17:15:05 <heycam> shepazu: where is it?
17:15:09 <ChrisL> ChrisL has joined #svg
17:15:10 <sgalineau> sgalineau has joined #svg
17:15:10 <heycam> ChrisL: Leipzig
17:15:16 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014
17:15:37 <ChrisL> http://libregraphicsmeeting.org/2014/
17:15:41 <heycam> heycam: that's 2-5 April for LGM
17:15:59 <heycam> ChrisL: which Wednesday to Saturday
17:16:30 <heycam> heycam: so meeting from Monday 7th April
17:17:01 <heycam> shepazu: I have Annotations workshop in SF around that time unfortunately
17:17:48 <heycam> ed: how many days?
17:17:57 <heycam> heycam: I probably prefer 4, so we can get a lot of work done
17:18:11 <heycam> ChrisL: have we got a meeting space? has anybody approached the university hosting the conference?
17:18:18 <heycam> heycam: Tav is in contact with them
17:21:22 <heycam> birtles: I agree 4 days is long but if we're taking the time/money to get there...
17:21:28 <heycam> ... then maybe it's worthwhile
17:21:39 <heycam> ChrisL: at that time of the year we'll be hopefully be trying to wind up and go to Last Call for SVG2
17:22:41 <heycam> shepazu: if we are going to have a 4 day week, I'd rather it be at the SVG Open one when I'll be there
17:24:32 <heycam> ... how about you have a 4 day meeting, where 2 or 3 days are the core meeting, and the final day or two is dedicated to working days
17:24:39 <heycam> ... where you try to finish up the things resolved during the F2F
17:25:10 <heycam> ... so people who need to leave after the core meeting can
17:25:25 <heycam> ed: so the proposal is April 7 - 10?
17:27:19 <Rossen__> Rossen__ has joined #svg
17:27:28 <heycam> krit: we should talk about who's sponsoring
17:27:35 <heycam> ChrisL: the university would supply a room but not food
17:27:59 <heycam> heycam: previously we've had F2Fs where we went out for lunch, and not had catering
17:28:05 <heycam> krit: that's OK by me
17:28:27 <shepazu> shepazu has joined #svg
17:28:37 <heycam> RESOLUTION: The April F2F will be April 7-10, where the 10th is an optional stay-for-spec-editing day.
17:29:56 <heycam> ed: how about the Graphical Web F2F?
17:30:13 <heycam> ... it's at the end of August
17:30:15 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014
17:30:16 <heycam> ChrisL: 27-30
17:30:20 <ChrisL> http://svgopen.org/2014/
17:30:29 <heycam> heycam: that's another Wednesday-Saturday
17:31:29 <heycam> krit: regarding Leipzig, the semester holiday ends right when we would be meeting
17:31:36 <heycam> ... so maybe it will be harder to get a room there
17:32:43 <heycam> heycam: to get the spacing better, we should meet before Graphical Web IMO
17:34:13 <heycam> heycam: would we be happy with Sat-Tue? or maybe Fri-Mon?
17:34:46 <heycam> krit: this is a university again by the way
17:36:10 <ChrisL> tpac  27 Oct to 31 Oct 2014 in Santa Clara, California
17:36:48 <heycam> heycam: if we met after Graphical Web, then we would be meeting in September and then in October for TPAC
17:42:06 <heycam> heycam: so we could do it Sat-Tue before, and make Sun the optional spec editing day or just a day off
17:43:30 <heycam> ... or Thu-Fri on, Mon-Tue on, weekend off
17:44:56 <heycam> ed: I don't mind either
17:45:45 <heycam> shepazu: let's decide the exact before-Graphical-Web dates later
17:46:08 <heycam> Topic: should script be affected by <switch>
17:46:13 <heycam> shepazu: no
17:46:13 <heycam> heycam: no
17:46:15 <heycam> ed: no
17:46:29 <heycam> ChrisL: if you were designing from scratch maybe, but given how <script> already works now...
17:46:48 <heycam> heycam: I am pretty sure all implementations will run script without looking at <switch>
17:47:10 <heycam> RESOLUTION: <script> is not affected by <switch>
17:48:40 <heycam> ACTION: Erik to clarify <script> is not affected by <switch> and will be run in there, but is still disallowed by the content model.
17:48:41 <trackbot> Created ACTION-3561 - Clarify <script> is not affected by <switch> and will be run in there, but is still disallowed by the content model. [on Erik Dahlström - due 2014-02-06].
17:49:49 <heycam> birtles: I don't see the point of disallowing stuff that will work
17:50:01 <heycam> ChrisL: it's disallowing stuff that people might have reasonable expectations of working differently
17:50:09 <heycam> ed: I think we should encourage people to put <script> in <defs>
17:51:11 <heycam> birtles: we could say authors SHOULDN'T put it in <script>
17:51:56 <heycam> ed: I think it's fine to remove the content model restriction but to encourage to put it in <defs>
17:52:05 <heycam> heycam: I'm not sure of <defs>
17:52:25 <heycam> ChrisL: part of the point of <defs> is for things which are referenced later, and hiding from being visible, which doesn't really apply to <script>
17:53:32 <heycam> action updated
17:53:58 <heycam> Topic: deprecating/removing hasFeature
17:54:09 <heycam> krit: are we talking about deprecating or removing?
17:54:14 <heycam> birtles: the proposal from Anne was to make it always return true
17:54:23 <heycam> krit: so not removing it, but deprecating and making default return true
17:54:31 <heycam> krit: if you look at the WebKit/Blink source code, we do something with this feature
17:54:37 <heycam> ... the question is is any script using it
17:54:47 <heycam> ... given this part of our source code is outdated it's not really reliable
17:55:43 <heycam> krit: iirc, hasFeature is indirectly called by <switch>
17:55:48 <heycam> ... which doesn't mean anything, ...
17:56:00 <heycam> ChrisL: it's one of those features that sounded good, thought it would be the way forward, turned out it wasn't
17:56:06 <heycam> birtles: I think we haven't deprecated it yet right?
17:56:18 <heycam> krit: in HTML content true is always returned
17:56:27 <heycam> birtles: I think we return proper values for it
17:56:45 <heycam> heycam: hasFeature is defined in DOM btw
17:57:01 <heycam> ChrisL: it was never clear if you needed to support 100% of a feature to return true
17:57:18 <heycam> birtles: now with things like modernizr...
17:57:53 <heycam> krit: did someone add a use counter for hasFeature?
17:58:01 <heycam> birtles: a few days ago someone did I think?
17:58:36 <ed> http://code.google.com/p/chromium/issues/detail?id=335301
17:58:54 <heycam> shepazu: in DOM 3 Events we come up with a logical way to make hasFeature work
17:59:15 <heycam> ... for fine grained control for reporting
17:59:23 <heycam> ... which was roundly rejected by anne and others
17:59:31 <heycam> ... which is expensive and other things which are not feature testable
17:59:52 <birtles> the usage counter has been added to blink: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.html
17:59:59 <heycam> ... I won't get in the way of removing it, but I think it's being done on outdated data
18:00:09 <birtles> https://code.google.com/p/chromium/issues/detail?id=335301
18:00:37 <heycam> shepazu: I've had conversations with Paul Irish about testing whether certain SVG features are available, and there weren't
18:01:13 <heycam> Rossen_f2f: can't you piggyback off @supports for this?
18:01:27 <heycam> shepazu: I don't mind
18:02:11 <astearns> astearns has joined #svg
18:02:30 <heycam> birtles: I think it's not going to work when there are bugs in the features that are being reported as true
18:02:35 <heycam> ... which you often want to test for
18:03:14 <heycam> ChrisL: it's not can I rely on this feature, but can I rely on a subset of this feature that I'm using right now?
18:03:26 <heycam> ... you're really saying if I use this in this way, in combination with this other thing, ...
18:03:32 <heycam> shepazu: feature detection won't work for that either
18:03:53 <heycam> Rossen_f2f: why wouldn't feature detection work?
18:04:00 <heycam> shepazu: it can't test for rendering things
18:04:14 <heycam> birtles: Safari on iOS 5 for example paints patterns upside down
18:04:19 <heycam> ... for that you really need to do UA string checking
18:04:46 <heycam> ... so I think that's an advantage of feature testing, you can test for exactly what you need
18:07:11 <heycam> ed: should we wait for the use counter results?
18:07:35 <heycam> ed: I wouldn't mind if we returned true all the time
18:07:42 <heycam> Rossen_f2f: you're trying to do implementaiton detection through feature detection
18:07:48 <heycam> ... which doesn't seem to be exactly what feature detection is for
18:07:55 <heycam> ... if you want to detect "what is the rendering of something" ...
18:08:08 <heycam> krit: there's a difference between supporting a property and supporting it in the rendering pipeline
18:08:55 <heycam> Rossen_f2f: your @supports or hasFeature should still return false in this case
18:09:35 <heycam> Rossen_f2f: I'm with Doug that hasFeature and feature detection are useful and good to keep
18:10:02 <heycam> ... still people are building solutions on top of this can impl versions of their apps that are best for that feature set
18:10:20 <heycam> krit: if you ask "do you support filters"? you might return true, even if you don't support all filter inputs
18:10:29 <heycam> sgalineau: that's true, but that's not an argument for not doing it at all
18:10:45 <heycam> sgalineau: that's why @supports gives you the ability to check for property values
18:10:52 <heycam> birtles: I'm just not sure you ever get enough granularity
18:11:13 <heycam> birtles: for animations, you could even test the supported values, like syncbase values, but you don't know if it supports cyclic dependencies
18:11:23 <heycam> shepazu: but you could add feature detection for specific cases like this
18:11:28 <heycam> ... but for other cases you wouldn't need to
18:12:02 <heycam> shepazu: pdr just said 10% of pages use SVG, which is misleading because a lot of that is Modernizr
18:12:20 <heycam> krit: there is a thing where you can select which features to check for, so not all Modernizr uses will end up creating an SVG element
18:12:28 <heycam> shepazu: but people will use it poorly
18:13:02 <heycam> ... the case where you inject SVG because you might use it, is different from doing it for feature detection
18:13:16 <heycam> ... I think the pattern of having to download scripts that are getting increasingly large, as there are more features added to the platform
18:13:33 <heycam> ... and putting the onus on authors to find some feature detection system that is a good tradeoff between what's actually supported and what's not supported,
18:13:40 <heycam> ... I think that's us being lazy and harming authoring
18:13:59 <heycam> sgalineau: that's why we have @supports
18:14:18 <heycam> Rossen_f2f: at the end of the day, it's a poor man's implementation of reflection
18:14:23 <heycam> ... and reflection is useful
18:14:34 <heycam> shepazu: maybe hasFeature is not the right place to do this
18:14:41 <heycam> ... I'm suggesting we should have reflection at all levels of the stack
18:14:54 <heycam> ... we can remove hasFeature, but let's not say we don't need the functionality, because we do
18:15:11 <heycam> ed: let's postpone until we get the use counter results
18:15:19 <heycam> Topic: adding SVG specific events to GlobalEventHandlers
18:15:41 <heycam> krit: was the editor of the spec with this interface had a chance to look at it?
18:15:48 <heycam> ed: Boris Zbarsky replied
18:15:49 <ed> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/041909.html
18:16:57 <heycam> onbegin, onend, onrepeat, onzoom
18:17:02 <heycam> ed: I'm proposing we don't add onbeing/onend/onrepeat
18:17:09 <heycam> ... for SVGZoom I'm not sure about it
18:17:16 <heycam> ... we could remove the prefix
18:17:26 <heycam> ChrisL: would it conflict it with something later?
18:18:01 <Thomas_smailus> Thomas_smailus has joined #svg
18:18:05 <heycam> ed: relatedly I also posted a patch to Blink to add the global event handlers
18:18:19 <heycam> ... so you assign to .onclick on SVG elements
18:18:51 <heycam> heycam: what are we doing about zoom event altogether?
18:19:14 <heycam> ... did we discuss getting rid of the "SVG" prefix?
18:19:19 <heycam> ed: we did, for those that have existing counterparts
18:19:25 <heycam> ... so that's all the events except for SVGZoom
18:19:34 <heycam> krit: zooming is being discussed in CSSWG
18:19:38 <ed> and endEvent/beginEvent/repeatEvent
18:19:54 <heycam> ... should we check what the outcome of that is first? before we add a global onzoom?
18:20:05 <heycam> ed: it doens't need to be resolved right away
18:20:15 <heycam> ... I don't think SVGZoom is used much
18:20:21 <heycam> birtles: can we drop it even? or is it used?
18:20:31 <heycam> ed: it's something people have asked for
18:20:36 <heycam> ... for UIs zooming and panning
18:20:50 <ChrisL> s/something later/current work on defining zoom/
18:22:02 <heycam> Rossen_f2f: I strongly suggest waiting for what Ted comes up with in CSS
18:22:11 <heycam> ... the one thing we need to figure out is what we really need from a zooming feature
18:22:31 <heycam> ... [mentions various possible zoomings]
18:22:58 <heycam> ... my hope is that once they're done defining the behaviour, the CSSOM will follow with the appropriate events for that
18:24:58 <heycam> heycam: so given .onzoom isn't supported anywhere, let's not add it now
18:25:19 <heycam> ... and wait to see what broader zoom events come out of the CSS work we can align with
18:31:07 <heycam> [look to see how things are done in HTML]
18:31:24 <heycam> ed: so let's put .onbegin, .onend, .onrepeat on SVGAnimationElement
18:31:25 <heycam> heycam: ok
18:31:52 <heycam> RESOLUTION: We won't add an onzoom IDL attribute, but we will add onbegin, onend, onrepeat to SVGAnimationElement.
18:32:05 <heycam> ACTION: Erik to add onbegin, onend, onrepeat to SVGAnimationElement.
18:32:06 <trackbot> Created ACTION-3562 - Add onbegin, onend, onrepeat to svganimationelement. [on Erik Dahlström - due 2014-02-06].
18:32:36 <heycam> -- 15 minute break --
18:33:32 <Tav> How do I call in?
18:33:41 <heycam> Tav, see /topic
18:34:08 <Tav> heycam, Thanks
18:50:54 <Tav> OK
18:51:08 <heycam> Topic: deprecate/remove SVGDocument.rootElement
18:51:11 <heycam> ChrisL: do it
18:51:21 <heycam> heycam: I asked, should we add use counters?
18:51:30 <heycam> ed: they've been added now, we'll have to wait a couple of weeks to get results
18:51:43 <heycam> ed: I still think we should mark it as deprecated in the spec
18:53:07 <heycam> birtles: I think we can mark it as deprecated, the results are useful for knowing when to remove it
18:53:13 <heycam> heycam: which might be immediately?
18:53:15 <heycam> birtles: might be!
18:53:32 <heycam> ed: this came up in a discussion with implementation for DOM 4, where we have a new XMLDocument interface, which is kind of used to replace SVG document
18:55:57 <thorton> thorton has joined #svg
18:56:58 <heycam> RESOLUTION: We will deprecate rootElement in SVG 2.
18:57:07 <heycam> ACTION: Erik to mention in SVG 2 that rootElement is deprecated.
18:57:07 <trackbot> Created ACTION-3563 - Mention in svg 2 that rootelement is deprecated. [on Erik Dahlström - due 2014-02-06].
18:57:10 <ChrisL> zakim, alias amen to resolved :)
18:57:51 <heycam> Topic: MPEG coloured fonts meeting report
18:58:21 <shepazu> s/coloured/colored/
18:58:23 <heycam> ChrisL: there was an SVG glyphs in OpenType group that discussed how to do this
18:58:45 <heycam> ... consensus was reached finally and we came up with a proposal that said how to do this
18:58:48 <heycam> ... backed up with an impl in Firefox
18:58:56 <heycam> ... Adobe was heavily involved in this, and has been making fonts, demos and promoting it
18:59:18 <heycam> ... this was good, and MPEG who do the ISO version of OpenType due to a strange historical accident, would do this for the 3rd edition
18:59:21 <heycam> ... they put out a call for proposals
18:59:26 <heycam> ... they were aware of four things going on
18:59:33 <heycam> ... one by Apple, who decided not to submit it (or document it)
18:59:40 <heycam> ... one by Google, which is a bunch of PNGs
18:59:50 <heycam> ... (currently OpenType supports rasters but only black and white)
19:00:03 <heycam> ... the PNGs can be different sizes
19:00:08 <heycam> ... that hits the emoji case closely
19:00:20 <heycam> ... MS had a different proposal which builds on TT rasterising
19:00:32 <heycam> ... outlines that can be hinted etc., but you can have multiple of them that can be stacked, and you have a palette to say what colours the layers have
19:00:37 <heycam> ... so you can do flat solid colour things
19:00:44 <heycam> ... can't do gradients, transparency, masking, filtering, etc.
19:00:54 <heycam> ... at the same time, for typographers that like things to be hinted, that seems a win
19:01:04 <heycam> ... then there's the SVG proposal, which uses secure animated mode, so there's no scripting, interaction
19:01:09 <heycam> ... but you can use any graphical support in SVG
19:01:15 <heycam> ... it doesn't use SVG Font's <glyph>
19:01:21 <heycam> ... we did some pre-harmonisation work with the MS proposal
19:01:25 <heycam> ... so we use the same palette information in the font
19:01:30 <heycam> ... that was seen as a good thing in the meeting
19:01:41 <heycam> ... typically the outcome of MPEG meetings is a competition
19:01:50 <heycam> ... and decide on a winner, then the winning company has to provide a reference impl
19:02:00 <heycam> ... each proposal was seen as having benefits/drawbacks, so the proposal is to stick them all in
19:02:04 <heycam> ... and the typographer can choose which to use
19:02:08 <heycam> ... we already have that with TT vs CFF outlines
19:02:18 <heycam> ... which also exposes a problem, because in OT2 you have to say which you're using
19:02:26 <heycam> ... if we're adding 3 more formats, that's obviously not going to work
19:02:28 <heycam> ... so they're fixing that bug
19:02:43 <heycam> ... the other thing was a call for some math tables that let you do equation typesetting
19:02:58 <heycam> ... the MS proposal, the only one, was accepted
19:04:43 <heycam> ... Vlad will incorporate the proposals and circulate a draft
19:04:49 <heycam> shepazu: what's the IPR policy on this?
19:05:06 <heycam> ChrisL: the IPR policy for the SVG glyphs in OpenType part was decided by the Community Group, and almost everyone has signed off on that
19:05:06 <heycam> ... so that's RF
19:05:15 <heycam> shepazu: anyone significant hasn't?
19:05:18 <heycam> ChrisL: Canon has not
19:05:48 <heycam> ... the policy for ISO as a whole is RAND, and all you have to do is say that you will give a license
19:05:56 <heycam> ... companies discuss about reasonable is
19:05:59 <heycam> ... not super happy about that
19:06:02 <heycam> ... but that's how it works
19:06:07 <heycam> ... at least for the SVG parts it's ok
19:06:15 <heycam> shepazu: what about for OpenType itself?
19:06:24 <heycam> ChrisL: there have been patents, e.g. the hinting stuff
19:06:40 <heycam> ... the other thing is that unlike most ISO groups, this one does publish the spec openly
19:06:47 <heycam> ... which is good except you still have to click through a licence
19:06:56 <heycam> ... in practice everyone refers to the MS version
19:07:15 <heycam> ... I spoke to Michelle from MS and assured me once the document was stable she'd incorporate it into the MS version
19:07:30 <heycam> ... some people were worried about the SVG one, and it transpired the reason why is that it would be an MPEG bake off
19:07:35 <heycam> ... and one would win, others would lose
19:08:12 <heycam> ... I'm doing a talk at LGM about this
19:08:27 <heycam> ... I'm starting to look at the impl landscape, most of which work on windows, some on mac, none on linux
19:08:30 <heycam> ... which let you edit various things
19:08:36 <heycam> ... there is some momentum though
19:08:43 <heycam> ... there is interest in doing it too
19:09:01 <heycam> ... the type industry which has traditionally sold sets of fonts that align, is understanding that that sucks as a workflow, and wants to have a single font with tables
19:09:18 <heycam> ... another worry about SVG was that the colours were fixed, so hearing that we had this palette mechanism, they were super happy
19:09:52 <heycam> ... as far as MPEG is concerned, they're at a given stage, but at some point in the future there will be votes and will become a standard
19:09:57 <heycam> ... no need for implementations like CR
19:10:14 <heycam> ... so it would be good to have in another browser, and also authoring tools
19:10:41 <heycam> ... demos made by typographers would be good too
19:11:39 <heycam> ... inkscape has already got a way to do SVG glyphs, which are going away, and wraps them up and produces a font
19:11:44 <heycam> ... would be good to repurpose that for SVG in OpenType
19:11:55 <heycam> Tav: I know there'll be a lot of FontForge people at LGM
19:12:06 <heycam> ChrisL: yes, though FF is a bit funky given its interface
19:12:13 <heycam> ... plus if you're running it on a mac you need to run X
19:12:28 <shepazu> q+ to ask about W3C spec, and embedding OT in SVG, and Decotype http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.html
19:12:29 <heycam> ... there was an effort to split FF into two parts, a library then a UI, that has not happened
19:12:40 <heycam> ... would be good to talk to Scribus people too
19:12:55 <heycam> ... one thing you can do with this, video games use a lot of coloured signage, icons, and you can have huge assets for this
19:12:57 <heycam> ... and recolour them etc.
19:13:08 <heycam> ... having a coloured font format for slotting different palette values, is a win
19:13:17 <heycam> ... and the 3D people use fonts
19:13:50 <ChrisL> for amazing title sequences
19:14:10 <heycam> ack shepazu
19:14:21 <heycam> shepazu: is there a possibility to co-publish this as a W3C spec?
19:14:24 <heycam> ChrisL: the whole of OT3?
19:14:39 <heycam> ... there's a possibility, but MS does own the non-ISO version of the spec, so not sure what they would say about that
19:15:37 <ChrisL> https://www.microsoft.com/typography/otspec/
19:16:32 <heycam> ChrisL: there's a bad redirect there for the licence
19:16:39 <heycam> shepazu: I think there could be some value at republishing at W3C
19:17:55 <heycam> ... second question is, since we are killing off SVG fonts, for those browsers who decided to never do SVG fonts, that's good news
19:18:17 <heycam> ... there's a chance we'll see this new SVG glyphs in other browsers since they already do OpenType
19:18:33 <heycam> ... with the shitty internationalization of the old SVG Fonts, it was reasonable for them not to implement it
19:19:31 <heycam> shepazu: what I hated about SVG Fonts was the inverted coordinate system
19:19:53 <heycam> ... is there any possibility for us resurrecting SVG Fonts in a way, by embedding an OpenType font in the document?
19:20:33 <heycam> ChrisL: the XML serialization of OT, UFO, is very verbose
19:20:44 <heycam> ... the binary format is very compact, lots of tables with bytes
19:20:56 <heycam> ... by the way, WOFF is a way to wrap up any sfnt font
19:21:12 <heycam> Tav: would it be possible to have the table information in the font, but feed in the SVG glyphs to it?
19:21:16 <heycam> ChrisL: that would be interesting
19:21:24 <heycam> ... there is a demo of that, but it's kind of hacky
19:21:43 <heycam> ... roc made it. you load in an OpenType font, and gives you a textarea to enter some SVG, wraps it up and sticks it into the table, generates an OpenType font
19:22:01 <heycam> Tav: I tried to do this with inkscape, but I ran into trouble since we use Pango for text layout, which doesn't let you insert a user font
19:22:10 <heycam> ... I was going to intercept the layout information from Pango, and just draw the SVG glyph
19:22:28 <heycam> ChrisL: I should say, Behdad Esfabod has been at these meetings and is aware of this
19:22:40 <heycam> ... and is interested in adding this to Harfbuzz
19:22:54 <heycam> shepazu: maybe not right now, but this is a useful use case to pursue in the future
19:23:02 <heycam> Tav: yeah. it's a way of getting your cake and eating it too.
19:23:13 <heycam> ... basically saying OpenType handles all the nasty i18n layout stuff, and we provide a glyph
19:23:43 <heycam> ChrisL: one thing people brought up was that they've looked at SVG for the first time, and noticed that SVG has text in it
19:23:45 <heycam> ... what if text has fonts on it
19:23:56 <heycam> ... do you have a glyph with the same font?
19:24:13 <heycam> ... and they've followed the CSS2 reference and thought you need to support all the old font formats
19:24:30 <heycam> ... but there is a possibility we might be asked down the line to produce a subset for SVG for this
19:24:36 <heycam> ... maybe we shouldn't prompt this, but if asked we should
19:24:47 <heycam> shepazu: if it's well in the scope of Integration...
19:24:58 <heycam> ChrisL: integration is already being referenced for secure mode, secure animated mode
19:25:43 <shepazu> http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.html
19:25:46 <heycam> shepazu: I had a conversation with the guys from Decotype
19:25:52 <heycam> ... they were asking about SVG fonts, told them about groovy fonts
19:25:56 <heycam> ... they're trying to do arabic
19:26:28 <heycam> ChrisL: they also talked to me, and they're basing their stuff on altGlyph
19:26:53 <heycam> shepazu: I told them it's going away, and they said oh that's not a problem, we can do it another way
19:27:05 <heycam> ... but their use case is, the groovy font use case
19:27:18 <heycam> ... and it ties in to wanting to have shape selection in SVG
19:27:25 <heycam> ... I'd like to talk to you guys about ramifications of that
19:27:34 <heycam> ... the idea of being able to select shapes as well as text
19:27:39 <heycam> ... I don't know the UI for that, or care
19:27:44 <heycam> ... but we should say when something is selected
19:28:03 <heycam> ... this could also play into copy and paste of graphics, and annotations
19:28:08 <heycam> ... and that would feed into groovy text as well
19:31:06 <heycam> [doug draws groovy text on the board. again!]
19:33:02 <heycam> ChrisL: maybe we should send a liaison statement to MPEG SC29 WG whatever
19:33:24 <heycam> ACTION: Chris to send Cameron an email with details on how to send a liaison statement to MPEG about SVG in OpenType
19:33:25 <trackbot> Created ACTION-3564 - Send cameron an email with details on how to send a liaison statement to mpeg about svg in opentype [on Chris Lilley - due 2014-02-06].
19:34:16 <ChrisL> http://letterror.com/fontcatalog/ltr-federal/
19:34:30 <heycam> ACTION: Cameron to propose something for marking up graphics with equivalent text
19:34:31 <trackbot> Created ACTION-3565 - Propose something for marking up graphics with equivalent text [on Cameron McCormack - due 2014-02-06].
19:36:31 <heycam> ChrisL: there are different optical sizes, but they're different fonts, for the filling of the "No" glyphs
19:36:40 <heycam> ... we should support that using media queries in SVG-in-OpenType
19:37:39 <heycam> ... but it's not quite possible yet, we don't yet have an appropriate MQ to do this
19:37:45 <heycam> heycam: this is related to the zoom MQ that Takagi-san wants
19:37:55 <heycam> ... we should work out what we need for this and give input to Ted etc. who are looking at zooming
19:38:26 <heycam> Topic: Percentage values on objectBoundingBox for content elements
19:38:51 <ed> http://lists.w3.org/Archives/Public/www-svg/2014Jan/0081.html
19:39:14 <heycam> ed: I think most people who responded to the mail said they preferred percenteages to be relative to the object bounding box and not the viewport
19:41:02 <heycam> krit: I think it should be oBB relative because browsers do bounding box dimension relative to the viewport dimension multiplied by percentage of viewport
19:41:04 <heycam> ... which is very confusing
19:41:21 <heycam> ... all browsers do that, that's interoperable behaviour
19:41:32 <heycam> Tav: Batik and Inkscape does it too
19:41:40 <heycam> krit: the specification says something different
19:41:47 <heycam> heycam: do you reckon anyone relies on it?
19:42:16 <heycam> krit: Illustrator partly, some examples do rely on what the spec says [i.e. different from impls]
19:42:19 <heycam> heycam: and what does the spec say?
19:42:23 <heycam> krit: it should be a percentage of the viewport
19:43:06 <heycam> krit: this is when you say maskContentUnits="objectBoundingBox"
19:43:13 <heycam> Tav: it's kind of strange that the mask would move when you widen the SVG
19:43:14 <heycam> krit: yeah
19:45:52 <heycam> ed: how much content would break?
19:46:08 <heycam> krit: people don't tend to use percentages here, because they don't understand the behaviour, and use 0..1 instead
19:46:47 <heycam> Tav: Inkscape doesn't generate using % objectBoundingBox values
19:47:07 <heycam> heycam: do we have tests in the test suite which support the current weird behaviour?
19:47:28 <heycam> krit: don't think so
19:48:09 <heycam> heycam: I think I'd be ok to be the guinea pig to try changing the behaviour here and see if we get any bugs
19:48:45 <cabanier_> Illustrator import would break since they resolve percentages wrt the viewport
19:49:10 <Tav> http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg
19:50:36 <heycam> Tav: not sure the spec is clear whether transforms on ancestors of these resource elements should be taken into account
19:51:20 <heycam> ChrisL: if there's specific wording in the spec you should suggest that
19:51:30 <heycam> ... we should add an example in test suite for that too to file a bug on rsvg
19:52:03 <heycam> ACTION: Tav to think of text to clarify whether transforms are taken into account with % objectBoundingBox values in resource elements
19:52:04 <trackbot> Created ACTION-3566 - Think of text to clarify whether transforms are taken into account with % objectboundingbox values in resource elements [on Tavmjong Bah - due 2014-02-06].
19:52:48 <heycam> -- lunch break --
20:22:50 <thorton> thorton has joined #svg
20:58:13 <shepazu> shepazu has joined #svg
20:58:14 <ChrisL> ChrisL has joined #svg
20:59:22 <pdr_> pdr_ has joined #svg
20:59:24 <slightlyoff_> slightlyoff_ has joined #svg
20:59:25 <birtles> birtles has joined #svg
20:59:26 <astearns> astearns has joined #svg
20:59:29 <TabAtkins_> TabAtkins_ has joined #svg
20:59:33 <cabanier_> cabanier_ has joined #svg
21:22:06 <shepazu> shepazu has joined #svg
21:22:15 <ChrisL> ChrisL has joined #svg
21:27:29 <shepazu> shepazu has joined #svg
21:27:31 <ChrisL> ChrisL has joined #svg
21:30:00 <Rossen_f2f> Rossen_f2f has joined #svg
21:33:20 <ChrisL> scribenick: chrisl
21:33:33 <ChrisL> topic: event handler attribute reflection
21:34:27 <ChrisL> ed: need wording to replicate what html5 has abour reflection in IDL and on-* attributes
21:34:32 <ChrisL> heycam: yes we do
21:35:04 <ChrisL> ed: reference html5 directly
21:35:19 <ChrisL> ChrisL: yes, unless its super specific
21:35:39 <ChrisL> action: erik to add ref to html5 for attr reflection
21:35:39 <trackbot> Created ACTION-3567 - Add ref to html5 for attr reflection [on Erik Dahlström - due 2014-02-06].
21:35:55 <ChrisL> topic: renaming svg resize and scroll events
21:36:20 <ChrisL> ed: html5 has resize and scroll events, not exatly same as svg which is specific to a fragment
21:36:24 <ChrisL> (checks)
21:37:08 <ChrisL> ed: resize is targetted to rootmost svvg element
21:37:20 <ChrisL> heycam: (what about namespace boundaries)
21:37:35 <ChrisL> only within an svg document fragment
21:37:47 <ChrisL> krit: what is it for object or embed
21:37:52 <ChrisL> heycam: the same
21:38:09 <ChrisL> heycam: suprised if people are listening to svg resize on outer html
21:38:35 <ChrisL> krit: relative sized inline svg, change window size
21:39:26 <ChrisL> heycam: no need to worry about html fragments inline. probably listening on html doc at the top or on window
21:39:46 <heycam> s/html fragments/svg fragments in html/
21:40:13 <ChrisL> shepazu: unless we find somethin unliveable users will find a way to do this
21:40:41 <ChrisL> ... do what hytml does. but new editor is not unfamiliar with svg and will understand the use cases
21:40:54 <ChrisL> ... if we need changes we should say
21:41:12 <ChrisL> heycam: not aware of anything needing to change. renaming is ok
21:41:24 <ChrisL> ... try it and look for breakage
21:41:37 <ChrisL> ed: exposed on html body and  window
21:41:38 <ed> The onblur, onerror, onfocus, onload, onresize, and onscroll event handlers of the Window object, exposed on the body element, replace the generic event handlers with the same names normally supported by HTML elements.
21:41:46 <ed> (from html5)
21:42:08 <ChrisL> ChrisL: so change body to body or svg
21:42:19 <ChrisL> heycam: they are actually listening to windopw
21:43:11 <ChrisL> ChrisL: we need to say they are exposed on svg element also
21:43:23 <ChrisL> ed: same for load event on window
21:43:42 <ChrisL> ... already have some wording for load events to make svg roots behave like body
21:44:28 <ed> The ‘svg’ element exposes as event handler content attributes a number of the event handlers of the Window object. It also mirrors their event handler IDL attributes.
21:44:38 <ed> (from svg2)
21:44:53 <ChrisL> ChrisL: so same wording for the others
21:45:01 <ChrisL> heycam: "a number" is vague
21:45:12 <ChrisL> ed: links to html5 to list them
21:45:15 <ed> https://svgwg.org/svg2-draft/struct.html#SVGElementEventHandlerAttributes
21:45:30 <ChrisL> ed: need to explicitly list them
21:46:45 <ChrisL> resolved: remove svg prefix on svgresize and svgscroll events
21:47:24 <ChrisL> action erik to remove svg prefix on svgresize and svgscroll events
21:47:24 <trackbot> Created ACTION-3568 - Remove svg prefix on svgresize and svgscroll events [on Erik Dahlström - due 2014-02-06].
21:48:30 <ChrisL> topic: scaling back features that suck performance
21:48:59 <ChrisL> heycam: hearing about wanting to better handle conent on lower performance machines
21:49:40 <ChrisL> ... working out what to do. if hardware is there and the machine is slow, it works but at low fps
21:50:05 <ChrisL> ... several approaches to make the websites less beutiful but functional and responsive
21:50:29 <ChrisL> ChrisL: do you have specific things that slow down
21:50:37 <ChrisL> heycam: no its across the whole stack
21:51:09 <ChrisL> heycam: one approach is to come up with out own hueristics to scale back features, things to turn off
21:51:40 <ChrisL> heycam: eg filters, reduce rendering or switch off
21:51:54 <ChrisL> heycam: can conformance be relaxed to codify that
21:52:19 <ChrisL> ... do people think there are particular features to scale back
21:53:23 <ChrisL> ChrisL: worried about relaxed conf criteria being also taken as the typical rendering
21:55:19 <Rossen_f2f_> Rossen_f2f_ has joined #svg
21:55:29 <ChrisL> ChrisL has joined #svg
21:55:32 <shepazu> shepazu has joined #svg
21:55:33 <Smailus> Smailus has joined #svg
21:55:34 <TabAtkins_> TabAtkins_ has joined #svg
21:55:34 <slightlyoff_> slightlyoff_ has joined #svg
21:55:38 <ChrisL>  topic: scaling back features that suck performance
21:55:38 <ChrisL> <ChrisL> heycam: hearing about wanting to better handle conent on lower performance machines
21:55:38 <ChrisL> <ChrisL> ... working out what to do. if hardware is there and the machine is slow, it works but at low fps
21:55:38 <ChrisL> <ChrisL> ... several approaches to make the websites less beutiful but functional and responsive
21:55:40 <ChrisL> <ChrisL> ChrisL: do you have specific things that slow down
21:55:44 <ChrisL> <ChrisL> heycam: no its across the whole stack
21:55:46 <ChrisL> <ChrisL> heycam: one approach is to come up with out own hueristics to scale back features, things to turn off
21:55:48 <ChrisL> <ChrisL> heycam: eg filters, reduce rendering or switch off
21:55:50 <ChrisL> <ChrisL> heycam: can conformance be relaxed to codify that
21:55:52 <ChrisL> <ChrisL> ... do people think there are particular features to scale back
21:55:54 <ChrisL> <ChrisL> ChrisL: worried about relaxed conf criteria being also taken as the typical rendering
21:55:56 <ChrisL> * Disconnected (No such device or address)
21:56:30 <ChrisL> ChrisL: in games is miostly user selected
21:56:53 <heycam> heycam has joined #svg
21:57:04 <ChrisL> Rossen_f2f: if this is done by the user agent, afraid there will be fast disparity between implementations depending on internal efficiency
21:57:18 <ChrisL> ... so you get great disparity on the same device
21:57:25 <ChrisL> ... if they are automatic
21:58:02 <ChrisL> ... if the policy is across all devices they can be automatic (low medium high) as long as they are defined exactly what happens
21:58:22 <ChrisL> ... and user must have right to override that
21:58:34 <ChrisL> shepazu: could be user agent dependent
21:59:15 <ChrisL> heycam: to decide what to scale back, 2 approaches: spec what it means, or author indicates disposable features and priority
21:59:53 <ChrisL> ChrisL: authors will do what works on their UA, not test on otyhers
21:59:54 <shepazu> q+
22:00:04 <ChrisL> Rossen_f2f_: ask performance wg about this
22:00:43 <ChrisL> krit: uas cvary so affect uas differently. does not necessarily help
22:01:03 <ChrisL> heycam: uas will auto adjust based on actual performance
22:01:15 <ChrisL> krit: not opposed to performance profiles
22:01:44 <ChrisL> Rossen_f2f_: same her, as long as testable and results will not vary by user agent at the same level on the same device
22:02:22 <ChrisL> ... figure out if it makes sense to sacrifice filters in medium or not (varies by UA)
22:02:36 <ChrisL> ... it will be sacrifice for sure
22:03:02 <ChrisL> birtles: if i have something with gpu optimisation, want to use that
22:03:17 <ChrisL> heycam: would not want to force user intervention
22:03:41 <ChrisL> ... bad to cripple the better implementation
22:03:53 <ChrisL> krit: use media queries for this
22:04:08 <ChrisL> ... author can decide what is important for high quality
22:05:05 <ChrisL> birtles: cant be entirely author device because many authors do not test widely
22:05:25 <ChrisL> heycam: bad to reduce functionality on a device that can do it
22:07:10 <ChrisL> ChrisL: have low medium high auto where auto scales by fps
22:07:47 <ChrisL> shepazu: engage with Khronos (webgl guys) about performance levels
22:08:03 <ChrisL> ... perfomance based characteristics. also did openvg
22:08:25 <ChrisL> ... willing to work with us. identified as a liaison item
22:09:21 <ChrisL> Rossen_f2f_: can argue both sides
22:10:13 <ChrisL> Rossen_f2f_: on mobile, browser defines the experience. need to get best experience possible on that device
22:10:26 <ChrisL> ... also depends on the competition
22:10:59 <ChrisL> heycam: now they can get different performance experience
22:11:20 <ChrisL> Rossen_f2f_: will also give behaviour changes
22:11:22 <ChrisL> ack shepazu
22:11:34 <ChrisL> q?
22:12:06 <ChrisL> shepazu: can we have best and worst levels for each feature
22:12:28 <ChrisL> ... say 2 uas on same hardware, one has hw accell on one thing is worse on something else
22:12:50 <ChrisL> ... so it would be predictsable what level it goes to
22:13:05 <ChrisL> ... level of service knocked out is independent
22:13:21 <ChrisL> Rossen_f2f_: so a minimum bar not an absolute bar
22:13:28 <ChrisL> shepazu: yes, and per feature
22:13:34 <ChrisL> ... so it is predictable
22:13:48 <ChrisL> heycam: that specificity would be good
22:14:22 <ChrisL> heycam: so there is a combinatorial explosion of profiles
22:14:52 <ChrisL> shepazu: maximises experience for user and author, also allows ua to compete on performance while still being predictable at a given level
22:15:37 <ChrisL> heycam: even if it is continuous, can reduce filer resolution for example, or should it be discrete
22:15:42 <ChrisL> shepazu: three levels
22:15:48 <ChrisL> Rossen_f2f_: low medium high
22:16:32 <ChrisL> heycam: imagine we discover that continuous perf improvement on filters with lower scale bitmaps. should they be allowed to vary or mnust they drop down to a discrete level
22:16:45 <ChrisL> shepazu: best is "do this or better"
22:17:01 <ChrisL> heycam: is that performance or rendering behaviour?
22:17:22 <ChrisL> shepazu: we set a minimum bar
22:17:34 <ChrisL> Rossen_f2f_: some impls could not make that
22:18:11 <ChrisL> Smailus: what defines what is in the profile, it changes over time
22:20:11 <ChrisL> Rossen_f2f_: if we have them, how does it benefit the content author to develop over device evolutions
22:20:22 <ChrisL> ... ua gets a better impl on the same device
22:20:38 <ChrisL> ... how would the content start to take advantage of that
22:21:11 <ChrisL> heycam: was thinking author would get perf benefir of scaling back features by defining how operations are done, including ignoring features
22:21:20 <ChrisL> ... not @media low-perf
22:21:38 <ChrisL> ... so when the usa meets te bar it uses high perf mode
22:21:59 <ChrisL> krit: these were requested four years ago already
22:22:35 <ChrisL> krit: sometimes a drop shadow is purely decoration and you drop it
22:22:47 <ChrisL> Rossen_f2f_: media queries f=to get the current perf level
22:23:06 <ChrisL> krit: what if you still are too low perf. can you drop features
22:23:26 <ChrisL> heycam: what if you are medium level then set properties that use higher perf features
22:23:44 <ChrisL> ... worry about author access to perf tweaks because they age badly
22:24:09 <ChrisL> Rossen_f2f_: hard to define the matrix of allowed capabilities
22:24:18 <ChrisL> heycam: dont want to do that per device
22:24:32 <ChrisL> .. want it done automatically
22:24:54 <ChrisL> Rossen_f2f_: some devices will be "always high"
22:25:22 <ChrisL> heycam: dont want to test on lots of devices to get the perf. want guidelines on how to tel lif perf is inadequate
22:25:48 <ChrisL> ChrisL: is perf mai=nly in terms of fps
22:25:50 <ChrisL> heycam: yes
22:26:45 <ChrisL> heycam: can always have ginormous files, stil lwant to auto scale back for that
22:27:50 <ChrisL> shepazu: suggest we say its interesting buf not define today
22:28:01 <ChrisL> krit: not going anywhere concrete
22:28:06 <ChrisL> shepazu: open to proposals
22:34:31 <Smailus> Smailus has joined #svg
22:38:47 <ChrisL> topic: a hazelnut in every bite
22:39:30 <ChrisL> topic: it goes to eleven
22:40:21 <ChrisL> topic: krit's keywords
22:40:42 <ChrisL> krit: (daws pretty pictures which we neglect to capture)
22:42:01 <ChrisL> bounding box of a stroke where there is dashing, taking into account miter limit, where the dashing does not cover the corner
22:43:48 <ChrisL> three options 1) actual painted area 2) geometric 3) maximal with miter limit and stroke geometry
22:44:46 <ChrisL> Rossen_f2f_: makes sense when ther is fill, not without
22:44:54 <ChrisL> krit: depends on miter limit
22:44:59 <ChrisL> birtles: and line cap
22:45:53 <ChrisL> (we don't want bounding box to oscillate if a dashed stroke animates start position)
22:46:41 <ChrisL> heycam: for beziers the exact tightest bound is expensive and not wirth it eg for a repaint region
22:46:49 <ChrisL> cabanier_: mostly you want loose bounds
22:46:58 <ChrisL> s/wirth/worth
22:47:23 <ChrisL> cabanier_: make it as fast and loose as possible
22:48:07 <ChrisL> (discussion on getting data back from gpu)
22:48:33 <ChrisL> (which is hard and slow, by the way, and endlessly fascinating as a conversational topic)
22:48:55 <ChrisL> cabanier_: you get the box you need stroking
22:49:11 <ChrisL> heycam: can stroke with transparent paint, or compute in offscreen buffer
22:49:45 <ChrisL> shepazu: does anyone disagree with 3
22:50:11 <ChrisL> cabanier_: option 4 is convex hull of control points
22:51:04 <ChrisL> heycam: really want to avoid the marching ants problem
22:52:06 <ChrisL> birtles: if someone animates miter limit
22:52:11 <ChrisL> (no one really does)
22:52:23 <ChrisL> shepazu: asks about vector effects
22:52:36 <ChrisL> ChrisL: no implementor interest unfortunately
22:52:58 <ChrisL> cabanier_: should be a more precise version too
22:53:16 <ChrisL> shepazu: add several ones
22:53:23 <ChrisL> Rossen_f2f_: over engineering
22:53:45 <ChrisL> heycam: we should be doing that (markers, stroke, etc etc)
22:54:42 <ChrisL> krit: css gradients on object bounding box. only covers half the stroke!
22:54:51 <ChrisL> ... so we need something better
22:55:07 <ChrisL> ... choose stroke outline instead, for a decorated bbox
22:55:48 <ChrisL> Rossen_f2f_: exactly like semi transparent dashed borders over background
22:56:40 <ChrisL> heycam: bbox of control points, can we do same for stroke and say ignore dashing
22:57:04 <ChrisL> krit: backend engine needs to do it twice, once without dashing
22:57:25 <ChrisL> ... better to just look at points without rendering
22:58:04 <ChrisL> cabanier_: only fails with stupid miter limits
22:58:09 <ChrisL> krit: can happen
22:58:38 <ChrisL> heycam: polygon with exact points, stroke width 10px, what do you do
22:59:02 <ChrisL> krit: miter limit on slallest angle, add miter limit ...
22:59:29 <ChrisL> heycam: ignore ML. calc disatnace from lime by stroke width
22:59:40 <ChrisL> .. same as doing stroke path operation, same maths
22:59:56 <ChrisL> krit: so we need to do it twice
23:01:02 <ChrisL> heycam: fudge factor to pad convex hull bbox, proportional to stroke width
23:01:46 <ChrisL> ChrisL: added onto the four sides of the chull bbox
23:02:07 <nikos> nikos has changed the topic to: 
23:02:10 <nikos> oops
23:03:11 <ChrisL> shepazu: people would find it counter intuitive
23:03:21 <ChrisL> krit: yes, not i am convinced on 3
23:03:31 <ChrisL> s/not/now
23:04:21 <nikos> nikos has changed the topic to: SVG Working Group - https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda - see http://wiki.csswg.org/planning/seattle-2014 for dial in information.
23:05:42 <ChrisL> 3 3 3 3 3 4 2 4 4
23:06:07 <ChrisL> cabanier_: perf will be really slow
23:06:23 <ChrisL> Rossen_f2f_: 3 on high, 4 on low ...
23:06:57 <ChrisL> shepazu: want to see some perf metrics and see how inaccurate 4 is
23:07:26 <ChrisL> cabanier_: illustrator uses 4 for selection hilight
23:07:55 <ChrisL> heycam: add an issue in the spec
23:08:04 <ChrisL> shepazu: they will do the easiest one
23:08:10 <ChrisL> Rossen_f2f_: the most performance one
23:09:04 <ChrisL> shepazu: how often is bbox called
23:09:24 <ChrisL> heycam: for this new one, not at all :)
23:09:38 <ChrisL> krit: stroke bbox is in blink, not activated, gets used a lot
23:10:30 <ChrisL> birtles: in future decorated bbox will be called a lot
23:13:02 <ChrisL> krit: problem if filling with image, missing some pixels due to inaccuracy
23:14:05 <ChrisL> ChrisL: image size for the fill should not be affected by the exact position dashes fall
23:14:25 <heycam> https://hg.mozilla.org/mozilla-central/file/6f544aa66c1a/layout/svg/nsSVGUtils.cpp#l1000 is what we use to work out an upper limit for the bbox of a stroked shape without actually calculating the stroke shape
23:15:36 <ChrisL> heycam: our calc for repain region ignores miter limit, just stroke width
23:15:46 <ChrisL> ... so pad bbox by half stroke width
23:15:57 <ChrisL> s/pain/paint/
23:16:28 <heycam> the input to that function is the bbox of the geometry that has already taken miter limit into account
23:16:31 <heycam> or miters into account
23:17:16 <ChrisL> zakim?
23:17:21 <Zakim> Zakim has joined #svg
23:17:28 <ChrisL> zakim, room for 2?
23:17:29 <Zakim> ok, ChrisL; conference Team_(svg)23:17Z scheduled with code 26631 (CONF1) for 60 minutes until 0017Z
23:17:40 <ChrisL> nikos, call into zakim plz
23:18:14 <Zakim> Team_(svg)23:17Z has now started
23:18:21 <Zakim> + +1.206.675.aaaa
23:19:10 <Zakim> +nikos
23:19:48 <ChrisL> krit: one dash on an ellipse ....
23:23:09 <heycam> http://lists.w3.org/Archives/Public/www-archive/2014Jan/0014.html
23:23:13 <heycam> ^ picture
23:23:23 <Smailus> Smailus has joined #svg
23:23:38 <ChrisL> krit: want to add both methods to the spec and add an issue
23:25:08 <ChrisL> shepazu: representing authors and users. informed decision needs data
23:25:30 <ChrisL> birtles: best to gather data as we implement
23:25:51 <ChrisL> shepazu: ask the community, give the tradeoffs perf and precision
23:27:02 <ChrisL> krit: not happy, does not help until they implement so defers
23:27:12 <ChrisL> shepazu: option3 won the vote
23:28:02 <ChrisL> .... put issue saying maybe 4
23:28:22 <ChrisL> shepazu: spec can be referenced at any level as long as the portion is stable
23:30:11 <ChrisL> (process explanations of stability criteria)
23:30:45 <ChrisL> action krit to add decorated bbox option 3 to svg2 with issue explaining option 4
23:30:46 <trackbot> Created ACTION-3569 - Add decorated bbox option 3 to svg2 with issue explaining option 4 [on Dirk Schulze - due 2014-02-06].
23:31:03 <ChrisL> break
23:31:23 <heycam> -- 15 minute break --
23:32:30 <Zakim> -nikos
23:51:21 <birtles> Scribenick: birtles
23:51:24 <birtles> Scribe: Brian
23:51:30 <birtles> topic: SVG2 status
23:51:42 <Zakim> +nikos
23:51:59 <birtles> heycam: one concrete thing I'd like to discuss is out new cut-off date
23:52:04 <birtles> ... at TPAC we thought we needed more time
23:52:11 <birtles> ... so we extended it from the end of last year
23:52:15 <birtles> ... so we need a replacement date
23:52:42 <birtles> birtles: what is left?
23:52:46 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
23:53:39 <birtles> heycam: let's see what's left per-person
23:55:35 <heycam> trackbot: close action-3271
23:55:36 <trackbot> Closed action-3271.
23:57:16 <birtles> ... starting with Doug
23:57:48 <birtles> ... 19 - level of detail -- covered by zoom media queries which Takagi-san has been looking into and we are waiting on Ted's investigation into
23:58:00 <birtles> ... Cameron will mark this one yellow
23:58:26 <birtles> ... 20 - InkML trace groups -- covered by variable-width stroke
23:59:04 <birtles> ... 40 - Catmull-Rom curves - keep it
23:59:30 <birtles> ... 41 - Regular polygons and stars - keep it, work with Tav
23:59:58 <birtles> Doug: 47 - flip-invariant text - keep it, need to talk to others
00:01:18 <birtles> ... 52 - Tooltip - keep it, Dirk interested
00:02:01 <birtles> ... 91 - Bounding box text, Dirk to take
00:03:24 <birtles> ... 93 - content editable - Doug will look at another way of looking at editing markup but possibly not part of SVG2, remove
00:03:42 <birtles> heycam: unless you want to define how it should work if you have contentEditable on an ancestor HTML element
00:03:53 <birtles> shepazu: you should be able to edit the text
00:03:58 <birtles> heycam: we need to define that
00:05:48 <birtles> Doug: 100 - Support for key events from DOM level 3 events
00:05:58 <birtles> krit: didn't Rich ask about referencing DOM4?
00:06:07 <birtles> heycam: yes, I think he referenced DOM3 in the end
00:06:53 <birtles> Doug: close this issue, stuff has already happened in the spec
00:08:01 <birtles> ... 128 - define how border and background apply to SVG, keep it
00:08:07 <birtles> ... 129 - outline property, keep it
00:09:40 <birtles> ... 130 - clarify how pointer-events can hit the root SVG or not, Erik to tke
00:09:53 <birtles> s/to tke/to take/
00:10:15 <birtles> Chris: 28 - color management, closed
00:10:43 <birtles> ... 30 - non-scaling features (e.g. rectangle corners)
00:11:01 <birtles> krit: we don't want to extend that, we found too many issues with this
00:11:11 <birtles> ... defer it
00:11:56 <birtles> ChrisL: 48 - deprecate xml:space and use CSS white-space
00:12:11 <birtles> heycam: give the CSS part to Tav who is rewriting the text part
00:13:28 <birtles> ChrisL: 62 - linear interpolation for some properties which are currently discrete only -> pass to Brian
00:13:58 <birtles> ... 66 - remove requirement for width/height from foreignObject
00:14:23 <birtles> (discussion about whether this is possible and if we should do it for foreignObject only)
00:14:38 <birtles> ChrisL: it's a fairly simple fix for this case, I think
00:14:44 <birtles> krit: I don't know that it is
00:15:10 <birtles> heycam: if there's HTML content inside use the shrink-wrapping algorithm to work out the size
00:15:42 <birtles> ... it's like the minimum width that doesn't break a line, or something like that
00:15:49 <birtles> ... it's what you use with absolute positioning
00:15:53 <birtles> ChrisL: I'll do it
00:16:10 <birtles> ... 70 - CSS3 Color syntax - done
00:17:36 <thorton> thorton has joined #svg
00:17:53 <birtles> ... 73 - Align CSS Value and Units
00:18:05 <birtles> heycam: I think I aligned some things but I haven't added new units etc.
00:18:08 <birtles> ... I'm happy to take it
00:18:11 <birtles> ChrisL: it's yours
00:18:30 <birtles> ... 76 - allow clip to reference any element
00:19:07 <birtles> krit: clip property is now deprecated
00:19:08 <ed> http://www.w3.org/Graphics/SVG/WG/track/issues/2355
00:19:15 <birtles> heycam: that should actually be clip-path
00:19:26 <birtles> krit: this is actually now part of CSS masking
00:19:33 <birtles> ... but it won't be in the first level
00:19:37 <birtles> ... give the action to me
00:19:54 <birtles> (make it yellow)
00:20:01 <birtles> (means "handled in another spec")
00:20:15 <birtles> ChrisL: 82 - WOFF support - done
00:21:07 <birtles> ... 89 - viewport-fill(-opacity) / background-color
00:22:27 <birtles> (discussion about whether viewport units can be used to cover the use cases for this feature)
00:22:52 <birtles> ... keep it
00:23:13 <birtles> ... 92 - improved text re: characters/glyphs/selection etc.
00:23:31 <birtles> heycam: Tav is reworking a lot of text stuff now so it might be worth waiting to see what he's done
00:23:47 <birtles> ChrisL: I'll do it if he hasn't
00:24:03 <birtles> krit: add Tav's name to 92
00:24:20 <birtles> ChrisL: 115 - currentFillPaint, currentStrokePaint - done by heycam
00:24:40 <birtles> ... 119 - Use updated CSS3 specs - heycam to do
00:25:02 <birtles> ... 126 - Require SVG Tiny fonts - no, close with no action
00:25:24 <birtles> ... 127 - Make CSS mandatory - keep
00:26:01 <birtles> ... 131 - xlink prefix for href
00:26:07 <birtles> krit: I already defined this in CSS Masking
00:26:12 <birtles> ChrisL: I'll copy it from there
00:26:32 <birtles> krit: either there or filters
00:26:58 <birtles> ChrisL: 138 - allow masks to use alpha/luminance both - covered by CSS Masking
00:27:39 <birtles> ... 140 - masks pointing to mask elements only - covered CSS Masking + element()
00:28:14 <birtles> heycam: 1 - Backwards compat note - skip it
00:28:25 <birtles> ... 9 - markers done
00:28:31 <birtles> ... 10 - fix DOM, ongoing
00:28:42 <birtles> ... (lots of items done, good work Cameron!)
00:28:52 <birtles> ... 25 - data-* attributes, keep
00:30:02 <birtles> ... 26 - HTML5 global semantic attributes - keep it, need to check what is in HTML
00:30:38 <birtles> ... 27 - make property values case insensitive - I might have done it, need to check
00:32:32 <birtles> ... 33 - stroke dash adjustment - keep it, I'll see what I can do
00:32:48 <birtles> ... 36 - align the style element with the HTML5 style element, keep it
00:33:25 <birtles> ... 45 - glyph baselines
00:33:48 <birtles> ... the text chapter will reference CSS text for this
00:34:38 <birtles> ... keep it
00:35:03 <birtles> ... 49 - transforms on tspans - keep it
00:35:34 <birtles> ACTION: Cameron to write spec text on transforming tspans
00:35:34 <trackbot> Created ACTION-3570 - Write spec text on transforming tspans [on Cameron McCormack - due 2014-02-07].
00:35:42 <birtles> krit: does this belong in CSS transforms?
00:35:48 <birtles> ... if so please notify www-style
00:35:58 <birtles> heycam: do you list applicable elements in CSS Transforms?
00:35:59 <birtles> krit: yes
00:36:03 <birtles> heycam: ok, I'll do that then
00:36:20 <birtles> ... 54 - Support HTML document-wide events and make sure they apply to SVG document, keep it
00:36:29 <birtles> ... 57 - async and defer on script elements
00:36:57 <birtles> ... at first I thought this was a good idea but others including Hixie actually thought there was lots of craziness in HTML we don't want that
00:37:20 <birtles> ... keep it, possible drop it
00:37:41 <birtles> ... 69 - positioning information in MouseEvents, keep it
00:37:55 <birtles> ... 74 - deprecate baseline-shift, vertical align, keep it
00:38:11 <birtles> ... 80 - DOM method to convert <text> to outline path data
00:38:24 <birtles> cabanier_: that's part of the Canvas path API which is separate to Canvas
00:39:16 <birtles> heycam: but the requirement is to get actual path data
00:39:35 <birtles> ... so I can actually manipulate the path segments
00:39:43 <birtles> cabanier_: that might not be available then
00:40:01 <birtles> ... it might be possibe
00:40:07 <birtles> s/possibe/possible/
00:40:51 <birtles> cabanier_: it lets you get an opaque pointer to the outlines that you can do operations on it but not individual segments
00:41:43 <birtles> ... keep it
00:41:51 <birtles> ... 108 - inline scriptable content, keep it
00:42:01 <birtles> ... 109, 110 - more script stuff, keep it
00:42:40 <birtles> ... 118 - CSS3 definitions for text, keep it
00:43:03 <birtles> ... 121 - Move events to Element
00:43:20 <birtles> ... nothing to do (Hixie says no)
00:43:38 <birtles> ... 122 - Path rotation command - done
00:44:24 <birtles> ... 123 - Introduce evt as alias to event, give it to Erik
00:44:34 <birtles> ... 124 - object-fit, object-position, keep it
00:44:50 <birtles> ... 132 - remove restriction on tref, done
00:44:55 <birtles> krit: does tref still exist?
00:45:07 <birtles> heycam: in any case, it's already done
00:45:23 <ed> https://svgwg.org/svg2-draft/text.html#TRefElement
00:46:23 <birtles> birtles: 14 - fix path APIs, keep it, might still be needed depending on how DOM improvements go
00:46:36 <birtles> ... 96 - synchronization, make yellow (Web Animations)
00:48:47 <birtles> ... 111 - Changes to animation, move to Animation Elements spec (yellow)
00:49:48 <birtles> krit: 51 - video in SVG, Takagi-san did this already
00:50:07 <birtles> ... 75 - captions for video, Takagi-san did this too
00:50:24 <birtles> ... 139 - canvas in SVG2, Takagi-san did this too!
00:50:43 <birtles> ... 21 - transform on the <svg> element, keep this
00:51:02 <birtles> ed: 29 - non-scaling stroke, done
00:51:28 <birtles> ... 55 - drag&drop, we have the global event handlers
00:51:43 <birtles> heycam: we need to add a sentence to say this works in SVG
00:51:54 <birtles> ed: will do
00:52:29 <birtles> ... 71 - image-fit, this is now object-fit which Cameron will do
00:52:52 <birtles> ... 87 - buffered-rendering, done?
00:52:58 <birtles> heycam: now that we have will-change do we need it?
00:53:02 <birtles> ed: we could reconsider it?
00:53:09 <birtles> ... it's not the exact-same thing
00:53:26 <birtles> heycam: let's discuss this in a telcon later
00:53:43 <birtles> ... 88 - vector-effect, this is non-scaling stroke, done
00:53:49 <heycam> ISSUE: should we have both buffered-rendering and will-change?
00:53:49 <trackbot> Created ISSUE-2452 - Should we have both buffered-rendering and will-change?.  Please complete additional details at <http://www.w3.org/Graphics/SVG/WG/track/issues/2452/edit>.
00:54:00 <birtles> ... 116 - focal point for radial gradients, done by Dirk
00:54:15 <birtles> ... 117 - fr attribute for radialGradient, done by Dirk/Tav
00:54:27 <birtles> ... 125 - text-overflow, done
00:54:40 <birtles> ... 126 - SVG Tiny fonts, no longer needed
00:55:29 <birtles> cabanier_: 20 - variable-width stroke - will discuss tomorrow
00:55:56 <birtles> heycam: only others are Tab, Tav and Cyril
00:56:47 <birtles> ... for Tab, z-index
00:57:01 <birtles> (discussion about whether to keep it or not)
00:57:08 <birtles> ... keep it for now
00:58:27 <birtles> ... Cameron to look into it
00:59:03 <birtles> 42 - arc in paths in easier
00:59:11 <birtles> heycam: I partly addressed this with the bearing commands
00:59:37 <birtles> ... we discussed adding all the canvas arc commands to SVG but I'm not sure
01:00:13 <birtles> ... assign it to Rik
01:00:33 <birtles> 89 - This is just Chris now
01:01:25 <birtles> 6 - namespace requirements, add Dirk
01:01:34 <heycam> Zakim, who is on the call?
01:01:34 <Zakim> On the phone I see +1.206.675.aaaa, nikos
01:01:35 <birtles> 8 - shadow tree, add Dirk
01:01:59 <birtles> 39 - shared path segments, leave it with Cyril
01:02:19 <birtles> 95 - animation element, covered by iframe work done by Takagi-san
01:02:58 <Zakim> -nikos
01:03:26 <birtles> 135, 136 - done in SVG2, Brian to remove from here and add to Animation Elements
01:04:04 <birtles> 137 - playbackOrder - Brian to remove from SVG2 and maybe add to Animation Elements
01:04:21 <birtles> We'll cover Tav's items tomorrow
01:04:49 <birtles> heycam: those items without names associated we will not do since no one is interested
01:05:00 <birtles> birtles: so can we now estimate our next deadline?
01:06:32 <birtles> heycam: we should have a cut-off date for new features and then allow a few months for getting to LC
01:06:50 <birtles> ... and I think that cut-off date should be June 30
01:07:58 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)23:17Z
01:08:01 <Zakim> Team_(svg)23:17Z has ended
01:08:01 <Zakim> Attendees were +1.206.675.aaaa, nikos
01:09:34 <ed> RRSAgent, make minutes
01:09:34 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/30-svg-minutes.html ed
01:18:01 <heycam> RRSAgent, bye
01:18:01 <RRSAgent> I see 8 open action items saved in http://www.w3.org/2014/01/30-svg-actions.rdf :
01:18:01 <RRSAgent> ACTION: Erik to clarify <script> is not affected by <switch> and will be run in there, but is still disallowed by the content model. [1]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T17-48-40
01:18:01 <RRSAgent> ACTION: Erik to add onbegin, onend, onrepeat to SVGAnimationElement. [2]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T18-32-05
01:18:01 <RRSAgent> ACTION: Erik to mention in SVG 2 that rootElement is deprecated. [3]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T18-57-07
01:18:01 <RRSAgent> ACTION: Chris to send Cameron an email with details on how to send a liaison statement to MPEG about SVG in OpenType [4]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T19-33-24
01:18:01 <RRSAgent> ACTION: Cameron to propose something for marking up graphics with equivalent text [5]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T19-34-30
01:18:01 <RRSAgent> ACTION: Tav to think of text to clarify whether transforms are taken into account with % objectBoundingBox values in resource elements [6]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T19-52-03
01:18:01 <RRSAgent> ACTION: erik to add ref to html5 for attr reflection [7]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T21-35-39
01:18:01 <RRSAgent> ACTION: Cameron to write spec text on transforming tspans [8]
01:18:01 <RRSAgent>   recorded in http://www.w3.org/2014/01/30-svg-irc#T00-35-34