Nabble - w3.org - www-svg

Re: Changing attributeType="CSS"

2009-12-17T03:05:07Z

Hello,

certainly it is pretty useful for example for a group of
similar elements to inherit attribute values from the grouping
element. As often colors in SVG are not really decorative,
it is maybe only the task to describe in the specification,
that presentation attributes are often not just decorative as
CSS properties are, therefore authors have to distinguish between
the technical issue, for example to inherit a value somehow from
the question whether something is decorative or not in SVG,
this applies much more for the property-attribute mixture in SVG
as for CSS+(X)HTML for example, where it is simple to distinguish
between decoration and function.
If authors apply stylesheets to SVG documents, it is more difficult
than for (X)HTML still to provide the same information with the
styled and the not styled document. If there become more and
more functional attribute properties, it gets more important for
the specification to pronounce this problem and that authors
have to take care, if they follow this approach.

Olaf

Erik Dahlstrom:

> On Mon, 02 Nov 2009 11:45:18 +0100, Dr. Olaf Hoffmann
>
> <Dr.O.Hoffmann@...> wrote:
> > Erik Dahlstrom:
> >> How about making the 'height' attribute a presentation attribute for
> >> SVG.next? I think it's possible to stay backwards compatible while
> >> adding
> >> the option of specifying the width/height through CSS.
> >>
> >> Cheers
> >> /Erik
> >
> > Because width and height are not essential, but more a decorative
> > question
> > for an element in XHTML for example, it is a pretty good choice to
> > have this as property.
> > But for a rect element in SVG, width and height are the essential
> > information
> > about what kind of rectangle we have, this is not decoration or styling
> > or
> > presentation.
>
> For rect I agree that it would be strange to not have dimensions in the
> markup, but OTOH you might want to "decorate" it with a different
> width/height on hovering the element for example. I guess you could
> compare <svg:image> and <html:img> too, what is the difference and why
> should you not be allowed to influence the dimensions of <svg:image> from
> CSS?
>
> At least for the svg elements that establish viewports[1] I think it would
> be useful to let that those viewport dimensions be stylable through CSS.
>
> > Therefore I think, they should not be presentation attributes
> > or properties like fill. It would be similar to say the d attribute of
> > path
> > should be only styling and decoration and the essential information is
> > only,
> > that we have a path - not important, what kind of path ;o)
> > Of course, once started one has to continue the game: r of circle? rx,
> > ry of
> > ellipse or rect? points of polyline and polygon? x1,x2,y1,y2 of a line? -
> > essential information or only presentation? ;o)
>
> Many of the listed attributes are already indirectly tweakable (but not
> individually) through CSS Transforms. Yet 'transform' is not a
> presentation attribute in SVG, though it looks likely that it will be in
> the future given that we now have CSS 2d/3d Transforms.
>
> Cheers
> /Erik
>
> [1] http://www.w3.org/TR/SVG11/coords.html#ElementsThatEstablishViewports

Re: Changing attributeType="CSS"

2009-12-17T01:07:23Z

On Mon, 02 Nov 2009 11:45:18 +0100, Dr. Olaf Hoffmann
<Dr.O.Hoffmann@...> wrote:

> Erik Dahlstrom:
>> How about making the 'height' attribute a presentation attribute for
>> SVG.next? I think it's possible to stay backwards compatible while
>> adding
>> the option of specifying the width/height through CSS.
>>
>> Cheers
>> /Erik
>
> Because width and height are not essential, but more a decorative
> question
> for an element in XHTML for example, it is a pretty good choice to
> have this as property.
> But for a rect element in SVG, width and height are the essential
> information
> about what kind of rectangle we have, this is not decoration or styling
> or
> presentation.

For rect I agree that it would be strange to not have dimensions in the
markup, but OTOH you might want to "decorate" it with a different
width/height on hovering the element for example. I guess you could
compare <svg:image> and <html:img> too, what is the difference and why
should you not be allowed to influence the dimensions of <svg:image> from
CSS?

At least for the svg elements that establish viewports[1] I think it would
be useful to let that those viewport dimensions be stylable through CSS.

> Therefore I think, they should not be presentation attributes
> or properties like fill. It would be similar to say the d attribute of
> path
> should be only styling and decoration and the essential information is
> only,
> that we have a path - not important, what kind of path ;o)
> Of course, once started one has to continue the game: r of circle? rx,
> ry of
> ellipse or rect? points of polyline and polygon? x1,x2,y1,y2 of a line? -
> essential information or only presentation? ;o)

Many of the listed attributes are already indirectly tweakable (but not
individually) through CSS Transforms. Yet 'transform' is not a
presentation attribute in SVG, though it looks likely that it will be in
the future given that we now have CSS 2d/3d Transforms.

Cheers
/Erik

[1] http://www.w3.org/TR/SVG11/coords.html#ElementsThatEstablishViewports

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Re: The synchronous load event is trouble

2009-12-17T00:19:47Z

On Nov 27, 2009, at 13:00, Dr. Olaf Hoffmann wrote:

> I don't know much about scripting, because I do not use it,
> however to have a well defined 'time-zero-point' or begin of
> the timeline is a requirement for animation and in tiny 1.2 for
> the synchronisation of multimedia content and animations as well.
> This load event is related to the timeline begin in SVG 1.1.
[...]
> Do you think, there should be a more flexible choice for authors
> to indicate, at which time the timeline begins?
> What should the behaviour of the document before the timeline has
> begun? Any ideas to provide a predictable behaviour for authors?

I'm suggesting that the load event fire from a task queue on the event loop as opposed to firing synchronously when the parser is on the call stack. The time-zero-point for animations can still be the time when the load event fires.

http://www.whatwg.org/specs/web-apps/current-work/#task-queue
--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

Naming Convention (was: [Parameters] specifications feedback)

2009-12-10T18:22:07Z

Hi, Steve-

Whoops! I drifted off in mid-sentence... completion below...

Doug Schepers wrote (on 12/9/09 11:44 PM):

>
> Steve Withall wrote (on 12/8/09 8:16 PM):
>>
>> B2. Further to B1, the subject of parameters would be easier to write
>> about
>> if we had clear terms for the 'usage' documents and for the 'declaring'
>> documents. (I'm finding it hard to decide how to refer to them in this
>> email. For want of something better, I call them the 'usage document'
>> and 'declaring document' respectively.)
>
> I'm not sure what you mean... are you referring to the spec format
> ('usage document' == Primer, 'declaring document' == Language Spec), or

... to the host/referring document vs. the resource/referenced document?
I think I like "host/resource" or "host/component" document... I agree
that some consistent terminology would help clarify the concept, and
welcome suggestions.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Minutes, SVG Telcon, 10 Dec 2009

2009-12-10T13:28:28Z

http://www.w3.org/2009/12/10-svg-minutes.html

---

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

10 Dec 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/12/10-svg-irc

Attendees

Present
Shepazu, [IPcaller], ed, anthony

Regrets
Chair
Erik

Scribe
anthony

Contents

* [3]Topics
1. [4]Next Telcon
2. [5]Face-to-face
3. [6]Collaboration with CSS
4. [7]DOM3 Event TransformX/Y
5. [8]SVG 1.1
* [9]Summary of Action Items
_________________________________________________________

<trackbot> Date: 10 December 2009

<scribe> Scribe: anthony

Next Telcon

DS: The next Telcon will be the 6th
... no wait
... Monday January 4th 2010

AG: I might not be there for that telcon
... flying back from Townsville

