London 2014 SVG WG F2F Day 3

25 Aug 2014


See also: IRC log


Cameron, Brian, Cyril, Konno, Rossen, Rik, Dirk, Jonathan, Nikos, Doug, Chris, Tav, Jun, Jet, Erik


<ed> scribeNick: ed

Performance of transformation in panning & zooming ("transforms", "will-change")


konno: zooming and panning is for general webpages rather than mapping
... it's an important feature
... we have three requirements
... 1) smooth start
... 2) smooth transition during panning and zooming
... 3) crisp view after panning/zooming is finished
... there are some issues re the performance of zooming & panning
... see table in the above wikipage

krit: is this scripted or native implementation?

brian: it's scripted, it's not the whole page
... with scale3d

rossen: so how are you doing this exactly?

brian: by chaning the transform, so doesn't affect the whole page

konno: [presents the table https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Facts]
... [demos the first example running in firefox]
... shows the last example in chrome, where chrome doesn't render the view crisply after finishing the zooming

(this is chrome version 36)

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Facts

heycam: maybe 2d scale transform might work better, does it have the same behaviour then?

konno: possible solutions, specifying css transform more closely


scribe: it might also be included in the will-change spec
... third way is using another way for zoming and panning, maybe using compositor thread
... it's a little bit difficult currently
... but this is an implementation issue, not a spec issue
... should this be a spec issue or a implementation issue?

krit: that everything is pixelated is an implementation issue

heycam: css transform prob doesn't say anything about crisp rendering

Rossen_: you're talking about zooming and panning, but are using transforms
... these are different things
... they can do similar things, but you can do different optimizations for the zooming and panning than for transforms
... depending on the current environment it will cause degenerate cases
... causing other elements to be rendered as well
... in the context of p&z, the two are completely different
... so, are you talking about p&z or about transforms?

heycam: it's implemented using transforms
... because that's what you have to do currently

Rossen_: in trident we have optimized p&z

krit: you don't mean svg panning and zooming, right?

Rossen_: right, not specifically svg panning and zooming

brian: it's for an element, not for the whole page
... the question about spec vs impl
... the gecko behavior should be fixed in impl
... when we scale using css animation, we don't resample during animation, so that it's smooth
... we could adjust heuristics
... don't think we need to spec anything for that

heycam: i think I agree

tav: are tehre cases where you'd want a different behaviour?

heycam: jerky zooming?

Rossen_: in host zooming, we don't resample until you reach a stable state

brian: we had some heuristics for layers and animation

Rossen_: it's certainly an implementation issue

konno: if it's an impl issue, we should create a testsuite for this

brian: sure, but it shouldn't be a conformance testsuite
... just something to link to from the bugs filed

Rossen_: or submit the tests to the performance WG

heycam: for like rendering perf?

Rossen_: yes, I think it'd be good to ping them to see if they have any ideas on this

heycam: for the second issue, about chrome and not rendering crisply, if you use 2d scale instead

krit: for some reason it looked the same (in webkit)
... the start and end should always look crisp

heycam: so you think it's a bug?

krit: it's using scale3d as the last argument, which shouldn't be hw acc

Rossen_: have you tried this with text instead?
... so without svg, just regular html

konno: only with svg

krit: it's using an object tag

ed: would be interesting to see if it's the same when using <img>, <iframe> or otherwise

heycam: do you agree that it's an impl issue as well?

krit/ed: yeah

heycam: it would be intersting to think about the R3 at some point
... so that you don't have to use css animations
... like using gestures directly

krit: link it to scrolling?

heycam: haven't thought about it much yet
... you can define it in terms of css boxes, scale ...

brian: we want to take web animations off thread
... and gestures

krit: blink said that scrolling should be done with javascript, or polyfills
... they might change their minds later

Rossen_: were you at the input f2f?

krit: no, this was mailing list
... if you do everything in js everything will be 60fps

brian: they set out current time based on scroll position

krit: might be an organizational issue

brian: they said we wish you had the web animations api

krit: so we agree no spec changes are required?

all: yes

HTML integration (aka iframe spec issues)

<birtles> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration

brian: this is something konnosan and I have discussed
... will go through the wikipage
... img is non-interactive, and fairly limited
... we want something like iframe

krit: who are we?

