See also: IRC log
<ed> scribeNick: ed
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming
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
<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
https://svgwg.org/svg2-draft/embedded.html
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>
<svg>
<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
<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
<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
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
<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
<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].
http://www.w3.org/TR/SVGTiny12/linking.html#externalReferences
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."
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]