SVG F2F Seattle 2014 Day 1 -- 30 Jan 2014

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Resolving dates for April F2F

shepazu: where is it?

ChrisL: Leipzig

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014

<ChrisL> http://libregraphicsmeeting.org/2014/

heycam: that's 2-5 April for LGM

ChrisL: which Wednesday to Saturday

heycam: so meeting from Monday 7th April

shepazu: I have Annotations workshop in SF around that time unfortunately

ed: how many days?

heycam: I probably prefer 4, so we can get a lot of work done

ChrisL: have we got a meeting space? has anybody approached the university hosting the conference?

heycam: Tav is in contact with them

birtles: I agree 4 days is long but if we're taking the time/money to get there...
... then maybe it's worthwhile

ChrisL: at that time of the year we'll be hopefully be trying to wind up and go to Last Call for SVG2

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
... 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
... where you try to finish up the things resolved during the F2F
... so people who need to leave after the core meeting can

ed: so the proposal is April 7 - 10?

krit: we should talk about who's sponsoring

ChrisL: the university would supply a room but not food

heycam: previously we've had F2Fs where we went out for lunch, and not had catering

krit: that's OK by me

RESOLUTION: The April F2F will be April 7-10, where the 10th is an optional stay-for-spec-editing day.

ed: how about the Graphical Web F2F?
... it's at the end of August

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

ChrisL: 27-30

<ChrisL> http://svgopen.org/2014/

heycam: that's another Wednesday-Saturday

krit: regarding Leipzig, the semester holiday ends right when we would be meeting
... so maybe it will be harder to get a room there

heycam: to get the spacing better, we should meet before Graphical Web IMO
... would we be happy with Sat-Tue? or maybe Fri-Mon?

krit: this is a university again by the way

<ChrisL> tpac 27 Oct to 31 Oct 2014 in Santa Clara, California

heycam: if we met after Graphical Web, then we would be meeting in September and then in October for TPAC
... so we could do it Sat-Tue before, and make Sun the optional spec editing day or just a day off
... or Thu-Fri on, Mon-Tue on, weekend off

ed: I don't mind either

shepazu: let's decide the exact before-Graphical-Web dates later

should script be affected by <switch>

shepazu: no

heycam: no

ed: no

ChrisL: if you were designing from scratch maybe, but given how <script> already works now...

heycam: I am pretty sure all implementations will run script without looking at <switch>

RESOLUTION: <script> is not affected by <switch>

<scribe> ACTION: Erik to clarify <script> is not affected by <switch> and will be run in there, but is still disallowed by the content model. [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action01]

<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].

birtles: I don't see the point of disallowing stuff that will work

ChrisL: it's disallowing stuff that people might have reasonable expectations of working differently

ed: I think we should encourage people to put <script> in <defs>

birtles: we could say authors SHOULDN'T put it in <script>

ed: I think it's fine to remove the content model restriction but to encourage to put it in <defs>

heycam: I'm not sure of <defs>

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>

action updated

deprecating/removing hasFeature

krit: are we talking about deprecating or removing?

birtles: the proposal from Anne was to make it always return true

krit: so not removing it, but deprecating and making default return true
... if you look at the WebKit/Blink source code, we do something with this feature
... the question is is any script using it
... given this part of our source code is outdated it's not really reliable
... iirc, hasFeature is indirectly called by <switch>
... which doesn't mean anything, ...

ChrisL: it's one of those features that sounded good, thought it would be the way forward, turned out it wasn't

birtles: I think we haven't deprecated it yet right?

krit: in HTML content true is always returned

birtles: I think we return proper values for it

heycam: hasFeature is defined in DOM btw

ChrisL: it was never clear if you needed to support 100% of a feature to return true

birtles: now with things like modernizr...

krit: did someone add a use counter for hasFeature?

birtles: a few days ago someone did I think?

<ed> http://code.google.com/p/chromium/issues/detail?id=335301

shepazu: in DOM 3 Events we come up with a logical way to make hasFeature work
... for fine grained control for reporting
... which was roundly rejected by anne and others
... which is expensive and other things which are not feature testable

<birtles> the usage counter has been added to blink: http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.html

shepazu: I won't get in the way of removing it, but I think it's being done on outdated data

<birtles> https://code.google.com/p/chromium/issues/detail?id=335301

shepazu: I've had conversations with Paul Irish about testing whether certain SVG features are available, and there weren't

Rossen_f2f: can't you piggyback off @supports for this?

shepazu: I don't mind

birtles: I think it's not going to work when there are bugs in the features that are being reported as true
... which you often want to test for

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?
... you're really saying if I use this in this way, in combination with this other thing, ...

shepazu: feature detection won't work for that either

Rossen_f2f: why wouldn't feature detection work?

shepazu: it can't test for rendering things

birtles: Safari on iOS 5 for example paints patterns upside down
... for that you really need to do UA string checking
... so I think that's an advantage of feature testing, you can test for exactly what you need

ed: should we wait for the use counter results?
... I wouldn't mind if we returned true all the time

Rossen_f2f: you're trying to do implementaiton detection through feature detection
... which doesn't seem to be exactly what feature detection is for
... if you want to detect "what is the rendering of something" ...

krit: there's a difference between supporting a property and supporting it in the rendering pipeline

Rossen_f2f: your @supports or hasFeature should still return false in this case
... I'm with Doug that hasFeature and feature detection are useful and good to keep
... still people are building solutions on top of this can impl versions of their apps that are best for that feature set

krit: if you ask "do you support filters"? you might return true, even if you don't support all filter inputs

sgalineau: that's true, but that's not an argument for not doing it at all
... that's why @supports gives you the ability to check for property values

birtles: I'm just not sure you ever get enough granularity
... for animations, you could even test the supported values, like syncbase values, but you don't know if it supports cyclic dependencies

shepazu: but you could add feature detection for specific cases like this
... but for other cases you wouldn't need to
... pdr just said 10% of pages use SVG, which is misleading because a lot of that is Modernizr

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

shepazu: but people will use it poorly
... the case where you inject SVG because you might use it, is different from doing it for feature detection
... I think the pattern of having to download scripts that are getting increasingly large, as there are more features added to the platform
... 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,
... I think that's us being lazy and harming authoring

sgalineau: that's why we have @supports

Rossen_f2f: at the end of the day, it's a poor man's implementation of reflection
... and reflection is useful

shepazu: maybe hasFeature is not the right place to do this
... I'm suggesting we should have reflection at all levels of the stack
... we can remove hasFeature, but let's not say we don't need the functionality, because we do

ed: let's postpone until we get the use counter results

adding SVG specific events to GlobalEventHandlers

krit: was the editor of the spec with this interface had a chance to look at it?

ed: Boris Zbarsky replied

<ed> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/041909.html

onbegin, onend, onrepeat, onzoom

ed: I'm proposing we don't add onbeing/onend/onrepeat
... for SVGZoom I'm not sure about it
... we could remove the prefix

ChrisL: would it conflict it with current work on defining zoom?

ed: relatedly I also posted a patch to Blink to add the global event handlers
... so you assign to .onclick on SVG elements

heycam: what are we doing about zoom event altogether?
... did we discuss getting rid of the "SVG" prefix?

ed: we did, for those that have existing counterparts
... so that's all the events except for SVGZoom

krit: zooming is being discussed in CSSWG

<ed> and endEvent/beginEvent/repeatEvent

krit: should we check what the outcome of that is first? before we add a global onzoom?

ed: it doens't need to be resolved right away
... I don't think SVGZoom is used much

birtles: can we drop it even? or is it used?

ed: it's something people have asked for
... for UIs zooming and panning

Rossen_f2f: I strongly suggest waiting for what Ted comes up with in CSS
... the one thing we need to figure out is what we really need from a zooming feature
... [mentions various possible zoomings]
... my hope is that once they're done defining the behaviour, the CSSOM will follow with the appropriate events for that

heycam: so given .onzoom isn't supported anywhere, let's not add it now
... and wait to see what broader zoom events come out of the CSS work we can align with

[look to see how things are done in HTML]

ed: so let's put .onbegin, .onend, .onrepeat on SVGAnimationElement

heycam: ok

RESOLUTION: We won't add an onzoom IDL attribute, but we will add onbegin, onend, onrepeat to SVGAnimationElement.

<scribe> ACTION: Erik to add onbegin, onend, onrepeat to SVGAnimationElement. [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action02]

<trackbot> Created ACTION-3562 - Add onbegin, onend, onrepeat to svganimationelement. [on Erik Dahlström - due 2014-02-06].

-- 15 minute break --

<Tav> How do I call in?

Tav, see /topic

<Tav> heycam, Thanks

<Tav> OK

deprecate/remove SVGDocument.rootElement

ChrisL: do it

heycam: I asked, should we add use counters?

ed: they've been added now, we'll have to wait a couple of weeks to get results
... I still think we should mark it as deprecated in the spec

birtles: I think we can mark it as deprecated, the results are useful for knowing when to remove it

heycam: which might be immediately?

birtles: might be!

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

RESOLUTION: We will deprecate rootElement in SVG 2.

<scribe> ACTION: Erik to mention in SVG 2 that rootElement is deprecated. [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action03]

<trackbot> Created ACTION-3563 - Mention in svg 2 that rootelement is deprecated. [on Erik Dahlström - due 2014-02-06].

MPEG colored fonts meeting report

ChrisL: there was an SVG glyphs in OpenType group that discussed how to do this
... consensus was reached finally and we came up with a proposal that said how to do this
... backed up with an impl in Firefox
... Adobe was heavily involved in this, and has been making fonts, demos and promoting it
... 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
... they put out a call for proposals
... they were aware of four things going on
... one by Apple, who decided not to submit it (or document it)
... one by Google, which is a bunch of PNGs
... (currently OpenType supports rasters but only black and white)
... the PNGs can be different sizes
... that hits the emoji case closely
... MS had a different proposal which builds on TT rasterising
... 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
... so you can do flat solid colour things
... can't do gradients, transparency, masking, filtering, etc.
... at the same time, for typographers that like things to be hinted, that seems a win
... then there's the SVG proposal, which uses secure animated mode, so there's no scripting, interaction
... but you can use any graphical support in SVG
... it doesn't use SVG Font's <glyph>
... we did some pre-harmonisation work with the MS proposal
... so we use the same palette information in the font
... that was seen as a good thing in the meeting
... typically the outcome of MPEG meetings is a competition
... and decide on a winner, then the winning company has to provide a reference impl
... each proposal was seen as having benefits/drawbacks, so the proposal is to stick them all in
... and the typographer can choose which to use
... we already have that with TT vs CFF outlines
... which also exposes a problem, because in OT2 you have to say which you're using
... if we're adding 3 more formats, that's obviously not going to work
... so they're fixing that bug
... the other thing was a call for some math tables that let you do equation typesetting
... the MS proposal, the only one, was accepted
... Vlad will incorporate the proposals and circulate a draft

shepazu: what's the IPR policy on this?

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
... so that's RF

shepazu: anyone significant hasn't?

ChrisL: Canon has not
... the policy for ISO as a whole is RAND, and all you have to do is say that you will give a license
... companies discuss about reasonable is
... not super happy about that
... but that's how it works
... at least for the SVG parts it's ok

shepazu: what about for OpenType itself?

ChrisL: there have been patents, e.g. the hinting stuff
... the other thing is that unlike most ISO groups, this one does publish the spec openly
... which is good except you still have to click through a licence
... in practice everyone refers to the MS version
... I spoke to Michelle from MS and assured me once the document was stable she'd incorporate it into the MS version
... some people were worried about the SVG one, and it transpired the reason why is that it would be an MPEG bake off
... and one would win, others would lose
... I'm doing a talk at LGM about this
... I'm starting to look at the impl landscape, most of which work on windows, some on mac, none on linux
... which let you edit various things
... there is some momentum though
... there is interest in doing it too
... 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
... another worry about SVG was that the colours were fixed, so hearing that we had this palette mechanism, they were super happy
... 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
... no need for implementations like CR
... so it would be good to have in another browser, and also authoring tools
... demos made by typographers would be good too
... inkscape has already got a way to do SVG glyphs, which are going away, and wraps them up and produces a font
... would be good to repurpose that for SVG in OpenType

Tav: I know there'll be a lot of FontForge people at LGM

ChrisL: yes, though FF is a bit funky given its interface
... plus if you're running it on a mac you need to run X
... there was an effort to split FF into two parts, a library then a UI, that has not happened
... would be good to talk to Scribus people too
... one thing you can do with this, video games use a lot of coloured signage, icons, and you can have huge assets for this
... and recolour them etc.
... having a coloured font format for slotting different palette values, is a win
... and the 3D people use fonts

<ChrisL> for amazing title sequences

shepazu: is there a possibility to co-publish this as a W3C spec?

ChrisL: the whole of OT3?
... there's a possibility, but MS does own the non-ISO version of the spec, so not sure what they would say about that

<ChrisL> https://www.microsoft.com/typography/otspec/

ChrisL: there's a bad redirect there for the licence

shepazu: I think there could be some value at republishing at W3C
... second question is, since we are killing off SVG fonts, for those browsers who decided to never do SVG fonts, that's good news
... there's a chance we'll see this new SVG glyphs in other browsers since they already do OpenType
... with the shitty internationalization of the old SVG Fonts, it was reasonable for them not to implement it
... what I hated about SVG Fonts was the inverted coordinate system
... is there any possibility for us resurrecting SVG Fonts in a way, by embedding an OpenType font in the document?

ChrisL: the XML serialization of OT, UFO, is very verbose
... the binary format is very compact, lots of tables with bytes
... by the way, WOFF is a way to wrap up any sfnt font

Tav: would it be possible to have the table information in the font, but feed in the SVG glyphs to it?

ChrisL: that would be interesting
... there is a demo of that, but it's kind of hacky
... 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

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
... I was going to intercept the layout information from Pango, and just draw the SVG glyph

ChrisL: I should say, Behdad Esfabod has been at these meetings and is aware of this
... and is interested in adding this to Harfbuzz

shepazu: maybe not right now, but this is a useful use case to pursue in the future

Tav: yeah. it's a way of getting your cake and eating it too.
... basically saying OpenType handles all the nasty i18n layout stuff, and we provide a glyph

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
... what if text has fonts on it
... do you have a glyph with the same font?
... and they've followed the CSS2 reference and thought you need to support all the old font formats
... but there is a possibility we might be asked down the line to produce a subset for SVG for this
... maybe we shouldn't prompt this, but if asked we should

shepazu: if it's well in the scope of Integration...

ChrisL: integration is already being referenced for secure mode, secure animated mode

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.html

shepazu: I had a conversation with the guys from Decotype
... they were asking about SVG fonts, told them about groovy fonts
... they're trying to do arabic

ChrisL: they also talked to me, and they're basing their stuff on altGlyph

shepazu: I told them it's going away, and they said oh that's not a problem, we can do it another way
... but their use case is, the groovy font use case
... and it ties in to wanting to have shape selection in SVG
... I'd like to talk to you guys about ramifications of that
... the idea of being able to select shapes as well as text
... I don't know the UI for that, or care
... but we should say when something is selected
... this could also play into copy and paste of graphics, and annotations
... and that would feed into groovy text as well

[doug draws groovy text on the board. again!]

ChrisL: maybe we should send a liaison statement to MPEG SC29 WG whatever

<scribe> ACTION: Chris to send Cameron an email with details on how to send a liaison statement to MPEG about SVG in OpenType [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action04]

<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].

<ChrisL> http://letterror.com/fontcatalog/ltr-federal/

<scribe> ACTION: Cameron to propose something for marking up graphics with equivalent text [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action05]

<trackbot> Created ACTION-3565 - Propose something for marking up graphics with equivalent text [on Cameron McCormack - due 2014-02-06].

ChrisL: there are different optical sizes, but they're different fonts, for the filling of the "No" glyphs
... we should support that using media queries in SVG-in-OpenType
... but it's not quite possible yet, we don't yet have an appropriate MQ to do this

heycam: this is related to the zoom MQ that Takagi-san wants
... we should work out what we need for this and give input to Ted etc. who are looking at zooming

Percentage values on objectBoundingBox for content elements

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

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

krit: I think it should be oBB relative because browsers do bounding box dimension relative to the viewport dimension multiplied by percentage of viewport
... which is very confusing
... all browsers do that, that's interoperable behaviour

Tav: Batik and Inkscape does it too

krit: the specification says something different

heycam: do you reckon anyone relies on it?

krit: Illustrator partly, some examples do rely on what the spec says [i.e. different from impls]

heycam: and what does the spec say?

krit: it should be a percentage of the viewport
... this is when you say maskContentUnits="objectBoundingBox"

Tav: it's kind of strange that the mask would move when you widen the SVG

krit: yeah

ed: how much content would break?

krit: people don't tend to use percentages here, because they don't understand the behaviour, and use 0..1 instead

Tav: Inkscape doesn't generate using % objectBoundingBox values

heycam: do we have tests in the test suite which support the current weird behaviour?

krit: don't think so

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

<cabanier_> Illustrator import would break since they resolve percentages wrt the viewport

<Tav> http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg

Tav: not sure the spec is clear whether transforms on ancestors of these resource elements should be taken into account

ChrisL: if there's specific wording in the spec you should suggest that
... we should add an example in test suite for that too to file a bug on rsvg

<scribe> ACTION: Tav to think of text to clarify whether transforms are taken into account with % objectBoundingBox values in resource elements [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action06]

<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].

-- lunch break --

<ChrisL> scribenick: chrisl

event handler attribute reflection

ed: need wording to replicate what html5 has abour reflection in IDL and on-* attributes

heycam: yes we do

ed: reference html5 directly

ChrisL: yes, unless its super specific

<scribe> ACTION: erik to add ref to html5 for attr reflection [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action07]

<trackbot> Created ACTION-3567 - Add ref to html5 for attr reflection [on Erik Dahlström - due 2014-02-06].

renaming svg resize and scroll events

ed: html5 has resize and scroll events, not exatly same as svg which is specific to a fragment

(checks)

