SVG Meeting minutes 2013/06/27

http://www.w3.org/2013/06/27-svg-minutes.html

                    SVG Working Group Teleconference

27 Jun 2013

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0158.html

   See also: [3]IRC log

      [3] http://www.w3.org/2013/06/27-svg-irc

Attendees

   Present
          ed, Doug_Schepers, +33.9.53.77.aaaa, Tav,
          +61.2.980.5.aabb, nikos, cabanier, +1.661.748.aacc,
          Rich_Schwerdtfeger, +1.415.832.aadd, krit

   Regrets
   Chair
          ed

   Scribe
          cabanier

Contents

     * [4]Topics
         1. [5]Questions concerning multiple paints
         2. [6]Should text-overflow apply to text-on-path?
         3. [7]SVG2 Text wrapping - new definition of 'width'?
         4. [8]making svg an ISO spec
     * [9]Summary of Action Items
     __________________________________________________________

   <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>
   [10]http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPain
   t

     [10] 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> [11]https://svgwg.org/svg2-draft/painting.html

     [11] https://svgwg.org/svg2-draft/painting.html

   … look at example 2

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

     [12] 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>
   [13]https://svgwg.org/svg2-draft/types.html#DataTypeChildSelect
   or

     [13] 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>
   [14]https://svgwg.org/svg2-draft/types.html#DataTypeChildSelect
   or

     [14] 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>
   [15]https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
   #the-mask-image

     [15] 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>
   [16]http://dahlstrφm.net/svg/css/text-overflow-ellipsis.svg

     [16] http://dahlstr/

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

     [18] 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

Summary of Action Items

   [NEW] ACTION: tav to make the text wrapping changes to the spec
   [recorded in
   [19]http://www.w3.org/2013/06/27-svg-minutes.html#action01]

Received on Thursday, 27 June 2013 21:58:34 UTC