brian: the people wanting to address mapping use-cases
... some ppl said they wanted canvas in svg
... you can with foreignObject, but it's cumbersome
... at the same time ppl want to be able to put div directly into the svg
... this is the background
... in order to address this, we've added the embedded content chapter to the svg2 spec
... it hasn't had much review yet


scribe: it combines some exisitng elements like foreignObject and image, so mostly the chapter is new, but there's some old content too
... some work commissioned by KDDI, got delayed due to multiple inheritance...
... inheritng from both SVGELement and HTMLElement wasn't a good approach
... from the mozilla viewpoint, and even from a spec POV
... should we really have an svg iframe element to begin with?
... led to discussion on svg and whatwg list
... we should instead allow html elements without having foreignObject
... that was the discussion there led to
... treat such elements as relative positioned
... layout is the second issue, one is parsing one is layout
... there's an outline of how it might work
... the proposal had x and y attributes
... we already decided to have x and y properties
... svg iframe had x, y and transform attributes
... if we want to allow that under this new proposal we'd need to add x,y and transform to HTMLElement
... there are two big issues, first is how to support parsing
... I put a fragment in the wikipage

<!doctype html>


<span id="s"></span>

<div id="i"></div>

scribe: what happens is whenever it sees the html elemnents it breaks out of the svg parsing mode
... because some pages on the web had content like this, which would otherwise break
... if we want to allow these elements to be descendents of the svg, we'd need to not break of svg mode
... so we'd need to change the html5 parser
... question is, is this something we can do?
... if we do, then pages that have no closing svg element would stop rendering again

rik: well, they'd render differently

brian: except if we make these elements render as children of the svg, then perhaps they woukld start rending
... however, the defaiult rendering for <svg> is overflow:hidden, so they might not render after all

ed: right, but we decided to make overflow:visible for this case at this F2F

heycam: the scorlling behavior might become wonky

krit: if we do render, everything will be positiioned relative to the top left of the svg root

heycam: the block will still be 300px, even if we have overflow visible

brian: why don't we just break these pages?

krit: I'd expect that codepens would break alot

heycam: like examples ppl have coded up?

doug: why don't we have an <html> element inside the svg?

brian: the other suggestion from anne, if we embed html elements in svg, you need to opt-in
... so that you can choose

heycam: it would be strange for the presence of an attribute to change the parser behavior

brian: anne said the same thing, he doesn't like it, but it's possible

doug: is there some reason why we don't want to put the elements inside an <html> content (instead of foreignObject)
... what's the goal?
... if we get wrapping text, what's the reason we want this?

brian: it's iframe, canvas etc

<tkonno> (FYI) http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Iframe_spec_issue_through_the_development

doug: if I wrote a document, like a barchart, and I wanted some text assoc with it, i'd prob want to put the text into the same structure, so having html root there would be kind of a pain
... but for standalone video, canvas I don't think it's so much of a pain
... we could advance from this at a later stage

brian: how is this different compared to foreignObject?

doug: it's not, jsut easier to type

brian: if you want to nest and svg in another svg, using iframe

doug: couldn't you use a <use> element?

brian: no, want interaction and separate document
... the reason <image> isn't good is because it isn't interactive

doug: what would the perf characteristics be like?
... I'd rather have a custom element thgat behaves like iframe, so taht we could optimize it for this use-case

brian: the feedback was that we don't want that

doug: html already have four different iframes, don't see why we couldn't have one
... you'd be establishing a viewport inside the svg for the html

heycam: I think what ppl are saying is they don't want the duplication

jwatt: can't we sidestep the issue
... by using a UA stylesheet

<heycam> <box><div>...</div></box> | box > * { position: absolute; top: 0; left; 0; width: 100%: height: 100%; }

<heycam> where that rule goes in the UA style sheet

<heycam> avoids having to write <div style="position: absolute; ...">

jwatt: one problem i'm trying to fit the content inside the foreigobject to a specific area

heycam: what if you stick an animate tag inside a foreignobject

Rossen_: not sure foreignobject content has to be html content
... could be anything else, VRML or whatever

jwatt: we don't want to have to use namespaces
... maybe we could come up witha tag like iframe with the expansion
... with some attribute that knocks it into a special mode for the parsing

krit: i'm worried about breaking content
... we should think about the layout as well
... ppl want to put a rect aligned to some text, in terms of html we should think about how that might work
... something like VML did in the past

jwatt: not sure it's related

heycam: so brian, what's the specific list of issues with foreignobject that we could solve with the proposals?

brian: authoring, it's a long hard name, that you have to wrap things in
... when you hae something like map, with hundreds of tiles, the overhead of haivng to wrap in FO is high
... the dimensions of the FO and having to set the same on the canvas / video etc is cumbersome

jet: is it typically hand-written svgs?

brian: maybe it's mostly the filesize issue
... for handwritten stuff it's mostly the thing with the sizing

heycam: if we had had audio, video, canvas from the start we'd have had them directly without the wrapper
... we could perhaps treat replaced elements different to the others
... so video different to div e.g

brian: for <template>s you have to wrap things in FO, which is a pain
... the use.cases for this will grow, and the overhead of having to wrap elements is unfortunate

Rossen_: it's pretty natural to want non-wrapped elements, like <button> for native UI

heycam: i'm optimistic about trying to go ahead to allow arbitrary html elements inside svg content
... what are the downsides of doing this besides breaking content?

brian: how to define the layout
... needs to be worked out

tav: suddenly you will have lots of "junk" in the svg (html elements), which editing tools will have to support

heycam: do editing tools support foreignobject atm?

tav: it'll be a black box, nothign inside the FO is supported
... if I had an svg I'd expect to be able to see it and be able to edit it in the editor

heycam: do you see that as a bad thing?

tav: if tehre are svg native alternatives maybe
... I don't know

brian: a similar thing, svg in opentype
... what does it say about FO?

heycam: it's disabled

brian: we might do the same

tav: i like the idea of the html tag

brian: for things like <template> that is really unnatural
... why would you have to wrap it in <html>?

doug: how many features do you think we want in svg?

cyril: the integration so far in svg2 is very unintutive and strange
... either you go with raplacing FO with <html>, or we need to document better

brian: why are they confused?
... if you had a <form> inside a <g> for example

cyril: as long as the layout is defined it'd be fine

tav: how would this work with xml parsing?

cyril: this is also an issue for video elements, do you have to close tags, and controls attributes

heycam: whatever xhtml requires would apply here

tav: right now if put <html> directly in svg, it'll parse but won't know what else to do with it

heycam: with xml you can construct arbitrary DOMs

brian: hearing some opposition to allwoing html elements to be used bare within svg
... not sure exactly why
... tab atkins, roc and so on
... don't have a sense of whether this is doable
... not a fan of redefining the elemnets in terms of svg
... a compromise of having a box of html element might work

heycam: we resolved to try and move things to the same namepsace
... so you'd have the iframe element in the same namespace
... so there's not really going to be svg and html versions of the same element, they'll actually be the same
... it's consistent with that

ed: I think it would be really nice to not have to wrap things in <html> or FO

krit: this would require parser changes

heycam: yes, all of the proposals would
... would it help to sort out the issues, and get a more concrete proposal

brian: yes, and try to get more feedback from the html people

heycam: it would be good to inform them of the different ways to handle things

brian: sounds good

jet: selling the change to the html5 parser will be hard I think

Rossen_: it does also bring the issues with authoring tools

jet: also sandboxing and security, the cost is high of removing FO

brian: long term I think we'd want to get rid of FO

cyril: but why? it can be used for PDF and lots of different things, it's the extensibility point

brian: this would be replacing this with something people would find easier to use

cyril: FO doesn't add its content to the DOM, right?

jwatt: if it's inline markup then that will get included in the DOM

cyril: we can put VRML in FO in our player
... or any other format that's supported, just by looking at the mimetype

heycam: don't think there's a mimetype attribute on FO
... so an action to make things more concrete?

<scribe> ACTION: brian to write up a more concrete proposal for allowing html elements directly in svg (related to https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration) [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action01]

