Hi Anne, I have not suggested is= as the method that must be implemented (I have not demanded anything), what I have tried to suggest is that minimum viable custom elements with all accessibility as bolt-on is a poor solution by design. From an acc view it means custom elements are nothing more than <div>s with fancy names.
-- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 16 January 2015 at 13:16, Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner > <faulkner.st...@gmail.com> wrote: > > With custom tags everything must be bolted on, with type extensions this > is > > not the case. > > I don't disagree with this, but is="" solves none of the problems of > why developers moved away from native elements in the first place. As > long as styling native form controls is a problem, is="" is not going > to help us. In other words, is="" is not what is going to make Gmail > stop its <div> abuse to mean <button>. is="" solves none of the > problems for which ARIA was invented as a workaround. > > Furthermore, is="" has considerably worse developer ergonomics > compared to custom elements making it unlikely to be used much. > > > > It may be that it is too hard to implement type extensions (i freely > admit > > much of the discussion on this thread is over my head), but I do not > think > > that it should be dismissed out of hand or that the consideration should > > characterised as "longdesc mark II" ;-) > > is="" is not that hard. What is hard is making subclassing native > elements work with good developer ergonomics. Making the markup of a > subclass of HTMLButtonElement just as elegant as a subclass of > HTMLElement is. > > > -- > https://annevankesteren.nl/ >