<scribe> ACTION: Erik to Email the SVG Working Group list informing
members when the next telcon is going to be (after the break)
[recorded in
[10]http://www.w3.org/2009/12/10-svg-minutes.html#action01]

<trackbot> Created ACTION-2704 - Email the SVG Working Group list
informing members when the next telcon is going to be (after the
break) [on Erik Dahlström - due 2009-12-17].

Face-to-face

DS: We do not have quorum for meeting in Sydney
... so will have to cancel that

AG: So when will the next F2F be?
... or will it still be around that time?

ED: When is Libre graphics?

<ed> [11]http://libregraphicsmeeting.org/2010/index_static.html

[11] http://libregraphicsmeeting.org/2010/index_static.html

DS: AKA LGM, is Belgium

ED: 26th to 29th May 2010

DS: If we are going to have a meeting before then
... JWatt said Feb works for him

<ed> [12]http://www.fosdem.org/2010/

[12] http://www.fosdem.org/2010/

ED: There is also Fosdem

<ed> 6-7 feb 2010

<ed> also brussels

ED: JWatt didn't want a conflict with

DS: So anytime around then works for me
... and I guess we'll be going to Europe
... if we going to have one at all
... I've been thinking about a DOM API summit
... get a bunch of people together
... for a couple of days
... and work out a good API
... get a bunch of requirements
... have people put forward proposals
... then have a discussion and hopefully come up with a model
... that can be used
... some major browser vendors have offered to host it
... Erik can you fly to the US in Jan/Feb?
... or March?

ED: March would be fine

DS: It wouldn't be exclusively SVG
... if we had it on the West coast, it might help JWatt
... This might be a fruitful alternative to an SVG F2F

AG: Have this as an alternative?

DS: Have 2 or 3 days SVG F2F and then a DOM Summit
... Might even have more days than that - 5 days depending how long
people can attend for

<scribe> ACTION: Doug to Look into details of a DOM summit/SVG
meeting [recorded in
[13]http://www.w3.org/2009/12/10-svg-minutes.html#action02]

<trackbot> Created ACTION-2705 - Look into details of a DOM
summit/SVG meeting [on Doug Schepers - due 2009-12-17].

DS: I guess we can't really decide right now where the next F2F will
be

Collaboration with CSS

DS: I spoke with a Designer on the CSS WG - Tab Atkins
... he's the editor on the CSS Gradients specification

<shepazu> [14]http://dev.w3.org/csswg/css3-images/Overview.html

[14] http://dev.w3.org/csswg/css3-images/Overview.html

DS: it's actually CSS Image Values
... we talked about his proposal
... there are some things that seem very funky to me
... with the syntax
... somethings you can do that you can't do with SVG gradients
... We agreed that we want the models as similar as possible
... including the syntax
... how would you guys feel about forming a task force with CSS
Working Group
... and working on some things with them
... It would part of the Paint Servers work

AG: As long as it can be extend at some point

ED: There's also text shadow as well

DS: These are some of things we should be collaborating on
... making sure they have the same syntax will be a real win for
authors
... I propose we act on it
... I asked PLH about this
... He supported the idea as long as the deliverable is in the
Charter
... a Taskforce is something the Chairs set up
... and had nothing to do with the Team
... So Erik is it possible to do this

ED: Sounds likes a good idea

DS: You will have to write to the CSS WG with a formal proposal

AG: Just looking at the CSS Gradients
... it looks like the geometry of the gradient is modified according
to the bounding box of the gradient
... well at least it can be specified to behave that way
... wouldn't be hard to do in SVG, just need another parameter

DS: They can specify a start point and an angle rather than an end
point

AG: That's also not a bad idea

DS: So there's a lot of points that we can collaborate on
... and CSS WG has designers which might be able to help us

DOM3 Event TransformX/Y

DS: We all no this problem
... if you write a drag and drop script
... as soon as you introduce transforms or a viewBox and you try to
drag it
... X/Y are offset from where the mouse pointer is
... and it is really painful
... JWatt proposed putting this into DOM 3 Events
... since CSS has proposed Transforms
... they will run into the same problems
... as we did
... I'm proposing for DOM 3 Events
... we have Tx/Ty
... Transform X and Transform Y
... and it unwinds the transformation matrix to get the actual
viewPort X and Y
... client X and client Y would be good if they had the right
algorithms behind them but they don't

AG: If we have to unwind the matrix
... we'd have to get the inverse matrix
... is that right ED?

ED: Yes, can't always get the inverse

<ed> [15]http://en.wikipedia.org/wiki/Invertible_matrix

[15] http://en.wikipedia.org/wiki/Invertible_matrix

AG: The idea has merit but there some cases where it will fail

DS: Where abouts?

ED: Scale 0
... trying to think of other cases

DS: If there are predictable cases you could specify don't do
calculations on these cases

ED: You can do a a cheap calculation to determine if you can get an
inverse
... but you may not want to do that all the time

DS: I'll show you both the script I'm working on
... and you can give me feedback over email

<scribe> ACTION: Doug to Send in details to the list on DOM 3
Transform X/Y for feedback [recorded in
[16]http://www.w3.org/2009/12/10-svg-minutes.html#action03]

<trackbot> Created ACTION-2706 - Send in details to the list on DOM
3 Transform X/Y for feedback [on Doug Schepers - due 2009-12-17].

<ed> [17]http://en.wikipedia.org/wiki/Determinant

[17] http://en.wikipedia.org/wiki/Determinant

ED: If you want the math behind it, you can calculate the
determinant

<ed> for a 3x3 matrix: det (A) = aei - afh + bfg - bdi + cdh - ceg.

ED: which will tell you if the matrix is invertable

<ed> if that's 0 it's noninvertible

ED: Are you suggesting to have properties on the Event interface?

DS: Yes, on any event that has x, y attributes, like the mouse event
interface event types
... you'd also have Tx, Ty
... that would be the value in the transformation space of the
element
... Any place we have transform it would be nice to have the
individual attributes
... Translate X, Translate Y, etc
... It would be nice to just have those individual transforms and
have a predefined order they are applied in

SVG 1.1

ED: Converting Opera internal intersection list tests
... to use the W3C template
... and reviewing the tests that Cameron wrote
... there are two or three tests on my to-do list

DS: There's a couple of actions I can do

AG: Same

<ed> [18]http://www.w3.org/Graphics/SVG/WG/track/products/1

[18] http://www.w3.org/Graphics/SVG/WG/track/products/1

ED: The Java bindings appendix is done

<scribe> ... pending review

UNKNOWN_SPEAKER: the other one I'm doing is intersection list and
clarification for that
... I might be able to take on more actions
... if people are having trouble with
... was thinking of taking ACTION-2676

<scribe> ACTION: Anthony to Send Doug the location of the tables for
the integration specification [recorded in
[19]http://www.w3.org/2009/12/10-svg-minutes.html#action04]

<trackbot> Created ACTION-2707 - Send Doug the location of the
tables for the integration specification [on Anthony Grasso - due
2009-12-17].

Happy Holidays everyone!

<ChrisL> sorry to miss the call gus, i had a transition call to do,
standing in for plh

Summary of Action Items

[NEW] ACTION: Anthony to Send Doug the location of the tables for
the integration specification [recorded in
[20]http://www.w3.org/2009/12/10-svg-minutes.html#action04]
[NEW] ACTION: Doug to Look into details of a DOM summit/SVG meeting
[recorded in
[21]http://www.w3.org/2009/12/10-svg-minutes.html#action02]
[NEW] ACTION: Doug to Send in details to the list on DOM 3 Transform
X/Y for feedback [recorded in
[22]http://www.w3.org/2009/12/10-svg-minutes.html#action03]
[NEW] ACTION: Erik to Email the SVG Working Group list informing
members when the next telcon is going to be (after the break)
[recorded in
[23]http://www.w3.org/2009/12/10-svg-minutes.html#action01]

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [24]scribe.perl version 1.135
([25]CVS log)
$Date: 2009/12/10 21:25:37 $
_________________________________________________________

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

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [26]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

[26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/well will/we did/
Succeeded: s/on that/on the Event interface/
Succeeded: s/on any event that has mouse event interface/on any event t
hat has x, y attributes, like the mouse event interface event types/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Shepazu, [IPcaller], ed, anthony
Present: Shepazu [IPcaller] ed anthony
Found Date: 10 Dec 2009
Guessing minutes URL: [27]http://www.w3.org/2009/12/10-svg-minutes.html
People with action items: anthony doug erik

[27] http://www.w3.org/2009/12/10-svg-minutes.html

End of [28]scribe.perl diagnostic output]

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

Re: [Parameters] specifications feedback

2009-12-09T20:44:10Z

Hi, Steve-

Thanks for your comments. This is a long email with lots of points, so
some of it I still have to consider and discuss with the SVG WG. With
the approach of the holiday season, it is unlikely that we will have
time to get back to you with a comprehensive reply before late January
(we have quite a lot on our plate), but I will give you my initial
impressions here, inline...

Steve Withall wrote (on 12/8/09 8:16 PM):

>
> Here is some feedback on your Parameters specification "SVG Parameters
> 1.0, Part 2: Language" (undated, but last modified 10th June 2009). I am
> not commenting on Part 1, because I believe that Part 2 gives me the
> opportunity to make every point of substance I have. I've divided my
> comments into two parts for readability, plus a third proposing a
> different way of declaring parameters.
>
> Steve.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> A. Comments on Part 2, "Use Cases and Requirements" section
> ===========================================================
> A1. Requirements and use cases ought to precede everything else - and be
> written before you consider what might be the best solution to them :)
> - so I find it strange that they are deferred to the second document.

The primer is simply intended as an introduction to the technology for
users of the technology to give them a broad overview of how it can be
used, and the syntax to use it. The use case and requirements are just
before the normative language in the technical spec, which I think it
appropriate.

> A2. "Usage Scenarios": This list of usages is helpful, but since they're
> examples they are merely anecdotal. They don't constitute a statement
> of the goals for parameters, which is lacking. The closest you come is
> saying in the Abstract of Part 1 that they're for "re-using a resource
> several times with specified variations", but this is vague and open
> to many interpretations.

I don't claim particular skill in developing formal use cases and
requirements, so if you want to educate me, I would be interested in
doing it better. Some concrete examples would go a long way, as well as
a summary of overall strategy.

I will note that this is a source of quite a lot of difference in
opinion in most of the working groups I've participated in. There is a
lot of debate as to what is an adequate level of detail for use cases
and requirements. In short, specific comments, change requests, and
additional use cases or requirements regarding these are welcome;
high-level comments like the above may be too open ended for me to know
how to satisfy the request.

Also, I believe that use cases are meant to be representative of an
unknowably large set of uses to which features are put... this is a
feature. They represent the minimum set of cases that the features
should satisfy.

(I don't mean to be terse, but this kind of discussion quickly leads
down the rabbit hole.)

> In recent emails, Doug, you have stated that you want to keep the
> Parameters specification simple. But without clearly defining what
> parameters are for, one cannot make an objective judgment of whether
> what's currently specified is adequate, nor whether suggestions for
> extra sophistication are good value or not.

As mentioned in the spec, here are the use cases I'm trying to solve,
based on my own authoring experience and the feedback of other authors:
* Adapt colors to fit theme
* Change size or position of graphical elements
* Hide or show elements
* Adapt text to use
* Change link locations
* Change aspects of 'use' content

I think those are very specific, and I think Params as specified meets
those cases adequately. I am open to better mechanisms, but I haven't
yet seen one that seems a better fit.

> BTW, when you say enhancements
> could be added in future, what do you mean? SVG 3.0 in 2017? :^)
> You ought to do you utmost to get it right first time.

My personal opinion is that the spec is at the right level of power vs.
ease of use. All too often, new features take on a life of their own,
growing in complexity without direct implementation and author
experience. I am adamant that this should not happen with SVG Params.

While the spec will almost certainly go through some changes before its
done, I don't think it's appropriate for it to get much more complex
than it is right now.

> In any case, the ability to add more sophistication in future without
> major disruption would be a useful requirement to add.

Though that's a reasonable requirement in general, I'm not sure how this
specification could address it without adding another level of
complexity. If you (or anyone) suggests a way to do so, I would add it.

In fact, I think that Params already satisfies the level of
sophistication needed for this feature. All suggestions I have heard
that make it more comprehensive also make it much more complicated, or
duplicate functionality found in other languages such as CSS or XSLT.

Keep in mind that this is just one part of SVG, and it's meant to work
in combination with other features to provide a more powerful whole.

> A3. "Usage Scenarios": Simplicity in the Parameters specifications is one
> thing; simplicity in the documents that use parameters is something
> else. How many parameters might document authors end up using in a
> single document? All your examples are simple (which is fine), but
> it's not hard to envisage parameters numbering in the dozens. A
> single flat list is less than ideal when it grows longer than, say,
> eight or ten.

If an author is making a document that has more than a few parameters, I
would argue that they are doing it wrong. As with O-O design, simple
reusable components are what this spec aims to address. I am happy to
put a note in the spec to that effect.

What sort of documents do you have in mind that would require such
complexity? I know you have a sophisticated implementation with SVG as
a central part of an application framework, but for most uses of SVG I
envision it being most applicable to compound documents using both SVG
and HTML, so smaller, more discrete SVG components seem most appropriate.

> A4. "Adapt text to use": This is potentially very useful, but might quickly
> become unwieldy if you have more than one or two text parameters
> (especially when passing via a URL, or for long pieces of text). Some
> authors might be tempted to use this to achieve multi-lingual text,
> which is probably not a good idea.

On the contrary, I think it is a good idea to use it for alternate
languages... why do you think it's not?

> A5. "Usage Scenarios": The previous point leads me to suggest that you
> investigate possible usage scenarios in more detail: if (sorry, when!)
> you give document authors this parameters facility, what uses might they
> put it to that you haven't thought of? You wouldn't want any nasty
> surprises. Perhaps you could invite suggestions. Some usages could
> be horrible bastardizations. Some might be worth considering in their
> own right, to allow them to be achieved in a cleaner and easier way.

I have been actively inviting suggestions, by presenting on this at
conferences. That's also the goal of public Working Drafts.

> When investigating in more detail, you ought to create examples that
> are as complex as authors might create in real life. (A 12-month
> bar chart with 6 parameters per month?) The existing examples are
> so simple that they don't tell you much about usage in practice.
> How do parameters scale up? Just how long might long URLs become?
> (Longer than you anticipate, I anticipate.)

Yes, I'd love to see people putting this into practice. That's one
reason I implemented it in Javascript, to allow authors to play with it
and find where it falls down. So far, I haven't heard back much about
it, but hopefully as the spec becomes more widely known, we will.

For what it's worth, I'm not a huge fan of the idea of sending
parameters via the URL string, but it's a case that must be covered.

> A6. "Special Considerations for SVG Parameters", "Implementation
> commitments": For all you say about keep Parameters simple, I
> believe that implementing them as specified is likely to involve
> considerable effort - because of the sheer number of attributes
> that must support the "param(...) ..." syntax. (Would the major
> implementers care to consider this and give us their verdicts?)

The SVG WG discussed this, and in light of the fact that we plan on
allowing more functional notations as attribute/property values for
layout, we didn't feel that "param()" adds significant burden.
Implementer feedback is obviously going to be taken into consideration.

> A7. Following on from A6, I suggest that the Working Group ponder
> whether any other forthcoming SVG enhancements have a similarly
> wide impact upon existing attributes en masse, so that implementers
> can make all these changes in one go. I have in mind the potential
> for the layout specification to introduce expressions. (I live in
> hope!)

See above. This is only one of several similar additions we are
considering along these lines.

> A8. "Special Considerations for SVG Parameters", "Ease of authoring":
> The first consideration is to make it easy for authors to know
> what parameters are available to them when they re-use a particular
> SVG document. I have more to say on this below, because it is a
> consideration I believe is not satisfied at present.

While not trying to say that "tools will save us", one of the scenarios
I had in mind was that authoring tools would expose these keywords,
their associated property or attribute, and perhaps display some
permutations on these. For example, a clipart gallery could show
several variations on a theme with the same image, or an authoring tool
could highlight those parts of the image which are subject to
parameterization.

> A9. "Requirements", point 1.1: Remove the "(but not limited to)" clause.
> It renders this requirement open-ended, which is unacceptable. Adding
> a new means of passing parameters constitutes an extra requirement.
> (Each existing means ought to be regarded as a distinct requirement too.)

SVG specs cannot make requirements on other specifications. If DocBook
or ODF or some other markup language or framework provides an adequate
way to pass parameters that can be interpreted by a conforming SVG Param
implementation, it is not the place of this spec to disallow that... in
fact, I encourage it, because we do not know all the environments that
SVG is or will be used in.

For example, Company Gamma may make a set-top-box framework where they
pass parameters this way:
<component file="mybutton.svg" color="red" label="Record" />
As long as they hook that into SVG Params the right way, I think that's
just fine.

> A10. "Requirements", points 2 and 3: Yes, you need to say more about
> scripting and animation! Nasty complications might lurk in both
> places, and you need to flush them out as soon as you can.

Agreed. Do you have any specific points to add?

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> B. Comments on Part 2, "Definitions and Basic Data Types", "Syntax" section
> ===========================================================================
> B1. I find that this document lacks structure. There are two distinct parts
> to Parameters: usage (the documents that refer) and declaration (the
> documents that are referred to). I think everything would be clearer
> if you had two clear top level sections accordingly. The "Syntax" section
> launches into the declaration aspects without introducing that that's
> what it's doing.

You're right... I'm not sure why I did that this way... it is still just
an early draft, but I should have different sections for "Definitions
and Basic Data Types" and "Syntax".

> (Actually, if you do choose to restructure Part 2, you could also consider
> merging Parts 1 and 2 into a single document. Two documents are not
> warranted for reasons of size, and a single document would allow you to
> avoid the repetition that is necessarily present now.)

The two documents are intended for different audiences. We've heard
feedback in the past from implementers that they don't want user
examples in the normative document, and from authors that they find the
technical implementation details too be confusing. By splitting them
out into paired documents, we address those concerns. The repetition
isn't that much overhead.

> B2. Further to B1, the subject of parameters would be easier to write about
> if we had clear terms for the 'usage' documents and for the 'declaring'
> documents. (I'm finding it hard to decide how to refer to them in this
> email. For want of something better, I call them the 'usage document'
> and 'declaring document' respectively.)

I'm not sure what you mean... are you referring to the spec format
('usage document' == Primer, 'declaring document' == Language Spec), or

> B3. "The 'param' Attribute", fourth paragraph: In order to stress how
> pervasive
> this change is, you ought to highlight as boldly as you can the statement
> * *that the "*param attribute value must be available as a value on any SVG
> * *attribute*". Further, I would change 'any' to '*every*', and add "*on
> every
> * *SVG element*". The implications of this are considerable: potentially
> large
> development effort by implementers (and perhaps even more for authoring tool
> developers), extra tests for every attribute in every SVG element, and
> ... what else? (My proposed alternative, described below, avoids all
> of these changes.)

I can add a note to the spec to that effect, but I think any implementer
reviewing it could hardly fail to take note of the implications.

> B4. "The 'param' Attribute": Any changes you make to attribute values ought
> also to apply to property values too, for consistency. Am I correct in
> believing that to date the values allowed in all property values are
> identical to the values allowed in the equivalent attributes? If so,
> this commonality should be maintained.

I wanted to first run the idea by the CSS WG before saying anything
about property values in CSS syntax. Early feedback from the CSS WG
seems positive, so it is likely that it will apply to property values as
well. (Note that the presentation attributes like 'fill' are still
attributes, even if they can also be expressed as properties.)

> B5. "The 'param' Attribute", fifth paragraph: You are correct that this
> section
> needs a lot of work. This section deals only with the local syntax for
> declaring a single parameter, which is relatively straightforward. A
> separate topic, which deserves a new section in its own right, is
> interactions between multiple parameter declarations. Topics that need
> addressing include:
>
> (a) Multiple parameters with the same name. This is useful and is
> presumably acceptable, to allow one parameter to affect multiple
> parts of the re-used document at once. For example a 'color'
> parameter could set the color of several sub-elements.

This is easily done with the current proposal... for example, passing
the parameter 'color:blue' to this file would result in both the stroke
of the rectangle and the fill of the text being blue.

<svg ...>
<rect stroke="param(color) red" ... />
<text fill="param(color) black" ... >Label</text>
</svg>

Any attribute that uses the same param keyword would have the same value
passed in.

> (b) Inconsistencies between parameters with the same name. For example,
> if parameter name 'p1' is a color attribute in one place and a
> co-ordinate in another, then ... well ... something's gonna break.
> A declaring document is in a position to detect such inconsistencies
> - but only by navigating the whole document tree to find all
> parameter declarations.

Different parameters cannot have the same name. Yes, if a file is
composed which uses multiple parameters that have the same name for
different purposes, something may break... authors shouldn't do that.
Obviously, the lacuna value would be used for anything that didn't have
the right value type (fill="8.54" would result in a black fill,
cx="green" would result in cx="0").

> B6. "The 'param' Attribute", fifth paragraph: Point B5 (b) leads to the
> subject of error handling, which I think your specification ought to
> addressexplicitly.

What I had in mind (but which it seems I haven't yet put into the spec)
is that if a fallback is provided (cx="param(posx) 20%"), and a
parameter doesn't match the expected value types for that attribute,
then the fallback value ("20%") is used.

> The validity of a parameter value written in a 'usage' document can only be
> determined by reference to its declaration in a separate document. This
> could lead to errors that aren't easy to explain to the user (especially
> sincethey may otherwise have no cause to look into the declaring document;
> indeed, one of the benefits of parameters is that they don't need to).
> This is an area where implementers need to take extra care with their error
> messages. Perhaps the Parameters specification could lay down some guidelines.

Agreed. I had planned to be more explicit in how the parameter names
are exposed to external examination... maybe providing a list of the
expected parameters and their datatypes in the Parameters API would be
useful in this respect.

> B7. "The 'param' Attribute", fifth paragraph: Further to B6, one source
> of errors
> in parameters is in data typing: an attribute might expect a color, but be
> given a length. Such errors are usually straightforward to deal with, but
> the fact that the value is supplied by one document and validated with
> reference to another introduces an extra level of complexity.

Regarding error messages, I will put in a note that mismatched values
for attributes should be reported to a UA's error console for the file
it's found it (which is already defacto SOP), with the suggestion that
the parameter name and expected value type also be provided, along with
the file name of the document where the parameter was declared.

> B8. Another situation to consider is an SVG document both declaring and
> using parameters. That is, a declaring document could refer to other
> documents that use parameters. This would appear to cause no problems
> if each usage is treated as self-contained. But might document authors
> want the parameter mechanism to percolate down the chain of referenced
> documents? For instance, if document A uses a parameter 'p1' in document
> B, and document B uses a parameter 'p1' in document C, should the same
> value of p1 passed from A to B also be passed to C? (I hope you can follow
> that.)

This is why I introduced the <param> element into SVG, for referencing
elements like <use>, with the <param@value> also able to take the
'param()' keyword. The author explicitly states the parameter names and
values passed to the referenced file:

<use xlink:href="someExternalFile.svg#root">
<param name="p1" value="param(p1)" />
<param name="dot" value="param(color)" />
<param name="x" value="param(y)" />
<param name="y" value="50%" />
</use>

By decoupling the parameter names and values this way, each component
file is indeed self-contained, but can easily be made part of an
inheritance chain. In fact, an SVG file which is called with
parameters, and which in turn calls parameterized components, might not
use the parameters for any other purpose than to pass them on to the
referenced files.

> Your 12-month bar chart example in Part 1 might benefit from a two-level
> declaration of this kind (especially if you wished to make it more complex):
> one document for the bar chart and a separate one for a column.

Yes, I had the same thought myself, but hadn't acted on it yet. I will
do so.

> B9. The 'parameters' property: Good luck to anyone who attempts to animate
> a list of parameters!

What specifically are you saying is the problem?

>I suspect that specifiers of standards have a
> tendency to throw in any feature which is easy for them to write. Making
> a property inheritable and animatable is for you a matter of a few
> keystrokes.

My chief concern is with empowering authors. Implementors are
considered, of course, but if I have to make a choice between making the
lives of millions of authors easier or the lives of a few implementers
easier, I will choose the authors every time.

As a corollary to that, I have to make sure that the feature is easy
enough to implement consistently, and well-specified enough to do so
interoperably. So, in that respect, I am sensitive to the concerns of
implementers.

To that end, I have taken to the practice of writing a script
implementation of the features I'm specifying, to make sure that they
are implementable (at least to some degree... I realize that there are
differences between how easy something is to accomplish in script vs.
C*/Java/etc.), that they cover the details that are needed, and they are
usable by authors. There are parts of SVG Param that I removed or never
put in because my personal experience taught me that it wasn't a good
approach.

>Ditto your policy of making every new attribute a property
> (which I dislike, find ridiculous for some attributes, and regard as
> not in the spirit of the original SVG standard). Do you adequately consider
> the implications each time you slip in (or copy in) such innocuous words?
> Conscientious as you are, you're not superhuman, so I imagine you can't.
> If in doubt, leave it out! Deliver on your promise to keep parameters
> simple! :)

I rely on my own authoring and implementing experience to inform most of
my judgments, yes. Different implementers and implementations (and
authors) may draw different conclusions than I do... that's why these
specifications are open for review. Creating a spec (especially in
these early stage) is an iterative process.

In this particular instance, I hadn't gotten around to thinking deeply
about the 'parameters' property... I should have marked it as a
placeholder while I talked to the CSS WG and looked at implementing it
myself. But a more productive (and less confrontational) way to comment
on this or other issues would be to explain the specific performance and
implementation challenges, and suggest a way to resolve it.

> And one more suggestion which I'll put here to save me creating a whole
> new section for it:
>
> B10. You use parameters to reference a whole SVG document. There's no reason
> why you couldn't reference a single element. This would allow multiple
> related 'referencable' elements to be placed in one document, which
> would give authors more flexibility, reduce the number of documents,
> potentially reduce the number of resources that need to be loaded, and
> allow these elements to share the same <defs> element (thus avoiding
> repetition).
>
> To do this would complicate the URL format to include the ID of the
> element to reference - but that's not a big deal.

Complicating the URL syntax and forcing users to reference a specific id
along with the parameter name seems very unwieldy to me.

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Proposal for an alternative to "param(...) ..." attribute values
> ================================================================
> Rationale: The problem of discovering what parameters can be passed to a
> particular declaring document led me to consider the analogy with
> programming languages. Functions in high level programming languages
> typically (always?) declare all their parameters at the beginning, which
> makes it clear what parameters to pass. A programming language that let
> you declare parameters anywhere in the body of a function's code would
> be considered very strange. Isn't that what the Parameters specification
> does?
>
> (Another analogy is to the animation of attribute values: SVG sensibly
> has separate animation elements, rather than attempting to pack the
> definition of an animation into an attribute's value - which is
> effectively what "param(...)" does for parameters.)
>
> An alternative is to declare all an SVG document's parameters in one
> place, as near the beginning of the document as possible - perhaps in
> the <defs> element. The declaration of a parameter needs a name plus
> references to one or more attributes that its value can be passed to.
> (An attribute value is not needed, because each attribute's normal value
> plays this role.)
>
> The equivalent of the SVG document in the "Passing Values to SVG Files"
> section in your specification Part 1 might be something like:
>
> <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> viewBox="0 0 110 40" width="100%"
> height="100%">
> <defs>
> <paramDefs>
> <paramDef name="color"
> elementId="button_rect" attribute="fill"/>
> <paramDef name="outline"
> elementId="button_rect" attribute="stroke">
> <paramDef
> elementId="button_label" attribute="fill"/>
> </paramDef>
> <paramDef name="label"
> elementId="button_label"/>
> </paramDefs>
> <defs>
> <title>Reusable Button</title>
> <desc>Takes parameters from parent document's embedding
> element.</desc>
> <g>
> <rect id="button_rect" x="5"
> y="5" width="100" height="30"
> rx="15" ry="15"
> fill="blue"
> stroke="navy" />
> <text id="button_label" x="55"
> y="30" text-anchor="middle"
> font-size="25"
> fill="black" font-family="Verdana">
> button
> </text>
> </g>
> </svg>

Indeed, this is very similar to the first approach I took [2]. We moved
away from that for a number of reasons, including a more verbose syntax,
an additional level of abstraction, and because we plan on introducing
new attribute value syntax anyway.

What you're suggesting can be done using CSS or paint servers
(gradients, solidColor, etc.) in combination with Params, i.e. the
'param()' functional notation is used for the gradient or solidColor,
which is referenced by the target element (the value is "pulled" by the
target element), or for the CSS values which are applied to the target
elements via selectors (the value is "pushed" onto the target element by
the class).

> Miscellaneous points and extra suggestions:
>
> C1. I have modified the example to apply the 'outline' value to the fill
> of the <text> element too, to demonstrate using a parameter in more than
> one place. (And I lazily used the same <paramDef> element name for the
> child element, which is probably inadvisable, but I couldn't think
> of a good alternative quickly.)
>
> C2. This example references elements by ID, but XPath could be offered as
> an alternative.

CSS selectors are a similar mechanism to XPath, and more broadly
implemented, in browsers at least.

> C3. The last <paramDef> element refers to the content of the <text> element.
> This is (supposedly) implied by the absence of an 'attribute' attribute,
> but it could be done in a more explicit way.

Though I don't like using CSS-injected text content, that could be used
as well.

> C4. Elements defining parameters could be further nested, to group related
> parameters. This could be convenient where many parameters are declared.
> This would result in hierarchical names, for which a dot notation might
> be suitable (eg. "may.percent" and "may.color", in your bar chart example).
>
> C5. The passing on of parameters to other documents with parameters (as per
> point B8 above) would probably demand its own extra constructs.
>
> C6. To support the referencing of a single element (as per point B10,
> above),
> any SVG element could be allowed to contain a <paramDefs> element.
>
> C7. Parameters could be used for more than just passing values directly to
> attributes and properties. Two possibilities:
>
> (a) Conditional logic. For example, a parameter definition could say
> that if parameter "side" equals "left" then change an attribute
> in one element, else change an attribute in another.

This is well down the side of the slippery slope... I don't want Params
to become a Turing-complete feature.

At the very most, I would suggest using <switch> elements with a new
evaluation attribute, but for v1, I think that goes too far.

> (b) As the basis for calculations, which could be useful for laying out
> elements. For instance, in your 12-month bar chart example in Part 1,
> you could have a "column-width" parameter that is used to calculate
> the position of each column. (In the preamble to that example you
> admit that parameters as specified have limitations; enhanced
> <paramDef> elements could overcome some of these limitations.)

That should fall more into the realm of SVG Layout, possibly in
conjunction with SVG Params.

> There are likely to be other interesting possibilities - which can be
> added relatively easily because they are merely additions within the
> <paramDefs>. The "param(...) ..." construct slams the door shut against
> such possibilities.

No, it doesn't... we could always add these features for use with the
abstraction of paint servers, CSS, etc. if experience shows that they
are needed.

> This approach offers several advantages:
>
> Ad1. The new parameter-related elements are the *only* changes. No
> attributes
> or properties in existing elements need be changed. There is no need
> for the "param(...) ..." construct, nor the "content-value" attribute.

As mentioned, the "param(...) ..." construct matches the planned growth
of SVG.

> Ad2. All the parameters are declared in one place, at the top of the
> document. So it's easy to see what they all are.

This can be done with the existing proposal as well, as explained above.

> Ad3. The parameter-related elements provide a place to *document* the
> parameters (which the existing specification does not provide).

Comments can be placed at any place in the document to explain these,
and exposing the list of param keywords through the API is more
programmatically useful.

> Ad4. Checking parameters for consistency involves checking just the content
> of the <paramDefs> element and the elements its descendents refer to,
> rather than the whole document tree.

I'm not sure why this is a particular advantage.

> Ad5. Future enhancements have a good chance of being localized to the
> parameter-related elements, rather than potentially involving further
> rounds of changes to all attributes in all elements.

What sort of enhancements?

I'm not trying to be negative, but I don't see your proposal as
substantive more powerful or specifically easier to implement, and it
seems much more complicated and abstract to author. The SVG WG will
discuss it, of course, and may have a different opinion than I do.

I do appreciate your thought-provoking comments, and I think the spec
will be improved by them. I will try to make an updated version of the
spec that reflects the changes I've agreed to in the next few weeks, and
I'll notify you and www-svg when I have.

[1] http://www.w3.org/TR/SVGParamPrimer/#param-el
[2] http://dev.w3.org/SVG/modules/ref/master/SVGRefPrimer.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Parameters] specifications feedback

2009-12-08T17:16:54Z

Doug,

Here is some feedback on your Parameters specification "SVG Parameters 1.0, Part 2: Language" (undated, but last modified 10th June 2009). I am not commenting on Part 1, because I believe that Part 2 gives me the opportunity to make every point of substance I have. I've divided my comments into two parts for readability, plus a third proposing a different way of declaring parameters.

Steve.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A. Comments on Part 2, "Use Cases and Requirements" section
===========================================================
A1. Requirements and use cases ought to precede everything else - and be
     written before you consider what might be the best solution to them :)
     - so I find it strange that they are deferred to the second document.

A2. "Usage Scenarios": This list of usages is helpful, but since they're
     examples they are merely anecdotal. They don't constitute a statement
     of the goals for parameters, which is lacking. The closest you come is
     saying in the Abstract of Part 1 that they're for "re-using a resource
     several times with specified variations", but this is vague and open
     to many interpretations.

    In recent emails, Doug, you have stated that you want to keep the
     Parameters specification simple. But without clearly defining what
     parameters are for, one cannot make an objective judgment of whether
     what's currently specified is adequate, nor whether suggestions for
     extra sophistication are good value or not. BTW, when you say enhancements
     could be added in future, what do you mean? SVG 3.0 in 2017? :^)
     You ought to do you utmost to get it right first time.

    In any case, the ability to add more sophistication in future without
     major disruption would be a useful requirement to add.

A3. "Usage Scenarios": Simplicity in the Parameters specifications is one
     thing; simplicity in the documents that use parameters is something
     else. How many parameters might document authors end up using in a
     single document? All your examples are simple (which is fine), but
     it's not hard to envisage parameters numbering in the dozens. A
     single flat list is less than ideal when it grows longer than, say,
     eight or ten.

A4. "Adapt text to use": This is potentially very useful, but might quickly
     become unwieldy if you have more than one or two text parameters
     (especially when passing via a URL, or for long pieces of text). Some
     authors might be tempted to use this to achieve multi-lingual text,
     which is probably not a good idea.

A5. "Usage Scenarios": The previous point leads me to suggest that you
     investigate possible usage scenarios in more detail: if (sorry, when!)
     you give document authors this parameters facility, what uses might they
     put it to that you haven't thought of? You wouldn't want any nasty
     surprises. Perhaps you could invite suggestions. Some usages could
     be horrible bastardizations. Some might be worth considering in their
     own right, to allow them to be achieved in a cleaner and easier way.

    When investigating in more detail, you ought to create examples that
     are as complex as authors might create in real life. (A 12-month
     bar chart with 6 parameters per month?) The existing examples are
     so simple that they don't tell you much about usage in practice.
     How do parameters scale up? Just how long might long URLs become?
     (Longer than you anticipate, I anticipate.)

A6. "Special Considerations for SVG Parameters", "Implementation
     commitments": For all you say about keep Parameters simple, I
     believe that implementing them as specified is likely to involve
     considerable effort - because of the sheer number of attributes
     that must support the "param(...) ..." syntax. (Would the major
     implementers care to consider this and give us their verdicts?)

A7. Following on from A6, I suggest that the Working Group ponder
     whether any other forthcoming SVG enhancements have a similarly
     wide impact upon existing attributes en masse, so that implementers
     can make all these changes in one go. I have in mind the potential
     for the layout specification to introduce expressions. (I live in
     hope!)

A8. "Special Considerations for SVG Parameters", "Ease of authoring":
     The first consideration is to make it easy for authors to know
     what parameters are available to them when they re-use a particular
     SVG document. I have more to say on this below, because it is a
     consideration I believe is not satisfied at present.

A9. "Requirements", point 1.1: Remove the "(but not limited to)" clause.
     It renders this requirement open-ended, which is unacceptable. Adding
     a new means of passing parameters constitutes an extra requirement.
     (Each existing means ought to be regarded as a distinct requirement too.)

A10. "Requirements", points 2 and 3: Yes, you need to say more about
      scripting and animation! Nasty complications might lurk in both
      places, and you need to flush them out as soon as you can.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B. Comments on Part 2, "Definitions and Basic Data Types", "Syntax" section
===========================================================================
B1. I find that this document lacks structure. There are two distinct parts
     to Parameters: usage (the documents that refer) and declaration (the
     documents that are referred to). I think everything would be clearer
     if you had two clear top level sections accordingly. The "Syntax" section
     launches into the declaration aspects without introducing that that's
     what it's doing.

    (Actually, if you do choose to restructure Part 2, you could also consider
     merging Parts 1 and 2 into a single document. Two documents are not
     warranted for reasons of size, and a single document would allow you to
     avoid the repetition that is necessarily present now.)

B2. Further to B1, the subject of parameters would be easier to write about
     if we had clear terms for the 'usage' documents and for the 'declaring'
     documents. (I'm finding it hard to decide how to refer to them in this
     email. For want of something better, I call them the 'usage document'
     and 'declaring document' respectively.)

B3. "The 'param' Attribute", fourth paragraph: In order to stress how pervasive
     this change is, you ought to highlight as boldly as you can the statement
     that the "param attribute value must be available as a value on any SVG
     attribute". Further, I would change 'any' to 'every', and add "on every
     SVG element". The implications of this are considerable: potentially large
     development effort by implementers (and perhaps even more for authoring tool
     developers), extra tests for every attribute in every SVG element, and
     ... what else? (My proposed alternative, described below, avoids all
     of these changes.)

B4. "The 'param' Attribute": Any changes you make to attribute values ought
     also to apply to property values too, for consistency. Am I correct in
     believing that to date the values allowed in all property values are
     identical to the values allowed in the equivalent attributes? If so,
     this commonality should be maintained.

B5. "The 'param' Attribute", fifth paragraph: You are correct that this section
     needs a lot of work. This section deals only with the local syntax for
     declaring a single parameter, which is relatively straightforward. A
     separate topic, which deserves a new section in its own right, is
     interactions between multiple parameter declarations. Topics that need
     addressing include:

      (a) Multiple parameters with the same name. This is useful and is
           presumably acceptable, to allow one parameter to affect multiple
           parts of the re-used document at once. For example a 'color'
           parameter could set the color of several sub-elements.

      (b) Inconsistencies between parameters with the same name. For example,
           if parameter name 'p1' is a color attribute in one place and a
           co-ordinate in another, then ... well ... something's gonna break.
           A declaring document is in a position to detect such inconsistencies
           - but only by navigating the whole document tree to find all
           parameter declarations.

B6. "The 'param' Attribute", fifth paragraph: Point B5 (b) leads to the subject
     of error handling, which I think your specification ought to address explicitly.
     The validity of a parameter value written in a 'usage' document can only be
     determined by reference to its declaration in a separate document. This could
     lead to errors that aren't easy to explain to the user (especially since they
     may otherwise have no cause to look into the declaring document; indeed, one
     of the benefits of parameters is that they don't need to). This is an area
     where implementers need to take extra care with their error messages. Perhaps
     the Parameters specification could lay down some guidelines.

B7. "The 'param' Attribute", fifth paragraph: Further to B6, one source of errors
     in parameters is in data typing: an attribute might expect a color, but be
     given a length. Such errors are usually straightforward to deal with, but
     the fact that the value is supplied by one document and validated with
     reference to another introduces an extra level of complexity.

B8. Another situation to consider is an SVG document both declaring and
     using parameters. That is, a declaring document could refer to other
     documents that use parameters. This would appear to cause no problems
     if each usage is treated as self-contained. But might document authors
     want the parameter mechanism to percolate down the chain of referenced
     documents? For instance, if document A uses a parameter 'p1' in document
     B, and document B uses a parameter 'p1' in document C, should the same
     value of p1 passed from A to B also be passed to C? (I hope you can follow
     that.)

    Your 12-month bar chart example in Part 1 might benefit from a two-level
     declaration of this kind (especially if you wished to make it more complex):
     one document for the bar chart and a separate one for a column.

B9. The 'parameters' property: Good luck to anyone who attempts to animate
     a list of parameters! I suspect that specifiers of standards have a
     tendency to throw in any feature which is easy for them to write. Making
     a property inheritable and animatable is for you a matter of a few
     keystrokes. Ditto your policy of making every new attribute a property
     (which I dislike, find ridiculous for some attributes, and regard as
     not in the spirit of the original SVG standard). Do you adequately consider
     the implications each time you slip in (or copy in) such innocuous words?
     Conscientious as you are, you're not superhuman, so I imagine you can't.
     If in doubt, leave it out! Deliver on your promise to keep parameters
     simple! :)

And one more suggestion which I'll put here to save me creating a whole new section for it:

B10. You use parameters to reference a whole SVG document. There's no reason
      why you couldn't reference a single element. This would allow multiple
      related 'referencable' elements to be placed in one document, which
      would give authors more flexibility, reduce the number of documents,
      potentially reduce the number of resources that need to be loaded, and
      allow these elements to share the same <defs> element (thus avoiding
      repetition).

     To do this would complicate the URL format to include the ID of the
      element to reference - but that's not a big deal.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proposal for an alternative to "param(...) ..." attribute values
================================================================
Rationale: The problem of discovering what parameters can be passed to a particular declaring document led me to consider the analogy with programming languages. Functions in high level programming languages typically (always?) declare all their parameters at the beginning, which makes it clear what parameters to pass. A programming language that let you declare parameters anywhere in the body of a function's code would be considered very strange. Isn't that what the Parameters specification does?

(Another analogy is to the animation of attribute values: SVG sensibly has separate animation elements, rather than attempting to pack the definition of an animation into an attribute's value - which is effectively what "param(...)" does for parameters.)

An alternative is to declare all an SVG document's parameters in one place, as near the beginning of the document as possible - perhaps in the <defs> element. The declaration of a parameter needs a name plus references to one or more attributes that its value can be passed to. (An attribute value is not needed, because each attribute's normal value plays this role.)

The equivalent of the SVG document in the "Passing Values to SVG Files" section in your specification Part 1 might be something like:

<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
    viewBox="0 0 110 40" width="100%"
height="100%">
  <defs>
    <paramDefs>
      <paramDef name="color"
elementId="button_rect" attribute="fill"/>
      <paramDef name="outline"
elementId="button_rect" attribute="stroke">
        <paramDef
elementId="button_label" attribute="fill"/>
      </paramDef>
      <paramDef name="label"
elementId="button_label"/>
    </paramDefs>
  <defs>
  <title>Reusable Button</title>
  <desc>Takes parameters from parent document's embedding
element.</desc>
  <g>
    <rect id="button_rect" x="5"
y="5" width="100" height="30"
rx="15" ry="15" 
      fill="blue"
stroke="navy" />
    <text id="button_label" x="55"
y="30" text-anchor="middle" 
      font-size="25"
fill="black" font-family="Verdana">
      button
    </text>
  </g>
</svg>

Miscellaneous points and extra suggestions:

C1. I have modified the example to apply the 'outline' value to the fill
     of the <text> element too, to demonstrate using a parameter in more than
     one place. (And I lazily used the same <paramDef> element name for the
     child element, which is probably inadvisable, but I couldn't think
     of a good alternative quickly.)

C2. This example references elements by ID, but XPath could be offered as
     an alternative.

C3. The last <paramDef> element refers to the content of the <text> element.
     This is (supposedly) implied by the absence of an 'attribute' attribute,
     but it could be done in a more explicit way.

C4. Elements defining parameters could be further nested, to group related
     parameters. This could be convenient where many parameters are declared.
     This would result in hierarchical names, for which a dot notation might
     be suitable (eg. "may.percent" and "may.color", in your bar chart example).

C5. The passing on of parameters to other documents with parameters (as per
     point B8 above) would probably demand its own extra constructs.

C6. To support the referencing of a single element (as per point B10, above),
     any SVG element could be allowed to contain a <paramDefs> element.

C7. Parameters could be used for more than just passing values directly to
     attributes and properties. Two possibilities:

     (a) Conditional logic. For example, a parameter definition could say
          that if parameter "side" equals "left" then change an attribute
          in one element, else change an attribute in another.

     (b) As the basis for calculations, which could be useful for laying out
          elements. For instance, in your 12-month bar chart example in Part 1,
          you could have a "column-width" parameter that is used to calculate
          the position of each column. (In the preamble to that example you
          admit that parameters as specified have limitations; enhanced
          <paramDef> elements could overcome some of these limitations.)

    There are likely to be other interesting possibilities - which can be
     added relatively easily because they are merely additions within the
     <paramDefs>. The "param(...) ..." construct slams the door shut against
     such possibilities.

This approach offers several advantages:

Ad1. The new parameter-related elements are the *only* changes. No attributes
      or properties in existing elements need be changed. There is no need
      for the "param(...) ..." construct, nor the "content-value" attribute.

Ad2. All the parameters are declared in one place, at the top of the document.
      So it's easy to see what they all are.

Ad3. The parameter-related elements provide a place to *document* the parameters
      (which the existing specification does not provide).

Ad4. Checking parameters for consistency involves checking just the content
      of the <paramDefs> element and the elements its descendents refer to,
      rather than the whole document tree.

Ad5. Future enhancements have a good chance of being localized to the
      parameter-related elements, rather than potentially involving further
      rounds of changes to all attributes in all elements.

Re: Potential spam/phishing attempt (was "Re: Warning Notice!!!")

2009-12-06T01:17:18Z

Hi again,

I just noticed that I missed including the general W3C contact address
in my message: after originally adding it, I noticed a few more
interesting bits and rewrote the email from scratch. Sorry for the
annoyance/persistence, but I feel that this is an important matter...

The previous message, together with the attachment, is already
available [1] in the archive.

Regards,
Helder

[1] http://lists.w3.org/Archives/Public/www-svg/2009Dec/0008.html

2009/12/6 Helder Magalhães <helder.magalhaes@...>:

> Hi everyone,
>
>
> I'm reporting what appears to be a potential spam/phishing attempt,
> made on behalf of the W3C Webmaster to the www-svg mailing list [1]
> (and, as I'm subscribed to it, to my personal email address).
>
> The full message is attached, as the visible message headers obfuscate
> the true origin of the message (a server located at
> "webmail.xnet.hr").
>
> As I wasn't sure about what the best way to report this, I'm replying
> to the message and also CCing the general address (stated in the
> general contact instructions [2]).
>
> Please take appropriate measures, as the message seems to be
> sufficiently well forged to deceive users: I must confess that I was
> starting to evaluate whether to reply or not; if the message contents
> were a little more coherent (and didn't request the password), I might
> not been convinced to crawl through the original message raw data.
>
>
> Hope this helps,
> Helder
>
>
> [1] http://lists.w3.org/Archives/Public/www-svg/2009Dec/0007.html
> [2] http://www.w3.org/Consortium/contact#otherwise
>
>
> ---------- Forwarded message ----------
> From: W3 Online Team <webmaster@...>
> Date: 2009/12/6
> Subject: Warning Notice!!!
> To:
>
>
> A DGTFX virus has been detected in your folders
> Your email account has to be upgraded to our new
> Secured DGTFX anti-virus 2009 version to prevent
> damages to our email log and your important
> files.
>
> Click your reply tab, Fill the columns below and
> send back or your email account will be terminated
> immediately to avoid spread of the virus.
>
> USERNAME:
> PASSWORD:
> PHONE NUMBER:
> DATE OF BIRTH:
>
>
> Note that your password will be encrypted with
> 1024-bit RSA keys for your password safety.
>
> WARNINGS
> If the above details is not sent you will
> experience login problems after you log out.

Potential spam/phishing attempt (was "Re: Warning Notice!!!")

2009-12-06T01:04:17Z

Hi everyone,

I'm reporting what appears to be a potential spam/phishing attempt,
made on behalf of the W3C Webmaster to the www-svg mailing list [1]
(and, as I'm subscribed to it, to my personal email address).

The full message is attached, as the visible message headers obfuscate
the true origin of the message (a server located at
"webmail.xnet.hr").

As I wasn't sure about what the best way to report this, I'm replying
to the message and also CCing the general address (stated in the
general contact instructions [2]).

Please take appropriate measures, as the message seems to be
sufficiently well forged to deceive users: I must confess that I was
starting to evaluate whether to reply or not; if the message contents
were a little more coherent (and didn't request the password), I might
not been convinced to crawl through the original message raw data.

Hope this helps,
Helder

[1] http://lists.w3.org/Archives/Public/www-svg/2009Dec/0007.html
[2] http://www.w3.org/Consortium/contact#otherwise

---------- Forwarded message ----------
From: W3 Online Team <webmaster@...>
Date: 2009/12/6
Subject: Warning Notice!!!
To:

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

Delivered-To: helder.magalhaes@...
Received: by 10.213.7.69 with SMTP id c5cs683394ebc;
Sat, 5 Dec 2009 20:12:13 -0800 (PST)
Received: by 10.220.122.78 with SMTP id k14mr6426812vcr.97.1260072731729;
Sat, 05 Dec 2009 20:12:11 -0800 (PST)
Return-Path: <www-svg-request@...>
Received: from frink.w3.org (frink.w3.org [128.30.52.56])
by mx.google.com with ESMTP id 13si7447857vws.127.2009.12.05.20.12.09;
Sat, 05 Dec 2009 20:12:11 -0800 (PST)
Received-SPF: pass (google.com: domain of www-svg-request@... designates 128.30.52.56 as permitted sender) client-ip=128.30.52.56;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of www-svg-request@... designates 128.30.52.56 as permitted sender) smtp.mail=www-svg-request@...
Received: from lists by frink.w3.org with local (Exim 4.69)
(envelope-from <www-svg-request@...>)
id 1NH8Sm-0008UG-RK
for www-svg-dist@...; Sun, 06 Dec 2009 04:11:12 +0000
Received: from maggie.w3.org ([193.51.208.68])
by frink.w3.org with esmtp (Exim 4.69)
(envelope-from <webmaster@...>)
id 1NH8Sg-0008Oc-51
for www-svg@...; Sun, 06 Dec 2009 04:11:06 +0000
Received: from jimbo.bnet.hr ([213.149.32.23] helo=jimbo.globalnet.hr)
by maggie.w3.org with esmtp (Exim 4.69)
(envelope-from <webmaster@...>)
id 1NH8SY-0007ul-Av
for www-svg@...; Sun, 06 Dec 2009 04:11:00 +0000
Received: from mail.globalnet.hr (cartman.globalnet.hr [213.149.32.10])
by jimbo.globalnet.hr (Postfix) with ESMTP id A693A2D6067
for <www-svg@...>; Sun, 6 Dec 2009 05:08:01 +0100 (CET)
Received: (qmail 13885 invoked from network); 6 Dec 2009 04:08:01 -0000
X-Mail-Scanner: Scanned by qSheff-II-2.1-r2 (http://www.enderunix.org/qsheff/)
Received: from randy.bnet.hr (HELO webmail.xnet.hr) ([83.139.80.35])
(envelope-sender <webmaster@...>)
by 0 (qmail-ldap-1.03) with SMTP
for <www-rdf-logic@...>; 6 Dec 2009 04:08:01 -0000
Received: from 41.220.75.3
(SquirrelMail authenticated user zrepac)
by webmail.xnet.hr with HTTP;
Sun, 6 Dec 2009 05:08:01 +0100
Message-ID: <6575e4b809e17bc109a0fdcbf10f9fb8.squirrel@...>
Date: Sun, 6 Dec 2009 05:08:01 +0100
From: "W3 Online Team" <webmaster@...>
Reply-To: updatedata@...
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-2
X-Priority: 3 (Normal)
Importance: Normal
To: undisclosed-recipients:;
Content-Transfer-Encoding: quoted-printable
Received-SPF: unknown
X-SPF-Guess: unknown
X-W3C-Hub-Spam-Status: No, score=-1.0
X-W3C-Hub-Spam-Report: BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1
X-W3C-Scan-Sig: maggie.w3.org 1NH8SY-0007ul-Av 48dda530731d3ee9da7bb6a25f6733ce
X-Original-To: www-svg@...
Subject: Warning Notice!!!
Archived-At: <http://www.w3.org/mid/6575e4b809e17bc109a0fdcbf10f9fb8.squirrel@...>
Resent-From: www-svg@...
X-Mailing-List: <www-svg@...> archive/latest/13151
X-Loop: www-svg@...
Sender: www-svg-request@...
Resent-Sender: www-svg-request@...
Precedence: list
List-Id: <www-svg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-svg-request@...?subject=unsubscribe>
Resent-Message-Id: <E1NH8Sm-0008UG-RK@...>
Resent-Date: Sun, 06 Dec 2009 04:11:12 +0000

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

Warning Notice!!!

2009-12-05T20:08:01Z

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

Re: [SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "3. TransformList Extensions"

2009-12-04T01:50:41Z

Hello,

another option would be another name for the attribute
of course. There is already transform, gradientTransform
and patternTransform, one could introduce perspectiveTransform
(or something like this) to avoid conflicts and backward incompatibilities.
Well, still different transform functions can be confusing for some
authors ...
The advantage of another attribute would be too, that this
could act independently from other transformations, as for
example animateMotion already is.

About right handed or left handed coordinate system and the
filter coordinate system: They need not necessarily the same
coordinates, it is just simpler to explain to authors, that z-directions
in different chapters or modules of SVG point in different directions.
Because filters are already part of a recommendation and are already
in use, it is to late to change.
Until it is to late, I think it is preferable to avoid this in the current
drafts. If it is not avoided, it needs to be discussed and noted in all
parts carefully. And still several readers will be surprised by different
directions of the z-axis. We can assume, that several authors are
not very familar with matrices, therefore some careful prose about
what results from the mathematics for the 'simple user' would help
them anyway.
With the proposed z-rendering-order indication there is now a third
part defining a meaning of a z-direction within SVG and maybe with
the CSS-transforms there is a fourth. Looks like a lot of z-directions
for an originally 2D format ;o)
Because we can assume that the spatial sense
of several authors is somehow limited, every confusion may
result in additional frustration.
Personally I have no much problems in switching from left
to right handed systems or from switching the z-direction for
every document, if necessary. But I think, there are less flexible
people having problems with this. Several seem to have already
problems to imagine what are results form a matrix transform ;o)

Olaf

Re: [SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "3. TransformList Extensions"

2009-12-03T23:10:21Z

Hi Dr. Olaf,

Your recent email [1] and Steve's email has prompted me to respond to your
original comments. See me responses inline below.

Cheers,

Anthony

[1] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0082.html

Dr. Olaf Hoffmann wrote:

> Hello SVG WG,
>
> currently this is not an extension of the transform
> list of SVG, it is simply incompatible.
>
> In detail:
>
> For the rotate type in this draft it is specified:
> 'rotate(<rotate-angle> <nx> <ny> <nz> [<cx> <cy> <cz>])'
> with ci indicating the rotation center and ni indicating
> the vector for the rotation
>
> However, even if it is assumed, that current viewers simply
> ignore list items, if there are more than defined for
> SVG1.1 and SVGT1.2, the result will be quite different
> from that of a 'SVG Transforms 1.0' viewer, because
> for SVG1.1 and SVGT1.2 we have:
>
> rotate(<rotate-angle> [<cx> <cy>])
>
> what corresponds here to
>
> rotate(<rotate-angle> 0 0 1 [<cx> <cy> 0])
> or
> rotateZ(<rotate-angle> [<cx> <cy>])
>

Yes. Personally I think this should be changed.

>
> The other question is, what an arbitrary viewer
> really does, if matrix, translate, rotate, scale
> appear with a different number of list items.
> Maybe it is in general a better idea, to use
> completely new types like m3D, t3D, s3D, r3D,
> rX3D, rY3D, rZ3D to avoid confusion. With this
> there is a good chance that several viewers
> will simply ignore the transform attribute
> following SVGT 1.2, if they do not have it
> implemented.
>

The original proposal was to use different names and as you can probably tell I
think the wider community would probably prefer different names as well.

> Else the other way round an 'SVG Transforms 1.0'
> gets problems with the old notation for matrix
> too, because, within this draft one has to
> provide a list of 12 numbers, in SVG1.1 and
> SVG1.2 only 6 numbers.
>
> Maybe it would be helpful to
> provide a feature string for 3D transformations,
> then authors can use a switch to provide some
> useful content for all viewers.
>

This is probably something worth discussing. This would be more of a band-aid
solution and be somewhat inelegant compared to adding new names for the 3D
transforms.

>
>
> The matrix in 1.2.3 represents only a rotation
> with cx=cy=cz=0 ?! -> should be noted.

Ok. Can do.

> Currently the 1.2.3 is referenced to represent
> the complete 3D rotation in the first sentence
> of the rotate defintion.
> I assume that the rotation vector points from
> [cx cy cz] to [nx ny nz] and that the direction
> of the rotation can be determined by the
> right-hand-grip-rule, correct?
> If this is true, SVG Transforms 1.0 seems to
> use a right handed systems, with the z-axis
> pointing into the direction roughly from the
> eye of the user into the screen (perpendicular
> to the screen)

Your assumption is correct. SVG Transforms 1.0 does use the right handed system
with positive z pointing perpendicular towards the screen. The reasons is the
vanilla 2D rotate value specifies an anti-clockwise rotation. Additionally, I
feel it is easier from an authoring point of view to have the perspective point
appear to be behind the screen (thus giving positive z in the direction towards
the monitor). Given that you've made a comment on this, is there anything you
feel should be fixed or clarified?

> Note that SVG filters use a positive z-axis
> pointing from the screen to the eye of the
> user, see for example the definition of
> 'fePointLight' and 'feSpotLight' - this does not
> fit together, has to be checked and in case
> that this observation is true fixed to avoid
> inconsistencies.
>
>

The conflict with filters is something that the SVG Working Group should
probably discuss to see if anything can be done about it. Thank you for pointing
this out.

>
>
> It is further noted for translation:
> 'If <ty> and <tz> are not provided, it is assumed to be zero.'
> It think, this should be something like:
> 'If <ty> or <tz> are not provided,
> the missing items are assumed to be zero.'
>
> Correspondingly for scaling:
> 'If <sy> and <sz> are not provided, it is assumed to be equal to <sx>.'
> ->
> 'If <sy> or <sz> are not provided,
> the missing items are assumed to be equal to <sx>.'
>

The wording sounds fine to me.

>
>
> Best wishes
>
> Olaf
>
>
>

Minutes, SVG Telcon, 3 Dec 2009

2009-12-03T13:48:18Z

http://www.w3.org/2009/12/03-svg-minutes.html

---

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

03 Dec 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/12/03-svg-irc

Attendees

Present
[IPcaller], ed, Shepazu, anthony, +39.524.9.aaaa

Regrets
Chair
Erik

Scribe
anthony

Contents

* [3]Topics
1. [4]Next Face-to-face
2. [5]Action Update
3. [6]Params Feedback
4. [7]DOM3 Events Group
5. [8]Christmas Break
6. [9]Charter
* [10]Summary of Action Items
_________________________________________________________

<trackbot> Date: 03 December 2009

<scribe> Scribe: anthony

Next Face-to-face

ED: Currently JW may have problems traveling to Australia
... looking at having the meeting in Europe
... around Jan - Feb

CL: Will he be shifting around that time?

DS: Not before Feb
... we could catch JW before he moves
... He's currently near Amsterdam
... Need to check if this is ok with him

Action Update

ED: I was doing a couple of actions
... master to publish scripts don't seem to be giving me all the
right files
... I think I fixed the Java bindings
... have a couple of fixes that I would like to get into the publish
version
... working on extracting test cases for getIntersectionList

CL: ACTION-2664 I worked out what the transfer codes for RGB
... I plotted those in SVG
... if you have 8 bit resolution you can't see any differences
between the different RGB gamuts
... sending an email

AG: Need to complete the full page

<ChrisL> email sent -
[11]http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/005
4.html

[11] http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0054.html

AG: was going to use the Tiny script and modify it

<shepazu> ACTION-2203?

<trackbot> ACTION-2203 -- Doug Schepers to add to the 1.1 Full
errata that the initial value for the root overflow property is
scroll rather than hidden -- due 2008-09-30 -- PENDINGREVIEW

<trackbot> [12]http://www.w3.org/Graphics/SVG/WG/track/actions/2203

[12] http://www.w3.org/Graphics/SVG/WG/track/actions/2203

<ChrisL>
[13]http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/att
-0054/sRGB3.svg

[13]
http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/att-0054/sRGB3.svg

<ed>
[14]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#overflow_
visible ?

[14] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#overflow_visible

CL: I've updated links in the spec relating to ACTION-2664 so they
point to a PDF containing the information

DS: Any feedback on 'Overflow Visible' errata?

ED: What about reference markers and patterns?
... David was complaining about when you have an SVG inside another
SVG

DS: No I think it was the reverse
... I think the main change I made was to say that the root SVG
element is
... now visible as declared in CSS2 overflow
... and then I said with a child element (including child SVG,
pattern and marker) it's hidden
... so that action is complete

CL: I did an update on ACTION-2682

<ChrisL> Update on ACTION-2682'

<ChrisL>
[15]http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-repor
t.html

[15] http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html

CL: That's the latest update on the implementation report
... Erik has an action relating to types-dom-02-f
... For painting-stroke-10-t we could back out the change

<ChrisL> painting-stroke-10-t is still an issue, stroking zero
length paths. no imp does this yet

CL: and leave it for the next version of the errata
... this would be the only one to roll back assuming you split
types-dom-02-f

ED: We get a pass from Opera and probably Batik

<ChrisL>
[16]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-tref-02-b.svg

[16] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-tref-02-b.svg

<ChrisL> please run in webkit

<ChrisL> crash! excellent

DS: Crashed webkit

CL: I didn't know what 'X' meant in the sheet

<shepazu> ☠

<shepazu> ?

CL: Tests almost done

<ed>
[17]http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_
Edition

[17] http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

ED: Only 3 or 4 left to review
... I will get to the IntersectionList ones soon

Params Feedback

DS: Dr Olaf sent in an email
... 1. Suggested syntax for the params URL
... It was a bit verbose, but we will have to do something like
#params and name value pairs
... First change is reasonable
... 2. Rather than have explicit params to be laid out in a
document. You allow the author to select and identify
... any element and then change an attribute in that
... But it's basically inventing CSS in a URL string
... the idea of params is have structured documents with exposed
attributes
... and allow them to be changed by other documents
... 3. He said it was too simple and he'd like to insert fragments
into the whole document
... I received similar feedback off list suggesting that params was
too simple
... But it's out of the scope of params
... Should use XSLT to do stuff like that
... I don't want to increase the complexity of the specification
... These are my initial reactions to the feedback

CL: I think sticking CSS in a URI string is pretty weird.

DS: Although we had an idea of forcing a style sheet on something

CL: I wouldn't do that necessarily by URI

<shepazu> mysvg.svg#params({color1:blue; fade:0.5;})

<shepazu> mysvg.svg#params(color1:blue; fade:0.5;)

ED: Something like that

DS: I think that idea is ok, because you can have a property bag
... and it would be easy to pass in values
... I'd be open to that idea
... I don't really want to rely on the URL string only
... CSS would probably like that syntax because it's probably the
only way it can be done with CSS

AG: So 'params' would be a reserved word?

DS: Yes
... I like the JSON syntax idea
... with the property bag

ED: Would that be similar to what Dr. Olaf suggested?

DS: No different. A person wouldn't need a 'param' key word
... they could access any element id

<ed>
[18]http://dev.w3.org/html5/spec/Overview.html#attr-iframe-seamless

[18] http://dev.w3.org/html5/spec/Overview.html#attr-iframe-seamless

DOM3 Events Group

DS: We decided not to meet for the remainder of the year

ED: I don't mind having meetings in the next week

DS: What about saying we do the next two telcons then work on list
... I never pushed integration spec
... because there were too many bugs with it
... I can push it before Christmas
... The tables are pretty much ready

RESOLUTION: We agree to publish the Integration specification

DS: DOM 3 Events is thinking deprecating DOMActivate
... because at this point 'click' pretty much does everything that
DOMActive does anyway
... having that complicates the model
... so we are thinking of extending 'click' to cover DOMActivate
completely

CL: I think it's a reasonable idea
... in practice they've almost been the same thing

DS: We should simplify it to say just use 'click'
... As long as you say 'click' just doesn't mean click
... I believe Opera implemented DOMActivate

ED: I think we have code to handle it but we don't dispatch it
... I don't object to the change
... I'd be happy having it behave like 'click'
... or have it replaced by 'click'
... There is very little code that would break in practice if we did
that

DS: I think you would find more on Mobile SVG content

RESOLUTION: SVG Working Group is ok with deprecating DOMActivate as
long as the accessibility people are happy with this also

Christmas Break

DS: So we were meeting for telcons next
... and then that's it until January

AG: Which date?

DS: Early. Anthony can you clarify which dates you get back from
holidays

Charter

DS: I'm simplifying the charter
... and I updated it
... I will try to get the charter to you guys before the end of the
year
... I want to put it in front of the AC soonish
... I've put my two deliverables in the charter
... if there is anything else that you guys think of let me know

trackbot, end telcon

Summary of Action Items

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [19]scribe.perl version 1.135
([20]CVS log)
$Date: 2009/12/03 21:36:54 $
_________________________________________________________

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

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [21]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/firles/files/
Succeeded: s/gradients/markers/
Succeeded: s/intersection/IntersectionList/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: [IPcaller], ed, Shepazu, anthony, +39.524.9.aaaa
Present: [IPcaller] ed Shepazu anthony +39.524.9.aaaa
Found Date: 03 Dec 2009
Guessing minutes URL: [22]http://www.w3.org/2009/12/03-svg-minutes.html
People with action items:

[22] http://www.w3.org/2009/12/03-svg-minutes.html

End of [23]scribe.perl diagnostic output]

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

Re: SVG param(eters)

2009-12-01T09:18:44Z

Hi, Dr. Olaf-

I'd prefer not to go in this direction. Yes, this is more powerful...
but if you want this much power and flexibility, you should probably be
using javascript or clientside XSLT to manipulate or transform the DOM.

The goal of Param is to provide a very simple, intuitive model that is
easily understood even by people who don't know SVG, and is easily and
interoperably implementable. Introducing complexity of this degree
risks crossing that rubicon.

I've heard other feedback that Param should be made more powerful, in
much the manner you describe. But I believe that what we have right now
hits the sweet spot between utility and complexity. These are
interesting ideas for a later expansion, or even for a wholly different
mechanism, but I want to resist complicating Param beyond its original
scope, at least for v1.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Dr. Olaf Hoffmann wrote (on 12/1/09 6:38 AM):

> Doug Schepers:
>>I'm not terribly fond of entities myself... why not simply set the
>>textcontent of the addressed element?
>
> Well, the usual entity construction is not very friendly for authors,
> but if you want just a part of an element content changed
> or more than one part changed independently from others -
> or think about a value list for animation, if you do not need to
> change all values, just one or two. Or within path data one can
> add a subpath for example reversing 'inside' and 'outside'
> and so on. This is a very powerful tool.
> For text content else one has to work around this limitation to
> the complete content with a lot of tspan or tref - possible too for
> graphical text content, but currently not for the alternative text
> content like that of title and desc.
>
> But of course, with a general approach there can be both
> relatively simple options with limited possibilities covering
> major use cases and some advanced options for
> 'experts' or advanced users with much less limitations.
> Authors can learn to use it, starting with the simple options,
> still having the chance to do more interesting things later.
> And this entity 'injection' looks like a very general option to
> change content. Of course, it has the potential to
> corrupt the document structure as well, if the wrong
> things are inserted. This would be an obvious
> argument against this general entity approach.
> The approach for the direct change of attribute values
> of identificable elements can contain a check frome
> the viewer for valid values of course.
> Indeed protection rules in the interpretation of such an
> entity feature looks difficult. On the other
> hand, everyone can anyway save any SVG file,
> add some stupid content, which corrupts the file,
> there is no big difference to the approach of corrupting
> the file with stupid parameter values ;o)
>
> Another problematic issue with those dynamic entities is,
> that older programs do not interprete them and they
> may stop presentation due to unkown entities within the file.
> The only - again not very author-friendly - way to
> avoid this, is to say, that only those entities can be
> changed, which have already a fallback value defined
> within the document - with this restriction there might
> be a chance for a check for nonsense as well. The fallback
> is only replaced, if the replacement has the same structure
> as the fallback - but not easy to specify such a rule in detail ...
>
> Indeed, because those entities are very powerful, it is
> difficult to specify how to insert them with such a parameter
> method without creating a possibility to do too much nonsense
> with it.
>
> Olaf

Re: SVG param(eters)

2009-12-01T03:38:08Z

Doug Schepers:
>I'm not terribly fond of entities myself... why not simply set the
>textcontent of the addressed element?

Well, the usual entity construction is not very friendly for authors,
but if you want just a part of an element content changed
or more than one part changed independently from others -
or think about a value list for animation, if you do not need to
change all values, just one or two. Or within path data one can
add a subpath for example reversing 'inside' and 'outside'
and so on. This is a very powerful tool.
For text content else one has to work around this limitation to
the complete content with a lot of tspan or tref - possible too for
graphical text content, but currently not for the alternative text
content like that of title and desc.

But of course, with a general approach there can be both
relatively simple options with limited possibilities covering
major use cases and some advanced options for
'experts' or advanced users with much less limitations.
Authors can learn to use it, starting with the simple options,
still having the chance to do more interesting things later.
And this entity 'injection' looks like a very general option to
change content. Of course, it has the potential to
corrupt the document structure as well, if the wrong
things are inserted. This would be an obvious
argument against this general entity approach.
The approach for the direct change of attribute values
of identificable elements can contain a check frome
the viewer for valid values of course.
Indeed protection rules in the interpretation of such an
entity feature looks difficult. On the other
hand, everyone can anyway save any SVG file,
add some stupid content, which corrupts the file,
there is no big difference to the approach of corrupting
the file with stupid parameter values ;o)

Another problematic issue with those dynamic entities is,
that older programs do not interprete them and they
may stop presentation due to unkown entities within the file.
The only - again not very author-friendly - way to
avoid this, is to say, that only those entities can be
changed, which have already a fallback value defined
within the document - with this restriction there might
be a chance for a check for nonsense as well. The fallback
is only replaced, if the replacement has the same structure
as the fallback - but not easy to specify such a rule in detail ...

Indeed, because those entities are very powerful, it is
difficult to specify how to insert them with such a parameter
method without creating a possibility to do too much nonsense
with it.

Olaf

Re: More Ideas around DOM Constructors

2009-12-01T03:16:23Z

Hey,

On Nov 27, 2009, at 08:28 , Doug Schepers wrote:
> My approach was similar, but didn't rely on a QName-syle approach because of some brittleness there. Here's how I did it [1]:
>
> root.createElement( "use", { href:[ xlinkns, "#my_circle" ], x:30, y:"-30" } );

It doesn't have to be brittle if it's well specified! You could easily state that "xlink" and "xml" are well-known prefixes that are pre-defined. That has the bonus of eliminating the more common uses (having implemented that, I find that it works nicely).

Your above example could hit a bit of a problem:

root.createElement("use", { href: [XLINK_NS, "#a"], href: [XHTML_NS, "#b"] });

So you need to enable using a prefix in the object. I think that it gets annoying quickly as you start working out the details, and more importantly that it breeds confusion.

I'd say go radical:

root.addNS("uni", "http://unicorns-galore.org/ns/pink");
...
root.createElement("path", { "uni:opacity": "none" });

Yes it means that libraries intending to use namespaces have to be smart to not walk on one another's feet. I think that's an acceptable issue given that libraries can be fixed easily, at little cost, and are maintained by people who will understand the issue.

> I would like to move away from the use of the XLink NS, since the promise of the XLink spec never really materialized. There are complications, but I think we can do it.

Yes, it really should go away :)

--
Robin Berjon - http://berjon.com/

Re: SVG param(eters)

2009-11-30T20:31:04Z

Hi, Dr. Olaf-

Dr. Olaf Hoffmann wrote (on 11/30/09 5:59 AM):
>
> or a new related construction:
> some.svg#svgParam(name(value);name2(value2))

That's a good suggestion, we might do something like that.

> or
> some.svg#svgParam(id1.attributeName(attributeValue);id2.attributeName2
> (attributeValue2))
> with id1/id2 fragment identifiers within the document
> the parameter is related to, similar to addressing
> event-values in animations.
> (this needs some more considerations about masking critical characters)

That's also an interesting idea... simply make any attribute of an
addressable element modifiable. We'll take that under consideration.

I have the feeling that this would not make for quite as intuitive an
authoring/reuse experience, but would be more powerful.

> To insert some content in title, desc or text elements, but avoiding larger
> backwards incompatibilities, one could add an additional method to create
> an entity (in doubt overwriting entities defined within the
> document-type-declaration as fallback, except the entities already defined
> by XML of course):
> some.svg#svgEntity(entityName(entityValue);entityName2(entityValue2))

I'm not terribly fond of entities myself... why not simply set the
textcontent of the addressed element?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Minutes, SVG Telcon, Mon 30 Nov 2009

2009-11-30T13:46:24Z

http://www.w3.org/2009/11/30-svg-minutes.html

--

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

30 Nov 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/11/30-svg-irc

Attendees

Present
Shepazu, [IPcaller], ed, +33.9.52.49.aaaa, anthony, jwatt

Regrets
Chair
SV_MEETING_CHAIR

Scribe
Jonathan Watt

Contents

* [3]Topics
1. [4]update on ACTION-2682 (svg errata implementation report)
2. [5]Spec conventions
http://www.w3.org/People/Schepers/spec-conventions.html
3. [6]CVS patch comments
* [7]Summary of Action Items
_________________________________________________________

<trackbot> Date: 30 November 2009

Zakim: who's here?

<scribe> scribe: Jonathan Watt

<scribe> scribenick: jwatt

<ChrisL> zaki, take up agendum 3

update on ACTION-2682 (svg errata implementation report)

<ed>
[8]http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0049
.html

[8] http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0049.html

<ed>
[9]http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/att-
0049/implementation-report.html

[9]
http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/att-0049/implementation-report.html

CL: I sent an email with the implementation report
... if you look in the first column, it styles it in grey if there
are no passes at all
... there are four of those, and we're wondering what to do about
that
... or we can back those out
... and publish 2nd edition with a note that those need traction

<ed> btw, latest "nightly" gogi passes the
[10]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-dom-01-f.s
vg test

[10] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-dom-01-f.svg

<shepazu> [11]http://www.w3.org/Graphics/SVG/WG/wiki/

[11] http://www.w3.org/Graphics/SVG/WG/wiki/

<ed> ED: types-dom-02-f tests some parts that (animVal mutability)
that we didn't errata, it's just testing previous 1.1 behavior

<ChrisL> types-dom-02-f could be split, some is errate related and
some is not. opera passes the erata-elated part

CL: my action would be to figure out which errata need to be backed
out

DS: backing out would not mean that the errata are lost, only that
they would go to a 3rd Edition errata

<shepazu>
[12]http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_
Edition

[12] http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

<ChrisL> Stroking subpaths of zero length painting-stroke-10-t.svg

<ed> ACTION: ed to split types-dom-02-f.svg into two tests, one part
testing animVal, one testing the rest (errata parts) [recorded in
[13]http://www.w3.org/2009/11/30-svg-minutes.html#action01]

<trackbot> Created ACTION-2700 - Split types-dom-02-f.svg into two
tests, one part testing animVal, one testing the rest (errata parts)
[on Erik Dahlström - due 2009-12-07].

<ChrisL> Firefox nightly 20090929 is elderly

<ChrisL> jwatt: firefox trunk passes i think

<ChrisL> ... oh, no it doesn't

<ChrisL> References to characters in SVGTextContentElement should be
UTF-16 code units text-dom-02-f.svg

<ChrisL> text-dom-02-f.svg opera gogi and safari pass the top 3
subtests.

<ed> safari 4.0.3 passes first and third subtests

<ChrisL> firefox nightly passes 1 and 4

<ChrisL> [14]http://en.wikipedia.org/wiki/Linear_B

[14] http://en.wikipedia.org/wiki/Linear_B

JW: it might be a good idea to to use a TTF/OTF/WOFF font instead of
SVG fonts so the test is only testing what it purports to be testing
... because lack of SVG fonts will mean these DOM methods will not
pass
... I mean they could pass, but the test will fail because of lack
of SVG font support

<scribe> ACTION: ChrisL to split the test [recorded in
[15]http://www.w3.org/2009/11/30-svg-minutes.html#action02]

<trackbot> Created ACTION-2701 - Split the test [on Chris Lilley -
due 2009-12-07].

<ChrisL> fixed in tracker to be meaningful

Spec conventions
[16]http://www.w3.org/People/Schepers/spec-conventions.html

[16] http://www.w3.org/People/Schepers/spec-conventions.html

DS: I was talking to Ian Jacobs about having standard conventions
across specifications so that people could transfer knowledge
between specifications
... I adopted some of the conventions from the SVG for DOM Events
... the above document would change what SVG is doing too in our
next version of the spec

<ChrisL> www-archive@...

DS: I took the convention discussion to www-archive since that seems
to be the w3c's general discussion list

<shepazu>
[17]http://www.w3.org/People/Schepers/spec-conventions.html

[17] http://www.w3.org/People/Schepers/spec-conventions.html

DS: what do you think?

CL: I think it's a good idea in general, and it certainly means
people need to learn less if they have an interest in more than one
specification
... in general I think it's good work

AG: I think it's good

DS: as long as people are using the markup conventions they can
restyle if the default style doesn't work for them for some reason
... we can't simply say that there's one stylesheet that you
reference
... there will be a supplementary stylesheet
... would the SVG WG be willing to adopt this?
... whatever specs I'm editing I plan to use this for
... there are also conventions about putting an id on things you
call out, since if they are that important they should be linkable
to

JW: it sounds good in principle, but I'm minuting so haven't looked
at the doc
... is this still a work in progress, will it change a lot?

DS: I don't think it will change a lot
... at least not the markup
... the styles will probably change

Carl proposed two different types of issue

scribe: so I separated out blocking issues

Hixie suggested a change to use XXX

Bert on the chairs list proposed changes

I incorporated those

Fantasai suggested improvements to the semantic markup

which I added

using <em> rather than <span> for example

I got a bit of pushback about that from Gregory at Opera

but accessibility people were behind it

CL: I think using <em> is overloading it, but I can understand where
the accessibility people are coming from if it makes things easier
for them given the current state of the art with screen readers
... is it the right time to start changing "real" documents right
now, or should we wait a while

JW: that's where I was coming from

DS: well in my experience you need to use it to start getting
feedback, good or bad
... so I think we should start using it to get focus on the issue

CL: I think that's fine

RESOLUTION: The SVG WG will start using the conventions proposed by
Doug

CVS patch comments

ED: for small typo type things I find patch files very useful

DS: I prefer to see things inline, not in the form of a patch
... I think it's just as easy to quote the offending text in an
email
... I'm also afraid that in a time of high feedback, if we set a
trend of accepting patches, then something we might not want could
at some point slip through

CL: I'd also prefer an email just saying what text needs fixed

AG: we also have the issue that our internal format is not the final
document we generate
... so patches would probably be patching the wrong document and
therefore be a problem to integrate

<scribe> ACTION: Chris to reply to Helder explaining why we would
prefer not to receive patch files [recorded in
[18]http://www.w3.org/2009/11/30-svg-minutes.html#action03]

<trackbot> Created ACTION-2702 - Reply to Helder explaining why we
would prefer not to receive patch files [on Chris Lilley - due
2009-12-07].

DS: I sent an email to the HTML WG explaining that their current
version of params can only be used with plugins
... mjs sent replied saying he'd discourage use of <object> and
would prefer <iframe>
... I personally don't think that meets the needs of some of the
things people want to use this for
... trying to edit a URL string
... that seems painful to me
... the param element seems the natural way to go to me
... I agree with some of his points including having a good URI
syntax
... but I think param is more user friendly
... and the markup is then much more clear than using encoded URI
strings

ED: I agree it's clearer
... <iframe> doesn't take <param> today

DS: no, but it could

[out of time]

CL: you should keep pushing on params

RSSAgent, generate minutes

thanks

trackbot: end telcon

Summary of Action Items

[NEW] ACTION: Chris to reply to Helder explaining why we would
prefer not to receive patch files [recorded in
[19]http://www.w3.org/2009/11/30-svg-minutes.html#action03]
[NEW] ACTION: ChrisL to split the test [recorded in
[20]http://www.w3.org/2009/11/30-svg-minutes.html#action02]
[NEW] ACTION: ed to split types-dom-02-f.svg into two tests, one
part testing animVal, one testing the rest (errata parts) [recorded
in [21]http://www.w3.org/2009/11/30-svg-minutes.html#action01]

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [22]scribe.perl version 1.135
([23]CVS log)
$Date: 2009/11/30 21:40:02 $
_________________________________________________________

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

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [24]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/someone/Gregory/
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Default Present: Shepazu, [IPcaller], ed, +33.9.52.49.aaaa, anthony, jw
att
Present: Shepazu [IPcaller] ed +33.9.52.49.aaaa anthony jwatt

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 30 Nov 2009
Guessing minutes URL: [25]http://www.w3.org/2009/11/30-svg-minutes.html
People with action items: chris chrisl ed

[25] http://www.w3.org/2009/11/30-svg-minutes.html

End of [26]scribe.perl diagnostic output]

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

Re: [Vector Effects] Minor correction suggestions for the currently available drafts

2009-11-30T09:57:15Z

Hi, Helder-

Helder Magalhães wrote (on 11/30/09 9:29 AM):

>
>> Supplying a CVS patch is clever, but that's not
>> really how we've traditionally take comments...
>
> I'd say CVS patches are much more appropriate for this sort of
> feedback (typos, whitespace and markup issues) than providing a long
> message full of snippets (as I recall doing during the SVG 1.2 Tiny
> LC). It would be great this was formally made a way to provide
> feedback, specially when no relevant text changes are involved; I do
> agree that, whenever significant prose changes are involved, providing
> text snippets is easier to both evaluate and discuss. :-)

Look at it this way: whether you claim that the differences are
editorial typos or not, we still have to review the changes closely to
make sure that your CVS patch doesn't introduce any other errors, or
accidental or deliberate changes that have not been discussed. If we
start accepting CVS patches, I'm afraid that a slip might occur,
especially when we are busier. Note also that the SVG WG has had
problems in the past with some changes being lost because of bad CVS
configurations.

>> I'll leave it up to the
>> editor, but I would personally much rather see a simple corrected document
>> that could be easily reviewed and copy/pasted if necessary.
>
> Yes, of course the editor has a final word on the subject.
>
> If you (or the editor, naturally) prefer that I attach the changed
> HTML files (I'm not sure if that's what you meant in the first place),
> of course I'm happy with it too: it just gets a little harder to tell
> the differences (downloading + performing a diff vs. directly taking a
> look at the patch), but the procedures are more or less equivalent.

CVS patches don't fit well into my current workflow; maybe they work
better for Chris. I admit that they are easier for both commentors and
editors than saying, "In section 3.4, paragraph 2, replace "fo" with
"foo" (though saying, "remove trailing spaces between the end of
sentences and the closing tag" or "use a spell-checker" is higher-level
and easy to do with a text editor). But for me, even better is a full
document that I can visually diff with the original, and accept changes
per item as I see fit.

For what it's worth, having reviewed your proposed patch, I would advise
you against bothering to correct typos, trailing spaces, etc. in the
"Status of This Document" boilerplate (those changes get blown away when
we prepare the document for publication), or in comment blocks that will
not make it into the final draft (marked in that spec with the class
"editor-note").

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: [Vector Effects] Minor correction suggestions for the currently available drafts

2009-11-30T06:29:36Z

Hi Doug,

> Supplying a CVS patch is clever, but that's not
> really how we've traditionally take comments...

I'd say CVS patches are much more appropriate for this sort of
feedback (typos, whitespace and markup issues) than providing a long
message full of snippets (as I recall doing during the SVG 1.2 Tiny
LC). It would be great this was formally made a way to provide
feedback, specially when no relevant text changes are involved; I do
agree that, whenever significant prose changes are involved, providing
text snippets is easier to both evaluate and discuss. :-)

> I'll leave it up to the
> editor, but I would personally much rather see a simple corrected document
> that could be easily reviewed and copy/pasted if necessary.

Yes, of course the editor has a final word on the subject.

If you (or the editor, naturally) prefer that I attach the changed
HTML files (I'm not sure if that's what you meant in the first place),
of course I'm happy with it too: it just gets a little harder to tell
the differences (downloading + performing a diff vs. directly taking a
look at the patch), but the procedures are more or less equivalent.

Regards,
Helder

SVG param(eters)

2009-11-30T02:59:27Z

Hello Doug, hello www-svg,

about the param discussion here:
http://lists.w3.org/Archives/Public/public-html/2009Nov/0665.html

why not to extend or to add a new functionality with the syntax
of SVG views like this:
some.svg#svgView(transform(scale(2)))

Parameters are somehow related to an alternative view of
the document, therefore this fits more or less.
The main advantage it, that this method does not depend
on the history or fate of other formats like (X)HTML, only on
something, that already exists in SVG.

http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
http://www.w3.org/TR/SVGMobile12/linking.html#SVGFragmentIdentifiers

Either one could use a new keyword:
some.svg#svgView(param(name(value)))

or a new related construction:
some.svg#svgParam(name(value);name2(value2))
or
some.svg#svgParam(id1.attributeName(attributeValue);id2.attributeName2
(attributeValue2))
with id1/id2 fragment identifiers within the document
the parameter is related to, similar to addressing
event-values in animations.
(this needs some more considerations about masking critical characters)

To insert some content in title, desc or text elements, but avoiding larger
backwards incompatibilities, one could add an additional method to create
an entity (in doubt overwriting entities defined within the
document-type-declaration as fallback, except the entities already defined
by XML of course):
some.svg#svgEntity(entityName(entityValue);entityName2(entityValue2))

Maybe one has to combine all these to be able to use all of these at once:
some.svg#svgView(transform(transformType(transformValue));param(id.attributeName(attributeValue));entity(name(entityValue));etc)

I would prefer the last method, if mixing parameters
with GET-parameters in the query in not accepted
(what would have of course the advantage, that a script on
the server could know too, what happens in the generated
content).

Olaf

Re: [Vector Effects] Minor correction suggestions for the currently available drafts

2009-11-29T14:48:07Z

Hi, Helder-

Thanks for your comments. Supplying a CVS patch is clever, but that's
not really how we've traditionally take comments... I'll leave it up to
the editor, but I would personally much rather see a simple corrected
document that could be easily reviewed and copy/pasted if necessary.

It is good to get such comments early, so it makes critical review at LC
much less painful.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Helder Magalhães wrote (on 11/29/09 12:11 PM):

>
> A few days ago I was taking a look at the vector effects primer [1]
> and ended up catching a couple of typos. Today, I took at look at the
> language [2] and requirements [3] and caught a few more, plus a bunch
> of white-space corrections, minor coherency fixes and such. Yes, I'm
> aware that the documents are at a draft status, but proposing
> corrections/improvements is a Good thing, right? :-)
>
> A patch to the public CVS repository [4] is attached to this message.
> I didn't double check for a specific procedure for providing this sort
> of feedback but, given their relatively low relevance, a patch seemed
> a perfect fit for the job.
>
> One thing that wasn't addressed was the fact that the requirements [3]
> refer to the SVG filters specification. As that can become a source of
> confusion, I'd suggest performing a quick "find and replace" followed
> by a cleanup to the document: IMHO, a stub with a "TODO" note would be
> better. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html
> [2] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
> [3] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsReqs.html
> [4] http://www.w3.org/Project/CVSdoc/#Public

[Vector Effects] Minor correction suggestions for the currently available drafts

2009-11-29T09:11:21Z

Hi everyone,

A few days ago I was taking a look at the vector effects primer [1]
and ended up catching a couple of typos. Today, I took at look at the
language [2] and requirements [3] and caught a few more, plus a bunch
of white-space corrections, minor coherency fixes and such. Yes, I'm
aware that the documents are at a draft status, but proposing
corrections/improvements is a Good thing, right? :-)

A patch to the public CVS repository [4] is attached to this message.
I didn't double check for a specific procedure for providing this sort
of feedback but, given their relatively low relevance, a patch seemed
a perfect fit for the job.

One thing that wasn't addressed was the fact that the requirements [3]
refer to the SVG filters specification. As that can become a source of
confusion, I'd suggest performing a quick "find and replace" followed
by a cleanup to the document: IMHO, a stub with a "TODO" note would be
better. ;-)

Hope this helps,
Helder

[1] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html
[2] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
[3] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsReqs.html
[4] http://www.w3.org/Project/CVSdoc/#Public

SVGVEMinorIssues.patch (17K) Download Attachment

Re: More Ideas around DOM Constructors

2009-11-27T16:58:42Z

Hi, Steve-

Steve Withall wrote (on 11/27/09 6:05 PM):

> At 27/11/2009 06:28 PM, Doug Schepers wrote:
>>
>>> Or perhaps the reliance on the XLink namespace is going away ?
>>
>> I would like to move away from the use of the XLink NS, since the
>> promise of the XLink spec never really materialized. There are
>> complications, but I think we can do it.
>
> Is that why you don't use the standard xlink:href attribute in your
> Parameters specification? :)

Hmmm... I don't *not* use XLink in Params... in the examples where I use
a param() to set a URL, I do use @xlink:href.

I'm not sure where else you would expect to use XLink in Params... it's
a simple name-value pair that's passed in from a URL or another
document, I don't see where XLink is relevant there.

> XLink may not have lived up to expectations, but at least it's familiar
> and everyone knows where they stand with it. I suggest continuing to use
> it where appropriate unless there's a good reason not to.

There is a good reason to discontinue its use in SVG: it complicates
implementation and authoring without adding clear benefits.

I love the idea of arcs and of extended links where there are multiple
destination locations that a user chooses from when they activate a
link, but it's not specified in enough detail to be interoperably
implemented, and in any case, SVG only uses that subset of linking
functionality that is roughly equivalent to HTML links, so unless we
expand SVG's linking abilities in a manner defined by XLink (rather than
some alternate new way), I'm not sure it's worth the added complexity.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: More Ideas around DOM Constructors

2009-11-27T15:05:57Z

At 27/11/2009 06:28 PM, Doug Schepers wrote:
>Hi, -
>
><Snip>
>
>>Or perhaps the reliance on the XLink namespace is going away ?
>
>I would like to move away from the use of the XLink NS, since the
>promise of the XLink spec never really materialized. There are
>complications, but I think we can do it.

