Minutes, SVG WG Brussels f2f day 4 (Monday)

Hello www-svg,

http://www.w3.org/2010/05/31-svg-minutes.html


SVG Working Group Teleconference
31 May 2010

See also: IRC log
Attendees

Present
    Alex, Anthony, Dave, JWatt, Doug, Patrick, Erik, Chris, Femke, Felipe, Hin-Tak, Simon
Regrets
Chair
    SV_MEETING_CHAIR
Scribe
    Dave_Crossland, Dave Crossland

Contents

    * Topics
         1. CSS 2.1 Issue 114
         2. Text and Fonts
         3. xlink:href and html integration
         4. svg 1.1
         5. SVG+HTML
         6. Group Workflow
    * Summary of Action Items

<trackbot> Date: 31 May 2010

<ed> trackbot, start telcon

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 31 May 2010

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/font-family-invalid-chars-02.svg

<pdengler> scribenick: pdengler
CSS 2.1 Issue 114

ChrisL: To run the test linked above, you need a certain font; according to CSS, you should skip that first font because it is invalid
... And that you should in fact skip over the entire list, which means the default font should be used

<ChrisL> firefox 3.6 shows all numbers

<ChrisL> opera 10.10 does too but opera 10.53 shows no numbers

pdengler: IE Platform preview shows none
... Chrome does the same as IE and FireFox

<ed> opera 10.53 shows no text at all (even the "revision" string), wondering if it really finds the proper font there

ChrisL: Proposal is that a CSS font should be an ident. But this is potentially to strict
... The issue is that certain characters would have to be quoted

pdengler: This means that fonts that start with (1-9) would have to be quoted

ChrisL: The issue is that CSS wants to close this issue, but that this effects SVG. But it looks like most of them are rejecting fonrt family names, and remain compliant

pdengler: Correction IE shows the numbers just as Chrome and Firefox

<ChrisL> batik (svn) shows the numbers (and a bunch of error messages)

ChrisL: Suggest we go with Mozilla proposal.

<ChrisL> so font family would be a list of CSS2.1 IDENT

<ed> http://wiki.csswg.org/spec/css2.1#issue-114

<ChrisL> so SVG WG aligns with proposal 1, http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html

<ChrisL> action chris to convey this result to CSS WG

<trackbot> Created ACTION-2788 - Convey this result to CSS WG [on Chris Lilley - due 2010-06-07].

<ChrisL> action-2788?

<trackbot> ACTION-2788 -- Chris Lilley to convey this result to CSS WG -- due 2010-06-07 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2788

<ChrisL> action chris to move the font-family parsing tests to the svg 1.1se test suite

<trackbot> Created ACTION-2789 - Move the font-family parsing tests to the svg 1.1se test suite [on Chris Lilley - due 2010-06-07].

nomis: The basic idea behind diffusion curves is that you define shapes, and then colors on the sides of a curve

<scribe> Topic : Diffusion Curves by Simon from GIMP

<ChrisL> http://wiki.inkscape.org/wiki/index.php/Diffusion_Curves

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2010May/0032.html

nomis: Simon has prototyped this on RGB (not yet on curves) but on pixels that diffuse colors

<nomis> I'd like to emphasize that all of the algorithm implementation is done by jasper.

<ChrisL> original paper http://artis.imag.fr/Publications/2008/OBWBTS08/

The use case for diffusion curves is rooted in drawing much smoother, richer graphics with being able to establish vectors/curves with a 'color' on each side, then having the algorithm fill in the difference

AlexD: Other use cases include removing/smoothing through averaging an image (such as 'air brushing a photo')

anthony: The issue with the original alogithm is that it was an iterative method. This was an issue with animation causing computational intensive rendering

ChrisL: Since then, there have been some papers on making that issue more tractable

pdengler: So what about the IP around this?

anthony: If you look at these images, they all have smooth edges. But if you have a pattern, this begins to break down

ChrisL: That's why having it in SVG is more powerful in an SVG Authoring Tool

anthony: Hi frequency color changes do not work as well (from the author and from Anthony)

