The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. #509

Closed
trusktr opened this Issue May 31, 2016 · 281 comments

Projects

None yet
@trusktr
trusktr commented May 31, 2016 edited

(copied from comment below): The is="" API can be confusing. For example (in current v0 API):

<my-el></my-el>
class MyEl extends HTMLElement { /*... */ }
MyEl.extends = 'div'
document.registerElement('my-el', MyEl)

// ...

document.querySelector('my-el') instanceof MyEl // true or false?

The spec says:

Trying to use a customized built-in element as an autonomous custom element will not work; that is, <plastic-button>Click me?</plastic-button> will simply create an HTMLElement with no special behaviour.

But, in my mind, that's just what the spec says, but not that it has to be that way. Why has it been decided for it to be that way?

I believe that we can specify this type of information in the customElement.define() call rather than in the markup. For example, that very same document shows this example:

customElements.define("plastic-button", PlasticButton, { extends: "button" });

Obviously, plastic-button extends button as defined right there in that call to define(), so why do we need a redundant is="" attribute to be applied onto button? I think the following HTML and JavaScript is much nicer:

<!-- before: <button is="plastic-button">Click me</button> -->
<plastic-button>Click me</plastic-button>
// before: const plasticButton = document.createElement("button", { is: "plastic-button" });
const plasticButton = document.createElement("plastic-button");

The necessary info for the HTML engine to upgrade that element properly is right there, in { extends: "button" }. I do believe there's some way to make this work (as there always is with software, because we make it, it is ours, we make software do what we want, and this is absolutely true without me having to read a single line of browser source code to know it), and that is="" is not required and can be completely removed from the spec because it seems like a hack to some limitation that can be solved somehow else (I don't know what that "somehow" is specifically, but I do know that the "somehow" exists because there's always some way to modify software to make it behave how we want within the limitations of current hardware where current hardware is not imposing any limitation on this feature).

@domenic
Contributor
domenic commented May 31, 2016

This was previously discussed at length in the other bug tracker, and it's explained in the spec in the sentence above that:

Customized built-in elements require a distinct syntax from autonomous custom elements because user agents and other software key off an element's local name in order to identify the element's semantics and behaviour. That is, the concept of customized built-in elements building on top of existing behaviour depends crucially on the extended elements retaining their original local name.

@trusktr
trusktr commented May 31, 2016 edited

@domenic That quote that you referred to makes me think exactly the same thing as I just wrote:

The necessary info for the HTML engine to upgrade that element properly is right there, in { extends: "button" }. I do believe there's some way to make this work (as there always is with software, because we make it, it is ours, we make software do what we want, and this is absolutely true without me having to read a single line of browser source code to know it), and that is="" is not required and can be completely removed from the spec because it seems like a hack to some limitation that can be solved somehow else (I don't know what that "somehow" is specifically, but I do know that the "somehow" exists because there's always some way to modify software to make it behave how we want within the limitations of current hardware where current hardware is not imposing any limitation on this feature).

You're pointing to something that exists in a spec, but I'm saying it doesn't have to be that way, specs can be modified. There is a solution (I don't know what that solution is specifically yet, but I know that the hardware on any computer that runs a browser nowadays isn't a limitation, and the only limitation is in the software we write, which can be modified). I simply can't understand why an HTML engine must need <button is="super-button"> (besides the fact that current algorithms require that) when clearly there's a JavaScript way to make the HTML engine understand that <super-button> means the same as <button is="super-button"> due to the fact we're defining that in the call to customElement.define.