Doug,

Is that why you don't use the standard xlink:href attribute in your
Parameters specification? :)

XLink may not have lived up to expectations, but at least it's
familiar and everyone knows where they stand with it. I suggest
continuing to use it where appropriate unless there's a good reason not to.

Steve.

>I don't think the idea of namespaced attributes is going to go away,
>so a good generic API will have to handle them.
>
>[1] http://schepers.cc/w3c/svg/api/cog.svg
>
>Regards-
>-Doug Schepers
>W3C Team Contact, SVG and WebApps WGs

Re: The synchronous load event is trouble

2009-11-27T03:00:39Z

Hello,

I don't know much about scripting, because I do not use it,
however to have a well defined 'time-zero-point' or begin of
the timeline is a requirement for animation and in tiny 1.2 for
the synchronisation of multimedia content and animations as well.
This load event is related to the timeline begin in SVG 1.1.

One needs something like this to get predictable (and testable) results -
and SMIL indicates too, that one has to define this 'document zero time'
somehow.

In tiny 1.2 there are two possible choices now, to be indicated
with the attribute timelineBegin in the start tag of the svg element.
http://www.w3.org/TR/SVGMobile12/struct.html#SVGElement

Do you think, there should be a more flexible choice for authors
to indicate, at which time the timeline begins?
What should the behaviour of the document before the timeline has
begun? Any ideas to provide a predictable behaviour for authors?
Should fit to SMIL of course, for animation it is possible to indicate
a begin before the document timeline has begun, if the animation
ends later than the begin of the timeline.

