About present and future SVG

Help from translator: Doug Schepers [ W3C ] - since 2007, an active W3C member 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 from the Internet Explorer team. He is 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 working group of the SVG (in the W3C - approx. Trans.). I asked Patrick a few 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 have determined that the next trend in the web is likely to be the graphics area. Although we became involved in the creation of the SVG specification, we had previously delivered to the W3C and brought VML (Vector Markup Language) to the web, but yes, this technology did not receive the attention we hoped for. Together with the commitment of the developer community to 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 job you can name?

Doug : Adding new features to 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 contend with the individual characteristics of SVG, HTML, CSS, and DOM implementations, so I want to simplify the life of people who use these technologies to solve their problems.

Doug: What Microsoft products today can already import or export SVG?

Patrick: SVG support, like many other products, has been in decline for the last ten years. At this point, Visio can export SVGs and our .NET Grid Controls controls contain the ability to create an SVG view as output, although they are still in beta. In addition, Bing as well as our other Microsoft Live services, as well as PowerPoint support SVG as a format. For a while, for compatibility, these services, like other leading sites on the network, will support VML for compatibility. I am glad that such costs for compatibility support 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 relevant specifications, including improvements in XHTML and DOM. In order to take the user experience to the next level, I know you, Doug, heard about it, we are making additional investments in hardware graphics acceleration and in a new compiled JavaScript engine, as well as in other performance improvements related to SVG (and our other features ) to make SVG technology a world-class technology.

Patrick : How do you assess the impact of the 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 have previously avoided using SVG will finally see something in this technology that they can use with the confidence that it will find widespread use. 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 seeing this, in fact, there are already many projects to convert SVG to Flash or to draw to the web with SVG. I think that the announcement of the support for 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 graphical calculations. Microsoft has revolutionized the PC gaming industry with DirectX and is happy to work with video card manufacturers in order to offer optimal experience for developers and players. The Internet Explorer team chose the right solution to use this success, using Direct2D libraries for all graphic functions (which also include HTML and text). This allowed us to eliminate a large number of software graphics graphics rendering and transfer these calculations to the GPU. This affects groups of functions such as transparency, gradients, geometry, graphical calculations, and even high-resolution video. We are pleased to use the ten-year investment of Microsoft, developers and vendors of hardware.

Doug: SVG 1.1 is a big spec. Like all other browser vendors, Microsoft splits implementation support into development periods and will not implement the full specification in IE9. What functions do you not plan to support right now and what plans do you have for the future?

Patrick: We told some implementers and W3C directly about it. As you mentioned, SVG is a big specification (twice as much as HTML 4.01), which is why browser developers gradually implement functions from version to version. Since we want to make a powerful push for graphics on the web, we decided that we need to implement the overwhelming part of the specification for portability with other browsers. In this regard, we are implementing 20 SVG modules and 23 existing modules. Three modules that we will not implement in IE9 are SVG Fonts, Filters and SMIL.

If you look 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 the key scenario for viewing text. Take a look at the many ways for web fonts 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 see no future for SVG Fonts. We think that a key feature of SVG Fonts for creating great fonts for the web is that the intellectual property relating to fonts can be protected for both open source developers and commercial vendors so that they can offer great solutions and eliminate the need to download fonts on desktop We will follow the demand for SVG Fonts using the techniques I have already mentioned, but at the moment I do not think that SVG Fonts will be widely distributed.

As for Filters, this is exactly the area that we could choose in order to demonstrate our graphical capabilities and transfer the intensive calculations 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 has gained much interest. The SVG specification offers 19 different filters from Component Transfer to Convolve Matrix and Specular Lighting. These are all excellent filters, especially when combined with each other and they can actually create interesting effects. However, if you look at the CSS Filters specification, you can find more convenient, web-developer-friendly filters, such as dropping shadows and already received recognition. I think we need to transfer ourselves to the state of “wait and see.” The SVG currently depends on the CSS 2.1 specification, not on CSS 3. We have formed special commissions in the CSS and SVG working groups to resolve this issue, but this will take some time.

Last, but not small, is SMIL, declarative animation. And again, Microsoft participated in the formation of the SMIL a dozen years ago. And, in collaboration with Compaq and Macromedia, I 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 challenge. Some believe that declarative animation will help build such a bridge and many toolmakers have made such attempts, few with some success. From communication with developers, we know that most create animations through code, which means JavaScript for the web. And this path is supported whole-heartedly in Internet Explorer 9, even now in Platform Preview versions. Animation is easily accessible and we offer developers a path to it for minimal resistance through code (using JavaScript - approx. Transl.). I’ll 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 models are correct. SMIL specifications for a decade. We supported SMIL for HTML all ten years and observed its extremely small use. We think that animation is an important part of HTML5, we know that the community has historically used code (JavaScript) and is starting to adopt a simpler CSS model. Time will tell.

Patrick: It was a general response. Do you agree that we need to pay attention to these things? How?

Doug: I understand that development teams have to make hard 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 implementations matured they implemented these functions, I think Firefox will release SMIL in its next version.

