I think dev-centric vector tools present a really good opportunity to improve the workflow between devs and designers and change the way many of us design web UI/animations. My main goals and interests:
- modular tools that are not encased within a monolithic editor
- animation/key frames
- renderer agnostic (for use with canvas/WebGL/CSS/etc)
- publishing path/animation state as a npm module, so that others could just "npm install spinny-preloader"
- ultimately building a suite of tools for more fluid motion graphics that render in real-time in the browser, but look just as good as something from After Effects
I wonder if some aspects of your tool could be reused for some of these goals.
Your tool is nice. The idea of doing vector graphics like this in the browser is very alluring. I worked on something similar for a long time, maybe you would find it useful:
The original idea was also to create an animation tool which could export to canvas code and/or SVG files with embedded JS. Ended up just being a generic SVG editor.
I eventually couldn't keep committing the time to develop it, but it was a fun project for a long while. Really got interesting when I started thinking about algorithms for something like Pathfinder (unfinished work: http://artur.co/pathfinder.html) and a freehand drawing tool which outputs cubic beziers (the crayon tool in my example). Also fun was coming up with data structures for undo/redo (mine still kind of suck).
Wow, looks great. I had a strong feeling that even a "really simple SVG editor" is an incredibly huge task for a single developer. Your app helps put things in perspective. :)
I always find "monolithic remakes" to be doomed from the start. So my current goal isn't to create the full app, but focus on it's different parts. Eg. the path-illustrator should be modular and standalone, and easily integrated into larger tools with perhaps different agendas. Same with timelines, SVG import/export, etc.
You should really see what the devtools team at Mozilla is working on. I think they already have many of those things either implemented or in progress.
CSS Shapes are still on the horizon, but not far off. Blink added the intent to ship them in May [0], and Apple called them out as one of the new web standards that will be in Safari 8 [1].
This looks awesome! Not really usable yet due to the lack of browser support[0] (Chrome 37+ and Safari 8 with -webkit-), but it's this kind of thing that rallies support for web standards.
Not sure why you're getting downvoted, that's probably true, sad as it is. Hopefully it won't be years, but it won't be months, either.
Even chrome and firefox, which auto-update their browsers in order to keep everyone on the latest version - which should let websites use new features earlier - seem to have around 1/4 to 1/3 of their users on old versions,
Side note: The use of the GIFs on the page really cuts to the chase and shows immediately what everything is about. I only watch explanatory videos if I'm really interested in a product, therefore appreciate this presentation.
Except for the most obvious difference between web and print, which is that you can design print layout for one particular rendering medium/resolution/size.
It's the same reason why we don't use absolute positioning in pixels to do all our CSS layout.
Custom shapes can be very finicky in when they break or don't break certain lines. Designing such a breaking-shape for a print magazine depends not only on the shape of the image, but is tweaked considerably depending on whether it breaks on a particular word on a particular line, and how this looks in the context of the page, spacing, readability, etc. Sometimes you can see this went wrong when a text has been edited without adjusting the shape. On the web with different mediums, resolutions, fonts and rendering, you can pretty much expect this to turn out wrong a significant part of the time.
Not to mention this is exactly the sort of "pixel perfect" design that we should be discouraging, not encouraging. It doesn't seem like this technique translates well to a flexible design philosophy by letting the browser choose the best way to reflow text around elements (based on the amount of available screen real estate).
I don't think that's true. Looking at the video it seems like an ideal mix of both worlds - non-standard shaped images will be floated with CSS, and text will reflow and rewrap according to available size.
But that's exactly what this is doing: defining a better bounding area for an element so that the browser can flow text around it according to the available screen real estate.
Defining the length of each line of text is a backward-facing solution and should be discouraged.
Yeah, I agree it would be annoying for long-form content (which is why magazines/newspapers never really adopted layouts like that in earnest) even if only because we've learned to read and therefore favor rectangular blocks of text.
It's still a neat effect for creating little asides, blurbs, etc. though
The only way to use SVG for this would be to include the text in the SVG. SVG's text handling is awful, and doesn't have concept of reflowing according to size, so it would ultimately be a terrible solution.
The shape is being used to style an HTML element; naturally you use CSS for that.
But if you're asking why the shape is being defined with text, inline in the CSS, that's because defining shapes with SVG was postponed to level 2 of the CSS Shapes spec.
It seems though that many (most?) use cases would be solved if image formats supported non-rectangular bounding, er, "boxes". Seems like something that could potentially be added to SVG.
I think dev-centric vector tools present a really good opportunity to improve the workflow between devs and designers and change the way many of us design web UI/animations. My main goals and interests:
- modular tools that are not encased within a monolithic editor
- animation/key frames
- renderer agnostic (for use with canvas/WebGL/CSS/etc)
- publishing path/animation state as a npm module, so that others could just "npm install spinny-preloader"
- ultimately building a suite of tools for more fluid motion graphics that render in real-time in the browser, but look just as good as something from After Effects
I wonder if some aspects of your tool could be reused for some of these goals.