Html: QUESTION: Why is the V1 observedAttributes mechanism apparently so restrictive?
<soapbox>
One of the good things about web programming has been dynamic objects. The user can add things that the author didn't think of.
</soapbox>
The observedAttributes mechanism seems to require the author to list all possible attributes that can trigger .attributeChangedCallback(). It would be really great if there were an option to indicate "tell me about any attribute that changes. Which is how V0 worked.
Is there some discussion I can read about this topic to understand why V1 apparently changed this to become so restrictive?
Jeff17Robbins
All 14 comments
https://www.w3.org/2016/01/25-webapps-minutes.html Ctrl+F "the only issue that was remaining was attribute filter for style attribute" should cover it.
To summarize, as you are the author of the custom element, you know all the attributes that you can write useful code to react to. And, no built-in element reacts to arbitrary attribute changes (i.e. no built-in element reacts when you do el.setAttribute("asdf", "xyzw")).
Going to close but happy to continue discussing in the closed thread.
domenic
on 12 Sep 2017
Downside of this is if your element wants to react to an arbitrary group of attributes with a common naming scheme. While no built-in element does this, it was an early proposal for <picture> (adding multiple numbered attributes to <img> to specify the sources, rather than adding a new wrapper element and multiple children).
(We anticipate this being a pattern in CSS, and plan to allow responding to properties based on prefix matching in a later version of the Properties & Values API.)
tabatkins
on 12 Sep 2017
Agreeing with @tabatkins . The special data-* attributes come to mind. A data store element might want to know about any of those changing.
I think the statement
To summarize, as you are the author of the custom element, you know all the attributes that you can write useful code to react to.
is true, but the concept of all the attributes could be "all by rule" rather than "all by enumeration". The current mechanism only gives me "all by enumeration".
I read the discussion linked-to (thank you for that!) and understand that for V1 this might be an expedient compromise, as apparently others wondered about some kind of pattern match too.
Also, on a minor note, an argument based on And, no built-in element reacts to arbitrary attribute changes seems to beg the question, to me. Custom elements liberate us from the restrictions, to some extent, of the built-in elements. It doesn't seem too farfetched, to this layperson who doesn't have to build the mechanism(!), that the mechanism could support a wildcard or pattern notion. We have built a large app using V0 and this change is really the only minor pain point in converting over to V1.
Jeff17Robbins
on 12 Sep 2017
Ah yeah, and bringing up data-* attributes actually shows that "no built-in element does this" is false. ^_^ Every built-in element responds to an arbitrary class of attributes starting with a data- prefix, and populates its .dataset property accordingly.
(It so happens that what it does could be implemented just by having .dataset be a Proxy that reads/writes to the attributes on demand, but in the general case this isn't true.)
tabatkins
on 13 Sep 2017
No built-in subclass of HTMLElement, is what I meant.
Re: question begging. In general custom elements are not meant to be arbitrarily powerful; they're meant to give you the same power as the platform has. Anything we allow beyond that leads to people building un-idiomatic "custom elements" which don't behave like other elements, and might be better suited for a non-custom-elements technology.
domenic
on 13 Sep 2017
No built-in subclass of HTMLElement, is what I meant.
??? I don't understand - are you disagreeing with the data-* thing, or somehow arguing that, since it's a superglobal (and thus on HTMLElement rather than any particular subclass) it doesn't count?
tabatkins
on 13 Sep 2017
The latter.
Custom elements allows you to implement subclasses of HTMLElement, and the goal is to give you the same powers as other subclasses. No other subclasses have that power; it's a special superglobal implemented for all HTML elements, but not part of any specific element's code. As such, we don't give that power to user-defined subclasses, just like we don't give it to browser-defined ones.
domenic
on 13 Sep 2017
Re: question begging. That power limitation concept is helpful to me. Thanks!
Jeff17Robbins
on 13 Sep 2017
That seems pretty specious? Why are you privileging the superglobal attribute there? What's special about it such that we don't think we need to provide the same capability to authors?
Whether an property is defined on a superclass or subclass is an implementation detail, not a meaningful capability difference.
tabatkins
on 13 Sep 2017
The point I was trying to make is that we implement things in the superclass that are special capabilities not intended for any particular element's API. Particular element APIs (subclasses) are more limited in their capabilities. You may disagree that this is good design, but I'm just stating it's the current design, and I at least think it's reasonable.
As a perhaps-stretched analogy, we privilege Object in JavaScript to get special powers (like being creatable from an object literal), whereas its subclasses don't get that capability.
domenic
on 13 Sep 2017
That is a stretched example, because it's very specifically a functionality of the one class, not of its subclasses. data-* attributes, on the other hand, are usable on every HTML element. A better match for object-literal syntax is the fact that only the html and svg elements are allowed to be the root of your document - that's a very specific power attached to a finite numbers of classes.
I meant it when I said super vs sub is an implementation detail - that's a basic tenet of the theory behind OOP. (It's implied by Liskov's Substitution Principle, I think.)
tabatkins
on 13 Sep 2017
@domenic, wanting to test my understanding re
they're meant to give you the same power as the platform has
Does that mean, in principle, that one could replicate all (or at least some of) the native elements by writing custom elements?
It might help illustrate the power and/or lack thereof of custom elements to list which of the native elements could be replicated via custom elements, which could not be replicated, and the reasons for why a given element could not be replicated.
For example, I'm thinking that the <video> element couldn't be replicated, nor the <img> element for that matter, without access to native code. And the <iframe> element.
But presumably the <input> element could be recoded as a custom element?
Jeff17Robbins
on 13 Sep 2017
Does that mean, in principle, that one could replicate all (or at least some of) the native elements by writing custom elements?
That's the plan! Unfortunately we're not really there yet. Basically none of the native elements can be replicated in detail. I worked on a project a few years ago (using the v0 API, but the result is the same) that showed this. Check out https://github.com/domenic/html-as-custom-elements including the summary at https://domenic.github.io/html-as-custom-elements/ for a/blockquote/div/span.
video or img aren't really problematic in the way I think you're imagining. You'd have a canvas in a shadow DOM and decode the bytes to paint there. No native code needed. iframe seems pretty magical though, yeah. input probably has some magical stuff like triggering platform IMEs...
domenic
on 14 Sep 2017
I knew V8 was fast, but I wasn't imagining it fast enough to decode Netflix
into a canvas in real-time! (See edit below...my imagination was outstripped by reality.)
[EDITED]
Had time to check out those links. Excellent. I think that's a great way to do a practical gap analysis between native elements and their quirks, history, and C++ power and the emerging power of custom elements. Thank you @domenic for pointing them out and in general for being kind to a newbie at this completely unaware of the level of work that's been done already to think through custom elements.
[EDITED again, chagrined]
One of my colleagues disabused me about video decoding in JavaScript:
https://github.com/mbebenita/Broadway
I had no idea!
On Wed, Sep 13, 2017, 6:01 PM Domenic Denicola notifications@github.com
wrote:
Does that mean, in principle, that one could replicate all (or at least
some of) the native elements by writing custom elements?That's the plan! Unfortunately we're not really there yet. Basically none
of the native elements can be replicated in detail. I worked on a project a
few years ago (using the v0 API, but the result is the same) that showed
this. Check out https://github.com/domenic/html-as-custom-elements
including the summary at
https://domenic.github.io/html-as-custom-elements/ for
a/blockquote/div/span.video or img aren't really problematic in the way I think you're
imagining. You'd have a canvas in a shadow DOM and decode the bytes to
paint there. No native code needed. iframe seems pretty magical though,
yeah. input probably has some magical stuff like triggering platform IMEs...—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/whatwg/html/issues/3035#issuecomment-329309561, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAWhzSBvUQ310Rcqj2xVQWMtE32g9R-ks5siFClgaJpZM4PVQlA
.
Jeff17Robbins
on 14 Sep 2017
Related issues
tkent-google
·
3Comments
domenic
·
4Comments
lazarljubenovic
·
4Comments
NOVALISTIC
·
4Comments
NE-SmallTown
·
4Comments
Most helpful comment
No built-in subclass of HTMLElement, is what I meant.
Re: question begging. In general custom elements are not meant to be arbitrarily powerful; they're meant to give you the same power as the platform has. Anything we allow beyond that leads to people building un-idiomatic "custom elements" which don't behave like other elements, and might be better suited for a non-custom-elements technology.