- From: Dirk Schulze <dschulze@adobe.com>
- Date: Sun, 19 Feb 2012 19:30:31 -0800
- To: Leonard Rosenthol <lrosenth@adobe.com>
- CC: Vincent Hardy <vhardy@adobe.com>, Alex Danilo <adanilo@google.com>, Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>, "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>
- Message-ID: <DABA483E-527F-47B6-A2A1-518954C67F25@adobe.com>
Hi, On Feb 19, 2012, at 7:23 PM, Leonard Rosenthol wrote: In which case it’s basically a scriptable <image>, yes? You could use it anywhere that you could use an image (and nowhere that you could not), yes? It would be a "graphics element" like defined in SVG Intro - Definitions [1]. But do we support Canvas 2D and 3D? Even if WebGL is not a W3C standard, do we have to specify how WebGL can/should be used in an SVG document? Greetings, Dirk [1] http://www.w3.org/TR/SVG/intro.html#Definitions From: Vincent Hardy [mailto:vhardy@adobe.com] Sent: Friday, February 17, 2012 11:13 AM To: Alex Danilo; Cyril Concolato Cc: SVG WG (public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>) Subject: Re: SVG 2 Requirements: next phase Hello, I think that having <canvas> in SVG is really important because you would not want to have to wrap it in a <foreignObject>. May be this is related to our efforts to support HTML elements more easily in SVG, but I would second a request to add support <canvas> directly to our list of requirements. Cheers, Vincent From: Alex Danilo <adanilo@google.com<mailto:adanilo@google.com>> Date: Thu, 16 Feb 2012 20:08:24 -0800 To: Cyril Concolato <Cyril.Concolato@cisra.canon.com.au<mailto:Cyril.Concolato@cisra.canon.com.au>> Cc: "SVG WG (public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>)" <public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>> Subject: Re: SVG 2 Requirements: next phase Hi Cyril, I do remember us discussing it last year since I was going to implement it before the Sydney F2F but didn't get time. The idea was to have <canvas> in the SVG namespace as well as an API identical to the HTML5 one and also allow that to be used as a paint server. We also discussed buffering drawing commands so they could be replayed on resize but BorisZ rightly pointed out that wouldn't be good. I did implement using SVG <video> as a paint server and sent some examples and the viewer to Chris to show at the tech plenary meeting but I don't know if you got a chance to see it. This is all vaguely related to: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Arbitrary_fill except the canvas discussion was somewhere else on the list. I'll see if I can dig up a reference. Alex On Fri, Feb 17, 2012 at 1:41 PM, Cyril Concolato <Cyril.Concolato@cisra.canon.com.au<mailto:Cyril.Concolato@cisra.canon.com.au>> wrote: Hi Alex, I can’t find it explicitly. The requirements page indicates Canvas as part of the improvement to the path API: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_SVG_path_DOM Cyril From: Alex Danilo [mailto:adanilo@google.com<mailto:adanilo@google.com>] Sent: Friday, 17 February 2012 1:00 PM To: Cyril Concolato Cc: SVG WG (public-svg-wg@w3.org<mailto:public-svg-wg@w3.org>) Subject: Re: SVG 2 Requirements: next phase Hi Cyril, Didn't we agree to add <canvas> to SVG? I don't see it in the list. Alex On Fri, Feb 17, 2012 at 10:49 AM, Cyril Concolato <Cyril.Concolato@cisra.canon.com.au<mailto:Cyril.Concolato@cisra.canon.com.au>> wrote: Hi all, As you have seen from my previous email, we are approaching the end of phase 1 (gathering and deciding on the proposed requirements). I think we should be starting phase 2. According to our planning, we should have a list of prioritized requirements ready in March. I proposed that to make this prioritized list, we start by gathering the intentions/commitments from the members to work on the agreed requirements. Based on those commitments, it should be easy to prioritize and assign feature ownership. For that purpose, I added a ‘commitment’ line to each accepted requirement in the requirements page. The idea is that you add your name or the name of your company (preferable) in some of them. It is meant to indicate commitment to provide concrete text for the spec on that topic (and maybe later on some test cases). Ideally, everyone should commit his/her company depending on the work load. We should not commit ourselves on too many items. In order to help you decide, I’ve tried to summarize the requirements that we have accepted so far. We could also put that sorted list in a wiki page if you prefer. · SVG DOM o Expose animateMotion o Improve SVGList* o Easier read/write of attributes o Access to property values o Improve bounding box APIs · The <image> element o Viewbox o Auto-sizing · Improved switching o Add a mechanism similar to allowReorder o Improve fallback mechanism · Referencing o dropping fragments to mean referencing root element o allow clip to reference any element o add features from the <animation> element o improved text from SVG Tiny 1.2 on reference restrictions o Improved text from SVG Tiny 1.2 on processing external references o <use> clean-up · SVG Parameters · Alignment with HTML 5 o data-* attributes o global semantics attributes (microformat and microdata) o RDFa o the style element o the video element • allow video elements to have captions, tracks … o the audio element • Control audio level and playback o document wide events o drag-and-drop functionality o content editable o focusability and navigation order and API to control the focus o Support for key events from DOM Level 3 Events o Progress events o Support for mousewheel event · Alignment with CSS o z-index o Automatic text wrapping in arbitrary shapes o Use of CSS white-space o CSS Transition-like animations o CSS 3 Color syntax o CSS image-fit o Reference CSS3 Values o Promotion of some attributes to properties o Controlling focus indication o case sensitivity of presentation attributes · Colour management · New Graphics features o Level of details control o non-scaling features • stroke • objects o advanced stroking • variable stroke width • stroke position • more precise stroke dashing • more control over position of dashes o advanced paint servers • hatching • painting from arbitrary elements • add the solidColor element and its properties • advanced gradients (Coons patches) o Custom filters o advanced paths features • shared paths • skeleton paths (as a separate module) • smooth path between points (Catmull-Rom) • simpler way to make regular polygons and stars • easier arcs • element-based path syntax • Improve SVG path APIs o Improved bounding box description o Add the vector-effect property o Viewport-fill and viewport-fill-opacity o Marker clean-up · Transforms o adding ‘transform’ to <svg> o specify rotation around particular points and shapes o positioning of objects along a path o allow transforms on <tspan> o add constrained transforms (transform=”ref()”) o add the transformBehavior attribute · Text o stretch method for textpath o flip-invariant text o deprecate baseline-shift and use vertical-align o add advanced font metrics interface o add methods to convert text to path data o Improved text on characters and glyphs, text layout, selection form SVG Tiny 1.2 o Scrolling to editable text · WOFF · script o allow async/defer · animations o Add snapshotTime o animation reversing o non-negative speed on time containers o path-based animation of pair of attributes o type=’matrix’ on animateTransform o linear interpolation of properties which were previously discrete o support for animation using a transform-list o motion animation of a specified speed o get animation timeline information o simpler interpolation between paths o synchronization · Rendering algorithms o Unknown elements rendering o Define more precisely progressive rendering o buffered-rendering o Flatten to image o Seamless rendering of adjacent edges / Pixel rounding methods · Interactivity o Positioning information in mouse events o Make it easier to write zoom/pan widgets o Add the SVGRotate event o Improved text from SVG Tiny 1.2 on hit-testing and event processing · Miscellaneous o Shadow tree clean-up o foreignObject: remove requirement for @width and @height o Tooltips o Copy/Paste of SVG graphics o Clarify the use of SVGZ files o Namespace clean-up o Checking Backwards compatibility o Checking Accessibility o Defining Undefined behaviors Best regards, Cyril The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system. The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Monday, 20 February 2012 03:31:10 UTC