See also: IRC log
<trackbot> Date: 30 November 2009
Zakim: who's here?
<scribe> scribe: Jonathan Watt
<scribe> scribenick: jwatt
<ChrisL> zaki, take up agendum 3
<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
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
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[End of scribe.perl diagnostic output]