I wish I had the time and resources to read the Chromium source in order to point to an actual solution (someone else can write the spec, as I'm not even good at reading those), but in the meantime, I'm 100% sure a backwards-compatible programmatic solution exists.

@domenic
Contributor
domenic commented May 31, 2016

Yes, everything is Turing machines and everything can be implemented. However, there are real-world constraints---both in implementation complexity and in ecosystem impact---that make it not desirable.

@trusktr
trusktr commented May 31, 2016 edited

Some things are complex to implement, but this particular change doesn't seem to be. :]

Would you mind kindly pointing to the complexity and impact that make it non-desirable?

Is it because if the element isn't registered (i.e. with JS turned off) that the browser won't know to at least render a fallback <button>? I think that's perfectly fine, because without JS the app probably won't work anyways, and I'm willing to bet that most people who will write JavaScript-based Custom Elements won't care if the app doesn't work with JS turned off. The Nike website doesn't work with JS turned off, and they care. Most people won't care. Developers who do care can just as easily use <noscript> and place a <button> in there, which makes much more semantic sense anyway.

What other reason might there be?

@trusktr
trusktr commented May 31, 2016 edited

When someone who comes from React tries to learn Custom Elements for the first time (which is more likely to happen than someone learning Custom Elements first due to the mere fact that specs are hard to read compared to things like React docs, unfortunately, because specs are meant for implementers, and the actual usage docs if any are sometimes limited or hard to find), they'll face these weird things like the redundant is="" form of extension and globally-registered custom elements that are not registered on a per-component basis.

This is what classes are for, and in the case of the HTML engine where multiple types of elements may share the same interface (which is probably a partial cause to any current problems) the third argument to customElements.define is there to clarify things. The is="" attribute is simply redundant and out of place from an outter API perspective (which may matter more than whatever extra implementation complexity there may be) because we already specify the extension in the define() call.

I'd take this further and propose that every single built in element should have a single unique associated class, and therefore ES2015 class extension would be the only required form of extension definition.

Just in case, let me point out we must currently specify an extension three whole times. For example, to extend a button:

class MyButton extends HTMLButtonElement {} // 1
customElements.define('my-button', MyButton, { extends: 'button' }) // 2
<button is="my-button"></button> <!-- 3 -->

That's three times we've needed to specify that we're extending something, just to extend one thing. Doesn't this strike you as a bad idea from an end-user perspective?

It should ideally just be this, assuming that there is a one-to-one relationship between built-in elements and JS classes:

class MyButton extends HTMLButtonElement {} // 1
customElements.define('my-button', MyButton)
<my-button></my-button>

I get what you're saying about complexities and real-world world constraints, but I think "breaking the web" might actually fix the web in the long run. There can be an API cleansing, and websites may have to specify that the new breaking-API is to be used by supplying an HTTP header. Previous behavior can be supported for a matter of years and finally dropped, the new API becoming default at that time. Sites that don't update within a matter of years probably aren't cared for anyways.

I'm just arguing for a better web overall, and breaking changes are sometimes necessary. It seems I may be arguing for this forever though. Unless I am an employee at a browser vendor, I'm not sure my end-user viewpoints matter much. The least I can do is share them.

@rniwa
Contributor
rniwa commented Jun 1, 2016 edited

The problem here is that UA internally checks local name e.g. element.localName == aTag to do various things, and all of that code needs to be updated to account for the fact there could be an intense of HTMLAnchorElement whose local name is not a.

Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.

@treshugart treshugart referenced this issue in webcomponents/webcomponentsjs Jun 6, 2016
Closed

V1 custom elements - missing functionality #551

@trusktr
trusktr commented Jun 7, 2016

The problem here is that UA internally checks local name e.g. element.localName == aTag to do various things, and all of that code needs to be updated to account for the fact there could be an intense of HTMLAnchorElement whose local name is not a.

I think that relying on element tag names might be a bad idea, especially if we give users ability to scope elements on a per-shadow-root basis (now that's a good idea!). If we can allow end users of a custom element to assign any name they wish to that custom element used within the user's component (within the user's component's inner shadow tree), then we can avoid the global mess that window.customElements will be when an app gets large and when people widely adopt Web Components (wide adoption is one of the goals here).

In React (by contrast) the creator of a component never decides what the name of that component will be in the end user's inner tree. The end user has full control over the name of an imported component thanks to ES6 Modules. We can encourage a similar concept by introducing a per-shadow-root custom element registration feature.

If we can map names to classes without collision and without two names assigned to the same class (i.e. without elements like <q> and <blockquote> sharing the same class), then we should be able to use instanceof instead of checking tag names, and element inheritance can be based solely on ES6 class extension, as it should be (rather than having the extra is="" feature). The change that would be needed here would be to ensure that the native elements map to separate leaf classes so it's possible to tell a <q> element apart from a <blockquote> element with instanceof and therefore encouraging that sort of checking over tag names.

This API is still v0 in practice, so I think there's room for modification even if v1 is on the verge of coming out.

Apple objects to extending subclasses of HTMLElement using is=

I think Webkit not implementing is="" may be a great thing.

If we continue with globally registered elements, it will be inevitable that some two components in an app will have a name collision, and that the developer of that app will attempt to fix the problem by modifying the source of one custom element (possibly requiring forking of an NPM module, pushing to a new git repo, publishing a new module, etc, time consuming things) just to change the name of that element; it'd be a pain and can introduce unexpected errors if parts of the modified code are relying on the old tag names.

TLDR, if we put more care into the JavaScript aspects of an element (f.e. choosing which class represents an element, which is already happening in v1) then we'll have a more solid Web Component design, and we can drop is="". It will also require fixing things like the <q>/<blockquote> problem.

@trusktr
trusktr commented Jun 7, 2016

@domenic Can you describe the "ecosystem impact" that you might know of?

@domenic
Contributor
domenic commented Jun 7, 2016

I am referring to the various tools which key on local name, including JavaScript frameworks, HTML preprocessors and postprocessors, HTML conformance checkers, and so on.

@trusktr
trusktr commented Jun 7, 2016

I think I know what you mean. For example, search engines read the tag names from the markup in order to detect what type of content and how to render it in the search results. This point may be moot because today it completely possible to use a root <app> component with a closed shadow root. In this case a search engine might only ever see

<html>
    <head>
        <title>foo</title>
    </head>
    <body>
        <app></app>
    </body>
</html>

That's functionally equivalent to an app with no shadow roots and made entirely of randomly named elements:

<html>
    <head>
        <title>foo</title>
    </head>
    <body>
        <asf>
            <oiur>
                ...
            </oiur>
            <urvcc>
                ...
            </urvcc>
        </asf>
    </body>
</html>

Based on that, I don't think it's necessary to keep element names.

I imagine a couple remedies:

  1. Allowing both forms and let users decide which to use: <button is="awesome-button"> or <awesome-button> and let users decide which to use as they so wish.
  2. Allowing overriding of native elements (which pairs well with the idea of per-shadow-root element registrations as in "hey, let me define what a <p> element is within my component that has no paragraphs."). Then <button> could behave like <awesome-button>, and search engines or other tools would be able to receive the same semantic meaning. This idea only works if the elements are in Light DOM.
@domenic
Contributor
domenic commented Jun 7, 2016

Remedy 1 is what we have consensus on.

@rniwa
Contributor
rniwa commented Jun 7, 2016

I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.

@Zambonifofex

It’s important to note that a lot of elements are implemented partially (or completely) with CSS. So, in order to support this and allow user agents to continue to implement elements like they do today, a new CSS pseudo-class would be needed: :subtypeof(button)

@chaals
Contributor
chaals commented Jun 11, 2016

a new CSS pseudo-class would be needed: :subtypeof(button)

Not really. The point of the is= approach is that since you have a button, that already matches CSS selectors for button. If you want to match a specific subtype you can do button[is=broken-button]

@Zambonifofex

@chaals right. You would need the pseudo-class if using a custom element that extends a native button could be done like <awesome-button> instead of <button is="awesome-button">.

@Zambonifofex

Also, like @trusktr said, if this and whatwg/html#896 become a thing, I think it’ll be possible to remove altogether the extends property from the options argument. We would then write customElements.define("awesome-button", class extends HTMLButtonElement{}, {}), which I really like.

Offering this as an alternative to the current way of defining extending native elements — allowing user agent developers and authors to choose which they want to use — is the best solution in my opinion. As @trusktr said, “I think ‘breaking the web’ might actually fix the web in the long run”.

@chaals
Contributor
chaals commented Jun 11, 2016

(@Zambonifofex it's generally not clear to me what you mean when you say "this", which makes it hard to engage)

As @trusktr said, “I think ‘breaking the web’ might actually fix the web in the long run”.

I've tried breaking the Web, at the turn of the century when it was smaller, to do something that would have been really useful. It failed. For pretty much the reasons given by people who say "you can't break the web".

Although user agent developers are less reluctant to break things than they were a decade ago, they're still very reluctant, and I believe with very good reason.

I think a strategy reliant on breaking the Web to fix it is generally a non-starter, even if the alternatives are far more painful.

@chaals
Contributor
chaals commented Jun 11, 2016

For what it's worth, I agree with @rniwa's characterisation - we have an agreement that we won't write is= out right now, but I don't see a strong consensus behind it. (Although as an individual I'm one of those who think it's pretty much indispensable to making this stuff work).

@Zambonifofex

@chaals

(@Zambonifofex it's generally not clear to me what you mean when you say "this", which makes it hard to engage)

When I say “this” I mean “this issue”; the suggestion made by @trusktr in the first comment of this thread.

But, honestly, — not that I’d be able to know, as I’ve never touched any browser’s code — I think that this would be a much easier change to make for user agent developers than you guys are making it out to be.

@Zambonifofex
Zambonifofex commented Jun 12, 2016 edited

I mean, sure, it could be slightly annoying to go and change all of the checks for the tag name to something else, but would it be actually hard?

@trusktr
trusktr commented Jul 2, 2016 edited

The is="" API can be confusing. For example (in current v0 API):

<my-el></my-el>
class MyEl extends HTMLElement { /*... */ }
MyEl.extends = 'div'
document.registerElement('my-el', MyEl)

// ...

document.querySelector('my-el') instanceof MyEl // true or false?
@domenic
Contributor
domenic commented Jul 2, 2016 edited

That API does not reflect the current custom elements API.

@trusktr
trusktr commented Jul 2, 2016 edited

We should make the result of instanceof be obvious. I think this could be better in v1 (without is="" and without options.extends):

<my-el></my-el>
class MyEl extends HTMLDivElement { /*... */ }
customElements.define('my-el', MyEl)

// ...

document.querySelector('my-el') instanceof MyEl // true!
@trusktr
trusktr commented Jul 2, 2016

I forgot this line too, in the previous comment:

document.querySelector('my-el') instanceof HTMLDivElement // also true!
@trusktr
trusktr commented Jul 2, 2016 edited

(@domenic I'm still using v0 in Chrome)

@trusktr
trusktr commented Jul 3, 2016 edited

@rniwa

there could be an intense of HTMLAnchorElement whose local name is not a.

I think you meant "instance" instead of "intense"? This seems to be the reason why is="" exists, making it possible to create new elements that extend from elements that inherit from the same class, but that possibly have new behavior added to them in their definitions along with differing nodeNames. This is also the reason for the {extends: "element-name"} (I am calling it options.extends), which effectively accomplishes the same thing. I feel like this may be an anti-pattern considering that we now have ES6 classes for describing extension.

I am against both of those methods of defining extension, as I believe encouraging ES6 Classes as the the tool for defining extension will reduce room for confusion.

@trusktr trusktr changed the title from Why must the is="" attribute exist? to The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. Jul 3, 2016
@trusktr
trusktr commented Jul 3, 2016

Perhaps existing native elements should be re-worked so that any differences they have should rather be described (explained) by using class extension, and not using those other two methods (is="" and options.extends). An example of native elements that are defined with the same interface/class but with different nodeNames are q and blockquote which share the HTMLQuoteElement interface. We should attempt to describe the difference (if any) between these elements with class extension rather than is="" combined with options.extends. If there is no difference except for nodeName, then if they are both instanceof the same class that is fine too as long as the behavior for both elements is entirely defined in the shared class, and not by other means.

@rniwa
Contributor
rniwa commented Jul 5, 2016

FWIW, we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.

@Zambonifofex

@rniwa if you could enumerate a couple of these “various reasons” or link to some previous discussion on this subject that lead to this conclusion, it’d be appreciated.

@bedeoverend

@rniwa I second @Zambonifofex, would love to know the rational behind this. In the case of needing features exclusive to native elements, how would someone use these features on a custom element without extending it?

An example my company is dealing with is replicating the sizing of a native img element, so far we haven't found any cross browser way to replicate the way it sizes, therefore having an element extension, so right now using is, is the only way to achieve this.

@Zambonifofex

@bedeoverend I don’t think they are against extending native elements, they are simply against classes extending subclasses of HTMLElement. So you would still be able to extend native elements using the extends property of the customElements.define method. What would be illegal is the class passed to the method to extend a subclass of HTMLElement.

@rniwa
Contributor
rniwa commented Jul 6, 2016

We won't be supporting extends either.

One fundamental problem is that subclassing a subclass of HTMLInputElement or HTMLImageElement often leads to a violation of the Liskov substitution principle over time. Because they're builtin elements, they're very likely to be extended in the future. Imagine that we had this feature supported before type=date was added. Then your subclass of HTMLInputElement must also support type=date in order to satisfy the substitution principle. Similarly, imagine we had added this feature before srcset was added to HTMLImageElement and you wrote a subclass of HTMLImageElement. Then not supporting srcset results in the violation of the principle again.

In addition, none of the builtin elements are designed to be subclassed, and in fact, we don't have builtin subclasses of HTMLElement that are also builtins. This limits the usefulness of any sort of subclassing. Furthermore, we don't have any hooks for the processing models and internal states of builtin elements such as the dirtiness of HTMLImageElement's value and when and how HTMLInputElement picks the appropriate image.

Finally, the whole design of is= is a hack, and it would harm the long term health of the Web platform.

@trusktr
trusktr commented Jul 6, 2016 edited

FWIW, we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.

One fundamental problem is that subclassing a subclass of HTMLInputElement or HTMLImageElement often leads to a violation of the Liskov substitution principle over time.

@rniwa True, which is why we should avoid subclassing when we can, but I think it's needed in order to fix the mistake that was made with q and blockquote. Otherwise, how does the web manifesto explain the difference between <q> and <blockquote>? I.e. How would the customElements.define() calls for q and blockquote differ in order to theoretically satisfy the web manifesto?

Maybe we would need to reserve HTMLQuoteElement for the q tag, and make a new HTMLBlockQuoteElement for the blockquote element, both of which extend from HTMLElement. I can see how that would be one way to satisfy the web manifesto and remain closer to Liskov's substitution principle.

@rniwa
Contributor
rniwa commented Jul 6, 2016 edited

Yeah, there has been a discussion about that for q and blockquote. A more likely consensus is to introduce two subclasses of HTMLQuoteElement, e.g. HTMLInlineQuoteElement and HTMLBlockQuoteElement and have q and blockquote each use it. It's a bit more hairly story for h1 through h6, which seems to require an introduction of six subclasses of HTMLHeadingElement from HTMLH1Element through HTMLH6Element.

@trusktr
trusktr commented Jul 6, 2016

I believe that would be totally fine along with agreement that subclassing in general is better avoided when possible. Nothing's perfect, but having those new subclasses for end-webdevs to extend from is already better than is=""+options.extends.

@domenic
Contributor
domenic commented Jul 6, 2016

having those new subclasses for end-webdevs to extend from is already better than is=""+options.extends.

While I can agree is="" is not perfect---perhaps even "a hack", although IMO a pretty reasonable one---I think this opinion is just wrong. Web devs and users both benefit greatly from the ability to extend built-in elements, and is="" is the most practical solution so far. That is why the consensus was to keep is="" in the spec and let implementations decide its fate: because it allows developers to write less code and get more correct behavior, and because it helps users---especially disabled users---interact with web pages in a more predictable and easy manner.

You can talk about how you dislike the technical aspects of is="" as a solution, but I think it's very unfair to say that omitting is="" is better for webdevs (or even "end-webdevs", although I'm not sure what those are).

@ebidel
ebidel commented Jul 6, 2016 edited

I've built web components for many years and talk with a lot of web developers regularly about them. I'd like to look at this question from their perspective. Devs don't care about implementation challenges or diving into the weeds.

We need to keep customized built-in elements. CE v1 is not a spec without a way to extend existing HTML elements. My talk at the Progressive Web App Summit highlights some of the reasons why it's important to keep:

  • is="" is 100% progressive enhancement!
  • Utilize built-in a11y features of the element. This is one of the primary reasons to keep it. I've seen far too many devs build custom elements that miss out on basic a11y...forget it altogether 👎.
  • More DRY. One gains native features for free (keyboard behavior, imperative API, and styling). Even recreating all the benefits of <button> requires way too much code.
  • Autonomous elements don't have the black magic that native elements have (e.g. creating an element that participates in <form> is painful). Same with extending other types of children.
  • Existing tools understand built-in elements
  • Existing CSS theming libraries work better with it
  • In Polymer, folks really love the extended helpers (<template is="dom-repeat">, <template is="dom-if">,`. They're easy to reason about, declarative, and simple to use. You know exactly what you're getting.
  • I talk to a lot of web developers. They don't mind is="".
  • No other component library gives you all ^ for free.

Whether is="" is the way to extend elements or not doesn't matter to much. But we definitely need a solution rather than no solution and currently, that's is="". Personally, I see nothing wrong with is="". It's worked great for the last couple of years in Chrome's v0 implementation. It's been implemented in a browser and proven. There may be edge cases with subclassing certain elements, but TBH, I haven't seen many (any?) developers run into them.

Ultimately, developers have to write less code with is="". That's huge. Extensions bring more reuse and keep best practices to our platform. Not less. Let's not remove such a useful feature.

@Zambonifofex
Zambonifofex commented Jul 6, 2016 edited

@domenic

Web devs and users both benefit greatly from the ability to extend built-in elements, and is="" is the most practical solution so far. That is why the consensus was to keep is="" in the spec and let implementations decide its fate: because it allows developers to write less code and get more correct behavior, and because it helps users---especially disabled users---interact with web pages in a more predictable and easy manner.

That’d hopefully still be the case if is="custom-button" gets removed in favor of <custom-button>.

@rniwa
Contributor
rniwa commented Jul 6, 2016

I don't get why people keep making claims that is= improves accessibility. It simply doesn't except the very simple scenario in which the entire UI of the builtin form control is preserved (e.g. just adding JS methods).

In reality, a lot of custom form controls exist on the web for the sole purpose of customizing appearances against their builtin counterparts. Unfortunately, as soon as you've attached shadow root on a builtin element which is not even supported in shadow DOM v1, there is no accessibility benefit from using is= because UA can't determine how elements in a shadow tree corresponds to what UI actions without explicit annotations by the author.

@esprehn
esprehn commented Jul 6, 2016

is@ is critical for supporting reasonable AX for links. We tried to replicate the subtle focus and keyboard behavior of <a> with a custom element for quite a while before giving up and doing <a is="...">. Nesting a link inside an element breaks styling since my-link:visited etc. stop working.

I could be convinced that we don't need to allow subclassing input, but I think links are super important. Note also that developers have been using template with is@ very successfully over the past 3 years.

Fwiw we also hope to introduce a unique class per tagName, so we would add all six classes for headers etc. It makes the platform make much more sense. :)

@WebReflection

My 2 cents, FWIW, <a is=""></a> or <img is=""> confuses nobody about the intent, <shena-nigans></shena-nigans> is a complete wonder of what the heck is that tag about.

Crawlers, old and new users, browsers themselves before they load non blocking async info about the custom elements, just to name few that benefits from is

It also shipped 3 years ago and it worked de-facto pretty well on real-world production sites.

I'm not sure why this bug is still opened or still considered as something to be changed.
AFAIK not a single developer I've talked to said it was confusing (I also gave a talk about this)

@treshugart
treshugart commented Jul 13, 2016 edited

Whatever happens here, platform consistency should be considered highly important. If all browsers but WebKit support is, anyone with a valid use-case for using it will have to not use it, or remove Safari from their browser support matrix. There are good reasons for both sides of the argument, but I think there should be some compromise.

@WebReflection

WebKit works well through this polyfill of v0 that will eventually be upgraded to support v1 as soon as it's stable (I don't want to repeat the effort for something not final yet)

Best of all, you can IE8 or even IE5 this page and always see where's your business.
That's just a tiny demo of how powerful is the is attribute.

http://webreflection.github.io/document-register-element/test/examples/x-map.html

You can disable everything you want, you gonna see what the map is supposed to show anyway
( ok, not if you're using a text only browser ¯_(ツ)_/¯ )

@WebReflection

@rniwa if it's been proved it works and scale well, I am not sure why WebKit would avoid it at all costs.

The result might be some nasty user-land overwrite/interception in order to make it work in there too (like a polyfill would do).

Moreover, the argument about violating the Liskov substitution principle doesn't feel appropriate for the Web environment. The entire global scope/context can be polluted (and it is) dozens of times by all libraries out there, with or without a namespace.

That doesn't prevent standard bodies to implement MyLibrary or fetch if that's an appropriate name for a new feature, isn't it?
Of course, modules partially solve this but polyfills will still do feature detections and pollute globally.

As summary: in a parallel universe where developers couldn't change the environment your point would be more than valid, but I think that's not really how the real-Web-world moved forward for the last 20 years.

If every other vendor agreed, please consider to follow this de-facto need and pragmatic solution for the sake of the Web, thank you.

@Zambonifofex

@WebReflection

I'm not sure why this bug is still opened or still considered as something to be changed.

Well, since no‐one else seems to agree with me and @trusktr, I think I’m fine with this being closed. I still don’t like is, but I can live with it.

@WebReflection
WebReflection commented Jul 14, 2016 edited

@Zambonifofex the DOM is old and not perfect, neither is the is attribute as solution. However, it solves everything every native HTMLElement has solved during the last 25 years without any need to reinvent the wheel. Moreover, it doesn't require O(n^2) amount of nodes (named custom elements plus eventually native links/input/whatever inside) and also it makes it possible to better integrate with the Web platform.

An example over every other, is the bloody tr that cannot be wrapped around a custom-tr element because it will break and table are still the best, semantic, accessible way to display tabular data.

TL;DR nobody likes is but whoever worked with it will admit is the most pragmatic, easy-peasy, cross platform friendly and working solution we have so that every developer moved forward building great stuff based on such attribute.

The previous x-img tag goes even further, using CSS like img[is=x-map], x-map {} to have common styles for before and after the upgrade which replaces the image with something else that has nothing to do with an image (it's a Leaflet canvas/iframe/different-world)

Why not closing this chapter and move forward then, since there are no equivalent solutions that either work or that have been even proposed?

So please, let's implement is and move forward the Web. Thank you!

@rniwa
Contributor
rniwa commented Jul 18, 2016

FWIW, we're going to iterate our opinion that we're not going to implement is attribute in WebKit.

@ebidel
ebidel commented Jul 18, 2016

That's very unfortunate.

@paulkinlan wrote a great piece on platform inconsistencies recently, "The Lumpy Web".

  • Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
  • We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
  • Developers should raise more issues to keep browser vendors accountable when there are differences

I hope this inconsistency doesn't become detrimental to the adoption of Custom elements.

@rniwa
Contributor
rniwa commented Jul 18, 2016

The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.

The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.

It's extremely frustrating for you to then make arguments to implement this feature after the fact. We've had this discussion before, and nothing has changed. So why do you think keep making the same arguments would change anything?

@WebReflection

'cause we're all thinking, reasonable, people and Custom elements with is attribute have been already adopted and not only by Google and Chrome.

@ebidel
ebidel commented Jul 18, 2016 edited

It's extremely frustrating for you to then make arguments to implement this feature after the fact.

Sorry, I don't mean to minimize previous spec discussions. There are a ton of historical conversations that have taken place outside this bug...over many many years! It's hard to follow Webkit's full reasoning without that reasoning being documented here. Would be nice to have a summary on this bug.

I think what you're seeing now is feedback from the actual dev community. Web developers don't participate in spec discussions. Github bugs makes things more approachable.

@chaals
Contributor
chaals commented Jul 19, 2016

Feedback from stakeholders - developers, toolmakers, end users, etc - is valuable. I'm grateful that people have provided it in a constructive and polite manner, because attacking individuals isn't helpful.

There doesn't seem to be new information here. There are people who think is= is a bad idea, and people who think it is worthwhile. I think we should close the discussion, and let the W3C Process operate.

@rniwa isn't unique in opposing is=. He is a thoughtful intelligent person who disagrees with the apparent majority of the 10 participants in this discussion.

Apple is not unique as an organisation in opposing the attribute.

At the same time, there are many who think it is a good idea. Personally I agree with @WebReflection that it is of limited, but real value and we are better off having it than not. As chair, that doesn't mean I can impose it.

The attribute is in there for now, with supporters and detractors. Given the obvious lack of consensus to either keep or remove it, the W3C Process includes testing whether there is a likelihood of interoperable implementation which will probably boil down to looking at actual implementation. Nobody is obliged to implement, we will look at what the market does.

Apple (and others who share their dislike for is=) know how to suggest that something is removed from a specification on technical grounds, and have said clearly before that they don't intend to support this. Others have said they do.

The Web doesn't develop in lock step because it isn't imposed by a single actor, and overall that seems to be a strength. It is quite reasonable in a market for some players to decide not to implement something. It is unfortunate that this produces inconsistency at the bleeding edge, but it also gives us great power to let innovations come from anywhere instead of only market-dominating players being able to do it for us.

Our process enables this deliberately, for reasons beyond the above. One of them is to make sure our work is not illegal anti-competitive industry collusion. That's important to a lot of companies who are important in this area. Anyone who wants to go further down that topic, which is beyond the scope of the Working Group, can buy me a beer and lecture me or let me lecture them. But please, not here.

@chaals chaals closed this Jul 19, 2016
@zeitiger zeitiger referenced this issue in WebReflection/document-register-element Jul 21, 2016
Closed

Custom Elements v1 #58

@matthewp

An alternative to is="" could be custom attributes. @rniwa mentioned mixins and this would be a form of that (maybe you had something else in mind). I think it solves the issues that people on boths sides have, and could have a very similar API to custom elements. Something like:

class FooBarAttr {
  attachedCallback() {
    console.log('was created for first time');
  }

  changedCallback(newValue, oldValue) {
    console.log('it changed');
  }
}

customAttributes.define('foo-bar', FooBarAttr);

This would be super simple to polyfill with MutationObservers as well.

@seaneking seaneking referenced this issue in SimplaElements/simpla-img Sep 1, 2016
Open

Refactor, and extend native <img> #37

0 of 5 tasks complete
@EduardoRFS

@rniwa A solution to this element.localName == aTag is easily, hack that. Create internally two elements, linked in properties(css and javascript), is really hard to implement that? Ok performance is not excelent but is really more slow than actual "is" implementation? Perdon if this is bullshit

@Zambonifofex

@matthewp

If you haven’t already, maybe you should create a new issue thread asking for this. It sounds like an excellent idea that’d get more attention if it was in its own thread.

@trusktr
trusktr commented Sep 10, 2016

@matthewp @Zambonifofex

I believe attributes should be on a per-custom-element basis, otherwise globally registered attributes will get messy quickly. Many custom elements may depend on values of attributes with the same name (I.e. name clashing can become a nasty problem).

In native HTML, style="" is common across many elements, if not all. This type of thing should happen through extension. If my custom element has special behavior based on a foo="" attribute, and you extend it to make your own custom element, then your element will inherit that attribute behavior. Likewise, we can explain the style attribute the same way due to the fact that custom elements can inherit it from HTMLElement (I think that is where style behavior is defined?).

@Zambonifofex

@trusktr

What about being able to define both global attributes and attributes on specific elements?

customAttributes.define("foo-bar", HTMLElement, FooBarAttr); // Global attribute
customAttributes.define("foo-baz", MyElement, FooBazAttr); // Element‐specific attribute

Still, I like to encourage the practice of pseudo‐namespaces. That is, when writing a library, named, say, “my library”, instead of having a fancy-button element, have a my_library-fancy_button element. Similar thing with attributes.

@tomalec
tomalec commented Oct 16, 2016

I would like to put my small feedback as a web-developer and would like to add another point to @ebidel 's list why is is important for my team and our products (custom elements).

It simplifies and optimizes not just styling, accessibility but also parsing.

We've created a number of vanilla CEs that extends <template> (far away from Google, Polymer, and their templating magic). The most important thing here is the inertness of element, which we cannot implement by ourselves . Probably, we can get it by just extend HTMLTemplateElement but it still will not solve the problem completely.
Before element definition is (lazily) loaded <our-template>...</our-template> will render ....

Removal of is (or equivalent/Custom Attributes) will require CE users to write <our-template><template>...</template></our-template>. Which not only look redundant and counter-intuitive, require more code on CE user side, as well as on CE dev side (as mentioned above), but what's most important <our-template> will still take part in regular rendering (could get styled, etc.) until it's definition is loaded.

@WebReflection
WebReflection commented Oct 16, 2016 edited

This is just a reminder that my V1 polyfill forces is="native" feature in browsers that don't support it, and it uses it natively where available.

I think we, developers, will find a way to implement is="native" feature in a way or another; I just wish they (browser vendors) will stop pushing back instead of understanding its use cases that are simply or practically impossible to reproduce otherwise.

template, tr, body, and even html are just few examples of what we're missing as extending possibility for the whole Web platform, present and future.

@EduardoRFS

@tomalec or just <our-template></our-template> is not removal of is= but deprecate, like all other features on web. Actually polymer use template with <template is="dom-repeat">, if is= turn optional allow that <dom-repeat>

@richardkazuomiller

There's been a lot of argument here about why some people like is="" and others don't, but I'd like to hear constructive suggestions from the anti-is side of how we can extend custom elements without using is while preserving all of the functionality of the native element and compatibility with browsers that don't support custom elements at all.

Consider this custom element:

<a is="fancy-anchor" href="/something">Fancy Anchor</a>

If is="" isn't an option, I'm assuming that the element would look like this:

<fancy-anchor href="/something">Fancy Anchor</fancy-anchor>

If that's the case, how does one implement it so all of the following are true?

  • A screen reader can always recognize that it is a link to another page
  • Clicking on the link opens /something when JavaScript is disabled
  • fancy-anchors can be focused using the tab key in IE8
  • The script that defines fancy anchor can be loaded asynchronously
  • A search engine will be able to tell that there is a link to /something on that page.
@matthewp

@richardkazuomiller You have MutationObservers at your disposal, so you can mimic everything is gives you in normal JavaScript unless you depend on synchronous callbacks. So you don't need to create a <fancy-anchor> element but rather can use a data-fancy-anchor attribute on a normal anchor, use mutation observers to know when the element is connected/disconnected and when attributes change.

@richardkazuomiller

@matthewp That defeats the whole purpose of having custom elements and introduces a whole other set of issues. The whole point is that once a custom element is implemented it can be created anywhere and treated the same as any other element. If upgrading the <a> to a fancy anchor depends on a MutationObserver, that means they will never be upgraded until they're inserted into the observer's target. If we need it to be upgraded it before it's inserted into the DOM we need to call some other function every time we want to create a fancy anchor, which means more code that doesn't follow a standard, probably more dependencies, and we're back where we started.

We at least all agree that being able to create a subclass of a native element – with or without is= – is a good idea right?

@seaneking

@richardkazuomiller Webkit is opposed to subclassing native element subclasses outright, see comment from @rniwa above (#509 (comment))

@richardkazuomiller
richardkazuomiller commented Oct 27, 2016 edited

Oh, I misunderstood subclasses of native element subclasses to mean subclasses of user-defined subclasses. My mistake.

So I guess the answer to my (admittedly mostly rhetorical) questions really are "don't use custom elements". That's worse than I thought. In that case I'd like to rebut some of the points made by the anti-is side, from my point of view as a developer.

The is="" API can be confusing

I've never heard of anyone who found it confusing. The intent of it is clear. Besides, if we bikeshedded every confusing part of the web until everything was perfect we wouldn't have browsers at all.

subclassing ... often leads to a violation of the Liskov substitution principle

Things breaking because of an update to a superclass's implementation happens is a fact of life. It should be avoided wherever possible, but eliminating subclassing altogether is not the answer. The possibility of a hypothetical input type being added is not worth throwing away all the possible custom input types developers could be making. Don't throw the baby out with the bathwater

none of the builtin elements are designed to be subclassed

I can say from experience that whether they were designed for it or not, subclassing native elements works very well. While there may be limitations when extending inputs, for example, it's easy to work within those limitations.

I don't get why people keep making claims that is= improves accessibility. It simply doesn't except the very simple scenario in which the entire UI of the builtin form control is preserved (e.g. just adding JS methods).

I think you're assuming that preserving the builtin UI isn't exactly what a lot of devs are doing. Look at Polymer's iron-input. No crazy shadow DOM stuff, just key bindings and a validator but that alone is very powerful. I've extended HTMLInputElement in my own applications to build things that are very complex, but thanks to custom elements I can just add is="whatever-input" to another input so they are also portable.

One might suggest that instead of extending native elements, we should create some kind of wrapper or bind events when the document loads or something, but custom elements v1 works with elements created with document.createElement, appended to another element as HTML, rendered as the HTML in the first request streams in, or any other way elements get created, without requiring any extra JS. If WebKit decides not to implement is=, thereby making progressively enhanced native elements impossible and forcing developers to write more code, people are just going to keep using the polyfill.

I'm just a lowly webdev, so while I have opinions about the big-picture future-of-the-platform stuff, I'll leave that to you folks. I hope you'll consider my perspective when implementing (or not implementing) the spec.

@pete-otaqui

I would really like to have the ability to use the unreproducible features of native elements in custom ones. I don't really mind if that's through inheritance or some other "mixin" approach.

Beyond even accessibility, which to me seems to be the biggest reason to want this, there are things like <datalist> which (in browsers that support it, hint hint) will produce a dropdown menu that overflows the browser window. Clearly no (sane) web dev is going to attempt to rebuild that from the ground up. I would love to be able to extend <datalist> to have custom matching routines, for example. Of course, I'd also love it if the native element was in Webkit in the first place ;)

The problem with <datalist> is that it's really not extensible. The existing implementations aren't fabulous - but they are so close, and could be made amazing with just a few extra touches.

The same thing applies with the venerable <select> too - especially on mobile platforms. There are interactions there that are simply not possible with a purely custom element - and not even possible (or at least straightforward) with custom elements that wrap / utilise the native ones inside. The fact that we web devs can't simply use those powerful native capabilities without recreating them from scratch, or hacking around with composing them, is a real shame for the web.

As I said, I'd be fine with mixins instead of inheritance - has any effort been put into specifying that? Would it mean I could still get all the unreproducible behaviours, of let's say a <select> tag, and add my own implementation pieces?

@WebReflection

FWIW, since "yurak is working on this", I guess all we have to do is wait that Firefox and Edge would follow and keep polyfilling WebKit (hopefully not forever).

This is a page to check builtin extend status.

This is the same page using my polyfill.

@oleersoy
oleersoy commented Nov 2, 2016

Suppose I'm using for example <app-drawer> or <chat-app> in my app. At this point is there any point to me considering the is syntax?

I'm not trying to argue for or against it, just trying to understand the When it is of interest part better.

@tomalec
tomalec commented Nov 2, 2016

@oleersoy I don't think so. is is supposed to customize/extend built-in elements, so you could use their parsing, accessibility features, etc. even before your element is upgraded. For example: <input is="spaceship-coordinates">, <template is="enhanced-template">.

@oleersoy
oleersoy commented Nov 3, 2016 edited

So I just want to confirm that if I'm using <app-drawer then there is no point in using the capabilities of is because the <app-drawer> element is not something that is amenable to progressive enhancement?

In other words there is no point in doing is="spaceship-coordinates", because even though that part could fall back to a normal input field for browsers that don't understand what the is is for, the <app-drawer> element would completely break, so essentially the app would be an airplane with the wings missing?

@WebReflection

@oleersoy the is="enriched-element" has different use cases than <custom-element>. If you want to have exactly same native behaviour and extend it on top, you need the is attribute through the builtins extend way. There are no valid and universally compatible alternatives to this approach, so it's a matter of when rather than if these are needed.

template, th, tr, body, head, html are just few examples where you simply cannot use a custom tag with same/needed element inside because the result would be breaking for the surrounding HTML or the page itself.

a, button, input, iframe, form are, on the other hand, things well handled and known by browsers and bring in a lot of things automatically. In these cases you can wrap these native builtins around through redundant, not needed, verbose HTML, or create them at runtime (and once) on connectedCallback losing completely graceful enhancement.

A canvas-3d could be created with both approaches, but if you put a canvas inside a canvas-3d you are still in redundant-land but it's not such big deal since canvas is not much accessible
anyway. Everything else with builtins special meanings is problematic to reimplement.

Last, but not least, if you have a custom element that doesn't need to extend any special functionality beside what HTMLElement provides already, you'd go with the regular extend through the tag name and basic definition.

Most of the time, that's all you need but as you can see, developers can, and will, use Custom Elements in various ways.

I hope I've clarified most common use cases.

@richardkazuomiller

@WebReflection Those are some great examples (^_^)

@oleersoy To add to the previous comment, <app-drawer> wouldn't necessarily break in browsers that don't support custom elements if it's implemented in the right way. You should check out this video of how to make a progressively enhanced accordion custom element by the Chrome Dev team (more links below). Try looking at it (in Chrome) with and without JavaScript. It's just a demo so it doesn't go as far as checking for custom element support in browsers other than Chrome, but you can get the idea.

The reason an <app-drawer> doesn't need is="something" is because it doesn't need to fall back to a particular element type. When is= is not used, a custom element will just fall back to a plain HTMLElement and it will work, because all of the browsers will display an element with any tag name. Luckily, that's been in the spec since long before custom elements have been a thing and will work regardless of the fate of is=.

Chrome Developers Supercharged - Accordion
Source code from the video
The final product

@oleersoy
oleersoy commented Nov 4, 2016

So I'm trying to make my question really simple because I'd like a straightforward answer. If this cannot be answered in terms of yes or no please let me know why.

Again I'm asking whether the minute I add the Polymer <app-drawer opened></app-drawer> to my app, it effectively obsoletes previous work done to make a progressively enhanced app?

BTW - I'm saying Polymer specifically because I prefer not get into "Well if it was implemented this way theory". If we expend enough effort we can do anything. Just ask the Microsoft team that tried to integrate the browser into the desktop.

@richardkazuomiller

@oleersoy The approach I suggested will work with Polymer's app-drawer. Just use CSS to make the app-drawer show its contents before it's upgraded and remove those styles if Polymer is available. You can probably get more specific and helpful answers about a particular Polymer element if you open an issue on that element's repository.

@oleersoy
oleersoy commented Nov 4, 2016

@richardkazuomiller Thanks that seems reasonable. What if the <app-drawer> uses the shadow-dom - will it continue to render and work as expected, given that we override the css used to display the element initially? @rniwa IIUC seems to be saying that any custom element that uses the shadow dom will terminate the progressive enhancement capability afforded to us by is?

@rniwa
Contributor
rniwa commented Nov 4, 2016

If you're using an autonomous custom element (i.e. not using is attribute in your code), all of that is irrelevant. Regardless of whether app-drawer uses shadow DOM or not, it functions as expected.

@trusktr
trusktr commented Nov 5, 2016 edited

Regardless of whether app-drawer uses shadow DOM or not, it functions as expected.

Not necessarily true for custom elements in general. Try using ShadowDOM with the A-Frame Custom Elements that are available at http://aframe.io, and you'll see that they won't work as expected (jsfiddles). A-Frame (and any other Custom Element libraries used for constructing custom render trees) need to be able to construct an internal representation of the final flat tree which is the result of composed shadow trees, and then the internal representation of the flat tree can be used (for example) to render a scene in WebGL or Canvas 2D.

@rniwa
Contributor
rniwa commented Nov 5, 2016

Not necessarily true for custom elements in general. Try using ShadowDOM with the A-Frame Custom Elements that are available at http://aframe.io, and you'll see that they won't work as expected (jsfiddles).

That's pretty orthogonal to what we're discussing here. That's just a limitation on the current shadow DOM API.

@ebidel
ebidel commented Nov 5, 2016

@oleersoy Custom elements go through an upgrade process, which means PE is a built-in feature of the API. Consume components under the assumption that JS may never run. Then, sometime in the future JS does run, registers the elements. Boom. You're progressively enhancing that markup.

This article and my presentation the PWA summit earlier this year discusses the notion of "progressively enhanced markup". Video.

@oleersoy
oleersoy commented Nov 5, 2016 edited

@ebidel just saw your comment now. Huge fan of your articles! I'll amend my comment a bit in light of yours.

OK - Let me reboot my simple scenario and limit it to custom elements and javascript in general.

SIDE NOTE

My background and primary reason for looking at all the specs is that I think custom elements and the shadow dom are fantastic tools for simplifying my apps, and my gut feeling is that anytime I create an element that does something beyond just special effects, the app will break given that the custom element API is not supported / The element upgrade has not yet kicked in. I'll illustrate what I mean.

END SIDE NOTE

So suppose I wrote an app consisting of two custom elements <custom-broadcast> and <custom-receiver> that talk to each other. The <custom-broadcast> elements sends messages on a configurable attribute channel and <custom-receiver> receives them on a configurable attribute channel.

I could also have a FancyButton configured as <button is="fancy-button">Broadcast</button>. When I click the button it will tell the <custom-broadcast message="Cubs win!!!" channel="1"> element to start broadcasting Cubs win!! and the <custom-receiver channel="1"> will just log that to the console.

So I load this app in a browser that does not support custom elements or will not upgrade them for some reason. The FancyButton falls back to a normal not so fancy button, and when clicked nothing works.

So to me it seems as if I want an app that works well on all browsers, then I'm better off with a non custom element approach, but if I want to go bleeding edge and throw some users with dusty browsers under the bus then I would choose custom elements.

In other words I simply don't see what advantage is is offering?

@rniwa
Contributor
rniwa commented Nov 5, 2016 edited

Right, that was one of the arguments we (WebKit team) made to argue against is. Progressive enhancement based on is sounds nice in theory but in practice, any app that relies on JS / DOM "enhancements" made by customized builtin code would break.

Similarly, anytime a shadow root is attached on a builtin element, we can't simply assume the ARIA role of the underlying element. For example, imagine input's type=date didn't exist and we were building it as a customized builtin element. Then by attaching a shadow root on input (which is not even allowed in shadow DOM API at the moment), and introducing controls for changing months, etc... in the shadow tree, we're effectively rewriting the semantics that need to be communicated with the assistive technology. So, in practice, user agents would need to use the flat tree to construct the accessibility tree anyway except all but the simplest of the simplest case.

@richardkazuomiller
richardkazuomiller commented Nov 5, 2016 edited

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

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.

As for the shadow DOM stuff, I honestly don't think that has anything to do with is. Attaching a shadow root to a builtin element might introduce complexity, but as a few people have said already, there are many use cases for custom elements that don't have anything to do with shadow DOM. This has already been proven by the fact that custom elements are already being used in production when shadow DOM is still only in Chrome. Shadow DOM and custom elements are often used together, but discussions about the two should be kept separate.

@seaneking
seaneking commented Nov 5, 2016 edited

@oleersoy in that scenario no, fancy-button wouldn't offer progressive enhancement because you're not progressively enhancing a button, you're giving it core functionality that your app is broken without.

There are lots of good examples of progressive enhancement enabled by extended builtins (eg: iron-input mentioned above). An example from our own work - we're building a wc content management library, and by extending builtins we can render content to elements before upgrading with editing behaviours, and therefore support legacy browsers, pre-rendering, etc. Without extension this becomes infinitely harder.

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). We've found that the 'just wrap the element' hack often falls short (eg: wrapped templates existing in doc flow, losing 1:1 interop with native elements). Given, this could be provided with mixins rather than is, but then you lose the prog enhancement benefits.

@oleersoy
oleersoy commented Nov 5, 2016

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.

@seaneking

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

I think discussing that is out of the scope of this issue.

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.

See the example in my previous comment

@oleersoy
oleersoy commented Nov 6, 2016

I think discussing that is out of the scope of this issue.

Of coarse why would the practical application of the technology you are recommending be in the scope of the issue?

See the example in my previous comment

I have not seen a single example that makes sense in an application context. If you think that one component makes an application and progressively enhancing a single component in a vacuum is a great reason to ask millions of developers and product managers to understand this topic then good luck convincing Apple and MS. "Here guys this is going to useful to you 0.0000000001% if the time. Bon appetit!!".

@WebReflection
WebReflection commented Nov 7, 2016 edited

@oleersoy

So I load this app in a browser that does not support custom elements or will not upgrade them for some reason. The FancyButton falls back to a normal not so fancy button, and when clicked nothing works.

Your example, a specific use case that ignores all other already discussed in here, relies heavily on JS regardless the usage of the is attribute.

So, if your question is if you should use a polyfill or not, that covers also the is attribute like dre does, then you are the only one that can answer such question: are your target browsers already spec-compliants? Then don't, otherwise go agead and use a poly based on features detection 'till that day.

I have not seen a single example that makes sense in an application context.

This is a good old example from V0 era that shows just one of the huge amount of benefits of the is attribute. It's a cross map and it works down to IE8 and Android 2 or iOS 5 (and BB7, webOS, etc)

Somebody took that example saying "you could've just used a wrapper element" but that would be meaningless and redundant on the layout, and it might cause gotchas on IE8 side which is incompatible with randomly named elements (and CSS).

The curent polyfill now fallbacks to V0 but it brings in V1 as much as it can (there are parts of V1 that cannot be polyfilled these days) and your specific use case would be covered too.

Somebody went further away with the map element using layers and much more, still Custom Elements only: https://customelements.io/Maps4HTML/Web-Map-Custom-Element/

Last, but not least, I've used Custom Elements for years now and never together with ShadowDOM due greediness of the old polyfill with WeakMaps that were breaking all over.
That doesn't meen ShadowDOM is bad or anything, it's actually pretty amazing, but it's absolutely complementary with Custom Elements, not mandatory at all.

@oleersoy
oleersoy commented Nov 7, 2016 edited

relies heavily on JS regardless the usage of the is attribute.

So what is the minimum amount of that JS that you would like the broadcasting example to contain in order to make it work well with the isattribute?

So, if your question is if you should use a polyfill or not

Where in the simple broadcasting example I provided did I ask that?

This is a good old example from V0 era that shows just one of the huge amount of benefits of the is attribute. It's a cross map and it works down to IE8 and Android 2 or iOS 5 (and BB7, webOS, etc)

What's the benefit? Specifically what is the is attribute doing that if it were not present you could not do?

It's already a custom element x-map - so it has to be upgraded in order to work ... so how is the is attribute even relevant? It's supposed to be used on non custom elements like <button>, etc. right?)

Last, but not least, I've used Custom Elements for years now and never together with ShadowDOM due greediness of the old polyfill with WeakMaps that were breaking all over.
That doesn't meen ShadowDOM is bad or anything, it's actually pretty amazing, but it's absolutely complementary with Custom Elements, not mandatory at all.

I looked at your x-map repository and it's obvious that you are a very talented developer, so I'm really hoping that you can come up with something that overcomes our doubts about the value of the is attribute. If you can rearchitect the simple broadcasting example I provided to somehow work well and provide value using the is element according to some of the criteria I have outlined above that would be really great.

@WebReflection
WebReflection commented Nov 7, 2016 edited

your demo example does not work without JS and unless you have a live editable version of it I'm not sure what you are asking for but I have a counter question: how would you create a fancy-button without is?

The fact you don't consider all examples already described like template or even html does not mean these don't exist: it's you ignoring them and thinking only about your use case.

That one, I am afraid, I cannot fix.

@oleersoy
oleersoy commented Nov 7, 2016 edited

your demo example does not work without JS

Neither do custom elements.

The fact you don't consider all examples already described like template or even html

Why would you want to PE the html tag? Or more importantly how many developers want to PE the html tag and when do they want to do this?

The is might be useful in certain cases. Sort like a nail and a 2X4 could be useful on an oil platform. The dude's on the platform might be like "Umm....What are you doing with that 2X4?

That one, I am afraid, I cannot fix.

I know. And that is what the core argument should be about. I'm guessing 99.9999% of developers are going to be looking at exactly this scenario. So should we add to the developer learning curve with is to support 0.00001% of use cases?

And if it's really easy to handle those cases with what we already now, then why is the is even in the spec?

@oleersoy
oleersoy commented Dec 6, 2016

Nice article but it does not exactly scream simple to me. Can I just put <map is="web-map"> and get a working map if javascript is turned off?

@prushforth
prushforth commented Dec 6, 2016 edited

Try it! (On the blog post at least, I can't remember if I put the image in the demo page) you should get the essential user experience of a map, minus zooming and panning. There's probably more I could/should do.

@oleersoy
oleersoy commented Dec 6, 2016

I tried it, I like it, and I think it's very cool! But when do we use it and how? I don't think this is going to pass @OvermindDL1 criteria, because when javascript is turned off how do you get the map tiles?

@prushforth

You get the image map, which is acceptable but not ideal.

@oleersoy
oleersoy commented Dec 6, 2016

OK I think it's cool and a great experiment, but if I tried to push it on my daughter she'd be like "Dad - I'm going with Waze". It's cool - but still!!

@prushforth

LOL yes I get that. Hopefully the Waze guys will use it someday. I mean the comment system here is using HTML but you wouldn't know it mostly.

@oleersoy
oleersoy commented Dec 6, 2016

Kids these days don't appreciate good engineering! :)

@WebReflection
WebReflection commented Dec 6, 2016 edited

We can change the spec. Maybe tear out the kitchen. Etc.

wait ... you quoted the current specs and this entire thread is about not changing them because already OK but some vendor author's manager doesn't get it.

There is nothing to change in specs because as these are, ... drum rolls ..., the bloody is attribute should be already there and widely deployed!

it's in the specs already

@oleersoy
oleersoy commented Dec 6, 2016

OK but some vendor author's manager doesn't get it

You mean Apple?

you quoted the current specs and this entire thread is about not changing them

OK so if I want to join the party of coolaid drinkers then it's OK to comment, but otherwise be quiet?

should be already there and widely deployed!

So are AngularJS 1.0 Apps. These things change very fast.

@chaals
Contributor
chaals commented Dec 6, 2016

People, be nice please.

@oleersoy
oleersoy commented Dec 6, 2016

@WebReflection started it! :)

@chaals
Contributor
chaals commented Dec 6, 2016

@trusktr wrote

If we keep it on merit of understandable syntax, then why not keep it in the same direction as JavaScript?

That's not the primary reason for it. The primary reason is the HTML parser - which gives special magic to elements having their native HTML name.

I agree with others that the syntax is kind of ugly, but it solves a specific concrete problem. The extends stuff would be nice - not least because you could make it do mix-in things to extend both tr and input type="date" in a single custom element. But that seems more like a nice new thing than solving an existing problem.

@WebReflection
WebReflection commented Dec 6, 2016 edited

OK so if I want to join the party of coolaid drinkers then it's OK to comment, but otherwise be quiet?

no, you made your single use case "CE are good enough" point, and never been able to answer all other problems already solved, and please let me underline already thanks to polyfills, by builtins extends.

You are in the same list of browser vendors that complain about is="" attribute and never provided an alternative.

We all got your point, which is restated over and over, and it keeps ignoring all counter-points that invalidate the "CE are good enough" argument.

Do you have a proposal to fix and cover what is="" attribute does already?

Yes? Please share!

No? Please stop making noise in this thread.

Thank you! (and I'll stop making noise myself too now, enough is enough)

@oleersoy
oleersoy commented Dec 6, 2016

Do you have a proposal to fix and cover what is="" attribute does already?

Yes. Do exactly what you are doing now.

No? Please stop making noise in this thread.

Right - my comments are noise and your comments are pure genius.

@oleersoy
oleersoy commented Dec 7, 2016

Thank you! (and I'll stop making noise myself too now, enough is enough)

No need to thank me. You are in full control of your own comments. If you think insulting me and chalking up my comments to "Noise" makes me go away, you are going to be in for rude awakening. Personally I'm just getting warmed up.

@OvermindDL1

Yes. Do exactly what you are doing now.

Well currently I am using is=, so keep using it then? I do need my management site to be accessible from non-javascript browsers after all and using pure custom elements would break that.

@oleersoy
oleersoy commented Dec 7, 2016 edited

Well currently I am using is=, so keep using it then?

Yes absolutely. It's currently being polyfilled in almost all the browsers that load your pages, so just use it. We change the spec so that it's DRY and maintain polyfill for all the cases that you need is for.

@oleersoy
oleersoy commented Dec 7, 2016

There's this joke ... NASA Astronauts came back from the space station and complained that they were not able to write in space because the ink would not come out of the pen. So NASA designed a ten billion dollar pen and low and behold it wrote in space. Russia also had the same problem. They used a pencil.

@prushforth

@oleersoy I don't get it- what is the pencil and what is the pen in your joke?

@oleersoy
oleersoy commented Dec 8, 2016

The pencil is the cost of web development if we get the spec right. For example if we do this:

class FancyButton extends HTMLButtonElement

Then that should be all that is necessary in order ensure that that element knows that it is a button and that element should have all the features that (Accessibility, etc.) of the native button element. If we get the DRY part right, then web developers get a predictable, consistent, and symmetric programming paradigm to work with.

If we cut down on the number of concepts we have to understand to deliver the same end result then we cut down on cost. The list of things we should learn now a days in order to be effective is pretty long. Just catching up on the latest specs (Shadow DOM, HTML Imports, etc.) for material related to this issue is a fairly large time investment, and hopefully it's a worth while investment because it brings greater simplicity to our products from a prototyping, implementation, and maintenance point of view.

The is attribute is the pen. That's because it places a massive handicap on the options you have for your application's features. If you are developing anything using the is attribute then that means that the corresponding form of PE that it enables is a priority. Since that's a priority the element that the is attribute is on cannot collaborate with any other custom element on the page, since that breaks the solution. And that is something that developers now need to clearly understand. Also suppose we are using the is attribute and we add other custom elements that your customer or you need. Well now we just negated the need for the is attribute by doing that and all developers should understand this. Do you need a an element with the is attribute and the shadow dom? That could get complicated ...

The is attribute also broadens startup phase for the solution into possibly more than two categories. That adds more units tests, more integration tests, more documentation, etc. It also means that more experimentation and tweaking is necessary because we should want the presentation to be decent all all levels of PE and at least to provide a minimal functionality set, if not all the bells and whistles.

So these are just a few things right off the top of my head. I'm sure if we start looking across a set of simple examples it will become clear that the is attribute is the ten billion dollar pen and that it's very easy to find a pencil to replace it.

@richardkazuomiller

@oleersoy

If you are developing anything using the is attribute then that means that the corresponding form of PE that it enables is a priority. Since that's a priority the element that the is attribute is on cannot collaborate with any other custom element on the page

Why not?

@oleersoy
oleersoy commented Dec 8, 2016

Because if <q is="realtime-publishing"> sends a message to <q is="realtime-receiver">, but the RealtimeReceiver class has not loaded the entire thing is broken.

@richardkazuomiller

You can just wait for everything to load before sending messages.

@prushforth

@oleersoy

Since that's a priority the element that the is attribute is on cannot collaborate with any other custom element on the page, since that breaks the solution.

I believe custom elements generally aren't supposed to depend on other custom elements being in the page, so they work independently. I can't find where I saw that; I think it was in a talk at the Polymer Summit. But if you think about it, the only thing an element should depend on is its own content probably.

Also

class FancyButton extends HTMLButtonElement

is already in the spec but it still needs to identify what element you wish to apply it to because HTMLButtonElement is an interface and elements share interfaces so there is a small problem about what element is being targeted, if its native. That is why we have the {extends: 'button'} parameter in customElements.define, so the actual element which is being overtaken is identified.

adds more units tests,

Don't think this is true. Why would a customized built-in element have more tests? If anything it would have fewer, because it inherits behaviour. Without customized built-ins, as pointed out by others, we can only extend HTMLElement, which doesn't buy you much - you have to re-build everything in javascript.

@oleersoy
oleersoy commented Dec 8, 2016

You can just wait for everything to load before sending messages.

Sure but a lot of people here think that the point of PE is to have something that works even if for example Javascript is disabled. So there you already have one point that is confusing. And that's what adds the expense. You are very smart and yet we hare having this discussion. This is the type of thing that is is going to cause. On the flip side if we just use <realtime-publishing> then there's zero discussion and zero chance for confusion.

@oleersoy
oleersoy commented Dec 8, 2016

I believe custom elements generally aren't supposed to depend on other custom elements being in the page, so they work independently.

Have you looked at for example <iron-routing>, <iron-location>, <iron-ajax>, <neon-animated-pages>, etc.? We have barely scratched the surface of what we will be doing with custom elements, but one thing that is very clear is that they will be collaborating.

is already in the spec but it still needs to identify what element you wish to apply it to because HTMLButtonElement is an interface and elements share interfaces so there is a small problem about what element is being targeted, if its native.

customElements.define('fancy-button', FancyButton);

Identifies that we are creating a <fancy-button> that is also a <button>. The <button> part can be derived from FancyButton extends HTMLButtonElement.

In some case we have the same super class for two elements. In that case the additional specificity can be given or the class hierarchy can be modified such that all native elements get their own superclass.

Why would a customized built-in element have more tests?

Everything you said in this section is correct if we are using the customized built in element in the element form without using is.

If we are using is then it depends on how many levels of PE you have. For example you pointed out that this issue application uses mostly html. Suppose it was composed of many custom elements and some of them did not work right, like the , because the PreviewTab class did not load. So if we want to have a PE level that we accept that the PreviewTab is not going to load then we should create a test case for this, evaluate to see whether that is actually a satisfying enough customer experience, etc. And doing this across all the browsers is expensive and time consuming.

So I agree with you that we should be able to customize built ins. And that way that should be done is by first extending the corresponding built in element's class, then using a define call to target the corresponding custom element, and then using that element in full element form only.

@OvermindDL1

Then that should be all that is necessary in order ensure that that element knows that it is a button and that element should have all the features that (Accessibility, etc.) of the native button element. If we get the DRY part right, then web developers get a predictable, consistent, and symmetric programming paradigm to work with.

And how does that call back to non-JS browsers like elinks? Would the <my-button> work in elinks? No it would not, hence why <button is="my-button"> is necessary if you want progressive-enhancement. In the button case you could wrap it of course, but you cannot do that in all cases, like tables (or templates in tables for JS use, but just tables for non-js use).

@oleersoy
oleersoy commented Dec 8, 2016

And how does that call back to non-JS browsers like elinks?

And this is why it's a 10 billion dollar pen. Instead of using a pencil you are using elinks.

@OvermindDL1

And this is why it's a 10 billion dollar pen. Instead of using a pencil you are using elinks.

If you have know of any other better terminal-mode browsers then I'd love links to them. :-)

@oleersoy
oleersoy commented Dec 8, 2016

If you have to do terminal mode then try vi. Or just download the resource and open it up in atom, eclipse, etc. Dude come on! You don't need the 10 billion dollar pen!! Although it's probably a really good one :).

@OvermindDL1
OvermindDL1 commented Dec 8, 2016 edited

If you have to do terminal mode then try vi. Or just download the resource and open it up in atom, eclipse, etc. Dude come on! You don't need the 10 billion dollar pen!! Although it's probably a really good one :).

Uh, so viewing raw html and curl'ing manually built form responses is better then seeing proper forms and being able to fill them out and submit them with ease? That is one thing that elinks is really good at, as well as other terminal browsers.

@oleersoy
oleersoy commented Dec 8, 2016

better then seeing proper forms and being able to fill them out and submit them with ease?

There's also this thing called a browser ... :)

@OvermindDL1

There's also this thing called a browser ... :)

elinks 'is' a browser that runs in the terminal. We do not always have an X session handy. ;-)

@prushforth

@oleersoy

So if we want to have a PE level that we accept that the PreviewTab is not going to load then we should create a test case for this, evaluate to see whether that is actually a satisfying enough customer experience, etc. And doing this across all the browsers is expensive and time consuming.

then using that element in full element form only.

Nobody is forcing us to use is for a customized built-in, but you have the option to do that and leverage PE if you see fit. Seems to me you are not so much rejecting is= but rather PE, even as an optional feature?

@oleersoy
oleersoy commented Dec 8, 2016

elinks 'is' a browser that runs in the terminal. We do not always have an X session handy. ;-)

Don't worry I'm creating a Kickstarter for OvermindDL right now. We need get you better tools and infrastructure!! :)

@oleersoy
oleersoy commented Dec 8, 2016

Nobody is forcing us to use is for a customized built-in, but you have the option to do that and leverage PE if you see fit. Seems to me you are not so much rejecting is= but rather PE, even as an optional feature?

If NASA wants to build a 10 billion dollar pen that's their business. Why should citizens care?

The spec should be something that moves us forward towards faster, better, and simpler. We all will be using the API that is driven by the spec. If that API is simpler we all gain.

@prushforth

@oleersoy : Who is NASA in your allegory?

If I could sum up, I believe you are saying you support customised built-in elements, but you also say they should not be allowed to have built-in syntax (which enables an important aspect of PE), because it costs somebody something, who's purse you're looking out for.

But beyond the cost of implementing customised built-in elements of the hyphenated variety (which may be significant I grant you, but which you are arguing for i.e. the 9.9 billion dollar pencil), what could be the cost of the non-hyphenated variety of customised built-in element? And not implementing that feature has a cost to others who want to enable that PE; they'll be more likely to build native apps for example. Not to mention the cost to the evolutionary aspects of the Web that I already mentioned.

Thank you

@trusktr
trusktr commented Dec 8, 2016 edited

PE is the only compelling argument. From a development perspective, is="" not so appealing, but for PE it is.

However, in my personal cases, if you don't have JavaScript, I don't care. I'm targeting those people that have modern technologies enabled (and by correlation, those people probably have money to buy/use my products).

If something like <my-button extends="button" /> can be specc'd so that a browser knows to fallback to <button>, then even a text-based browser like elinks can update to follow the spec and it will work there.

If we follow the current <button is="my-button"> in the current order, then there's also the question of what something like <my-better-button is="my-button"> does, and how can that ever fall back to <button>?

Maybe there can be a new non-javascript way of specifying fallbacks for those who really want it, maybe in CSS or some other file (JSON file)?

CSS:

my-button extends button;

JSON:

{
 "extensions": {
  "my-button": "button"
 }
}
@oleersoy
oleersoy commented Dec 8, 2016

@oleersoy : Who is NASA in your allegory?

Anyone who has to spend time explaining the semantics around the is element to their development team or their customers. The net effect of that is going to be very expensive.

What I'm saying though should not be complicated or controversial. The custom element API should be as simple as possible for the biggest use case, which is making things like <paper-button>.

Here is a quote from the spec:

Note: Extending HTMLButtonElement endows our fancy button with all the DOM properties/methods of <button>. That checks off a bunch of stuff we don't have to implement ourselves: disabled property, click() method, keydown listeners, tabindex management. Instead, our focus can be progressively enhancing with custom functionality, namely, the drawRipple() method. Less code, more reuse!

I think this is dead on and genius. That's exactly how it should be. I just don't think that we should have to change the define call when extending native elements. If we extend HTMLButtonElement in order to get all the DOM properties/methods of <button> then that should be enough. To define the element we should just have to do:

customElements.define('fancy-button', FancyButton);

Not:

customElements.define('fancy-button', FancyButton, {extends: 'button'});

The browser should or Polyfill should be able to derive the {extends: 'button'} part due to the fact that FancyButton extends the HTMLButtonElement.

Support for things like is can be added, if necessary, but should not pollute the API for everyone else who is not working an an element that needs is for PE. In other words there should be a core spec that corresponds to the core API that does not deal with PE, and PE considerations can then extend that core.

If I need a shovel, then just give me a shovel. Don't give me a shovel that is both a sledge hammer and a shovel, because I need to expend expend additional energy picking it up every time I want to move some dirt.

I have zero objection to people using is or loving is or doing things with is that perhaps no one should know about.

@prushforth

@oleesroy

The browser should or Polyfill should be able to derive the {extends: 'button'} part due to the fact that FancyButton extends the HTMLButtonElement

I keep typing and you keep ignoring what I type.

@oleersoy
oleersoy commented Dec 9, 2016

I keep typing and you keep ignoring what I type.

Ooops - Sorry. Which part did I ignore?

@WebReflection
WebReflection commented Dec 9, 2016 edited

@trusktr

If we follow the current <button is="my-button"> in the current order, then there's also the question of what something like <my-better-button is="my-button"> does, and how can that ever fall back to <button>?

you did one extend right but you lost it in the second attempt. If it's native that you want to preserve, you'd have <button is="my-button"> and <button is="my-better-button">.

While you'd use {extends: 'button'} for the first case, you'll use {extends: 'my-button'} in the second because being inherited via MyBetterButton it needs to be known.

Accordingly, this is how it could be via current specs, since you have a dependency.

customElements.whenDefined('my-button').then(() => {
  // avoid concurrent re-definition if run more than once
  if (customElements.get('my-better-button')) return;
  // define my-better-button
  const MyButton = customElements.get('my-button');
  customElements.define(
    'my-better-button',
    class MyBetterButton extends MyButton {},
    {extends: 'my-button'}
  );
});

That's it, you preserve backward compatible built-ins semantics, you have the freedom to inherit anything that implements at its root the same built-in.

Accordingly, I don't see your point as a real issue, it's just that is="" is ugly for devs, but like already stated before by others, designers behind templates or people on the FE won't ever complain about.

It works, and it's been working for years, which is why I believe we already have the pencil but few are not realizing it, and they are looking for a pen thinking it'd be simpler.

@prushforth
prushforth commented Dec 9, 2016 edited

@oleersoy

This:

HTMLButtonElement is an interface and elements share interfaces

You said:

The browser should or Polyfill should be able to derive the {extends: 'button'} part due to the fact that FancyButton extends the HTMLButtonElement.

But customElements.define(1,2,[3]) needs a third argument when used with customized built-ins because it needs to identify from among many, the one element which should be sock puppeted.

@trusktr
trusktr commented Dec 9, 2016 edited

@WebReflection

<button is="my-button"> and <button is="my-better-button">

That makes sense, but someone else might do it the wrong way that I pointed out. In order to have a consistent API, <my-better-button is="my-button"> should also work (although it doesn't fallback). The my-better-button and my-button in <my-better-button is="my-button"> should be able to be built-in names or custom element names just the same.

While you'd use {extends: 'button'} for the first case, you'll use {extends: 'my-button'} in the second because being inherited via MyBetterButton it needs to be known.

This is where I lean on what @oleersoy is saying: that the 3rd argument should not be required (one of the original points of my OP).

Also, without the 3rd argument, that whole customElements.whenDefined hack won't be required. That is really ugly because now imagine how Custom Element authors are going to write ES6 modules to define elements that extends other elements. The module author will have to export a promise, and anyone who imports a class from that module will have to await a promise. I don't think that is ideal, it adds a new level of complexity compared to synchronously exporting a class definition and then importing it synchronously in another module.

So, if the is="" attribute API is something that we would keep, I would argue these points:

  1. No 3rd argument to customElement.define should be required, so just customElements.define('fancy-button', FancyButton);, not customElements.define('fancy-button', FancyButton, {extends: 'button'});.
  2. Modify the spec to require all built-in elements to match one-to-one with built-in classes. We will need a base class with common functionality for quote-like elements in true object-oriented fashion, then HTMLQElement, HTMLCiteElement, and HTMLBlockquoteElement for the specific element classes. This automatically eliminated the need for the ugly {extends:} argument.
  3. <button is="my-button"> and <button is="my-better-button"> is the recommended way to use PE where in that example the class associated with my-better-button extends from that class associated with my-button, via JavaScript inheritance without the {extends:} argument.
  4. should still work. Whenmy-buttonis not available,my-better-buttonshould be used, even ifmy-buttondoes not extendmy-better-button`.
  5. The argument to the is="" attribute is not required to extend the element owning the is="" attribute, and in no way should the is="" attribute signify that the specified element extends the owner element. For example, in <some-element is="unrelated-element">, when the definition for unrelated-element exists, then the element is instantiated (upgraded) as an instance of the class associated with unrelated-element with whatever prototype inheritance it happens to have, which may not include the prototype associated with some-element. If the definition for unrelated-element does not exist but the definition for some-element does, then the element is instantiated (upgraded) as an instance of the class associated with some-element, which may have a prototype chain that is completely unrelated to the prototype chain of the class associated with unrelated-element.

If the API is like that, it will be more DRY, and it will be more useful specifically for people who want any form of progressive enhancement of built-in elements or custom elements alike. At that point, any argument against the API is really an argument against progressive enhancement IMO, not an argument relating to the confusion that happens due to the fact that currently the API is limited to use with built-in elements, not an argument relating to the fact that both is="" and {extends:} are required, and not an argument relating to possible confusion from is="" being used to define inheritance. If JavaScript is available, then inheritance shall be specified that way, otherwise the fallback of the element should have nothing to do with JavaScript inheritance (and HTML doesn't care about the inheritance at that point because JavaScript is not enabled to begin with!).

The outcome of my points above is that now the is="" attribute doesn't specify inheritance at all, it is strictly a tool for progressive enhancement which is the only reason in this thread that people want the is="" attribute, so if we keep it lets make the API clean. If the value of is="" is an element that happens to extend the element that owns the is="" attribute, then that should be considered only a coincidence, but it should not be a requirement.

For example, this should be possible: <video is="awesome-button"> where when awesome-button is not defined, a video (HTMLVideoElement) is played on the screen, and when awesome-button is defined (and extends from HTMLButtonElement) then a button with button behavior is seen on the screen. Maybe the user's progressive enhancement idea in this example is to show a video that makes fun of the end-user who has an outdated browser that doesn't support custom elements, and makes them feel like they should get a new browser!

@prushforth I think you missed the idea that @oleersoy (and me too after I realized the same fact that you are pointing out) has been trying to convey multiple times: that browsers should not share interfaces across multiple elements, but rather that browsers should implement a single class per element. See my points 1 and 2 above.

@WebReflection
WebReflection commented Dec 9, 2016 edited

@trusktr

For example, in <some-element is="unrelated-element"> ..
For example, this should be possible: <video is="awesome-button"> where when

I don't think the scope of this specification is to fix possible bad architectures or UX.

You can still class BetterDate extends Boolean {} in JS but that doesn't mean that the core should reject anything non-sense like a class extending a native behavior in a pointless way.

Like I've said, we have already the pencil, which is the is="" attribute, you want magic that would require much more effort from vendors and specs authors, which is the costly pen, IMO.

Yes, in an ideal world the runtime would understand all the things but that's not fast moving forward approach.

It is a possible V2 but right now we need to finalize at least V1 across browsers.

@oleersoy

@prushforth I think @trusktr answered it for me. If we invest some effort into cleaning up the hierarchies and making sure that extending classes like HTMLButtonElement can be done in a simple way (In other words there's no ambiguity) we will have a cleaner solution.

@rniwa also pointed out that some inheritance cases would lead to violation of the liskov substitution principle. We could identify these cases and come up with other classes that are more suitable for inheritance / mixins. For example if inheriting from the HTMLButtonElement leads to a violation, perhaps a AbstractHTMLButtonElement would be a better fit for inheritance in general.

If some browser vendors are deciding to delay jumping onboard because they feel that the above situation should be addressed first in order to have a clean and simple solution, then we will be polyfilling those browsers for a long time.

My sense is that some people from other vendors are insulted that their views are being disregarded. If that's the case then they could end up hitting the breaks on supporting implementation of the specs. That's more collateral damage for all of us. I do think though that the vendors should voice their opinions and back them up with code and simple examples in open channels like this one.

On the flip side I agree with @WebReflection (God help me :) ) that it's good to push forward and try to get things working even if it's not a 100% perfect, because we will get utility out of it and learn and possibly even discover a few new cool things that are side effects.

However if we get the inheritance hierarchy right and get a simple clean API then that's less refactoring of components that all of us will be doing down the road. If we all rolled up our sleeves and took one class each, we could probably finish up before midnight and grab a few beers!

@rniwa
Contributor
rniwa commented Dec 10, 2016

FWIW, we have no doubt that being able to extend a native builtin element is useful. However, we don’t think the customized builtin as currently spec’ed is the right approach. We have provided more nuanced feedback about various aspect of is attribute in the past.

We could have spent another three years debating how to do it properly but we wanted to focus on the minimum viable product that can be shipped on all browsers sooner than that. This is why we’ve been advocating to move this feature to v2 level, and focus on shipping on the autonomous custom element for now.

Note that there were many other proposals and features, some of which are extremely simple like automatically cloning template contents in attachShadow as an optional argument, we wanted to add in v1 Shadow DOM and Custom Elements APIs but we retreated those in the favor of shipping the MVP sooner.

@prushforth

@rniwa Very glad to hear that you also think extending native builtins is useful. I hope you are able to come to some agreement with your peers over this. FWIW, I think is works quite well for the map element and I would be very interested to hear your thoughts on improving on is for PE-focused HTML authors, for whom is will make custom elements useful.

@oleersoy

Also to @prushforth point about thoughts on utilizing PE for the map element it would be nice to have a repository of dead simple examples that are minified real world use cases and prototypes that we can point to as these discussions are progressing. Something similar to the TodoMVC for Single Page Apps, but instead of selecting a framework the goal would be to demonstrate the viability of the new spec as implemented per the prototype. It's a lot easier and productive to avoid the type of friction that arises from discussion at an abstract level when it's done from the vantage point of a simple example.

@WebReflection

@rniwa

We could have spent another three years debating ...

FWIW, the reason most of us are here defending is="" is that nobody wants to wait other 3 years before being able to extend native builtins, specially when is="" solution,as ugly as it is, already worked for the last 2 years and keeps working without problems polyfilled.

Any possible improvement for V2 would be welcomed by everyone, but how about we move the Web forward today ?

@Zambonifofex

@WebReflection

I think it’s important to take the time to do things right, instead of rushing to “move the Web forward today”.

@oleersoy

Any possible improvement for V2 would be welcomed by everyone, but how about we move the Web forward today?

I have to say I love the spirit of this in general. Some things are stuck in the debate stage forever. For example the OAuth2 spec lead resigned due to the endless debate over every nuance of the spec.

The next consideration then is how much refactoring needs to be done to the components and apps once they move from V1 to V2? For example the shadow dom content element got switched to a slot element. So now all the components moving to version 1 of the shadow dom that utilize the content element have to be refactored and retested. How much documentation has to be rewritten, etc?

In addition if we had version 2 now, how much efficiency do we gain in the development process for new elements?

I think if @trusktr suggestions are incorporated into V1 we could end up saving ourselves a lot of time in the long run and possibly gain some goodwill from all browser vendors such that we get this working across the board quickly. Also if the development picture is prettier, we should be getting a lot more traction with other open source developers. Right now ReactJS, etc. still seem to be the preferred approach over Polymer, and personally I would love to see Polymer get a boost.

@WebReflection

@Zambonifofex sure, let's start dropping Web IDL then, as practical and fast-forward moving as that is.

Meanwhile, all third parts frameworks would've become the de facto standard abusing HTML attributes as much as they can and for any sort of behavior they want, winning in delivery and perhaps performance too.

@Zambonifofex

@WebReflection

Well, I don’t think we should just stop in time, I just don’t want bad, unthoughtful, and non‐future‐proof APIs to be welded into the Web forever.

[…] specially when is="" solution,as ugly as it is, already worked for the last 2 years and keeps working without problems polyfilled.

I said it before, and I’ll say it again: it “working” doesn’t mean it’s something good from a language‐design/API‐design perspective.

By the way, I’m not saying I dislike is (I do like it, and hope that it stays), I’m just disagreeing with your arguments for it.

@oleersoy

Here's something that's indirectly related. If we read up on the Shadow DOM V1 Spec we see a lot of examples like this:

header.attachShadow({mode: 'open'});

And then when we get to the bottom of the spec there's a big section creating closed shadow roots and why we should avoid this (NEVER EVER EVER EVVERRR Ever DO THIS).

div.attachShadow({mode: 'closed'})

So you step back for a moment and say "OK if we should never make it closed, then why do all the example calls declare it to be open?. Why is this not just the default?" Or maybe it is, but it's hard to tell from the write up and it definitely seems like something is broken in the W3C process.

If we took this type of approach in manufacturing we would get a lot of recalls. Recalls are expensive. It's a lot more profitable to make sure the quality is tight upfront. It also leads to happy customers.

Not only that but if collaborators get the sense that we are going to shoe horn the spec in even it starts to effect moral. It will also make some customers go ... hmmm maybe I'll skip Playstation 2 and just wait Playstation 3.

Lastly supposedly this has been in play for two years now. So why is this stuff not ironed out? The dream team is on the field and yet we are having a hell of a time getting a touch down.

@WebReflection
WebReflection commented Dec 11, 2016 edited

@Zambonifofex

it “working” doesn’t mean it’s something good from a language‐design/API‐design perspective.

remember Python 3 intent was to fix all Python 2 bad designed things?

This is how it ended up:
https://www.naftaliharris.com/blog/why-making-python-2.8/

In a nutshell:

practicality beats purity

and I couldn't agree more for this specific case too.

@Zambonifofex

@WebReflection

Well, I’m not saying we should redo the Web because there are some badly designed APIs, but if we have the chance to make a new API, I think we should take our times to make it be the best API we can.

@WebReflection
WebReflection commented Dec 11, 2016 edited

@Zambonifofex

I think we should take our times to make it be the best API we can

Agreed, but for V2, not V1 which is already spec'd and should be just deployed "as is" ¯\_(ツ)_/¯

@trusktr
trusktr commented Dec 11, 2016 edited

For those that want progressive enhancement (which so far is the only argument for keeping is=""), why not just

<web-map>...</web-map>
<noscript><map>...</map></noscript>

? That seems to achieve the same thing. A downside is that HTML has to be duplicated, but that is no problem when using a template engine to dynamically insert identical content.

Here's other ways:

<web-map></web-map>
<noscript><map>...</map></noscript>
<script>
  // If javascript is enabled
  var $ = document.querySelector.bind(document)
  var map = $('noscript > map')
  var webMap = $('web-map')
  webMap.innerHTML = map.innerHTML
  // copy attributes too if needed
</script>

or

<div id="map-container">
  <map id="map">...</map>
  <script>
    // If javascript is enabled
    var webMap = document.createElement('web-map')
    webMap.innerHTML = window['map'].innerHTML
    // copy attributes too if needed
    window['map'].remove()
    window['map-container'].appendChild(webMap)
  </script>
</div>

Is there something we can achieve with is="" that we can't achieve with tricks like above besides avoiding duplicate HTML?

It might be better to use these slightly-more-verbose methods (they work!), and wait until is="" can be cleaned up.

I see how is="" is useful for progressive enhancement, but currently the API isn't clean when disregarding PE. We should be able to achieve non-PE things with <autonomous-elements> using JavaScript inheritance without the {extends:} argument. After inheritance is cleaned up and JS-centric, is="" can be added as a convenient way to achieve the PE examples above.

@tomalec
tomalec commented Dec 12, 2016 edited

@trusktr

Is there something we can achieve with is="" that we can't achieve with tricks like above besides avoiding duplicate HTML?

#509 (comment)

I would say PE is not the hardest part to workaround that is gives,
parsing context is.

Do you have any nice solution for following? (other than in fact polyfilling is in current shape)

<table>
 <my-tr>
<my-template>
   <div>This should be unavailable for `querySelector`, CSS and rendering
<form>
   <my-input>which value will get serialized
@WebReflection

@trusktr try doing that with my-form that contains my-input and my-button

TL;DR no, noscript is not even close to an alternative solution

@tomalec
tomalec commented Dec 12, 2016 edited

@oleersoy Speaking of pen vs. pencil, pencil tips introduces fire hazard, see Apollo 1

Keeping, the allegory, making small tip set your ship in fire, making lack of is let you loose support for elements with different context, which you cannot rebuild, nor polyfill anyhow, may be pretty expensive.

@trusktr
trusktr commented Dec 12, 2016 edited

@tomalec @WebReflection

For things like

<table>
 <my-tr>

Can you just use CSS to style my-tr elements the same as the browser's default styling for tr elements?

<my-template>
   <div>This should be unavailable for `querySelector`, CSS and rendering

This is not a solution to be solved with is="". Browsers should be cleaned up, and anything that extends from HTMLTemplateElement should behave as a <template> element does. Anything that extends from HTMLTableRowElement should behave as such. Etc. If you're targeting very old browsers (Maybe 3rd world countries, etc), then my vanilla examples above already provide insight into how to make that possible. For example,

<div id="container">
<table>
 <tr></tr>
</table>
<div>
<script>
 var c = document.querySelector('#container')
 c.innerHTML = c.innerHTML.replace('<table', '<my-table').replace('<tr', '<my-tr')
 // it works in modern browsers, in old browsers, and in browsers with JS disabled.
</script>

It is a little more verbose, but it doesn't rely on a not-yet-solid API. It is also possible to make shortcut APIs for the previous types of example (i.e. you could polyfill is="" yourself as a shortcut, without relying on the browser shipping a unclean API). For example, when JavaScript is available:

<div id="container">
<table>
 <tr></tr>
</table>
<div>
<script>
 is('#container', {
  table: 'my-table',
  tr: 'my-tr',
 })
</script>

or

<div id="container">
<table>
 <tr></tr>
</table>
<div>
<script>
 is('#container > table', 'my-table')
 is('#container > table > tr', 'my-tr')
</script>

I'd also like to state again that modern browsers should use something similar to instanceof HTMLInputElement, etc, to make sure autonomous custom elements behave as expected.

@trusktr
trusktr commented Dec 12, 2016 edited

Those last three examples are assuming browsers do that aforementioned checking of instanceof to ensure that things behave as expected. In browsers where that isn't the case, the custom elements can render to DOM separately. For example, one could write

<my-table>
 <my-tr></my-tr>
</my-table>

and the actual result when you inspect element could be

<my-table>
 <my-tr></my-tr>
</my-table>

<!-- rendering result -->
<table>
 <tr></tr>
</table>

where any changes to the custom elements are reflected into the rendering result, and any DOM events on the rendered elements are forwarded to the custom element logic. There's ways to accomplish these things without relying on is="".

I agree: in concept, is="" is nice for PE and for those edge cases like table > my-tr, but when looking at it from the perspective of component programming, it is not so clean (yet) as far as inheritance goes. It would be awesome for that to be cleaned up. And once it is cleaned up, as I mentioned, then the is="" attribute (used for PE or for fallback cases like form > my-input) doesn't even need to have anything to do with inheritance at all.

@oleersoy

@oleersoy Speaking of pen vs. pencil, pencil tips introduces fire hazard, see Apollo 1

Wow the joke is actually real. I though it was just a joke!

Keeping, the allegory, making small tip set your ship in fire, making lack of is let you loose support for elements with different context, which you cannot rebuild, nor polyfill anyhow, may be pretty expensive.

Maybe but to me it still seems like we are making a 10 billion dollar pen, even though we could just bring our Samsung Note. Just don't bring the Samsung Note 7. That one was rushed a little bit and next month it will officially be useless.

I'm not going to be shocked if the is attribute ends up being useful in ways that we have not even thought about yet, but at least get the API design right. The fact that it's been in play for 2 years and still has not been cleaned up feels like a massive red flag to me. Doesn't the W3C have a room 30 floors down in the basement where everyone can be locked up and no one comes out until the best solution is drawn up?

@oleersoy

The main issue I have with PE as it is implement here is that it does handicap the solution / app. The minute the client wants two more custom elements that collaborate in the page, the functionality implemented with the is attribute for the purpose of clients that need PE becomes useless. So the client comes up to you and says "Hey can we add this and this and this to make the page really awesome!!??". "Nop - sorry Ed - this is a PE App. We've told you before and we'll tell you again NO awesome stuff! Now go back to the lunch room and play pong.".

But why does it have to be like that? The best possible solution we can imagine here will allow us to use any custom element and still achieve PE.

@prushforth

@trusktr As I may have mentioned, the map element is intended to be a proposal to extend HTML essentially.

On top of that, all your examples seem quite willing to make life complicated for HTML authors, but you decry a third argument to the API function as not DRY or ugly etc. I am trying to make the HTML author interface as simple as possible, and web-map is a step in the wrong direction.

@oleersoy

@prushforth it's a great example of how something could work, but from a practical standpoint could it work? Usually we see maps links displayed as a micro map image on company, store, and restaurant site. So I go to http://ole.com and one of the links is location and the rest of the site is other stuff. So if the rest of the site is built with Polymer and includes functionality from <iron-ajax>, <iron-location>, <iron-routing>, etc. then with JS off the <map is=web-map> map will still work, but the rest of the site is broken, because none of the other stuff will work without javascript enabled and then some.

@prushforth

@oleersoy The only dependency is Leaflet, which has no deps. So the intent is to make it a prollyfill that will work until native implementations are available.

Of course, native implementations won't all happen at once. So the PE aspect is important not for when JS is turned off, but for when the JS implementation will actually be the fallback.

@tomalec
tomalec commented Dec 12, 2016 edited

@trusktr

For things like

<table>
  <my-tr>

Can you just use CSS to style my-tr elements the same as the browser's default styling for tr elements?

I cannot as (at least the old browsers) will put <my-tr> outside of <table> and we cannot just break backward compatibility, like that.

Browsers should be cleaned up, and anything that extends from HTMLTemplateElement should behave as a <template> element does. Anything that extends from HTMLTableRowElement should behave as such

I do agree that conceptually, that is nice and clean. Once we extend it with class MyTr extends HTMLTableRowElement we should be able to use it as just <my-tr>. However, even if we would get all the a11y, parsing, styling, serializing behavior, and disregard PE for a moment, by limiting ourselves to just this syntax we will loose readability from HTML perspective. The new-comer will have to read (minified) JS source to figure about whether <my-element> behaves more-or-less like <tr>, <tbody> or <caption>.

Even though I'm not a browser implementer, I would expect that changing parser behavior in run-time would be extremely expensive.

The solution with

 c.innerHTML = c.innerHTML.replace('<table', '<my-table').replace('<tr', '<my-tr')

Would trigger a lot of unnecessary DOM mutations, re-paints, FOUC, etc.

I wouldn't say <my-table><my-tr> is a solution, as just to deliver custom <tr> I would have to re-implement <table>, <thead>, <tbody>, etc. and what is even worse, force my user (developer who consumes my CE) to use those. Instead, for example <trusktr-thead> which could be awesome and needed as well. So we are loosing composability, which is in my opinion key feature of CE and HTML in general.

BTW, I do agree that sticking to polyfill of just is="" until V2 will somehow address this problem is a way to go and that's the way we "moved the Web forward" for recent years. Especially that's the price for getting the rest of V1 sooner.
I just want to state, that there are use-cases which are not covered w/o is. Plus, polyfill which covers it in 100% is not trivial (if even possible).
That's why, I would really love to hope, that someday the solution would be in the signed spec.

I also feel the pain explaining the change from V0 to V1 instead just advertising a new feature/spec. But, I feel there is a significant group of developers who already rely on is since V0, so we are already here.

@oleersoy

@prushforth we are saying two different things, but you brought up an important point.

Take the polymer shop demo for example. It uses a lot of Polymer components / custom elements. We could put a progressively enhanced map element in the About us view and it will still render even if Javascript is turned off. But with Javascript turned off the whole thing is turned off. It's like having a progressively enhanced oven. If the gas line is not connected, it does not help that some knobs are progressively enhanced.

Now with respect to direct component dependencies that's another important area that could be confusing for developers and customers. You could have an <swan-map> element that does declare dependencies and those dependencies have transitive dependencies and when javascript is turned on the thing just blows the customers mind and they want it! But it's also supposed to work when javascript is turned off, and the minute that happens the <swan-map> turns into <uglyduckling-map>. So as you will see in my upcoming comment both the messaging WRT the is element and the developer experience can is confusing.

JS implementation will actually be the fallback.

The thing is that when we are doing <map is="swan-map> we are assuming that Javascript could be turned off. That's the whole point of it. If javascript is definitely going to be available then we might as well do <swan-map>. So if we agree that that is the smart thing to do, and go one more step further and get browser vendors to relax schema restrictions so that @tomalec can put a template element right smack in the middle of the table then we have solved this in a far more elegant way that is less confusing for everyone (Customers, project managers, developers, people that have to write this stuff up and loose a lot of their hair in the process, etc.).

@prushforth
prushforth commented Dec 12, 2016 edited

@oleersoy Yes, my apologies for not addressing your point exactly. A bit of a fog at 6 this morning :-)

If none of the components work on a page that is quite a catastrophe, I guess, but at least the map would still show up if the HTML author had taken the care to provide an image map fallback, not that everyone would care enough to do so.

That's the whole point of it.

Not quite the whole point; I guess not a lot of people shut JS off; perhaps a more important point is to progressively enhance towards swan-map as much as possible, given the availability of network resources. So, the <map is="swan-map"> would load as much of its content (assuming all the JS loads) as it can, and display what it can. I think even if none of the layers loads, if the img upon which an image map is based loads, the JS implementation of swan-map (of either built-in or autonomous variety) could still provide a responsive version of the image map, at least. So the 'progressive' part can be partial, it does not have to just be a complete fallback, but the complete fallback is always there as a backstop for the <map is="swan-map"> version. That is what is so compelling about customized built-ins: they permit and encourage the evolution of the Web because we can say, hey users and platform guys, how about this feature for HTML%name%Element??? Autonomous elements are nice and all, but they lack this feature, IMHO. If we had to build this stuff in C++, it would not get the exposure that a Custom Element can; it would have to be behind a flag or something like that, it would have no chance of actually becoming popular in the real world etc. Customised Built-Ins allow us / the Web to experiment in the real world.

If javascript is definitely going to be available then we might as well do .

Just to reiterate, the part where 'no JS' gets interesting to me is when the HTML author wants to use the native implementation of <map is="swan-map"> where available thus not needing the prollyfill. Where the native implementation of <map is="swan-map"> is not complete, the Customized Built-In <map is="swan-map"> is used; CSS selectors and JS references don't need to be changed. So it's not like saying everyone should disable JS - far from it! It's using JS to enhance the user's experience where possible/necessary. That is all. Such a scenario can't play out under the 'no is="..." ' future; everything would be a <swan-map> which is why I asked @rniwa what he sees as a reasonable replacement foris.

@oleersoy

I cannot as (at least the old browsers) will put <my-tr> outside of <table> and we cannot just break backward compatibility, like that.

That's true but the PE thing to do then is to display a message to the user that they need to upgrade their browser. That's option 1. Option 2 is to use ReactJS, EmberJS, AngularJS, heck even Dojo, or one of the 1000s of other MVC frameworks that have already solved this so that it does work across all spectrum of browsers.

We really need to start realized that the spec is not something that is our personal toy for our personal use case. Some of the smartest developers looking at this are all here and it's obvious that even with this microcosm there is already a lot of confusion so how is that going to translate to a great developer experience?

The new-comer will have to read (minified) JS source to figure about whether behaves more-or-less like <tr>, <tbody> or <caption>.

Come on man! You can look at the rendering. If you are putting <my-tr> inside a table then that's probably your element or an element that you gave to your developer to put inside a table element. If a html author sees it inside a table element then they are probably smart enough to figure out that it belongs inside the table element. Lastly if someone is looking for custom elements that work in the context of the native <table> element then they are probably going to search through the Polymer catalog, NPMJS, or some other catalog where you have tagged that element as working with <table> elements. If you are assign work that involves custom elements then assign it to someone who knows how to work with custom elements.

Would trigger a lot of unnecessary DOM mutations, re-paints, FOUC, etc.

That's true but again this is the Higgs Boson fall back. It's only being done because your requirement is to support Higgs Boson browsers instead of just telling the user to upgrade their browser or using one of the 1000s other solutions that will work better.

So we are loosing composability, which is in my opinion key feature of CE and HTML in general.

We are loosing it but only because there is a schema restriction that browser vendors had to implement around.

I also feel the pain explaining the change from V0 to V1 instead just advertising a new feature/spec. But, I feel there is a significant group of developers who already rely on is since V0, so we are already here.

They can still rely on it. No one is forcing anyone to upgrade. And the only reason I care is that by catering to a few, we will loose the many.

@oleersoy

@oleersoy Yes, my apologies for not addressing your point exactly. A bit of a fog at 6 this morning :-)

Don't worry was up all night with an itchy throat so I'm a little surprised that I can even type right now :). Good things this is not a call in!

I understand all your points and personally I love working on this type of stuff and annoying everyone with it (A lot of people run away when they see me coming - "OH @#$#@ it's Ole") which is why I think I know how this is going to end. The thing is developers are picky bastards and if something is a little bit more complicated they just go with option B.

The same thing goes for customers. If someone pops up a "You are using an ad blocker" message on their site I hit ctrl-l and do the search again and google finds 10000435325345642 results within -532.00 milliseconds and I just click on the next best one.

And what about the "We are using cookies" message that everyone now has to click. 99.999999999% of users don't even know what a cookie is, so we are we making everyone click that!!??

@prushforth

@oleersoy I don't follow your point here, sorry.

The thing is developers are picky bastards and if something is a little bit more complicated they just go with option B.

What is option B here, please? If it's Waze/Google Maps, I get the feeling you're saying YouTube is simpler than <video src="...">

@oleersoy

Two points really. The first is that when a developer is tasked with making a shopping website, or a restaurant website, or a stock tracking site or even a site that sells pet monkeys they are going to choose a set of elements that allow them to do this rapidly. They don't really care or want to worry about whether the Higgs Boson scenario is going to play out well.

Second developers that are contributing to open source React, or Angular, or whatever their favorite framework is they usually do it because there are a lot of compelling parts of the framework that makes their life simpler. We are already well on our way to gathering those WRT to ShadowDOM, CE, etc. These are killer features that hopefully will lead to more developers taking the plunge and joining the CE community, unless we muck it up with confusing messaging and features.

@prushforth

@oleersoy I frankly don't understand your point. I am not a nuclear physicist, nor a particularly skilled web developer, but even I understand the is concept. I guess we can just agree to disagree, and leave it at that hopefully.

@oleersoy
oleersoy commented Dec 12, 2016 edited

nor a particularly skilled web developer

Me neither, but looking at your map demo I would thought otherwise! It's really not about whether you or I or any of the MIT graduated Google engineers get the concept. It's about whether it's confusing for the average developer and the fallout of the results from that.

Xerox Parc had the best R&D talent in the world at their peak. They invented the first mouse, the first UI, the first network and yet they did not get it to mass market. In order to cross the bridge from cool tech to mass market viability it has to be slick and simple and fit well with the greater whole and right now it doesn't.

@WebReflection
WebReflection commented Dec 12, 2016 edited

It's about whether it's confusing for the average developer

it's apparently not, read his comment which was:

even I understand the is concept

Keeping talking FUD about how difficult is for everyone to understand is="", which has been used and understood for the last 2 years, is not moving anything forward.

Talking about alternatives that do not cover what is="" covers already is also not moving anything forward.

Web developers are tired of these new but never trust-able APIs and every dev that believed and used what Web Standards proposed got it, swallowed the "not perfect" solution, and moved forward adopting it.

People against is attribute in this thread are only those that never used it and never investigated why it's needed, I've honestly no idea why we're still talking about it because there's no need to convince anyone about its usefulness, just propaganda about not having it, without valid alternatives for today needs.

I start believing myself this thread should be closed. It's bringing literally nothing to the discussion, including my over-stated comments.

Best Regards

@oleersoy

The problem with you @WebReflection is you view yourself as the ultimate judge of what is valuable discussion and what is not.

@WebReflection
WebReflection commented Dec 12, 2016 edited

No. I simply think from this comment on there's seriously nothing new to the plate.

Everyone that used is so far never complained about it, people never using it, guessed its value.

Most of them didn't even know that <table><my-tr></my-tr></table> doesn't work by specs but felt entitled to guess the is value, talk about NASA, etc. etc.

This thread should be closed as incapable to evolve, IMO, specially 'cause new comers never even tried to read previous comments, just decided it was their time to speak, without any background fact check.

Best Regards

@oleersoy

I read the entire thread top to bottom and that's why I understood @rniwa comment. @trusktr opened the issue, so it's fairly safe to say that he knows what he's talking about.

The reason the W3C process is broken is you. If it does not fit with your agenda it's worthless information and who ever is presenting it does not get it.

So go ahead close it up and good luck obtaining mass appeal as well as future input and collaboration.

@WebReflection

I read the entire thread top to bottom

nope

X opened the issue, so it's fairly safe to say that he knows what he's talking about.

nope

The reason the W3C process is broken is you.

sure

go ahead close it up and good luck obtaining mass appeal as well as future input and collaboration.

we might be in the same ship here, but I'm just a web developer that uses web standards and tries as hard as possible to ignore 3rd parts solutions to the web platform so ... I can't close anything.

I'm also unsubscribing from this repo for a while so don't worry.

Best Regards

@oleersoy

I'm also unsubscribing from this repo for a while so don't worry.

So talk to you tomorrow :)

@hax
hax commented Dec 13, 2016

Hi guys I just can't bear anymore, is there any way I can block oleersoy, hide all his helpless comments in my timeline but still see other comments in this issue?

@lgh06
lgh06 commented Dec 13, 2016

go to his profile page,try block him.

@Zambonifofex
Zambonifofex commented Dec 13, 2016 edited

@oleersoy

Would you mind re‐explaining to me what do you have a problem with? I seem to have lost it in all the discussion…

I see you don’t like is, but do you think it’s important to be able to extend built‐in elements? If so, what do you propose as a solution? One can’t simply say “allow <my-tr>”, for the multiple problems it brings (as stated several times already).

You may feel it’s unnatural (I feel so too), but it’s the best working solution we currently have.

Honestly, I’m starting to agree with @rniwa and Apple more and more that it might be better to simply not allow extending built‐in elements; at least not in the same way we extend custom elements.

(by the way, @oleersoy, you seem to think @WebReflection is from the W3C, which is simply not the case. Heh 🙂😜😝😝)

@oleersoy

Would you mind re‐explaining to me what do you have a problem with? I seem to have lost it in all the discussion…

Hehe. OK. Basically we have three core arguments for is so far. And I'm going to make this as dead simple as I possibly can.

Argument 1: NO SHOWER (Javascript)

We go in the shower and turn the progressively enhanced shower knob and no water comes out. But we still feel good because at least we can see the shower knob.

Argument 2: NO WATER (Network)

We go in the shower, turn the progressively enhanced shower knob, and one drop of water comes out. We have a special cloth that is designed for living on Mars that we catch the drop with and with that drop and some special soap we can actually clean up a little bit. Don't use normal soap though because it will completely negate the function of the special cloth.

Argument 3: AIR CONDITIONING WAY TOO COLD (Schema too Strict)

We are sitting in the house and it's freezing. Fifty degrees. So we go and grab our best North Face gear and some heavy blankets and sit down to watch Netflix.

The air conditioning is not our enemy. We just turn it up to 70. Maybe there are times when only one drop of water comes out of the shower, but how many people actually have that problem and if that's the case could you borrow your neighbors shower?

Honestly, I’m starting to agree with @rniwa and Apple more and more that it might be better to simply not allow extending built‐in elements; at least not in the same way we extend custom elements.

It might be a genius point for now. Instead of extending built ins, replicate the features of the built ins in external classes, extend those classes to get the features needed, and then consolidate that with Web IDL, and finally we will have a clean fit.

@Zambonifofex

Honestly, I’m starting to agree with @rniwa and Apple more and more that it might be better to simply not allow extending built‐in elements; at least not in the same way we extend custom elements.

It might be a genius point for now. Instead of extending built ins, replicate the features of the built ins in external classes, extend those classes to get the features needed, and then consolidate that with Web IDL, and finally we will have a clean fit.

ahem #567 ahem

@oleersoy

@Zambonifofex I see you did a little thinking about this - Lightweight, simple, unobtrusive, puts the power in the hands of the developer. But seriously, this would be like using a scalpel to perform surgery. Who's going to go for that?

@oleersoy

BTW @WebReflection I probably offended you. I just call it the way I see it, but it is not my desire to offend you or make you go away. I think if we all take a solid look at this we will come up with something great that is a good fit for all of us. We can all win.

@trusktr
trusktr commented Dec 14, 2016

The solution with c.innerHTML = c.innerHTML.replace('<table', '<my-table').replace('<tr', '<my-tr') Would trigger a lot of unnecessary DOM mutations, re-paints, FOUC, etc.

So would is="", because <tr is="some-thing"> may first render as <tr> until some-thing is ready, then it will re-render to <some-thing>.


I have a crazy but awesome idea: How about browsers take the "native" elements and re-write them entirely with JavaScript using Web Components APIs. This would make them moldable/hackable/monkey-patchable/extendable/breakable/mixinable/etc to the web developer's needs. If we did this first with problem elements (table, tr, form, input, etc), then web developers would inevitably solve the problems in various ways. Imagine the "native" (non-interpreted) side of a browser is merely a platform that allows for elements to be defined (Custom Elements), and that all pre-existing elements are merely custom elements. The used-to-be-"native" elements would still be native, just that they are defined in the browser's native JavaScript context, not the web app's context, and would still work even if javascript is "disabled". This will give us all a clear picture of how the web works and how to modify it. It would be a big undertaking, but would have awesome results.

@Zambonifofex
Zambonifofex commented Dec 14, 2016 edited

@trusktr

I think literally everyone here would want that. It’s simply not realistic. How would one implement template? script? style? html/body/head? audio/video/picture/source/img?

@oleersoy

It seems a lot of the people advocating for is really wanted to be able to PE the table element. Specially they wanted to do things like:

<table>
   <rainbow-row>

IIUC this blows up because <rainbow-row> gets booted by the parser as it's building the dom model. I think it's fine though if a <rainbow-table> is provided correspondingly.

Anyways since this scenario is so important to many of the is advocates here I'm just placing an appeal that it be one of the primary scenarios driving the investigation of the API and hopefully one of the first test cases for any V2 API improvements.

I'd also like to appeal to everyone to focus in on the "Why?". You want the is element, but "Why?" do you want it? If we can deliver the "Why?" fast natively for given concrete scenarios without a big bang approach like is then hopefully no one feels like they are being left out in the cold.

@prushforth I know you have been doing a lot of work on PE maps, so I hope the underlying considerations there become one of the primary drivers / test cases as well.

@oleersoy

Just want to point out one more thing that should probably be incorporated into the design framework. With native components we can use BEM modifiers like this (From Philip Walton's Extending Styles article):

<!-- Using a BEM modifier -->
<button class="Button Button--small">Download</button>

With custom elements that maps to:

<!-- Using a Web Component with an attribute for variation -->
<my-button small>Download</my-button>

My only point here is that it is less than straightforward to consolidate this type of architectural approach with the is attribute. So it's an example of how the is attribute puts a constraint on the element designer.

@appunnicer13

I think W3C should go with is="" .
Reason 1 : People don't always live in Cities where internet is a basic need. There are more villages than cities . So internet speed is not so great in those places. If the default behaviour is not set then what they see when page loads will be some spaghetti half eaten. So by using is="", we will have that basic support for elements by default.
Reason 2 : I use 100 different buttons in a page, almost every actionable item is a button, round button , rect button , elliptical button etc ... So It will be very tedious otherwise to select all buttons of a page at the same time . From a web developers's view if you think, We need this not only for just implementing , we are having to maintain this from time to time, so if we want to add tracking code or anything it will be another story .

@oleersoy

Reason 1 : People don't always live in Cities where internet is a basic need.

If you are designing for these cities then keep it light weight. The is attribute is not light weight. By using is you are implying that you will be pulling in additional javascript to support the implementation of what the is attribute is targeting. Thus your page will flicker as the elements are being upgraded and the user will end up having a poor experience. In other words the is attributes guarantees that your comment:

If the default behaviour is not set then what they see when page loads will be some spaghetti half eaten.

Will be true.

I use 100 different buttons in a page, almost every actionable item is a button, round button , rect button , elliptical button etc ...

These are all CSS core concerns. You can do these without the is attribute and you will have a cleaner design. Use SUIT-CSS, BEM conventions, etc.

The is attribute could also cause your maintenance and user experience support scenarios to turn into a nightmare.

A lot of companies are afraid to touch their CSS because the way they went about implementing it resulted essentially in a stack of wine glasses. None of the glasses can be touched without fear of the entire stack tumbling. You risk the same thing with the is attribute.

@WebReflection WebReflection referenced this issue in w3ctag/polyfills Jan 12, 2017
Open

A Disappointing Document #8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment