- From: Charles McCathieNevile <chaals@opera.com>
- Date: Wed, 01 Aug 2007 13:50:20 +0200
- To: "public-html WG" <public-html@w3.org>
On Tue, 31 Jul 2007 03:22:37 +0200, Karl Dubost <karl@w3.org> wrote: > Le 31 juil. 2007 à 07:01, Maciej Stachowiak a écrit : >> My personal conclusion is that both retained-mode and immediate-mode >> graphics are useful. I'd guess that browser implementors largely agree, >> since Opera, Firefox and Safari* are all supporting both SVG and Canvas. > > Yes I guess that both things are useful. There are two issues which > Robert Burns started to address. > ... > * authoring (declarative versus programmatic) This thread shows a couple of things. One is that user agent developers do have a lot of power over what HTML is. Why the shock? On the web, people author around IE's old box model. They optimise sites for Nintendo Wii, iPhone, or Opera mini. They deal with strange behaviour in Netscape 4. So whatever HTML *should* be, what it is includes a huge amount of recognition (in terms of code volume) that user agents are the bedrock requirement for most "normal web developers" (note that this doesn't apply everywhere, but I don't think that matters). There are, as Maciej pointed out, use cases for both canvas and SVG - and three browsers are introducing the two in parallel. (I won't go on about the use cases - I think both technologies have proven support. If you want to see more canvas, have a look at the most popular Opera widgets. If you want to see more SVG, have a look for things that try to be accessible, and think about how they can do it). In other words, including canvas is really about paving emergent cowpaths - ones that were so clear to the people framing HTML 5 in the WHAT-WG that it is not easy to find out now how this came about. It seems perfectly justified to me (although I have grave concerns with the way authors will provide accessibility, and believe that the current pattern were most canvas authors just don't bother will continue :( ). It also highlights a disconnect in the group about how to handle accessibility. (The original point of Lachlan starting this thread was to show we have effectively treated canvas the same way as, for example, the headers attribute, so I claim this is on topic). There are a lot of accessibility features in HTML 4 - and most of them are used in a minority of cases, often badly or wrongly. I think the disconnect comes from the way accessibility works in practice. People with disabilities often cannot do some things that others take for granted. Simple stuff, like shopping at your favourite site, listening to music with your favourite music player, reading the newspaper, voting, paying taxes, applying for a job, using a browser. In some cases, most things do not work, in others a few. When your life is circumscribed by such problems, everything that *does* work is valuable. And the web has, in a number of cases, opened a huge range of new options to people, since one shopping site that gives access makes up for any number of competitors that don't (and as any free-market zealot knows, two such sites that are run independently will improve things even more - even in a situation where another ten thousand sites are not available). So "design for universal access" really has two aspects. One, quite correctly understood by nearly everyone, I think (although naturally with varying interpretation in a given case) is to make HTML 5 support better accessibility in the future. The other, which leads to so many problems, is not to rip up the few carefully laid flagstones that have often at great expense been put down on the boggiest patches of common cowpaths. Don't, for example, kill off something that is only used by the handful of people who will do anything to be accessible, since there are people who really really need it. Even if it only works on a handful of UK government sites, in a couple of browser/AT combinations, and therefore has an audience of about 100,000*, something that does provide accessibility and doesn't actually seriously break the web is generally worth keeping even where 80% of the usage fails to achieve the goal. This is not the same as saying "don't fix it". It is just saying "don't break it while we are experimenting with a new answer", since you cannot guarantee that the fix will work, and destroying a handful of things people rely on in exchange for some new ideals, however much we believe that they will lead to improvement in overall accessibility, isn't a very helpful thing to do to people. cheers Chaals * A conservative guess at how much a given feature is usually worth today based on the fact that the UK is the best at getting these things deployed sensibly, and .5% of the population might be expected to benefit from anything I thought of in about 3 minutes reflection. Research from Forrester done for Microsoft claims that overall accessibility requirements assist about 2/3 of *all* Microsoft's users, so we are not necesasrily talking *overall* about small concerns). -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com Catch up: Speed Dial http://opera.com
Received on Wednesday, 1 August 2007 11:50:46 UTC