ChrisL: How would this be integrated into SVG?

nomis: Why define diffusion curves independent of the image

shepazu: We are discussoin whether to make it a paint server, or whether you apply via an effect

anthony: Could you do it through filters where you apply it to shape?

ed: Doesn't come naturally that way

ChrisL: We are going to need some sort of syntax that allows to define 'left-side'/'right-side' colors
... You can imagine it being referenced as a fill/paint as you can any other paint

shepazu: I was thinking of a new property, e.g.

<AlexD> I think you are putting the cart before the horse. It's a nice graphical demo, however it would be good to first see mainstream authoring tools support it; and more importantly fully evaluate the run-time efficiency of the techniques. If the diffusion curve algorithms are n^2 then forget it. Is there any IP also?

<AlexD> BTW, left/right side fill is the Flash model.

anthony: Consider using the new path syntax

<ChrisL> yes but its a solid fill i believe

shepazu: e.g. new path syntax <path><quadratic ../><lineto../><horiztonal ../></path>

<ed> AlexD: yeah, the complexity does worry me as well

shepazu: consider too verbose. But if you use compressed it, it turns out the the compressed format is much better

pdengler: I still think it's too verbose given the potential use cases

<AlexD> Personally I think we need to address things like variable stroke-width that's been asked for years ago and If I remember correctly high on the cartographers wish-lists.

ed: I've been working on OpenGL; would it be interesting to redefine a path syntax to include a color?

shepazu: If we are talking about having the constraints functions (calc, etc) we are already talking about changing the path syntax, to break down into path/calc/ and color

pdengler: No way

ChrisL: Suppose you are only allowed to use cubic beziers. The start/end positions would be known. So you can have a separate attribute for coloring (lcolls/rcols)

nomis: I'm not sure why you would want to restrict this to bezier curves?

ChrisL: Simplicty

nomis: But any path can have these

shepazu: Back to the agenda, we want to talk about group workflow
... typically what we do with a feature, we will have a discussion in the group, mailing lists, face-to-faces are used for attempting to finalize decisions
... Now we are just brainstorming

ChrisL: We have had a couple of runs at diffusion curves; we are excited about it; we see the potential now

anthony: In that case, we should gather the ideas together and write them down

<AlexD> We should collate all the work done on 1/2 Full of which there is a lot - compositing, vector effects, flow graphics, etc. etc. and add the interesting nice things - and hopefully address the shortcomings that the geo community have been asking for for years. Amongst everything else of course.

<AlexD> s?1/2?1.2?

shepazu: So does GIMP import SVG?

nomis: Yes.

ChrisL: Can you interpret clipping paths on raster images?

nomis: We output them from raster images; you can defining a clipping path for exporting to TIF for example

ed: What I would like to see personally is this plan that we have written up over the previous days to put it on the Wiki for collaboration

<scribe> ACTION: pdengler to post plan for the plan for SVG 2.0 on the Wiki [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action01]

<trackbot> Created ACTION-2790 - Post plan for the plan for SVG 2.0 on the Wiki [on Patrick Dengler - due 2010-06-07].

nomis: One more item on diffusion curves: if you have paths with multiple color definitions along the way, you might want to define the way colors are interpoloated along the path

<scribe> Topic : Fonts

<scribe> ACTION: chrisl to investigate diffusion curves and potentials for SVG 2.0 [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action02]

<trackbot> Created ACTION-2791 - Investigate diffusion curves and potentials for SVG 2.0 [on Chris Lilley - due 2010-06-07].

<nomis> if anybody wants to play with the prototype diffusion code: http://www.home.unix-ag.org/simon/files/diffuselib.tgz

ChrisL: Will investigate syntax, authoring tools, use cases

anthony: I will investigate rendering methods

<scribe> ACTION: anthony Investigate rendering methods for diffusion curves [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action03]

<trackbot> Created ACTION-2792 - Investigate rendering methods for diffusion curves [on Anthony Grasso - due 2010-06-07].

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Diffusion_Curves
Text and Fonts

<fat_tony> CL: I have a proposal for SVG 2.0 as what we should do for fonts