<trackbot> Created ACTION-3648 - Write up a more concrete proposal for allowing html elements directly in svg (related to https://www.w3.org/graphics/svg/wg/wiki/f2f/london_2014/agenda/html_integration) [on Brian Birtles - due 2014-09-01].

-- 15 min break --

<stakagi> Thanks!

<cyril_> scribe: cyril

<cyril_> scribeNick: Cyril

HTML Integration (issue 2)

<cyril_> scribeNick: cyril_

brian: defining layout

<scribe> scribeNick: cyril_

UNKNOWN_SPEAKER: I'm trying to represent the proposal, initial from RoC
... original proposal was that html children of SVG element are treated as position relative
... so that you have x/y properties position things as you expect

so that <iframe width=.. height ...> would wokr

Rossen: what about position: fixed (or page)

brian: the question was raised about other position values

rossen: the problem I have is that display: inside on your SVG element hosting HTML
... display-inside should be grid
... I should be able to use grid positioning
... this is just one example: multi-column ...
... I would expect to work on foreignObject
... blink currently supports multicolumn on foreignObject

as a general behavior of the fO, or the new HTML integration, I'd expect allowing display-inside to anyhting other that svg

scribe: we should just define the containing block
... overall I don't think we have too much of a problem
... we should say that fO defines the initial containing bloc
... and display types is a different discussion

<ed> https://svgwg.org/specs/integration/#foreign-content

heycam: I thought we talked about positioning HTML elements outside of fO

Rossen: on the contrary, if I have a rectangle, and HTML inside, what would happen

birtles: the proposal is not to use rectangles, just the nearest svg viewport

ed: the svg integration spec has some text regarding fO and initial containing block but the SVG 2 spec does not talk about it

heycam: is the desire to have display inside SVG so that the whole tree can use CSS layout to define where everything goes
... SVG is like a replaced-elements, CSS stops, and SVG handles it
... the desire is to have CSS control the whole thing
... is that the purpose ?

birtles: I don't know
... It was the result of a discussion between RoC and Tab

heycam: I'm not sure it's a useful thing

krit: the idea is that later SVG can adopt other CSS layouts

birtles: Anne was also in favor of that

krit: the idea is to be able to use SVG/HTML seamlessly

heycam: long term I wanted to do layout in SVG
... allowing display and position to opt-in to CSS positioning
... I don't know if on the root element it's the right or wrong thing without going all the way

krit: maybe at some points we want to have SVG specific layout

Rossen: having the new svg display type saying that the only layout I can do in SVG is svg, it's fine
... but I would expect being able to change it, and if changing it does not work, would seem strange

heycam: we need to go one step ahead at least

krit: I don't we will be ever able to use all CSS layout in SVG

heycam: what's the reason for having display-inside: svg ?

<birtles> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0144.html

heycam: Tab is suggesting that once we have the SVG layout model, then x/y can be used as is
... I'd like to check other layout before locking that in

Rossen: the implications of display is that you are defining what x/y means inside that layout type
... if we are tying that display-inside to an element type, we are preventing the use of other layout types when the content inside is anything else than svg

krit: it's hard to discuss it without the proponents

Rossen: we can discuss that in some weeks
... we are going to discuss that in CSS WG F2F in 2 weeks

Rossen to discuss svg layout using CSS during the coming CSS F2F meeting

<scribe> ACTION: Rossen to discuss svg layout using CSS during the coming CSS F2F meeting [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action02]

<trackbot> Created ACTION-3649 - Discuss svg layout using css during the coming css f2f meeting [on Rossen Atanassov - due 2014-09-01].

heycam: if this proposal was to help for raw iframe in SVG, I don't thnk that the smallest way to make it work
... we could just say that iframes are positioned with x/y
... and we could then think more deeply on the layout question

Rossen: would you expect CSS display on svg element to affect the iframe

heycam: like <g display=flex>
... maybe but there are lots of details to be worked out

Rossen: also inheritance

heycam: I would say yes because that's normal inheritance

Rossen: I played with fO in different implementations and had issues

Decision on tref

<Tav> http://tavmjong.free.fr/SVG/TREF/tref.html

Tav: a past decision left me thinking
... before the previous meeting I had looked at the discussion on tref
... someone proposed to deprecate tref
... someone else says tref is useful for shadowing text and has been using it
... I agree this is not the best way of using it, but he's got a hundred of installations using it

doug: standalone svg installations ?

Tav: it's mixed

shepazu: they still could be conformant 1.0 and 1.1 viewers

Tav: but there are other viewers browsers, using the same content

shepazu: Doug argued against deprecating

Tav: there was an issue with the security model of tref, but the same model as use could be used
... some other people came in, saying it was useful and waiting for FF to implement
... so just from reading the email, I don't see any reason for deprecating it

shepazu: there is more information, another thread of conversation
... on one of the chrome-dev channel
... and everebody agreed there (including Alex Russell)
... Chrome is removing it, FF is not implementing it
... if we want interoperability, that's going to be hard

Tav: from an external viewpoint, on the list, it looks like we are ignoring feedback
... I got a sense from external people that their input is not important
... the other problem is that it was removed, not deprecated

ed: there are very few things that you can do with tref that you can't with use

Tav: the basic thing is that we are breaking things that exist without much warnign, and I feel bad the way it's being done

shepazu: we can't force Chrome to support tref, or FF or IE

cyril_: we can at least say how to solve the same use cases differentlu

shepazu: yes, we should make some wiki page
... there is a general practice that we deprecate in one version and remove in the next

Tav: we'd have much less problem with that

shepazu: I don't know about the requirements for deprecated features

ed: long time ago, I wrote up a polyfill for tref

nikos: the deprecation won't reinstate it in blink

krit: it's there in webkit

<krit> still

heycam: it's been removed from the spec

shepazu: we could have a section at the end of the spec about removed/deprecated things

heycam: probably it's mentionned in the change list

cyril: how would you solve a localization use case without tref ? with use ?

ed: tref can be used inside a text element, but use cannot

heycam: CSS text layout would be more difficult
... I think it's not implemented in FF because it's a weird feature

<scribe> ACTION: Doug to inform the community why we removed tref and how to solve the use cases [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action03]

<trackbot> Created ACTION-3650 - Inform the community why we removed tref and how to solve the use cases [on Doug Schepers - due 2014-09-01].

<ed> there's a sort of polyfill for tref in http://svg-wow.org/buffered-rendering/bokeh.html

fill and stroke improvements

krit: we already resolved that we want to have multiple layers for fill and stroke
... the syntax is the same as the background property
... so I would suggest that we add blend modes in fill and stroke

Tav: so for the problem of text visibility, we could use "difference"
... you want the text to stick out from the background
... one solution is to use a stroke of a different color behind the fill

krit: I want to blend just with the different layers within the fill
... the fill is isolated as a group, and the stroke too

cabanier: so they would knock out each other

krit: people would like to use the same pattern in background and fill and stroke, we just miss blending
... you can already blend within the pattern
... but people want to copy/paste what they have in background for the fill

heycam: about from background-attachment, is background-blend-mode the only background property that fill and stroke don't support

krit: yes
... it's just an alignment with CSS in terms of syntax

heycam: if we explicitely use the same model, we should go for it

Tav: I want to think about it a bit more, but I think I agree with it

nikos: yes, makes sense

<scribe> ACTION: Tav to investigate blending for fill and stroke [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action04]

<trackbot> Created ACTION-3651 - Investigate blending for fill and stroke [on Tavmjong Bah - due 2014-09-01].

Tav: are you implementing it?

krit: yes and no

Tav: I would think it'd be pretty easy in Inkscape
... it can be useful for cross-hatching

CSS layout properties

<krit> https://svgwg.org/svg2-draft/layout.html

<cyril> scribeNick: cyril

krit: I added some properties in the above link
... cx, cy, r, rx, ry
... we also have width and height but they are already in CSS

but we should clarify that they are CSS ropperties now

we already have an experimental implementations in webkit (nightly)

scribe: it supports viewport units, calc, css animations and transitions
... and the relevant attributes turn to presentation attributes

cyril: so there would be a difference for type=XML and type=CSS in animations

krit: yes the same difference as for other properties

heycam: if you use vw and vh in a standalone document, what would you use ?

krit: the window

Rossen_: in CSS it's always the physical viewport
... the adoption of vh and vw is good in CSS, so people should not expect a different behavior

heycam: it's just unfornate to have the same word "viewport"

cyril: it's worth a note in the spec

heycam: yes

<Rossen_> s/physical vieport/nearest viewport/

<scribe> ACTION: Dirk to add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action05]

