This was interesting to me:

Evented Programming with jQuery

It sounds like a good way to think about how to build things.

Summary: when faced with building some widget, in the example it's a tabbed interface, approach it by thinking first: if this were already part of HTML, how would I want to interact with it? Work out your interaction, then code up the widget to provide that API.

Food for thought.:thumbsup:

If he really wants to make "native" code he needs to add custom html tags (which he claims isn't possible). This will also ensure a css dev in the future doesn't blow away his work.

Once you extend the xmlns, webkit and mozilla can work with the tags as native.

IE is an exception, but if you're stuffing this work into almost "native" solution, the work to get it right once cross browser isn't such a big deal.

@media all {
tab:xmlns { color: rgb(255,0,0); display: block; } } test test ​

the term "xmlns" within the element name can be anything. I just couldn't think of anything.

If you aren't concerned about the style of the parent custom name space, IE will only ignore the tag and render the text node within the tag. The dom parser will still see it and you can still work with it in javascript. So you could give your html coder custom tags and hork them around in IE back to html namespace native tags in this supposed hidden native extender.

Eitherway, talk about overwrought. I think augmenting native types with events is easily covered in a simple jquery class extender as he pointed out maybe 4 or 5 times. Fast switching of a particular element's controllers is one of jquery's strength. Why remove that or give it an extra step?

As well, Hiding important event ownership could have maintenance issues as coders simply assume the events are in fact native. eitherway i'd approach xml as a way to act as a big damn flag something very fishy is going on with how the class events have been applied, so devs know something has directly bypassed MVC. I wouldn't want to be the one to figure out a phantom event error down the scope chain.

as ever persist that's a fascinating reply.

Do you find yourself extending the xmlns often? I knew this stuff was possible, but I've never done it nor seen how it's done.

Could you explain this? "Fast switching of a particular element's controllers is one of jquery's strength"

i would never do it unless I needed to for some strange widget convention or protection of styles in an unpredicted deployment context.

I'd probably reach for xsl (depending on where webkit is these days) if i found myself in some corner needing that much abstraction.

As for fast switching, here's what i mean.

So this guy is saying he wants to extend these tabs so that they just work. Well maybe i dont want them to work all the time. Maybe I don't want them firing off tab events if the user isn't logged in, and I will not maintain some state boolean that says whether or not the callee should act.

So instead I can put the tab in a simple NATIVE mouse over mode that informs them they need to log in to see those tabs.

I can use ajax to log the user in. Rather than reload the page and setup these "native" additions to the page, I can just remove the notification class and simply apply a different class. No state meta required. And sure you can say, well you can put disabled or alternative modes into the "native" extension, but at tha point how much program logic should go into such a thing, i thought we were trying to make it nativei-sh?

If I said ok, all interactions have this native state that is going to ask you to log in until you do so, I now have to figure out wtf phantom class extended div:tab, remove that, assuming I can uniformly across the application, and remove the controller listening for the event. And that's assuming it was documented somewhere and that I even know it exists because it's obfuscating and misleading the availability of events in jquery.

Once I apply a new class, I have to hope future classes weren't relying on this "native" extension after having disabled it.

The UI has been tied to the code directly, with the coder stuck persisting a phantom native capability simply because another coder has decided it's part of his framework of sparkle ponies.

As a lead dev I'd kill that immediately if one of my devs used it.

The only way I can think this is remotely useful is if jquery UI picked up the notion to implement cross cutting UI conventions across widgets or you need to implement your own widget API for developers and you don't want to use iWidget spec or something.

Hey Persist, thanks for the detailed reply. I hadn't replied yet because frankly I don't get it but I don't want it to go without a thanks at least!

I don't know how you do this for instance: "I can just remove the notification class and simply apply a different class." I'm only on my first jQuery project so I have a little ways to go before much of this will make sense to me.