June 7, 2010 at 12:01About the present and future of SVG
- Transfer
Help from the translator: Doug Schepers ( W3C ) - since 2007, an active participant in the W3C in the development of SVG
In order to learn a little more about the current state of affairs with SVG implementations, I sent an open request to SVG implementers via email. For the first of a series of interviews, I contacted the newest SVG implementer, Patrick Dengler of the Internet Explorer team. He works as a senior project manager in the team responsible for implementing SVG in IE9.
We exchanged questions and answers via email, just over the week of the last meeting of the SVG working group (in W3C - approx. Primary). I asked Patrick some questions, and he asked some to me.
Doug: Microsoft recently announced that it intends to support SVG in IE9. What is the reason for this decision?
Patrick:We spent a lot of time collecting information from many different sources about current and future trends on the web. We will definitely use this information to plan each release. We determined that the next trend on the web is likely to be the area of graphics. Although we began to participate in the creation of the SVG specification, we previously supplied it to W3C and introduced VML (Vector Markup Language) into the web, but yes, this technology did not receive the attention we hoped for. Together with the desire of the development community for new and existing graphics capabilities, including the inclusion of SVG in the HTML5 specification, SVG was the right choice for us at the right time.
Patrick : You have been working on SVG for a while. What are the most important parts of your future work that you can name?
Doug: Adding new features to the SVG that meet the needs of users and developers and will make the Web a more functional and useful platform. When I previously developed many different web applications, I often had to struggle with the individual features of the SVG, HTML, CSS and DOM implementations, so I want to simplify the life of people who use these technologies to solve their tasks.
Doug: What Microsoft products can now import or export SVG?
Patrick:Support for SVG, like many other products, has been in decline over the past ten years. At the moment, Visio can export SVG and our .NET Grid Controls contain the ability to create an SVG representation at the output, although they are still in beta. In addition, Bing, like our other Microsoft Live services, as well as PowerPoint, supports SVG as a format. For some time, for compatibility, these services, like other leading sites on the network, will support VML for compatibility. I am glad that such compatibility support costs will disappear with the release of Internet Explorer 9 (specifically for this version of the browser - approx. Transl.).
Doug: How do you view SVG in terms of your organizational strategy?
Patrick:SVG is a key element for the Internet Explorer team, as well as requirements for implementing related specifications, including improvements to XHTML and DOM. In order to take user experience to the next level, I know you, Doug, have heard about this, we are making additional investments in hardware graphics acceleration and in the new compiled JavaScript engine, as well as in other performance improvements regarding SVG (and our other functions) ) in order to make SVG technology a world-class technology.
Patrick : How do you assess the impact of SVG implementation in Internet Explorer on web developers, how will this affect them?
Doug:Given the large share of Internet Explorer in the browser market, I think people who previously avoided using SVG will finally see something in this technology that they can use with the confidence that it will be widely used. When IE9 is released, current and future versions of every other major browser will support SVG and this will increase interest in SVG. We are already witnessing this, in fact, there are already many projects for converting SVG to Flash or drawing on the web with SVG. I think that the announcement regarding support in IE9 played a role in this.
Doug: What is the most interesting thing about implementing SVG in IE9? Every browser developer has something special about SVG ... what is IE9 cool about?
Patrick:Undoubtedly, this is our hardware acceleration, high-quality graphics and graphics computing. Microsoft has revolutionized the PC gaming industry with DirectX and is pleased to work with video card manufacturers to offer the best experience for developers and players. The Internet Explorer team has chosen the right solution to use this success, using Direct2D libraries for all graphical functions (which also include HTML and text). This allowed us to eliminate a large number of software graphics rendering and transfer these calculations to the GPU. This affects groups of functions such as transparency, gradients, geometry, graphics, and even high-resolution video. We are pleased to use the ten-year investment of Microsoft, developers and hardware vendors.
Doug:SVG 1.1 is a great specification. Like all other browser vendors, Microsoft divides the implementation of support into development periods and will not implement the full specification in IE9. What features do you plan to support right now and what are your plans for the future?
Patrick:We told some implementers and W3C directly about this. As you mentioned, SVG is a big specification (twice as much as HTML 4.01), which is why browser developers are introducing features gradually, from version to version. Since we want to make a powerful push for graphics on the web, we decided that we needed to implement the vast majority of the specification for portability with other browsers. In this regard, we are implementing 20 SVG modules and the existing 23. Three modules that we will not implement in IE9 are SVG Fonts, Filters and SMIL.
If you look closely at the scenarios for using SVG Fonts, then in fact there are a lot of reasons to think about fonts in SVG, since SVG is scalable graphics and this is a key script for viewing text. Let's take a look at the many ways for fonts on the web that already exist (OpenType, TrueType, ClearType, WOFF) and take into account the fact that the W3C Web Fonts working group is moving towards standardizing Web Fonts, so I don’t see the future of SVG Fonts. We think that the key feature of SVG Fonts to create great fonts for the web is that font intellectual property can be protected for both open source developers and commercial vendors so that they can offer great solutions and eliminate the need to download the font on desktop
As for Filters, this is exactly the area that we could choose in order to demonstrate our graphics capabilities and transfer intensive computing directly to the GPU. However, we have doubts for some reason. First, let's not forget that Internet Explorer was the first to support filters since version 4.0. And again, we do not observe their wide distribution. Trends are changing and our radars tell us about it. Filters are where CSS got a lot of interest. The SVG specification offers 19 different filters from Component Transfer to Convolve Matrix and Specular Lighting. All these are great filters, especially when combined with each other and they can really create interesting effects. Nevertheless, if you look at the CSS Filters specification, you can find more convenient ones. Web developer friendly filters such as casting shadows and they have already gained recognition. I think we need to put ourselves in a “wait and see” state. SVG currently depends on the CSS 2.1 specification, not CSS 3. We formed special commissions in the CSS and SVG working groups to resolve this issue, but it will take some time.
Last but not least is SMIL, declarative animation. And again, Microsoft participated in the formation of SMIL a dozen years ago. And, in collaboration with Compaq and Macromedia, it released the HTML version of SMIL (called HTML + Time) and implemented it in Internet Explorer 4. And again, we did not see the wide distribution of this functionality. To bridge the gap between the developer and the designer is always a difficult test. Some believe that declarative animation will help build such a bridge and many tool manufacturers have made such attempts, few with some success. From communicating with developers, we know that most of them create animations through code, for the web this means JavaScript. And this path is supported wholeheartedly in Internet Explorer 9, even now in Platform Preview versions. Animation is easily accessible and we offer developers a way to it for minimal resistance through code (using JavaScript - approx. Transl.). I add that CSS3 also explores animations through CSS Transitions and CSS Animations. Are you starting to see a trend in this? And again, a special commission from the SVG and CSS groups explores how the correct model is. The SMIL specifications have been around for a decade. We have supported SMIL for HTML all ten years and have observed very little use of it. We think that animations are an important part of HTML5, we know that the community has historically used code (JavaScript) and is starting to adopt a simpler-looking CSS model. Time will tell. CSS3 also explores animations through CSS Transitions and CSS Animations. Are you starting to see a trend in this? And again, a special commission from the SVG and CSS groups explores how the correct model is. The SMIL specifications have been around for a decade. We have supported SMIL for HTML all ten years and have observed very little use of it. We think that animations are an important part of HTML5, we know that the community has historically used code (JavaScript) and is starting to adopt a simpler-looking CSS model. Time will tell. CSS3 also explores animations through CSS Transitions and CSS Animations. Are you starting to see a trend in this? And again, a special commission from the SVG and CSS groups explores how the correct model is. The SMIL specifications have been around for a decade. We have supported SMIL for HTML all ten years and have observed very little use of it. We think that animations are an important part of HTML5, we know that the community has historically used code (JavaScript) and is starting to adopt a simpler-looking CSS model. Time will tell. that the community has historically used code (JavaScript) and is starting to adopt a simpler-looking CSS model. Time will tell. that the community has historically used code (JavaScript) and is starting to adopt a simpler-looking CSS model. Time will tell.
Patrick: That was a common answer. Do you agree that we need to turn our attention to these things? How?
Doug:I understand that development teams have to make difficult decisions about what to implement with limited time and resources. And the IE team makes the same decisions as the others in the first round of implementations. Other browsers did not have filters or SMIL animations at the initial stage, but as their implementation matured, they implemented these functions, I think Firefox will release SMIL in its next version.
But I agree that we need a closer look at all these functions in order for us to see how to improve them, not only to simplify and coordinate the implementation, but also to simplify the use by developers and so that developers can solve specific problems .
The matter with SVG Fonts is a little trickier, the guys from Firefox have their own preferences against supporting SVG Fonts, on the other hand, Opera and WebKit support part of SVG 1.2 Tiny (and this is the only WebFont format available on iPhone). I love SVG Fonts, although I understand that today there is a new generation of web font technologies available in browsers that overlap the capabilities of SVG Fonts. With accessibility for WOFF font designers, there will be much less need for SVG Fonts. But there are some interesting options for using SVG Fonts, and I think we should carefully consider what we will do with technology in the future. SVG 2.0 plans do not include the inclusion of SVG Fonts in the specification; instead, they will be allocated in a separate module. Thus,
Filters are another thing, I think it’s obvious that IE should support them in future versions, especially since you have hardware acceleration. As you know, the FX Task Force commission, which we formed together with the CSS working group, is developing the Filters module specification, which will allow you to use SVG filters with HTML content. Firefox and Opera have already implemented prototypes of this, and I am already observing a lot of interesting content on the web that uses these features for games, for data visualization, for video. CSS will support some attractive effects, such as the shadows you mentioned, but for a more advanced combination of effects, developers will need to use SVG filters for the content. And the attractive CSS effects will be just syntactic sugar built over the full functionality of the filters.
I have a twofold attitude towards SMIL animation: I love it because of what I can do with it and I hate it because it cannot be done. CSS declarative animation is very interesting to me and this is another area we are working on in the FX Task Force commission. We need a single base model for animating SVG elements and animations based on CSS classes, and they both need a sophisticated timing model (which is inherited from SMIL in SVG) and a state machine (which none of them now have). And both of them need better integration with JavaScript and the possibility of reuse for various elements (which CSS allows you to do, but SMIL does not). I predict that we will stop simplifying the SVG animation that we originally inherited from SMIL, but we will improve it in areas
This is my vision of things, although it is the business of the SVG and CSS working groups to develop what will eventually be used in browsers. All browser vendors and the public should express their point of view on what they need from SVG.
Doug: What was the most difficult to implement SVG?
Patrick:I think most implementers will agree that this is SVGDOM. There are some oddities that are not clear to us and the W3C SVG working group, for example, the ability to access any property using .baseVal. According to W3C rules, the SVG working group is not allowed to change the specification. Nevertheless, I think that the group will agree with those high-priority areas of SVG 2.0 and even with some ideas that hover around us and were posted by you earlier. By the way, this is another reason to revise the implementation of SMIL in the form in which it is written today. Each type (excluding some) is an animated type and requires a syntax for .baseVal / animVal, which we believe turn the design upside down. I am convinced the working group will revise this design.
Doug:Yes, I hope we can solve this problem with SVG 2.0. The path proposed today is not the best for implementers of the standard and for developers.
Doug: Is there anything else in SVG that you would like to change?
Patrick:I think I have already described most of the controversial issues that we stumbled upon during our planning phase, these are filters, fonts, SMIL to which we look at both SVGDOM and data types that we are already implementing. I would be glad to see SVG more simplified, more focused on vector graphics, separating styles (CSS) from pure geometry. I would be happy to see how accessibility is becoming a big part of the specification. I think it's time to reduce the size of the SVG DOM, bearing in mind that 90% of the scripts use interfaces against the more general get / setAttribute models used by web developers for less common scripts. Basically, I would like to see a competent separation of styles, animations and vector graphics, so that we can get a single model of styles and animations through what I consider to be the basic graphics for HTML5:
Patrick: From your point of view, what would you change?
Doug:I already mentioned some changes in declarative animation and DOM. I would like to simplify the reuse of SVG elements, which was the reason for my specification of SVG Parameters. I would like to add some features for defining high-level connectors between elements, since graphs are a common and frequently used application for SVG ... things like charts, diagrams, sketchy flows, trees, metro maps and so on. And I also want more graphic effects, like diffusion curves. And I would like to simplify the architecture around things like