Dynamic rendering can cause of course more complexity as well
as scripting. But without well defined times the behaviour of a
document is not predictable for authors and those dynamic features
get pretty useless. To have no such event causes even more trouble
for authors.

SMIL and tiny 1.2 provide features for authors to indicate the
precision of synchronisation with external resources , see for example:
http://www.w3.org/TR/SVGMobile12/multimedia.html#Smil2Sync

Olaf

Re: The synchronous load event is trouble

2009-11-26T23:42:10Z

On Nov 26, 2009, at 15:54, Erik Dahlstrom wrote:

> On Thu, 26 Nov 2009 13:13:32 +0100, Henri Sivonen <hsivonen@...> wrote:
>> The event is marked as bubbling and non-cancelable.
>
> 'load' and 'SVGLoad' are both marked as events that don't bubble[1]. Can you please give a pointer to where it says they bubble?

Oops. Sorry. Please disregard the bubbling issue. I read the wrong line in the table when I wrote my email. (I started writing the email about synchronicity and then thought I found a new issue while writing the email.)

My synchronicity concerns stand.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

Re: More Ideas around DOM Constructors

2009-11-26T23:28:39Z

Hi, -

Jeff Schiller wrote (on 11/25/09 2:03 PM):
> Is there a proposal on how to handle attributes in different
> namespaces with DOM Constructors? If we specify a property bag is it
> ok to just do:
>
> { fill: "red", "xlink:href", "foo.html" } ?
>
> As long as xlink: lines up with a declared namespace prefix?

