> On Jun 8, 2015, at 3:23 PM, Alice Boxhall <aboxh...@google.com> wrote: > > On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa <rn...@apple.com > <mailto:rn...@apple.com>> wrote: >> >> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall <aboxh...@google.com >> > <mailto:aboxh...@google.com>> wrote: >> Web developers are already writing their own "custom elements" as a bunch of >> nested div's. How does introducing custom elements make it worse? > > I believe the rest of my comment already addressed this.
Sorry, I don't follow. >> >> - I realise that to some extent developers already aren't using native >> >> elements, in part because of the styling issues we've discussed which >> >> also affect is=. My concern here is that custom elements will further >> >> legitimise this habit, which we've been making some recent progress in >> >> changing - we stand to backslide on that effort. Having is= would allow >> >> us to roll it into the "use native elements where possible" message >> >> rather than diluting it with "unless you're using a custom element in >> >> which case here's a checklist which you're not going to look at of >> >> everything it should do" until we come up with an alternative. >> >> In the case of stylizing elements, it doesn't really matter if authors >> attach a shadow DOM on top of a builtin input element or to a div because as >> soon as the shadow DOM replaces the rendered contents, we can't make >> assumptions about how to expose that element to AT. > > That's simply not true at all. If someone replaces the rendered content of a > `<button>`, we know that their intent is to create an element which is > semantically a button, and may even be rendered as a button in some cases. > Similarly for `<input>` with a `type` attribute. This is no different to > using an ARIA role as far as assistive technology is concerned. Perhaps I should have said "we can't _always_ make assumptions about how to expose that element to AT." Consider creating a date picker in the time we haven't added type=date yet. Inside the shadow DOM of this color picker may contain various buttons and controls to move between months and pick a date. Treating the entire control as a text field will provide a very poor user experience. All the use cases I can think of that let UA can safely make assumptions about the ARIA role of the element involves tweaking the appearance, which is better served by better styling mechanisms for form controls. > >>> The way I look at this is that currently you have nothing, since only > >>> Chrome ships this. There's a chance to get three more browsers if you > >>> make some concessions on the warts. And then hopefully we can iterate > >>> from there in a more cooperative fashion. > >> > >> Here's where we differ, because: > >> - I don't think it's a wart. I've given this a great deal of thought and I > >> keep ending up back at the current syntax when I try to think of > >> reasonable alternatives, even assuming we could magically fix all the > >> implementation issues with any alternative proposal. > > FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) > spec'ed. > > Any chance you could go into more detail on that? What exactly is it you > dislike about it? See our replies on the topic on public-webapps. I don't have a time to collect all our replies or restate all the problems we have with is= syntax. (Perhaps I should put up a document somewhere to reference since someone brings up the same question every six months or so, and I'm getting sick and tried to even say that I don't have a time to re-iterate the same points over and over...) >> >> - I don't think shipping in one browser is "nothing". People (both >> >> framework authors and web page authors) are already writing code using >> >> is=. >> >> Some developers are always going to use a feature only implemented by a >> single browser (ActiveX in Trident, NaCl in Chrome, current web components >> implementation in Chrome). In fact, why would any browser vendor ship a >> feature that's not going to be used by anyone? However, that doesn't mean >> the feature will be standardized or adopted by other browser vendors. > > No, but unlike the first two examples, this is a proposed web standard. Well, not everything people propose as a standard becomes a standard. When a proposed standard is rejected, however, people tend to come up with an alternative proposal to address those issues. As far as is= syntax is concerned, I haven't heard of any proposals to "fix" it so as to address everyone's concerns. If you're really passionate about this feature, I suggest you can go dig all the discussions we've had in the last three years and see if you can resolve all the concerns raised by various participants of the working group. Now, some of those concerns we and others have raised may not be relevant, and they may have changed their positions and opinions on matters. Regardless, I don't think keep saying you like (or that you think we need) this feature without proposing "fixes" to raised concerns is productive. - R. Niwa
