The more I think about the overlay code I mentioned in my previous post the more I want it. But the actual implementation doesn't seem sufficient to me... it's very vague that when ids simply overlap they get merged, and there's no way to indicate an id you mean to be merged and one you want to use for some other purpose. Also, the overlay itself can't pull in external resources, which I want. And lastly, while expressions might not be necessary, I think some form of cascading is good. For instance, if you have an <h1> element that you want to take either the document title or something by the id html-title (which can contain markup), there should be a way to express that.
Now that I think about it, there should also be a way to merge the head elements entirely, probably with some knowledge of the semantics of HTML (like one <title> element).
So, here's an idea:
I think that's it. Damn, that shouldn't be hard to implement. But I must keep myself from implementing it, because I'm really trying to get the last few loose ends together for a Paste 0.4 release. Must... stop... self...
The one pain in the ass part of this is parsing HTML. Easy in Javascript, but not in Python. With parsed markup, this is super-easy to implement.
I did not completely what you are trying to do but it sounds like reinventing something like kids content and replace attributes, does it not?
BTW, parsing the HTML can be easy if XHTML would be used at all times or maybe generated with Tidy.
Using Javascript on the client sounds a bit strange as that implies needing javascript and break of the system without it which is not very nice. Maybe ok for special apps but not for webpages.
Otherwise a use case for overlays would be something like an CMS editor overlay which adds the needed buttons like edit or delete to the HTML. Or even just as your Commentary (which looks absolutely great by the way) simpler stuff like adding doubleclicks to certain areas.
What do you really want with these overlays would be my general question I guess (maybe I am just to lame to understand but all this sounds really interesting at least for some stuff I would like to do too)
I meant of course:
I did not completely understand [...]Should not write when tired ;)
I don't think it is "reinventing" anything from Kid in particular. This is purely declarative and is not associated with any templating language. It's fairly close to ZPT's METAL, except with special consideration for HTML (the merging of head elements), and cascading of slots. And of course implemented at a much later stage than METAL would be (since that is actually done before templates are rendered).
For server-side parsing I'd probably require XHTML or maybe particularly well-formed HTML. Client-side this isn't a problem.
As far as needing Javascript, that is a concern. I'm not sure how big of a concern it is -- I think this has the potential to be more accessible than current server-side rendering anyway -- but I think it is part of why HTML Overlays haven't been used by nearly anyone (that I know of). A dual implementation is possible, with server-side rendering for those people who need it. Detecting the non-presence of Javascript is always such a pain, though :(
One of the other major issues I see is how it interacts with other Javascript and onload events. That and how it responds when some part of the process (the overlay itself or included content) is slow to fetch. Moving to async would be good (the original code is synchronous I believe), but then you get the cross-domain issues.
As for the goal, it's really for crude skinnability of applications. As long as you aren't too obsessive, overlays with CSS tweaking should be enough to make several applications seems like a cohesive whole. Not perfect, mind you, but it should let you get 80% of the way really really quickly.
# Ian Bicking
On my put there is drawings of the weapon, russian plane, tank, projects of the cars, design of the development, drawings of the naves and cosmic station.