<fat_tony> ... the web has meanwhile moved to downloading fonts of web

<fat_tony> ... in 1.0 you were required to SVG fonts

<fat_tony> ... I propose for SVG 2.0 we mandate you use WOFF

<fat_tony> ... and have SVG Fonts as an optional features

<fat_tony> DS: I have a counter proposal, right now we have SVG Tiny 1.2 fonts in Opera and Webkit

<fat_tony> ... and there are patches for FireFox

<fat_tony> DC: Yes

<fat_tony> JW: We don't currently SVG Fonts are the well designed and should be the solution going forward

<fat_tony> ... if we have demand from users to put them then we will consider it

<fat_tony> ... at the moment we'll see how WOFF goes

<fat_tony> ... and if that meets the majority of uses cases we can gather the uses cases it doesn't meet

<fat_tony> ... and reconsider

<fat_tony> DS: My counter proposal is we add SVG Tiny 1.2 fonts to SVG 2.0

<fat_tony> ... we consider adding it

<fat_tony> ... then we have separate font specification

<fat_tony> CL: Had considered that

<AlexD> What's the status of WOFF standards-wise? Is this W3C working group or loosely coupled vendor alliance like WhatWG?

<fat_tony> ... but there are few reasons why I didn't say this

<fat_tony> ... Tiny subset does the single colour path, but don't get any features about animated fonts, video fonts etc. E.g. anything that can be drawn is a glyph

<fat_tony> ... that's the bit that should be held onto SVG Fonts

<fat_tony> PD: What couldn't you take those benefits that SVG Fonts have, and take those to WOFF

<fat_tony> CL: Because WOFF is a packaging format for OpenType

<fat_tony> PD: I agree we should put fonts in as an optional module

<fat_tony> ... SVG Fonts as an optional module

<fat_tony> ... If customers demand it, I'll build it

<fat_tony> ED: I agree with what Doug proposed

<fat_tony> ... breaking it out is fine

<AlexD> SVG Tiny 1.2 fonts is trivial to implement, and by being defined as a font allows an implementation to

<fat_tony> ... but that subset should be required

<AlexD> optionally cache glyphs.

<fat_tony> ... because that is already implemented

<ChrisL> @alex: woff is being standardized at W3C

<AlexD> SVG fonts are the only (current) way to deliver a single piece of SVG content to a device and have the text rendered as intended. Similar to XPS where obfuscated OpenType is mandated. I'd like to see the obfuscated OpenType considered alongside WOFF too.

<fat_tony> DS: To me as a developer, there are couple of different things about SVG Tiny 1.2 fonts

<fat_tony> ... you can have overlaps

<ChrisL> http://www.w3.org/Fonts/WG/

<fat_tony> ... which you can't do in traditional fonts

<fat_tony> ... and you can do scripting

<fat_tony> ... which is why I would want them

<fat_tony> ... I'll be flexible on this

<fat_tony> DC: [gives diagram over overlapping font]

<fat_tony> DS: Wouldn't want overlapping fonts unless you get to headers

<AlexD> Also, as for overlaps - you can define strokes as individual graphics items and glyphs using <use> which gives you the ability to generate Asian fonts using a set of calligraphic strokes that are composite glyphs. That sort of encapsulation isn't available in other fonts and can reduce size greatly for large glyph sets like Kanji...

<fat_tony> PD: In terms of beyond headings is it reasonable to use SVG Fonts for a document?

<fat_tony> ED: Primary use case is headings

<fat_tony> DC: My experience of SVG graphics is they can be quite slow, so it's not typical to render large blocks of text

<fat_tony> PD: I know you have more use cases

<fat_tony> ED: I'm not saying the whole module should be required

<fat_tony> ... I'm saying a small subset that's already implemented should be carried on to the new spec

<fat_tony> DS: There are two or three proposals on the table

<fat_tony> BL: I think it use already

<fat_tony> ... the SVG Fonts

<fat_tony> ... if you make it optional now

<fat_tony> ... it might not work anymore

<fat_tony> CL: That's the issue now

