Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

> I've never found is confusing. Not elegant, hacky, everything but confusing, really.

In and of itself `is` is no more confusing than `<p>` or `<hr>`, or any of the other atomic self contained entity.  

But developers working with custom elements are expecting them to behave as lego blocks that can communicate, encapsulate native dom elements, and be backed by javascript classes that are effectively the custom element's controller.  The `is` attribute breaks this paradigm, and that is going to lead to horrible UX and subsequent confusion.

> Other buzz words are just developers choice, as you can see they love confusion so they create thousands slightly different bundlers while HTTP2 idea is to not need them at all.

I love HTTP, but it's still half baked.  We need AOT compilers etc. for Angular 4 (If you want the best production build) and the browser runtime environment has to support it universally in order for it to be a great solution for all of us, so it's a ways out.  Also tools like Rollup have to be run in order to minimize the module sized, which is likely to be a requirement even with HTTP2.

> However, this stat about 0.00...1% is confusing, and I've no idea where does it come from.

Well for example just look at the number of downloads of angular material and various other angular components / directives / pipes, and other related angular 4 on NPM.  For example here's Angular HTTP:

https://www.npmjs.com/package/@angular/http

**20,000** downloads in the last day and  **1,289,089** downloads in the last month.  This is brand new stuff and these are already the stats.  The stats are roughly the same for angular router.
https://www.npmjs.com/package/@angular/router   

That means that developers are looking to create pages with very advanced capabilities.  The `is` attribute concept simply does not have a home in any of these environments.  If there were a few components on NPM that supported the `is` attribute we could do a head to head fairly accurate statistic on what the application / page ratio of environments using `is` is.

> I've written examples and fixed transpilers, promoted and advocated Custom Elements with or without the rest of the Web Components family for years, and I keep feeling their limited application.

That's fantastic and I applaud it.  We need more of that.

> You can invent new things but never improve what's there.

I think everyone here wants to improve what's there.  We have to make sure that what we are improving works well for everyone though.

> To do that, you need to ignore vendors and specifications and target directly nodes or their prototype.

I think a different way of saying that is that we need to think out of the box.  I'm all for it.  Ultimately thought the semantics we produce have to play well with the whole.

> Like I've said already, I'm OK with that, I just wish we could've found a better agreement here.

I play a lot of soccer and I'm constantly amazed how difficult it is to get team members to act in everyones best interest.  Indoor games should be 2 minute shifts.  Go out, play hard, get off.  Yet some guys stay out there dead tired and hog a bunch of play time.  So then the rest of the guys say "Well screw it - I'm staying out there too", and so we end up with some par performance.

There are a few things getting in the way right now.  One really simple thing that we have to stop pretending is true is that `is` helps with accessibility.  It's not going to because the number of apps and pages that are going to be produced without any `is` attribute is going to be the ocean and the few that will contain the `is` attribute is going to be a few drops and therefore pretending that `is` solves accessibility is actually putting accessibility technology behind.  The `is` is not a magic bullet for accessibility. 

@trusktr has put forth a lot of sensible API recommendations that are both elegant and seem to make a lot of sense as far as extending native elements go.  We should be drilling into that more.  This is code and we can bend it any way we want.  We can be happy once we get the best result.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/509#issuecomment-302924329