On 12/7/2011 9:45 AM, Dimitri Glazkov wrote:
On Wed, Dec 7, 2011 at 9:01 AM, Charles Pritchard<[email protected]> wrote:
On 12/7/11 7:36 AM, Dimitri Glazkov wrote:
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchard<[email protected]>
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