<fat_tony> BL: Can do a lot of great things with SVG Fonts

<fat_tony> PD: It will be only performant it will on be use cases for headings

<fat_tony> BL: Is there a technology right now that can replace SVG Fonts

<fat_tony> PD: We don't need fonts

<fat_tony> ... you can use paths

<fat_tony> ... we have this huge API on this thing called fonts

<fat_tony> CL: You're suggesting don't put text there

<fat_tony> ... put graphics there

<fat_tony> ... not good for accessibility

<fat_tony> PD: It just seems heavy handed

<AlexD> If SVG fonts are used the user agent automatically knows that the bitmap can be cached for re-use and efficiency. Basic laser printer techniques from the 80s apply here. And accesibility and cut/paste from the graphic, and searching,etc...

<fat_tony> CL: You've converted the curve and stuck an element to say it's font

<fat_tony> DS: There is altGlyph

<fat_tony> ... This is the reverse to the way I would've done it

<fat_tony> ... syntax would be like:

<shepazu> <text ...><altGlyph xlink:href="#myshape">My Logo</altGlyph> </text>

<fat_tony> CL: It points to a glyph

<fat_tony> ... it has to say what the base line is

<ChrisL> and the coordinate system

<fat_tony> DS: We could alter altGlyph

<fat_tony> ... as if it where a use

<fat_tony> CL: Where is your point you're anchoring at?

<fat_tony> DS: If you're pointing at something that is not a glyph it acts more like a <use>

<fat_tony> ... but it does it inline

<fat_tony> ... we'd have to define in the spec what things in the spec what the baseline is

<fat_tony> JW: I'm not resistant to working on SVG Fonts

<fat_tony> ... I'm just saying it should not be required by 2.0

<fat_tony> ... I'm quite happy to work and participate on the fonts part

<fat_tony> ... there's a difference to us having fonts in our charter compared to requiring it

<fat_tony> CL: Do you think Mozilla would implement it if it was optional?

<fat_tony> JW: Depends on demand

<AlexD> if the time-frame for 2.0 reflects 1.2 Tiny in any way, i.e. 7 years from 1.1 to Tiny 1.2 then you will have 7 years of 1.1 browsers that support SVG fonts. Deprecating them for 2.0 seems a bit short-sighted. And the implementation effort is trivial compared with other aspects of the spec...

Not all browsers support them now

<AlexD> True - but there are _many_ mobile and IPTV user agents that do.

<AlexD> Oh and both Adobe Illustrator and Corel Draw emit SVG Fonts as part of their content, and they are leaders in the graphic arts authoring community...

<ChrisL> alex, these are all good points

<ChrisL> so does inkscape

<ChrisL> inkscape can author svg fonts as well. as can fontforge

<ChrisL> deprecation is not on the table

<fat_tony> DS: I'm ok with potentially removing them from the core, as along as there is away to do SVG text as a graphic

<fat_tony> ... I'm proposing some sort of altGlyph like solution

<fat_tony> ... so we don't have content out that is not a-semantic

<fat_tony> ... want text extraction and text search to work

<fat_tony> PD: It gets tricky with fonts on a path

<AlexD> What's tricky about fonts on a path?

<ChrisL> debug off, optimize on, deprecation on

<ed> dave crossland: one usecase I see for svgfonts is photo-fonts

<ed> ...there are such proprietary font formats

<ed> CL: we should collect those on a wiki or something

<ed> DS: fontlab (photofont.com)

<ed> DC: you're not going to typeset a book with a photofont, but it does get used for some things

<ed> DS: the scrapbooking community might be interested in this

<ed> DS: (shows a glyphshape used as a clippath, cutting out a letter G of a photo)

<ed> (examples of photofonts shown)

<ed> DC: sometimes you want glyphs randomly selected, having several shapes, like for handwriting fonts

<ed> CL: you could do most of that using an svgfont

<ed> ...using ligatures etc

<ed> DC: full svgfonts would give the power to do more interesting (such as photofonts)

<ed> ... so saying it would be nice if full svgfonts were supported in svg 2.0

