- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 03 Jun 2013 17:32:07 +0900
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from day 1 of the Tokyo 2013 SVG F2F meeting:
http://www.w3.org/2013/06/03-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
03 Jun 2013
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2013/06/03-svg-irc
Attendees
Present
Jun, Cyril, Tav, Tab, Satoru, Yusuke, Tomoaki, Cameron,
Rik, Dirk, Nikos, Brian, Shane
Regrets
Chair
Cameron
Scribe
Cyril
Contents
* [4]Topics
1. [5]agenda
2. [6]should fill-rule apply to text elements?
3. [7]marker orientation issues
4. [8]feBlend issues
5. [9]enable-background issues
6. [10]What makes a stacking context?
7. [11]buffered rendering
8. [12]Stacking contexts, cont.
9. [13]review of hatches
10. [14]multiple paint servers on one element
* [15]Summary of Action Items
__________________________________________________________
<trackbot> Date: 03 June 2013
<TabAtkins> Hrm. I got confused and came up to Mori tower for
some reason. Is the best way to fix this to head back down and
use the subway again?
<heycam> TabAtkins, no, but it is about 15 minutes walk
<cabanier> scribenick: cabanier
<heycam> TabAtkins, (Mori tower is right where my hotel is)
<heycam> TabAtkins, do you have a map? it's a reasonably
straightforward route
<TabAtkins> kk
<TabAtkins> i have google maps?
<TabAtkins> kinda?
<shans__> TabAtkins: I can come get you if you want
<TabAtkins> heh, sure
<TabAtkins> <3
<TabAtkins> birtles: Yeah, I have that up, but it doesn't stop
me from being dumb.
<shans__> TabAtkins: OK, I'll meet you at the bottom of the
mori tower?
<TabAtkins> yeah, i'm at the starbucks
<shans__> TabAtkins: alright, be there in 10
<TabAtkins> yay!
agenda
heycam: are there missing topics?
… don't worry about scribing
<TabAtkins> Shane has found me! Coming in.
should fill-rule apply to text elements?
heycam: in svg 1.0, it applies to shapes and text
… but does it make sense?
Tav: maybe for SVG in OpenType?
heycam: does it make sense to control how the path data is
interpreted?
krit: per glyph or the whole word?
heycam: my feeling is that it's not very useful
… so wanted to see if other people feel the same way
… I discovered because a site was using
cabanier: yes, it should have no effect
… you are supposed to define them so that are unaware of the
fill rule
… outlining glyphs should be unaware of winding rules
heycam: our implementation was slower for even odd
krit: we rely on the rendering engine so it doesn't affect the
winding
nikos: so, subpixel-aa is also turned off
heycam: yes
... what if the glyphs overlap?
cabanier: they should paint separately and not interact with
each other anyway
heycam: so, should they work?
everyone: no
heycam: so we'll change the text so it doesn't aooky
Cyril: maybe this is for SVG fonts?
heycam: that's possible
... for SVG in OpenType, there's no way either
resolution: fillrule does not apply to text
marker orientation issues
tav: I added it
… basically there are inconsistencies between browsers
… you can look at the examples
<krit> [16]http://paullebeau.com/svg2/markers/
[16] http://paullebeau.com/svg2/markers/
… and there's also the question of rectangles
… what do you do with rounded corners
heycam: I remember making a test for this
… I have a feeling that the spec should define this
… ie angle coming from 2 different directions
krit: is there a spec issue of is it just implemenation
Tav: it might be just implementaion
… for 2 subpath, they should not be treated as 1
… I think
(looking over the examples)
heycam: looks like rendering issue
tav: what with the double point?
heycam: I wonder what the spec says?
… (reading) it seems that you get 2 markers for double points
krit: why would you draw points on top?
tav: maybe in animations
krit: I would expect the markers over each other
tav: you always get the discontinuity
krit: I'm more talking about transparent markers
heycam: taking a look at the 'correct' version, I think he is
right
krit: do we need to change the spec
heycam: yes, it should be make clearer. for instance the
orientation shouldn't be in an appendxi
… it could benefit from being rewritten
… orientation is also used for motion path orientation
krit: text on a path
heycam: yes when the glyph is on the point
… it sounds like we agree with his findings
TabAtkins: we can't use his exact wording
… because he wants to use coincident points to be ignorder
heycam: he may be talking about the orientation
… do we all agree that there should be rendering for each
point?
tav: yes
resolution: we agree with his finding to determine the
orientation of the marker and we should paint a marker for each
vertex even if they coincide
heycam: he also suggest a new value for the orient attribute
TabAtkins: that seems to make easy double arrows
heycam: given that you need to duplicate marker elements
TabAtkins: no, it will flip it around. the name is unclear
… start or reverse seem better names
heycam: I like the idea but not the name
tav: autoreverse?
TabAtkins: 'auto-reverse'
… could it be multi-value
heycam: not sure. let me check
<birtles> (discussed that 'auto-reverse' is used on
animateMotion's rotate attribute with different meaning so it
could be confusing)
… currently the value for marker orient is exposed as IDL
attributes
… orient type which is an animated enumeration
— and the angle value
… maybe we can resolve on this new value
resolution: we'll have a new value for orient attribute to do
the right thing for arrow heads
TabAtkins: there's an issue where there are begin and end
markers on closed paths
heycam: I find it odd that the open subpaths don't have an end
TabAtkins: that's what the spec said. It's on path element
itself
heycam: closed subpaths should only have marker mids?
all: yes
heycam: markers on rects and ellipses
(previous topic)
(discussion on just moveto's creating markers)
krit: we have patches to make that happen
heycam: I thought we had tests for all this
… but I can't find it
… so we should decide something
… I think it would be most consistent to paint both
krit: this is strange
TabAtkins: the problem is that this is a spec change
heycam: looking at subpaths makes more sense but it seems that
most implementations already agree on the just looking per path
element
… I'd be most happy with the small change
TabAtkins: it all seems broken
<TabAtkins> TabAtkins: All the existing renderings are broken.
>_<
krit: we should add a note that it may change in the future
resolution: we'll keep start and end markers apply to the whole
path
<TabAtkins> Hey shepazu, WRITE STAR.
<TabAtkins> Alternately, send me your notes and I'll write it.
<shepazu> TabAtkins, I'll write star
<shepazu> or at least start it
heycam: there was 1 remaining topic on markers
… rectangles, ellipses, etc
tav: what about rounded corners?
TabAtkins: all the remaining elements should define the
equivalent path
heycam: you'd probably want to use marker pattern
… should that be doable
TabAtkins: yes
birtles: it would be useful to have path equivalents for the
rect and ellipse
<birtles> (for variable-width stroke)
resolution: closed subpaths should get no start or end markers
<AlexD> +1 to that
heycam: I already have an action to come up with equivalent
paths for rects and ellipses
<AlexD> Make sure ellipses use ellipse segments, not beziers!
cabanier: yes
TabAtkins: Canvas already defines this
… it uses it as 4 arc paths
<AlexD> Nice
heycam: I have the action so we can draw the dashes correctly
<TabAtkins> Canvas doesn't define it as 4 arc paths - it does
it as one continuous arc. But still, its start point is the
rightmost point.
<TabAtkins> So we should match.
… maybe we can copy rect over from svg tiny 1.2
<AlexD> We already have tests for dashing around rects & Arcs
so should be easy to check they match
<AlexD> Ellipses, sorry
TabAtkins: yes, canvas has it with the start in upper left and
going clockwise
<heycam> AlexD, good point
<AlexD> e.g. shapes-ellipse-03-t.svg
resolution: we need to have markers on rect, circle and ellipse
and all basic shapes (in case of stars)
... rounded rects start at straight horizontal line of the top
left
... rounded rects wind clockwise and include 0 length segments
when the rounder corner is 50%
... for ellipses and circles, the path starts at right-most
point and consists of 4 arcs going clockwise and each are 90
degrees
<scribe> ACTION: heycam to integrate the marker resolutions in
the spec [recorded in
[17]http://www.w3.org/2013/06/03-svg-minutes.html#action01]
<trackbot> Created ACTION-3496 - Integrate the marker
resolutions in the spec [on Cameron McCormack - due
2013-06-10].
<TabAtkins> ScribeNick: TabAtkins
feBlend issues
cabanier: feBlend as defined today does blending an
compositing.
... This is usually fine today, but if you blend with
backgroundIMage, you'll get double compositing, and there's no
way to avoid it.
<Tav>
[18]http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filt
ers_Background.svg
[18]
http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filters_Background.svg
cabanier: We can either change feBlend (seems to be the only
way)
... We can add an attr to feBlend, so it doesn't do the
compositing.
... That is, do the "normal" compositing only.
krit: [draws an example]
cabanier: There's too much existing content out there for us to
change the default behavior.
... And if you don't use backgroundImage, it's not bad, and
sometimes good, to composite eagerly.
... So choices are add an attribute that stops compositing, or
try to detect when backgroundImage is the input, and don't
composite.
krit: I like the attribute, because it might sometimes be
useful to do the extra composite.
[some side discussion about naming]
TabAtkins: So it looks like just dropping backgroundImage
compositing would be web-compatible?
heycam: Anything else with this problem?
cabanier: feComposite, but that's much more intentional.
krit: There are more use-cases that might want only blending,
so doing the attr seems better.
ACTION krit to define a new attribute (nocomposite?) on feBlend
that turns off the compositing effect.
<trackbot> Created ACTION-3497 - Define a new attribute
(nocomposite?) on feBlend that turns off the compositing
effect. [on Dirk Schulze - due 2013-06-10].
RESOLUTION: Keep feBlend's current behavior (where it blends
and composites), but add an attribute that turns off
compositing.
enable-background issues
cabanier: Today, e-b has a really long description.
... I think IE implemented it, and Opera, but nobody else.
TabAtkins: I think roc is against it, and we (blink) have
similar concerns.
cabanier: Yeah, it's really expensive.
... The way it's defined today you have to render twice - once
to use as the background.
... Nice for authors, but hard/slow to implement.
... Adobe apps do something similar under the hood, which we
can add in the future.
heycam: Isn't there a trick to keep you from double-rendering?
cabanier: Yes, but there are still issues where you have to
keep two sets of pixels, and that kills performance.
<AlexD> double rendering? Isn't it just a backing store that
you bitblt as the second pass? Blts are fast:-)
<nikos> [19]http://www.svgopen.org/2005/papers/abstractsvgopen/
[19] http://www.svgopen.org/2005/papers/abstractsvgopen/
heycam: I think e-b isn't explained well in the spec, and if
impls have a trick that can make it not so slow, the spec
should define this.
... But you're saying that even with that trick, due tto the
arch. of accel. compositors, it'll still be slower.
cabanier: Yeah. We can revisit this in the future, but we
should get the basics right now.
... We can define similar things to HTML's "stacking contexts"
- if you ahve a <g> with opacity, it's a stacking context.
<AlexD> The requirements to support e-b are the same as
supporting filters. So if you can accelerate filters you should
be able to accelerate e-b. Need hard data to falsify this
claim:-)
No, it's not the same.
You can do filters with one copy of the data in a single gpu
pass.
<AlexD> <g> with opacity already requires some intermediate
thing - however you can do it with a pixel sequential renderer
and no backing store.
You don't have to go retrieve data from a different gpu pass in
order to render them.
[some discussion about transforms and stacking contexts]
<AlexD> agreed Tab, and you can model e-b in a similar way
<AlexD> backing stores can be a last resort fallback
cabanier: So I think we should get rid of e-b, and say that
certain elements create a fresh background.
krit: e-b can still be used to create an isolation group for
filters.
... That's what's done in Opera/IE.
<AlexD> If we get rid of e-b, then it should be replaced by
something better, like PDFs transparency groups which are a
better model
cabanier: It can also be used to make non-isolated groups.
krit: Some properties need to create isolated groups by default
anyway. For example, opacity needs to be an isolated group
independently of e-b.
... We already have some impls of e-b, and I'm not keen ot have
it removed without asking the impls about it.
cabanier: In the current spec langauge, it says you *must* use
e-b for blending to work. We don't want that either.
krit: e-b gets less necessary with the definition that some
other properties make isolation groups.
<AlexD> I agree, haven't seen a strong argument that it's not
implementable. Current architectures for H/W accelerate
shouldn't degrade the model...
cabanier: If we can just change e-b without breaking the web,
that's fine too.
... To summarize, everything that creates a stacking context,
creates an isolated group.
heycam: So what's the use of e-b outside of that?
[something about the effects of removing e-b from the spec]
heycam: So when do you want e-b? Somewhere when there's not
already an isolated group?
cabanier: Yeah, but there are several proeprties which can make
isolation without any other effects, and the 'isolation'
property specifically for that.
heycam: Okay, so it sounds easy to get rid of e-b, use
'isolation' or stackign contexts when you want to turn off
background blending.
... As long as people don't think there's strong use-cases for
people using the more complicated e-b stuff.
<AlexD> Maybe we can try to get some data about how much it's
used in the wild. Does Inkscape support it to isolate layers,
etc.
[rehashing of previous conversation]
krit: To be clear, e-b is implementable, just not with the perf
characteristics we want.
<AlexD> Then you need to write better code krit:-) GPUs are so
slow...
[discussion of the values that 'isolate' has and their
meanings]
<krit> AlexD: yeah, that is why I wrote everything for the CPU
:P
<cabanier> cabanier: the issue is not GPU performace, the
problem is that you need at least 2 extra readbacks from the
backbuffer and 3 writes to the input buffer
heycam: Regardless of discussion over ease of implementation,
because current impls dont' do it and don't want to do it, the
spec should leave it out for the moment.
<AlexD> Again we need to get hard data on whether it's used.
Currently it acts as a spot to run your filter chain back to.
So we need to at least address that case.
<cabanier> cabanier: which accesses the memory a lot more which
will drain your battery
heycam: If Alex can convince people later, we can add it.
krit: [wants a value for 'isolate' that prevents isolation of
descendants even with stacking contexts. Pointed out that we
can add this later and have 'auto' respond to it]
RESOLUTION: Remove e-b from this level of Filters.
<AlexD> For the record I'm not for or against, just want to
make sure we don't break existing content in the field
krit: Should I remove e-b silently, or have a note?
several: Seems useful to have a note pointing back to the old
definition.
What makes a stacking context?
cabanier: Anything in CSS that makes a stacking context -
transforms, filters, etc.
heycam: Do you really want every transform attr to make a
stacking context?
<AlexD> NOOOO!
cabanier: No, but we want to be simple and consistent with CSS.
;_;
krit: We all agree that SVG transforms are oftne just used for
moving things around, and are quite basic, rather than
something that requires stacking contexts.
... But impls all do normal CSS stuff.
cabanier: Maybe we can say that 2d transforms in SVG dont' make
a stackign context?
heycam: If you want the same kinds of optimizations, maybe you
do want stacking contexts.
cabanier: Like smooth transitions, yes.
krit: Does FF do transform transitions in hardware? WebKit
doesn't do it yet (all software for SVG), but we want to change
that.
heycam: Same.
... Seems like this will suck.
cabanier: It will.
krit: Rik tried to specify it around whether you're animating
or not, but it didn't gain consensus - ugly flash when you
change.
cabanier: So maybe we can just differentiate 2d vs 3d - 2d
doesn't make a stacking context in SVG.
heycam: What if authors definitely want a separate layer, but
ar ejust using 2d transforms?
TabAtkins: Use a null 3d transform, or just use 'isolate'.
heycam: Ah, I think I might be okay with using 'isolate' to get
the stacking context.
Cyril: That seems to make sense.
<AlexD> I like isolate better than the 3d transform hack
krit: I think in practice implementors are going to use the
same code as in HTML/CSS, so 2d transforms will be isoalting as
well.
... I think we should add an agenda for Wed to ask the other
CSS implementors.
cabanier: Back to the original context, also filters and
opacity cause stacking contexts.
Cyril: z-index also makes a stacking context?
heycam: Yes, just like CSS.
Tav: Question about that - we have someone wanting to
implementing connectors in Inkscape.
... You have symbols for the components, want connectors on
different layers, etc.
... Suppose my symbol has things with different levels.
... And I want to have multiple symbols sometimes interleave?
[explanation of how stacking contexts work]
[conclusion is - it'll work, but making the symbol itself a
stacking context will prevent it]
Cyril: [discussion of a layer use-case]
heycam: BAck to main discussion, are people expecting blending
to work through opacity?
cabanier: Probably, but it's hard to make work.
krit: We make them isolated groups, and I think FF does too.
... Also masks and clips are stacking contexts.
cabanier: Why are clips?
TabAtkins: They're basically inverses of each other.
heycam: Simple clips can be done simpler than masks, but
complex clips (with overlapping curves, or text, etc.) might
use the same code path.
krit: Remember, this is the firsst level of blending. In the
next level, we can do "real" blending, so it can go through
stackign contexts, etc.
buffered rendering
Cyril: It's a hint.
krit: That's the problem. Blink is looking to implement it.
... So it can make a stackign context sometimes - "auto" is
determined by the engine.
... So we should change "auto" to mean "don't make an image
buffer".
Stacking contexts, cont.
[I meant that 'buffered-rendering' also causes stackign
contexts.
RESOLUTION: buffered-rendering:auto/dynamic never create a
stacking context; "static" does.
<Cyril> scribe: Cyril
<scribe> scribeNick: Cyril
heycam: someone should actually note those things that create a
stacking context in the spec
<scribe> ACTION: Rik to note those things that create a
stacking context in the spec [recorded in
[20]http://www.w3.org/2013/06/03-svg-minutes.html#action02]
<trackbot> Created ACTION-3498 - note those things that create
a stacking context in the spec [on Rik Cabanier - due
2013-06-10].
heycam: the rendering model chapter should reference the
compositing/blending
nikos: I did start updating it
<heycam> [21]https://svgwg.org/svg2-draft/render.html
[21] https://svgwg.org/svg2-draft/render.html
cabanier: the CSS compositing spec references that and extends
it
[22]https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.h
tml#module-interactions
[22]
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#module-interactions
cabanier: we believe that CSS Blending and CSS Filters
currently extend SVG 1.1 and don't need to reference SVG 2
krit: it depends on when SVG 2 goes to CR state
cabanier: there needs to be a link back from SVG 2 to those 2
specs
... does this mean those 2 specs need to be at CR stage ?
krit: no
review of hatches
<Tav> [23]https://svgwg.org/svg2-draft/pservers.html#Hatches
[23] https://svgwg.org/svg2-draft/pservers.html#Hatches
Tav: I'd like people to review it and tell me if it is ok
krit: how would you implement hatches ?
tav: creating a pattern on the fly could work
krit: hatch as a dimension
tav: inifinite in one direction
... you can go to one tile but need to be carefull at tile
boundary
... I would make the tile the size of the whole thing
... as long as you take car of the boundaries, it should work
heycam: can you summarize the new elements
<AlexD> Take a look at my open source hatching that I emailed
ages ago - it's really easy to hatch. You generate the bound
box of the thing being filled, generate the lines and clip them
against the polygon.
tav: the hatch element copied from the pattern element
<heycam> AlexD, but does that work if you want to use the hatch
in the stroke of a shape?
<heycam> (unless you have good stroke-to-path routines)
<AlexD> Yes - you have to generate the outline of the stroke of
course
tav: the hatch has a pitch to repeat
<AlexD> [24]http://www.ishtek.com/hpgl2.htm
[24] http://www.ishtek.com/hpgl2.htm
tav: the hatch has a path which defaults to a line
... and an offset from the origin
heycam: can you choose the origin ?
tav: yes, that's copied from patterns
<AlexD> Source code is [25]http://www.ishtek.com/gl2-0_1.zip
[25] http://www.ishtek.com/gl2-0_1.zip
<shepazu> (isn't the problem with patterns a matter of
implementation, not an inherent problem with the spec?)
tav: the fdifference between a normal path and a hatch path,
you don't have to provide the original move to
... if not, the y is 0 and x is that last x value
... that's how you get the continuous
heycam: why y = 0 ?
tav: because you're repeating in the y direction
... look at the 1st squiggle example
krit: why do you need to introduce a hatchPath element? why not
reuse the path element?
Tav: no initial move to
... it's necessary to repeat
... examples 9 and 10 show the difference between having the
initial move to or not
krit: why do you need the angle attribute since you have the
transform attribute ?
tav: maybe not needed then ...
krit: it can be confusing in which order they apply
tav: I have to think about it
nikos: should the d attribute be called differently ?
krit: I'm worried about the transform attribute
... we already have the gradientTransform ...
tav: that's fine with me, I just copied over from pattern
heycam: this brought the issue of capitalization of elements
... we did not resolve firmly on it
... especially given the HTML parsing algorithm
... each new mixedCase name that we introduce we need to update
the HTML parser
krit: I think we should continue with our naming
heycam: and update the HTML spec ?
... otherwise the casing will not be preserved
... I'm pretty sure there will be a problem if we don't do
anything
... we could say that both names work in the DOM
krit: is it only when SVG elements are not used in an SVG
subtree ?
heycam: no, even if in an SVG subtree because the HTML parser
won't know that new element
Tav: that must be trivial to fix
heycam: yes, but that could create problem between parsing and
DOM manipulations
... maybe it's not a big deal because people won't be doing
that
... one solution could be to allow both cases to produce the
same DOM element
... because if we don't allow that we have to file a bug on the
HTML spec
krit: can you fill hatch paths ?
Tav: no
... that needs to be clarified
krit: what about filters ?
heycam: and markers ?
... can you use the normal stroke properties ?
Tav: yes
... even variable width stroke, but it depends on the use case
heycam: it makes sense to allow all stroke properties
... you could do overlapping, which you can't easily do with
patterns
Tav: overflow on the parent is not defined
<AlexD> Yes, and it does that in GL/2 i.e. hatch lines are
clipped, then the stroke can go outside the original shape with
line ends, etc.
heycam: if overflow is set to hidden, then there must be some
rectangular region used for clipping
tav: the rectangular region is infinite length
(tav drawing on the board)
krit: there would be a difference between overflow x and
overflow y
Tav: it would be nice to have overflow on patterns
krit: it was implemented but then removed from the spec
Tav: it would be easier for authors
heycam: I do it 4 times and clip the middle
krit: it was not implemented by Opera and Firefox
Tav: can we revisit that for SVG 2
heycam: let's start without it
Tav: any other issue that people see ?
heycam: I would start with the assumption that all stroke
properties work
krit: should all paint servers work ?
Tav: like a hatch inside a hatch ?
... why not if it can be implemented easily
<AlexD> Mmmm, fractal hatching:-)
heycam: most people won't use it
... if you have a hatch whose stroke properties references a
paint sever defined in terms of objectboundingbox
... which bounding box would you use, the small one or the
infinite one ?
krit: can we leave that undefined for now
... unspecified
heycam: I don't think it should stay unspecified
TabAtkins: it is a mistake to leave it undefined
Tav: we could say only solid colors for now
RESOLUTION: Hatch will only support solid color paint servers
Cyril: can you reuse a path?
Tav: that's not really the same as another path?
... currently there is only a hatchPath and it cannot reference
something else
krit: I would leave it like that
heycam: there is a xlink:href attribute on the hatch element
break
<TabAtkins> /break
<TabAtkins> [Presentation from IDPF about "Advanced Hybrid
Layouts" to get input from SVGWG for some questions.]
<TabAtkins> [Slides will be published shortly.]
example of "intra-navigation rendition" for Comics using SVG:
[26]http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/
[26] http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/
works only in Firefox
<TabAtkins>
[27]http://www.whatwg.org/specs/web-apps/current-work/multipage
/the-map-element.html#attr-area-shape
[27]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-area-shape
heycam; we could have the overflow property apply to the view
element
krit: does it need to be the view element ?
TabAtkins: yes because there is no nested svg element
... it has to be a view
krit: you could use the view element with use elements
IDPF: would you feel offended if we added our own attribute
heycam: we would prefer to define it in SVG
TabAtkins: it sounds useful for general SVG
IDPF: multi-lingual manga, tapping an area or moving the mouse
over to change the language
... it dosn't work on tablet
birtles: you can use SVG animations
TabAtkins: or HTML with hidden option elements
... with pure HTML, no JavaScript
heycam: relies on the fragment changing and links?
TabAtkins: using check boxes and radio buttons and
pseudo-classes
... use check to display none
... you can cycle between language
birtles: if your UA supports SVG animations, it would be a lot
simpler and more semantically intersting to use SVG
IDPF: what about CSS animations?
TabAtkins: some of it will be only possible in SVG animations
... what about scaling to 100 languages
IDPF: with menus maybe
TabAtkins: JS would become more useful
IDPF: could you use SVG animations to store your language
preference
Cyril: maybe using SMIL state
birtles: you could use the switch element
krit: I would not rely on the switch element
IDPF: how well is the support for animation
birtles: well in all browsers except IE
krit: but you could use JS libraries
[28]http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/
[28] http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/
<TabAtkins>
data:text/html;charset=utf-8,<!DOCTYPE%20html>%0A<div%20id%3Dba
ckground>%0A%20%20<input%20name%3Dfoo%20type%3Dradio%20id%3Di1%
20checked><label%20for%3Di2>1%2C%202%2C%203<%2Flabel>%0A%20%20<
input%20name%3Dfoo%20type%3Dradio%20id%3Di2><label%20for%3Di3>%
E4%B8%80%2C%20%E4%BA%8C%2C%20%E4%B8%89<%2Flabel>%0A%20%20<input
%20name%3Dfoo%20type%3Dradio%20id%3Di3><label
<TabAtkins>
%20for%3Di1>i%2C%20ii%2C%20iii<%2Flabel>%0A<%2Fdiv>%0A<style>%0
Ainput%2C%20input%3Anot(%3Achecked)%20%2B%20label%20%7B%20displ
ay%3A%20none%3B%20%7D%0A<%2Fstyle>
<TabAtkins> D'oh, terrible link handling.
IDPF: How should we capture regions ?
<TabAtkins>
[29]http://software.hixie.ch/utilities/js/live-dom-viewer/saved
/2271
[29] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2271
<TabAtkins> ^^^ Example of cycling language via HTML.
<TabAtkins> (And it can be powered up with a "default language"
selection as well.)
IDPF: Should we use SVG views, SVG elements in the rendition
tree or SVG elements in <defs>
Cyril: you want to describe metadata
IDPF: yes
... a tree of regions
... for navigation
... the rest is flat
heycam: is the description of the hierarchy inside or outside
the SVG document ?
IDPF: outside
<TabAtkins> (Also, the basic mechanics in my example are
captured in a draft CSS spec on my blog, and the CSSWG is
interested in pursuing it, so this might be usable for SVG as
well.)
TabAtkins: if you extend media fragment to add a polygon that
might do a lot
IDPF: yes
Cyril: it would be good to add the metadata in the SVG document
to enable viewing it with browsers
... possibly with JS navigation logic
IDPF: why having both views and fragment identifiers ?
heycam: maybe for flexibility
TabAtkins: yes it depends on who is the author of the document
<birtles> SVG version of above:
[30]http://software.hixie.ch/utilities/js/live-dom-viewer/saved
/2272
[30] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2272
heycam: we can answer to the IDPF questions in a liaison
... we need also to wok on the clipping question
TabAtkins: overflow should clip the content
... I will take the question to the CSS group
... and we need to work on swapping text around
heycam: there is also a work on custom media queries
TabAtkins: to avoid creating a class attribute on the body
(modernizr)
IDPF: we are wondering if we should use media queries for text
direction or language
TabAtkins: it should work
... your use cases seem appropriate for MQ
... some properties like luminance are in CSS MQ 4
<heycam>
[31]http://www.w3.org/mid/CAAWBYDBbJ5qSDZzHAvThdA9W0PDmEOTh7+Ap
LaQYtHwi6U0o_Q@mail.gmail.com
[31]
http://www.w3.org/mid/CAAWBYDBbJ5qSDZzHAvThdA9W0PDmEOTh7+ApLaQYtHwi6U0o_Q@mail.gmail.com
heycam: in summary we need to answer how to represent non
rectangular view, clip them, swap text, more media queries
<TabAtkins> Also: where to put region information?
<TabAtkins> heycam: Keep it in content where possible.
heycam: we can consider that for SVG 2
... you need to point to the views from outside
... and for browser fallback to use # to those views and have
sensible behavior
IPDF: we like CR
heycam: the original plan was to have a stable version at the
end of this year
... but I'm not sure we can make that
... we could right a separate specification if that would make
your life easier
IDPF: yes that would
... we would need to decorate semantically the views
heycam: I think that would be fine for you to define the
semantics in the SVG document in a different namespace
IDPF: yes that's our plan
... also order would be significant
heycam: arbritrary authoring tools might not preserve the order
IDPF: but we might need to represent the order in our external
navigation metadata documet
heycam: I will gather our ideas and send that as a liaison
<scribe> ACTION: heycam to gather ideas for solving IDPF issues
and send that as a liaison [recorded in
[32]http://www.w3.org/2013/06/03-svg-minutes.html#action03]
<trackbot> Created ACTION-3499 - Gather ideas for solving IDPF
issues and send that as a liaison [on Cameron McCormack - due
2013-06-10].
<heycam> ScribeNick: heycam
multiple paint servers on one element
Tav: sometimes you want a crosshatch
… you could have multiple fills on an object
… it might be useful to have a colour fill and with a hatch on
top
… how to specify this?
… maybe a comma separated list?
krit: and what about the fallback value?
… fill/stroke have a paint server reference and a fallback
value
… how does that work?
TabAtkins: just like background, the last thing would be a
colour
… and you'd fall back to that
… it's comma separated, but the last layer can be a colour
krit: you have a space separated fallback colour in fill/stroke
now
heycam: why not have <paint> for each item?
krit: then we need to define the paint order. we should do it
like background-image.
heycam: so it's backwards?
Tav: that's how I'd do it
krit: what about having fill-attachment, fill-clip, ...?
TabAtkins: do we really want that? it might be a good idea,
but...
heycam: allow that for stroke as well?
Tav: yeah
RESOLUTION: We will allow multiple paints in the fill and
stroke properties in SVG 2.
<TabAtkins> Comma-separated, painting first layer on top, last
on bottom. Only last layer can be a color or have a fallback
color.
cabanier: what about the other stroke properties, like
stroke-width?
heycam: having a comma separated list of stroke-dasharrays
would be problematic
… we could wrap them in a function if we need to, though
krit: I don't want to support those yet
… let's just do fill and stroke properties, and leave stroke-*
properties as single items for now
heycam: ok
<scribe> ACTION: Tav to put multiple fills/strokes in SVG 2.
[recorded in
[33]http://www.w3.org/2013/06/03-svg-minutes.html#action04]
<trackbot> Created ACTION-3500 - Put multiple fills/strokes in
SVG 2. [on Tavmjong Bah - due 2013-06-10].
RESOLUTION: <hatch angle> will be renamed <hatch rotate>.
... <hatch rotate> will allow angle units.
Summary of Action Items
[NEW] ACTION: heycam to gather ideas for solving IDPF issues
and send that as a liaison [recorded in
[34]http://www.w3.org/2013/06/03-svg-minutes.html#action03]
[NEW] ACTION: heycam to integrate the marker resolutions in the
spec [recorded in
[35]http://www.w3.org/2013/06/03-svg-minutes.html#action01]
[NEW] ACTION: Rik to note those things that create a stacking
context in the spec [recorded in
[36]http://www.w3.org/2013/06/03-svg-minutes.html#action02]
[NEW] ACTION: Tav to put multiple fills/strokes in SVG 2.
[recorded in
[37]http://www.w3.org/2013/06/03-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
Received on Monday, 3 June 2013 08:32:56 UTC