- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 7 Dec 2011 09:45:11 -0800
- 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 ... </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