If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible. Also you could not bookmark anything. I remember doing a frameset per content frame url automatically and also redirecting to that frameset from inside the page via javascript if the content frame's url was directly opened.
>If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible.
Feature, not bug in my book. Same thing happens in today's iframes. But for situations where that is a problem, the spec could have been extended to support every page being able to identify a preferred parent frame. Or browsers could have changed behavior to by default duplicate a frame's parent and siblings when opening a frame in a new window.
>Also you could not bookmark anything.
Again a limitation of the spec that could have been addressed rather than throwing out a useful feature. We support have text fragment identifiers in URLs these days; surely we could have supported URLs with multipart frame targets.
They could! window.parent exists for this! Also, the target attribute on a.
For multipart frame targets, the fix then, as it is now, is to parse out the URL fragment params into something reasonable. SPAs use the path for state; no reason you couldn’t use it for frames.
If browsers got around to actually implementing basic features on browser level like making a frame navigation work instead of coming up with new CSS properties that nobody is going to use we could be all building websites without any javascript.
