With SVG being integrated more and more into HTML5, both included via <object> and <img> elements, and inline in the same document, some natural questions about SVG and CSS are receiving more focus. This includes box model questions like background and border, and pointer events.
I’m interested in comments from the community on what direction SVG should take.
Continue reading “Pointers on Background of SVG Borders on Mutiny”
I’m really excited about W3C’s new public Audio Incubator Group, just launched today, and open for collaborators, innovators, and instigators. Go take a look for yourself, and see if you can contribute.
To celebrate the occasion, here’s a simple example of an experimental audio inteface, in the world’s first (and worst) audio synthesizer in SVG (you’ll need a special Minefield build to use it). Just click on the keyboard… it’s pretty rough still, but it shows some of the potential:
For some background, read on after this break…
Continue reading “Web Audio Goes to Eleven”
I attended Google I/O a couple weeks ago, and had a great time. They really put the “hype” in HyperText Markup Language 5, identifying things like the Geolocation API and some of the WebApps Working Group deliverables as part of “HTML5”. Not quite accurate, but it was a branding exercise, not a technical one. Notably absent from the things they rolled into HTML5 during the keynote, though, was SVG… in fact, they seemed to go out of their way to avoid it.
But it’s in there. Continue reading “Platform Games”
While answering a question about styling SVG with CSS in the Freenode #svg IRC channel (yes, people still use IRC), I threw together a simple example to illustrate. I like to do this, since in keeps me in practice, and gives me a chance to check the state of current implementations in the fast-changing world of SVG browser support.
The question was how to use CSS stylesheets, both internal and external, with SVG in Inkscape. While I know that Inkscape makes heavy use of CSS inline style declarations on elements (more than is to my personal taste, to be honest), I didn’t (and don’t) know if it has any UI features for adding internal stylesheet blocks, or links to external stylesheets. So I made a little test…
<?xml-stylesheet type="text/css" href="svgstyle.css" ?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%" height="100%" viewBox="40 0 145 70">
<style type="text/css"><![CDATA[
ellipse
{
fill: lime;
stroke: green;
stroke-width: 10px;
}
]]></style>
<rect id="inline" x="50" y="10" width="30" height="50"
rx="5" ry="5"
style="fill:lime; stroke:green; stroke-width:3px;"/>
<ellipse id="internal" cx="103" cy="35" rx="15" ry="25"
style="stroke-width:3px;"/>
<circle id="external" cx="150" cy="35" r="25"
style="stroke-width:3px;"/>
</svg>
circle
{
fill: lime;
stroke: green;
stroke-width: 10px;
}
Which looks like this (at least, in Firefox, Opera, Safari, and presumably Chrome):
Both internal styles worked fine in Inkscape, but the external reference did not, showing just a black circle. I’m not really surprised. Note the clunky way that you have to link to external stylesheets in SVG:
<?xml-stylesheet type="text/css" href="svgstyle.css" ?>
That’s really XSLT-licious. I have to confess, I don’t really care for PIs (insert dated Magnum PI joke here), or XML prologs in general… they seem somehow clumsy and un-XMLy, like a throwback to SGML. And as far as I know, they can’t be created or changed dynamically via clientside script. Compare that to the relatively easy and straightforward X/HTML way of linking to external stylesheets:
<link href="svgstyle.css" rel="stylesheet" type="text/css"/>
In the SVG WG, we intend to allow authors to reference external stylesheets in a manner a little more modern and consistent with what authors are already used to using, in some upcoming spec. We could do that a couple of different ways. We could allow them to use an xlink:href attribute on the <style> element, in the same way we currently treat the <script> element (that is, if there’s a resolvable external link, we use that, otherwise we use the child content of the element), or we could add a <link> element like X/HTML, or both. I kinda like the idea of allowing either.
To that end, I made a couple of tests, just playing around, to see if any browsers accidentally supported either of those options, by merit of having some shared codebase with X/HTML in their implementations. Unsurprisingly, neither worked.
But then I had another idea… use the an <xhtml:link> element in the XHTML namespace…
<xhtml:link href="svgstyle.css" rel="stylesheet" type="text/css"/>
With this rather happy result, which works in at least Firefox, Opera, and Safari.
external-link-xhtml.svg:
I don’t know if this is by design, or if it just fell out of the model, but I have to say I’m pleased as punch that it works. If nothing else, it’s a great proof of concept for adding more ways of linking to CSS in the SVG spec. This one goes in my toolkit, and I’m going to try to ensure that it gets standardized, if it’s not already there in some corner of some other spec. Probably somebody already knows about this (hell, probably everybody does, and I’m late to the party), but for me it was a w00ty discovery.
Update: heycam speculated that you might also be able to use @import rules, and indeed you can:
<style type="text/css">@import url(svgstyle.css);</style>
Okay, first a disclaimer: none of this speculation comes from “insider information” I’ve gotten as an employee of W3C; but being surrounded by the swirl of standards, I suspect I may have picked up on a zeitgeist. I’m interested in seeing how well my predictions play out.
Prediction 1: Microsoft will merge its browser and office platforms
That’s what I would do if I were them. Right now they are in a bit of mindshare competition with online apps, like Google Docs; as Web apps transition to the desktop (like, the downloadable desktop GMail client), Microsoft will take their core competencies (the desktop Office suite) and make it more Web-friendly. They’ll take advantage of the fact that desktop apps are often more robust and speedier, and tie in the chief benefits of Web apps: distributed authoring, ease of deployment, and ubiquitous availability. To enable the latter, they also make a Office-lite Web app, sold as “software as a service”, for those who’ve bought the real product (though of course it won’t be as good as their desktop version); they might open this up in the razor-and-blade sales model.
They will merge two of their products, SharePoint Server and Exchange Server, into a sort of portal/wiki thing that ties into their new Office Browser. They will probably integrate chat (MSN, or whatever) into the whole thing, so you have some uber-communications suite: email, chat, collaborative distributed document creation, and all that enthralling office goodness.
This could be IE8 (or IE9), or a totally new product, but it will probably be a new version of MS Office. It will be their typical monolithic entry into the agile Web space. And of course, it will use OOXML as a native format.
Why I’m wrong: I think this would be smart, but the different divisions of Microsoft actually compete for resources. I wonder if they could play nicely together for long enough.
Update (25-01-2008): I’m actually going to Microsoft next week to talk about standards stuff. Maybe I will get an inside scoop.
Prediction 2: A cross-platform browser based on WebKit (but not Safari) will supplant Firefox
WebKit has a cleaner, faster (if less complete) engine than Mozilla, and it’s already been reused by Apple for Safari, Nokia for their mobiles, Adobe for Apollo (I think), and by Google for Android. But all those are controlled, as far as I can tell, by their name-brand deployers.
I think a new, more open repackaging will happen. It will be standards-based, and truly open-source, from the engine on up to the executable. It will implement Widgets (as being specified at W3C), so that people can make simple desktop applications based on common Web technologies. But the key enhancement will be a new, cleaner, lessons-learned, easier-to-author Extensions platform. Extensions, in my mind, are the most brilliant thing about Firefox, allowing slightly-above-average users to create new features for the browser, or to use features added by others; this gives great community buy-in. But it will be even easier to do in this new browser; this will probably necessitate a new XUL-like language, too, so people can add chrome, or it might just be in the form of script APIs. But what would be even smarter is to have the Extension editor, and Widget editor, built right into the browser, so making a new theme or feature or widget is as point-and-click as possible, with common tasks encapsulated (though for advanced enhancements, some scripting will be needed, in a smart editor with code completion).
Oh, and it will have SVG support.
Naturally.
Why I’m wrong: This is just my dream browser. Browsers are a hard market to break into, because there’s established competition, and you’re not making a product you can sell… you have to give it away. There’s already a lot of momentum around other efforts. But this is the browser I want. Too bad I’m so lazy.
Over the past few weeks, there has been a long, drawn-out discussion about how to integrate ARIA (an accessibility specification) into both SVG and HTML in a uniform way. There have been two main camps, as there usually are in these matters: the XML advocates, and the HTML5 (WHATWG) advocates. Both sides want to make sure that all content works the same across all browsers, authoring tools, etc. (collectively called User Agents), but they differed in how they thought it should be done.
The XML True Believers have held that the way forward for the Web is to enforce a strict, well-defined syntax for Web languages, and that to extend or combine languages, a differentiating mechanism called “namespaces” would be used. Namespaces in XML are specified to take the form “schepers:doug”. They declared a do-over on HTML, recasting it in the new XML mold (XHTML), and planned for browsers to be stricter on new content, and for authors to have learned their lessons.
The HTML Young Turks came forward with the observation that no matter how well you define a syntax, people will make mistakes (or not know the right way to do things), and that the way to recover from those mistakes is to define error-handling behavior for each kind of mistake; they also believed that since they could now reconcile older “broken” content with new browser behavior, that they were constrained to define behavior that would work in all past browsers, as much as possible, and to degrade gracefully in those that didn’t. But this required a more rigid parsing mechanism that doesn’t work well with extensibility, a problem exacerbated by Internet Explorer’s idiosyncratic and variable (one might even say spasmotic) behavior regarding the colon (“:”), meaning XML Namespaces didn’t work right. Also, the colon has a special meaning in CSS, yet another wrinkle.
So, XHTML and SVG are based on the XML model, and the new HTML5 is based on the new-old model. This difference wasn’t really much of a problem for SVG, though, because SVG and HTML are two different languages…
But of course people want to use them together. (More on that in some other post.)
The obvious way around that is to have two different parsers (a parser is a program that reads a formal syntax and makes a model of it for the browser to act on), and when you encountered SVG inside HTML, you would switch to the stricter parser. HTML would have its model for naming attributes (with no colon), and SVG would have its attributes (with a colon).
But there’s a hitch. ARIA is an accessibility technology meant to work in HTML and XHTML and SVG (and other presentation languages). The functionality for ARIA is defined in its own specification, but it’s not intended to be used on its own… it has to be integrated into a host language. It would be confusing for authors to have to use two different syntaces for the same functionality in different languages.
For example, in SVG you might have:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:aaa="http://www.w3.org/2005/07/aaa"> <g xhtml:role="checkbox" aaa:checked="true"> <rect x="5" y="5" width="20" height="20" rx="5" ry="5" fill="none" stroke="crimson" stroke-width="2"/> <text x="30" y="22" font-size="18" fill="crimson"> Enable Accessibility</text> </g> </svg>
While in HTML, you would have something like:
<html> <ul role="checkbox" aria-checked="true"> <li>Enable Accessibility </ul> </html>
Let the drama unfold…