- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 7 Dec 2011 07:36:43 -0800
- To: Charles Pritchard <chuck@jumis.com>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchard <chuck@jumis.com> wrote: > 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> > That's not a decorator. That's a custom element. They are very different. Did I fail to draw enough distinction in the explainer? > 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. Yep, except s/decorator/custom element. > > Now let's take a look at Canvas components: What are 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. Why would you need to reach there visually? I think I am lost. > > 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. What are you trying to accomplish? Can we start with that first? > > 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 15:37:15 UTC