ed: resize is targetted to rootmost svvg element

heycam: (what about namespace boundaries)

only within an svg document fragment

krit: what is it for object or embed

heycam: the same
... suprised if people are listening to svg resize on outer html

krit: relative sized inline svg, change window size

heycam: no need to worry about svg fragments in html inline. probably listening on html doc at the top or on window

shepazu: unless we find somethin unliveable users will find a way to do this
... do what hytml does. but new editor is not unfamiliar with svg and will understand the use cases
... if we need changes we should say

heycam: not aware of anything needing to change. renaming is ok
... try it and look for breakage

ed: exposed on html body and window

<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.

<ed> (from html5)

ChrisL: so change body to body or svg

heycam: they are actually listening to windopw

ChrisL: we need to say they are exposed on svg element also

ed: same for load event on window
... already have some wording for load events to make svg roots behave like body

<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.

<ed> (from svg2)

ChrisL: so same wording for the others

heycam: "a number" is vague

ed: links to html5 to list them

<ed> https://svgwg.org/svg2-draft/struct.html#SVGElementEventHandlerAttributes

ed: need to explicitly list them

resolved: remove svg prefix on svgresize and svgscroll events

action erik to remove svg prefix on svgresize and svgscroll events

<trackbot> Created ACTION-3568 - Remove svg prefix on svgresize and svgscroll events [on Erik Dahlström - due 2014-02-06].

scaling back features that suck performance

heycam: hearing about wanting to better handle conent on lower performance machines
... working out what to do. if hardware is there and the machine is slow, it works but at low fps
... several approaches to make the websites less beutiful but functional and responsive

ChrisL: do you have specific things that slow down

heycam: no its across the whole stack
... one approach is to come up with out own hueristics to scale back features, things to turn off
... eg filters, reduce rendering or switch off
... can conformance be relaxed to codify that
... do people think there are particular features to scale back

ChrisL: worried about relaxed conf criteria being also taken as the typical rendering

<ChrisL> heycam: hearing about wanting to better handle conent on lower performance machines

<ChrisL> ... working out what to do. if hardware is there and the machine is slow, it works but at low fps

<ChrisL> ... several approaches to make the websites less beutiful but functional and responsive

<ChrisL> ChrisL: do you have specific things that slow down

<ChrisL> heycam: no its across the whole stack

<ChrisL> heycam: one approach is to come up with out own hueristics to scale back features, things to turn off

<ChrisL> heycam: eg filters, reduce rendering or switch off

<ChrisL> heycam: can conformance be relaxed to codify that

<ChrisL> ... do people think there are particular features to scale back

<ChrisL> ChrisL: worried about relaxed conf criteria being also taken as the typical rendering

* Disconnected (No such device or address)

ChrisL: in games is miostly user selected

Rossen_f2f: if this is done by the user agent, afraid there will be fast disparity between implementations depending on internal efficiency
... so you get great disparity on the same device
... if they are automatic
... if the policy is across all devices they can be automatic (low medium high) as long as they are defined exactly what happens
... and user must have right to override that

shepazu: could be user agent dependent

heycam: to decide what to scale back, 2 approaches: spec what it means, or author indicates disposable features and priority

ChrisL: authors will do what works on their UA, not test on otyhers

Rossen_f2f_: ask performance wg about this

krit: uas cvary so affect uas differently. does not necessarily help

heycam: uas will auto adjust based on actual performance

krit: not opposed to performance profiles

Rossen_f2f_: same her, as long as testable and results will not vary by user agent at the same level on the same device
... figure out if it makes sense to sacrifice filters in medium or not (varies by UA)
... it will be sacrifice for sure

birtles: if i have something with gpu optimisation, want to use that

heycam: would not want to force user intervention
... bad to cripple the better implementation

krit: use media queries for this
... author can decide what is important for high quality

birtles: cant be entirely author device because many authors do not test widely

heycam: bad to reduce functionality on a device that can do it

ChrisL: have low medium high auto where auto scales by fps

shepazu: engage with Khronos (webgl guys) about performance levels
... perfomance based characteristics. also did openvg
... willing to work with us. identified as a liaison item

Rossen_f2f_: can argue both sides
... on mobile, browser defines the experience. need to get best experience possible on that device
... also depends on the competition

heycam: now they can get different performance experience

Rossen_f2f_: will also give behaviour changes

shepazu: can we have best and worst levels for each feature
... say 2 uas on same hardware, one has hw accell on one thing is worse on something else
... so it would be predictsable what level it goes to
... level of service knocked out is independent

Rossen_f2f_: so a minimum bar not an absolute bar

shepazu: yes, and per feature
... so it is predictable

