Re: Canvas and ARIA alternatives

On Tue, Aug 7, 2012 at 11:03 PM, Ian Sharpe <isforums@manx.net> wrote:
> 1. At a glance, I suspect the kind of styling available via this particular
> library is probably achieveable using CSS3, such as gradient backgrounds.

Some of the stylings yes, some of the stylings no. The library
provides a common API and uses a common implementation in both
situations.

> 2. If there is such demand for more fine-grained control over the appearance
> of standard elements, not currently available through CSS, surely it would
> be more sensible to extend what is possible through CSS to achieve this? I
> can already hear some saying that CSS would become even more bloated and
> there will always be something that somebody wants to be able to do that
> would be too complex to implement. But what is worse, encouraging people to
> abuse elements to address a perceived shortfall in existing standards and
> then having to spend significant time and resources trying to work out how
> to deal with the fallout from an accessibility perspective? Or extending CSS
> to provide more control and flexibility in appearance using a well
> understood and accessible presentation model?

"Shipping code wins".

http://diveintohtml5.info/past.html

First, W3C has little influence with which to encourage or discourage
content developers.

Second, there's no value in working on existing _standards_, as
opposed to working on existing features actually in use. Whether
something is "standard" or not has little impact on the web corpus.
Witness the sad history of the <embed> and <object> elements.

Third, W3C has little influence over the feature development agenda.
When W3C blocks interoperability by failing to work on specs that have
market interest, the internet routes around that damage and the specs
get written elsewhere. For example, when W3C was hopelessly pushing
XHTML2, the community went to WHATWG and continued work on HTML. W3C
has a tiny staff and specs, tests, and implementations are all mostly
developed on by (a still insufficient number of) people outside by the
W3C, who tend to work on features of interest to them or their
employers.

> Or to think about it in a different way, if you take this approach to the
> extreme, there's no reason why the entire web couldn't end up using the
> canvas as the primary user interface. Kind of a world away from the semantic
> web.

Indeed, that could happen.

I happen to prefer the traditional layering of style and behavior on
top of semantic markup over the <canvas> approach, I would like to see
the traditional layering enhanced with new features to enable wider
customisation of look and feel. This is actually a not uncommon
preference in the community working on these specs. For example, the
WHATWG HTML editor Ian Hickson has long been vocal about improving
contenteditable rather than adding features for trying to building
purportedly accessible rich text editors in canvas.

However, actually providing such features is hard. That's partly
because with <canvas> backings, you can leave the visual rendering to
content developers rather than defining a new rendering feature and
precisely how it interacts with all the other rendering features. This
complexity is an important reason why progress on specifying CSS is so
very slow.

The idea that we can do it all by extending CSS is proving naive
because user agent implementations of native controls are often very
different to reflect platform norms. The feature development community
has already had one go at defining features for writing custom widgets
(XBL2) and it tanked. People are now working on web components, maybe
that will prove more effective in the market.

Anyway, there's little progress on CSS form styling capabilities. If
someone wants this, they need to step up and work on implementations,
tests, and specs.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 8 August 2012 07:24:46 UTC