> Thanks for the feedback Aaron; I'm excited to check out (and hopefully > contribute to) your UI kit. >
I'm excited to have the help! > Cons: > > - requires a browser supporting custom elements / polyfill > <http://www.polymer-project.org/platform/custom-elements.html> > - does not lend itself to multiple behaviors > - for behaviors where options are specified as JSON, don't think I've > really reduced the notably > > Pros: > > - nice semantics > - reduced learning curve for simple behaviors > > Having actually built UIs with this stuff, I can tell you that combining things is pretty crucial to getting stuff to work. Note that you still have to do the same stuff for the delegators, and custom tags probably won't help you there. It's way more common to have more than one of these things on a single element than you think. Learning to use these as they are, the message is, "lay out your page with regular ol' vanilla HTML, then tell them how to behave" instead of "learn all these new tags". For *some* of these things, the behavior is tied up with the UI; for example, the carousel component is pretty clearly a UI component (though, again, you'd be surprised how complicated you can make it if you want, for example, a video on slide three to start playing when you get to it). But most of the behaviors are a bit more general than that. Form validation, for example, ajax behaviors, ALL of the delegators, and others. Another angle here is the semantic difference between HTML and how the page behaves. One benefit of behavior is that you can turn it off and the page still works (generally speaking). I.e. a link with the ajax delegator on it is just a regular link. It can even fetch the entire full-page response and then snag only the portion it wants to use for ajax, such that opening the link in a new window doesn't give you just the ajax partial but rather the whole page. This makes debugging your application WAY easier, as you can turn off the JavaScript layer entirely and validate that all the other stuff - the HTML, CSS, and, above all, the response from the server, is working properly. By separating design from layout (CSS/HTML) and those things from interaction (JS), you get a very clean development interface. My 2 cents. Of course if you go with the custom tag route and want to add it to the repository I'd be into it. I could totally be wrong. > As I wrap up this post, I think I may be talking myself OUT of doing this, > since I'm not really sure nice semantics are worth the effort :-) > Well, certainly if you were to put the same amount of effort into adding new behaviors and delegators, improving the UI kit itself and broadening it's functions, it would make it better. The custom tags might make it better, too, but I don't think the benefits you're perceiving are that great, and neither are the cons. The system as it is works pretty well, and it's really not that hard to learn. Plus, it's there already. I'm still hoping to get something online for you, however rickety, by the end of the week. -- --- 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 mootools-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
