Standardizing HTML6 through the W3C – My Trip to TPAC 2010
The W3C working groups, across the board, are making progress completing the important next generation of web standards, getting key specifications to last call, and a focus on defining the test suites for measuring the completeness of implementations. At the same time, there is renewed focus on innovating for the future of the web at the W3C.
Some members of the W3C CSS/SVG FX Task Force.
From left to right: Jun Fujisawa - Canon, Chris Lilley - W3C, Doug Schepers - W3C, Håkon Wium Lie - Opera, Patrick Dengler - Microsoft, Anthony Grasso - Canon, Erik Dahlström - Opera
I attended as a representative of Microsoft and a member of the Scalable Vector Graphics (SVG) Working Group.
Once per year the W3C Community gathers together Working Groups, Interest Groups and invited guests for a week of technical discussions.
For the Technical Plenary day, all attendees gathered in one room to discuss various technical topics of “significant importance to past, present and future of the World Wide Web Consortium”. During the HTML.next session, I presented a paper entitled HTML6: HTML + SVG + CSS. I talked about how as a group, the members of the W3C, represent the broader web developer community, and therefore have an obligation to serve that community by creating an interoperable Web platform and delivering it in a timely manner.
On Thursday, the CSS Working Group joined a discussion with the SVG working group to focus on complementary, but incompatible, features that crossed both CSS and SVG. There is a growing consensus that the next generation of SVG will mostly be in the context of an HTML page – something that the HTML5 specification calls out, and that is necessary to create a cohesive experience that leverages Web developers’ existing skills. There is a lot of interest and activity in the intersection of CSS and SVG. For example, some browser vendors have experimentally implemented CSS features such as transforms, transitions, animations, filter effects, and gradients. SVG has had most of these technologies for over a decade, but they are incongruent with what Web developers expect.
The SVG and CSS Working Group attendees discussed each of these areas, identified area experts as owners, and established timelines for delivering transforms (possibly combining 2D and 3D), transitions and animations, filter effects and gradients. The end goal is that Web Developers will have an interoperable set of features they can depend upon, and browser vendors will have a stable platform to implement.
The Working Groups continued with this momentum and resolved additional integration issues with SVG, CSS, and HTML.
The integration of SVG into HTML paired with CSS seems to be well defined, but would definitely benefit from more conformance tests. The Working Groups will collaborate to build tests for cross SVG, CSS, and HTML scenarios into the HTML testing infrastructure. Additionally, some browsers are investigating how to simplify the SVG DOM to make it more closely resemble the HTML DOM experience that is expected by Web developers.
We’re excited about the approach the SVG Working group, in partnership with other Working Groups, is taking to drive and complete this consolidation by applying engineering principles. These principles include establishing Scenarios and Use Cases, prioritizing features that offer focus, delivering tests together with specifications, and aligning delivery dates across feature sets. The Working Groups have tentatively agreed that we could stabilize all of these specifications by June, 2011.
It is great to be a part of the progress happening at the W3C, across a broad range of important web standards, including SVG and CSS. The large amount of activity in all the face-to-face meetings generates a lot of follow-on work. There is much for the web community and working groups to do together in the year ahead. We’ll continue to provide updates on the progress in these areas on the IE blog.
Patrick Dengler
Senior Program Manager
Internet Explorer
Comments
Anonymous
December 01, 2010
Offtopic, but the share on Twitter link provides a tweet that is waaaaaay too long.Anonymous
December 01, 2010
hey good job man. Visit my site… http://www.webkotwal.com/ ……….. http://www.chambatrip.com/Anonymous
December 01, 2010
Meh. Another blog post that's just repeating parts of the previous one.Anonymous
December 01, 2010
We want WebWorkers :)Anonymous
December 01, 2010
Did you add WebGL and WebSockets yet?Anonymous
December 01, 2010
Why you ask about unfinished and/or non-standard things? WebWorkers - not finished(not stable enough) WebGL - outside of W3C / not finished WebSockets - not finished(not stable enough)Anonymous
December 01, 2010
I said something similar on Adrian Bateman's post, but: testing as you go, etc. certainly seem to be a good thing when developing software. But in a standards body, I'm afraid the process will get substantially slowed down as vendors work out every corner case in the CSS test suite before Microsoft will implement anything. Much of the cool stuff in HTML5 happened when a vendor implemented it, a rough (non-test-suite-y) spec got written, and vendors built their implementations to conform to that roughly written spec plus their own best guesses about what would be best for developers plus what they saw other implementations do. Some incredibly cool things in HTML4 -- innerHTML, XmlHttpRequest -- were extensions first. VML was deployed before SVG was standardized. "Embrace and extend" can work when the extensions are platform-neutral, will ultimately be controlled by standards bodies, and start with good compatibility -- not 100%, but getting lots of the showstoppers out -- then converge rapidly. These days vendors can produce a better, more compatible first cut than was possible in the browser wars. What I'm saying is, if test-driven standardization winds up super-slow, I'll take faster innovation and deployment over perfect compatibility in v1.0. Whether it's slow is an empirical question -- if it's not, test suites for the win. But my wish is for the web's capabilities to grow rapidly more than for them to grow without any bumps and bruises I have to deal with as a developer. I don't want the world to need another WHATWG years from now. As a related but distinct heretical challenge, I'd love to see Microsoft field a DirectX-based analogue of WebGL. It's not realistic to expect MS to build an OpenGL implementation soon, but I can totally see two JS 3D stacks getting a portable JS engine built on them. And I've said it a million times, but I want -ms-transition in IE9: easy-to-use declarative animations rock.Anonymous
December 01, 2010
HTML<strong>6</strong>? WTF?Anonymous
December 02, 2010
HTML6? #LOLAnonymous
December 02, 2010
You guys are too late, last week we upgraded our site to HTML 7.0 beta!Anonymous
December 02, 2010
One thing that annoys me, as a user of SVG outside of an image editing GUI, is that, though this is a markup language, it is very dissimilar to any other markup language. Specifically, In HTML, XML, or even SOAP, grouping is handled by assigning a parent tag to a group of elements. In (X)HTML this means a ton of things, especially when combined with CSS for positioning. SVG on the other hand has a grouping element (g) which says very little in regards to semantics and style. Sure, I have a group of shapes, but: I cannot move the group without performing a transform; I STILL have to position the grouped elements based on the "viewPort"; and if I have a group of a rectangle and text block, they are in no way connected (as a label for a rectangle or otherwise), which means it gains no semantic value. I suggest that SVG 1.2 or 2.0 alter the syntax to expand certain elements (shapes, text) and allow them to contain other elements (more shapes and text). This would make the language feel a lot more like other markup languages, adds the benefit of allowing positioning relative to the parent element (which will increase the accuracy of SVG documents), and will increase the semantic value of SVG tags. You might have just thrown a flag on the text containing text comment, but I think this would simplify the use of text tags (instead of needing a text tag AND a tspan tag...why??). All of the changes I mentioned here can easily support deprecation while still being backwards compatible. I think this alone might provide that cohesive experience you were looking for in your meeting.Anonymous
December 02, 2010
The comment has been removedAnonymous
December 02, 2010
@Eric Martindale and @Sérgio Rodrigues : don't worry, they just messed up December 1st and April 1st.Anonymous
December 02, 2010
@Rob, @Eric @Olivier : HTML6 was not meant to be a joke or mislead. It was mean to really think about how all of these previously disconnected technologies actually come together in HTML. And in fact to @Kevin's post, I agree that SVG needs some mondernization. If you read the links and such you will pull this story and how it all relates together I hope. If not, feel free to respond.Anonymous
December 02, 2010
It seems that geolocation still fails on IE9 and on Windows fone 7 blue e. Why when it is almost 2011 has MSFT not got this working yet? Please finish fixing innerHTML while you are at it.Anonymous
December 02, 2010
Thanks for this Patrick. I follower tpac via the IRC logs and the plenary day audio stream and your contributions stood out as some of the most energetic and forward-thinking.Anonymous
December 02, 2010
The comment has been removedAnonymous
December 03, 2010
Why are we even talking about HTML6 when HTML5 hasn't been finalized yet?Anonymous
December 05, 2010
Not a conformance test, but the physical science text I author now exists as HTML+CSS+SVG+MathMl served as text/html at www.comfsm.fm/.../200.html The text is 7346 lines of hand coded HTML5, prints out to 154 pages, and validates at validator.nu. Any browser that can correctly render this text along with its SVG charts and MathMl formulas would seem likely to be a conforming browser with respect to SVG and MathMl. I work from a small island in the Pacific (Pohnpei, GMT +11) and bandwidth is limited during our business day, so best to pull that page during our night!Anonymous
December 05, 2010
The comment has been removed