<ed> DS: we don't see it on the web much today

<ed> ... designers might want to be able to use these features, things that can't be done with traditional fonts

<ed> ...and I'm fine with having svgfonts as an optional module
xlink:href and html integration

<ed> scribenick: ed

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href

<fat_tony> sribenick: fat_tony

<fat_tony> ED: If you had xlink:href and href on an element you are saying that one of them is thrown away during parsing?

<abattis> O

<abattis> Yo

<abattis> scribenick

<abattis> scribenick: abattis

<ChrisL> scribe: Dave_Crossland

<scribe> scribe: Dave Crossland

shepazu: here's now IRC works
... and thats it.
... If only xlink:href is present it will be put into the DOM property href and when serialised href is not namespaced
... theres one remaining usse
... xlink is used in content for title=""
... the xlink title is meant to describe the nature of the lnked resource, not the graphic in the SVG
... so do we get rid of xlink and added title as well to fulfil that function
... so its title as used in html

ChrisL: we only added it because XLINK had it
... having human readbale text in attributes where you can't i18n it
... but xlink made that mistake and we can inherit it (?)

shepazu: title as in attribute descirbes whats being linked to
... title as a child describes the link itseld
... itself

ChrisL: HTML can do both, eg lang and hreflang

shepazu: svg tin 1.2 today does it with attribute only
... i prpose we say yes

pdengler: what do i put in for script?

<ChrisL> href

shepazu: first, i want to minute a resolution to go with this plan

pdengler: if you put href on an image
... then _IF_ we have a goal of syntactic and programmatic (img.src)

shepazu: epareate the issues of src and href
... our goal can be to treat href one way and agree ,and then look at src

pdengler: you think we can get agreemnt on src fast?

ChrisL: you end up with a guessing game for href and src, if they are dfferent, people dont remember

pdengler: src is more important

shepazu: we have to resolve how href is processed
... its definied in <use>
... they are really separate issues
... are you saying not to allow image href at all?

pdengler: you want IE to do this

shepazu: yes

pdengler: if we ship IE with image href

shepazu: that doesnt preclude img src, we can do both

pdengler: whats the API look like?

shepazu: crappy
... we have to say what happens with href, period
... we have to say what happens when we have href there, so thats why its separate issue
... everywhere
... everywhere
... even HTML when SVG is inside HTML

pdengler: so out of doc?

shepazu: everywhere!

pdengler: theres an issue with the API... i hate to proliferate and attribute

shepazu: maybe its okay, lemme think
... i think its separete because if we start doing <script src=""> then
... theres a better case there than <img>
... its a tag spelled differently, behaves differently

pdengler: we can make a case t oHTML WG they have inconsisntecyn

abattis: whats up with html 6?

shepazu: there are things talked about not going in to html5, so probably there will be one
... okay, so, href itself is readonly

ed_work: theres a link thats read-write
... the spec is confused
... its RW because you can write to what it points to

shepazu: so can we get an AMEN to xlink:href

pdengler: amen

jwatt: ummm let me think

fat_tony: amen

shepazu: patches welcome

<ChrisL> yea verily

ed_work: if we agree things are thrown away when parsing to generate the DOM, both xlink:href and href, what i hear here is that the xlink:href will be thrown away

jwatt: srsly?

ChrisL: more time?

jwatt: i dont think we should throw it away, we should put both into DOM and give one precedence

ChrisL: and if one is chagned later, what happens?

jwatt: a script can set attributes for both
... or does it throw?
... there are still issues to be worked out
... on that point i prefer precedence than messing with the parser

<AlexD> I agree with JWatt, allow both and add precedence, like we did for xml:id and id in Tiny.

shepazu: i want to see a more formal prposal, thats a cxomplex design descisoin for a minor use case
... and i think browser vendors would agree
... mozilla people have said this idea isnt a good solution to me

jwatt: not to me

shepazu: AlexD, that was a disaster

(lol)

<AlexD> Agreed, I don't like xml:id at all.

shepazu: you have 2 dom attirbutes, why?
... what happens when you hcange the href property?

