W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [Component Model]: Decorators and Fallback Content

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 7 Dec 2011 07:36:43 -0800
Message-ID: <CADh5Ky0iYJeMzzZpFSLZDLV+YEbtGVsBKzUkP6PTGZUsHOKHJQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC