Allo.
There's no reason that behavior wouldn't work with custom tags, though it's
not designed to work with them as semantic replacements for the behavior
listing itself. For example:
<foo> I'm a foo </foo>
wouldn't translate into Behavior instantiating it as a Foo. Instead you'd
have to do:
<foo data-behavior="Foo"> I'm a foo </foo>
This is ideal for two big reasons:
- You might have more than one behavior for the tag (both Form.Request
and Form.Validator, for example)
- You only have to do one DOM search to find them all
($$('[data-behavior]')). This search is far more scalable than having to do
a DOM search for each behavior you write.
On an unrelated note, I've been working towards open-sourcing our UI kit
here where I work. There's still a lot of work to do (we have a bunch of
demos we hope to get online as well as docs and css/less files that
accompany them), but you can at least see what's in it now:
https://github.com/Behavior-UI/behavior-ui/tree/master/js/Source
-aaron
On Mon, Jun 23, 2014 at 11:21 AM, Eric Patrick <[email protected]>
wrote:
> Has anyone experimented with porting Aaron's behaviors
> <http://www.clientcide.com/code-releases/bootstrap-3-0-clientcide-3-1-0-behavior-1-3-0-and-more-behaviors-1-0-8/>
> to
> HTML5 custom tags
> <http://www.html5rocks.com/en/tutorials/webcomponents/customelements/>?
>
> Our toolset targets business 'power users' who are not js experts, but do
> learn basic markup. I've found behaviors are a very powerful tool in
> enabling this user base to achieve things that normally require
> 'traditional' coding.
>
> However, we also have client shops with JS expertise (usually jQuery), and
> I am weighing porting our custom behaviors to HTML5 custom tags, and
> allowing JS devs to create new custom tags following a similar structure
> using jQuery, instead of requiring MooTools.
>
> (I continue to love Moo; just trying to leverage existing knowledge bases
> out there. I'm in an enviable position of generally dictating the browser
> to our user base, so I get to ensure an evergreen
> <http://tomdale.net/2013/05/evergreen-browsers/> browser.)
>
> Anyway, just wondering if anyone on this list has weighed pros and cons of
> such an approach, of if you might be interested if I just put this in GIT
> for joint development?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "MooTools Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"MooTools Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
