Using the HTML5 Pack you can do the following:
- Parameterized SVG
- Multi-screen SVG
- Mark object as canvas in SVG
- Export named character styles as CSS
- Export artwork appearances as CSS
- Include Selected Graphic Style as CSS in SVG
Parametrized SVG allows a designer to create objects with variable attributes. These might include fill and stroke color, opacity, and a few others. As variables, the developer can then address these programmatically after the designer hands over the artwork.
Multi-screen SVG allows a designer to create different versions of their design that will then display on the appropriate screen. For instance, we are all familiar with iPhone apps that switch from Portrait to Landscape mode. Multi-screen SVG enables a designer to design for those orientations and also for specific screen sizes. This will help designers create more consistent designs across multiple mobile devices.
Marking an object as a canvas in SVG allows the designer to designate an object as a canvas. This will rasterize the content within the canvas and make it available for the developer in javascript or other scripting languages.
Exporting character styles and artwork appearances to CSS does just that. Character Styles become CSS that the developer can use to maintain consistency when they are creating new elements in the application. An object's Fill, Stroke, Opacity, Gradient and also the absolute position and dimensions are also exportable as CSS.
You can also Include a Graphic Style as CSS in your SVG. Using this option, the designer can send graphic styles that aren't currently used in the artwork, with the expectation that the developer will enable and disable these styles programmatically. Using this option, the designer can designate exactly how objects should appear under specific conditions, and then the developer can enable that behavior.
Why is all this important? One of the most challenging parts of developing content for the Web and Mobile devices is that the designers and developers speak different languages. This language barrier is very real; developers sneer at designers who don't know how to code, and designers can't understand the ham-handed way that developers carve up their work to turn it into functional code. Any tool that helps designers better inform developers of their desires, and also enables developers to use the content that developers provide without having to carve it up will empower both sides to work more productively and harmoniously.
Over at Forrst, I asked who is likely to use this new feature. While I haven't gotten feedback yet (it's only been a few minutes!) I anticipate that there will be a lot of interest. Whether there is widespread adoption depends on how well the plug-in works in real-world situations. I look forward to the results of the survey.
Leave a comment