SVG Working Group Teleconference -- 08 Aug 2013

<trackbot> Date: 08 August 2013

<TabAtkins> I'll be following along in IRC.

Zakim: [IP is me

krit: I also added CSSMatrix item

<heycam> ScribeNick: birtles

review of css-cascade-3

heycam: this spec defines how the cascade works and values that can be defined to every property
... initial default etc. and also scoped styles etc.
... it probably doesn't affect us a lot so probably not a lot of work
... anyone interested apart from me?

<TabAtkins> Nah, it should affect SVG only insofar as SVG uses CSS, and even then it's almost completely just a proper rewrite and clarification of what was already stated.

heycam: it defines which rules win for each property etc.

<TabAtkins> Only real addition is the "unset" value, and clarification of how scoped styles and some newer things like transitions/animations interact with other origins.

krit: we need the functionality from that spec

heycam: yes, but it's unlikely they are speccing anything we will disagree with

krit: I'll read over it

<scribe> ACTION: Dirk to review CSS3 Cascade by August 26 [recorded in http://www.w3.org/2013/08/08-svg-minutes.html#action01]

<trackbot> Created ACTION-3516 - Review CSS3 Cascade by August 26 [on Dirk Schulze - due 2013-08-15].

<Tav> http://tavmjong.free.fr/SVG/publish/text.html

rewriting Text chapter in SVG2

Tav: I've made a start on rewriting this
... the goal is to move towards more CSS-framed layout
... I'm looking for some basic feedback as to if the direction I've been taking is something the group agrees with
... basically, the first step is to layout text using CSS
... then after that you apply SVG transformations like dx, dy etc.
... in order to layout CSS text you need a content area
... there are different ways
... if you don't specify a content area you get a rectangle with a width and height
... if you do specify a content area you get specify a rectangle with width and height or a shape inside or outside
... and then you apply CSS layout
... after that you apply SVG rules if any
... if you look at the reorganization of that chapter the most important sections are the text layout sections
... content area, direction, positioning
... then the SVG-specific rules: pre-formatted text, auto-wrapped text, text on a path
... I've reworked the introductions to each of those sections
... I've had trouble determining which CSS specs to reference
... there are a bunch of specs at different stages of development
... and there are various inconsistencies between the CSS specs and SVG 1.1 that need to put address
... I've put issues throughout the spec to mark those
... any comments?

heycam: when do you think we should incorporate this into the main spec?
... do you want to resolve the issues first?

Tav: I think the sooner we merge the better
... but I'd like to get some review of it first because it is a drastic change
... although the end result shouldn't change
... but the structure of the chapter has changed

heycam: I'll have to set aside time for a proper review to give detailed feedback
... but in general I'm in favour of this work
... I had one question about wrapping with shape-inside
... in CSS you have your box you would normally put text in and then with shape-inside you'd put that inside the box

Tav: one of the difficulties is the coordinate system is different
... we don't have the box, we have the viewbox and user coordinates
... CSS defines it relative to a float but SVG doesn't have floats
... at an implementation level you can just say you have a float the size of the content area

<TabAtkins> Yeah, that's not a big deal.

Tav: in CSS you have a box to begin with, so your shape inside, what you wrap text into, the units are based on that box
... we only have a viewbox and user units
... if you have an exclusion it's defined using a shape inside
... and in CSS/HTML that is defined using a float
... and that float determines the units you will use for adjusting... essentially you're changing the shape of the float
... but SVG doesn't have floats
... so instead we need to the use the viewbox and user units to define the shape of the exclusion region

heycam: does that mean you'd be required to put the width/height attributes on the text element?

Tav: no, because you're not using the <text> to determine the exclusion
... there's a complete example:

http://tavmjong.free.fr/SVG/publish/text.html#TextShapeInside

<Tav> http://tavmjong.free.fr/SVG/publish/text.html#TextShapeOutside

Tav: so you see there are two rectangles and two text elements
... the first text element uses the first rectangle as a shape inside and the second rectangle as a shape outside
... it also shows the shape-padding and shape-margin
... the blue area is the resulting wrapping area
... does that make sense?

heycam: so the default shape-outside is the shape-inside
... and then if you specify the shape-outside you're intersecting a rectangle with that?

Tav: the default shape-outside is nothing because you're excluding something

heycam: but the default area you're excluding from is what?

Tav: the shape-inside
... the shape-inside defines the content area
... then you can exclude part of that using shape-outside

shepazu: how does this apply to floats?

Tav: it doesn't apply to floats in SVG
... in CSS/HTML it is defined using floats

heycam: perhaps we could ask people to review it by a certain date and then look at merging it?

Tav: ok

shepazu: is this compatible with the current regions/exclusions stuff in CSS? or is this somehow different?

Tav: it is compatible with shapes except Shapes Level 1 doesn't have SVG paths in it (that will be in Level 2)
... and shape-inside is not in level 1
... but it was agreed in Japan that it will go into level 2
... and the author is supposed to be preparing a draft of level 2

shepazu: I see you included text auto-wrapping

Tav: yes, we agreed to that
... the one issue there is whether you want to define a rectangle using both width and height

heycam: so if we had 2~3 weeks to review, would that be alright?

Tav: yes

heycam: so how about we revisit it in the Sept 5 telcon

shepazu: I think we need to review the definition of the width/height attributes on text element

heycam: yes, I think CSS/HTML does something different here so I think we should look at it

shepazu: do you specify what happens when text overwraps its container?

Tav: yes, that's specified towards the bottom

heycam: it falls off the edge of the page

Ideas for opting in to an improved SVG DOM

<shepazu> +1

heycam: a couple of weeks ago I thought about how we could radically change the SVG DOM

<TabAtkins> Also +1.

heycam: it came about partly when trying to write up the new marker properties
... where we were trying not to add new integer constants to the IDL

<TabAtkins> Note: Per spec at least, createElement() *always* puts the element in the HTML namespace. There's no need to say that SVG elements with no namespace have this behavior as well.

<TabAtkins> Just dump all the SVG elements into HTML and let that be the switch.

<heycam> http://people.mozilla.org/~cmccormack/improving-svg-dom

heycam: I thought about the discussion we had about having a big switch which would let us change to an improved SVG DOM

<heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/

<heycam> (that link)

heycam: I only sent it to the list yesterday so I just wanted to bring it up and briefly summarise it
... the basic idea is that to get the new interface on the DOM nodes you'd create the SVG nodes in the HTML namespace / no namespace
... that's the big switch
... it's critical that something about the creation of the element is what determines what interface is available

<TabAtkins> I just wrote up a blog post with my initial reactions, too: http://www.xanthir.com/b4RR0 ^_^

heycam: and attribute on the other hand happens after the element is created and it would be difficult to switch interfaces on the fly
... the second point is how to make sure that works well with parsing in the HTML parser
... the existing behaviour of the parser--I would be worried that we can't change what currently parsed SVG in HTML is doing

<krit> TabAtkins: great! We can stop the discussion immediately: "I'm going to make sure that SVG and CSS evolve together"

heycam: so I don't think we can just say that all <svg> in <html> get parsed in the HTML namespace

<TabAtkins> krit: I have no idea whether you're being sarcastic or not. Regardless, it's not appreciated.

<krit> TabAtkins: I have no problem with that

heycam: because then all existing content would end up in that category without the author opting into it

shepazu: so why is that important?

<TabAtkins> If anyone's currently scripting at <svg>-in-HTML, they'll break if we just switch them over.

shepazu: perhaps I didn't get the nuance of the proposal, but I didn't see anything you proposed that people would likely to be relying on

<TabAtkins> And without something like a new root element, we can't switch over standalone <svg>.

shepazu: how often to people actually test interface names

heycam: not so much, but they depend on the APIs themselves

shepazu: this is a fairly radical proposal, specifically the <graphics> element

<TabAtkins> Yeah, these proposals are both additive *and* subtractive, so scripts expecting SVG1 stuff will break.

<krit> TabAtkins: we discussed allowing SVG elements in HTML directly and may change to SVG 1.1 mode if you use an <svg> root-element

<TabAtkins> krit: I know.

shepazu: there's going to have to be fallback for older content and older browsers

heycam: yes I think that's the biggest problem with introducing a new root element (fallback for older browsers)

shepazu: that's not a deal-breaker but we need to do an analysis to work out the cost given that it will take a long time for this to deploy

<krit> TabAtkins: I meant to switch from SVG.next to SVG1.1 you just use the <svg> element, and no root element at all if you don't want to (not even <graphics>)

shepazu: if you did createElement now, you are proposing the element does get put in the HTML namespace

<TabAtkins> krit: That doesn't help when you *do* need a viewport element. It also does nothing for the standalone case - svg-in-html is not an image.

heycam: that's how it already works

shepazu: so let's just dump the SVG namespace at all

<TabAtkins> Yeah, right now it'll just have the HTMLUnknownElement interface.

<TabAtkins> But it'll be an <html:svg> element.

<krit> TabAtkins: that is correct

shepazu: if we are going to change it radically, I don't think we should persist in having an SVG namespace

<TabAtkins> shepazu: How are you going to deal with legacy content?

<krit> TabAtkins: he actually rasied this concern

<krit> TabAtkins: brian can't catch up :)

<TabAtkins> krit: Hah, kk.

<TabAtkins> krit: The perils of having a dead phone and a broken charger.

<krit> TabAtkins: :)

shepazu: if someone created something in the SVG namespace explicitly, and we put in the HTML namespace for forwards compatibility reasons

<TabAtkins> That would break legacy code that expects elements it creates to be in the SVG namespace, and to have the SVG1 DOM.

shepazu: we should see what at what points a script is likely to break if we adopted Cameron's proposal from an interface perspective
... Cameron seems to be trying to prevent breakage by introducing a new root element
... and we have to see how disruptive that would be compared to simply introducing the new API

<TabAtkins> Lots of things would break, quickly. Anything trying to get .baseVal, for example, since it's missing from the new DOM.

krit: if we put SVG elements in HTML namespace and vice versa, it wouldn't matter which namespace they were in
... it wouldn't matter how you created them

heycam: every element gets created in a given namespace
... every node will be in one namespace

birtles: shepazu are you saying we could add Cameron's proposal in parallel to the existing interfaces?

shepazu: I don't have a specific proposal, but I'm wondering how many scripts would break...

krit: I don't think anything would break if we switched on namespace

shepazu: I don't like the idea of having two different namespaces for SVG
... you're saying we'd have two different namespaces for SVG

<TabAtkins> No, we'd have the SVG1 namespace, for SVG1. Then SVG2 would just be a part of Greater HTMListan.

krit: now you have to specify the namespace if you want to create an SVG element
... if you don't do that it ends up as HTMLUnknownElement
... so new scripts could use the new interface...

shepazu: I think it complicates implementations if we have to support both

heycam: I think the proposal complicates it for implementations since they have to support both

<TabAtkins> We have to support both anyway. You're just proposing we support both, merged into the same interfaces.

shepazu: I think that's madness

heycam: I think it's the maximally compatible thing to do

shepazu: I'm trying to think of scripts that I've been writing where I've been trying to find the SVG root in an HTML document
... I just walk up until I find a different namespace
... when it comes down to it, what are we trying to preserve?
... the more complex the content is more likely to not work in browsers anyway

heycam: It's not that I'm worried about, it's using the actual interfaces

shepazu: so you're suggesting we use namespaces to switch interfaces but require browsers to support the old interfaces
... instead of having an implicit switch we just alias the new behaviour
... why do we need the extra step of opting into the new interface

<TabAtkins> Browsers only support the old interfaces on the old elements, for legacy compat reasons.

heycam: so you're proposing we support the union of the two interfaces on the same element
... we tried to do that but we reached limits
... because we can't change, for example, rect.x to something more sensible because it's defined to return SVGAnimatedLength

<TabAtkins> Yeah, too many things are broken in ways that would require actually changing names, which breaks the language much more thoroughly (and ruins hopes of compat with HTML in things like <a>.href)

shepazu: if we change that, how much will it break?

birtles: I think it will break a lot

<TabAtkins> It will break literally *anything* that actually uses that attribute.

shepazu: I think we need to analyze what will break and determine if we really need a switch, but I don't like the new root element

<TabAtkins> zcorpan over in #whatwg asks if we know usage numbers for the current DOM. If they're low enough, can we just drop the old stuff straight up?

<TabAtkins> shepazu: We've already looked it through. >_<

shepazu: if it's just to do with the dom then maybe it's a new keyword

<krit> TabAtkins: shepazu doesn't read your comments :( Can't you call in?

<TabAtkins> No, I can't.

shepazu: I think the distinction based on root element / namespace is going to be difficult for someone new to web development / svg

<TabAtkins> There's no distinction. There's SVG, which has a <graphics> root and is part of Greater HTML, and then there's some weird legacy stuff you see occasionally.

heycam: well this is a start to get people thinking about new SVG DOM ideas
... feel free to send more thoughts to the mailing list

krit: please add points from this discussion as issues to the proposal

- DRAFT -

SVG Working Group Teleconference

08 Aug 2013

Attendees

Contents

review of css-cascade-3

rewriting Text chapter in SVG2

Ideas for opting in to an improved SVG DOM

Summary of Action Items

Scribe.perl diagnostic output