Re: [webcomponents] self-documenting component.html files

attributeChangedCallback is provided by spec, I don't believe one needs
another avenue for observing attributes.

Mapping properties to attributes is non-trivial, that's where a higher
level abstraction (toolkit or x-tags, e.g.) comes in.


On Apr 5, 2013, at 11:31 AM, Travis Leithead <>

  For the attribute changes, you can use MutationObservers, unless you need
to have the values updated synchronously, in which case, you can always
fallback to Mutation Events or hook the relevant APIs with ES5
defineProperty overrides…? Generally, I think all the tools you need for
notifications are probably already available.

*From:* Mike Kamermans [ <>]
*Sent:* Friday, April 5, 2013 4:51 AM
*Subject:* [webcomponents] self-documenting component.html files

Hi all,

a short while back I'd been working on a web components demo, with one
result being a components.html that also acted as its own documentation
(since as a components.html anything that isn't 'more components', script,
or element, gets ignored), which sparked a small discussion on how
self-documentation might be done at all. I've been trying to think of some
way to do this while staying within the custom element specification, but I
keep ending up with needing bits that aren't in the spec. So, let me just
list what I have, and perhaps some of the bits are useful enough for
further discussion, while some other bits can be shown to be silly, with
much better alternatives. This is what I come up with if the idea is to
make a custom element as self-descriptive as possible:

One obvious difference is that for attributes that you actually want to do
anything with (i.e., you're creating your own custom audio element, and
setting the src should reload the data and start autoplaying or something),
you want to be able to specify the getter/setter and events that will
occur. I didn't see anything in the webcomponents/custom element specs that
would currently allow for this. I did hear from Scott Miles that some work
had already been done, and that the custom element shim now already
supports an attributeChangedCallback function to do just this thing, but
that's a bit broader level than specific get/set behaviour on attributes.
Consider my gist to be some thinking out loud =)

Also, out of the discussion on fully documenting vs. docstripped
(essentially the develop vs. production question): I'd make this something
that people who deploy their components for others to use are responsible
for in the same way they are responsible for full vs. minified javascript
libraries right now. If you only put up a fully-documented components.html
you're probably inconveniencing your audience, but having it available next
to a minified version is great for when people want to look something up -
they'll know where to go by simply removing the ".min" part in a CND'ed
components.html URL. So as long as the minification process is easily
performed, that should be enough (so my gist also contains a description of
what "minification" would look like)

- Mike "Pomax" Kamermans

Received on Friday, 5 April 2013 20:34:00 UTC