Ian Bicking: the old part of his blog

Extending overlays comment 000

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.

Comment on Re: Extending overlays
by Ian Bicking