Minutes, 8 August 2013 SVG WG telcon

Minutes from this week's SVG WG telcon are below.

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


   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

08 Aug 2013

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
   Regrets
   Chair
          Cameron

   Scribe
          birtles

Contents

     * [4]Topics
         1. [5]review of css-cascade-3
         2. [6]rewriting Text chapter in SVG2
         3. [7]Ideas for opting in to an improved SVG DOM
     * [8]Summary of Action Items
     __________________________________________________________

   <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
   [9]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> [10]http://tavmjong.free.fr/SVG/publish/text.html

     [10] 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:

   [11]http://tavmjong.free.fr/SVG/publish/text.html#TextShapeInsi
   de

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

   <Tav>
   [12]http://tavmjong.free.fr/SVG/publish/text.html#TextShapeOuts
   ide

     [12] 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>
   [13]http://people.mozilla.org/~cmccormack/improving-svg-dom

     [13] 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> [14]http://dev.w3.org/SVG/proposals/improving-svg-dom/

     [14] 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: [15]http://www.xanthir.com/b4RR0 ^_^

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

Summary of Action Items

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

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.138 ([18]CVS log)
    $Date: 2013-08-08 21:45:14 $
     __________________________________________________________

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/



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.