See also: IRC log
<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
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
<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
<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"
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
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
<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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/overlapping diagram/overlapping font/ Succeeded: s/headers/headings/ Succeeded: s/headers/headings/ Succeeded: s/can be quite slow/can be quite slow, so it's not typical to render large blocks of text/ Succeeded: s/photolab/photofont.com/ Succeeded: s/which one would you throw away?/you are saying that one of them is thrown away during parsing?/ Succeeded: s/lang/lang and hreflang/ Succeeded: s/in both/in both, and thus we can't discard attributes/ Succeeded: s/ed_work: no/ed: just restating the discussion we had a bit back, not objecting/ Succeeded: s/plan/are considering/ Succeeded: s/recommentation again/recommentation process again/ Succeeded: s/MS passes 100% of svg tests they submitted/MS passes 100% of svg tests they submitted :)/ Succeeded: s/ed_work/DS/ FAILED: s/conut/count/ Found ScribeNick: pdengler Found ScribeNick: ed WARNING: No scribe lines found matching ScribeNick pattern: <ed> ... Found ScribeNick: abattis Found Scribe: Dave_Crossland Found Scribe: Dave Crossland Found ScribeNick: pdengler Scribes: Dave_Crossland, Dave Crossland ScribeNicks: pdengler, ed, abattis Present: Alex Anthony Dave JWatt Doug Patrick Erik Chris Femke Felipe Hin-Tak Simon Found Date: 31 May 2010 Guessing minutes URL: http://www.w3.org/2010/05/31-svg-minutes.html People with action items: anthony chris chrisl pdengler[End of scribe.perl diagnostic output]