SVG Working Group Teleconference -- 26 Aug 2009

<trackbot> Date: 26 August 2009

<scribe> scribe: anthony

<scribe> chair: Cameron

<ChrisL> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0054.html

Substitute for onload event in XSLT-generated graphics [www-svg]

<ChrisL> http://www.w3.org/mid/17608.193.8.177.17.1251183912.squirrel@webmail22.mirsky.de

CM: This about events and whether it should be dispached if the document you opened is the result of an XSL transformation

CL: You don't automatically have parsing happening when XSLT is running
... it generates source?

CM: It generates the DOM
... then installs the document
... that's how I thought it work
... not sure if incremental XSLT exists

CL: Basically it's another data source
... either way it should be parsed
... and when it's finished you should get a load event

CM: I haven't checked the wording we've got
... to see if it focuses on the parsing tags

CL: I don't hear any disagreement if that should happen

CM: If you have a whole DOM in memory and you wanted to do the thing where script elements run
... as soon as you see the closing script tag

<ChrisL> http://www.w3.org/TR/2009/PER-xslt20-20090421/#result-trees

<ChrisL> The output of a transformation is a set of one or more final result trees.

<ChrisL> A final result tree can be created explicitly, by evaluating an xsl:result-document instruction. As explained in 2.4 Executing a Transformation, a final result tree is also created implicitly if no xsl:result-document instruction is evaluated, or if the result of evaluating the initial template is a non-empty sequence.

<ChrisL> The way in which a final result tree is delivered to an application is implementation-defined.

CL: [reads out above text]
... so XSL itself says nothing
... about how it gets load etc
... talks in terms about what the grammar is and what the out put is

CM: I wonder if the HTML5 spec says anything XML style sheet processing instructions
... maybe they've already covered that
... about script elements and when they get run

<shepazu> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-xhtml-syntax

<shepazu> "Certain algorithms in this specification spoon-feed the parser characters one string at a time. In such cases, the XML parser must act as it would have if faced with a single string consisting of the concatenation of all those characters."

DS: specifically the section 10.4

<shepazu> 10.4 Parsing XHTML fragments

DS: I'm not sure if it's at the same level that you guys were talking

CM: Maybe the stuff in 10.2, 5th paragraph is talking about
... the script element
... and what you do with it
... It seems to me that SVGLoad gets dispatched to the root

CL: One thing about the original message is it about the spec or an unnamed implementation being used?

CM: Think it being used in FireFox

CL: We seem to agree that SVGLoad event should be fired
... and there is nothing in HTML5 that is very definitive

CM: I think the trick is whether you have half a document in memory (in the DOM) when you encounter a script element
... if the output of your XSLT is the whole DOM or whether you need to reconstruct everything

