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 09:45:11 -0800
Message-ID: <CADh5Ky2RkEnVtnBRnnrKON3MNdqme2EMjEw4kMiV09TcWasVtQ@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: public-webapps <public-webapps@w3.org>
On Wed, Dec 7, 2011 at 9:01 AM, Charles Pritchard <chuck@jumis.com> wrote:
> On 12/7/11 7:36 AM, Dimitri Glazkov wrote:
>> 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?
> Sorry about the confusion. I did not make the clear distinction of custom
> tags with templates and decorators.
>>> Now let's take a look at Canvas components:
>> What are Canvas components?
> A <canvas> element with usable fallback content.
> This is not a component:
> <canvas>You do not have Canvas, you Shall not Pass!</canvas>
> This is a component:
> <canvas>
> <legend tabindex="-1" for="button">The Big Red Button</legend>
> <button tabindex="0" id="button">Launch Missiles</button>
> </canvas>

Why is that a component? And why is there a <canvas> tag surrounding
it? I must have not been following some discussion somewhere. Is
<canvas> there to provide some presentational quality? If so, I would
write this like so using Web Components:

<div is="x-foobar">
<legend ...
<button ...

Then the "x-foobar" custom element is defined as:

<element name="x-foobar" extends="div">



In other words, put <canvas> in the shadow DOM, leave the meaningful
tags in the document.

>>> <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.
> I've repeatedly had cases where I'd like to show the sub-tree. While I can
> certainly do dom manipulation to accomplish it, in my experience, it makes a
> lot more sense and is a lot easier to use css.

>From my perspective, you're narrowing on a solution without first
stating a problem. Why do you need to show the subtree? Give me an
example? I am not trying to be a butt, just failing to understand what
you're trying to do.

> This is not solely about accessibility, though I do think supporting
> "appearance: none" would help developers work with their sub-tree.

To paraphrase the famous Princess Bride quote, I don't think
appearance: none means what you think it means. The effects of
-webkit-appearance are limited to painting. Extending it to mean
something else is probably going to be more pain than just adding a
new primitive. I am not sure if there's a need for a new primitive,

> It's a frustrating practice to need to intentionally break the canvas tag to
> debug in place:
> <not-canvas><button data-notes="I am now debugging my sub-tree">Tap for a
> treat</button></canvas>

I am still puzzled why you would want to stuff a live DOM tree into a
canvas, but it seems that the solution I outlined earlier should help
you here.

> I don't want to get too wrapped up in providing use cases: if it's an issue,
> I will being a more formal list in my next response. In general, I'd say the
> use is for debugging and for simply showing a plain view. It encourages
> authors to use semantic HTML appropriately.
> The ability to switch presentational modes is important. It's what CSS is
> all about, isn't it?
>>> 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?
> I want to "disable" these higher presentation layers via CSS.
> That's what happens with: <button style="-webkit-appearance: none" />.
> Custom decorations are dropped, and we go back into the past, a simpler
> time.
> I'd like to see appearance: none work with custom elements and canvas
> elements.
> It would benefit users, to be able to easily change the style sheet and I
> believe it would benefit developers, to be able to more easily debug, with
> dual-use of their markup.
> I think this should apply to <audio controls> as well;
> <audio controls><a href>My Music File</a></audio>
> That'd hide the controls and simply show the link, as though audio were not
> supported.
> I've been trying for some time to find a semantic to fit this use I have.
> CSS replaced content was not a good fit. "appearance: none" seems to be the
> right one.
> -Charles
Received on Wednesday, 7 December 2011 17:45:48 UTC

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