- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 26 Aug 2014 02:39:10 +1000
- To: www-svg@w3.org
http://www.w3.org/2014/08/25-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
London 2014 SVG WG F2F Day 3
25 Aug 2014
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2014/08/25-svg-irc
Attendees
Present
Cameron, Brian, Cyril, Konno, Rossen, Rik, Dirk,
Jonathan, Nikos, Doug, Chris, Tav, Jun, Jet, Erik
Regrets
Chair
Cameron
Scribe
cyril
Contents
* [4]Topics
1. [5]Performance of transformation in panning & zooming
("transforms", "will-change")
2. [6]HTML integration (aka iframe spec issues)
3. [7]HTML Integration (issue 2)
4. [8]Decision on tref
5. [9]fill and stroke improvements
6. [10]CSS layout properties
7. [11]update on SVG integration spec
* [12]Summary of Action Items
__________________________________________________________
<ed> scribeNick: ed
Performance of transformation in panning & zooming ("transforms",
"will-change")
[13]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performan
ce_in_panning_%26_zooming
[13] 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
[14]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performan
ce_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
[14] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Facts
(this is chrome version 36)
<heycam>
[15]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performan
ce_in_panning_%26_zooming#Facts
[15] 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
[16]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performan
ce_in_panning_%26_zooming#Possible_Solutions
[16] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Possible_Solutions
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>
[17]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Age
nda/HTML_integration
[17] 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
[18]https://svgwg.org/svg2-draft/embedded.html
[18] 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)
[19]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Iframe_spe
c_issue_through_the_development
[19] 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
[20]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Age
nda/HTML_integration) [recorded in
[21]http://www.w3.org/2014/08/25-svg-minutes.html#action01]
[20] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration)
<trackbot> Created ACTION-3648 - Write up a more concrete
proposal for allowing html elements directly in svg (related to
[22]https://www.w3.org/graphics/svg/wg/wiki/f2f/london_2014/age
nda/html_integration) [on Brian Birtles - due 2014-09-01].
[22] https://www.w3.org/graphics/svg/wg/wiki/f2f/london_2014/agenda/html_integration)
-- 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> [23]https://svgwg.org/specs/integration/#foreign-content
[23] 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>
[24]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0144.ht
ml
[24] 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
[25]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> [26]http://tavmjong.free.fr/SVG/TREF/tref.html
[26] 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
[27]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
[28]http://svg-wow.org/buffered-rendering/bokeh.html
[28] 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
[29]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> [30]https://svgwg.org/svg2-draft/layout.html
[30] 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
[31]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
[32]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:
02[33]http://git.io/yfWm8Q
[33] http://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:
02[34]http://git.io/CB5w2w
[34] http://git.io/CB5w2w
<commit> 13test/06master 14a882407 15Cameron McCormack: test
change
<commit> [13test] 15heycam pushed 1 new commit to 06master:
02[35]http://git.io/_-2DbA
[35] http://git.io/_-2DbA
<commit> 13test/06master 148608157 15Cameron McCormack: Another
test change.
<commit> [13test] 15heycam pushed 2 new commits to 06master:
02[36]http://git.io/nycJ3w
[36] http://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:
02[37]http://git.io/WRVt0Q
[37] http://git.io/WRVt0Q
<commit> 13test/06master 1418185ff 15Cameron McCormack: one
change
<commit> 13test/06master 140e1f0f7 15Cameron McCormack: two
change
<krit> tkonno: ed:
[38]https://bugs.webkit.org/show_bug.cgi?id=136225
[38] https://bugs.webkit.org/show_bug.cgi?id=136225
<krit> SubScript: krit
SuperScript: krit
<krit> ScribeNick: krit
update on SVG integration spec
<heycam> [39]https://svgwg.org/specs/integration/
[39] 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_> [40]http://codepen.io/anon/pen/CfGqy
[40] 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_> [41]http://codepen.io/anon/pen/CfGqy
[41] 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
[42]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
[43]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].
[44]http://www.w3.org/TR/SVGTiny12/linking.html#externalReferen
ces
[44] 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
[45]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>
[46]http://www.whatwg.org/specs/web-apps/current-work/#images-2
[46] 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
[47]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
[48]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
[49]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
[50]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
[51]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
[52]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
[53]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
[54]http://www.w3.org/2014/08/25-svg-minutes.html#action02]
[NEW] ACTION: Tav to investigate blending for fill and stroke
[recorded in
[55]http://www.w3.org/2014/08/25-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [56]scribe.perl version
1.138 ([57]CVS log)
$Date: 2014-08-25 16:36:45 $
__________________________________________________________
[56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[57] http://dev.w3.org/cvsweb/2002/scribe/
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 [58]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[58] 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 C
hris Tav Jun Jet Erik
Agenda: [59]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agen
da
Got date from IRC log name: 25 Aug 2014
Guessing minutes URL: [60]http://www.w3.org/2014/08/25-svg-minutes.html
People with action items: brian cameron dirk doug rossen tav
[59] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
[60] http://www.w3.org/2014/08/25-svg-minutes.html
[End of [61]scribe.perl diagnostic output]
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 25 August 2014 16:39:39 UTC