But I agree that a closer look at all of these functions is needed so that we can see how to improve them, not only to simplify and coherent implementation, but also to simplify the use by developers and so that developers can solve specific problems. .

The case with SVG Fonts is a bit trickier, the guys from Firefox have their own preferences against SVG Fonts support, on the other hand Opera and WebKit support some of SVG 1.2 Tiny (and this is the only WebFont format available on the 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 the availability to WOFF font designers, the need for SVG Fonts will be much less. But there are several interesting uses for SVG Fonts, and I think we should carefully consider what we will do with technology in the future. SVG 2.0 plans do not involve the inclusion of SVG Fonts in the specification, instead they will be allocated in a separate module. Thus, browser manufacturers will be able to base their decisions on user requirements for this function.

Another thing is filters, I think, obviously, 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 that will allow you to use SVG filters with HTML content. Firefox and Opera have already implemented prototypes of this, and I already see a lot of interesting content on the web, which uses these features for games, for data visualization, for video. CSS will support some attractive effects, like the shadows you mentioned, but for a more advanced combination of effects, developers will need to use SVG filters for content. And the attractive CSS effects are 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 I can't do it. The declarative animation in CSS 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 animation based on CSS classes and they both need a sophisticated timings model (which is inherited from SMIL in SVG) and a state machine (which is not in any of them now). And both of them need better integration with JavaScript and reusability for different elements (what CSS allows you to do, but SMIL doesn't). I foresee that we will stop simplifying the SVG animation that we originally inherited from SMIL, but we will improve it in areas that will make it more powerful for developers and designers.

This is my vision of things, although it is up to the SVG and CSS working groups to develop what will eventually be used in browsers. All browser vendors and the public should express their views on what they need from SVG.

Doug: What was the most difficult part of implementing SVG?

Patrick: I think most implementers would agree that this is SVGDOM. There are some oddities that are not understandable 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 the group will agree with those high-priority areas of SVG 2.0 and even with some ideas that hover around us and placed earlier by you. By the way, this is another reason to revise the implementation of SMIL as it is written today. Each type (excluding some) is an animated type and requires syntax for .baseVal / animVal, which we think is turning 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, the SMIL to which we are still looking at and SVGDOM and the types of data that we are already implementing. I would be glad to see SVG more simplified, more focused on vector graphics, the separation of styles (CSS) from pure geometry. I would be happy to see accessibility becoming the most part of the specification. I think it's time to reduce the size of the SVG DOM, meaning that 90% of the scripts use interfaces against the more common get / setAttribute models that web developers use for less common scripts. Basically, I would like to see a good separation of styles, animations and vector graphics, so that we can get a single model of styles and animations through what I consider the basic graphics for HTML5: SVG + CSS + HTML.

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 possibilities for defining high-level connectors between elements, since graphs are a common and common use for SVG ... things like diagrams, diagrams, schematic flows, trees, subway maps, and so on. And I also want more graphical effects, like diffusion curves. And I would like to simplify the architecture around things like <use>, <symbol>, <clipPath> and the like. The general requirement is for more advanced markup capabilities and I hope we can implement it in SVG 2.0 with shape-paths and relative positioning without making SVG too complicated. Finally, I would like to see a common graphic API with Canvas so that developers can only learn about it. And like many people, I would like to see transparent compatibility with HTML: links to SVG files from HTML, embedded SVG code in HTML, embedded HTML code in SVG.

Doug: The SVG team started creating early draft SVG 2.0. What would you like to see in SVG 2.0?

Patrick: As you know, I raised this topic at the last newsgroup. I think that now there is a genuinely positive desire to move forward to the next version. The current specification is more than ten years old, and implementers have learned a lot during this time. Although vector graphics are fundamental in nature, there are always opportunities to make things better. Microsoft is heading the next meeting at the end of May in Belgium. I will be on it and will continue to push the working group to turn around and look at the meaning of SVG as part of HTML in the developer’s daily life. Instead of delving into new features and functionality, you need to decide how we could eliminate some of the painful points that we all faced during the implementation of the specification. But more importantly, eliminate the side effects of these painful points that stand in the way of web developers. Since scripts of static SVG documents have existed for a long time, they are already well implemented. We need to return to the level of scenarios and revise the goals of SVG, to engage in basic developments from the moment of their implementation and to produce the best model for HTML5 and SVG for existence in harmony on the web and designed for web developers.

Patrick: You posted a lot of great drafts, for example on reducing DOM and supporting <param>. Do you agree that we, as a working group, need to look back and think first about the level of scenarios?

Doug: Yes, I think in SVG 1.1 a lot of cool things, but also a lot of things that I would like to change, things that we SVG developers have learned over the decade of development. I think that SVG 2.0 is a great opportunity for us to correct mistakes before the SVG really gets distributed and it will be difficult for us to change something. And our decisions should be dictated by the needs of SVG developers and the design community.

Patrick: I think SVG has a bright future, do you agree?

Doug: I wouldn't be here if I didn't agree! It will take time, but the SVG will eventually find its recognition.

Patrick: Well, it was great to meet you at MIX and see you in Brussels.