My approach was similar, but didn't rely on a QName-syle approach
because of some brittleness there. Here's how I did it [1]:

root.createElement( "use", { href:[ xlinkns, "#my_circle" ], x:30,
y:"-30" } );

> Or perhaps the reliance on the XLink namespace is going away ?

I would like to move away from the use of the XLink NS, since the
promise of the XLink spec never really materialized. There are
complications, but I think we can do it.

I don't think the idea of namespaced attributes is going to go away, so
a good generic API will have to handle them.

[1] http://schepers.cc/w3c/svg/api/cog.svg

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: The synchronous load event is trouble

2009-11-26T05:54:23Z

On Thu, 26 Nov 2009 13:13:32 +0100, Henri Sivonen <hsivonen@...> wrote:

> SVG 1.2 Tiny says about the 'load' event:
>> The event is triggered at the point at which the user agent finishes
>> loading the element and any dependent resources (such as images, style
>> sheets, or scripts). In the case the element references a script, the
>> event will be raised only after an attempt to interpret the script has
>> been made. Dependent resources that fail to load will not prevent this
>> event from firing if the element that referenced them is still in the
>> document tree unless they are designated as externalResourcesRequired.
>> The event is independent of the means by which the element was added to
>> DOM tree.
>
>
> SVG 1.1 Full says about the event the is handled by the 'onload' event
> handler:
>> The event is triggered at the point at which the user agent has fully
>> parsed the element and its descendants and is ready to act
>> appropriately upon that element, such as being ready to render the
>> element to the target device. Referenced external resources that are
>> required must be loaded, parsed and ready to render before the event is
>> triggered. Optional external resources are not required to be ready for
>> the event to be triggered.
>
>
> The event is marked as bubbling and non-cancelable.

'load' and 'SVGLoad' are both marked as events that don't bubble[1]. Can
you please give a pointer to where it says they bubble?

Cheers
/Erik

[1] http://www.w3.org/TR/SVGTiny12/interact.html#SVGEvents

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

The synchronous load event is trouble

2009-11-26T04:13:32Z

SVG 1.2 Tiny says about the 'load' event:
> The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still in the document tree unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree.

SVG 1.1 Full says about the event the is handled by the 'onload' event handler:
> The event is triggered at the point at which the user agent has fully parsed the element and its descendants and is ready to act appropriately upon that element, such as being ready to render the element to the target device. Referenced external resources that are required must be loaded, parsed and ready to render before the event is triggered. Optional external resources are not required to be ready for the event to be triggered.

The event is marked as bubbling and non-cancelable.

In Gecko, in the XML tree builder, the event is implemented as an event that fires synchronously when the </svg> end tag is parsed. I haven't implemented this event at all in the HTML5 parser in the hope that the SVG WG makes it undesirable characteristics go away.

I think the definition of the event has at least the following three problems:

1) The firing of the event is synchronous with the parse. This is highly unusual. I'm not aware of any other standards-based feature requiring an event to be dispatched synchronously with the parse. Gecko has some non-stardards-based analogous behaviors, but, as I understand it, those behaviors cause scripts to run either from the task queue or from a deferred execution mechanism that isn't fully synchronous but isn't the task queue, either. Having scripts run as the side effect of the parse is generally trouble. It's impossible to eliminate </script> running scripts as a side effect of the parse, but I think we should get rid of all the other cases, so that parsing can be optimized with the assumption that only </script> may cause synchronous script execution (which requires the parser to go into a state that's safe for script execution).

2) The event is defined to be fired at a particular point relative to parse but also relative to network activity. Scripts already have to block the parser for legacy reasons. However, all blocking of the parser due to external resources is bad for performance, so it would be desirable to allow styles to load asynchronously with the parse. As written, the spec text seems to establish </svg> as a point where the parser potentially has to yield to the event loop if there are pending style sheet loads. (I don't know how cross-resource 'use' works, but it seems trouble if those don't attach asynchronously.)

3) As I understand it, a load event dispatched to an <svg> element embedded in an HTML document would bubble to the HTML <body> element and up. JavaScript libraries written for text/html may legitimately assume that the event handled by the 'onload' event handler is dispatched once per document life cycle. It seems to me that adding some embedded SVG to an HTML page has the potential of severely confusing pre-existing JavaScript code that is listening for the traditional HTML load event.

Considering the above, I propose removing the current SVG 'load' event behavior and then adding the following:

A) If the root element is the <svg> element, dispatch the 'load' event to that element the same way the 'load' element is dispatched to the <body> element when <html> is the root element. (I.e. wait for external resources, then dispatch the event asynchronously from the task queue.)

If that's not enough and existing SVG content relies on the 'load' event being dispatched to each nested <svg> element also (I don't know what the legacy constraints are), then also add the following:

