W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2012

Re: SVG 2 Requirements: next phase

From: Alex Danilo <adanilo@google.com>
Date: Mon, 20 Feb 2012 15:33:23 +1100
Message-ID: <CAGdNekQd=XfJcxp2n41-utpL0VVt6bBVP4Q3T62KqgQgKTY-zQ@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Vincent Hardy <vhardy@adobe.com>, Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>, "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>
Hi Leonard,

On Mon, Feb 20, 2012 at 2:23 PM, Leonard Rosenthol <lrosenth@adobe.com>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?
>

In principle yes. But we also have an associated 'feature' which is using
it as a paint server, and that could also extend to <image> as well.

Alex

> ****
>
> ** **
>
> *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)
> *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>
> *Date: *Thu, 16 Feb 2012 20:08:24 -0800
> *To: *Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>
> *Cc: *"SVG WG (public-svg-wg@w3.org)" <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> 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]
> *Sent:* Friday, 17 February 2012 1:00 PM
> *To:* Cyril Concolato
> *Cc:* SVG WG (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> 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 04:33:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC