08:05:07 <RRSAgent> RRSAgent has joined #svg
08:05:07 <RRSAgent> logging to http://www.w3.org/2010/05/31-svg-irc
08:05:09 <trackbot> RRSAgent, make logs public
08:05:11 <trackbot> Zakim, this will be GA_SVGWG
08:05:11 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
08:05:12 <trackbot> Meeting: SVG Working Group Teleconference
08:05:12 <trackbot> Date: 31 May 2010
08:05:32 <pdengler> pdengler has joined #svg
08:05:38 <ed> ed has joined #svg
08:05:53 <ed> trackbot, start telcon
08:05:55 <trackbot> RRSAgent, make logs public
08:05:57 <trackbot> Zakim, this will be GA_SVGWG
08:05:57 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
08:05:58 <trackbot> Meeting: SVG Working Group Teleconference
08:05:58 <trackbot> Date: 31 May 2010
08:06:39 <ed> Zakim, remind me in 8 hours about whatever
08:06:39 <Zakim> ok, ed
08:13:08 <jwatt> jwatt has joined #svg
08:15:05 <ChrisL> ChrisL has joined #svg
08:15:28 <ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/font-family-invalid-chars-02.svg
08:15:50 <pdengler> scribenick: pdengler
08:16:15 <pdengler> topic: CSS 2.1 Issue 114
08:17:49 <pdengler> 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
08:18:16 <pdengler> ChrisL: And that you should in fact skip over the entire list, which means the default font should be used
08:18:24 <ChrisL> firefox 3.6 shows all numbers
08:18:42 <ChrisL> opera 10.10 does too but opera 10.53 shows no numbers
08:18:46 <pdengler> pdengler: IE Platform preview shows none 
08:19:32 <pdengler> pdengler: Chrome does the same as IE and FireFox
08:19:56 <ed> opera 10.53 shows no text at all (even the "revision" string), wondering if it really finds the proper font there 
08:20:29 <pdengler> ChrisL: Proposal is that a CSS font should be an ident. But this is potentially to strict
08:20:48 <pdengler> ChrisL: The issue is that certain characters would have to be quoted
08:21:59 <pdengler> pdengler: This means that fonts that start with (1-9) would have to be quoted
08:23:41 <pdengler> 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
08:24:05 <pdengler> pdengler: Correction IE shows the numbers just as Chrome and Firefox
08:24:24 <ChrisL> batik (svn) shows the numbers (and a bunch of error messages)
08:24:41 <pdengler> ChrisL: Suggest we go with Mozilla proposal.
08:25:43 <ChrisL> so font family would be a list of CSS2.1 IDENT
08:26:42 <ed> http://wiki.csswg.org/spec/css2.1#issue-114
08:28:21 <ChrisL> so SVG WG aligns with proposal 1, http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html
08:29:19 <ChrisL> action chris to convey this result to CSS WG
08:29:20 <trackbot> Created ACTION-2788 - Convey this result to CSS WG [on Chris Lilley - due 2010-06-07].
08:29:57 <ChrisL> action-2788?
08:29:57 <trackbot> ACTION-2788 -- Chris Lilley to convey this result to CSS WG -- due 2010-06-07 -- OPEN
08:29:57 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2788
08:31:45 <ChrisL> action chris to move the font-family parsing tests to the svg 1.1se test suite
08:31:45 <trackbot> Created ACTION-2789 - Move the font-family parsing tests to the svg 1.1se test suite [on Chris Lilley - due 2010-06-07].
08:40:13 <pdengler> nomis: The basic idea behind diffusion curves is that you define shapes, and then colors on the sides of a curve
08:40:43 <pdengler> Topic : Diffusion Curves by Simon from GIMP
08:40:54 <ChrisL> http://wiki.inkscape.org/wiki/index.php/Diffusion_Curves
08:42:03 <shepazu> http://lists.w3.org/Archives/Public/www-svg/2010May/0032.html
08:42:04 <nomis> nomis has joined #svg
08:42:46 <shepazu> shepazu has joined #svg
08:42:51 <pdengler> nomis: Simon has prototyped this on RGB (not yet on curves) but on pixels that diffuse colors
08:43:20 <nomis> I'd like to emphasize that all of the algorithm implementation is done by jasper.
08:46:44 <ChrisL> original paper http://artis.imag.fr/Publications/2008/OBWBTS08/
09:02:03 <ed> ed has joined #svg
09:05:33 <pdengler> 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
09:06:13 <pdengler> AlexD: Other use cases include removing/smoothing through averaging an image (such as 'air brushing a photo')
09:06:38 <ed_> ed_ has joined #svg
09:07:10 <pdengler> anthony: The issue with the original alogithm is that it was an iterative method. This was an issue with animation causing computational intensive rendering
09:07:23 <pdengler> ChrisL: Since then, there have been some papers on making that issue more tractable
09:07:28 <pdengler> pdengler: So what about the IP around this?
09:15:44 <shepazu> shepazu has joined #svg
09:21:45 <pdengler> pdengler has joined #svg
09:22:11 <pdengler> anthony: If you look at these images, they all have smooth edges.  But if you have a pattern, this begins to break down
09:22:28 <pdengler> ChrisL: That's why having it in SVG is more powerful in an SVG Authoring Tool
09:22:50 <pdengler> anthony: Hi frequency color changes do not work as well (from the author and from Anthony)
09:24:56 <pdengler> ChrisL: How would this be integrated into SVG?
09:27:21 <pdengler> nomis: Why define diffusion curves independent of the image
09:28:19 <pdengler> shepazu: We are discussoin whether to make it a paint server, or whether you apply via an effect
09:28:42 <pdengler> anthony: Could you do it through filters where you apply it to shape?
09:28:47 <pdengler> ed: Doesn't come naturally that way
09:29:10 <pdengler> ChrisL: We are going to need some sort of syntax that allows to define 'left-side'/'right-side' colors
09:29:29 <pdengler> ChrisL: You can imagine it being referenced as a fill/paint as you can any other paint
09:30:17 <pdengler> shepazu: I was thinking of a new property, e.g. 
09:32:24 <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?
09:33:06 <AlexD> BTW, left/right side fill is the Flash model.
09:33:20 <pdengler> anthony: Consider using the new path syntax
09:33:49 <ChrisL> yes but its a solid fill i believe
09:34:59 <pdengler> shepazu: e.g. new path syntax <path><quadratic ../><lineto../><horiztonal ../></path>
09:35:15 <ed> AlexD: yeah, the complexity does worry me as well
09:35:28 <pdengler> shepazu: consider too verbose.  But if you use compressed it, it turns out the the compressed format is much better
09:35:55 <pdengler> pdengler: I still think it's too verbose given the potential use cases
09:37:25 <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.
09:39:07 <pdengler> ed: I've been working on OpenGL; would it be interesting to redefine a path syntax to include a color?
09:40:00 <pdengler> 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
09:40:06 <pdengler> pdengler: No way 
09:42:30 <pdengler> 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)
09:43:07 <pdengler> nomis: I'm not sure why you would want to restrict this to bezier curves?
09:43:09 <pdengler> ChrisL: Simplicty
09:43:21 <pdengler> nomis: But any path can have these
09:49:03 <pdengler> shepazu: Back to the agenda, we want to talk about group workflow
09:50:23 <pdengler> shepazu: 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
09:50:36 <pdengler> shepazu: Now we are just brainstorming
09:50:51 <pdengler> ChrisL: We have had a couple of runs at diffusion curves; we are excited about it; we see the potential now
09:51:07 <pdengler> anthony: In that case, we should gather the ideas together and write them down
09:54:05 <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.
09:54:20 <AlexD> s?1/2?1.2?
09:54:56 <pdengler> shepazu: So does GIMP import SVG?
09:55:01 <pdengler> nomis: Yes.
09:55:11 <pdengler> ChrisL: Can you interpret clipping paths on raster images?
09:55:45 <pdengler> nomis: We output them from raster images; you can defining a clipping path for exporting to TIF for example
09:57:09 <pdengler> 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
09:57:52 <pdengler> action : pdengler to post plan for the plan for SVG 2.0 on the Wiki
09:57:52 <trackbot> Created ACTION-2790 - Post plan for the plan for SVG 2.0 on the Wiki [on Patrick Dengler - due 2010-06-07].
10:01:30 <pdengler> 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
10:02:31 <pdengler> Topic : Fonts
10:03:07 <pdengler> Action : chrisl to investigate diffusion curves and potentials for SVG 2.0
10:03:07 <trackbot> Created ACTION-2791 - Investigate diffusion curves and potentials for SVG 2.0 [on Chris Lilley - due 2010-06-07].
10:03:27 <nomis> if anybody wants to play with the prototype diffusion code: http://www.home.unix-ag.org/simon/files/diffuselib.tgz
10:04:21 <pdengler> ChrisL: Will investigate syntax, authoring tools, use cases
10:04:48 <pdengler> anthony: I will investigate rendering methods
10:05:13 <pdengler> action : anthony Investigate rendering methods for diffusion curves
10:05:13 <trackbot> Created ACTION-2792 - Investigate rendering methods for diffusion curves [on Anthony Grasso - due 2010-06-07].
10:06:23 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Diffusion_Curves
10:08:30 <fat_tony> Topic: Text and Fonts
10:10:10 <fat_tony> CL: I have a proposal for SVG 2.0 as what we should do for fonts
10:10:52 <fat_tony> ... the web has meanwhile moved to downloading fonts of web
10:10:59 <fat_tony> ... in 1.0 you were required to SVG fonts
10:11:18 <fat_tony> ... I propose for SVG 2.0 we mandate you use WOFF
10:11:27 <fat_tony> ... and have SVG Fonts as an optional features
10:11:53 <fat_tony> DS: I have a counter proposal, right now we have SVG Tiny 1.2 fonts in Opera and Webkit
10:11:58 <fat_tony> ... and there are patches for FireFox
10:12:02 <fat_tony> DC: Yes
10:12:50 <fat_tony> JW: We don't currently SVG Fonts are the well designed and should be the solution going forward
10:13:05 <fat_tony> ... if we have demand from users to put them then we will consider it
10:13:26 <fat_tony> ... at the moment we'll see how WOFF goes
10:13:41 <fat_tony> ... and if that meets the majority of uses cases we can gather the uses cases it doesn't meet
10:13:51 <fat_tony> ... and reconsider
10:14:17 <fat_tony> DS: My counter proposal is we add SVG Tiny 1.2 fonts to SVG 2.0
10:14:24 <fat_tony> ... we consider adding it
10:14:30 <fat_tony> ... then we have separate font specification
10:14:37 <fat_tony> CL: Had considered that
10:14:41 <AlexD> What's the status of WOFF standards-wise? Is this W3C working group or loosely coupled vendor alliance like WhatWG?
10:14:51 <fat_tony> ... but there are few reasons why I didn't say this
10:16:07 <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
10:16:16 <fat_tony> ... that's the bit that should be held onto SVG Fonts
10:16:32 <fat_tony> PD: What couldn't you take those benefits that SVG Fonts have, and take those to WOFF
10:16:51 <fat_tony> CL: Because WOFF is a packaging format for OpenType
10:17:59 <fat_tony> PD: I agree we should put fonts in as an optional module
10:18:15 <fat_tony> ... SVG Fonts as an optional module
10:18:27 <fat_tony> ... If customers demand it, I'll build it
10:18:35 <fat_tony> ED: I agree with what Doug proposed
10:18:41 <fat_tony> ... breaking it out is fine
10:18:46 <AlexD> SVG Tiny 1.2 fonts is trivial to implement, and by being defined as a font allows an implementation to
10:18:52 <fat_tony> ... but that subset should be required
10:18:58 <AlexD> optionally cache glyphs.
10:19:05 <fat_tony> ... because that is already implemented
10:19:48 <ChrisL> @alex: woff is being standardized at W3C
10:20:10 <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.
10:20:14 <fat_tony> DS: To me as a developer, there are couple of different things about SVG Tiny 1.2 fonts
10:20:17 <fat_tony> ... you can have overlaps
10:20:20 <ChrisL> http://www.w3.org/Fonts/WG/
10:20:23 <fat_tony> ... which you can't do in traditional fonts
10:20:29 <fat_tony> ... and you can do scripting
10:20:33 <fat_tony> ... which is why I would want them
10:20:38 <fat_tony> ... I'll be flexible on this
10:21:48 <fat_tony> DC: [gives diagram over overlapping diagram]
10:22:25 <fat_tony> s/overlapping diagram/overlapping font/
10:24:15 <fat_tony> DS: Wouldn't want overlapping fonts unless you get to headers
10:24:40 <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...
10:26:05 <fat_tony> PD: In terms of beyond headers is it reasonable to use SVG Fonts for a document?
10:26:17 <fat_tony> ED: Primary use case is headers
10:26:40 <fat_tony> s/headers/headings/
10:26:43 <shepazu> s/headers/headings/
10:27:11 <fat_tony> DC: My experience of SVG graphics is they can be quite slow
10:27:28 <fat_tony> PD: I know you have more use cases
10:27:37 <fat_tony> ED: I'm not saying the whole module should be required
10:27:56 <fat_tony> ... I'm saying a small subset that's already implemented should be carried on to the new spec
10:27:57 <shepazu> s/can be quite slow/can be quite slow, so it's not typical to render large blocks of text/
10:28:10 <fat_tony> DS: There are two or three proposals on the table
10:29:13 <fat_tony> BL: I think it use already
10:29:18 <fat_tony> ... the SVG Fonts
10:29:25 <fat_tony> ... if you make it optional now
10:29:38 <fat_tony> ... it might not work anymore
10:29:42 <fat_tony> CL: That's the issue now
10:29:53 <fat_tony> BL: Can do a lot of great things with SVG Fonts
10:30:13 <fat_tony> PD: It will be only performant it will on be use cases for headings
10:30:25 <fat_tony> BL: Is there a technology right now that can replace SVG Fonts
10:30:31 <fat_tony> PD: We don't need fonts
10:30:35 <fat_tony> ... you can use paths
10:30:47 <fat_tony> ... we have this huge API on this thing called fonts
10:30:55 <fat_tony> CL: You're suggesting don't put text there
10:30:59 <fat_tony> ... put graphics there
10:31:14 <fat_tony> ... not good for accessibility
10:31:24 <fat_tony> PD: It just seems heavy handed
10:31:45 <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...
10:31:49 <fat_tony> CL: You've converted the curve and stuck an element to say it's font
10:32:28 <fat_tony> DS: There is altGlyph
10:33:07 <fat_tony> ... This is the reverse to the way I would've done it
10:33:12 <fat_tony> ... syntax would be like:
10:33:32 <shepazu> <text ...><altGlyph xlink:href="#myshape">My Logo</altGlyph> </text>
10:35:07 <fat_tony> CL: It points to a glyph
10:35:15 <fat_tony> ... it has to say what the base line is
10:35:26 <ChrisL> and the coordinate system
10:35:40 <fat_tony> DS: We could alter altGlyph
10:35:47 <fat_tony> ... as if it where a use
10:35:58 <fat_tony> CL: Where is your point you're anchoring at?
10:37:30 <fat_tony> DS: If you're pointing at something that is not a glyph it acts more like a <use>
10:37:36 <fat_tony> ... but it does it inline
10:37:51 <fat_tony> ... we'd have to define in the spec what things in the spec what the baseline is
10:39:23 <fat_tony> JW: I'm not resistant to working on SVG Fonts
10:39:32 <fat_tony> ... I'm just saying it should not be required by 2.0
10:39:41 <fat_tony> ... I'm quite happy to work and participate on the fonts part
10:40:04 <fat_tony> ... there's a difference to us having fonts in our charter compared to requiring it
10:40:19 <fat_tony> CL: Do you think Mozilla would implement it if it was optional?
10:40:28 <fat_tony> JW: Depends on demand
10:41:05 <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...
10:42:54 <pdengler> Not all browsers support them now
10:43:22 <AlexD> True - but there are _many_ mobile and IPTV user agents that do.
10:44:28 <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...
10:44:43 <ChrisL> alex, these are all good points
10:44:49 <ChrisL> so does inkscape
10:45:22 <ChrisL> inkscape can author svg fonts as well. as can fontforge
10:45:50 <ChrisL> deprecation is not on the table
10:46:16 <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
10:46:52 <fat_tony> ... I'm proposing some sort of altGlyph like solution
10:47:19 <fat_tony> ... so we don't have content out that is not a-semantic
10:47:30 <fat_tony> ... want text extraction and text search to work
10:48:32 <fat_tony> PD: It gets tricky with fonts on a path
10:50:53 <AlexD> What's tricky about fonts on a path?
11:56:34 <ChrisL> debug off, optimize on, deprecation on
12:00:55 <ed> dave crossland: one usecase I see for svgfonts is photo-fonts
12:01:09 <ed> ...there are such proprietary font formats
12:01:35 <ed> CL: we should collect those on a wiki or something
12:02:02 <ed> DS: fontlab (photolab)
12:02:13 <ed> s/photolab/photofont.com/
12:02:54 <ed> DC: you're not going to typeset a book with a photofont, but it does get used for some things
12:03:21 <ed> DS: the scrapbooking community might be interested in this
12:04:48 <ed> DS: (shows a glyphshape used as a clippath, cutting out a letter G of a photo)
12:08:34 <ed> (examples of photofonts shown)
12:09:55 <ed> DC: sometimes you want glyphs randomly selected, having several shapes, like for handwriting fonts 
12:10:12 <ed> CL: you could do most of that using an svgfont
12:10:20 <ed> ...using ligatures etc
12:11:08 <ed> DC: full svgfonts would give the power to do more interesting (such as photofonts)
12:11:42 <ed> ... so saying it would be nice if full svgfonts were supported in svg 2.0
12:12:00 <ed> DS: we don't see it on the web much today
12:12:55 <ed> ... designers might want to be able to use these features, things that can't be done with traditional fonts
12:13:07 <ed> ...and I'm fine with having svgfonts as an optional module
12:15:30 <ed> topic: xlink:href and html integration
12:15:40 <ed> scribenick: ed
12:16:24 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href
12:16:39 <pdengler> pdengler has joined #svg
12:17:58 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href
12:24:44 <fat_tony> sribenick: fat_tony
12:25:05 <fat_tony> ED: If you had xlink:href and href on an element which one would you throw away?
12:25:49 <ed> s/which one would you throw away?/you are saying that one of them is thrown away during parsing?/
12:26:28 <abattis> abattis has joined #svg
12:26:31 <abattis> O
12:26:35 <abattis> Yo
12:26:48 <abattis> scribenick
12:27:31 <abattis> scribenick: abattis 
12:27:45 <ChrisL> scribe: Dave_Crossland
12:27:52 <abattis> scribe: Dave Crossland
12:28:34 <abattis> shepazu: here's now IRC works
12:29:00 <abattis> ... and thats it. 
12:30:24 <abattis> ... If only xlink:href is present it will be put into the DOM property href and when serialised href is not namespaced
12:30:49 <abattis> ... theres one remaining usse
12:30:58 <abattis> ... xlink is used in content for title="" 
12:31:14 <abattis> ... the xlink title is meant to describe the nature of the lnked resource, not the graphic in the SVG
12:31:30 <abattis> ... so do we get rid of xlink and added title as well to fulfil that function
12:31:36 <abattis> ... so its title as used in html
12:31:54 <abattis> ChrisL: we only added it because XLINK had it
12:32:12 <abattis> ... having human readbale text in attributes where you can't i18n it 
12:32:22 <abattis> ... but xlink made that mistake and we can inherit it (?) 
12:32:35 <abattis> shepazu: title as in attribute descirbes whats being linked to
12:32:43 <abattis> ... title as a child describes the link itseld
12:32:52 <abattis> ... itself
12:33:03 <abattis> ChrisL: HTML can do both, eg lang
12:33:19 <abattis> shepazu: svg tin 1.2 today does it with attribute only
12:33:32 <abattis> ... i prpose we say yes
12:33:52 <abattis> pdengler: what do i put in for script? 
12:34:08 <ChrisL> href
12:34:09 <abattis> shepazu: first, i want to minute a resolution to go with this plan
12:34:24 <abattis> pdengler: if you put href on an image 
12:34:39 <ChrisL> s/lang/lang and hreflang/
12:34:58 <abattis> ... then _IF_ we have a goal of syntactic and programmatic (img.src) 
12:35:08 <abattis> shepazu: epareate the issues of src and href
12:35:31 <abattis> ... our goal can be to treat href one way and agree ,and then look at src
12:35:39 <abattis> pdengler: you think we can get agreemnt on src fast?
12:36:07 <abattis> ChrisL: you end up with a guessing game for href and src, if they are dfferent, people dont remember
12:36:12 <abattis> pdengler: src is more important
12:36:26 <abattis> shepazu: we have to resolve how href is processed
12:36:34 <abattis> ... its definied in <use> 
12:36:43 <abattis> ... they are really separate issues
12:36:54 <abattis> ... are you saying not to allow image href at all?
12:37:01 <abattis> pdengler: you want IE to do this
12:37:03 <abattis> shepazu: yes
12:37:12 <abattis> pdengler: if we ship IE with image href
12:37:21 <abattis> shepazu: that doesnt preclude img src, we can do both
12:37:24 <abattis> pdengler: whats the API look like?
12:37:27 <abattis> shepazu: crappy
12:37:38 <abattis> shepazu: we have to say what happens with href, period
12:37:51 <abattis> ... we have to say what happens when we have href there, so thats why its separate issue
12:38:09 <abattis> .. everywhere
12:38:12 <abattis> ... everywhere
12:38:19 <abattis> ... even HTML when SVG is inside HTML
12:38:24 <abattis> pdengler: so out of doc?
12:38:27 <abattis> shepazu: everywhere!
12:38:46 <abattis> pdengler: theres an issue with the API... i hate to proliferate and attribute
12:38:55 <abattis> shepazu: maybe its okay, lemme think
12:39:08 <abattis> shepazu: i think its separete because if we start doing <script src=""> then
12:39:16 <abattis> ... theres a better case there than <img> 
12:39:30 <abattis> ... its a tag spelled differently, behaves differently
12:39:40 <abattis> pdengler: we can make a case t oHTML WG they have inconsisntecyn
12:46:11 <abattis> abattis: whats up with html 6?
12:46:29 <abattis> shepazu: there are things talked about not going in to html5, so probably there will be one
12:46:41 <abattis> ... okay, so, href itself is readonly
12:46:58 <abattis> ed_work: theres a link thats read-write
12:47:02 <abattis> ed_work: the spec is confused
12:47:17 <abattis> ed_work: its RW because you can write to what it points to
12:47:43 <ed> ed has joined #svg
12:47:56 <abattis> shepazu: so can we get an AMEN to xlink:href 
12:47:59 <abattis> pdengler: amen
12:48:11 <abattis> jwatt: ummm let me think
12:48:27 <abattis> fat_tony: amen
12:48:33 <abattis> shepazu: patches welcome
12:48:36 <ChrisL> yea verily
12:49:06 <abattis> 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
12:49:11 <abattis> jwatt: srsly?
12:49:30 <abattis> ChrisL: more time?
12:49:46 <abattis> jwatt: i dont think we should throw it away, we should put both into DOM and give one precedence
12:49:55 <abattis> ChrisL: and if one is chagned later, what happens?
12:50:01 <abattis> jwatt: a script can set attributes for both
12:50:08 <abattis> ... or does it throw?
12:50:13 <abattis> ... there are still issues to be worked out
12:50:28 <abattis> ... on that point i prefer precedence than messing with the parser
12:50:57 <AlexD> I agree with JWatt, allow both and add precedence, like we did for xml:id and id in Tiny.
12:50:59 <abattis> shepazu: i want to see a more formal prposal, thats a cxomplex design descisoin for a minor use case
12:51:09 <abattis> ... and i think browser vendors would agree
12:51:18 <abattis> ... mozilla people have said this idea isnt a good solution to me
12:51:20 <abattis> jwatt: not to me
12:51:41 <abattis> shepazu: AlexD, that was a disaster
12:51:50 <abattis> (lol)
12:51:58 <AlexD> Agreed, I don't like xml:id at all.
12:52:04 <abattis> shepazu: you have 2 dom attirbutes, why?
12:52:16 <abattis> ... what happens when you hcange the href property?
12:52:43 <abattis> 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
12:52:49 <abattis> ... if you set both, you get both bcak
12:53:14 <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.
12:53:23 <abattis> 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
12:54:26 <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.
12:55:04 <abattis> shepazu: lets not fork SVG, i dont want different behavour in SVG standalone and SVG+HTML
12:55:24 <abattis> ed_work: AlexD makes an interesting point
12:55:29 <AlexD> So we're screwed:-)
12:55:30 <abattis> shepazu: i dont want differnet behaviour
12:55:48 <abattis> ChrisL: either do it in the parsing model of each, or its the same in both
12:56:04 <abattis> shepazu: i really want it tobe simple and unambiguous for authors and simpler for implementors
12:56:24 <abattis> jwatt: its no problem to see if we have href, if so use it, else if xlink, use that
12:56:25 <ChrisL> s/in both/in both, and thus we can't discard attributes/
12:56:37 <abattis> shepazu: its not as simple as that, its what i wrot ethe page for
12:56:42 <abattis> jwatt: link pls
12:56:46 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href
12:56:53 <AlexD> Simplest for implementation is to just ignore the namespace prefix, so href is all that's looked at.
12:59:00 <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...
12:59:05 <abattis> jwatt: ed, were you obejcting to my idea?
12:59:07 <abattis> ed_work: no
12:59:18 <abattis> jwatt: this doesnt to me mess with what the makrup does
12:59:28 <abattis> shepazu: it seems like deprecating href in a way
12:59:48 <abattis> jwatt: i dont see why it encourages its use more than dougs solution
12:59:50 <abattis> shepazu: ok
12:59:59 <abattis> ... maybe a simpler syntax is a win
13:00:07 <ed> s/ed_work: no/ed: just restating the discussion we had a bit back, not objecting/
13:00:15 <abattis> ... but what if you have both, and you setone, and its href it takes precedence/
13:00:54 <abattis> jwatt: if you set an attribute, thats what you want
13:01:16 <abattis> ... someone setting on attr and animating the other? a real edge case we dont need to consider highly
13:02:16 <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.
13:02:28 <abattis> ... to restate: it seems easy to allow setting both, and see if either exists and use that, and precedence is ... 
13:02:34 <abattis> shepazu: how do you serialise that?
13:02:46 <abattis> jwatt: serialise them both
13:02:53 <abattis> ... if they put it in for backward compatibiltly
13:03:05 <AlexD> JWatt: Nooooooo..... Yuk!
13:03:21 <abattis> ChrisL: before <a> name="" to id="", people duplicated the values in both attrs
13:03:27 <AlexD> We have a document model or we don't.
13:03:53 <abattis> jwatt: shepazu, if you think inserting is a bad thing, tell me
13:04:07 <abattis> ChrisL: AlexD says ^^^
13:04:19 <abattis> ... i can live with jwatts prposal, i want to see it written pu
13:04:52 <abattis> ed_work: so, for animating, say ou animate the URLs, different HREFs, with the DOM you take one out
13:04:58 <abattis> ... it makes it harder to deal with dependenceies
13:05:02 <abattis> jwatt: not got it
13:05:06 <abattis> ... you animate an attr
13:05:14 <abattis> ed_work: now you can animate attrs
13:05:26 <abattis> jwatt: eh? i can put 2 animator tags in and do it separately
13:05:41 <abattis> pdengler: now we're tlaking abotu 2.0 without types or other thing
13:05:49 <abattis> pdengler: do we know if href should be an animated string?
13:05:58 <abattis> ... the first time we looked at href we choked
13:06:14 <abattis> ... i know what youre trying to get done, get href, i dont worry about animating this thing
13:06:29 <abattis> ... my argument against jwats proposal is that they will pile up
13:06:48 <abattis> ... if you dont set a stake in the ground about higher level constricts uts hard to nke desicsions abut the details
13:07:06 <abattis> jwatt: simple cases like rollovers, slideshows, 
13:07:12 <abattis> pdengler: xhtml never had these? 
13:07:19 <abattis> ChrisL: yo uhad to do it with script
13:07:39 <abattis> pdengler: is SVG for the 500 people using it to date? or the millions of web devs who know a programming pattern
13:07:48 <abattis> pdengler: plan that stuff first
13:08:10 <abattis> pdengler: if theres a middle ground about what jwatt needs, modifing th eprposal, im not concenred about animated types but ed_work is
13:08:24 <abattis> ... it looks like a problem, but until i see an nimated href
13:08:31 <abattis> ChrisL: they ar ein SMIL
13:08:47 <abattis> shepazu: are you using aniimating in a different way? a mouseover, a cilick, can be an animation
13:08:53 <abattis> pdengler: i havent seen much SMIL content
13:09:00 <abattis> ... nor much SVG content
13:09:10 <abattis> shepazu: its 3pm
13:09:18 <abattis> ... jwatt, what do you say?
13:09:25 <abattis> jwatt: we have precedence
13:09:32 <abattis> jwatt: dont drop or not set attrs
13:10:02 <ChrisL> Resolution: accept modified href proposal with no dropped attributes, just precedence
13:10:04 <abattis> shepazu: okay, ill modify the prposal live
13:10:17 <AlexD> Phew
13:10:28 <abattis> :)
13:11:31 <abattis> shepazu: writing it right now!
13:13:24 <FelipeSanches> FelipeSanches has joined #svg
13:13:27 <ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Href
13:13:29 <abattis> ... * read out what i wrote
13:14:11 <abattis> shepazu: when serialised what hpanes?
13:14:18 <abattis> ChrisL: you get back what you put in
13:14:49 <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. 
13:15:15 <FelipeSanches> can we have an in-memory representation of path data that javascript could more easily manipulate?
13:15:38 <ChrisL> @Felipe yes we plan to have a more verbose xml syntactic alternative to cover that use case
13:15:48 <FelipeSanches> thanks
13:17:27 <abattis> pdengler: err we discussed, not planned. memory footprints have unknown tradeoffs
13:17:28 <ChrisL> s/plan/are considering/
13:17:32 <pdengler> I don't agree; we have discussed potential alternatives, but haven't weighed the pros and cons
13:18:39 <abattis> ChrisL: DOM is an API not a memory modeule
13:19:06 <abattis> ... you can give him a mini parser to do that?
13:20:28 <abattis> BREAK TIME
13:36:15 <abattis> pdengler: theres enough benefi tto doing the href
13:36:30 <abattis> ... to have something Just Work
13:36:47 <abattis> ... i would push hard to get this in MSIE to move from HTML development to HTML+SVG development
13:37:21 <abattis> ... 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>
13:37:41 <abattis> ... 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
13:38:04 <abattis> ... 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
13:38:11 <abattis> ... so i dont think were ready to dicuss SRC
13:38:30 <abattis> shepazu: with the new membership of NASA in W3C, we are now literally architecture astronauts
13:38:37 <abattis> jwatt: when did that happen?
13:38:41 <abattis> pdengler: a few days ago
13:39:04 <abattis> ChrisL: diffusion constraintsin vector graphics paper:
13:39:08 <ChrisL> http://artis.inrialpes.fr/Publications/2010/BEDT10/
13:39:36 <abattis> ChrisL: note thats are in english ;)
13:39:52 <abattis> ChrisL: which suggests they want this Out There :)
13:41:12 <abattis> 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"
13:44:50 <abattis> topic: svg 1.1
13:45:03 <abattis> ed_work: whats left to be done on the spec itself?
13:45:11 <abattis> ChrisL: im working it into shape
13:45:28 <abattis> ... there are rules for produce a tech report on the w3 website
13:45:48 <abattis> ... thats the document you saw and im getting it ready so when we are ready for publshing it can go straight
13:46:19 <abattis> ... there are other docs to do, and an internal meeting, and you effectvely go through the candidate recommentation again
13:46:31 <abattis> s/recommentation again/recommentation process again/
13:47:00 <abattis> ed_work: do we need a minuted resultion? anyone objecting?
13:47:23 <abattis> ed_work: okay, we resolve to request publication of SVG 1.1 PER
13:47:40 <abattis> Resolution: We will request publication of SVG 1.1 PER
13:47:45 <pdengler> pdengler has joined #svg
13:47:54 <ed> ed has joined #svg
13:47:57 <ed> RRSAgent, pointer?
13:47:57 <RRSAgent> See http://www.w3.org/2010/05/31-svg-irc#T13-47-57
13:49:51 <FelipeSanches> FelipeSanches has left #svg
13:50:35 <ChrisL> file://localhost/D:/WWW/dev/SVG/profiles/1.1F2/errata/implementation-report.html
13:50:55 <ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html
13:51:52 <ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/test/status/test_suite_status.html
13:55:22 <abattis> shepazu: MS passes 100% of svg tests they submitted
13:55:46 <abattis> pdengler: opera passed 100% of their test subsmission :)
13:56:05 <abattis> ed_work: no it didnt :)
13:56:20 <abattis> ;)
13:58:19 <shepazu> s/MS passes 100% of svg tests they submitted/MS passes 100% of svg tests they submitted :)/
13:58:54 <ChrisL> action: chris to request PER of SVG 1.1SE
13:58:55 <trackbot> Created ACTION-2793 - Request PER of SVG 1.1SE [on Chris Lilley - due 2010-06-07].
14:04:08 <pdengler> I will work on the test suite from svgdom-over-01-f.svg reverse alphabetical
14:04:29 <pdengler> Anthony will resubmit the MSFT tests that didn't have the CVS parameter set correctly
14:09:04 <abattis> fat_tony: so are we done with 1.1?
14:09:05 <abattis> ed_work: yeah
14:09:19 <abattis> ChrisL: tlaking about the week of 7th june? im free friday
14:09:24 <abattis> shepazu: im traveling all june
14:09:42 <abattis> ed_work: is a marathon teleconf any good?
14:09:47 <abattis> pdengler: time overlaps are tricky
14:10:01 <abattis> ChrisL: block time and people can bookend it
14:10:27 <abattis> ChrisL: like a scrum, rotate through when they are available so all can participate
14:11:25 <abattis> ed_work: i can do it whenever
14:11:27 <abattis> fat_tony: same
14:11:42 <abattis> ChrisL: shepazu, HTML+SVG?
14:11:56 <abattis> shepazu: 2 more things, short ones
14:12:35 <abattis> topic: SVG+HTML
14:12:58 <abattis> shepazu: MSIE considered novel syntax... HTMl5 is some way from being done and the parsing algo has only 1 implementaitn thats incomplete
14:13:13 <abattis> shepazu: from W3C process perspective its far from done
14:13:27 <abattis> jwatt: the strategy to ship first is a problem
14:13:40 <abattis> ChrisL: its shipped and not finalised at the same time
14:13:41 <abattis> ;)
14:13:48 <abattis> ed_work: there's 2 impkementations
14:14:00 <ed> s/ed_work/DS/
14:14:15 <abattis> shepazu: there maybe 2, but 'we shipped libhtml5' doesn't conut
14:14:26 <abattis> s/conut/count
14:14:37 <AlexD> Are there any tests for HTMl5 parsing conformance?
14:15:00 <abattis> pdengler: MSIE 9 hsa no plans for this, its for later. first we need to rationalise and unionise many things
14:15:35 <abattis> pdengler: 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
14:16:18 <abattis> pdengler: we have to nail the union of the 2 specs 
14:16:29 <abattis> shepazu: if its ships its too late (?) 
14:16:45 <abattis> pdengler: it requires cooperation with the HTML group. when do they close the spec? 
14:16:53 <abattis> jwatt: its open for some time
14:17:01 <abattis> pdengler: right
14:17:11 <abattis> jwatt: once something ships, if we both ship HTML5 parses...
14:17:43 <abattis> 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 
14:17:57 <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.
14:17:58 <abattis> shepazu: these are coupled, yes. 
14:18:41 <abattis> shepazu: say you want serverside stuff, and we can imagine a html6 parser being different. parsers determine what syntax is allowed
14:19:07 <abattis> pdengler: can a div work in a co ordinate space/ 
14:19:23 <abattis> pdengler: when do we decide this is a div/
14:19:37 <abattis> ... like a div within SVG
14:20:05 <abattis> ... what does it mean to have HTML not as a foreign object in SVG?
14:20:18 <abattis> ... we are yet to dicover what people expet and how they will use SVVG in HTML
14:20:44 <abattis> ... remove the idea of forign object..?
14:20:52 <abattis> jwatt: is this in scope of html5? 
14:21:15 <abattis> jwatt: they are only looking at parse
14:21:18 <abattis> r level
14:23:32 <abattis> ...
14:23:59 <abattis> shepazu: to draw this to a close, we need to go backto html5 group and say, we got these use cases.... 
14:24:10 <abattis> ... how productive will itbe at this point?
14:24:51 <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?
14:25:25 <abattis> jwatt: parsing thing, its more the CSS WG to talk to
14:26:48 <abattis> jwatt: existing specs its not well done
14:27:13 <abattis> jwatt: look at draft cSS spec 
14:28:43 <abattis> jwatt: need to look at CSS2.1 
14:28:54 <abattis> ChrisL: intended to bedeon thi yar
14:29:26 <abattis> shepazu: we should consider what the WGs did
14:35:24 <abattis> Action: pdengler to talk to MSIE team about HTML5+SVG tests
14:35:24 <trackbot> Created ACTION-2794 - Talk to MSIE team about HTML5+SVG tests [on Patrick Dengler - due 2010-06-07].
14:37:16 <abattis> ...
14:39:01 <abattis> shepazu: we can move forward on this in the context of SVG integration
14:39:38 <abattis> pdengler: integration is an optional module for 2.0. its key going forward. 
14:39:50 <abattis> shepazu: its a standalone module, yes
14:40:14 <abattis> Topic: Group Workflow
14:40:17 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Group_Workflow
14:40:51 <pdengler> scribenick : pdengler
14:41:46 <FelipeSanches> FelipeSanches has joined #svg
14:42:05 <pdengler> shepazu: This link was set up in the context of the conversation that Patrick brought up earlier around use cases.
14:42:27 <pdengler> shepazu: Review and make recommended changes to this
14:43:17 <pdengler> shepazu: don't move the status of specs from proposed to approved before we have tests for those
14:43:26 <pdengler> ed: I don't think this will work as we will have changes across the entire spec
14:44:00 <pdengler> ed: It is a good idea to differentiate between what is proposed, and what is approved, but we don' t necessarily have anything better
14:45:40 <pdengler> shepazu: to be clear, have all of the tests in place, not just some
14:45:55 <pdengler> ChrisL: I share the concern that there will be cross dependencies that will be difficult to manage
14:46:14 <pdengler> shepazu: We could have a status of 'approved pending..'
14:46:39 <pdengler> ChrisL: We need a stage of 'being worked on, but not just proposed'
14:46:59 <pdengler> shepazu: As part of our process of submitting specs, that we formally adopt the idea that right away we right tests for it
14:47:32 <ChrisL> zakim, list attendees
14:47:32 <Zakim> sorry, ChrisL, I don't know what conference this is
14:49:56 <pdengler> anthony: For the print spec, we tried to mark up the assertions in the spec and this worked well
14:50:21 <pdengler> anthony: We did this for the compositing spec as well, and then wrote tests against them, which made it much easier to link to assertions
14:50:23 <ChrisL> Present: Alex, Anthony, Dave, JWatt, Doug, Patrick, Erik, Chris, Femke, Felipe, Hin-Tak, Simon
14:50:36 <ChrisL> rrsagent, make minutes
14:50:36 <RRSAgent> I have made the request to generate http://www.w3.org/2010/05/31-svg-minutes.html ChrisL
14:50:56 <ChrisL> rrsagent, make logs public
14:50:59 <ChrisL> rrsagent, make minutes
14:50:59 <RRSAgent> I have made the request to generate http://www.w3.org/2010/05/31-svg-minutes.html ChrisL
14:51:12 <ChrisL> Chair: Erik
14:51:13 <ChrisL> rrsagent, make minutes
14:51:13 <RRSAgent> I have made the request to generate http://www.w3.org/2010/05/31-svg-minutes.html ChrisL
14:53:03 <shepazu> http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html
14:54:56 <shepazu> trackbot, stop telcon
14:54:56 <trackbot> Sorry, shepazu, I don't understand 'trackbot, stop telcon'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
15:04:22 <fat_tony> fat_tony has left #svg
15:25:27 <FelipeSanches> FelipeSanches has left #svg
15:53:33 <shepazu> Rue du Parnasse 19, 1050 Ixelles
15:53:55 <shepazu> Renaissance Brussels Hotel
16:06:40 <Zakim> ed, you asked to be reminded at this time about whatever
16:23:30 <nomis> nomis has joined #svg
21:41:18 <karl> karl has joined #svg
23:52:00 <FelipeSanches> FelipeSanches has joined #svg
23:52:10 <FelipeSanches> FelipeSanches has left #svg