See also: IRC log
<trackbot> Date: 26 September 2009
<heycam> Meeting: Mountain View F2F 2009 Day 1
<scribe> Scribe: Anthony
<scribe> ScribeNick: fat_tony
DS: What if you have a completely different thing like script
CM: That's the example that Erik gave
CL: In particular the way the script being handled is weird
DS: What about CSS?
CL: It has parsing rules that allows you to skip over it
... [reads section of spec out]
DS: That's fine looks good to me
ED: I'm concerned that's going to break things in the future
... because it looks like we are planning to change SVG Fonts anyway
... we also discussed how things inherit into it
... I guess we haven't decided on how it is going to work
DS: You did talk about what sorts of changes you want to make?
JW: For restricting content what would we restrict?
CL: Unless we restrict it to zero
... the errata I just stuck in doesn't change anything
DS: Chris's change just clarifies the spec
... it's not changing anything
... if we want to change anything in 2.0
... then that's fine
ED: Just sounds weird to me
... but if that's the way it's suppose to work
... it's not going to change what we do
CL: I don't see how it's different from a bunch of <use> elements
... both of them say they create anonymous shadow trees
ED: The wording for the way it behaves like a cloning thing is not good
... I agree with what ROC says
JW: Does batik render anything other than the 'd' attribute
CM: Yes
JW: Inheritance thing?
CM: Not sure
JW: Say I have two <tspans> in a text thing that's using a font
... those two <tspans> might have different styling
... and the same glyph
... if you do shadow trees then you need to do different styling
ED: I was thinking about a font that could be made on both old and new user agents
... in some situations there might be a case where you want to provide a completely different glyph
... I can think of other ways of doing it
<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Fonts
ED: So these are the properties that would inherit by default?
JW: Unless you tried to stop them
CM: So is this the list of all inherited properties minus the font ones?
JW: I wasn't trying to create a complete list though
<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Fonts_Inheritance
JW: the font element should be self contained
... if I copy and paste a font that has a gradient
... reference, then it will break
CL: But how is that different from a group
JW: I think of fonts as more self contained things
<ChrisL> They can be coded like that. Its authoring advice
DS: Unless there is a optimisation advantage
JW: It would be more overhead to restrict it
ED: So I'm not objecting to the change anymore
CL: I propose removing within an SVG document fragment part
<ed> xlink:href for tref says:
<ed> A URI reference to an element/fragment within an SVG document fragment whose character data content shall be used as character data for this 'tref' element.
<ed> change to:
<ed> A URI reference to an element whose character data content shall be used as character data for this 'tref' element.
RESOLUTION: We agree to remove the restriction of tref pointing to only an SVG document fragment
ED: So I put fill and stroke-width with on a glyph and it didn't affect the glyph
... I guess it depends what type of element the glyph is
CM: I don't think it's good to treat it differently
<ed> if fill and stroke-width is put on a <text> element then it does affect the rendered text
<ed> so the same for svg fonts as for any other type of font
CM: But does it do it in the coordinate system of the glyph?
ED: I don't think so
<ed> the inheritance rules are slightly different for 'd' and child content on <glyph>
<ed> for 'd' attributes particularly: "The resulting, transformed path specification is rendered as if it were a 'path' element, using the styling properties that apply to the characters which correspond to the given glyph, and ignoring any styling properties specified on the 'font' element or the 'glyph' element."