jwatt: yuou set thte attributes, and whichever is active, has precedendce. so if you have href set, use that, if you have xlnk:href set use that
... if you set both, you get both bcak

<AlexD> This is where I think HTML5+svg an pure XML based SVG need to diverge. If it's XML, then xlink:href, when we integrate into HTML5, href only. But needs more discussion.

ed_work: if yo uhave both set, and serialise it back, jwatt is saying you get both, whereas before we said only 1 would comeback

<AlexD> JWatt is correct here. If you have both, the DOM should represent both. But in the HTML5 case I'd argue integration should throw away xlink.

shepazu: lets not fork SVG, i dont want different behavour in SVG standalone and SVG+HTML

ed_work: AlexD makes an interesting point

<AlexD> So we're screwed:-)

shepazu: i dont want differnet behaviour

ChrisL: either do it in the parsing model of each, or its the same in both, and thus we can't discard attributes

shepazu: i really want it tobe simple and unambiguous for authors and simpler for implementors

jwatt: its no problem to see if we have href, if so use it, else if xlink, use that

shepazu: its not as simple as that, its what i wrot ethe page for

jwatt: link pls

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href

<AlexD> Simplest for implementation is to just ignore the namespace prefix, so href is all that's looked at.

<AlexD> BTW, there is content out there being shipped commercially that claims to be SVG and uses href with no prefix and the implementor of the UA is a Swedish cmpany...

jwatt: ed, were you obejcting to my idea?

ed: just restating the discussion we had a bit back, not objecting

jwatt: this doesnt to me mess with what the makrup does

shepazu: it seems like deprecating href in a way

jwatt: i dont see why it encourages its use more than dougs solution

shepazu: ok
... maybe a simpler syntax is a win
... but what if you have both, and you setone, and its href it takes precedence/

jwatt: if you set an attribute, thats what you want
... someone setting on attr and animating the other? a real edge case we dont need to consider highly

<AlexD> We can't break DOM2/DOM3. If you setAttribute it's in the null namespace, if it's setAttributeNS then the namespace is honoured. You can't expect an SVG UA to override with extra behaviour. It pushes it into the wrong level of the DOM model.

jwatt: to restate: it seems easy to allow setting both, and see if either exists and use that, and precedence is ...

shepazu: how do you serialise that?

jwatt: serialise them both
... if they put it in for backward compatibiltly

<AlexD> JWatt: Nooooooo..... Yuk!

ChrisL: before <a> name="" to id="", people duplicated the values in both attrs

<AlexD> We have a document model or we don't.

jwatt: shepazu, if you think inserting is a bad thing, tell me

ChrisL: AlexD says ^^^
... i can live with jwatts prposal, i want to see it written pu

ed_work: so, for animating, say ou animate the URLs, different HREFs, with the DOM you take one out
... it makes it harder to deal with dependenceies

jwatt: not got it
... you animate an attr

ed_work: now you can animate attrs

jwatt: eh? i can put 2 animator tags in and do it separately

pdengler: now we're tlaking abotu 2.0 without types or other thing
... do we know if href should be an animated string?
... the first time we looked at href we choked
... i know what youre trying to get done, get href, i dont worry about animating this thing
... my argument against jwats proposal is that they will pile up
... if you dont set a stake in the ground about higher level constricts uts hard to nke desicsions abut the details

jwatt: simple cases like rollovers, slideshows,

pdengler: xhtml never had these?

ChrisL: yo uhad to do it with script

pdengler: is SVG for the 500 people using it to date? or the millions of web devs who know a programming pattern
... plan that stuff first
... if theres a middle ground about what jwatt needs, modifing th eprposal, im not concenred about animated types but ed_work is
... it looks like a problem, but until i see an nimated href

ChrisL: they ar ein SMIL

shepazu: are you using aniimating in a different way? a mouseover, a cilick, can be an animation

pdengler: i havent seen much SMIL content
... nor much SVG content

shepazu: its 3pm
... jwatt, what do you say?

jwatt: we have precedence
... dont drop or not set attrs