<trackbot> Created ACTION-3652 - Add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport [on Dirk Schulze - due 2014-09-01].

cyril: note, the title of the page should be fixed, it says "Filter Effects"

<ed> ACTION: dirk to make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?) [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action06]

<trackbot> Created ACTION-3653 - Make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?) [on Dirk Schulze - due 2014-09-01].

heycam: we should replace the grey line for presentation attributes to a link to that

cyril: there should be a note explaining the consequences of these attributes becoming properties

<ed> nit: the heading links at the top of the chapter don't work

-----lunch break ----

<commit> [13test] 15heycam pushed 3 new commits to 06master: 02http://git.io/yfWm8Q

<commit> 13test/06master 14fed0628 15Cameron McCormack: Rename svg2-tools/ to tools/.

<commit> 13test/06master 148fb423f 15Cameron McCormack: Update Makefile to point to new tools location.

<commit> 13test/06master 1401e963b 15Cameron McCormack: Ignore build directories.

<commit> [13test] 15heycam pushed 1 new commit to 06master: 02http://git.io/CB5w2w

<commit> 13test/06master 14a882407 15Cameron McCormack: test change

<commit> [13test] 15heycam pushed 1 new commit to 06master: 02http://git.io/_-2DbA

<commit> 13test/06master 148608157 15Cameron McCormack: Another test change.

