- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 25 Jul 2012 15:47:12 +0200
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes below:
http://www.w3.org/2012/07/24-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
24 Jul 2012
[2]Agenda
[2]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/07/24-svg-irc
Attendees
Present
+1.206.675.aaaa, Tav
Regrets
Chair
ed
Scribe
birtles, ChrisL, krit, cabanier
Contents
* [4]Topics
1. [5]Marker proposal review
2. [6]Revised text layout proposal
3. [7]white spaces edits in SVG
4. [8]SVG in Web IDL
5. [9]Quick question about mask: <funciri> auto
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 24 July 2012
<Tav> Telephone?
<birtles> scribenick: birtles
Marker proposal review
<ChrisL> scribenick: ChrisL
<birtles>
[11]https://svgwg.org/svg2-draft/painting.html#Markers
[11] https://svgwg.org/svg2-draft/painting.html#Markers
<birtles> CM: I want to go through the marker part of the spec
<birtles> ... some might need changing
<birtles> ... I've rewritten that hold section using fewer
words
<birtles> .... I've defined different types of markers
<birtles> ... four kinds: (1) vertex markers
<birtles> ... you can do this currently
<birtles> ... (2) segment markers, this is a new one
<birtles> ... they place markers at the centre of the path
segment
<birtles> ... (3) repeating markers
<birtles> ... specify a pattern like a dash to repeat markers
at fixed distances along the patah
<ed> scribenick: birtles
UNKNOWN_SPEAKER: (4) position markers
... use markers as a child of a path element
... at fixed positions
<heycam>
[12]https://svgwg.org/svg2-draft/painting.html#MarkerSegmentPro
perty
[12] https://svgwg.org/svg2-draft/painting.html#MarkerSegmentProperty
UNKNOWN_SPEAKER: this is (2), similar to marker-mid
... but in the middle of the edge
ED: what happens if you have a zero-length segment
?
CM: I think it's defined but I would expect it to paint
DS: what about a zero-length path?
CM: I think it won't paint
... marker-mids render on zero-length segments right?
... so in keeping with that you'd do the same here
... and render even for zero-length segments
DS: what does that mean?
... so in order for it to render you have to have at least one
segment of non zero-length?
... so an empty path doesn't render
CM: right
... someone pointed out they'd prefer not to have a
discontinuity as segments get shorter and shorter
... they shouldn't suddenly disappear
ED: what about only rendering if the segment length is longer
than some length?
CM: that's an interesting idea
DS: could be a property
CM: apart from that marker segments aren't too complicated
... but marker patterns (3) are more interesting
<heycam>
[13]https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers
[13] https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers
CM: in Hamburg we discussed this
... talked about having a feature where you could say "skip to
the next vertex"
... but after thinking about that it didn't seem that useful to
me
... and if you want things on edges and vertices then you can
use the other properties
TA: looks good to me
CM: one thing you may want to do
... is stretch out the marker pattern so that it's an even
number of markers along the path
... perhaps the pathLength attribute could affect the distances
in the marker pattern?
... like with dash arrays
... so we should get that for free by using pathLength
... the lengths you specify in this property would be
proportions of the pathLength if you specify that property
DS: what's the big difference between marker and marker-pattern
CM: the existing markers can only be positioned on the vertices
... but this lets you put them by distance along the path
DS: if I click on one of these markers what happens?
CM: these ones (1)-(3) are the same, you can't click on them
... that don't have a unique ID
... so you won't know which one you clicked on
... but the positioned markers (4) do allow you to do that
<heycam>
[14]https://svgwg.org/svg2-draft/painting.html#MarkerElement
[14] https://svgwg.org/svg2-draft/painting.html#MarkerElement
CM: there is an example of positioned markers in the element
section
... at the end of that subsection
... below the attribute definitions
... you could use this for putting arbitrary patterns on a path
... the item marked "the cross" in example 1 in the spec
... in this example there are some marker children
... and the reason they are positioned markers and not regular
markers using the referencing scheme discussed yesterday is the
position attribute
... as well as the position attribute I've added an href
attribute
... since you might want to reference some existing marker
definition
... rather than duplicating it
... in that example, there's <marker href="#Square" ... />
DS: why no just use <use>?
CM: because then how do you know it's a marker?/
... I used a calc since we should be allowing calc wherever we
allow lengths
... that is, we should be allowing CSS lengths
CC: how does this work this the proposal we discussed yesterday
... where marker children become regular markers?
CM: well, a marker could serve both purposes
... a child marker could simultaneously by referenced from
marker-mid, marker-segment
... as well as being a positioned marker by having a position
attribute
... whether it is a positioned attribute or not is dependent
solely on whether or not it has a position attribute
RC: so a marker that doesn't have an href, has no refX, refY?
CM: there is a default value
... 0,0
... my example there should have a refX
... the thing with the positioned markers is that you can put
event listeners on those markers
CL: it would be worth calling that out
CM: yes, I have an issue to do that
DS: I like it
CM: re clipping, the problem was we wanted to specify parts of
the underlying path to knock out
... e.g. so it doesn't appear around the edge of the arrow head
... so I tried to make it easier to compute a single clipping
path to apply when rendering the whole path element
<Tav> [15]http://tavmjong.free.fr/blog/
[15] http://tavmjong.free.fr/blog/
TB: I think it would work better if you specify a clipping path
relative to the marker
... I have some examples of that
... you define the marker and you define a clipping path
relative to that
CM: clipping paths normally specify the part you preserve
rather than the part you remove
DS: I'd like to revisit that
CM: one issue is if you have a bunch of markers that overlap
... it would be nice if you could in the implementation, treat
it as a clipping path you apply before painting
... if each clipping path specifies the area you want to remove
... the implementation has to compute the inverse of that
... which might tricky but probably possible
DS: do you want the author or implementation to calculate it?
... it makes sense for the implementation to do it for simple
cases
... but for complex cases it doesn't
CM: I'm ok with the author specifying the clip path
CC: Figure 13, with knock out
... you have two paths joining
... and you specify marker start and end
... how many line segments do you have in these examples?
CM: 1
DS: these are shapes being cut out
... each of these labelled sections is a path
... and there's a knockout for those
CM: to make it easy to calculate intersection of shapes
... I limited it to some simple shapes
... it makes the computation easier for calculating
intersections
... so I specified the two halves of the shape you're knocking
out separately
CL: can left and right be different?
CM: yes
CC: what is the syntax
CM: it's underneath
DS: why can't the path in the mask be the clipping-path?
CL: I think that's common, e.g. the path plus 3px
CM: I think that's common but also I think these shapes are
useful
TB: how does this affect the fill on the path
CM: I haven't quite worked that out yet
... but you could either have this knockout the fill or not or
make it controllable
DS: can Tav's proposal also solve the problem?
CM: yes
CC: it would be nice to have more drawings in the spec about
how the triangle etc. are drawn
DS: if I clicked on one of these knockout areas what happens?
CM: I assume we do the same as clip-path, i.e. it doesn't hit
the element
DS: ok, we should make that explicit
CM: if we allow the author to specify arbitrary paths for the
area you want to remove
... or the area to include from the marker
... what you need to end up with is a clipping path as we
currently have it
... that you can apply before painting
... if you do that manually you need a big rect to cover the
bbox
... plus a reverse path for the section you want to remove
<ed> would be nice to have an example like this: ->>-
CM: you have to get the clipping path in that form
... unless you want to turn it into a mask (which would be
slower)
... so you need to get the clipping path in that form
(everything included except some bit)
... but you don't want the author to have to specify that
... since, for a start, the author doesn't know how big the
path will be
... so you could allow the author to just specify the bit to
remove
... or they specify the bit they want to include
... and the implementation computes the reverse shape
... and I'd rather not require implementations compute the
reverse shape
... to make it easiest for the author you want them to specify
some part of the shape
... but the implementation has to calculate the overall
clipping path
... and that's what I was trying to help with by using these
predefined shapes
... makes it easy for the implementation to do intersection
detection
DirkS: so you can calculate it rather than asking the graphics
library
CM: it's a lot simpler than bezier curves
... I'm not sure if this is the best way
DougS: what if I don't want to specify a knockout shape
... would the default be the bbox of the shape?
CM: bbox would work for some things like arrows
... but not for many other things
DougS: I think for other cases you use the knockout shapes
... but having a default be bbox it takes the burden off
authors from having to specify anything at all
... perhaps "auto" = bbox ?
<Zakim> ChrisL, you wanted to ask about child(n) and to
consider a keyword that takes the stroke width
CL: I was wondering if would be useful to have a keyword that
means the width of the stroke
... since I think that would be one of the most common knockout
cases
CM: that's the most you need to clip out is up to the width of
the stroke
DougS: yes, that might be more common than bbox
CM: if you're clipping out a square that is exactly the height
of the stroke
... you need to be careful that you do actually do cover the
whole stroke
... if you specify the clipping path you have the be careful
you don't run into precision issues
DougS: what happens if the stroke comes back again under the
marker
... what happens to that new bit of stroke?
CM: I think unless you want to split up the path into multiple
sections
... if you set up a single clipping path before you draw the
path
... you'll have problems
... at least, if you the area you're knocking out goes beyond
the marker shape
DirkS: paths are 1-D, so you apply the clipping path to the
whole path
CM: if you want overlapping behaviour, like the overlapping
road example, you have to split the path
DirkS: should the knockout area for a marker on a curved part
of the stroke also follow the curve?
CM: good question
... I think there are cases where the marker should be
distorted and cases where it shouldn't (e.g. subway circle)
... if the marker is empty and you just want to remove some
part of the path
... then you probably do want the knockout area to be curved
CC: this knockout property seems to make a different between
left and right
... but so far markers don't make that distinction
CM: the shape of your marker might not be symmetrical
... so you might want to knockout out different shapes on
different sides when the marker is in the middle of the path
ED: is the rendering order defined?
CM: yes, it's defined
... marker-start, alternating, segment vertex, marker-patterns,
children etc.
TA: why left / right?
... start / end?
CM: sounds good
<ed> ah, found it...
[16]https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm
[16] https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm
CM: when we publish the spec, is it ok to keep this part in?
All: yes, leave it in
Break time, 15mins
<krit> nickScribe: krit
<krit> scribeNick: krit
Revised text layout proposal
heycam: Wanted to reduce the amount tha I presented in Hamburg
<ed> [17]http://people.mozilla.org/~cmccormack/temp/text.pdf
[17] http://people.mozilla.org/~cmccormack/temp/text.pdf
heycam: I want to give the proposals and let people say yes or
no
... one: make it easier to integrate text layout
... text is chucked on abs. pos. at the moment
... each chuck is independent for shaping
... each chunk almost a different text element
... (has presentation on slides)
<ChrisL> relevant CSS work - line layout module
[18]http://dev.w3.org/csswg/css3-linebox/
[18] http://dev.w3.org/csswg/css3-linebox/
heycam: chunking affects how ordering happens, make it more
difficult to reuse text layout
... text elements should be blocks and child elements as spans
... chunks won't stop shaping accross elements
... absolute pos. happens once you got text layout
<ChrisL> also writing modes module
[19]http://dev.w3.org/csswg/css3-writing-modes/
[19] http://dev.w3.org/csswg/css3-writing-modes/
heycam: SVG allows specifying it by each glyph at the moment
AS what happens when you have liguaritures
heycam: there are rules in the spec how to apply chars into a
glyph
... and how to ignore
... We still need to solve the char to glyph mapping before
applying chunks
... evrything should happen across a text element as a whole
... what happens if you specify some pos. but other glyphs
don't have a pos?
... I think we should specify that glyphs without pos should be
relative positioned to previous glyph
fi n a l exampl
fi ligurature
x="100 1550 200"
fi 100
n 150
a 200
sorry wrong
fi 100
n 200
a = 212
l = 224
AS: luguature should break in roman text
Cyril: I miss the explaination why 150 is not used
heycam: that is what spec says currecntly, skip it
<Tav> telephone?
<ChrisL> we need to allow the flexibility of per-font defaults
for discretionary ligatures
<ChrisL> note that this changed recently in css3 fonts
no
heycam: I think it might make sense
ChrisL: don't disallow positioning ligatures
heycam: what is the default value?
ChrisL: do what the font says
... we agreed not to overwrite it
... or switch them of
... svg says, if chars have a pos, glyphs shouldn't ligatures
heycam: if more than one pos, is specified you get behavior
questional ligatures won't be formed
ChrisL: should say may not formed, dependent what the font says
AS: it is up to the font
... I would not expect to form ligatures, but think ChrisL is
right. It depends on the font
heycam: do the CSS layout first
... for the x positions you can not really say how it affects
the font
<ChrisL> see
[20]http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-
prop
[20] http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
AS: right, so you can't rely on the ligature forming
... We shouldn't let it to the font to decide
<ChrisL> Initial: normal
<ChrisL> A value of �normal� implies that the defaults set by
the font are used.
ChrisL: we have to see what the font syas
... initial value is normal - do what the font says
heycam: pos should not influence if ligatures should be formed
ChrisL: AS: agree
... It gives you more flexibiity
heycam: you can't know as an author which chars get a glyph
... after positioning anchoring
... I won't change how anchoring worsk
... the current behavior stays, fi and nal get anchored
... at 100 and 200
ed: end anchoring might be difficult
... basically wondering what happens
heycam: text-anchor is end
... you got 2 chunks
... first chung single glyph
... you should look at all glyphs within a chunk, and look at
the very right or left chunk (dependent on ltr) and shift it
from there
<ed> <text x="100 200" text-anchor="end">ABCDE</text> (and the
same with BIDI)
heycam: ltr text
... right edge of A would be 100, BCD on its's left Eat 200
ed: browsers don't do the same think
heycam: I think the spec is clear about that
ed: what if text was rtl
heycam: you would have the left edge of the A at 200
... you look at the left edge of all glyphs
... A is on the most left
... x should give you exactly the anchor position
Cyril: for my understanding: ltr example
... step one apply CSS layout?
heycam: yes
... lets say fi is a ligature
... then the described behavior is what UAs are doing
... in simple cases it gives you same results
... I show more complicated cases
<text x="300 100">1nab</text>
heycam: 1. perfm css layout and find glyph pos
... n 1 a b
... 20,10,20,32
ChrisL: what you show is the backing store \
heycam: mark up is visual order
<ChrisL> alef and bet are the two letters, btw - see
[21]http://en.wikipedia.org/wiki/Hebrew_alphabet
[21] http://en.wikipedia.org/wiki/Hebrew_alphabet
heycam: normal position
n and 1 are hebrew
heycam: 2. preform CSS layout and find glyph pos
... n is at 200
... 1 is at 100
... a at 110
... b at 122
... a and b calculated according to pref pos
... 1 ab n
... old behavior 1ab n
... I want to change SVG behvaior
AS: 1 and n are rtl
... ab would be pos to the right of n
heycam: I think my proposal makes it possible just to look at
last char in memory
Cyril: english hebrew english
... ——> <—— ------>
... english he___brew english
... don't want to have second english word pos between hebrew
chunks
krit: I think positioning of glyphs is stupid
... we should deprecate it
heycam: well, it is complicated
... at least my proposal is simple to implement
... look from left to right, shift all position
<cabanier> slide deck:
[22]http://people.mozilla.org/~cmccormack/temp/text.pdf
[22] http://people.mozilla.org/~cmccormack/temp/text.pdf
heycam: Opera renders the example correctly according to the
current spec
krit: can we deprecate it?
heycam: yes
... but we need to specify how the deprecated feature is
supposed to work
krit: :P
heycam: have no strong feeling disabling anchoring all together
... propably not important
ChrisL: you have a backing store of glyphs and order them in
rendering order
... where does text-anchor: none go
<ChrisL> the slides are confusing the source display and the
backing store order - slides could be improved for clarity
there
heycam: have to check anchoring: none, but I think it is an
unimportant case
... undefined behavior in the spec t the moment:
<textPath>…</textPath>TextAfterTextPath
... where should it ogo?
... the bottom left of the text path should be relevant for
positioning text after textpath
... we should relax some restictions and allow x,y on textpath
... it just translates the content by transforming the space of
the text path
... we should also allow textpath in tspan
... summary, di what CSS is doing and apply SVG on top of it
shepazu: Can we have a resolution to make textPath element as
top level element (not surrounded by text element)?
general agreement to do so
RESOLUTION: textPath must not surrounded by text element
anymore.
<ed> [23]https://svgwg.org/svg2-draft/text.html#WhiteSpace
[23] https://svgwg.org/svg2-draft/text.html#WhiteSpace
ChrisL: I edited the section about white space handling
s/RESOLUTION: textPath not needed to be surrounded by text
element anymore./RESOLUTION: textPath not needed to be
surrounded by text element anymore.
Cyril: I think I am fine with the proposal
... but am concerned about the complexity of the basic thing
... Is it still from the same complexity as before?
heycam: depends on you implementation of the text rendering
... I don't think that you need to implement all the CSS now
... it is quite unprecise in some cases anyway
<ChrisL> it is the linebox and writing-modes and text modules
of CSS3
<ChrisL> see [24]http://dev.w3.org/csswg/ for links to those
[24] http://dev.w3.org/csswg/
heycam: you don't have to worry about the whole CSS box model.
And the CSS text layout isn't much greater than it is currently
krit: CSS is a requirement anyway
Cyril: I am thinking about the cost to implement it
ChrisL: It does things for browsers easier, but for sure more
complicated fot viewers without CSS engine
heycam: I can put current proposal into the spec and ask if it
makes sense.
... I tried to make it simple
... I think it is easy to implement it
... I can ask Mozilla people as well
RESOLUTION: Add Camerons proposal to spec and ask for wider
feedback
white spaces edits in SVG
<ChrisL> [25]https://svgwg.org/svg2-draft/text.html#WhiteSpace
[25] https://svgwg.org/svg2-draft/text.html#WhiteSpace
ChrisL: previously whitespace was notgood and complicated
... we removed tests from test suite
... I kept it in
... for legacy
... white space handling is using whitespece-property now
... added it to the spec
... added a third section for old and new whitespaces
... and how to do both
... I felt it needs to be adressed
heycam: not hane any XML white space behavior and use property
to select whitespace behavior
... there are still differences
... but should be mostly the same, inore differences and switch
over to white-space: normal and pre
... I have implemented it using a UI style sheet rule
shepazu: we are not talking about word breaking
heycam: ChrisL: yes we are
s/word breaking/collapsing/ ?
ChrisL: I think we want pre-wrap
heycam: CSS people already splitting out whit space collapsing
... If white space is normal I would like to wrap if the width
attribute is specified on the text element
... width attribute is new for text
TabAtkins_: how far do we want to go? We want to have <p> in
SVG anyway
krit: use cases might be different
ChrisL: that is right
[26]http://dev.w3.org/csswg/css3-text/#white-space
[26] http://dev.w3.org/csswg/css3-text/#white-space
<ChrisL>
[27]http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity
[27] http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity
ChrisL: it is just using space collapsing
... I think we agree that we want to remove things from the XML
ns.
<scribe> ACTION: ChrisL to work out things on removing XML ns
stuff on text and figure things out with the CSS WG [recorded
in [28]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
<trackbot> Created ACTION-3323 - Work out things on removing
XML ns stuff on text and figure things out with the CSS WG [on
Chris Lilley - due 2012-07-31].
<ChrisL> action-3323?
<trackbot> ACTION-3323 -- Chris Lilley to work out things on
removing XML ns stuff on text and figure things out with the
CSS WG -- due 2012-07-31 -- OPEN
<trackbot>
[29]http://www.w3.org/Graphics/SVG/WG/track/actions/3323
[29] http://www.w3.org/Graphics/SVG/WG/track/actions/3323
<ed> -- 15 min break --
<cabanier> scribenick: cabanier
<ChrisL> scribenick: ChrisL
<scribe> scribenick: cabanier
<ed>
[30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
ace_reorganization
[30]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
SVG in Web IDL
CM: I propose to redo the SVG idl
[31]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
ace_reorganization
[31]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
…turn "stylable", "locatable" and "transformable" in actual
element
…SVGtransformable is inherited the most
WebIDL doesn't support multiple inheritance
…there is nothing too contraversial
…I do propose to get of the SVG namespace. move away from XML
lang
…there is only a couple of elements that you can't use the
properties on
…if you use xml lang on animate, it's not going to have any
effect
TA: it negotiates fonts.
…for different languages
BB: ElementTimeControl
will it disappear all together?
CM: yes
BB: this is how I test for SMIL support. We might break content
if we remove interfaces
… gecko and webkit support it. Opera doesn't
CM: I can leave it in.
BB: not sure if there's content that relies on it
... I can change my content
CC: in some case you remove multiple inheritance by merging. In
others they implement. I don't understand how you made the
decision
CM: take SVGFitToViewBox. SVGSVGElement needs it and a couple
of others.
…SVGSVGElement we want to be able to transform but not
SVGMarker
CC: the solution to multiple inheritance
DS: why not multiple inheritance?
CM: because JavaScript doesn't support it
…there is a difference between 'implements' and 'inherits'
… implements is a new copy of the function while inherits is
the same
… the reason SVGGraphicsElement and SVGDefinitionElement are
introduced because it's a good place to hang the mixed in
interface instead of the more specific
from the spec: "Having these two interfaces gives us a place to
mix in other common interfaces (like SVGTests) without having
to do it on each sub-interface."
… this is how we might reorganize the interfaces
… Jen, don't you use WebIDL directly
J: not sure about that
CM: any questions?
All: no
resolution: we will adopt Cameron's proposal for Proposals/IDL
interface reorganization
CM: let's move SVGStylable up to the SVGElement
All: agreed
BB: so get rid of stylable element?
all: yes
BB: that's great
resolution: we will get rid of SVGStylableElement
<scribe> ACTION: Cameron to do all this interface stuff
(Proposals/IDL interface reorganization) [recorded in
[32]http://www.w3.org/2012/07/24-svg-minutes.html#action02]
<trackbot> Created ACTION-3324 - Do all this interface stuff
(Proposals/IDL interface reorganization) [on Cameron McCormack
- due 2012-07-31].
CM: can we get rid of externalresourcesrequired?
all: what's it for?
BB: it should line up with DOMContentLoaded
all: yes
CL: people wanted that if one resource doesn't load, nothing
should load
CC: externalresourcesrequired was more granular since it worked
per group and we especially helpful for fonts
… but I don't think anyone implements or use it
DS/ED: we believe that is true
ED: Opera implements it, but eRR isn't used much
DS: are there cases where this is useful?
BB: if that's true, we should do it for HTML as well.
resolution: remove ExternalResourcesRequired from the spec
CM: That's all for the IDL talk
BB does a demo of an animation application written in SVG
BB: having viewbox as a property would be very helpful in
conjunction with media queries
CM: is viewbox the CSS name?
css syntax:
svg { viewbox: 0 0 240px 240px; }
<ed> ick, why the units?
<ChrisL> because CSS
CM: does it make sense to non-svg?
DS: such as iframe
<ChrisL> can the units be optional?
TA: yes, just iframe establishes a viewport
<ed> if we allow units, then we should allow units in the
viewbox attribute too, but sure, that follows from making it a
presentation attribute I guess...
<heycam> ed, agreed
fixed CSS syntax: svg { view-box: 0 0 240px 240px; }
<ed> calc too?
<heycam> of course
<ed> people are probably already writing "viewbox" in
html-with-inline-svg, and "viewBox" in svg... and then
"view-box"?
DS: this seems to be a very nice feature in combination with
auto scaling
…there is a question with auto
… what happens when things move around? content will start
growing/shrinking
DirkS: then you should absolute coordinates
…should we apply to HTML as well?
TA: HTML and iframe create a viewbox
resolution: convert viewbox to a property and give it an 'auto'
characteristic
<scribe> ACTION: Tab Atkins to take HTML and Iframe view-box
property to the CSS working group [recorded in
[33]http://www.w3.org/2012/07/24-svg-minutes.html#action03]
<trackbot> Created ACTION-3325 - Atkins to take HTML and Iframe
view-box property to the CSS working group [on Tab Atkins Jr. -
due 2012-07-31].
<scribe> ACTION: brian birtles to write up a proposal for
view-box property for SVG [recorded in
[34]http://www.w3.org/2012/07/24-svg-minutes.html#action04]
<trackbot> Created ACTION-3326 - Birtles to write up a proposal
for view-box property for SVG [on Brian Birtles - due
2012-07-31].
Quick question about mask: <funciri> auto
BB: in the case you have a mask property, let the mask decide
what it is: luminance or alpha
<birtles> current syntax proposal: [ <funciri> | child |
element(<compound-selector>) | none ] [ luminance | alpha |
auto ]?
… auto means do what the mask says
… but if you point it to an image, what should it be?
<ChrisL> you need to be able to choose either
RC: it seems that you should get luminance
DirkS: I think it should be alpha
CL: people that want alpha point to a grayscale. I have a
feeling that it should be alpha
<ChrisL> alpha alpha alpha, ra ra ra
resolution: alpha is chosen when selection 'auto' is set and
mask is pointed to an image
... the property alpha/luminosity wins when pointing to a mask
element
Summary of Action Items
[NEW] ACTION: brian birtles to write up a proposal for view-box
property for SVG [recorded in
[35]http://www.w3.org/2012/07/24-svg-minutes.html#action04]
[NEW] ACTION: Cameron to do all this interface stuff
(Proposals/IDL interface reorganization) [recorded in
[36]http://www.w3.org/2012/07/24-svg-minutes.html#action02]
[NEW] ACTION: ChrisL to work out things on removing XML ns
stuff on text and figure things out with the CSS WG [recorded
in [37]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
[NEW] ACTION: Tab Atkins to take HTML and Iframe view-box
property to the CSS working group [recorded in
[38]http://www.w3.org/2012/07/24-svg-minutes.html#action03]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version
1.136 ([40]CVS log)
$Date: 2012/07/24 19:02:03 $
__________________________________________________________
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[40] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [41]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/pint/paint/
Succeeded: s/this markers/these markers/
Succeeded: s/specify relative/specify a clipping path relative/
Succeeded: s/pth/path/
Succeeded: s/DS: so/DirkS: so/
Succeeded: s/questions/question/
Succeeded: s/would be 200/would be 100/
Succeeded: s/at 100/at 200/
Succeeded: s/middle/none/
Succeeded: s/surouned/surrounded/
Succeeded: s/edded/edited/
FAILED: s/RESOLUTION: textPath must not surouned by text element anymore
./RESOLUTION: textPath not needed to be surrounded by text element anymo
re./
Succeeded: s/RESOLUTION: textPath must not surouned by text element anym
ore./RESOLUTION: textPath not needed to be surrounded by text element an
ymore./
Succeeded: s/coast/cost/
WARNING: Bad s/// command: s/word breaking/collapsing/ ?
Succeeded: s/it doesn't see much use/Opera implements it, but eRR isn't
used much/
Found ScribeNick: birtles
Found ScribeNick: ChrisL
Found ScribeNick: birtles
Found ScribeNick: krit
Found ScribeNick: cabanier
WARNING: No scribe lines found matching ScribeNick pattern: <cabanier> .
..
Found ScribeNick: ChrisL
Found ScribeNick: cabanier
Inferring Scribes: birtles, ChrisL, krit, cabanier
Scribes: birtles, ChrisL, krit, cabanier
ScribeNicks: birtles, ChrisL, krit, cabanier
WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa Tav mdyck TimMills
New list: +1.206.675.aaaa Tav
Default Present: +1.206.675.aaaa, Tav
Present: +1.206.675.aaaa Tav
WARNING: Fewer than 3 people found for Present list!
Agenda: [42]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_201
2/Agenda#Agenda
Found Date: 24 Jul 2012
Guessing minutes URL: [43]http://www.w3.org/2012/07/24-svg-minutes.html
People with action items: atkins birtles brian cameron chrisl tab
[42]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
[43] http://www.w3.org/2012/07/24-svg-minutes.html
End of [44]scribe.perl diagnostic output]
[44] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 25 July 2012 13:47:51 UTC