Minutes, 7 May 2015 SVG WG telcon

Formatted minutes at
http://www.w3.org/2015/05/07-svg-minutes.html



SVG Working Group Teleconference

07 May 2015

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2015May/0003.html

   See also: [3]IRC log

      [3] http://www.w3.org/2015/05/07-svg-irc

Attendees

   Present
   Regrets
          Brian, Doug

   Chair
          Cameron

   Scribe
          nikos_, Nikos

Contents

     * [4]Topics
         1. [5]HTML parser lowercasing SVG names
         2. [6]Continued SVG 2 open issue discussion
         3. [7]Linking chapter issues
         4. [8]Linking chapter - issue 5
         5. [9]Linking chapter - issue 7
     * [10]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 07 May 2015

   <shepazu> heycam, can't make the telcon today, but +1 on making
   SVG case-insensitive
   [11]https://lists.w3.org/Archives/Public/www-svg/2015May/0010.h
   tml

     [11] https://lists.w3.org/Archives/Public/www-svg/2015May/0010.html

   <shepazu> maybe we could even define a lightweight
   syntax/parser for it

   <heycam> shepazu, thanks. can you respond on
   [12]https://www.w3.org/2002/09/wbs/19480/Linkoping2015 when you
   get a chance.

     [12] https://www.w3.org/2002/09/wbs/19480/Linkoping2015

   <shepazu> heycam, will do

   <shepazu> heycam, probably can't make it :(

   <TabAtkins> I can call in. One sec.

   <scribe> scribe: nikos_

   <scribe> scribe: Nikos

   <scribe> scribenick: nikos_

HTML parser lowercasing SVG names

   TabAtkins: dealing with matching SVG elements and attributes
   case sensitively in selectors
   ... is annoying in our code and we do it wrong in blink
   ... we currently always lowercsae it
   ... which makes it impossible to select an svg element that
   uses camel case
   ... had someone try to plumb the code - works but it's nasty
   ... instead we committed a patch that always matches case
   insensitively
   ... not sure of the exact details how that works
   ... so can we make that official in the spec?
   ... Doug added that we just always lowercase
   ... at least when included in HTML

   heycam: what does the spec say about query selector?

   TabAtkins: selectors by default will be case sensitive but
   individual host languages can specify that matching should be
   done case insensitively
   ... HTML does this
   ... SVG does not currently

   heycam: what is it that makes general style sheets work to
   match mixed case names?

   TabAtkins: most aren't camel case so they work - the few that
   are don't have many properties that can be played with
   ... it's only that it can't select by tag name or attribute
   name - class works fine

   heycam: so in Blink yo ucouldn't select clipPath element by
   name?

   TabAtkins: yes

   heycam: so the patch that landed implements what you're
   suggesting?

   TabAtkins: I think so - everything matches case insensitively
   in SVG

   heycam: any idea what other implementations do?

   TabAtkins: I believe FF matches correctly
   ... not sure how they handle if you do a selector with an
   upercase D, how it matches a HTML element with a lower case d

   Tav: so this only affects HTML and not xHTML?

   TabAtkins: Either way is possible
   ... we could do it just for SVG in HTML
   ... or for SVG ENTIRELY

   heycam: I would like there to be a way to select these elements
   in XML

   shepazu: we talked in the past about making a lightweight
   serialisation/parsing thing for svg

   <TabAtkins> XML5

   shepazu: dom based rather than syntax based

   <TabAtkins> annevk has worked on that for a while

   shepazu: HTML has all these rules for backwards compat - we
   wouldn't need to do all that sort of stuff because SVG has
   always been well formed
   ... is there any political will towards doing that as a general
   solution?

   TabAtkins: We could make that opt in
   ... stand alone SVGs need a doctype for example - and opt in to
   the HTML like parsing
   ... but a standard XML declaration would use a standard XML
   parser

   <TabAtkins> Like <!doctype svg>

   shepazu: I'm allergic to doctype
   ... recognise they're neccessary in HTML

   <ed_work> in theory a specialized svg parser mode could filter
   out/throw away all textnodes that don't apply, they seldom make
   sense for svg

   shepazu: but would prefer to avoid them for SVG

   AmeliaBR: HTML has two syntaxes, parsed as HTML or parsed as
   XML. I don't see anything wrong with doing the same thing for
   SVG - to say this can be parsed as an XML document or it can be
   parsed using an HTML or HTML like parser that is case
   insensitive
   ... but don't forget that it's not just HTML vs stand alone -
   there's other situations for SVG
   ... as long as we say which parser can be used
   ... and how it would filter down to other DOM methods - and
   whether it would create headaches with createElementNS, etc
   ... would we need two versions of that function?

   shepazu: we don't control a lot of xml pipeline stuff
   ... tools are often quite old
   ... think people will be resistant to changing parsing of these
   tools
   ... I'm not so interested in solving that use case - for them
   it will always be case sensitive
   ... I am interested in the DOM methods - which we control
   ... assuming browsers are on board
   ... we can say 'from now on, DOM methods are case insensitive'

   heycam: earlier you asked if the group is amenable to a HTML
   like parser for SVG
   ... I think we are - think we're at the point where someone
   needs to write down a proposal for how it would work
   ... would be happy to start small - selectors in general, etc
   ... think the general parsing issue will be a larger think to
   solve

   shepazu: I also want to make sure that authoring tools have a
   clear path forward with this
   ... specifically ones that are updated such as InkScape and
   Illustrator
   ... I propose that we accept this notion pending some sort of
   actionable spec and definition that we can agree on
   ... and find someone to take the action

   TabAtkins: yes, and I can take the action

   Tav: I want to make sure the XML part is maintained to some
   extent
   ... in InkScape we use a lot of namespaces

   TabAtkins: I expect it will be like HTML where we have the
   current syntax and the more permssive syntax

   heycam: I would like to resolve today how querySelector works
   in current documents

   TabAtkins: I propose: selectors in general are case insensitive
   for SVG elements, just like they are for HTML elements

   shepazu: agree

   <ed_work> +1

   shepazu: not just querySelector, but anything that uses
   selectors

   TabAtkins: I'll drive it forward

   RESOLUTION: selectors in general will match SVG attributes and
   elements case insensitively
   ... We will work on a method for parsing SVG documents using
   case insensitive syntax like HTML - with all this would entail

