what about: - finding a workaround at the user level (through DOM, CSS, JS, etc.), - the eventual security issues, - sending patch, - discuss this on W3C lists first.
> http://server.com/frameset.htm?framexxx=this.htm&frameyyy=that.htm The problem is that everything after a '?' is reserved for server-side processing. More to the point, how is Mozilla supposed to know whether it's supposed to parse that stuff itself or send it to the server? All pages currently in existence would assume that it does the latter. Sorry, but you need a better proposal for encoding the information you want -- doing it inside the URI is not feasible.
>The problem is that everything after a '?' is reserved for server-side processing. Who reserved it for that? Is it a standardized matter? > More to the point, how is Mozilla supposed to know whether it's supposed to parse that stuff itself or send it to the server? By comparing the variable names in the URL search with the frame names defined in the frameset page. Furthermore, mozframengine=1 could be added to the URL search. This should also cover security issues.
> Who reserved it for that? Is it a standardized matter? It was reserved by the IETF in RFC 2396 ("URI Generic Syntax"). The section you want is section 3.4 ("Query Component"); the exact language is: The query component is a string of information to be interpreted by the resource. "the resource" is the server in the case of HTTP URIs. And yes, this is a standardized matter, since RFC 2396 is the standard that defines what a URI is. > By comparing the variable names in the URL search with the frame names defined > in the frameset page. Which breaks if some page just happens to use those names for its own internal purposes (recall that the standard and all other implementations would indicate that the page should be able to do that). Any approach that depends on taking already-existing functionality that does something and changes it to do something else is not acceptable here, for the same reason.
I proposed to add a switch in order to avoid problems. Only in case that the URL query sets mozframengine or another uniquely named variable to true, the URL parser would take care of the frameset. The main advantage of such a frameset engine was that the URL would tell which pages the frameset contains. That means transparency. One could also use that for a custom sidebar, so the sidebar is just a frame. From the referers the webmasters would be able to find out who combines his content in which way. It is natural to have several windows which are related, and I cannot imagine an easier way to build this that by my idea.
> I proposed to add a switch in order to avoid problems. That only works if no one uses that same switch by accident. Hence not acceptable. The idea itself is fine. But an http URI is not the right way to encode such information; some other mechanism is needed.
It is very unlikely that someone writes an URL query variable with the same name like one of the frames and that he at the same time sets "our" switch variable to true. The result for user and server will be different from what the webmaster expected only in case that both conditions are true. Furthermore, one could call it not "mozframengine" but "hgje678h7g8d3" which further reduces the probability of a mistake.
Yes, but the point is that if we did we would have a buggy implementation of URIs. The bug would not be triggered often, but would be easy to trigger if someone were trying to. And it would be just that -- a bug. Just like parsing "black" as "green" in CSS.
So, before anything gets done W3C had to modify its URL standard first? But then, if not even a test implementation exists, would W3C care? Who cares anyway? Let´s just forget it!
The W3C has nothing to do with the URL standard. Again, this could be a worthwhile feature. All it needs is a sane way to encode the information that needs encoding (which documents to load in which frame).
Marking this INVALID. This is not a Mozilla bug, this should be solved with a standard organisation. I believe XFrames, if it ever will be a standard, has some mechanism for this.