Re: [Component Model]: Decorators and Fallback Content

On 12/7/2011 9:45 AM, Dimitri Glazkov wrote:
> 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:
>>>> 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.

I called it a component to try to avoid confusion. Didn't work! If you'd 
prefer, I'll call it an interactive canvas element or a canvas widget.

And while I understand the nature of your suggestion, I'm talking about 
existing implementations.

Yes, when the Component Model is available and implemented, we'll have 
another option to use with <canvas> based interactive widgets.

It's been my position that the existing practices of the <canvas> 
element are a helpful topic in understanding the needs of Web 
Components. It's also my position that canvas should be heavily 
considered in the design of web components, and that web components 
should be heavily considered in future discussions about canvas. I 
intend to bring them up in public-canvas-api when Web Components is a 
little further along.

Again, I apologize for the miscommunication here, I only intended to 
bring up a single issue, CSS "appearance".

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

The problem is that it is a kludge to view alternate content. IE9 is the 
only browser that makes it easy on me, and it makes it easy because in 
their developer tools I can switch to IE8-mode, where Canvas was not 
supported. The other problem is that I would like to use CSS media 
selectors to show the fallback content, instead of the canvas painting, 
in some circumstances. While I can do a bunch of DOM mutations, it makes 
a lot more sense to have a pure-CSS option.

Additionally, projects like NoScript do not show canvas fallback 
content. This would make it easier on the authors of Noscript to do so, 
via simple CSS.

I'm trying to introduce an easy to use method for showing fallback 
content in advanced controls: in HTML5.
HTML4 did not really have this issue. It was there, but not such a big deal.



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

appearance: none, will affect the presentation as well as width and 
height of the element.
It has similarities to the <template> proposal.

While it's not so apparent on Windows, it's very apparent on OS X, with 
input type=submit.

The semantic was created (I believe) prior to Canvas. It's not yet been 
applied. So I'm suggesting that we extend its meaning, because it's a 
close fit.

This says, use the CSS I've put in the document and forget all that 
fancy upgrading of the element:
input type=submit style=-webkit-appearance: none

That seems an appropriate semantic for doing the same with <canvas> and 
<audio controls>.


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

Putting live elements into the DOM tree with Canvas is becoming a best 
practice. It ensures that the semantics of interactive elements are 
available in the DOM.

This is how we ensure WCAG can be met.

The solution you outlined earlier is a proposal based on an draft in 
progress. I think it's very important to ensure that <canvas> works well 
with your proposal, but that's secondary to the topic I've brought up, 
about supporting the fallback content in Web Components AND Canvas. 
Canvas is currently deployed on the web, and requires [compliance is 
another issue] that implementers support the sub-tree.

I do recommend you catch up on Canvas: it's an interesting precursor to 
Web Components.

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

I believe many of your questions are addressed here.

-Charles

Received on Wednesday, 7 December 2011 18:12:32 UTC