Minutes Brussels F2F Day 3 (May 26, 2010)

Logs from the third day:


   http://www.w3.org/2010/05/26-svg-irc.html


as text here:


- DRAFT -
SVG Working Group Teleconference
26 May 2010

See also: IRC log
Attendees
Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
jwatt, pdenger, pdengler
Contents
Topics
SVG 2.0
Summary of Action Items



<trackbot> Date: 26 May 2010


<leonardr>  
http://www.lyrics007.com/Berlin%20Lyrics/The%20Metro%20Lyrics.html

<leonardr> for future reference, computers need to be turned on before  
they can be used...
SVG 2.0

<jwatt> scribenick: jwatt

PD: the main use cases for SVG we came up with were scalability, high  
fidelity, printing

<AlexD> Printing - could you perhaps elaborate on use cases?

PD: a printing example: we have a CAD program that outputs SVG, and it's  
very accurate
... if for example out building layout software was able to do that, we  
could create a quick webapp to print building layouts to help with  
navigation, or office moves

DS: a CAD company I've talked to has told me they're not interested in  
SVG, partly because it gets in the way

PD: it would be good to find out why

<AlexD> Patrick - years ago I had a slide presentation comparing the  
feature sets of SVG Tiny vs. XPS. There are many parallels in the graphics  
model. How would you see XPS vs. SVG as competing/complementary, or XPS  
failed in the market so it's irrelevant and open standards provide a web  
compatible print option?

LR: these types of companies often have their own solutions that work for  
them already

ED: one thing that worries me is that very detail plans, for example,  
result in huge files
... which if you're on a phone or on a slow network is a problem

LR: memory use for large files isn't so much of an issue if you know you  
don't need a DOM

PD: our compliance department has looked into which international  
organizations require SVG support
... there are 17 at required, and dozens on the way
... from recommended to required
... AlexD: I'd never thought of them as competing, we use XPS as a print  
format

LR: yes, once everything settled, nobody wanted XPS as a document format,  
only as a principle format

PD: SVG allows tooling

<ed> ...more easily due to it being an xml format

<AlexD> So Leonard, how do you see the MARS SVG print thing fitting into  
all of this?

<AlexD> We had SVG-print going, it was stillborn then Adobe developed  
MARS, is this of use and how is it relevant to SVG on the web...

<leonardr> i'll answer that in a sec...in the midst of a separate  
discussion...