<ChrisL> Resolution: accept modified href proposal with no dropped attributes, just precedence

shepazu: okay, ill modify the prposal live

<AlexD> Phew

:)

shepazu: writing it right now!

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Href

shepazu: * read out what i wrote
... when serialised what hpanes?

ChrisL: you get back what you put in

<FelipeSanches> I am concerned about the d attribute in the path tag. Whenever somebody wants to modify it dinamically through javascript we have to parse the d data, then generate a new d attribute, then the browser has to re-parse it again.

<FelipeSanches> can we have an in-memory representation of path data that javascript could more easily manipulate?

<ChrisL> @Felipe yes we plan to have a more verbose xml syntactic alternative to cover that use case

<FelipeSanches> thanks

pdengler: err we discussed, not are consideringned. memory footprints have unknown tradeoffs

<pdengler> I don't agree; we have discussed potential alternatives, but haven't weighed the pros and cons

ChrisL: DOM is an API not a memory modeule
... you can give him a mini parser to do that?

BREAK TIME

pdengler: theres enough benefi tto doing the href
... to have something Just Work
... i would push hard to get this in MSIE to move from HTML development to HTML+SVG development
... they are goig to get caught on script in some cases if it uses HREF, if its inside the SVG tag, but mostly people will put the script where they are used to, in the HTML <head>
... so in the end if you dont solve this the world is a difficult place for a while bu tleads to the right model later on
... if we do it now its easier now and for later on puts a challenge on us, its the same as class and id, but for an attr thats not used as widely
... so i dont think were ready to dicuss SRC

shepazu: with the new membership of NASA in W3C, we are now literally architecture astronauts

jwatt: when did that happen?

pdengler: a few days ago

ChrisL: diffusion constraintsin vector graphics paper:

<ChrisL> http://artis.inrialpes.fr/Publications/2010/BEDT10/

ChrisL: note thats are in english ;)
... which suggests they want this Out There :)

email from Luke Kenneth Casson Leighton: "do remind them of the existence of GWTCanvas and its python port, which works even under pyjamas-desktop using DCOM to connect directly with MSHTML.DLL"
svg 1.1

ed_work: whats left to be done on the spec itself?

ChrisL: im working it into shape
... there are rules for produce a tech report on the w3 website
... thats the document you saw and im getting it ready so when we are ready for publshing it can go straight
... there are other docs to do, and an internal meeting, and you effectvely go through the candidate recommentation process again

ed_work: do we need a minuted resultion? anyone objecting?
... okay, we resolve to request publication of SVG 1.1 PER

Resolution: We will request publication of SVG 1.1 PER

<ChrisL> file://localhost/D:/WWW/dev/SVG/profiles/1.1F2/errata/implementation-report.html

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/test/status/test_suite_status.html

shepazu: MS passes 100% of svg tests they submitted :)

pdengler: opera passed 100% of their test subsmission :)

ed_work: no it didnt :)

;)

<ChrisL> ACTION: chris to request PER of SVG 1.1SE [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action04]

<trackbot> Created ACTION-2793 - Request PER of SVG 1.1SE [on Chris Lilley - due 2010-06-07].

<pdengler> I will work on the test suite from svgdom-over-01-f.svg reverse alphabetical

<pdengler> Anthony will resubmit the MSFT tests that didn't have the CVS parameter set correctly

fat_tony: so are we done with 1.1?

ed_work: yeah

ChrisL: tlaking about the week of 7th june? im free friday

shepazu: im traveling all june

ed_work: is a marathon teleconf any good?

pdengler: time overlaps are tricky

ChrisL: block time and people can bookend it
... like a scrum, rotate through when they are available so all can participate

DS: i can do it whenever

fat_tony: same

ChrisL: shepazu, HTML+SVG?

shepazu: 2 more things, short ones
SVG+HTML

shepazu: MSIE considered novel syntax... HTMl5 is some way from being done and the parsing algo has only 1 implementaitn thats incomplete
... from W3C process perspective its far from done

jwatt: the strategy to ship first is a problem

ChrisL: its shipped and not finalised at the same time

;)