B) When the end tag of a non-root <svg> element is parsed, dispatch a *non-bubbling* 'load' event to that element asynchronously from the task queue without waiting for external resources.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

Re: Fwd: Minutes, SVG Telcon, 23 Nov 2009

2009-11-25T12:31:35Z

Hi Doug,

On Wed, Nov 25, 2009 at 1:38 PM, Doug Schepers <schepers@...> wrote:
>
>> Even then it will be harder to re-train people and will be confusing
>> to tell them when to use Document.createElement() and
>> Element.createElement().
>
> It made more sense to me when the methods I defined (with different names)
> simply inserted the created element as a child of the element this method
> was called on.
>

Actually I agree with you. Perhaps then we could do the following:

1) Update document.createElement() and document.createElementNS() to
have that third property-bag argument. These, of course, are the
non-inserting methods.

2) Have new methods on Element that do the inserting:

Element.createChild(elementName, propertyMap, insertionIndex)

As you say, we don't need a namespace-aware method here. This method
creates and inserts a child in the same namespace.

I'd also be ok with 'insertElement' or 'insertChild' or even
'createElement' though I prefer something that immediately implies
that the newly created element will be inserted (i think 'Child' does
that as does, of course, 'insert').

Regards,
Jeff

Re: Fwd: Minutes, SVG Telcon, 23 Nov 2009

2009-11-25T11:38:41Z

Hi, Jeff-

Jeff Schiller wrote (on 11/25/09 2:17 PM):

> <shepazu> shepazu: Jeff may not have considered the issue of the
> namespace of an element when he criticized using createElement as an
> element method
>
> I assume you mean that createElement() as an element method would
> never need to have a namespace argument. Yes, I can see that - but I
> still think that tweaking existing methods (createElement,
> createElementNS) is better than inventing new methods UNLESS you plan
> to have these new methods at the DOM Core level so that HTML coders
> can use them too (not sure if that was the intention).

My hope (and assumption) is that if the SVG WG, implementers, and
community indeed decides that this approach is a good idea, then we
would try to get this as a universal part of DOM Core. Baby steps.

> Even then it will be harder to re-train people and will be confusing
> to tell them when to use Document.createElement() and
> Element.createElement().

It made more sense to me when the methods I defined (with different
names) simply inserted the created element as a child of the element
this method was called on.

But basically, the idea is that the newly minted element takes on the
namespace of whatever node it was created on. So, if you are trying to
create an SVG element, and the root is an SVG document, you could use
either Document or Element (on any of the SVG elements of the document);
if the root is an HTML document, then you shouldn't use
Document.createElement(), you should use Element.createElement() on one
of the SVG elements (if any exist).

I don't think it's that complicated to understand... the created element
is of the same "type" (namespace) as the element/document from which
it's created. createElementNS is retained to explicitly set the "type"
if a suitable element doesn't already exist, but the NS syntax is
error-prone and clumsy, so I'd like for authors to have to use it only
when it's absolutely necessary.

> What I don't want though is different ways of creating SVG elements
> than creating HTML elements ... thus my leaning towards both existing
> techniques of innerHTML and document.createElement/NS.

Totally agreed. We are looking at innerHTML's suitability for SVG and
compound document content, in addition to HTML, and hopefully will be
able to move forward on that soon.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Fwd: Minutes, SVG Telcon, 23 Nov 2009

2009-11-25T11:17:55Z

<shepazu> shepazu: Jeff may not have considered the issue of the
namespace of an element when he criticized using createElement as an
element method

I assume you mean that createElement() as an element method would
never need to have a namespace argument. Yes, I can see that - but I
still think that tweaking existing methods (createElement,
createElementNS) is better than inventing new methods UNLESS you plan
to have these new methods at the DOM Core level so that HTML coders
can use them too (not sure if that was the intention).

Even then it will be harder to re-train people and will be confusing
to tell them when to use Document.createElement() and
Element.createElement().

What I don't want though is different ways of creating SVG elements
than creating HTML elements ... thus my leaning towards both existing
techniques of innerHTML and document.createElement/NS.

Jeff

On Wed, Nov 25, 2009 at 12:46 PM, Doug Schepers <schepers@...> wrote:

> Hi, SVG Folks-
>
> Here are the minutes for the SVG WG telcon of 23 Nov 2009:
>
> http://www.w3.org/2009/11/23-svg-minutes.html
>
> Or as text below:
>
> [1]W3C
>
> [1] http://www.w3.org/
>
> - DRAFT -
>
> SVG Working Group Teleconference
>
> 23 Nov 2009
>
> See also: [2]IRC log
>
> [2] http://www.w3.org/2009/11/23-svg-irc
>
> Attendees
>
> Present
> ed, Shepazu, jwatt, Chris_Lilley, [IPcaller], anthony
>
> Regrets
> Chair
> ed
>
> Scribe
> anthony
>
> Contents
>
> * [3]Topics
> 1. [4]SVG 1.1 2nd Ed
> 2. [5]list activity
> 3. [6]DOM constructors
> * [7]Summary of Action Items
> _________________________________________________________
>
>
>
> <trackbot> Date: 23 November 2009
>
> \me zakim, drop shepazu
>
> <scribe> scribenick: shepazu
>
> SVG 1.1 2nd Ed
>
> <ed> [8]http://www.w3.org/Graphics/SVG/WG/track/products/1
>
> [8] http://www.w3.org/Graphics/SVG/WG/track/products/1
>
> <ed> 12 open issues, 22 open actions
>
> issue-2013?
>
> <trackbot> ISSUE-2013 -- Percentages in clipPath/pattern/filter/mask
> unintuitive -- OPEN
>
> <trackbot> [9]http://www.w3.org/Graphics/SVG/WG/track/issues/2013
>
> [9] http://www.w3.org/Graphics/SVG/WG/track/issues/2013
>
> <ChrisL> issue-2013?
>
> <trackbot> ISSUE-2013 -- Percentages in clipPath/pattern/filter/mask
> unintuitive -- OPEN
>
> <trackbot> [10]http://www.w3.org/Graphics/SVG/WG/track/issues/2013
>
> [10] http://www.w3.org/Graphics/SVG/WG/track/issues/2013
>
> <ed> moved to SVG Core 2.0
>
> Resolution: we will move this to SVG 2.0
>
> issue-2017?
>
> <trackbot> ISSUE-2017 -- Find sane values for getSubStringLength and
> selectSubString -- OPEN
>
> <trackbot> [11]http://www.w3.org/Graphics/SVG/WG/track/issues/2017
>
> [11] http://www.w3.org/Graphics/SVG/WG/track/issues/2017
>
> <ed> ACTION-2325?
>
> <trackbot> ACTION-2325 -- Doug Schepers to propose wording and
> examples for ISSUE-2107 -- due 2008-10-30 -- CLOSED
>
> <trackbot> [12]http://www.w3.org/Graphics/SVG/WG/track/actions/2325
>
> [12] http://www.w3.org/Graphics/SVG/WG/track/actions/2325
>
> <ed>
> [13]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/023
> 9.html
>
> [13]
> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0239.html
>
> <ed> [14]http://www.w3.org/2008/10/23-svg-minutes.html#action02
>
> [14] http://www.w3.org/2008/10/23-svg-minutes.html#action02
>
> ed: heycam didn't see a strong argument either way
> ... what should we do with this? close it or take it up again?
>
> jwatt: acid3 depends on this behavior?
>
> ed: it did at one time
> ... we did change the behavior in the spec for the better
>
> <ed>
> [15]http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html#TextCh
> apter
>
> [15]
> http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html#TextChapter
>
> shepazu: we might look at this more closely in SVG 2.0
>
> ed: right
>
> <ChrisL> i think its closed, for 1.1
>
> jwatt: the current errata makes sense to me
>
> resolution: close the issue
>
> issue-2071?
>
> <trackbot> ISSUE-2071 -- potential security hole involving
> pointer-events, filters, foreignObject, cross-origin IFRAMEs, and
> elementFromPoint -- OPEN
>
> <trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2071
>
> [16] http://www.w3.org/Graphics/SVG/WG/track/issues/2071
>
> resolution: move to SVG 2.0
>
> issue-2113?
>
> <trackbot> ISSUE-2113 -- animate-elem-35 -- OPEN
>
> <trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2113
>
> [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2113
>
> <ed> ISSUE-2213?
>
> <trackbot> ISSUE-2213 -- Some issues in the definition of
> suspendRedraw/unsuspendRedraw/forceRedraw -- OPEN
>
> <trackbot> [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2213
>
> [18] http://www.w3.org/Graphics/SVG/WG/track/issues/2213
>
> resolution: defer to SVG 2.0
>
> issue-2217?
>
> <trackbot> ISSUE-2217 -- How units are resolved on an SVGLength is
> not defined -- RAISED
>
> <trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2217
>
> [19] http://www.w3.org/Graphics/SVG/WG/track/issues/2217
>
> Resolution: move to SVG 2.0
>
> issue-2219?
>
> <trackbot> ISSUE-2219 -- Missing test coverage for SVG 1.1
> properties -- RAISED
>
> <trackbot> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2219
>
> [20] http://www.w3.org/Graphics/SVG/WG/track/issues/2219
>
> jwatt: we should put this off until we decide on the new test format
>
> Resolution: resolve in SVG 2.0
>
> issue-2259?
>
> <trackbot> ISSUE-2259 -- Inconsistent use of <uri> symbol -- RAISED
>
> <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2259
>
> [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2259
>
> <ed>
> [22]http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPa
> thProperty
>
> [22]
> http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPathProperty
>
> ed: didn't we resolve this in second edition?
>
> ChrisL: basically, this is rolling in changes we made in SVGT1.2
> ... it should be easy to do
>
> <scribe> ACTION: ChrisL to make funcURI consistent, and update tests
> [recorded in
> [23]http://www.w3.org/2009/11/23-svg-minutes.html#action01]
>
> <trackbot> Created ACTION-2697 - Make funcURI consistent, and update
> tests [on Chris Lilley - due 2009-11-30].
>
> <ed>
> [24]http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#Interfac
> eSVGViewSpec
>
> [24]
> http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#InterfaceSVGViewSpec
>
> <ChrisL> issue-2263?
>
> <trackbot> ISSUE-2263 -- The attributes on the SVGViewSpec interface
> are underspecified -- RAISED
>
> <trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2263
>
> [25] http://www.w3.org/Graphics/SVG/WG/track/issues/2263
>
> shepazu: we will have to reexamine this in the context of the new
> SVG DOM API, anyway
>
> Resolution: defer to SVG 2.0
>
> issue-2294?
>
> <trackbot> ISSUE-2294 -- Adding an animated length attribute into a
> baseval length list -- RAISED
>
> <trackbot> [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2294
>
> [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2294
>
> jwatt: I was going to write an email about this...
> ... maybe we need some custom error about removing items from the
> original list (readonly)
> ... maybe we should have a "copy" method?
> ... let's address this in the new DOM API
>
> Resolution: move to SVG 2.0
>
> issue-2299?
>
> <trackbot> ISSUE-2299 -- Text on a path layout rules unclear wrt
> startpoint-on-the-path and text-anchor -- RAISED
>
> <trackbot> [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2299
>
> [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2299
>
> ChrisL: I don't think they are contradictory, they seem to be saying
> the same thing in different ways
> ... it's using "start point" for 2 different things...
> ... it's talking about shifting the initial start point
>
> ed: it's ambiguous enough that implementations all do different
> things
> ... but I'm not sure it's critical for SVG 1.1 2nd ed.
>
> shepazu: I want this fixed because it's important... could we start
> a 3rd edition errata in addition to SVG 2.0?
>
> ChrisL: we could do... we need to test all of this better, too
>
> ed: one way to start off easy is to have a straight line as the
> textPath for tests that describe the start point
>
> ChrisL: good idea
>
> resolution: keep as SVG 1.1 3rd edition errata, but duplicate for
> SVG 2.0, to make sure it's addressed in both
>
> issue-2301?
>
> <trackbot> ISSUE-2301 -- Text on a path layout rules unclear wrt
> startpoint-on-the-path and text-anchor (svg2) -- RAISED
>
> <trackbot> [28]http://www.w3.org/Graphics/SVG/WG/track/issues/2301
>
> [28] http://www.w3.org/Graphics/SVG/WG/track/issues/2301
>
> ed: 23 pending actions left
>
> s23 pending actions left/23 pending actions left left left
>
> action-2077?
>
> <trackbot> ACTION-2077 -- Erik Dahlström to test implementations for
> percentage values in clipPath, etc. -- due 2008-07-03 -- OPEN
>
> <trackbot> [29]http://www.w3.org/Graphics/SVG/WG/track/actions/2077
>
> [29] http://www.w3.org/Graphics/SVG/WG/track/actions/2077
>
> action-2203?
>
> <trackbot> ACTION-2203 -- Doug Schepers to add to the 1.1 Full
> errata that the initial value for the root overflow property is
> scroll rather than hidden -- due 2008-09-30 -- OPEN
>
> <trackbot> [30]http://www.w3.org/Graphics/SVG/WG/track/actions/2203
>
> [30] http://www.w3.org/Graphics/SVG/WG/track/actions/2203
>
> action-2404?
>
> <trackbot> ACTION-2404 -- Doug Schepers to add errata item for root
> overflow -- due 2009-01-22 -- CLOSED
>
> <trackbot> [31]http://www.w3.org/Graphics/SVG/WG/track/actions/2404
>
> [31] http://www.w3.org/Graphics/SVG/WG/track/actions/2404
>
> list activity
>
> ed: discussion about transforms, getIntersectionList, DOM
> constructors, image clarification, z-index
>
> ChrisL: I wonder if alex addressed this to their satisfaction?
> ... a good example might help
>
> <ChrisL> suppose a filter brings in a greyscale image with feimage,
> then we do an rgb fecomponenttransfer. that should work
>
> <ChrisL> it wont give an error
>
> <ChrisL> so that is what "as it its promoted to RGBA" means
>
> ChrisL: when we say, "implement as if...", then things that fall out
> of the model still have to work
> ... action to respond to image clarification email with concrete
> example
>
> <scribe> ACTION: ChrisL to respond to image clarification email with
> concrete example [recorded in
> [32]http://www.w3.org/2009/11/23-svg-minutes.html#action02]
>
> <trackbot> Created ACTION-2698 - Respond to image clarification
> email with concrete example [on Chris Lilley - due 2009-11-30].
>
> ed: anthony addressed the transforms issues
> ... Dr. Olaf pointed to his older email... did we address this?
>
> anthony: not sure
>
> ChrisL: Dr. Olaf raised a good point, CSS didn't consider animation
> when they specified angles, which need to be normalized, and since
> they now have animation this affects them too... we should raise
> this with the CSS WG
>
> anthony: I'll take a crack at replying to Dr. Olaf
>
> DOM constructors
>
> <anthony> scribe: anthony
>
> DS: Just started off with basically describing
> ... what we had proposed
> ... because he didn't read the proposal page
> ... just ready the 'what sort of problems we have' page
> ... he also proposed that we use the innerHTML method for larger
> document fragments
> ... and Brois said that innerHTML has been optimised because
> browsers have to parse already
> ... so that's one thing they optermise for
> ... Boris seemed to be have mixed responses about sending in a
> property bag object for element constructors would help the
> performance
> ... I definitely under the impression from taking to implementers
> that setting attributes individually was a huge performance hit
>
> <shepazu> ChrisL: if it's done right, it should be a performance
> gain, and is never a performance hit
>
> CL: It can be an atomic operation
>
> <shepazu> shepazu: and it's much nicer for authoring
>
> DS: It's much nicer for authors
>
> <shepazu> shepazu: Jeff may not have considered the issue of the
> namespace of an element when he criticized using createElement as an
> element method
>
> <shepazu> shepazu: jwatt, what's your impression?
>
> <shepazu> jwatt: boris seemed to refute some of the performance
> points that Jeff pointed to
>
> <shepazu> ... but it's about ease of authoring, not so much
> performance
>
> <shepazu> ... boris says it's hard to predict performance
>
> <ed>
> [33]http://dev.w3.org/html5/spec/Overview.html#html-fragment-parsing
> -algorithm
>
> [33]
> http://dev.w3.org/html5/spec/Overview.html#html-fragment-parsing-algorithm
>
> <shepazu> ed: have we verified that innerHTML would work with SVG?
>
> <shepazu> ... I'm reading it, and it doesn't seem great for SVG
>
> <shepazu> jwatt: I can test it, don't know offhand
>
> <shepazu> ACTION: jwatt to test innerHTML for applicability to SVG
> [recorded in
> [34]http://www.w3.org/2009/11/23-svg-minutes.html#action03]
>
> <trackbot> Created ACTION-2699 - to test innerHTML for applicability
> to SVG [on Jonathan Watt - due 2009-11-30].
>
> <shepazu> shepazu: speaking of this, what's the standard way of
> doing ASV's printNode?
>
> <shepazu> jwatt: I have a wrapper
>
> <jwatt> [35]http://www.mozilla.org/projects/svg/wrappers.js
>
> [35] http://www.mozilla.org/projects/svg/wrappers.js
>
> <shepazu> ed: maybe for innerHTML, it needs to be put into the
> foreign-content mode...
>
> <shepazu> ... otherwise you have to wrap everything in <svg>
>
> <ChrisL> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre
>
> <ed> <html><svg id="foo">...</svg><script>$("foo").innerHTML="<rect
> width='100' height='100' fill='green'/></html>
>
> <shepazu> ed: anything that conflicts with HTML element names might
> cause a problem
>
> <ed> so test <font>, <video>, <audio>, <textArea>... any others?
>
> <shepazu> jwatt: about the F2F... I'm probably not coming
>
> <shepazu> ... mozilla thinks 4 meetings a year is too frequent
>
> <shepazu> shepazu: actually, I think it's 3 meetings a year now
>
> <shepazu> shepazu: maybe we should examine who would be able to
> attend
>
> <shepazu> ed: what about relocating it?
>
> <shepazu> trackbot, end telcon
>
> Summary of Action Items
>
> [NEW] ACTION: ChrisL to make funcURI consistent, and update tests
> [recorded in
> [36]http://www.w3.org/2009/11/23-svg-minutes.html#action01]
> [NEW] ACTION: ChrisL to respond to image clarification email with
> concrete example [recorded in
> [37]http://www.w3.org/2009/11/23-svg-minutes.html#action02]
> [NEW] ACTION: jwatt to test innerHTML for applicability to SVG
> [recorded in
> [38]http://www.w3.org/2009/11/23-svg-minutes.html#action03]
>
> [End of minutes]
>
>
>

Re: More Ideas around DOM Constructors

2009-11-25T11:03:12Z

Is there a proposal on how to handle attributes in different
namespaces with DOM Constructors? If we specify a property bag is it
ok to just do:

{ fill: "red", "xlink:href", "foo.html" } ?

As long as xlink: lines up with a declared namespace prefix?

Or perhaps the reliance on the XLink namespace is going away ?

Jeff

On Fri, Nov 20, 2009 at 11:26 AM, Jeff Schiller <codedread@...> wrote:

> My apologies, I missed
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Constructors_for_Elements
>
> I really think that providing a constructor for each element type is a
> bad idea. I also think providing attributes in the constructor
> signature is a bad idea.
>
> I also missed http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#createChildNS
> which seems to be inline with my thinking though it is adding new
> methods on Element apparently.
>
> I still think just adding a new (optional) argument to the standard
> DOM methods is the right approach there - it's what people are
> familiar with.
>
> I also think innerMarkup is fine too if there is potential confusion
> around innerHTML in a SVG context.
>
> Regards,
> Jeff
>
> On Fri, Nov 20, 2009 at 11:17 AM, Jeff Schiller <codedread@...> wrote:
>> First off, I assume the SVG WG wiki at
>> http://www.w3.org/Graphics/SVG/WG/wiki/ is for WG members only? If
>> not, maybe I had an account before but lost the login info. I tried
>> to login via OpenID but it says that the pages are locked.
>>
>> Anyway, I was reading
>> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM/JSON_Constructors.
>>
>> I was also reading
>> http://www.slideshare.net/jaffathecake/optimising-where-it-hurts-jake-archibald
>> yesterday.
>>
>> Anyway, here are my thoughts on constructors. I'll say up front that
>> I'm not familiar with the WebIDL stuff that jwatt has mentioned
>> several times, so my apologies if that has an impact on the following.
>>
>>
>> There are a variety of ways that DOM elements can be constructed. In
>> HTML land, there are pretty much two ways: DOM Level 1 and
>> innserHTML. It seems that many browsers (IE, Mozilla, Opera) have
>> optimized using innerHTML, though it's interesting that Webkit
>> browsers actually suffer from innerHTML manipulation (see slide 84 of
>> the above pack).
>>
>> In SVG currently there is only the DOM createElement, setAttribute,
>> appendChild route at the moment.
>>
>> Not only is it very painful for users, but it's probably slower in
>> Mozilla, Opera than it could be because there are (N+2) DOM calls you
>> need to make to get the node into the DOM, where N = number of
>> attributes you want to set.
>>
>> On the other hand innerHTML has to take a JS string and parse it to
>> create DOM elements, then attach the elements. At some point, this
>> must have an advantage in the case where you need to create a
>> large-ish subtree of elements. In other words, I'm not sure how well
>> the chart on slide 84 would hold up if they had constructed large
>> trees of nodes using DOM and then innerHTML and compared the two.
>>
>> Here is my proposal, they are rather simple:
>>
>> 1) Extend createElement(), createElementNS() with a new argument.
>> This new argument should be a name-value map of attributes. In JS
>> this would look like:
>>
>> createElement("circle", {cx: 40, cy:40, r:20, fill:"red"})
>>
>> As before, this returns the element, which you could then
>> appendChild/insertBefore, etc.
>>
>> This reduces the number of DOM calls by N. It's actually fairly
>> readable in my opinion and doesn't suffer from the order problem that
>> jwatt mentions on the DOM wiki because we're only talking about
>> attributes of a single element.
>>
>> I'm not sure if language bindings are a problem here. I really feel
>> that if a language does not provide a non-ordered name-value map then
>> it's not worth considering using these days (C++ std::map, Java Maps,
>> Python dictionaries, etc), but I'm really interested in hearing about
>> this from the WG.
>>
>> 2) For large-ish subtrees of DOM elements that need be created, the
>> solution seems obvious to me: Adopt the innerHTML property from HTML5
>> for XML: http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml1
>> including the algorithm for setting the contents.
>>
>> Personally, I don't think worrying about 'HTML' in the name of the
>> property matters these days, do you?
>>
>> Regards,
>> Jeff Schiller
>>
>

Minutes, SVG Telcon, 23 Nov 2009

2009-11-25T10:46:15Z

Hi, SVG Folks-

Here are the minutes for the SVG WG telcon of 23 Nov 2009:

http://www.w3.org/2009/11/23-svg-minutes.html

Or as text below:

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

23 Nov 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/11/23-svg-irc

Attendees

Present
ed, Shepazu, jwatt, Chris_Lilley, [IPcaller], anthony

Regrets
Chair
ed

Scribe
anthony

Contents

* [3]Topics
1. [4]SVG 1.1 2nd Ed
2. [5]list activity
3. [6]DOM constructors
* [7]Summary of Action Items
_________________________________________________________

<trackbot> Date: 23 November 2009

\me zakim, drop shepazu

<scribe> scribenick: shepazu

SVG 1.1 2nd Ed

<ed> [8]http://www.w3.org/Graphics/SVG/WG/track/products/1

[8] http://www.w3.org/Graphics/SVG/WG/track/products/1

<ed> 12 open issues, 22 open actions

issue-2013?

<trackbot> ISSUE-2013 -- Percentages in clipPath/pattern/filter/mask
unintuitive -- OPEN

<trackbot> [9]http://www.w3.org/Graphics/SVG/WG/track/issues/2013

[9] http://www.w3.org/Graphics/SVG/WG/track/issues/2013

<ChrisL> issue-2013?

<trackbot> ISSUE-2013 -- Percentages in clipPath/pattern/filter/mask
unintuitive -- OPEN

<trackbot> [10]http://www.w3.org/Graphics/SVG/WG/track/issues/2013

[10] http://www.w3.org/Graphics/SVG/WG/track/issues/2013

<ed> moved to SVG Core 2.0

Resolution: we will move this to SVG 2.0

issue-2017?

<trackbot> ISSUE-2017 -- Find sane values for getSubStringLength and
selectSubString -- OPEN

<trackbot> [11]http://www.w3.org/Graphics/SVG/WG/track/issues/2017

[11] http://www.w3.org/Graphics/SVG/WG/track/issues/2017

<ed> ACTION-2325?

<trackbot> ACTION-2325 -- Doug Schepers to propose wording and
examples for ISSUE-2107 -- due 2008-10-30 -- CLOSED

<trackbot> [12]http://www.w3.org/Graphics/SVG/WG/track/actions/2325

[12] http://www.w3.org/Graphics/SVG/WG/track/actions/2325

<ed>
[13]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/023
9.html

[13]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0239.html

<ed> [14]http://www.w3.org/2008/10/23-svg-minutes.html#action02

[14] http://www.w3.org/2008/10/23-svg-minutes.html#action02

ed: heycam didn't see a strong argument either way
... what should we do with this? close it or take it up again?

jwatt: acid3 depends on this behavior?

ed: it did at one time
... we did change the behavior in the spec for the better

<ed>
[15]http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html#TextCh
apter

[15]
http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html#TextChapter

shepazu: we might look at this more closely in SVG 2.0

ed: right

<ChrisL> i think its closed, for 1.1

jwatt: the current errata makes sense to me

resolution: close the issue

issue-2071?

<trackbot> ISSUE-2071 -- potential security hole involving
pointer-events, filters, foreignObject, cross-origin IFRAMEs, and
elementFromPoint -- OPEN

<trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2071

[16] http://www.w3.org/Graphics/SVG/WG/track/issues/2071

resolution: move to SVG 2.0

issue-2113?

<trackbot> ISSUE-2113 -- animate-elem-35 -- OPEN

<trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2113

[17] http://www.w3.org/Graphics/SVG/WG/track/issues/2113

<ed> ISSUE-2213?

<trackbot> ISSUE-2213 -- Some issues in the definition of
suspendRedraw/unsuspendRedraw/forceRedraw -- OPEN

<trackbot> [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2213

[18] http://www.w3.org/Graphics/SVG/WG/track/issues/2213

resolution: defer to SVG 2.0

issue-2217?

<trackbot> ISSUE-2217 -- How units are resolved on an SVGLength is
not defined -- RAISED

<trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2217

[19] http://www.w3.org/Graphics/SVG/WG/track/issues/2217

Resolution: move to SVG 2.0

issue-2219?

<trackbot> ISSUE-2219 -- Missing test coverage for SVG 1.1
properties -- RAISED

<trackbot> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2219

[20] http://www.w3.org/Graphics/SVG/WG/track/issues/2219

jwatt: we should put this off until we decide on the new test format

Resolution: resolve in SVG 2.0

issue-2259?

<trackbot> ISSUE-2259 -- Inconsistent use of <uri> symbol -- RAISED

<trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2259

[21] http://www.w3.org/Graphics/SVG/WG/track/issues/2259

<ed>
[22]http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPa
thProperty

[22]
http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPathProperty

ed: didn't we resolve this in second edition?

ChrisL: basically, this is rolling in changes we made in SVGT1.2
... it should be easy to do

<scribe> ACTION: ChrisL to make funcURI consistent, and update tests
[recorded in
[23]http://www.w3.org/2009/11/23-svg-minutes.html#action01]

<trackbot> Created ACTION-2697 - Make funcURI consistent, and update
tests [on Chris Lilley - due 2009-11-30].

<ed>
[24]http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#Interfac
eSVGViewSpec

[24]
http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#InterfaceSVGViewSpec

<ChrisL> issue-2263?

<trackbot> ISSUE-2263 -- The attributes on the SVGViewSpec interface
are underspecified -- RAISED

<trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2263

[25] http://www.w3.org/Graphics/SVG/WG/track/issues/2263

shepazu: we will have to reexamine this in the context of the new
SVG DOM API, anyway

Resolution: defer to SVG 2.0

issue-2294?

<trackbot> ISSUE-2294 -- Adding an animated length attribute into a
baseval length list -- RAISED

<trackbot> [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2294

[26] http://www.w3.org/Graphics/SVG/WG/track/issues/2294

jwatt: I was going to write an email about this...
... maybe we need some custom error about removing items from the
original list (readonly)
... maybe we should have a "copy" method?
... let's address this in the new DOM API

Resolution: move to SVG 2.0

issue-2299?

<trackbot> ISSUE-2299 -- Text on a path layout rules unclear wrt
startpoint-on-the-path and text-anchor -- RAISED

<trackbot> [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2299

[27] http://www.w3.org/Graphics/SVG/WG/track/issues/2299

ChrisL: I don't think they are contradictory, they seem to be saying
the same thing in different ways
... it's using "start point" for 2 different things...
... it's talking about shifting the initial start point

ed: it's ambiguous enough that implementations all do different
things
... but I'm not sure it's critical for SVG 1.1 2nd ed.

shepazu: I want this fixed because it's important... could we start
a 3rd edition errata in addition to SVG 2.0?

ChrisL: we could do... we need to test all of this better, too

ed: one way to start off easy is to have a straight line as the
textPath for tests that describe the start point

ChrisL: good idea

resolution: keep as SVG 1.1 3rd edition errata, but duplicate for
SVG 2.0, to make sure it's addressed in both

issue-2301?

<trackbot> ISSUE-2301 -- Text on a path layout rules unclear wrt
startpoint-on-the-path and text-anchor (svg2) -- RAISED

<trackbot> [28]http://www.w3.org/Graphics/SVG/WG/track/issues/2301

[28] http://www.w3.org/Graphics/SVG/WG/track/issues/2301

ed: 23 pending actions left

s23 pending actions left/23 pending actions left left left

action-2077?

<trackbot> ACTION-2077 -- Erik Dahlström to test implementations for
percentage values in clipPath, etc. -- due 2008-07-03 -- OPEN

<trackbot> [29]http://www.w3.org/Graphics/SVG/WG/track/actions/2077

[29] http://www.w3.org/Graphics/SVG/WG/track/actions/2077

action-2203?

<trackbot> ACTION-2203 -- Doug Schepers to add to the 1.1 Full
errata that the initial value for the root overflow property is
scroll rather than hidden -- due 2008-09-30 -- OPEN

<trackbot> [30]http://www.w3.org/Graphics/SVG/WG/track/actions/2203

[30] http://www.w3.org/Graphics/SVG/WG/track/actions/2203

action-2404?

<trackbot> ACTION-2404 -- Doug Schepers to add errata item for root
overflow -- due 2009-01-22 -- CLOSED

<trackbot> [31]http://www.w3.org/Graphics/SVG/WG/track/actions/2404

[31] http://www.w3.org/Graphics/SVG/WG/track/actions/2404

list activity

ed: discussion about transforms, getIntersectionList, DOM
constructors, image clarification, z-index

ChrisL: I wonder if alex addressed this to their satisfaction?
... a good example might help

<ChrisL> suppose a filter brings in a greyscale image with feimage,
then we do an rgb fecomponenttransfer. that should work

<ChrisL> it wont give an error

<ChrisL> so that is what "as it its promoted to RGBA" means

ChrisL: when we say, "implement as if...", then things that fall out
of the model still have to work
... action to respond to image clarification email with concrete
example

<scribe> ACTION: ChrisL to respond to image clarification email with
concrete example [recorded in
[32]http://www.w3.org/2009/11/23-svg-minutes.html#action02]

<trackbot> Created ACTION-2698 - Respond to image clarification
email with concrete example [on Chris Lilley - due 2009-11-30].

ed: anthony addressed the transforms issues
... Dr. Olaf pointed to his older email... did we address this?

anthony: not sure

ChrisL: Dr. Olaf raised a good point, CSS didn't consider animation
when they specified angles, which need to be normalized, and since
they now have animation this affects them too... we should raise
this with the CSS WG

anthony: I'll take a crack at replying to Dr. Olaf

DOM constructors

<anthony> scribe: anthony

DS: Just started off with basically describing
... what we had proposed
... because he didn't read the proposal page
... just ready the 'what sort of problems we have' page
... he also proposed that we use the innerHTML method for larger
document fragments
... and Brois said that innerHTML has been optimised because
browsers have to parse already
... so that's one thing they optermise for
... Boris seemed to be have mixed responses about sending in a
property bag object for element constructors would help the
performance
... I definitely under the impression from taking to implementers
that setting attributes individually was a huge performance hit

<shepazu> ChrisL: if it's done right, it should be a performance
gain, and is never a performance hit

CL: It can be an atomic operation

<shepazu> shepazu: and it's much nicer for authoring

DS: It's much nicer for authors

<shepazu> shepazu: Jeff may not have considered the issue of the
namespace of an element when he criticized using createElement as an
element method

<shepazu> shepazu: jwatt, what's your impression?

<shepazu> jwatt: boris seemed to refute some of the performance
points that Jeff pointed to

<shepazu> ... but it's about ease of authoring, not so much
performance

<shepazu> ... boris says it's hard to predict performance

<ed>
[33]http://dev.w3.org/html5/spec/Overview.html#html-fragment-parsing
-algorithm

[33]
http://dev.w3.org/html5/spec/Overview.html#html-fragment-parsing-algorithm

<shepazu> ed: have we verified that innerHTML would work with SVG?

<shepazu> ... I'm reading it, and it doesn't seem great for SVG

<shepazu> jwatt: I can test it, don't know offhand

<shepazu> ACTION: jwatt to test innerHTML for applicability to SVG
[recorded in
[34]http://www.w3.org/2009/11/23-svg-minutes.html#action03]

<trackbot> Created ACTION-2699 - to test innerHTML for applicability
to SVG [on Jonathan Watt - due 2009-11-30].

<shepazu> shepazu: speaking of this, what's the standard way of
doing ASV's printNode?

<shepazu> jwatt: I have a wrapper

<jwatt> [35]http://www.mozilla.org/projects/svg/wrappers.js

[35] http://www.mozilla.org/projects/svg/wrappers.js

<shepazu> ed: maybe for innerHTML, it needs to be put into the
foreign-content mode...

<shepazu> ... otherwise you have to wrap everything in <svg>

<ChrisL> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre

<ed> <html><svg id="foo">...</svg><script>$("foo").innerHTML="<rect
width='100' height='100' fill='green'/></html>

<shepazu> ed: anything that conflicts with HTML element names might
cause a problem

<ed> so test <font>, <video>, <audio>, <textArea>... any others?

<shepazu> jwatt: about the F2F... I'm probably not coming

<shepazu> ... mozilla thinks 4 meetings a year is too frequent

<shepazu> shepazu: actually, I think it's 3 meetings a year now

<shepazu> shepazu: maybe we should examine who would be able to
attend

<shepazu> ed: what about relocating it?

<shepazu> trackbot, end telcon

Summary of Action Items

[NEW] ACTION: ChrisL to make funcURI consistent, and update tests
[recorded in
[36]http://www.w3.org/2009/11/23-svg-minutes.html#action01]
[NEW] ACTION: ChrisL to respond to image clarification email with
concrete example [recorded in
[37]http://www.w3.org/2009/11/23-svg-minutes.html#action02]
[NEW] ACTION: jwatt to test innerHTML for applicability to SVG
[recorded in
[38]http://www.w3.org/2009/11/23-svg-minutes.html#action03]

[End of minutes]