-
Notifications
You must be signed in to change notification settings - Fork 177
Align API with SVG where possible #78
Comments
It is interesting because several people have actually asked that we unify more with the CSS model (e.g. IMO, SVG made a few mistakes due to the DOM centric API. The string based data model won even though the DOM properties are rich data structures. The rich data structures are, however, very verbose and difficult to work with - and nobody really knows how to use them. That's why I designed transforms, paths and gradients as rich objects but with a convenient API instead of strings and ids. The ART React at some point chose the camel-case PROPERTY names ( The However, another consideration is that since the main target is Canvas and the Canvas API is seeing nicer API development and unification with newer SVG APIs maybe we should be trying to unify with the Canvas API rather than SVG. In that case, maybe Similarly Canvas calls it I suppose it is difficult to strike a fine balance between consistency amongst several competing standards, what people are most familiar with and what would be a nicer API if you had a chance to rethink assumptions. I think the end goal is to create a nice ideal API to code dynamic content. It is not a primary goal to be a target for copy/pasting existing static SVG content. There is an automated SVG -> ART converter although sadly there is no React ART version. I'd love for someone to update it to support React ART output though. Even though the JSX may make it seem strange, I think I'd rather error on the side of Canvas/CSS than SVG for consistency. Given this context, what do you think? What changes would you suggest? |
Can you point me to that? In principle it's the same to me whether the API aligns closer to SVG or Canvas. Whatever provides the cleanest declarative API should be appropriate. SVG seemed to me the more logical, since it's already a declarative drawing API much like I do think there is a strong argument to be made for an easy transition from SVG. Being able to export a design to SVG and, with minimal changes, have the option to render via Canvas is a big deal. This use case could be covered by a SVG > ReactART convertor, of course. Another big deal, now that SVG has wide browser support, would be to not need an SVG renderer since the source would be a subset of SVG to begin with. Regarding On the same note, the API could allow transformations to be set with a string or a Transform instance, providing consistency with the SVG API while also enriching it. By using a subset of SVG as the source, a fallback also comes for free. Accessibility becomes a solved problem too; a fallback to the original SVG for screen readers could be implemented easily. I'm not sure on the numbers of people familiar with SVG so I'll defer to your experience, but I do think SVG represents a well established standard for declarative drawing, albeit with some clumsy bits. I'm curious to know how an API aligned more closely with Canvas would look. SVG and Canvas already share a path description format. Beyond that would it just be property names? Or are there some areas where you would move away from the declarative? Another question is, how is this library most used and approached? I'm coming at all this from the approach of someone working with SVG who needs to target canvas on mobile for performance. My browser compatibility targets on desktop already have great SVG support so for me SVG is the base from which I'd like to sometimes render to Canvas. It'd be great to hear your thoughts and experiences on other approaches to the library. |
svgconverter here, I think: http://sebmarkbage.github.io/art/. Though it looks broken. It's possible that it works locally and is just broken on GitHub pages right now? |
Hi,
I'm converting a somewhat complex SVG component to work with ReactART. It's a huge thrill to see it rendering to canvas without rewriting the codebase, but the experience of learning the API has been a pretty painful groking of source. That's part lack of documentation but also that the prop names are sometimes consistent with SVG and other times not.
React has, except in cases of naming confict, maintained attribute similarity with HTML with an easy-enough camelCase translation. I think it would be a good approach for ReactART too. It would reduce cognitive load for developers by using an already familiar API, and it would make code reuse from SVG to ReactART all the easier.
I recognise that it could only ever be a subset of the ginormous SVG API, but a clearly defined subset could still be a lot easier to get up to speed with. At present, the API sometimes aligns with SVG, other times not, with no clear pattern for mental translation.
Examples that spring to mind...
opacity
=opacity
(same, i.e. notblend
as in ART)stroke-dasharray
(string) =strokeDash
(array)stroke-linecap
(string) =strokeCap
(string)text-anchor
(start/middle/end) =alignment
(left/center/right)d
for path property, mimicking SVG<rect>
=<Rectangle>
What do you think?
The text was updated successfully, but these errors were encountered: