And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like <template> and <style>.
On Mon, Jun 8, 2015 at 2:16 PM, Alice Boxhall <aboxh...@google.com> wrote: > Did anyone have any further thoughts on this? My concerns haven't changed. > > On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall <aboxh...@google.com> wrote: > >> On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren <ann...@annevk.nl> >> wrote: >> >>> On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall <aboxh...@google.com> >>> wrote: >>> > I definitely acknowledge is= may not be the ideal solution to the >>> latter >>> > problem - it definitely has some holes in it, especially when you start >>> > adding author shadow roots to things - but I think it does have >>> potential. >>> > I'd really like to be convinced that we either have a reasonable >>> alternative >>> > solution, or that it's not worth worrying about. >>> >>> I think it is worth worrying about, but I don't think it's worth >>> holding up a minimal v1 of Custom Elements for. The way to get >>> agreement among all parties is to do less. And then take baby steps >>> from. >>> >> >> I can definitely see that logic. >> >> My concerns with this in practice are: >> >> - In the time between v1 and v2 (however long that ends up being) we are >> left without any way to solve this problem, assuming we don't come up with >> something else for v1. If developers start using custom elements where they >> would previously have used a native element, this could well result in a >> regression in accessibility for the web as a whole for this period, and we >> will be stuck with the legacy of code written during this period for much >> longer as well. >> >> - 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. >> >> - v1 sets the stage for people to develop habits and expectations about >> how custom elements work. New features tend to be slowly adopted, by both >> browser vendors and (partly as a consequence) developers, so even if we do >> come up with something for v2, it will be even longer before it becomes >> mainstream (and as I mentioned earlier we will still be stuck with code >> written to v1 for much longer again). >> >> >>> 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. >> - I don't think shipping in one browser is "nothing". People (both >> framework authors and web page authors) are already writing code using is=. >> >> >>> (The thread Steve shared about ARIA seemed like an equivalent effort >>> by the way, to expose some of the semantics of native elements through >>> simple attributes.) >>> >> >> Thanks for the pointer - I followed up on that thread with some thoughts >> on that proposal. >> > >