Re: [Component Model]: Decorators and Fallback Content

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 ...
</div>

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

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

//...

</script>
<template>
<canvas></canvas>
</template>
</element>

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,
though.

>
> 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