SVG Working Group Teleconference -- 07 May 2015

<trackbot> Date: 07 May 2015

<shepazu> heycam, can't make the telcon today, but +1 on making SVG case-insensitive 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 https://www.w3.org/2002/09/wbs/19480/Linkoping2015 when you get a chance.

<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

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?

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: 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 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> 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 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> 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 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> 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> 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> 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> 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

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

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

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

- DRAFT -

SVG Working Group Teleconference

07 May 2015

Attendees

Contents

HTML parser lowercasing SVG names

Continued SVG 2 open issue discussion

Linking chapter issues

Linking chapter - issue 5

Linking chapter - issue 7

Summary of Action Items

Scribe.perl diagnostic output