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

> If your app breaks because a certain API is not available, you're doing progressive enhancement wrong.

So how would I progressively enhance my very simple app the right way?

> The argument that a feature doesn't have any advantages because it might break in old browsers could be made about literally any new browser feature and if we accepted that we'd never make anything new.

That's not the argument I'm making.  The first thing I try to do when convincing someone that a feature has clear advantages in terms of:
- Improving developer productivity
- Improving code maintainability
- Improving runtime efficiency and speed
- Reducing delivery time
- Improving user experience
- And in general just making overall components of the solution simpler

Is to come up with a really simple example that shows how it does this across the board.  I think custom elements, shadow dom, etc. all do this and they are complete no brainers.  However I personally don't see a application development scenario where the `is` feature is like "YES!!!! - Hallujah finally we have this feature!!!".

I provided a very simple application scenario that illustrates my thinking.  If @richardkazuomiller and @seaneking could come up with an equally simple scenario that illustrates what you are saying and causes us all to realize that the benefit of implementing `is` across browsers is a great thing, then that would be super helpful.

If I'm telling a team to consider progressive enhancement and specifically to use the `is` capability I need solid ammo, and right now I don't have any.  In other words I cannot lead a team and say "If you see this scenario or this scenario or this scenario, then use the `is` capability" to do progressive enhancement.  And by scenario I mean a simple example like the one I provided so that my team members have something concrete to go by / reference.

> @oleersoy in that scenario no, fancy-button wouldn't offer progressive enhancement

I think the point of progressive enhancement is that it's progressive.  From what @ebidel is saying there are two ways of looking at it.  One is that the API for using a component is simply not there so that the component falls back to a more lightweight way of operating.  It still works, just not with all the bells and whistles we would like.  In the other scenario, the API / native capability is there but the the browser or script has not had a chance to upgrade the element yet.  

So in this case it's not that the button is not offering PE.  It offers it because of how it is declared `<button is="fancy-button">`.

> because you're not progressively enhancing a button

That's true because that's up to the runtime (Although I have tried progressively enhancing a few things, but my wife always objects, so I've mostly given up).

> you're giving it core functionality that your app is broken without.

I think what you are saying is precisely what I'm trying to illustrate.  I have a button that can be progressively enhanced and two custom elements that form the entire app.  If those custom elements don't work, the app is broken.  So why then use custom elements at all?  We are assuming that the `is` capability is generally going to be blended with the usage of custom elements right?  Otherwise why have it in the v1 spec?

> Also prog enhancement is only one (admittedly very important) upside of type extension. Another is inheriting unreplicable native behaviours (eg: template, anchor, button, img, html, etc).

This I totally agree with.  I almost tattooed "Just wrap the element" on my forehead once, before getting more smarterer.  I would love to see one example that uses custom elements in a minimal and realistic app that demonstrates how `is` is better than just extending and creating a `<fancy-button`> using a more minimal API that excludes the `is` capability.

Again if there is one way to do it, and we say that we can also do it this way, then there should be some significant advantage over the next 4 years to doing it both ways.  Otherwise we are just introducing more stuff to learn about and make decisions with and possibly further complicate a already fairly advanced set of tools with a fairly steep learning curve that we use to produce awesome things and this does does not just waste our time, but the time of millions of developers, maintainers, product managers, and investors.

-- 
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-258636237