- 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