Re: [Component Model]: Decorators and Fallback Content

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