heycam: that specificity would be good
... so there is a combinatorial explosion of profiles

shepazu: maximises experience for user and author, also allows ua to compete on performance while still being predictable at a given level

heycam: even if it is continuous, can reduce filer resolution for example, or should it be discrete

shepazu: three levels

Rossen_f2f_: low medium high

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

shepazu: best is "do this or better"

heycam: is that performance or rendering behaviour?

shepazu: we set a minimum bar

Rossen_f2f_: some impls could not make that

Smailus: what defines what is in the profile, it changes over time

Rossen_f2f_: if we have them, how does it benefit the content author to develop over device evolutions
... ua gets a better impl on the same device
... how would the content start to take advantage of that

heycam: was thinking author would get perf benefir of scaling back features by defining how operations are done, including ignoring features
... not @media low-perf
... so when the usa meets te bar it uses high perf mode

krit: these were requested four years ago already
... sometimes a drop shadow is purely decoration and you drop it

Rossen_f2f_: media queries f=to get the current perf level

krit: what if you still are too low perf. can you drop features

heycam: what if you are medium level then set properties that use higher perf features
... worry about author access to perf tweaks because they age badly

Rossen_f2f_: hard to define the matrix of allowed capabilities

heycam: dont want to do that per device
... want it done automatically

Rossen_f2f_: some devices will be "always high"

heycam: dont want to test on lots of devices to get the perf. want guidelines on how to tel lif perf is inadequate

ChrisL: is perf mai=nly in terms of fps

heycam: yes
... can always have ginormous files, stil lwant to auto scale back for that

shepazu: suggest we say its interesting buf not define today

krit: not going anywhere concrete

shepazu: open to proposals

a hazelnut in every bite

it goes to eleven

krit's keywords

krit: (daws pretty pictures which we neglect to capture)

bounding box of a stroke where there is dashing, taking into account miter limit, where the dashing does not cover the corner

three options 1) actual painted area 2) geometric 3) maximal with miter limit and stroke geometry

Rossen_f2f_: makes sense when ther is fill, not without

krit: depends on miter limit

birtles: and line cap

(we don't want bounding box to oscillate if a dashed stroke animates start position)

heycam: for beziers the exact tightest bound is expensive and not worth it eg for a repaint region

cabanier_: mostly you want loose bounds
... make it as fast and loose as possible

(discussion on getting data back from gpu)

(which is hard and slow, by the way, and endlessly fascinating as a conversational topic)

cabanier_: you get the box you need stroking

heycam: can stroke with transparent paint, or compute in offscreen buffer

shepazu: does anyone disagree with 3

cabanier_: option 4 is convex hull of control points

heycam: really want to avoid the marching ants problem

birtles: if someone animates miter limit

(no one really does)

shepazu: asks about vector effects

ChrisL: no implementor interest unfortunately

cabanier_: should be a more precise version too

shepazu: add several ones

Rossen_f2f_: over engineering

heycam: we should be doing that (markers, stroke, etc etc)

krit: css gradients on object bounding box. only covers half the stroke!
... so we need something better
... choose stroke outline instead, for a decorated bbox

Rossen_f2f_: exactly like semi transparent dashed borders over background

heycam: bbox of control points, can we do same for stroke and say ignore dashing

krit: backend engine needs to do it twice, once without dashing
... better to just look at points without rendering

cabanier_: only fails with stupid miter limits

krit: can happen

heycam: polygon with exact points, stroke width 10px, what do you do

krit: miter limit on slallest angle, add miter limit ...

heycam: ignore ML. calc disatnace from lime by stroke width
... same as doing stroke path operation, same maths

krit: so we need to do it twice

heycam: fudge factor to pad convex hull bbox, proportional to stroke width

ChrisL: added onto the four sides of the chull bbox

<nikos> oops

shepazu: people would find it counter intuitive

krit: yes, now i am convinced on 3

3 3 3 3 3 4 2 4 4

cabanier_: perf will be really slow

Rossen_f2f_: 3 on high, 4 on low ...

shepazu: want to see some perf metrics and see how inaccurate 4 is

cabanier_: illustrator uses 4 for selection hilight

heycam: add an issue in the spec

shepazu: they will do the easiest one

Rossen_f2f_: the most performance one

shepazu: how often is bbox called

heycam: for this new one, not at all :)

krit: stroke bbox is in blink, not activated, gets used a lot

birtles: in future decorated bbox will be called a lot

krit: problem if filling with image, missing some pixels due to inaccuracy

ChrisL: image size for the fill should not be affected by the exact position dashes fall

<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

heycam: our calc for repaint region ignores miter limit, just stroke width
... so pad bbox by half stroke width