<commit> [13test] 15heycam pushed 2 new commits to 06master: 02http://git.io/nycJ3w

<commit> 13test/06master 1472b873d 15Cameron McCormack: Another test change.

<commit> 13test/06master 14bd21f5e 15Cameron McCormack: And one more.

<commit> [13test] 15heycam pushed 2 new commits to 06master: 02http://git.io/WRVt0Q

<commit> 13test/06master 1418185ff 15Cameron McCormack: one change

<commit> 13test/06master 140e1f0f7 15Cameron McCormack: two change

<krit> tkonno: ed: https://bugs.webkit.org/show_bug.cgi?id=136225

<krit> SubScript: krit

SuperScript: krit

<krit> ScribeNick: krit

update on SVG integration spec

<heycam> https://svgwg.org/specs/integration/

heycam: The spec hasn’t changed since the last time
... last time the OpenType group wanted a stable version by a part date
... since then I talked with Vlad how to reference this document
... he was concerned about making a normative reference unless it is REC
... in which case I think it doesn’t make sense to reference the document normatlively
... so I duplicated the changes to the OT spec
... and added an informative text and reference to the SVG WG spec
... saying that the SVG spec may update it

ChrisL: we had this issue before and it didn’t work out

heycam: SVG2 has context-fill/stroke which is not REC… So I duplicated this as well with a note as well
... so there is no particular time frame requiring us to get this along
... Dirk didn’t you have something to talk about fetching? The work with Anne?

krit: won’t be in the integration spec but in SVG2

Cyril: wanted to look at the document cause it is quite small
... and issue 1 is something we can dicuss
... what is relevant for the document for instance?
... currently there are 3 interesting sections
... the intro says it will also add more recommendation how to extend or use SVG
... [quoting the spec]

heycam: we don’t need to have those
... sizing and reference mode are most interesting IMO

Cyril: I thought it was the same as processing modes

heycam: I split it out
... they said animations in combination and scripting ….

Cyril: more higher level
... summary table of all different elements referencing element and the reference mode they use
... should be added

krit: just elements? or documents?

Cyril: just Cyril
... just elements

heycam: we should just have what we use on the web platform

Cyril: how are reference modes and processing modes related?

heycam: I might need to update the text in the example still
... static image document is an example of an reference mode

Cyril: the way you reference the document has impact how you process the document

heycam: that is right

krit: so you are saying processing is important as well?

Cyril: I think it should be clear

heycam: the set of reference mode can be referenced by the referencing elements that we add to the reference table
... the dot points in the issue has some nice to have
... but would say we should delay to for now
... the sizing stuff (next two dot points) has been defined

Cyril: isn’t sizing specified in CSS

krit: no

Rossen_: if it is embedded in contributes to the box model

heycam: we talked about intrinsic ratio, but where do we define that?
... Is it defined?

Rossen_: don’t think it is defined but it apparently was discussed to the last F2F

heycam: yes
... we can talk about it the next time

Cyril: ForeignObject use and size is not specified

heycam: ppl come up with their own ideas
... cause the main SVG spec doesn’t say

Rossen_: does it need any particular element defined?

heycam: no

Rossen_: don’t think so either

Cyril: the description like context (XML or HTML context for SVG) should go into this document

heycam: doug wanted to have a format to use HTML parser
... probably not more work

Rossen_: we can do HTML parser with additions in general

krit: there are certain cases where it is not enough

Rossen_: I think I agree that parse modes and expectations should be part of the document

heycam: ok, but it doesn’t need to be normative

Rossen_: at least interested people would have a document they can look at
... and then we should discuss

<Cyril> we should loosen the parsing

a less restrictive parsing mode

heycam: so the 2nd last point would be an interesting reference for user
... I had this but was hard to read.
... ok, so we add sizing, html vs xml parsing mode and that is all

