<trackbot> Date: 30 November 2009

Zakim: who's here?

<scribe> scribe: Jonathan Watt

<scribe> scribenick: jwatt

<ChrisL> zaki, take up agendum 3

update on ACTION-2682 (svg errata implementation report)

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

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

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

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

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

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

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

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

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

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

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

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

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

<ChrisL> Firefox nightly 20090929 is elderly

<ChrisL> jwatt: firefox trunk passes i think

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

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

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

<ed> safari 4.0.3 passes first and third subtests

<ChrisL> firefox nightly passes 1 and 4

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

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

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

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

<ChrisL> fixed in tracker to be meaningful

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

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

<ChrisL> www-archive@w3.org

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

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

DS: what do you think?

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

AG: I think it's good

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

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

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

Carl proposed two different types of issue

scribe: so I separated out blocking issues

Hixie suggested a change to use XXX

Bert on the chairs list proposed changes

I incorporated those

Fantasai suggested improvements to the semantic markup

which I added

using <em> rather than <span> for example

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

but accessibility people were behind it

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

JW: that's where I was coming from

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

CL: I think that's fine

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

CVS patch comments

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

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

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

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

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

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

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

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

DS: no, but it could

[out of time]

CL: you should keep pushing on params

RSSAgent, generate minutes

thanks

trackbot: end telcon

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/someone/Gregory/
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Default Present: Shepazu, [IPcaller], ed, +33.9.52.49.aaaa, anthony, jwatt
Present: Shepazu [IPcaller] ed +33.9.52.49.aaaa anthony jwatt

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

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