Continued SVG 2 open issue discussion

   heycam: last time we finished embedded content chapter
   discussions
   ... not sure which others needed discussion?

   [13]https://svgwg.org/svg2-draft/render.html#PaintingRasterImag
   es

     [13] https://svgwg.org/svg2-draft/render.html#PaintingRasterImages

   nikos: Not sure who added this issue - do people think there is
   something we should say with respect to animated bitmap images?
   Or can we drop the issue?

   heycam: does the HTML spec say what happens with animated
   raster images?
   ... if it mentions it at all that might give some ideas -
   otherwise could perhaps drop it
   ... maybe a requirement that we don't need to render the
   animation

   ed_work: I'm not sure we require running the animation (or if
   we require support for any image formats that are animated)

   <AmeliaBR> HTML text on the subject:
   [14]http://www.w3.org/TR/html5/rendering.html#images

     [14] http://www.w3.org/TR/html5/rendering.html#images

   heycam: I don't remember seeing it

   <AmeliaBR> "All animated images with the same absolute URL and
   the same image data are expected to be rendered synchronized to
   the same timeline as a group, with the timeline starting at the
   time of the most recent addition to the group."

   AmeliaBR: there's one sentence in HTML that says that if you
   have multiple copies of the same animated image then they
   should be synchronised
   ... I think anytime you add a copy you reset the
   synchronisation
   ... we could reference that and encourage the same behaviour

   but probably don't want to add additional rules regarding
   controlling timelines

   scribe: but we probably don't want that to be SVG specific

   heycam: agree we shouldn't have specific requirements
   ... so do we need to say anything in our spec?
   ... or is referencing HTML enough?

   AmeliaBR: we could just reference the HTML spec

   heycam: I'm assuming the sentence in the HTML spec is about
   html image elements
   ... there's a big section about how to handle image elments in
   html
   ... e.g. what happens to sizing, and if it has an alt attribute
   ... not sure how many requirements are applicable to svg

   Smailus: only concern I have is to clarify that raster content
   in SVG is treated the same as raster content in HTML
   ... it's different in current browsers
   ... we're having an issue with down sampling
   ... it's being done cheaply in SVG
   ... whereas in HTML we are getting a much higher quality result
   ... lines dissapear out of two colour TIFFs, etc

   heycam: I suspect the definition of image-rendering
   ... which should apply to HTML and SVG images
   ... should mean that the same things happen
   ... I would be fine saying here or in image-rendering, to say
   the intention is for the sampling should be the same between
   HTML and SVG

   <ed_work> require the same image formats to be supported too?

   <ed_work> (as in html)

   <scribe> ACTION: Nikos to look at definitions for image in HTML
   and see what applies to SVG as well - reference HTML spec from
   SVG where appropriate [recorded in
   [15]http://www.w3.org/2015/05/07-svg-minutes.html#action01]

   <trackbot> Created ACTION-3788 - Look at definitions for image
   in html and see what applies to svg as well - reference html
   spec from svg where appropriate [on Nikos Andronikos - due
   2015-05-14].

Linking chapter issues

   AmeliaBR: these have been lingering on the agenda for a while
   ... issue 2 isn't one of mine - we have informal definitions
   that should be moved to formal definitions - not sure who could
   talk about that one

   <AmeliaBR> [16]https://svgwg.org/svg2-draft/linking.html#issue2

     [16] https://svgwg.org/svg2-draft/linking.html#issue2

   ed_work: I don't mind taking the action - but would be happy if
   someone else could
   ... I think it's probably pretty clear what the terms mean

   botie:

   <botie> nikos_: sorry...

   BogdanBrinza_: would probably make sense for me to take hte
   action

   <scribe> ACTION: Bogdan to resolve ISSUE 2 in linking chapter
   [recorded in
   [17]http://www.w3.org/2015/05/07-svg-minutes.html#action02]

   <trackbot> Created ACTION-3789 - Resolve issue 2 in linking
   chapter [on Bogdan Brinza - due 2015-05-14].

   BogdanBrinza_: I'm not sure these chapters were reviewed - so
   we may have more to do

Linking chapter - issue 5

   <AmeliaBR> [18]https://svgwg.org/svg2-draft/linking.html#issue5

     [18] https://svgwg.org/svg2-draft/linking.html#issue5

   AmeliaBR: target media fragments have a way of saying whether
   units are pixels or percentages
   ... assume they map to viewbox units and viewbox w/h
   ... anyone have other ideas?

   heycam: I don't have any opinion
   ... but as part of last weeks action to look at how implemented
   media fragments are, maybe I should think about this at the
   same time
   ... I'll do testing as part of that

   <scribe> ACTION: Cameron to resolve issue 5 in linking chapter
   as part of work on other media fragment actions [recorded in
   [19]http://www.w3.org/2015/05/07-svg-minutes.html#action03]

   <trackbot> Created ACTION-3790 - Resolve issue 5 in linking
   chapter as part of work on other media fragment actions [on
   Cameron McCormack - due 2015-05-14].

   <heycam> [20]https://svgwg.org/svg2-draft/linking.html#issue7

     [20] https://svgwg.org/svg2-draft/linking.html#issue7

Linking chapter - issue 7

   AmeliaBR: we've got an option of setting a transform on an SVG
   view target fragment

   <AmeliaBR> [21]https://svgwg.org/svg2-draft/linking.html#issue7

     [21] https://svgwg.org/svg2-draft/linking.html#issue7

   AmeliaBR: and it's a bit complicated how this maps to CSS
   transforms
   ... currently browsers differ
   ... wrt transform origin on the svg
   ... no way to specify a different origin
   ... my question is: should we expand it to any possible css
   transform property?
   ... or should we keep it simple"?
   ... I lean to keeping it simple

   heycam: I feel like this syntax is a bit of a niche feature -
   and not too keen on expanding with transform origin or that
   sort of thing

   AmeliaBR: so should we deprecate the idea of using
   transformations on an svg view?
   ... think your plan of what to do with parameters is a good way
   of solving generally, how to control the rendering from outside
   ... but we don't quite have that yet
   ... so not sure we should deprecate it yet
   ... I like that idea
   ... with a better syntax in future we might be able to get rid
   of this - but don't break it yet

   heycam: part of the issue is that different implementations use
   a different transform origin
   ... so that behaviour should be nailed down

   AmeliaBR: it's whether you treat the root svg as an element
   with a css layout box
   ... may have been fixed, but last I tested browsers had that
   behaviour

   heycam: have you written text? or can you?

   s/writtten text/written tests

   AmeliaBR: we'd be asking the CSS transform spec for a
   clarification - or we could add clarifications that 'the root
   element of an svg document is an element with a layout box for
   purposes of the css spec'

   heycam: transforms spec has something that says the value of
   transform origin is (0,0) for something that doesn't have a
   layout box

   AmeliaBR: that wording is so inline svg in html tranfsorms like
   any other css layout box
   ... but child content transforms like svg transforms

   heycam: then idea of clarifying sentence in our spec is good

   AmeliaBR: do we want resolution on transforms on root svg
   element?
   ... because that would change the behaviour of SVG on the
   canvas

   heycam: I want it to be what implementations do currently

   AmeliaBR: I'll come up with some text options and summary of
   behaviour
   ... for other issues I think we agree that view in a target
   fragment should behave the same as on the svg root element - we
   debated previously whether the transform should accumulate or
   replace the transform
   ... we tentatively resolved that it should accumulate
   ... and I started looking to see how much of a mess that would
   be

   heycam: is that captured by one of the issues here?

   AmeliaBR: issue 6
   ... not specifically, but it's related

   heycam: what's the next step there?

   <AmeliaBR>
   [22]https://lists.w3.org/Archives/Public/www-svg/2015Mar/0017.h
   tml

     [22] https://lists.w3.org/Archives/Public/www-svg/2015Mar/0017.html

   AmeliaBR: that's my list of test cases and current behaviour

   heycam: I'll need to read the email

   AmeliaBR: we can talk about this next week maybe
   ... my preference for 'whats the transform origin of the
   canvas'? Treat the root element as the layout box
   ... everyone except FF implements that
   ... maybe IE doesn't implement at all
   ... I would recommend any svg view transform replaces transform
   on the root element
   ... nobody quite implements that in a consistent way
   ... FF only replaces transform attribute, not transform style

   <ed_work> note that I have landed some patches a while back in
   blink that may have affected this (so, might be good to test in
   a canary build)

   heycam: no consistency might be good as we can choose best
   behaviour
   ... I'll read through the emails ready for next week

   AmeliaBR: there are some issues with escaping - I would like to
   rewrite this to be more consistent with browsers
   ... specifically that browsers should respect url escape
   notation
   ... but in many cases browsers let you treat spaces as spaces

   heycam: probably that section should just be informative

   <AmeliaBR> [23]https://svgwg.org/svg2-draft/linking.html#issue8

     [23] https://svgwg.org/svg2-draft/linking.html#issue8

   AmeliaBR: problem is browsers don't decode the url encoding in
   the target fragment - or at least only some do
   ... we can definitely remove where it says 'don't use spaces'
   ... think it makes sense t orequire them to decode the url
   encoding

   heycam: not sure about that - I want to do some reading
   ... I feel like at the time you're looking at the url here - in
   terms of parsing the view -

   <AmeliaBR> Can we get feedback from implementations? Anyone
   want to look in the code and see how it works?

   heycam: I agree that if we can turn this into a realistic
   informative statement about how to write things in the url so
   it's interpreted correctly, then I'm happy with that
   ... I can look into what FF is doing and get back to you

   AmeliaBR: I did have a test case
   ... I'll send it out again
   ... only other issue in that chapter, re viewTarget, Cam was
   going to follow up with CSS group
   ... it's issue 12

   [24]https://svgwg.org/svg2-draft/linking.html#issue12

     [24] https://svgwg.org/svg2-draft/linking.html#issue12

   <AmeliaBR>
   [25]https://svgwg.org/svg2-draft/linking.html#issue12

     [25] https://svgwg.org/svg2-draft/linking.html#issue12

   heycam: we can follow up linking issues next week and go
   through issues in the appendices

Summary of Action Items

   [NEW] ACTION: Bogdan to resolve ISSUE 2 in linking chapter
   [recorded in
   [26]http://www.w3.org/2015/05/07-svg-minutes.html#action02]
   [NEW] ACTION: Cameron to resolve issue 5 in linking chapter as
   part of work on other media fragment actions [recorded in
   [27]http://www.w3.org/2015/05/07-svg-minutes.html#action03]
   [NEW] ACTION: Nikos to look at definitions for image in HTML
   and see what applies to SVG as well - reference HTML spec from
   SVG where appropriate [recorded in
   [28]http://www.w3.org/2015/05/07-svg-minutes.html#action01]

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.