<leonardr> At this time, Adobe has no plans for Mars - we found that there  
was not enough user interest :(. However, we would be interested in  
discussions with this committee (or others) about taking it over...

(general agreement that the WG focus should be on both standalone and  
integrated SVG, rather than just standalone as it has been historically)

LR: Mars is abandoned
... we'd be happy to turn it over to anyone who wanted it

DS: it would be nice if Adobe could make that a member's submission

LR: one of the usecases we always saw and which we think is now coming  
into its own is as a graphics interchange format
... clipart is a great example

DS: scrapbooking uses crickets (a cutting printer) which use SVG as their  
format

<shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

LR: we released FXG
... which is really close to SVG
... there are two reasons we didn't use SVG
... we wanted to throw out all the stuff that's not useful for an exchange  
format: scripting, effects, etc

<AlexD> At the moment ePub is big for pagination. It's basically HTML+SVG  
and some viewers use XSL-FO to drive the pagination side of things (but  
not the FO formatting model). So it's a bit more webby - being HTML+SVG.  
This is where we're heading. Mars was a single SVG file per page, a lot  
like the SVG Print proposals where it creates final form markup - similar  
to XPS in fact. So, we need to consider the use cases already put forward  
for SVG print, the ePub ecosystem and

LR: the other reason was that we were using it for flash graphics, and it  
made implementation easier to make the object names in the XML to match  
the Flash DOM
... so rather than have a name converter, it was easier to have different  
names to SVG

<ed> AlexD: yes, we did discuss epub export here, didn't get scribed  
apparently

DS: so we've been doing work on having profiles so you can disable script,  
for example

LR: in ePub you may not want scripting, but could want declarative  
animation
... I think graphics interchange format should definitely be a goal for SVG

JW: my main use cases for getting into SVG were to provide more powerful  
educational material, and data visualisation
... for example script changing the parameters on a SMIL an engine piston  
engine diagram
... and script and animation of vector diagrams makes data visualization  
so much more powerful

<ed> ED: for me, being able to take an SVG and remix/edit the graphic is  
what the web is about, ties into the whole interchange format discussion

JW: Mozilla's focus is naturally much more on Web usecases than on data  
interchange

LR: well for things like your Air equivalent exchange becomes relevant to  
you too
... webapps too

<AlexD> With web focus/data interchange etc. One of the nice things is  
that it's XML so you can use a text editor or a graphics tool like  
Illustrator, InkScape etc. Some of them use proprietary things to mark  
layers, etc. Should we consider meta-markup to indicate structure to help  
the graphics interchange stuff perhaps?

<pdengler> We think that this is what the XML format is for. Doug notes  
tha the W3C should consider that outside the scope of SVG

PD: one of the usecases I was thinking of was as image maps

DS: I'm starting to see gradients, filter, transforms and others as more  
styling things, rather than as SVG features

<AlexD> Patrick, one thing that I'd like you to consider. I've done a lot  
of work on IE unrelated to our plugin in the general area of printing. One  
thing that is glaringly missing when printing to XPS is a connection  
between semantic content such as hyperlinks and what gets emitted to the  
print stream. XPS has the capability to represent hyperlinks in its  
format. The only thing that generates those is Word with the XPS export  
function (not the print path). So if IE9 intro

PD: I agree, although SVG introduced and showed leadership with these  
types of features, I think we need to have a move to develop them more  
holistically across other formats

<pdengler> Yes, and as Doug stated we want to think about gradients,  
filters, transforms and anything that is a 'paint server' as styling, i.e.  
not a core deliverable of SVG

ED: as I see it, yes, these belong in the CSS group to some extent, but  
I'm not sure that that group is interested in defining arbitrary filter  
chains
... I think that belongs in our group

PD: yes, what we have is a lot more powerful than what CSS is looking at
... Doug's SVG Wow demo was amazing
... but could those 17 chained filters be written with a tool

ED: yes

DS: yes
... canned filters should definitely be defined is CSS though
... Firefox lets you reference filter chains defined in SVG using CSS to  
apply to any content

PD: so CSS lets you reference SVG filters

LR: but tools take care of complexity

PD: the vast majority of Web developers are what we call "notepad  
developers"
... we've been waiting for them to switch to more powerful tooling, but  
it's just not going to happen

DS: yes, tools won't really save us

LR: I just don't want us to go completely down the road of view-source'ing
... if the goal is to better integrate SVG with these other standards (and  
I think that's a good goal), do we have the latitude to throw out stuff?
... I'm talking high level
... if it were me, I would throw out all the stuff we don't need any more
... anything that can go into a more general standard
... backwards compatibility would not be a priority
... or rather, a 2.0 consumer would not have to be able to consume 1.x

PD: there are big features I'd deprecate moving forward
... SVG fonts for example
... we didn't implement them simply because there are better alternatives  
now
... the story around CSS transitions, animations, scripting and SMIL needs  
to be sorted out
... I want one method to do animations
... I want queue's and transitions
... the transitions is a better spec, but the css animations not so clear
... we didn't implement filters yet, because of the compeating
... the SVG filters are powerful, but the web developer is not going to  
know how to do all the chaining

ED: you can do what SVG filters can do with canvas and pixel ops, but the  
performance will be terrible

<leonardr> what you really want is something akin to Adobe's PixelBender -  
http://www.adobe.com/devnet/pixelbender/

ED: for WebGL you can do shaders
... which is more or less filters, if a different way of specing it

PD: the JS case, is it for wow affects, or putting a simple blur
... the XML namespacing needs to go away

<AlexD> Don't forget the compositing spec. Those operators map directly to  
the PDF imaging model as well as Apple's Quartz and play nicer than  
filters for blending. The filter model is a bit clumsy in hindsight.

PD: there are benefits and cons
... there's the user complexity
... but then there's the benefits of being able to bring in other things
... such as metadata
... XLink should definitely go away

AG: I think we should deprecate some things, and agree that things should  
move into CSS or FX now
... we should consider making it more clear how the spec is architected
... the way things happen and their timing

PD: organisation of the spec

DS: I think we need to think about SVG in three different ways
... things that are applicable to the web platform as a whole
... platform features, where SVG is just part of the platform
... in fact it doesn't need to even just be the Web platform
... it could be any platform
... so things like compositing, gradients, filters, styling, transforms -  
things that affect the way things look and are presented
... another platform feature is animation
... things that are moderately complex to implement, but applicable across  
multiple technologies
... we should have one model
... but there's potentially room for more than one syntax
... and we can extend in SVG where things make sense in SVG when they  
don't make sense in the platform
... that's the first part
... the second is architectural features
... nesting structure
... use
... groups
... <title>
... things where their context of their parent mater
... these things which are specific to SVG

PD: you don't think HTML would benefit from <use>?

<AlexD> Also need to consider the dominant architectures for graphics  
today. IE9 uses H/W acceleration, i.e. GPU. I did have that debate with  
Jon about filters at the implementers panel. Some H/W acceleration  
architectures can't get pixels back efficiently. So this also needs  
consideration. Pixels and pixel manipulation are bad in a vector format  
IMHO. So what can we leverage from existing GPU capability that will  
enhance SVG...

DS: I think that won't happen
... we have styling attributes in general, as opposed to HTML which  
doesn't have that so much
... the third category of SVG is the features of SVG
... we need to start thinking more about things that SVG should be good at
... connectors, for example
... HTML shouldn't have connectors, but SVG should

LR: WebCGM
... SVG doesn't have that many of this third category
... but these things make it so much easier for authors
... charts may be one of these features, although that may be going too  
deep to make primitives for that
... although the aria guys may disagree, since they really want the  
semantics
... anyway, we can look at what is specifically graphical/SVG

PD: are you including raster and video in "graphical"
... I don't think you are
... maybe just "vector" graphical

LR: I'd hate to see us adding graphing primitives to SVG
... we should definitely have primitives to enable that to be implemented  
in SVG

<shepazu> http://www.w3.org/TR/WD-wwwicn.html

LR: but let's keep SVG focused on "vector graphic primitives for the web"

<AlexD> +1 for Leonard's position

JW: I'm all for keeping the focus on general purpose primitives that meet  
a wide range of usecases too

ED: in SVG 2 I'd like to see us clean up the DOM
... clean up some of the primitives
... drop things that are not implemented at all
... see a focus on maintaining backwards compatibility
... as long as the content that's out there continues to work
... SVG fonts, some parts are not implemented, we can probably drop some  
things there
... vertical text doesn't work
... animation I think we should revisit
... thinking about the different solutions for animation
... thinking about how SMIL interacts with scripting
... inserting SMIL elements that have been created using script
... I think we can extend parts of SVG, like with vector affects
... shape path, like textPath, but for laying out objects
... layout

<AlexD> We're seeing strong demand for vertical text from Japan - so  
"vertical text doesn't work" isn't a good comment. We should fix it or  
provide via HTML/CSS that capability. The world isn't full of westerners  
you know! You guys trying to kill my SVG video fonts? Hmmph:-) We had  
graphical object flow in the 1.2 Full work which seems to have all gone  
into hiatus. Layout is contentious and IMO bad for SVG.

LR: doesn't layout tread somewhere between XSL-FO and CSS?

DS: FO is not a Web format
... and I don't think CSS is interested in constraints based layout

<AlexD> FO is a W3C spec, so if it's not web, then what's W3C doing  
defining it...?

<ed> AlexD: I think we need to rethink vertical text in svg, at least make  
sure it gets implemented interoperably and that it meets requirements of  
people asking for it

DS: W3C 5-10 years ago, we were siloed into this is HTML and XML
... we tried to break that down, but browser vendors weren't on board
... now we're seriously taking a look at all the gaps that have been left  
by doing things in separate silos
... but now we are doing a much better job of coordinating between groups

<AlexD> Interoperability is key, I agree. That's where layout brings you  
into interoperability hell... Perhaps a sensible way forward is to  
leverage the HTML5 spec. Subset SVG as the 'efficient SVG' for HTML5 spec  
and throw out all the things we don't need for stand-alone SVG. Just a  
thought.

ED: better integration with HTML and CSS is certainly something we should  
have as a focus for SVG 2

<ed> ...this includes rethinking foreignObject, and mixing markup

<pdengler> scribenick : pdenger

<pdengler> jwatt: Better focus on interoperability between implementations  
by having a push on shared automated test suites

<ed> scribenick: pdengler

ed: I second the automation part

pdengler: I agree that interop is absolutely key for SVG being a practial,  
useful solution

shepazu: W3C needs to be pushing the automation test suites, and the SVG  
WG should work closely along with them

jwatt: The automated testing is harder than it looks, especially when it  
comes to collaborating
... but it is worth it for the sake of content authors having to avoid the  
headaches

shepazu: We spent 2 years doing the Tiny 1.2 test suites

pdengler: Why?

shepazu: SVG Tiny 1.2 was not written to easily extract testable  
assertions; other groups have looked more closey from this perspective
... SVG WG in large part created the tests which is highly involved.

<AlexD> More to the point - Tiny 1.2 was run in parallel to the full work  
and Tiny is shipped in over 700 million phones so it has more traction  
than desktop SVG has had so far.

<AlexD> Test review by the WG is incredibly time consuming and not a great  
use of WG time.

pdengler: Have we considered test driven development of a spec?

(all) Yes. We think this will add a lot of value. No new features without  
sufficient tests

shepazu: Would love to see Opera, Firefox, IE coming to us with prototypes  
of features that are not spec'd yet.

jwatt: It's incredibily valuable to hve that; test should be written as a  
feature that we trying to spec, whether or not it is independent of the  
actual engineering

<ed> (DS elaborates on svg testfest history)

pdengler: Should the goal be that all UA's pass 100% SVG conformance tests

<AlexD> Yes.

<AlexD> e.g. in the printer industry companies like Quality Logic create  
test suites. There are a number of different levels of test suite. You can  
ask for certification and that means passing the test suite 100%. We  
should have a baseline test set that can be endorsed as an interoperable  
UA. Not as simple as ACID which is obfuscated features, but a general  
across the board set of features that will give good graphical fidelity  
for the most common use cases (like graphics

jwatt: What does the goal mean in practice

shepazu: W3C as a standards body does not make conformance tests, we make  
implementability tests (testing the spec)
... The intention is that spec itself can be implemented interoperabiity

leonardr: How far does that go? Does tha mean that vendor a and vendor b  
are interoperable for every test?

shepazu: No; for every given feature we have a test; and as long as two  
vendors pass any of these specs, it can be considered interoperable and  
shippable

jwatt: we started with finit tests; but unfortunately, that level of  
granularity led to bugs when thinking in the real world composite tests;  
let's not forget those

shepazu: This is why I proposed the tiered test that says "this test  
required feature foo to use"; this would allow for a no-op instead of a  
fail category

SVG 2.0 scenarios

shepazu: dynamically scalable images, including a static graphic, or  
something interactive like an image map
... technical drawings, engineering diagrams, floorplans, etc
... animated or interactive illstrations (such as mouse over) or the  
example piston engine
... scriptable webapps, whether integrated with HTML or standalone

<ed> wrt to the discussion on svg fonts, some examples/use-cases here:  
http://dev.opera.com/articles/view/seven-web-fonts-showcases

shepazu: re-usable component graphics
... games
... things we should look at as features : connectors, parameters and  
improve the DOM, and more specifially a shared API with <canvas>
... and seriously consider a math engine and/or physics engine

anthony: the ability to author UI's for standalone apps and to control  
audio/video etc
... star wars credit text effect
... psuedo 3d (2.5D)
... basic animation on text and glyphs (like the a glyph on fire)

pdengler: A developer wishes to use SVG as an image interleaved thorughout  
web pages where scalability or image size (where possible) can improve
... A Developer wishes to create a richer, more graphic intensive webapps  
where HTML does not suite the needs well to creating the graphic  
experience, using a comomn programming model or framework which increases  
the productivity of the developer, user experience and satisfcation  
improve, and is interoperable
... A web site hosts interactive vector graphic diagrams mixed with HTML  
such as org charts, calendars, graphs and maps
... games like on OneMoreLevel

jwatt: Dynamic and interactive display of information :educational  
material, data visualization (graphing, orgcharts), documentation

ed: User interfaces
... audio/video : educational material, tv station
... progressive rendering and streaming : for a long running animation,  
and discard portions as they are utilized
... advanced text effects (change fonts dynamically)

<shepazu> http://www.fiestagrill.us/FGname.jpg

http://ie.microsoft.com/testdrive/Performance/12ScrollingText/Default.xhtml

<ed> trackbot, end telcon
Summary of Action Items
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/01/18 18:48:51 $
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_HTML_Format (score 1.00)

Succeeded: s/the Adobe/then Adobe/
Succeeded: s/glarngly/glaringly/
Succeeded: s/filter changes/arbitrary filter chains/
Succeeded: s/of them/of this third category/
Succeeded: s/SVG fonts don't work/SVG fonts, some parts are not  
implemented, we can probably drop some things there/
Succeeded: s/implementations Tests, Suites, Automation/implementations by  
having a push on shared automated test suites/
Succeeded: s/W3C needs to be pushing the automation test suites, and the  
SVG WG should not have to worry about this/W3C needs to be pushing the  
automation test suites, and the SVG WG should work closely along with them/
Succeeded: s/UI/UA/
Found ScribeNick: jwatt
Found ScribeNick: pdenger
WARNING: No scribe lines found matching ScribeNick pattern: <pdenger> ...
Found ScribeNick: pdengler
Inferring Scribes: jwatt, pdenger, pdengler
Scribes: jwatt, pdenger, pdengler
ScribeNicks: jwatt, pdenger, pdengler

WARNING: No "Present: ... " found!
Possibly Present: AG AlexD DS JW LR PD anthony ed f1lt3r fat_tony jwatt  
leonardr pdengler scribenick shepazu trackbot
You can indicate people for the Present list like this:
	<dbooth> Present: dbooth jonathan mary
	<dbooth> Present+ amy


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

Found Date: 26 May 2010
Guessing minutes URL: http://www.w3.org/2010/05/26-svg-minutes.html
People with action items:

[End of scribe.perl diagnostic output]

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 27 May 2010 08:19:45 UTC