I had the pleasure of speaking to a really savvy crowd at Surrey University last night on "Tomorrow's web standards today". It was a fun session with lots of really good questions at the end - just the way I like it.
Below are my slides written in HTML. They're best viewed in Opera on full screen (View > Full screen) but of course work in any browser.Demos for <video>, <canvas>, SVG, web forms, widgets and media queries are all either linked from the presentation or bundled together in the download.
One thing that seems to come up from time to time when talking about SVG is the apparent lack of a mechanism to make certain size specific adjustments. Typical use case is icon design, where you want to make sure the outline of the icon you're creating is always 1px, regardless of the icon being 16, 32 or 64 pixels in size.
While at the SVG Open conference last week, I investigated how this problem could be solved, and found out that you can do this by using media queries inside the SVG file. Different widths set on the img tag pointing to the SVG file then will trigger different max-width/min-width media queries to be triggered.
I've presented my findings during the lightning talks session at SVG Open, and have turned the talk into a YouTube video, which you can watch below.
extending the language to better support Web applications, since that is one of the directions the Web is going in and is one of the areas least well served by HTML so far.
This puts HTML in direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight.
Early the next morning, I was woken by the organisers asking me to do a second talk. As I had no time to prepare, I coded an HTML5 page live. Five minutes before going on stage, my laptop died; thanks so much to the guys on the Microsoft stand who lent me a replacement Windows machine, installed the necessary software and got my lappie running again!
Finally, thanks to all those who came along and gave me great feedback. I was literally hoarse from chatting in the breaks, in the pub and everywhere else about HTML5. The biggest gripe (apart from those appalled by the fact that you can use XML syntax or not, as you wish) was the stylability of the new form elements and their error messages. I'd love to hear your feedback on this.
Today, I've made a Web Fonts+SVG image tribute to Bruce Lee - the martial artist. The SVG image is edited in Inkscape, and retouched in a text editor to add animation using SVG element such as animate and set.
The text (including the background text) are all web fonts and hence selectable.
One of the issues with SVG is that to make any complex image involving things like paths, you really need to generate the initial file using a vector graphics editor. Even with formats such as HTML, automatically generated mark-up is most often sub par compared to hand crafted mark-up. This is no different with SVG, with each editor adding its own extra attributes for meta data, or adding a lot of default values that are not needed. It is often best to strip out this extra cruft to make the mark up leaner, save file size, speed up rendering and make it easier to script and update the image. I’ve done this by hand previously, and it is a slow process. Now however their is an easier way. Jeff Schiller has produced Scour, which is an open source script to scrub automatically generated SVG files to optimise their size. It is currently in early days of development, so there are bugs, but it is already immensely useful.
As an example of its powers, I took a SVG file I recently created by talking a Inkscape generated map and hand edited, and ran it through Scour. The file went from 560126 bytes to 299969 bytes. There was some bugs along the way, which I've been speaking to Jeff about, and he has already fixed most of them and a 0.11 version will be out very soon with these fixes. He even added SVGZ support out of the box, so I was able to get the file size down to only 81919 bytes. This is huge savings from the original size. As Scour optimises path data as well as removing unneeded elements and attributes, it makes better savings than most people would be able to do by trying to optimise a generated file by hand. An example of how to use Scour via the command line, with an SVG file as input and SVGZ file as output is as follows:
python scour.py -i input.svg -o output.svgz (requires version 0.11)
I would recommend to run Scour before you do any adjustments by hand to the SVG file. For example, in the map file linked previously, I based it on a Inkscape generated map from Wikipedia, and added things like my own styling, animations and text by hand. As Scour adjusts the mark up, it may remove any semantics you have added, and has issues with CSS styles in the style element, due to not being able to parse references in the CSS. Scour removes unused mark up, so it may remove things like filters or gradients if they are only referenced in the style element or by and external style sheet, and adjusting the mark-up, such as putting anything from a style attribute into a XML attribute instead may affect the specificity, making different rules fire. As most of these issues are not a problem if the file has been untouched by hand, the best work flow is probably to Scour the file first then add extra semantics and hand tuned adjustments afterwards. Of course, if you try out Scour and find bugs, please report them. If you can reduce the file to the minimum amount of SVG to reproduce the problem, that would help a great deal.
image: screen capture of the original SVG.
WIDGETIZE
