SVG Working Group Teleconference -- 27 Jun 2013

<trackbot> Date: 27 June 2013

scribenick cabanier

<richardschwerdtfeger> we meeting?

<scribe> scribenick: cabanier

<richardschwerdtfeger> k

Questions concerning multiple paints

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

shepazu: no.

… 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

<ed> http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint

… 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

<Tav> https://svgwg.org/svg2-draft/painting.html

… look at example 2

<ed> https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

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 selector
... 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?

<ed> https://svgwg.org/svg2-draft/types.html#DataTypeChildSelector

Tav: an example will be really good

ed: a class selector would work.

<ed> fill=".fooBarClass"

<ed> fill="select(.fooBarClass)"

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

<ed> https://svgwg.org/svg2-draft/types.html#DataTypeChildSelector

… 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

Tav: OK

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-image

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

Should text-overflow apply to text-on-path?

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

<ed> http://dahlström.net/svg/css/text-overflow-ellipsis.svg

… 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

SVG2 Text wrapping - new definition of 'width'?

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

shepazu: yes

… should we resolve on that?

ed: yes

<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> https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement

<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

making svg an ISO spec

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?

richardschwerdtfeger: yes

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

- DRAFT -

SVG Working Group Teleconference

27 Jun 2013

Attendees

Contents

Questions concerning multiple paints

Should text-overflow apply to text-on-path?

SVG2 Text wrapping - new definition of 'width'?

making svg an ISO spec

Summary of Action Items

Scribe.perl diagnostic output