On Dec 5, 2013, at 7:38 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 12/5/13 4:30 AM, Ryosuke Niwa wrote: >> As I understand it, people want to do: >> >> <select name=cities is=map> > > That's not the main issue being discussed right now, as far as I can tell.
Sorry, I should have been more explicit in my email but I intended to ask specifically about using web components for styling control elements. > What's being discussed, I think, is that people want to do things like: > > <input type="date"> > > and then style the datepicker in some particular way. Right. WebKit (and quite possibly Blink) exposes some special pseudo elements to do that kind of stuff: http://trac.webkit.org/wiki/Styling%20Form%20Controls My initial thinking was that we could be standardizing some of these pseudo elements. And accessibility works great if we did that because AT could simply ignore (some) styles. But I've heard an argument that this is not flexible enough, and we should be using Web components to solve this problem. The problem, however, is that: On Dec 5, 2013, at 7:58 AM, Scott González <scott.gonza...@gmail.com> wrote: > Given <input type="date">, we want to keep all of the semantics (the APIs, > built-in validation, etc.), but apply custom styling. Custom styling may come > in the form of CSS or it may come in the form of a completely new UI that > uses JS. The latter may or may not use shadow DOM. But the important thing is > that we don't actually want to create a new element type, we want to leverage > the existing ones. To complicate this further, we may want to just leave it > alone in some devices because the native behavior is already optimized. > Unfortunately it's hard to tell when that's the case. Precisely. Consider mobile browsers for example. When mobile browsers initially came out, many websites in the wild didn't take mobile browsers into account. In that world, we would like to replace the UI of all custom form controls. However, as the Web evolved to support mobile usage, a lot of websites started having mobile versions and UI specifically designed for some mobile operating systems. Unfortunately, web components doesn't give us some magical mechanism by which UA determines that a certain custom form control should be replaced by a native control. Furthermore, we can't simply "replace" custom element with a native form control if the custom element could provide some JS API because that'll be exposed to the rest of the page. We can't just swap the "UI" or what's being exposed to AT without changing what's being displayed on the screen since some ATs such as Voice Over needs to highlight what's been focused, etc… on the screen. I'd love to solve this problem because I deeply care about accessibility but I don't think using shadow DOM magically solves it. - R. Niwa
