[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

Angelina Fabbro <angelinafabbro@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |angelinafabbro@gmail.com

--- Comment #22 from Angelina Fabbro <angelinafabbro@gmail.com> ---
Hi! I'm Angelina, the presenter in the video that was referenced earlier in the
thread. About the presentation in the video specifically, with a little bit of
background:

I had read in the spec (or the explainer, can't remember which) that the is=""
attribute is specifically not mutable; I cannot removeAttribute() and have my
element restored to it's original prototype. I even tried this in my own
experiments just for the hell of it and it failed as expected; I like to see
what I can get away with in my spare time and I make a point to try and break
or use things I'm not supposed to. When I was on the spot at the talk, I didn't
remember this. I'm sorry that I didn't; I was very nervous like I am every time
I speak in front of an audience. 

What is most interesting after the fact, I think, is how I chose to answer the
developer's question in a way that I thought made the most sense. I made an
educated guess (that turned out to be wrong) because most of the common
attributes I work with are mutable. This may or may not be the case for other
developers, but you can bet that at least some others will make the same
mistake. I knew that technically the attribute affects the DOM tree as
rendered, so I thought that changing it would change the tree as rendered
appropriately when applied or unapplied. Other developers will make this
assumption. It's the kind of mistake you do once though, then read the docs,
and hopefully learn your lesson. It makes sense for some attributes to be
immutable (script src, input type), and maybe there are good reasons for it in
this case but to the average developer on the other side of these APIs, it is
confusing.

In the video I talk about potential use cases for responsive web layouts. My
idea when I incorrectly understood the is="" attribute was that I might be able
to re-purpose a <nav> element on the fly if I detect a viewport size less than
some size n. Width is less than 768? Bam, <nav> gets an attribute <nav
is="mobile-menu"> and encapsulated somewhere in my mobile-menu is some code
that takes the children of my nav element and turns it into a drop down. I
understand basic re-rendering can be done by the application/removal of
decorators, but actually I want to be able to apply/unapply behavior for my
menu via script as well, and so I want to be able to use a full-fledged custom
element. Knowing that I can't use the is="" attribute the way I had hoped, this
makes me a sad panda. 

Someone said earlier that I didn't realize that the is="" attribute is not
crucial to acquire the behavior that I'm looking for. I'm well aware that there
is more than one way to skin a cat - er, yak. :) I did say 'absolutely crucial'
in the video, but that's about being able to interact with my component in a
certain way, and if the is="" attribute is not the way to do that, then the is
attribute is not absolutely crucial and I care about it a lot less. 

I'd love to be able to declare my component, and then change an attribute on it
like the data attribute in such a way that signals the component to be able to
behave in the way I need. For example, when I detect a mobile user:

<x-adaptive-menu data-layout="mobile"></x-adaptive-menu>

That being said, now would be a good time to weigh in on this whole
custom-tag-vs-attribute component decision:

One of the most confusing things when I started learning about shadow DOM and
web components was the relationship between the host element with is="". I
quickly learned that in the case that I have <element name="pants"
extends="ul">, then for <article is="pants"> 'article' is not anything. It's a
husk. It's a vessel. That's it. It (maybe) provides you with some children
which you may or may not use. What I have is a pants element that has the
prototype of an unordered list, not an article, and honestly that's really
confusing when you look at the markup. You can expect other developers to
assume that prototypal inheritance comes from the tag on which the is=""
attribute and custom element are applied because that's what's in the markup.
You effectively make the true prototype of the custom element obfuscated from
the document source, but what's worse is that there's this lie, as it's been
said, of it being something that it's not. That is sitting there waiting to
confuse someone who doesn't know better yet. It is awfully unintuitive. 

On the concern about semantics when it comes to custom tags: at some point
earlier a fear was expressed about developers using custom elements everywhere
rather than semantic ones. Someone else pointed out that this is already a
problem and that custom elements is not the place to solve it. I agree that
this is not the place where we try and solve this issue. It's not your
responsibility what tool a developer uses from the toolbox you've given them. 

If you tell a developer that they will build the best house with a hammer and
nails but instead they just smash everything with a brick and put some paint on
it, then I guess you might feel a bit bad for the person buying and using the
house in the end but it's not on you. It's not your responsibility how the tool
was used just because you made the tool and gave it to someone. You might think
to try and create better tools, maybe tools that avoid certain pitfalls; this
is good as we should always strive towards better tools. But keep in mind that
even if you try and create those better tools, there's still no guarantee every
developer will care to understand them and use them. There are many developers
for whom webwork is a paycheck and the bare minimum of effort and understanding
is all that is put forth. Those developers will continue to make everything a
div forever with inline scripts and styles and whatever else they do that shuns
the current web development paradigm no matter what we do. I don't know how to
solve this problem, but I do know this isn't the place to do it.

If we're worried about semantics and we agree that role="" is not a panacea for
those who DO care (I care!), then I think that this approach gives me the good
feelings I'm looking for:

<x-fancy-input as='input'>

Let me specify the overall semantic value of my custom tag as an attribute if
role="" is just a suggestion for screen reading software so that machines will
parse my tag in a meaningful way for indexing the like. If I don't tag a custom
component, then it's nothing special; maybe it's parsed with about as much
semantic value as a div.

"Generally speaking, I wouldn't expect there to _be_ semantics that make sense
inside a component. "

I would.

I understand that a screen reader should be able to traverse the tree as
rendered for it's purposes; does/would a search engine do the same? If this is
the case, then I definitely want to be able to have some semantic information
in my component. For example, I might have a dynamic component in a magazine's
web page that has a hierarchy of heading tags and content; maybe this component
is updated with breaking stories and their summaries. Maybe I'm using a comment
template component too, which has <em> tags used by the thread participants.
I'd want all of this to be crawlable and parseable by the search engine. Just
because I don't want my component's content to be mucked with by scripts in my
parent scope doesn't mean I don't want search engines to be able to crawl it,
and that means I'd probably want to be semantic in my components too. Perhaps
there should be an attribute that tells the search engine whether or not to
crawl/parse the content of the tree as rendered? If this can't happen, then I
need to rethink how I'd use components some more.

I'm in the custom tags camp over the attribute camp. I used the is="" attribute
in my demo because I happen to have a working polyfill supporting this, and
also because I thought it was the direction that things were likely to go in,
not because I like that approach personally.


Cheers,

- Angelina

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

Received on Monday, 7 January 2013 07:19:18 UTC