- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 10 Sep 2011 12:43:34 -0700
- To: Chris Baker <chris.baker.gr@gmail.com>
- CC: public-html-comments@w3.org
- Message-ID: <4E6BBDE6.9020309@jumis.com>
On 9/9/2011 9:16 AM, Chris Baker wrote: > Simply in the way of comment, this situation is quite dismaying. I > fear that the less organized and stable the working groups and the > process of maintaining and generating the spec becomes, the more apt > vendors are to become inconsistent in implementation; this will > directly result in fewer developers adopting any of the new spec in > the short term. Moreover, I think the participation of Microsoft in > the specification and adoption may potentially be one of the single > greatest boosts to innovation on the web - the hours and dollars > wasted on implementing cross-browser code can instead be spent on > forward development. If this process or the spec itself cannot be > organized, professional, orderly, and business-like, I fear vendors, > especially Microsoft, are going to see the incentive to play ball > diminish and we'll have another 10 years of continued dual- (or > tripple- or nightmare quadrupal-) development ahead of us to make this > stuff work in the various user agents. Taking ONLY that into > consideration, I view this entire specification and process as a > pivotal moment for the web as a whole, and to lose this initiative > means stagnation for years to come. Calm your fears! <smile>. Having followed vendors closely for the past 5 years, while I develop, I can tell you that things continue to work-out-well for browser interoperability. Microsoft has been very supportive of the web standards, and continues to catch-up to the newer more powerful web-side specifications: http://html5labs.interoperabilitybridges.com/ They continue to be the leader in ARIA support, with Mozilla a close second. They're playing ball. Webkit and Opera are both, very much invested in w3c specs. I've only seen a convergence, when it comes to these specifications, despite there being so may new specs on the table. There have been instances where vendors do have to go-it-alone. I think that Apple-WebKit is a prime example. These have not been particularly harmful, as vendors tend to catch-up. I believe the developers on all browser teams are aiming more for convergence, than for forking. The majority of Apple's innovations have made it into the other UAs. > I am loathe to make this comment; I am hardly highly-involved, I feel > like the peanut gallery. But I think I can say that I speak for a > significant number of developers when I implore, urge, beseech and beg > you as a group to take the necessary measures to pull this process > back together and give us something we can rely on. I'm game, I've > started putting the more stable elements of HTML5 out there on my > client pages, I'm teaching new developers about the newer spec and > encouraging adoption in any way I can. I look to the WHATWG *and* w3 > to be the leaders here; we "field developers"" are literally at your > mercy. All the current momentum is not lost, there's a workable > specification in all those documents with nothing less than the future > of the internet hanging in the balance - this is not melodramatic to > say. Your work is important, I appreciate all that has been done and > look forward to a return to order! Let's examine balance: Editors: Tab Atkins: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html "The editor is the *lowest* level in the hierarchy of constituencies" Ian Hickson: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1277.html "As editors we must be willing to throw away efforts when it becomes clear that they are not the best solution for the Web" http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0021.html "make an API for these features that addresses the needs I listed ... and assuming that browsers would be willing to support them, then there's no question that we'd add them to the spec." Aryeh Gregor: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/030041.html "Sometimes features get added without implementers' support, but don't rely on it. If it gets implemented, on the other hand, you can be sure someone will want to spec it, so that interoperability doesn't suffer" http://annevankesteren.nl/2011/07/editor "my time is my own or my employer's, and no one else has any right to place demands on how I spend it... I simply do not agree that I have any moral obligation to let the W3C or anyone else tell me how to spend my time." Vendors: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029133.html "I have approximately zero faith in JS coders and HTML coders doing things 'right', after fairly extensive exposure to the results of their work... My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely because it's not quite as mainstream yet, so only the more competent folks are doing it." http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0069.html "A million developers doing a million different things will mostly do things wrong when the correct solution requires extra effort and doesn't have immediate visual or functional feedback telling you if it's working or broken." http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0032.html "a much better way to address the problem of canvas text editors not being accessible ... is to discourage authors from building them in the first place." http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0039.html "rather than trying to hack accessibility onto a feature so that it may be used for something it was never intended to do, you should detail the missing functionality that you want/need from the normal text editing machinery" http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0080.html "I've talked with several WebKit engineers here at Apple... the consensus is that adding retained-mode features to the Canvas API is not something we're interested in." http://lists.w3.org/Archives/Public/public-html/2011Jun/0351.html "Microsoft considers SVG to be the correct way to do retained mode graphics" http://lists.w3.org/Archives/Public/public-html/2011Jun/0339.html "Why is 'use SVG' not sufficient for this?" Balance: The balance is very-much on the side of big vendors. That's fine, they have the money, they invest in their browsers, and in some cases, the browsers are open source and we're able to submit patches. With a project like WebKit, I know that I could invest into a proposal, submit it for webkit review, and from there, likely into a specification. Currently, none of the big boys are making Canvas applications. Google has their sketching program in docs, written for SVG targets. Microsoft barely uses Canvas, though they are at least interested in accessibility on its own means. Apple lives in its OS stack, they define the language and the accessibility. They recommend coding in Objective-C. ;-) The reason I bring that up: vendor priorities are very much driving these processes. Google's decision to enter into the browser market is a primary force for them to enhance their own service offerings. By rapidly introducing APIs which suite Google products, they are able to cut costs, and increase the attractiveness of their services. If a service has a need, lets say Gmail needs better support for file attachments, Google has a browser, a hook into WebKit upstream, and several people working on W3C specs. They get what they want. If Apple has a need, well they just add it into their browser and let the specs catch up later. We can't do that as developers. Now that the Web Apps have reasonably caught up to traditional desktop technologies, there are hundreds, perhaps thousands, of independent companies creating their own client-side web applications; desktop development-style. This is a power shift in itself. Where traditional development has been document-centric, with little pairings of interactivity, web application development is tool-oriented; it's about creating a consumer of documents, instead of creating documents. It's about creating user agents inside of the browser, user agents that process documents. A document may be viewed for minutes, and then the next document is brought up. A user agent may be open for hours, as the user moves through multiple documents. Web application developers are creating user agents inside of the browser, as they support whatever processes their product is intended to. This is in conflict with the notion that the browser vendor should be the only user agent present. When this conflict is internal to a company, it gets resolved. When it's external, we have a really bad situation. Look at IBM, there's a vendor that did not jump into the browser fray. Now they have an issue: "the first time I mentioned canvas to an IBM product team the first word out of their mouth was: 'Cool, we can create a new custom UI on the existing standard controls!'". Though they have contributed to the w3c, to Webkit and to Mozilla, they are in a bit of a bind on meeting WCAG levels. If they had done what Google had done, and put weight as a browser vendor, they could just do what Google does, what Apple does, and add in the methods they need to meet their business requirements. Instead, they have to sit and wait. Because, they are developers, not browser vendors. Browser vendors maintain the utmost control in this process. They are aware of that control, and they are using it to their advantage. And that's perfectly reasonable. But, they can use that control in a manner that is anti-competitive. In a manner that says to developers: "sure, you spent hundreds of thousands, perhaps millions, in authoring. Go ahead and rewrite all of that... it doesn't fit within our idea of correctness." In point of fact, it doesn't fit within their current product offerings and internal procedures. That's the issue. It benefits them to block such innovations, as a tactical business advantage. Let's go back to Mozilla: they now have an offering, a PDF viewer written in JS, which acts as a user agent within a user agent. Now, unlike last year, and the year prior (remember bespin), that behemoth has a reason to look into developer issues again. Should Google, should Apple, find that they too want to write a user agent, perhaps to re-write a PDF viewer in JS, they too will change their tone. When they need to meet federal standards for accessibility, and they find that their APIs are insufficient, it will no longer be a protracted argument about the merits and correctness of things. They'll simply add the APIs, and that will be that. Many of these spec editors are employed by very self-interested corporations. And in free market style, things are, mostly, working out for all of us. The W3C is, I believe, intended to assist the members that do not develop their own browser implementations, to assist them in working with members that do. That is where I would like to see attention, in this unfortunate power struggle. Work on accessibility is blocked continually, in large part, by Apple and by Google, who have little interest in maintaining compatibility with Windows, or with old applications, or with third party assistive technology. Little interest. When we work on the lists, this is relegated to issues of "correctness". The issue, really, is of relevance. The W3C should maintain relevance of its members and of developers; it continues cede that power to browser vendors; those vendors are manned by business savvy folk who realize that obstruction can be a tactical advantage in business. TLDR; Vendors have discovered that forking is expensive, a bad business choice. Hurray. They've also discovered that selective inclusion and obstruction is rather cost effective, giving them competitive advantages. A great business choice. That, unfortunately, hurts developers, ranging in size from megaliths such as IBM, to non-members such as Wacom, and individual developers, such as myself. -Charles
Received on Friday, 9 September 2011 19:41:40 UTC