Rossen_: I had issues with scroll bars and overflow on foreignObject

krit: ok, but fO is not part of SVG integration and should be discussed with SVG2

Rossen_: just mentioning it
... do we need to define the CSS cascade when it comes to integration?

<ed> FO is overflow:visible per default according to the current svg2 spec text

<Rossen_> http://codepen.io/anon/pen/CfGqy

krit: we do have different behavior with inner svg and other referencing modes

Rossen_: in the example I specified background color to the foreignObject and expected to get it applied.

krit: it should not apply to SVG elements at this problem

jwatt: I think it should

Rossen_: should be specified explicitly

Cyril: IMO a fO element should establish a viewport

<ChrisL> Its the combination of what is outside (FO) and what is inside (HTML or something using CSS) that establishes the containing block

Cyril: I though fO should inherit into the content of fO.

all: yes, that is correct

jwatt: I was saying that nothing stops us from defining background-color on fO element. It is currently not specified

krit: agree

heycam: what happens if you have multiple foreign namespace elements?

Rossen_: maybe it should be added to integration spec that you can not do that
... but we need to be careful
... because nesting may should work again

ChrisL: I think we should not define what happens with multiple childs

<ChrisL> and tell people not to do it

Rossen_: If I spec flex box on fO, I expect the content of fO to follow it
... fO is just the equivalent of the viewport box

<ChrisL> fair enough

krit: does it imply that viewport units are bounds to fO boundaries?

Rossen_: yes
... it is contextual, so fO should be part of integration spec

Cyril: I think so too

krit: do not agree

jwatt: don’t agree either
... I would also say it is not context dependent

Rossen_: for me it is just a viewport with scrollbars and stuff in it
... would you change the FF implementation to add background-color and scrollbars to fO?

jwatt: yes

Rossen_: ok, so then I agree it is not contextual
... are there any OM restrictions for the integrated content?

heycam: what do you mean?

Rossen_: scroll offset offset counts and all these regular HTML queries

heycam: the CSS OM view spec makes offsetTop work on plain SVG element

Rossen_: the reason I am asking: we define fO to be a viewport, then all queries would end there
... if vh and vw are reset to the new viewport, the queries should as well

heycam: not sure if I fully agree
... up to a cetain degree I do

<Rossen_> http://codepen.io/anon/pen/CfGqy

Rossen_: I updated the test

krit: as I expected, the viewport units use the real CSS viewports

Rossen_: FF does the same

krit: I think that fO is part of the document and does not simply embed a new document like iFrame

heycam: I agree with Dirk
... why would it be different from getting from HTML to inline SVG to SVG to HTML
... so the initial containing block is the size of the viewport. I would think it is more like a positioning containing block

Rossen_: it is different
... we do not establish that
... and don’t want to. Otherwise you print the content of the fO on every page if you print it as we do with other pos cont blocks

krit: we could come up with a new box

Rossen_: good luck with bringing that up to CSS WG

heycam: the initial containing block, the rendering of the box regardless of the box inside ()always renders HTML background border)

<heycam> ScribeNick: heycam

heycam: so if you have <foreignObject style="background:red"><otherlanguage/></foreignObject> does the red background still paint?

jwatt: yes I think it should
... partly for consistency, but also because an author has specified these things, so presumably they want them

Rossen_: so this also needs to create a "CSSOM root"
... so for example offsetTop calculations stop at the foreignObject

RESOLUTION: foreignObject will paint its box (including background, borders, etc.) and be a "CSS OM" root for offsetTop etc.

<scribe> ACTION: Cameron to make foreignObject paint its box and be a CSS OMroot [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action07]

<trackbot> Created ACTION-3654 - Make foreignobject paint its box and be a css omroot [on Cameron McCormack - due 2014-09-01].

heycam: for the "using Fetch" issue, Dirk says he will work on the in the main SVG spec
... next issue, should animations run in the resource document?

Rossen_: yes it's an issue

heycam: should the timelines between all resource document references to the same document be synchronised?
... maybe that lets you tell whether the resource document has already been referenced

birtles: for fonts I think you want this to be synchronised

Rossen_: there are many open questions about when the timeline actually begins

krit: if a resource document has a <pattern> with an SVG animation in it; should the animation run on the pattern?

jwatt: these resource documents might be embedded in documents from different domains

Cyril: what about resource documents referencing other resource documents?

heycam: that's disallowed, at least in firefox
... you can only go one level

