The result of discussion among the Membership is that there is strong support for:
In short, there is strong support in the Membership (but not unanimity) for all of the use cases cited by the HTML Working Group except forking the specification. Several W3C Members do feel strongly that the document license should allow forking, however.
People at the meeting agreed that, in any case, copyright is not likely to prevent fragmentation. Several points were made:
We have work to do to find the right license to meet the stated goals: to make it easy for people to reuse W3C specifications in almost all of the scenarios people have expressed are important to them.
We plan to work with the community on the details as we move forward. More information can be found in my slides from the meeting. We welcome your feedback.
]]>At the same time we are looking to engage with IETF and W3C to explore how to get broader adoption of the OData extentions & conventions.
I would like to take Microsoft up on their suggestion: I invite you to create an Incubator Group at W3C. Incubator groups start quickly, and the Members that start them can design them so that anyone can participate. A lot of people who are passionate about data are already part of the W3C community and you are likely to get a lot of feedback.
Incubator Groups don't produce standards, but the community can decide later whether the API should move to the W3C Recommendation Track (or somewhere else). One good reason for doing that is the W3C Royalty-Free Patent Policy. Incubator Groups can smooth the transition from "good idea" to "widely deployed standard available Royalty-Free."
I hope you'll take me up on the invitation.
Oh, and the invitation is not just for Microsoft. W3C is interested in APIs for access to data; this is on the agenda for a June Workshop. If you're working on an API and it has "data" in the name, I encourage you to build community support in a W3C Incubator Group.
]]>For me, a major attraction to come to W3C is its reputation and success as a trusted custodian for an open web. Accordingly, I was pleased to see certain expectations met:
Through the years I've heard people propose improvements for W3C. While problems are known – and they came up quite clearly during the interview process – I candidly did not know whether the stakeholders of W3C were committed only to complain, or were passionate about supporting change to address issues. Although I came in not knowing how people would react, I was very encouraged by:
Our environment provides challenges. At the financial level there are the impacts of the economy and at the technical level there are issues of fragmentation due to parallel innovation. As a result, I was not surprised to see some issues, including:
Every organization has its core constituency, and W3C is no different. Although W3C has worked hard to broaden its constituency, I was disappointed to see how much work was in front of us. Included in that is:
More broadly, there are many ideas on how to strengthen the organization (a good thing), but sparse staffing to pursue these ideas (a bad thing). Bridging this chasm needs to be a priority for me.
Clearly, it is my responsibility to lead the staff in addressing the items which need work. First, however, it is critical for me to get as complete a perspective as possible from as many stakeholders as possible. My objective is to strengthen W3C and I need both a firm grounding in current status and a rich understanding of how people would like it to evolve. People with opinions should feel free to post them here or send them via email.
]]>This event is free and organized as part of the Boston Web Design Meetup group. Please, don't forget to register as soon as you can.
We're looking forward to see you there and have fun with Web technologies.
]]>Let me also use this blog entry as a gentle reminder that the deadline for the position paper submissions is on April the 4th. There is still time, but not that much…
]]>The World Wide Web is easily the most revolutionary development that has changed not only information technology, but everything about business, education, entertainment, and information retrieval.
The World Wide Web consortium is the singular organization that leads the web to its full potential with its protocols and guidelines.
I am honored to be here, I am honored to work with Tim Berners-Lee, and excited to play a role in this mission.
My most immediate priority is to preserve and enhance the W3C culture of having an open consensus-based process. This works well today, but I also need an effective and open high-bandwidth communications path with the large, diverse, and global set of stakeholders of the W3C.
One part of that is blogging. I intend to post often and invite comments. This will be a good way for people to engage in public discussion with me on issues of importance to the organization.
Not every issue will show up on a blog. To cover different issues, or if people are more comfortable with email, they are also welcome to send their thoughts to jeff@w3.org. I intend to be responsive but also ask your patience as I adapt to this new role.
Another priority for me is to climb a steep learning curve in a short amount of time. Accordingly, I’ll save comments on other topics until I learn some more. Meanwhile, feel free to contact me with your ideas, aspirations, and concerns relative to W3C.
]]>
As part of a series of interviews with W3C Members to learn more about their support for standards and participation in W3C, I'm talking to Paul Cotton from Microsoft and co-Chair of the W3C HTML Working Group.
First, let me thank you personally on becoming a co-chair of the W3C HTML Working Group. I am very happy with Microsoft's commitment to the HTML Working Group and to HTML 5. Microsoft is collaborating very actively, and helping drive consensus around many HTML 5 proposals related to Canvas, Accessibility and Extensibility.
Q. Microsoft participates in a large number (~30) of W3C Working Groups and has shown this level of commitment for many years. You sent 12 people to the November 2009 HTML Working Group face-to-face meeting, an unusually high number of people from a single company for a face-to-face meeting. Why is Microsoft investing so heavily in the W3C HTML 5 effort?
A. Thank you Philippe, I really appreciate your comments.
It’s true, Microsoft has been working with the W3C since the 1990’s, and has held a number of leadership positions as well as having a great many individual contributors engaged with a variety of different W3C working groups. Over the last decade, since HTML4 was made a W3C Recommendation the Web has grown immensely. It’s also gone from a fairly static, document centric place to being the rich, interactive, transactional and real-time place it is today. HTML forms the backbone of interoperability on the Web, and as the next revision of the specification begins to take shape, Microsoft plans to contribute the necessary resources and expertise to help the W3C ensure a thoughtful, comprehensive, backwards-compatible, and testable specification is put forward as a new W3C Recommendation. W3C and Microsoft understand that the Web is no longer the domain of just academics, governments, and computer scientists, but that it is today a vital service relied upon by regular people around the world as well as enterprises. It is a vital part of everyday life, and must be treated with the utmost care.
Because of this, Microsoft has allocated software engineers, test developers and program managers to assist the W3C with the work ahead. Microsoft has a vast breadth and depth of experience in the challenges of supporting such a vast, dynamic ecosystem – after all, over a billion people rely on the safety, security, and compatibility of our operating systems today. We’ve learned a lot of lessons – sometimes the hard way – about how to build resiliency and interoperability into our operating systems. We want to bring this expertise to the W3C to help with the challenge of revising the underpinnings of the Web.
Since August 2009 when I became a co-chair of the W3C HTML Working Group I have been trying to use my more than 10 years of W3C experience to help progress long standing issues on the specification, to define a testing infrastructure, and to push for more work in important areas that had not yet received enough attention – like accessibility.
Q. There is considerable confusion about what HTML 5 is: People use the term HTML 5 to refer not only to the work of the HTML Working Group, but also to work being done in other W3C working groups or even referring to technologies that are not being standardized. As co-Chair of the HTML Working Group, can you talk about what the group expects to be part of HTML 5 and how it relates to the work of other Working Groups?
A. I agree that many of us use the term “HTML 5” very loosely.
First, I believe that most people use the term “HTML 5” to refer to the HTML 5 specification currently being worked on by the HTML WG. The HTML 5 specification defines the syntax and the semantics of the elements and attributes in the HTML markup language and several of the APIs that are used to process HTML documents. Recently the HTML WG has started to break the HTML 5 specification into more modular and separate Working Drafts e.g. HTML+RDFa, HTML Microdata, and HTML Canvas 2D Context. The HTML WG is also publishing two additional documents to aid users of HTML 5: the HTML 5 differences from HTML4 specification and HTML: The Markup Language which is aimed at developers that produce HTML 5 output.
Each of these additional Working Drafts are still part of “HTML 5” and are all on track to become separate but related W3C Recommendations or Working Group Notes. I believe that the content of these WDs taken together will define the part of “HTML 5” being worked on by the HTML WG.
But I believe that some use the term “HTML 5” to refer also to the important related API specifications being worked on by the WebApps WG. The WebApps WG is chartered to create client-side APIs that can be used with the HTML markup language – in fact some of its specifications started as part of the HTML 5 specification but were migrated over to be separate modular specifications managed by the WebApps WG. In addition there are some very interesting APIs under development by the Device APIs and Policy Working Group which are related to HTML 5 since they can be used with the HTML language and in user agents.
Others use the term “HTML 5” to also include the ECMAScript-262 Language which defines the programming language that we use today to build dynamic web applications.
Q. There is a considerable amount of work is still required before HTML 5 is finalized. There has been a lot of excitement in web development circles about HTML 5, and a lot of misconception about the status of the specification. Can you explain exactly where you see the current status of the HTML 5 specifications and the process being organized by the 3 co-chairs of the HTML Working Group to drive HTML 5 to completion?
A. The HTML 5 specifications being worked on by the HTML WG are all at the W3C Working Draft stage. This means that the material is not final and is still being worked on by the HTML WG.
In order to get the WG’s specifications to the W3C Last Call stage the WG needs to resolve all the known comments and issues with the Working Drafts and make WDs functionally complete. In order to do this the WG co-chairs have helped the WG come to consensus on a decision policy for outstanding issues. The WG is now using and evolving this policy. The current status of issues before the WG is available.
Q. Where can we find the latest information on the current status of HTML 5 and the list of open issues of the HTML Working Group?
A. The HTML WG encourages comments and input on the WG’s Working Drafts. The WG processes comments by using a Bugzilla entry for each separate comment. There is a Bugzilla “component” for each of the HTML WG specifications, for example, comments related to the main HTML 5 specification can be entered via the “HTML 5 spec bugs” component. Anyone can search the Bugzilla components for the HTML WG to see which bugs have been for example been CLOSED or which are still OPEN. And as indicated above the status of the issues before the HTML WG is available.
The current HTML WG working drafts and other HTML-related working drafts are available.
Q. Can you talk about the Working Group's perspective on the role of testing in the standards process?
A. Last fall the HTML WG agreed to create two separate task forces: one on Testing and a second on Accessibility. The Testing Task Force’s mandate is to setup the infrastructure and a test suite for the HTML WG’s specifications. The task force is lead by Kris Krueger from Microsoft. The Testing Task Force’s Wiki pages are available.
When the WG has processed all Last Call stage comments the HTML WG specifications will move on to the W3C Candidate Recommendation stage when the W3C does a “Call for Implementations” for the specifications. The idea behind starting the Testing Task Force so much in advance of getting to the CR stage is to build as much of the required test suite as possible BEFORE the WG’s specifications gets to CR. By doing this the time spent in the CR stage should be minimized. In addition by creating tests for the specifications as early as possible these tests can then be used to assist in improving the quality of the HTML 5 specifications even before the Last Call or Candidate Recommendation stages.
Having a comprehensive test suite for all the HTML 5 specification is something that Microsoft thinks is very important. Microsoft is committed to submitting test cases for HTML 5 features and to reviewing test cases submitted by other task force members.
Q. Although HTML 5 has not been finalized, can you talk about what parts of HTML 5 IE8 supports?
A. IE8 implemented some features from the W3C HTML 5 Working Draft (AJAX Navigation, Network Connectivity Events), from the W3C Web Applications specifications (DOM Storage, Cross Domain Request and Cross Document Messaging), from the ECMAScript-262 Language specification (Native JSON Support) and CSS Selectors and Mutable DOM Prototypes. A good overview of these functionalities is available.
Q. Can we expect even more support for HTML 5 in IE 9?
A. Watch this space. As you can see, Microsoft is investing very heavily in the W3C HTML 5 effort, working with our competitors and the web community at large. We want to implement ratified, thoroughly tested, and stable standards that can widely help interoperability of the Web. We will have more to say on the subject at the MIX conference.
]]>With a Future of XML workshop in the offing, maybe it's time to revisit one of the oldest XML feature requests: binding general entities without using the internal/external subset.
There have been numerous more-or-less serious proposals to address this requirement over the years---here's a new (?) one.
Suppose we introduce a new official PI, named xml-entity:
<?xml-entity copyright "©"?>with the obvious consequence that any use thereafter of ©right; would produce a ©. That would allow a few entity declarations to be added to an XML document.
To enable large numbers of entity 'declarations' to be managed effectively, the next step would be to introduce xml-entities as well:
<?xml-entities PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent"?>and
<?xml-entities SYSTEM "myentities.ent"?>where the referenced files could use either the old <! ENTITY syntax or the new PIs.
Simple, low-impact, and it's backwards compatible. It won't work with SOAP, which forbids PIs altogether (why?).
]]>Each camp is one day. The morning sessions will feature talks from experts and surprise guests. In the afternoon of each session, the participants themselves will choose the topics they wish to discuss during the breakouts.
Wikis are available to submit topics of discussion in advance. There is one wiki per camp: LODCampW3CTrack and HTML5campW3CTrack. Apart from technical topics, we are also looking for lightning talks (very short presentations) proposals: anything from announcements, forward thinking ideas, controversial statements, observations, short demos, etc. Note too that the breakout session outcomes will be recorded in the same wikis.
So, if you're planning to attend the WWW conference, please register through the WWW2010 online registration system and let's W3Ccamp there!
]]>
Back in 2008, the Mobile Web Test Suites Working Group released its first Web Compatibility Test for Mobile Browsers that packed 12 (and later, 16) important Web technologies into a single page that would tell you at a glance how well your browser supported them.
Fast forward to 2010, the level of support on this first Web compatibility test has tremendously improved, although the browsers that show a fully green grid are still few.
But in the meantime, the technologies have also evolved, and while many of them are still not final by any means, it seemed that getting an overview of which of these technologies are available today on what browsers would make a good follow-up to our first test.
That's the goal of our second Web compatibility test for mobile browsers that tests a number of Web technologies through their JavaScript interfaces, and collects detailed results on which browsers pass which tests.
This is the first release of the test, so it likely isn't quite perfect, and as always, the choice of the tested technologies is somewhat arbitrary; we are very much looking for feedback, either in the comments here, on our Working Group blog, or to our public mailing list.
]]>Q. Who makes the decision within a Working Group to request publication of a W3C Working Draft?
A. The Working Group. The W3C process says:
“The Chair MUST record the group's decision to request advancement.”
Working Groups must fulfill certain criteria before requesting publication, and as the document matures towards Recommendation, there are reviews of the publication request to ensure that the criteria for publication have been satisfied.
See section 7.4 of the W3C Process Document for more information about what criteria the Working Group must satisfy in order to advance a document on the Recommendation Track.
Q. Can a group participant stop the group from requesting publication?
A. No.
To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).
Furthermore, per the previous question, the Chair may record a decision where there is dissent so that the group may make progress. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.
A dissenter may formally request that the Director consider the dissent as part of evaluating the related decision. This is done by raising a Formal Objection. A record of each Formal Objection must be publicly available.
Furthermore, the expectation is that the Status section of a document should say when there is not consensus (see the Manual of Style and Process document for information about what is useful to include in a Status section).
Q. For most W3C drafts, who approves the Working Group's request to publish?
A. The vast majority of publication requests are not disputed, and they fall clearly within the scope of the Working Group's charter. Although the W3C Director has responsibility for approving publication requests, on a day-to-day basis he delegates (see W3C Team) this responsibility to others on the W3C management Team as described in the public documentation about W3C technical reports. The W3C management Team escalates to the attention of the Director when necessary.
Q. Have there been concerns raised over whether the HTML Working Group should publish some of the documents currently under consideration?
A. Yes. Procedural concerns have been raised about whether some of documents (HTML+RDFa, HTML Microdata, and HTML Canvas 2D Context) fall within the scope of the HTML Working Group charter, or whether another W3C Working Group should develop them. Such concerns appropriately arise from time to time. In the current case, the concerns have been raised consistent with W3C Process, including the requirement to have a public record of concerns available for review. While the concerns are being given due consideration within the community, the W3C Staff expects that if the Working Group requests to publish the relevant documents, the Status sections will clearly note that there is disagreement on the scope question.
]]>They are now... The Workshop will indeed take place on the 26 and 27 of June, 2010, and hosted by the National Center for Biomedical Ontology (NCBO), at Stanford University. Note that those dates are on the week-end after the SemTech2010 conference, held nearby in San Francisco.
The call for paper of the Workshop has been updated, and also includes details on the way of submitting position papers.
]]>Back in 2008, Karl Dubost crafted an image of our robots and put it on a tee-shirt that we handed out to the W3C groups Chairs, at TPAC2008, as a gift, to acknowledge their terrific work.
The "W3C Bots" image is now available! It comes in different flavours (graffle, SVG, PNG, and EPS) which are available under the Creative Commons Attribution 3.0 United States license.
People who read French can follow the story of the W3C Bots on Karl's blog entry "La naissance des bots du W3C", others can simply look at the pretty photos. Here are draft three and the final version:
Just as for all new services bugs may have been overlooked; contact Ivan Herman if you find any!
]]>… It is not the goal of this wiki to supersede other community wikis […] instead it is to provide a “first stop” for more information on Semantic Web technologies, in particular on Semantic Web Standards published by the W3C. Communities around such standards are also welcome to use the Wiki for their purpose
The new wiki makes use of Semantic Media Wiki (and thanks to Denny Vrandecic to have helped in setting up things). A good example is the way Semantic Web tools are handled (the structure was greatly inspired by a similar collection on the SemanticWeb.org site). In contrast to the old collection of Semantic Web tools on ESW Wiki, each tool gets its own page now; see, for example, the page for Jena.
The template that helps creating that page adds a number of Semantic Media Wiki statements which also yield an RDF description for the tool. The RDF content makes use of public vocabularies like Dublin Core, DOAP, RDFS; it also has an rdfs:seeAlso entry to the similar page on SemanticWeb.org and, when applicable, there is also a link to the tool‘s DOAP file. (Using external vocabularies was not obvious; it is a bit convoluted in Semantic Media Wiki. Denny‘s help was essential in finding out how to do that…). As a result, these tool descriptions are not in isolation any more but are properly linked to other resources on the (Semantic) Web.
The tools are also categorized on what type of SW technologies they are relevant to (ie, RDF, OWL, SKOS, etc), what category of tools they are (programming environment, editors, converters), or what programming language, if any, they are usable from. The great thing is that it is then possible, by adding suitable Semantic Media Wiki statements into a page, to collect references to tools on another page. Eg, the page on RDFa includes (well, indirectly via a template) the following:
{{#ask: [[Category:Tool]] [[SW Technology::RDFa]]
|?Tool Name= |?modified= |sort=modified |limit =5
…
that will automatically display references to the 5 most recently added/modified tools related to RDFa. This type of possibility (and others, see the tool page) made it really worth the move from the old ESW wiki.
Of course, this is a wiki. Ie, it has to evolve through community help and participation. Maybe new features for tools or new search formats and references are necessary. I would like to see a structure similar to the tools for the list of books which is, at present, just a flat list. A SPARQL engine to search through the site would be useful. Various communities should use the Wiki for their own purposes (this has already started, see the discussion page set up for the discussion on RDF‘s future). Etc… But the first step has been made!
]]>WAI encourages you to tell organizations how important it is that their websites are accessible. Especially when you come across accessibility barriers, tell the organization about it!
To help make this easier and hopefully more effective, WAI just published:
Contacting Organizations about Inaccessible Websites. It walks through steps, provides lots of tips, and includes sample e-mails.
Just yelling at your computer isn't going to get the accessibility barriers fixed. Just complaining on a blog or other place where the organization won't see it isn't likely to help.
Instead, consider what approach will get the results you want. An encouraging e-mail is often a good first step. Sometimes organizations are not even aware of accessibility issues, and don't know how web accessibility is vital for equal rights, required by law in some cases, and has strong business benefits. See Contacting Organizations about Inaccessible Websites for more.
WAI would like to hear your ideas for this document and your experiences dealing with inaccessible websites. The WAI Interest Group (WAI IG) hosts a public discussion e-mail list; comments on specific documents are collected through the publicly-archived wai-eo-editors@w3.org list; and we'll watch for comments to this blog post.
(Please send comments by 3 February 2010 for consideration in the next version.)
Thanks! ~Shawn
Contacting Organizations about Inaccessible Websites is edited by Andrew Arch, Shawn Lawton Henry, and Shadi Abou-Zahra; developed by the WAI Education and Outreach Working Group (EOWG) as part of the WAI-AGE Project.
]]>We would like to add relevant, strong resources to this page. We are particularly looking for case studies where the main changes to the website were accessibility improvements. If you have made accessibility improvements to your website in the last three years, we may be able to help you gather data and develop a case study. Would your organization be willing to share your case study to support the business case for web accessibility?
To share business case resources, please e-mail the publicly archived list: w3.org-wai-editors@w3.org, or team-accessibility-business-case@w3.org (This second mailing list is not publicly archived; however, there are some non-W3C-staff Working Group members subscribed to the list.)
I've been asked: "Why are you even talking about the business case? Access to the Web is a basic human right, as stated in the UN Convention on the Rights of Persons with Disabilities. It's the right thing to do for equal access. And it's required by law in many places."
My reply: Understanding the business case can help organizations put a higher priority on accessibility. While ideally organizations would make their websites accessible just because it's the right thing to do; in reality, many organizations need a business case justification for spending resources on accessibility. Our goal is for the Web to be accessible to people with disabilities, and we are happy to promote the business benefits of accessibility to help meet that goal and make the Web accessible.
We hope you find the business case resources helpful, and we encourage you to share your resources via the links above. Thanks! ~Shawn
]]>We're excited about these and other documents on the perspectives of users — specifically users with disabilities and older users — coming soon as part of WAI-AGE Project funded by the European Commission. People with disabilities have long known that direct experiences are a key input to the standardization process and to successful implementation of standards. Understanding the experiences of older users is becoming an important issue for many projects. These documents help project managers, developers, and designers better include users' experiences throughout their work.
When designers and developers see people with disabilities use products like theirs, most are highly motivated by a new understanding of accessibility. Rather than seeing accessibility as only a checklist item, the real-life experience shows the human side of accessibility. Designers and developers understand the opportunity for their work to impact lives.
It also broadens your perspective in a way that can lead you to discover new ways of thinking about your product that will make it work better for more people in more situations.
The Involving Users docs start with several ways that involving people with disabilities from the beginning of a project helps you better understand accessibility issues and implement more effective accessibility solutions. The docs provide pointers on:
While the evaluation document is mostly for those developing websites, web applications, browsers, assistive technologies (AT), and authoring tools; the main Involving Users document also addresses those developing standards and policies for accessibility, and those developing any web technologies or technical specifications.
We hope that the Involving Users documents help you realize the benefits of involving people with disabilities in your web projects. Please share your experiences, and your suggestions for the documents: the WAI Interest Group (WAI IG) hosts a public discussion e-mail list; comments on specific documents are collected through the publicly-archived wai-eo-editors@w3.org list; and we'll watch for comments to this blog post. Thanks! ~Shawn
]]>The ideas behind the proposal presented here are neither particularly new nor particularly mine. I've made the effort to write this down so anyone wishing to refer to ideas in this space can say "Something along the lines of [this posting]" rather than "Something, you know, like, uhm, what we talked about, prefix binding, media-type-based defaulting, that stuff".
Criticism of XML namespaces as an appropriate mechanism for enabling distributed extensibility for the Web typically targets two issues:
Of these, the first is arguably the more significant, because the number of authors exceeds the number of developers by a large margin. Accordingly, this proposal attempts to address the first problem, by providing a defaulting mechanism for namespace prefix bindings which covers the 99% case.
dpd for use in the (X)HTML
header;xml-dpd and/or an
attribute xml:dpd for use at the top of XML
documents;XML namespaces provide two essentially distinct mechanisms for 'owning' names, that is, preventing what would otherwise be a name collision by associating names in some way with some additional distinguishing characteristic:
In XML namespaces as they stand today, the association with a URI is done via a namespace declaration which takes the form of an attribute, and whose impact is scoped to the subtree rooted at the owner element of that attribute.
Liam Quin has proposed an additional, out-of-band and defaultable, approach to the association for unprefixed names, using patterns to identify the subtrees where particular URIs apply. I've borrowed some of his ideas about how to connect documents to prefix binding definitions.
The approach presented here is similar-but-different, in that its primary goal is to enable out-of-band and defaultable associations of namespaces to names with prefixes, with whole-document scope. The advantages of focussing on prefixed names in this way are:
aria- and data-;Provision is also made for optionally specifying a binding for the default namespace at the document element, primarily for the media type registry case, where it makes sense to associate a primary namespace with a media type.
If this proposal were adopted, and a dpd document for use in HTML 4.01 or XHTML1:
<dpd ns="http://www.w3.org/1999/xhtml"> <pd p="xf" ns="http://www.w3.org/2002/xforms"/> <pd p="svg" ns="http://www.w3.org/2000/svg"/> <pd p="ml" ns="http://www.w3.org/1998/Math/MathML"/> </dpd>
was registered against the text/html media type, the following would result in a DOM with html and body elements in the XHTML namespace and an input element in the XForms namespace:
<html> <body> <xf:input ref="xyzzy">...</xf:input> </body> </html>
The theme photo for W3C presentations at the TPAC09 showed the Natural Bridges state beach of Santa Cruz, California. We met in Santa Clara (not far from Santa Cruz) 2-6 November in order to bridge various communities and bring them together. For example, bringing together the HTML 5 browser folks and the extensibility folks was a goal. We joked this goal was called "Unnatural Bridges".
Broadening the W3C community was one of the themes of TPAC09, and was reflected in talks as well as participation.
For the first time ever, we invited the public to gather for an afternoon of discussion and networking, the Developer Gathering (the minutes are now available). Ian Jacobs aligned fantastic speakers who regaled us when they presented the latest on various open standards in development. Feedback from the #w3cdev demos included many "very cool", "absolutely amazing", "video element", "impressive", "geolocation", "accelerometer", "APIs", "nice possibilities", "features".
I thought the event went very well and think W3C should organize more. Please let us know what sort of event would appeal to you (e.g., with speakers as we had this time, or more like a bar camp, or a mix). If you blogged about #w3cdev, please, share a pointer in a comment!
TPAC is our biggest yearly event. Each year about 300 people who participate in various W3C groups meet face-to-face to exchange ideas, resolve technology issues, and socialize. My sense is that for most people involved, TPAC is their favorite W3C meeting of the year.
We tracked micro-blogosphere feedback on #tpac09. We expanded the number of people we follow (I'm not yet quite caught up with the additions I wanted to make, so excuse us if we're not yet following you). Likewise, at the occasion of TPAC and the Developer Gathering, a significant number of people also expanded their contact list and started to follow us (yay!). In Santa Clara @dckc said, '@w3c has ~5000 followers'. This is still growing, ~6300 now!
A bit of a mystery to me as I reviewed the tweets is the unicorn meme. I have no idea who started it and why, but unicorns were mentioned, portraited (it even made it to our theme photo!), tweeted, and interjected.
Oh, and I mentioned werewolves in the title. Although not (yet) a resident on our meetings agenda, Werewolves attacked the villagers almost every night at TPAC! Led by fantastic emcee @dontcallmedom, many people enjoyed the battles of minority against majority, the games of suspicion, trust, lies, doubts and beliefs. Nightly werewolf encounters are such fun in person.
If you attended TPAC09 and would like to give feedback, we'd appreciate if you took the WBS survey. I welcome additional feedback, or a pointer to your blog entry in a comment to this entry.
]]>This cheatsheet aims at providing in a very compact and mobile-friendly format a compilation of useful knowledge extracted from W3C specifications — at this time, CSS, HTML, SVG and XPath —, completed by summaries of guidelines developed at W3C, in particular the WCAG2 accessibility guidelines, the Mobile Web Best Practices, and a number of internationalization tips.
Its main feature is a lookup search box, where one can start typing a keyword and get a list of matching properties/elements/attributes/functions in the above-mentioned specifications, and further details on those when selecting the one of interest.
The early feedback received both from TPAC participants after the demo and from the microblogging community has been really positive and makes me optimistic that this tool is filling a useful role.
This is very much a first release, and there are many aspects that will likely need improvements over time, in particular:
The code behind the cheatsheet is already publicly available, and I’m hoping others will be interested to join me in developing this tool — I’m fully aware that the first thing that will need to get others involved will be some documentation on the architecture and data formats used in the cheatsheet, and I’m thus hoping to work on that in the upcoming few weeks.
In the meantime, I very much welcome bug reports and suggestions for improvements, either by private email to me (dom@w3.org) or preferably to the publicly archived mailing list public-qa-dev@w3.org.
]]>I will be hosting the gathering (5 November in the afternoon). We've planned for some fun give-aways to be revealed at the meeting. Registration closes today, although we will admin walk-ins at a higher rate next week.
If you can't join us in person, you can follow the meeting on IRC; more details are available on the meeting page.
I hope you will join us next week.
]]>We are working on these fixes. I also welcome fix suggestions from the community. Thanks again to those who have sent comments to site-comments@w3.org
]]>Comments are flowing in, some touching on issues we identified when we announced the beta version. Here are a few:
There are also a few rendering issues we are aware of and plan to fix over the next few days. Please tell us about any issues you encounter on site-comments@w3.org. Please be sure to tell us the URI of the page in question and what browser and OS you are using.
]]>