Re: [Component Model]: Decorators and Fallback Content

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>

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

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

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 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:02:19 UTC