birtles: at least these resource documents shouldn't be synchronised with the referencing document
... use might be different
... since that clones the subtree

krit: Rossen do you want animations running at all in resource documents?

Rossen_: I think it might be hard to argue against those use cases

ChrisL: I think there are only two possibilities here; all references to a given resource document uses the one timeline
... or they are all different

jwatt: you really don't want to be using all that memory
... you could make it opt in

Rossen_: I don't believe it will be that hard to enumerate your resources and find out if you have a matching one that's already existing, and just reuse that
... then you'll be getting into a timeline that's already in motion
... I agree I don't want to waste resources though

birtles: you can probably use <use> as a way to opt in
... the behaviour there might end up being different, if it's doing something like a clone of the DOM tree you would effectively be restarting animations
... so <use> might be the mechanism for that

jwatt: I certainly think the default should be a single instance of the resource document
... then we can look at what the opt in mechanism for different instances should be later

krit: external resources are not supported for the most part in Blink/WebKit

Rossen_: IE will implement them
... animations not running would be much simpler
... can we make the case for not running them?

<scribe> ACTION: Cameron to look into whether and how animations should run in resource documents. [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action08]

<trackbot> Created ACTION-3655 - Look into whether and how animations should run in resource documents. [on Cameron McCormack - due 2014-09-01].


krit: I don't think HTML specifies a timeline for gifs
... it allows the implementation to optimise if it is able

Rossen_: but using the same timeline is how it works

nikos: would usage patterns be different though? where a <pattern> might be used multiple times in different places?

<scribe> ACTION: Cameron to reword the smiley example text in SVG Integration [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action09]

<trackbot> Created ACTION-3656 - Reword the smiley example text in svg integration [on Cameron McCormack - due 2014-09-01].

<birtles> http://www.whatwg.org/specs/web-apps/current-work/#images-2

<birtles> "All animated images with the same absolute URL and the same image data are expected to be rendered synchronised to the same timeline as a group, with the timeline starting at the time of the least recent addition to the group."

<birtles> "In other words, when a second image with the same absolute URL and animated image data is inserted into a document, it jumps to the point in the animation cycle that is currently being displayed by the first image."

Summary of Action Items

[NEW] ACTION: brian to write up a more concrete proposal for allowing html elements directly in svg (related to https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration) [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action01]
[NEW] ACTION: Cameron to look into whether and how animations should run in resource documents. [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action08]
[NEW] ACTION: Cameron to make foreignObject paint its box and be a CSS OMroot [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action07]
[NEW] ACTION: Cameron to reword the smiley example text in SVG Integration [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action09]
[NEW] ACTION: Dirk to add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action05]
[NEW] ACTION: dirk to make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?) [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action06]
[NEW] ACTION: Doug to inform the community why we removed tref and how to solve the use cases [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action03]
[NEW] ACTION: Rossen to discuss svg layout using CSS during the coming CSS F2F meeting [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action02]
[NEW] ACTION: Tav to investigate blending for fill and stroke [recorded in http://www.w3.org/2014/08/25-svg-minutes.html#action04]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-08-25 16:36:45 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/translate3d/scale3d/
Succeeded: s/wrap elements is bad/wrap elements is unfortunate/
Succeeded: s/for templates/for <template>s/
Succeeded: s/mopve/move/
Succeeded: s/difficuly/difficult/
FAILED: s/physical vieport/nearest viewport/
Succeeded: s/the last time/since the last time/
Succeeded: s/Cyril/heycam/
Succeeded: s/yes/yes it's an issue/
Succeeded: s/for/against/
WARNING: No scribe lines found matching ScribeNick pattern: <cyril> ...
Found ScribeNick: ed
Found Scribe: cyril
Found ScribeNick: Cyril
WARNING: No scribe lines found matching ScribeNick pattern: <Cyril> ...
Found ScribeNick: cyril_
Found ScribeNick: cyril_
Found ScribeNick: cyril
Found ScribeNick: krit
Found ScribeNick: heycam
ScribeNicks: ed, Cyril, cyril_, krit, heycam
Present: Cameron Brian Cyril Konno Rossen Rik Dirk Jonathan Nikos Doug Chris Tav Jun Jet Erik
Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
Got date from IRC log name: 25 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/25-svg-minutes.html
People with action items: brian cameron dirk doug rossen tav

[End of scribe.perl diagnostic output]