<heycam> the input to that function is the bbox of the geometry that has already taken miter limit into account

<heycam> or miters into account

zakim?

nikos, call into zakim plz

krit: one dash on an ellipse ....

<heycam> http://lists.w3.org/Archives/Public/www-archive/2014Jan/0014.html

<heycam> ^ picture

krit: want to add both methods to the spec and add an issue

shepazu: representing authors and users. informed decision needs data

birtles: best to gather data as we implement

shepazu: ask the community, give the tradeoffs perf and precision

krit: not happy, does not help until they implement so defers

shepazu: option3 won the vote
... put issue saying maybe 4
... spec can be referenced at any level as long as the portion is stable

(process explanations of stability criteria)

action krit to add decorated bbox option 3 to svg2 with issue explaining option 4

<trackbot> Created ACTION-3569 - Add decorated bbox option 3 to svg2 with issue explaining option 4 [on Dirk Schulze - due 2014-02-06].

break

<heycam> -- 15 minute break --

<birtles> Scribenick: birtles

<scribe> Scribe: Brian

SVG2 status

heycam: one concrete thing I'd like to discuss is out new cut-off date
... at TPAC we thought we needed more time
... so we extended it from the end of last year
... so we need a replacement date

birtles: what is left?

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

heycam: let's see what's left per-person

<heycam> trackbot: close action-3271

<trackbot> Closed action-3271.

heycam: starting with Doug
... 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
... Cameron will mark this one yellow
... 20 - InkML trace groups -- covered by variable-width stroke
... 40 - Catmull-Rom curves - keep it
... 41 - Regular polygons and stars - keep it, work with Tav

Doug: 47 - flip-invariant text - keep it, need to talk to others
... 52 - Tooltip - keep it, Dirk interested
... 91 - Bounding box text, Dirk to take
... 93 - content editable - Doug will look at another way of looking at editing markup but possibly not part of SVG2, remove

heycam: unless you want to define how it should work if you have contentEditable on an ancestor HTML element

shepazu: you should be able to edit the text

heycam: we need to define that

Doug: 100 - Support for key events from DOM level 3 events

krit: didn't Rich ask about referencing DOM4?

heycam: yes, I think he referenced DOM3 in the end

Doug: close this issue, stuff has already happened in the spec
... 128 - define how border and background apply to SVG, keep it
... 129 - outline property, keep it
... 130 - clarify how pointer-events can hit the root SVG or not, Erik to take

Chris: 28 - color management, closed
... 30 - non-scaling features (e.g. rectangle corners)

krit: we don't want to extend that, we found too many issues with this
... defer it

ChrisL: 48 - deprecate xml:space and use CSS white-space

heycam: give the CSS part to Tav who is rewriting the text part

ChrisL: 62 - linear interpolation for some properties which are currently discrete only -> pass to Brian
... 66 - remove requirement for width/height from foreignObject

(discussion about whether this is possible and if we should do it for foreignObject only)

ChrisL: it's a fairly simple fix for this case, I think

krit: I don't know that it is

heycam: if there's HTML content inside use the shrink-wrapping algorithm to work out the size
... it's like the minimum width that doesn't break a line, or something like that
... it's what you use with absolute positioning

ChrisL: I'll do it
... 70 - CSS3 Color syntax - done
... 73 - Align CSS Value and Units

heycam: I think I aligned some things but I haven't added new units etc.
... I'm happy to take it

ChrisL: it's yours
... 76 - allow clip to reference any element

krit: clip property is now deprecated

<ed> http://www.w3.org/Graphics/SVG/WG/track/issues/2355

heycam: that should actually be clip-path

krit: this is actually now part of CSS masking
... but it won't be in the first level
... give the action to me

(make it yellow)

(means "handled in another spec")

ChrisL: 82 - WOFF support - done
... 89 - viewport-fill(-opacity) / background-color

(discussion about whether viewport units can be used to cover the use cases for this feature)

scribe: keep it
... 92 - improved text re: characters/glyphs/selection etc.

heycam: Tav is reworking a lot of text stuff now so it might be worth waiting to see what he's done

ChrisL: I'll do it if he hasn't

krit: add Tav's name to 92

ChrisL: 115 - currentFillPaint, currentStrokePaint - done by heycam
... 119 - Use updated CSS3 specs - heycam to do
... 126 - Require SVG Tiny fonts - no, close with no action
... 127 - Make CSS mandatory - keep
... 131 - xlink prefix for href

krit: I already defined this in CSS Masking

ChrisL: I'll copy it from there

krit: either there or filters

ChrisL: 138 - allow masks to use alpha/luminance both - covered by CSS Masking
... 140 - masks pointing to mask elements only - covered CSS Masking + element()

heycam: 1 - Backwards compat note - skip it
... 9 - markers done
... 10 - fix DOM, ongoing
... (lots of items done, good work Cameron!)
... 25 - data-* attributes, keep
... 26 - HTML5 global semantic attributes - keep it, need to check what is in HTML
... 27 - make property values case insensitive - I might have done it, need to check
... 33 - stroke dash adjustment - keep it, I'll see what I can do
... 36 - align the style element with the HTML5 style element, keep it
... 45 - glyph baselines
... the text chapter will reference CSS text for this
... keep it
... 49 - transforms on tspans - keep it

<scribe> ACTION: Cameron to write spec text on transforming tspans [recorded in http://www.w3.org/2014/01/30-svg-minutes.html#action08]

<trackbot> Created ACTION-3570 - Write spec text on transforming tspans [on Cameron McCormack - due 2014-02-07].

krit: does this belong in CSS transforms?
... if so please notify www-style

heycam: do you list applicable elements in CSS Transforms?

krit: yes

heycam: ok, I'll do that then
... 54 - Support HTML document-wide events and make sure they apply to SVG document, keep it
... 57 - async and defer on script elements
... 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
... keep it, possible drop it
... 69 - positioning information in MouseEvents, keep it
... 74 - deprecate baseline-shift, vertical align, keep it
... 80 - DOM method to convert <text> to outline path data

cabanier_: that's part of the Canvas path API which is separate to Canvas

heycam: but the requirement is to get actual path data
... so I can actually manipulate the path segments

cabanier_: that might not be available then
... it might be possible
... it lets you get an opaque pointer to the outlines that you can do operations on it but not individual segments
... keep it
... 108 - inline scriptable content, keep it
... 109, 110 - more script stuff, keep it
... 118 - CSS3 definitions for text, keep it
... 121 - Move events to Element
... nothing to do (Hixie says no)
... 122 - Path rotation command - done
... 123 - Introduce evt as alias to event, give it to Erik
... 124 - object-fit, object-position, keep it
... 132 - remove restriction on tref, done

krit: does tref still exist?

heycam: in any case, it's already done

<ed> https://svgwg.org/svg2-draft/text.html#TRefElement

birtles: 14 - fix path APIs, keep it, might still be needed depending on how DOM improvements go
... 96 - synchronization, make yellow (Web Animations)
... 111 - Changes to animation, move to Animation Elements spec (yellow)

krit: 51 - video in SVG, Takagi-san did this already
... 75 - captions for video, Takagi-san did this too
... 139 - canvas in SVG2, Takagi-san did this too!
... 21 - transform on the <svg> element, keep this

ed: 29 - non-scaling stroke, done
... 55 - drag&drop, we have the global event handlers

heycam: we need to add a sentence to say this works in SVG

ed: will do
... 71 - image-fit, this is now object-fit which Cameron will do
... 87 - buffered-rendering, done?

heycam: now that we have will-change do we need it?

ed: we could reconsider it?
... it's not the exact-same thing

heycam: let's discuss this in a telcon later
... 88 - vector-effect, this is non-scaling stroke, done

<heycam> ISSUE: should we have both buffered-rendering and will-change?

<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>.

heycam: 116 - focal point for radial gradients, done by Dirk
... 117 - fr attribute for radialGradient, done by Dirk/Tav
... 125 - text-overflow, done
... 126 - SVG Tiny fonts, no longer needed

cabanier_: 20 - variable-width stroke - will discuss tomorrow

heycam: only others are Tab, Tav and Cyril
... for Tab, z-index

(discussion about whether to keep it or not)

scribe: keep it for now
... Cameron to look into it

42 - arc in paths in easier

heycam: I partly addressed this with the bearing commands
... we discussed adding all the canvas arc commands to SVG but I'm not sure
... assign it to Rik

89 - This is just Chris now

6 - namespace requirements, add Dirk

8 - shadow tree, add Dirk

39 - shared path segments, leave it with Cyril

95 - animation element, covered by iframe work done by Takagi-san

135, 136 - done in SVG2, Brian to remove from here and add to Animation Elements

137 - playbackOrder - Brian to remove from SVG2 and maybe add to Animation Elements

We'll cover Tav's items tomorrow

heycam: those items without names associated we will not do since no one is interested

birtles: so can we now estimate our next deadline?

heycam: we should have a cut-off date for new features and then allow a few months for getting to LC
... and I think that cut-off date should be June 30

- DRAFT -

SVG F2F Seattle 2014 Day 1

30 Jan 2014

Attendees

Contents