209462 - Proposal of a new frameset feature

Status: RESOLVED INVALID

(Core :: Layout: Images, Video, and HTML Frames, enhancement)

Description

[Ulrich Grassberger]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529

I propose that Mozilla parses the URL in order to load certain documents into
certain frames of the frameset.
http://server.com/frameset.htm?framexxx=this.htm&frameyyy=that.htm is a simple
example. See the testcase URL for more information and a rude implementation in
Javascript.

I know that "layout: HTML Frames" is not the right category, but I do not know a
fitting one. IMO this feature is great and could become very popular and in the
end even recognized by W3C, but first someone has to implement it. I am not a
C++ programmer.

Reproducible: Always

Steps to Reproduce:
1. 
2.
3.

Comment 1

[Olivier Cahagne]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 3

[Ulrich Grassberger]

>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. 

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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.


  

Comment 5

[Ulrich Grassberger]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 7

[Ulrich Grassberger]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Ulrich Grassberger]

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!

Comment 10

[Boris Zbarsky [:bzbarsky]]

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).

Comment 11

[Ulrich Grassberger]

The URL was the best medium for that information because it is visible for all
and acessible by all. 

Another related issue which I did not mention yet is that the page history of
the browser is not compatible with traditional frames: There is only one set of
back/forth/reload buttons but multiple frames. Various bugs about this have been
filed. An Microsoft invented "inline frames", a caricature of Netscape frames.

The way they are now, frames do not comply to standards, or let us say that some
standards contradict each other. I find this an unsatisfiing situation. The
basic question is how can one express a relation between several documents in
one command, e.g. in a URL. Probably I will have to stick to my homegrown
Javascript frame syncer although it messes up log files and causes various
little problems (especially with Mozilla). 

Comment 12

[Anne (:annevk)]

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.