ed_work: there's 2 impkementations

shepazu: there maybe 2, but 'we shipped libhtml5' doesn't conut

s/conut/count

<AlexD> Are there any tests for HTMl5 parsing conformance?

pdengler: MSIE 9 hsa no plans for this, its for later. first we need to rationalise and unionise many things
... i could throw out some idea on default inlining SVG... putting an XY coordinateon a div in svg, that wont hold unless you ge tthe other stuff sorted
... we have to nail the union of the 2 specs

shepazu: if its ships its too late (?)

pdengler: it requires cooperation with the HTML group. when do they close the spec?

jwatt: its open for some time

pdengler: right

jwatt: once something ships, if we both ship HTML5 parses...

pdengler: is this a parsing problem? if so, raise them, but i wont thikn what they might be, i look at what people want to do

<AlexD> Given how long it will take HTML5 to mature (i.e. PREC) then perhaps SVG needs to take some lead in an HTML(4)+SVG integration profile... HTML5 is a bit of vapourware right now really.

shepazu: these are coupled, yes.
... say you want serverside stuff, and we can imagine a html6 parser being different. parsers determine what syntax is allowed

pdengler: can a div work in a co ordinate space/
... when do we decide this is a div/
... like a div within SVG
... what does it mean to have HTML not as a foreign object in SVG?
... we are yet to dicover what people expet and how they will use SVVG in HTML
... remove the idea of forign object..?

jwatt: is this in scope of html5?
... they are only looking at parse

r level

scribe:

shepazu: to draw this to a close, we need to go backto html5 group and say, we got these use cases....
... how productive will itbe at this point?

<AlexD> There is a difficult line to tread here. Parsers may define what syntax is allowed but HTML and tag-soup has allowed all sorts of non-spec compliant to try to render something. SVG has tried to be more strict. When we join them, what will the author expect and what should we mandate?

jwatt: parsing thing, its more the CSS WG to talk to
... existing specs its not well done
... look at draft cSS spec
... need to look at CSS2.1

ChrisL: intended to bedeon thi yar

shepazu: we should consider what the WGs did

<scribe> ACTION: pdengler to talk to MSIE team about HTML5+SVG tests [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action05]

<trackbot> Created ACTION-2794 - Talk to MSIE team about HTML5+SVG tests [on Patrick Dengler - due 2010-06-07].

UNKNOWN_SPEAKER:

shepazu: we can move forward on this in the context of SVG integration

pdengler: integration is an optional module for 2.0. its key going forward.

shepazu: its a standalone module, yes
Group Workflow

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Group_Workflow

<pdengler> scribenick : pdengler

shepazu: This link was set up in the context of the conversation that Patrick brought up earlier around use cases.
... Review and make recommended changes to this
... don't move the status of specs from proposed to approved before we have tests for those

ed: I don't think this will work as we will have changes across the entire spec
... It is a good idea to differentiate between what is proposed, and what is approved, but we don' t necessarily have anything better

shepazu: to be clear, have all of the tests in place, not just some

ChrisL: I share the concern that there will be cross dependencies that will be difficult to manage

shepazu: We could have a status of 'approved pending..'

ChrisL: We need a stage of 'being worked on, but not just proposed'

shepazu: As part of our process of submitting specs, that we formally adopt the idea that right away we right tests for it

anthony: For the print spec, we tried to mark up the assertions in the spec and this worked well
... We did this for the compositing spec as well, and then wrote tests against them, which made it much easier to link to assertions
Summary of Action Items
[NEW] ACTION: anthony Investigate rendering methods for diffusion curves [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action03]
[NEW] ACTION: chris to request PER of SVG 1.1SE [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action04]
[NEW] ACTION: chrisl to investigate diffusion curves and potentials for SVG 2.0 [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action02]
[NEW] ACTION: pdengler to post plan for the plan for SVG 2.0 on the Wiki [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action01]
[NEW] ACTION: pdengler to talk to MSIE team about HTML5+SVG tests [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action05]
 
[End of minutes]

-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Monday, 31 May 2010 14:53:22 UTC