- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 07 Dec 2011 00:01:49 -0800
- To: public-webapps <public-webapps@w3.org>
TL;DR: How about supporting appearance: none for the <canvas> element,
and decorator as well.
The component introduces a "decorator: url(#url)" semantic to upgrade
elements while maintaining backward compatibilty.
Decorators can be applied in various manner, but this is where I'd like
to focus:
<button is="x-my-component">This is a button</button>
For a browser that does not support decorators, or if the decorator is
unavailable, that's going to turn into a standard button.
Great stuff. If the decorator is supported, we've got ourselves whatever
it is the component author intended. Good stuff.
Now let's take a look at Canvas components:
<canvas><button>This is a button</button></canvas>
This is no fun, how do I reach that fallback content, visually? There
are many means of doing it, but it's not as clean as I'd like.
And now a trip down memory lane. It was about five years ago I was
actively developing a form-centric application, it uses mouseover to
change the background color of some input buttons. I look silly now, now
that submit buttons can be styled by the user agent.
So, back to the future, I ought to add input[type=submit] {
-webkit-appearance: none; } to my old project, for a quick fix.
If you're with me so still, I've just ensured that the present Webkit,
let's say Chrome, for this example, will now render my input submit
buttons as defined in CSS, and not in the manner inherited by the
operating system. That's important for my mouse events, because the OS
rendered button is very different than the button that displays when CSS
is handling the task. If you have questions about this, ask, and I'm
sure we can hunt down some examples together.
And that takes me back to the <canvas> and decorator examples.
<canvas style="-webkit-appearance: none"><button>This is a
button</button></canvas>
That ought to go ahead and "hide" the Canvas element and show the button
element, as though Canvas were not supported. It shouldn't nuke the
Canvas context, but it should no longer be in the render tree. This
makes it easy to turn Canvas off and on, and to see that fallback
content. That's something I want in Canvas, and that's something I want
for decorators in the component model.
And since we're stuck with appearance: none, it seems like the right
semantic to pick up for this task. I think it's a good fit.
Also, CSS-UI doesn't want it -- and I think they're right in booting it
out. So I'm proposing that the Component Model pick it up.
-Charles
Received on Wednesday, 7 December 2011 08:02:21 UTC