<scribe> ACTION: Cameron to Look more into the HTML 5 specification to see if there is wording about how the result of XSLT are parsed when script element is encountered [recorded in http://www.w3.org/2009/08/26-svg-minutes.html#action01]

<trackbot> Created ACTION-2661 - Look more into the HTML 5 specification to see if there is wording about how the result of XSLT are parsed when script element is encountered [on Cameron McCormack - due 2009-09-02].

filterRes Issue

http://lists.w3.org/Archives/Public/www-svg/2009Jul/0014.html

AG: As far as I can tell the filterRes is used to calculate a scaling factor for the filter primitive
... you divide the filterRes by the bounds in device space
... to get the scaling factor
... I'm pretty sure it's a DPI measurement

<ChrisL> (by the way, on previous topic, http://www.astrotexte.ch/sources/svgonload.html fails to fire load in Firefox 3.6a1 but does throw in Opera 10 b2)

CM: It should be it's used to determine intermediate width and height of the primitive
... the current wording makes it sound like they are the actual width and height

AG: I think the current wording is wrong
... I'd like to hear what Eric thinks about this issue as well

Substitute for onload event in XSLT-generated graphics [www-svg] again

CL: I tried the example
... in Firefox it's not thrown
... in Opera it is
... couldn't test Safari can't get it working on my PC atm
... What we need is a test which uses XSLT to generate HTML with a script that fires onload
... to see what they do with that

<ChrisL> http://www.astrotexte.ch/sources/svgonload.html

CL: I suspect all the browsers will throw a load event

AG: Do you think it's worth making this a test case?

CL: Would be an interesting test

CM: Do we require XSL instructions to be processed in SVG?

CL: Optional addition

<ChrisL> safari on windows seems to crash on any svg file. odd

CL: sort of like inline TIFF, you can display it
... but don't have to
... In fire fox in the top case all you see is a blue circles

DS: When I load it in Safari it produces astrological symbols
... top and bottom

CM: So Safari does dispatch the event then
... next interesting test
... will be a document with a script halfway through it

CL: If you look on the bugzilla, the same comment is made there as was made to us
... I think it would be useful to find out what HTML does in practice
... I'd rather have the same load event dispatched

CM: Even if you don't go the root of reconstructing the DOM in the right order we can say
... dispatch the event to the root element

<scribe> ACTION: Cameron to Test XSLT generating HTML with a script that fires an onload event [recorded in http://www.w3.org/2009/08/26-svg-minutes.html#action02]

<trackbot> Created ACTION-2662 - Test XSLT generating HTML with a script that fires an onload event [on Cameron McCormack - due 2009-09-02].

painting-render-02-b.svg review

CL: Currently writing a program to test the different versions of sRGB
... there's the original version invented by MS and HP
... then there's another version presented to the W3C that rounds off
... the constants
... produced a discontinuity
... then there's another version that got standardised in IEC
... how did you derive your value?

AG: I used the W3C sRGB to calculate it

CM: Which is the correct one?

CL: The IEC sRGB

<ChrisL> http://en.wikipedia.org/wiki/SRGB#Theory_of_the_transformation

CM: Does that mean the W3C one should be updated to match?

CL: It should, I had considered submitting something about this

<ChrisL> w3c has K0 = 0.03928

<ChrisL> iec has K0 = 0.04045

CM: Is this in a spec or is this a note?
... Is this something worth pointing out in the W3C spec?

CL: Yes, this may contribute to some of the variations between results

<scribe> ACTION: Chris to Investigate the discontinuities in the sRGB gamut and correct any notes on the W3C website and any colour tests that are incorrect [recorded in http://www.w3.org/2009/08/26-svg-minutes.html#action03]

<trackbot> Created ACTION-2663 - Investigate the discontinuities in the sRGB gamut and correct any notes on the W3C website and any colour tests that are incorrect [on Chris Lilley - due 2009-09-02].

<scribe> ACTION: Chris to Propose wording for the colour section in F1.1 which clarifies which sRGB colour gamut to use [recorded in http://www.w3.org/2009/08/26-svg-minutes.html#action04]

<trackbot> Created ACTION-2664 - Propose wording for the colour section in F1.1 which clarifies which sRGB colour gamut to use [on Chris Lilley - due 2009-09-02].

MIME type registration

<ChrisL> http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.html

CL: The latest version can be found in the above link
... I submitted a draft in July
... ISO still have some issues with what 5th edition spec references
... The bit about parsing the ascii characters hasn't changed in editions
... I'm going to put explicit wording which will help address this issue
... I'll probably be making a draft 0.3 that will incorporate the change
... I've also started making some tests
... my draft also deprecates text/XML and says to used application/XML

DS: What time frame are we talking about for the maturity such that it would register the SVG MIME type

CL: All you have to do is show a two week period with no outstanding comments

DS: So we could have SVG MIME type registered by SVG Open

CL: Depends on how things go

- DRAFT -

SVG Working Group Teleconference

26 Aug 2009

Attendees

Contents

Substitute for onload event in XSLT-generated graphics [www-svg]

filterRes Issue

Substitute for onload event in XSLT-generated graphics [www-svg] again

painting-render-02-b.svg review

MIME type registration

Summary of Action Items

Scribe.perl diagnostic output