See also: IRC log
<trackbot> Date: 27 June 2013
<richardschwerdtfeger> we meeting?
<scribe> scribenick: cabanier
tav: we agreed in tokyo that we can have multiple paints
… I started on that and had a couple of questions
… the old text said that if the paint server was invalid and there was no fallback, the document was in error
shepazu: that has changed for svg2
Tav: if the final paint server is invalid, is the document in error
… look at svg tiny 1.2
… I remember that we addressed that in that version. just look at the wording
ed: yes. there's no state that's an error
Tav: ok, so we'll just copy that text
… and I assume that you wouldn't fall back on the lacuna value
… suppose you have 3 things on top of each other and if the first 2 are invalid
shepazu: you'd display the third value. If that's invalid too, you fall back to the lacuna value
… so there's 2 case:
… one if where the resource if pointing to nothing
… the other if there's something wrong inside that resource
ed: svg1.2 states what should happen so you could borrow that
shepazu: what if you point to an existing reference but it has an invalid value. do you still use the second
Tav: no, you still paint all three. only the last one has a fallback
… if there's a problem with one, you don't paint it. if there's a problem with the last one, you paint the fallback value
… look at example 2
shepazu: that seems arbitrary but it seems like a reasonable one
Tav: this is what we decided in Tokyo
… the second question: How should 'child' behave with allowing multiple paint
… you can reference a child of an element as a paint server
… but what if you have 3 children. right now it says take the last child, but in the case of multiple paints, you want them all
ed: you have a child selector
Tav: what do you do with the keyword child
<ed> [ <funciri> | child | <child-selector> ]
ed: you use iri, child or a child
... this is from the current spec
… so if you want a specific child you use the selecor
Tav: but what if you want al three
shepazu: use a funciri and point to it
… the child is just a convenience method
scribe: so use a funciri
Tav: that sounds reasonable
… can you give me an example?
Tav: an example will be really good
ed: a class selector would work.
ed: you have to put all the things in
Tav: ok. I will add a couple more example
ed: most common will be nth-child
… at least, that's my guess
shepazu: can a child selector select more than one value
… if I have 3, but want to select 2, can I do that?
ed: yes, look at the example I posted. it can be a comma separated list
… but it's not completely clear in the spec
shepazu: we should fix that in the spec
… is this something from css, or svg?
ed: it's from svg but links to css
shepazu: who defined the syntax?
… the individual?
ed: I don't know
<TabAtkins> Brian, I think? With help from me?
Tav: I find it strange how it pulls in CSS
krit: css masking is using this and it just selects direct children
ed: does anyone have a solution to the problem? should we ask it on the mailing list?
shepazu: yes, we should find out who put it in and have them add more examples
krit: yes, it should be better specified
ed: tav, can you write up an email?
krit: that would be great
ed: quick question about the example
… that tav put in the spec.
<ed> fill="url(#MyHatch1, #MyHatch2 powderblue)"
… it uses syntax like above
… is that correct syntax?
Tav: I will fix that
… I just pasted
Tav: it only apply to regular text for now
… we discussed this but I don't remember
… if we concluded anything
ed: opera just treated it on the text element but it works on a text path
… because we wrap the text-path
krit: what happens with overflow in text
… we discussed this before and decided that it was difficult to definee
ed: we'd have to go back and special case it
… so it basically worked but it's possible that it wasn't great in all cases
… you layout the text on a straight line first and then map it to a path
… at least that's how opera did it
… it's not ideal in all cases. for instance if it's not one line
Tav: that's what you'd want
… maybe the order of the agenda items is reversed :-)
… the next item talks about what width means
Tav: width defines the width of a single line of text
… but now it defines the width of an area
… and you get overflow if the text wraps of the bottom
… if you have only have width the text keeps wrapping
shepazu: that's correct
Tav: this is natural way of
getting a wrapping context
... the other problem is the case of vertical text
… the width doesn't apply in the case of vertical text
shepazu: the directionality of the flow of the text is not dependant on width/height
… it also depends on the text direction property
… top to bottom right to left, if I specified a width it wouldn't have the desired effect
scribe: I specified width and height, it would start clipping the width
nikos: is it feasible to do this on the flow of the text
shepazu: yes , you'd have to do that
…. the behavior is dependant on the direction of the text\
… you have to know the flow of the text
… it would be worth to talk about that
… and hopefully CSS already covers this
Tav: css redefines left to right, top to bottom
… they are redefining the text flow
… so width should define wrapping context and not overflow
shepazu: we need to talk to the css wg
Tav: what does this have to do with the CSS?
…. we don't rely on CSS
… to define the wrapping context using width and height does not depend on CSS
shepazu: that is not my understanding. My proposal is all about CSS
Tav: no, once you have a wrapping context you fill it using CSS
shepazu: I don't see how it's different. a div would cause wrapping
Tav: no, our width and height create a wrapping context
… you said we have to check with CSS
shepazu: I want to make sure that we're all on the same page
… with overflow etc
Tav: I agree with that.
… using width and height didn't seem like we need their approval
… should we resolve on that?
<TabAtkins> Yes, please.
resolution: we will add width and height for text wrapping on the text element using the css wrapping context
<scribe> ACTION: tav to make the text wrapping changes to the spec [recorded in http://www.w3.org/2013/06/27-svg-minutes.html#action01]
<trackbot> Created ACTION-3509 - Make the text wrapping changes to the spec [on Tavmjong Bah - due 2013-07-04].
<nikos> readonly attribute number tabIndex;
shepazu: let's talk about making svg an ISO spec
… there's reasons that we want it
… because of competition with other formats
… and because some people can't use it in governments unless it's in ISO
… and because as a method to promote the stability of the format
krit: where is the problem?
shepazu: we didn't have this minuted
… and Rich has concern that we should do SVG 2 instead of 1.1
krit: I thought we wanted to do 2.0
nikos: I remember that too
Tav: yes, that is true
shepazu: That's not my recollection
… we wanted SVG 1.1 second edition
… since it was suitable for ISO submission
… my stance is that it does no harm to have 1.1 as an ISO spec
… it will take little effort (unless there are objections)
… and will only take 3 months and follow up in 2014
… when svg2.0 has recommendation
… and make that an iso spec as well
… it will help people that want to use SVG 1.1 for government use
…. and they can then upgrade to SVG2.0
… who has objections?
richardschwerdtfeger: so, you will be releasing 1.1 and 2.0 a year later? that will drive people crazy?
…. do you want people to write 1.1 or use 2.0?
Tav: what does that drive people crazy?
richardschwerdtfeger: if you get people to gear up for 1.1 and then switch a year later. it takes a lot of time and money to switch over
… 3 to 4 years is btter
Tav: one year for svg 2 is very optimistic
shepazu: yes, it's not just editing the spec but also driving implementations
… we run the risk that we talk at least 2 years
richardschwerdtfeger: IE has problems even with the 1.1 stuff
… such as animations
shepazu: they don't want to implement certain 1.1 features
richardschwerdtfeger: more support for things in 2.0?
shepazu: I think there's still an open question
… we might drop features in 2.0 if they're not implemented in other browsers
… which could include SMIL and SVG fonts
<krit> Am in favor for SVG 1.1 and update to 2 later
… but we have no consensus on that
ed: I see no harm in submitting 1.1 and 2.0 later on. SVG 1.1 is stable.
shepazu: creating an iso spec could be ready around october 2013
richardschwerdtfeger: why do you think it needs to be an ISO spec
shepazu: I've talked to people that have told me this
richardschwerdtfeger: the other issue is that SVG does not offer accessibility
shepazu: that's not quite true.
… there's nothing that support accessible bar chart
richardschwerdtfeger: every web accessible technology has to be keyboard accessible
shepazu: that's not quite true. you can put titles and descriptions on everything
richardschwerdtfeger: that's not keyboard accessible
shepazu: we should bring this up in 2 weeks
Tav: if there's no work for us, then we should do an ISO spec now
shepazu: let's do a poll!
richardschwerdtfeger: no. wait for 2.0
… but I'd need an internal discussion
… but I am concerned about accessibilty
shepazu: the competing technologies have the same issues
… are PDF images keyboard accessube?
ed: let's wait 2 weeks to get to resolution
richardschwerdtfeger: Doug can you write me a note why w3c wants this and how it could be helpful
shepazu: yes, I will try that
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I agree that 2.0 will be ready soon./I see no harm in submitting 1.1 and 2.0 later on. SVG 1.1 is stable./ Found ScribeNick: cabanier Inferring Scribes: cabanier Default Present: ed, Doug_Schepers, +126.96.36.199.aaaa, Tav, +61.2.980.5.aabb, nikos, cabanier, +1.661.748.aacc, Rich_Schwerdtfeger, +1.415.832.aadd, krit Present: ed Doug_Schepers +188.8.131.52.aaaa Tav +61.2.980.5.aabb nikos cabanier +1.661.748.aacc Rich_Schwerdtfeger +1.415.832.aadd krit Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0158.html Found Date: 27 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/27-svg-minutes.html People with action items: tav WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]