alternative to target aspect of frames/iframes

[questions]

I've looked around for some idea for this, but now decided to post.

I had my old webpage in frames, which now are pretty much defunct. Some people suggest iframes, but they also seem be on their way out as I understand XHTML won't support them in the future.

Fine.

Is there a simple way to do what frames does:

SPECIFICALLY if I have a page with little images, to click on the little images (like a menu of images) and have a bigger image (or whatever content) appear in a specific place on the page. In frames this meant setting up one frame as the target for where content would be displayed.

Is this only possible in really complicated ways? SSI, for example, partly seems to do what frames did, by combining pages. But I don't know if you can set things up to do what I mean above.

Thanks.

[Twey]

Some people suggest iframes, but they also seem be on their way out as I understand XHTML won't support them in the future.XHTML (and HTML for that matter) doesn't support them now, only the outdated Transitional DOCTYPEs which were meant to ease webmasters' transition from HTML3, and so duplicate some of HTML3's features. In other words, <iframe>s have been obsolete since HTML4 was completed in 1998.

You'd want to use Javascript, possibly with the XMLHttpRequest object.

[questions]

Do you mean something similar to what this person was asking about:
http://www.dynamicdrive.com/forums/showthread.php?t=28606

Is there someplace you can recommend for me to look at to learn?
Javascript is not so easy for me, though I've figured out some of it before.

But also, I heard it is not too good to use Javascript, like if people have it turned off, etc. Maybe it also complicates things too much?

There is no other way, huh?

[Twey]

You just have to construct your links properly. For example, you might write:
<a href="foo.html" onclick="loadIntoElement(this.href + '.json'); return false;">... where foo.html.json is a page containing foo.html's markup in JsonML (http://jsonml.org/) format, and loadIntoElement is a function capable of taking an URL and rendering the resulting JsonML into an element in the DOM. That way, anyone who doesn't have Javascript will simply get the static page.

Of course, then you're maintaining two copies of each page. It's easier to use a server-side script that parses the JsonML into HTML when needed, or one that parses both out of XML (perhaps XHTML).

[questions]

OK. I am not very familiar with what you are saying, but I'll look into it. Thanks!

[molendijk]

As long as a DOM-method like

var Ifr = document.createElement('iframe');
Ifr.setAttribute("src","somefile.html"), etc.
is supported. I wouldn't worry too much about the iframe being deprecated.

Arie Molendijk.

[Twey]

Arie would have us descend into digital anarchy like in the days of the browser wars. :)

As usual, there are good reasons for it being deprecated. It causes a lot of accessibility problems.

[molendijk]

Speaking of the dark Middle Ages, what's the difference, then, between my previous message (creating an iframe) and directly using an iframe on a page, like in this (http://www.dynamicdrive.com/forums/showthread.php?t=28662) recent thread?
Anyway, I wouldn't like to go back this far (http://www.youtube.com/v/WLCb_E6yM2k&rel=1&border=1).

Arie.

[Twey]

Speaking of the dark Middle Ages, what's the difference, then, between my previous message (creating an iframe) and directly using an iframe on a page, like in this recent thread?Yours requires JS, and the validator can't check JS so will say it's valid (even though it isn't). Bear in mind that the validator is neither authoritative nor exhaustive.
Anyway, I wouldn't like to go back this far.Haha, yes, those fire catapults look painful!

[questions]

You know, I don't understand why the people who write these codes don't understand how nice it is to have a scrollable menu that puts pictures in the same page. Especially for viewing pictures, but for much more. So you have the menu and the final bigger content right there.

It seems like something so basic that many people would instinctively want.

It is shameful that we have to go around it in complicated ways. So, there were problems with frames. But taking them out altogether without a better alternative is pretty bad.

This is what turns designers to use flash, which I can't stand...

[Twey]

But taking them out altogether without a better alternative is pretty bad.Because there is no alternative. The problem is with the very concept, it doesn't fit in with the "page" metaphor of the Web and Web browsers. The "bad" thing is only that they existed in the first place.

[questions]

I found something that could be useful. Using Javascript to hide and make visible images as you rollover.

http://www.htmlcodetutorial.com/help/viewtopic.php?t=1854&start=0

So, say I put the thumbnail of images in a table and the "large" version of the images in another place, when rolling over one could view the larger images. The only problem is that if the thumbnails are many in number and one needs to scroll, the larger image will always pop up in the same place and it will be off the page if one scrolls past it. Does that make sense?

I can't figure out a way to have two tables move independently of one another. For example, one table or location of small images that scrolls and one location of where the big image will appear that moves with it. I tried putting the large image in a table of "100%" width/height. But the table stayed in the same place. It didn't move along with the scrolling page.

I also tried putting the thumbnails page in as an object into the page with where the larger image should appear. But that was a mess altogether, because I think then the javascript doesn't work from one .html page to another.

[molendijk]

With regard to this (a little while ago):

As long as a DOM-method like

var Ifr = document.createElement('iframe');
Ifr.setAttribute("src","somefile.html"), etc.
is supported. I wouldn't worry too much about the iframe being deprecated....

to which Twey answered with this:

Arie would have us descend into digital anarchy like in the days of the browser wars. :)As usual, there are good reasons for it being deprecated. It causes a lot of accessibility problems.
I have the following question. If we do this (DOM-compliant):


<script type="text/javascript">
function makeObj(){
var TheTag = document.getElementById('test');
while(TheTag.firstChild) TheTag.removeChild(TheTag.firstChild);

var AnObject = document.createElement('object');
AnObject.classid='clsid:25336920-03F9-11CF-8FD0-00AA00686F13';
AnObject.setAttribute('type','text/html');
AnObject.setAttribute('data','included.html');
AnObject.setAttribute('width','600px');
AnObject.setAttribute('height','300px');
AnObject.setAttribute('name','my_object');
AnObject.setAttribute('border','1px');
TheTag.appendChild(AnObject);
}
</script>

then the file named 'included.html' won't load in IE6 (perhaps neither in IE7) unless we take out AnObject.classid=... and AnObject.setAttribute('type','text/html'). Does anybody have an idea why?

Arie Molendijk.

[BYK]

questions,

You can use "overflow: auto" divs for scrollable menus etc. I do not like Flash much also and nearly always I find a solution without flash but as shiny as flash ;)

molendijk & Twey,
I have to say that I'm in molendijk's side since in some aspects(such as hidden iframes, form posts to them etc.) there NO alternatives to iframe right now and since it is used properly I do not see any reason for not using it, until proper replacements arrive ;)

[Twey]

there NO alternatives to iframe right nowAnd never will be. They were removed because their intrinsic properties make them difficult or impossible to use without introducing a small heap of accessibility problems and questions. Should someone come up with a superior method that can be used in their stead without their issues, I suspect the W3C will support it -- but whatever it is, it will have to be considerably different from the <iframe> you know.

[BYK]

I meant the internal usabilities such as making a form's target an iframe for asynchronous file uploading.

And I wonder what those issues are, which you mentioned. I mean you talk about iframe like it something horrible but as you know it was introduced again by W3C at that time.