Wedge

Given how fast we change the code, any test results have a decent chance of being out of date.

Ah, I got the terminology slightly off then.

Regarding replace vs append, there's one fairly good reason why I'd suggest it should be append: mods.

Sure, themers and the core code will typically do replace, because they don't have to care about the consequences nearly as much - they're setting the canvas that mods will later work with.

WedgeDesk used the old subtemplate insertion code, to add subtemplates and so on e.g. to the sidebar, and not once did it do a replace, it was always doing appends.

That said, if the core code does 300 vs 20, then it should probably stand and modders will just have to use it the way I've used it thus far :lol:I can think of reasons why you might.Argh, yes, I can see the problem.Well, remember that unlike the DOM specification, jQuery was built by and for people who actually *use* the DOM. So the spec says that insertBefore, insert-as-last and removeChild are enough, but the real world needs to use replace, before, after, etc. (And yes, there should have been a remove operation on that list)

Surely, the contents of main_wrap has both a block and a layer in it?[1]

I honestly wouldn't make replace the default; if someone does want to replace the entire contents of a layer, fine, but don't make that the default state of play. (And if they do want to replace, discard the entire contents of that layer and be done with it)

Instead, I'd suggest append should be the default of the day, if someone adds to a layer, the typical behaviour is going to be to add it to the end of the layer. If they can add it arbitrarily inside the layer (before all, before/after a given node) that's important, but at the end should be the default.

If in doubt, think about the typical DOM methods exposed in jQuery as the sorts of operations people do actually want to do: replaceWith, before, after, prepend, append, and wrap. The same operations would typically be desirable for managing blocks and layers - which really aren't any different to DOM manipulation.[2]

1.	Assuming I haven't muddled the terminology up.
2.	It is more than just a passing similarity, since the skeleton's pseudo-XML is representational of the content's own HTML anyway.

*shrug* People will still ask, we'll still give them the same answer.

Heck, people didn't even read the big warning in Aeva's installer/download page/mod thread, why should they read a post that by definition has a filter on it that implicitly filters out most people?[1]

1.	Seriously, that's what I'm beginning to see the word FAQ as: a filter for anyone who isn't more intelligent than average that says "You don't want to read me, I'm boring." Or a filter that says "Nah, what I have to say doesn't apply to YOU, you're more special than everyone else."

Hardly corrected. I just said the same thing only more forcefully :P

Yes, he was referring to the "+ mail client" part, I think.

It would mean tying my computer into the Googleplex more than it already is. Why would I want to give them personally identifiable details tied to all my searches?

You know, also that G+ issues have caused peoples' accounts to be frozen, why would I risk that? (Not that I've done anything to prompt it, but given the kinds of insanity that Google are doing at the moment, why would I even go near doing that when I can for less hassle go elsewhere and get a service that's closer to what I want and need.)