[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669

--- Comment #24 from Daniel Buchner <danieljb2@gmail.com> ---
I'm going to attempt to break out of this Ground Hog's Day-esque loop of
explaining the same things over and over...I digress - here goes:

> > 1) In terms of developer ergonomics, for both conceptual understanding and
> > in practical use, it is much easier to deal with and "x-modal" tag vs a
> > random tag with is="x-modal" applied.
> 
> Note that if is="" is used, there is no need for the x-. You could just say
> is="modal".
> 
> As far as conceptual understanding goes, developers already need to
> understand <input type="foo">.


I can see where someone could think this is a good example, but it is entirely
different. We're not just talking about a mutable attribute that has a scoped
affect on a specific element proto, we're talking about an attribute that
actually defines the proto object identity of the tag itself.


> > 4) Developers worth their salt will assume prototypical inheritance from the
> > tag on which the is="" attribute is applied - this is a head-fake for
> > developers. The extends linkage is created in the Custom Element definition,
> > and if we use attributes, a developer will be left to wonder what mix of
> > prototype they are being dealing with.
> 
> So why wouldn't we make the custom element inherit from the element
> designated by the tag name in terms of the APIs available?


Are you forgetting these are actually extended protos? Let's say I'm coding a
custom element, "x-importer", to inherit from an existing native element,
HTMLScriptElement, and my custom element code materially relies upon the
inherited proto methods/getters/setters. Why can't I just slap is="x-importer"
on any ol' element on the page? Well shucks, do I need to go further here
folks?

Long story short - no, nope, nada, noski, no-siree-bob, not ever - should we
allow a pig pen of false interoperability that lies to developers by virtue of
some transient, immutable attribute that may or may not produce an extended
proto that works for the internal custom element's code definition.

"Yo dawg, I heard you liked inexplicable failures in your custom elements, so I
let the web play pin the proto-tail on the element-donkey with attributes." -
Xzibit


> > To mitigate semantic concerns of some who favor the is="" attribute, I would
> > point developers at role="" for accessibility and semantic expression.
> 
> There is a crucial distinction: role="" is understood by the user agent
> while the user agent has no clue of the semantics of is="".


You're basically saying that is _is_ meaningless to the user agent
currently...err...I agree? Obviously if a UA can be coded to understand an
is="" linkage, they can be coded to look at what a tag extends, defaulting to
HTMLSpanElement - as the spec describes.

Let's be clear: If the true desire of some on this thread is to provide devs a
way to specify *optional*, *additional* semantics that extends="", role="", and
semantic elements inside a custom element can't, then sure, lets include an
optional attribute like is="" as="" dat="" shiz="" - but there's no need to ram
the whole API into a terrible, sure-to-be-fail-prone attribute interface to
assuage the desire for nth degree semantics that may or many not be an issue
with a subset of components.

Moral of the story: make it optional, make it passive - if not you're creating
10 real-deal, additional problems that will #FacePalm devs left and right, all
for the cause of something that could be an issue for a subset of use-cases.


> (In reply to comment #8)
> > I'd be fine with not using an attribute if we have some other solution. My
> > concern is that people will abandon the use of semantic HTML in favour of
> > Web components, in much the same way that they used <font> or <div
> > style="">s. This hurts accessibility, it hurts search engines, it hurts
> > maintainability, and it hurts backwards-compatibility (graceful
> > degradation). I would like to avoid this by requiring that authors use
> > regular HTML elements that they then _augment_ using Web components.
> 
> I have this concern, too, at least for document-oriented Web content. It's
> unclear to me how much of a lost cause Gmail is. That is, if it is practical
> to try to redeem Gmail from the land of <span role=button class=foo> to
> <input type=button is=foo>.


Oooweee, good example! --> <input type=button is=foo />

Riddle me this: Under an is="" world, what happens when a developer jumps into
source, sees this cool button, that materially relies on extending <input>, and
logically, obviously, tries to do this: <button is="foo">. I can hear the
subtle explosions inside the <element name="foo"> definition script now...BOOM!


> (In reply to comment #9)
> > 1) What prevents the developer, or would even dissuade them, from using
> > normal, semantic elements *inside* their components?
> 
> What's the expected accessibility exposure model for Web Components? Is the
> component's (shadow?) tree supposed to be exposed to accessibility APIs are
> not? (For XBL2, the answer was not, which might be affecting people's
> presuppositions when discussing this.)


The browser has knowledge and control of all the objects, whether in shadow
roots or not, I can't state with 100% confidence that a browser can use
elements in the Shadow DOM just the same, but I can't see any reason why not.
Dimitri?


> > 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> > it hails from the nav element's prototype? The generated custom element
> > prototype does not inherit the prototype of the element that is="" is
> > applied to
> 
> Why not?


Hopefully we don't need to rehash this ever again...


> > 1) We already have a document method perfect for this case:
> > document.renameNode -
> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode
> 
> As Anne pointed out, we don't really have document.renameNode().

So implement it! We're talking about augmenting the platform to account for an
attribute, is there some moratorium on adding helpful methods?

Please excuse any frustration, all of these issues have already been explained
several times in this thread - it becomes an Ad nauseam task to continually
restate them.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 January 2013 21:38:52 UTC