I'm still trying to wrap my head around the Zen of custom elements. Right
now I'm pondering how to keep content out of the Shadow DOM, in
document-oriented apps, like CMS's, blogs, forums, doc viewers, etc.
Currently every app I've seen has a single tag in the top document and from
there it's shadow all the way down.
The html5rocks.com article on Shadow DOM includes this great paragraph:
One rule of thumb, which is possibly being violated here, is that you
> shouldn’t put content in Shadow DOM. Content must be in the document to be
> accessible to screen readers, search engines, extensions and so on. Shadow
> DOM is for all of the semantically meaningless markup you need to create an
> attractive, usable widget. But the content should stay in the page.
This makes a lot of sense when you start internalizing the web components
way. For a static document that uses custom tags, it's even easy to demo,
with something like:
<html><body>
<blog-post>
<blog-title>Keep Content Out of Shadow DOM</blog-title>
<blog-body>It's easy!</blog-body>
<blog-footer><p>We can put <b>markup</b> here too</p></blog-footer>
</blog-post>
</html></body>
Sweet. This would presumably be crawlable too, if the custom tag names
don't trip up the crawler.
But I'm a little lost on how best to achieve this ideal in a dynamic app,
since the markup that uses the custom elements itself needs to be
generated, and the primary way we have of doing that is via a component and
its template. Doing that would mean that the markup ends up in shadow DOM,
which we don't want (assuming light dom option is going away). The other
options are imperatively building up the DOM, or using template binding
outside of custom elements, which I've heard isn't being encouraged (please
correct me if I'm wrong there).
But let's assume that using a template is the way to go. It'd look like
this:
<html><body>
<template id="post" bind>
<blog-post>
<blog-title>{{ title }}</blog-title>
<blog-body>{{ body }}</blog-body>
<blog-footer><p>We can put <b>markup</b> here too</p></blog-footer>
</blog-post>
</template>
</html></body>
Then do a: querySelector('#post').model = post; and voilá!
This has a few interesting implications.
First, it seems like there's two sets of "bindings" for everything: one set
of template binding mustaches to generate the document's DOM that uses
custom tags, and the other would be mostly a set of content tags with
selectors in the custom tags which project the content into the right
places in the shadow trees.
It would also seem to imply, though I haven't tried to go down this road so
salt grains apply, that custom tags shouldn't really be interfacing with
directly an app's data-model, but mainly with their own attributes and
content. Bindings would still be common for controlling rendering based on
component state. I could maybe see that being a principle, but I haven't
heard it before. I'm unsure with this approach how rendering would best be
controlled based on the structure of content. Mutation observers that
update internal state variables?
Am I totally off in the weeds? I have not seen a Polymer app built this
way, but I have not yet seen a Polymer app that adheres to the html5rocks
advice either.
Thanks,
Justin
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/CAEKsHmAiTh3ZNPTEyeOwsTHLG6JpNn8JrZugGri%2BUJkeTSTDhg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
