Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Framesets with Handhelds 1

Status
Not open for further replies.
CliveC

CliveC

Programmer
Nov 21, 2001
1,222
US
HANDHELDS & FRAMESETS

Thinking Outside the Frame:

I discovered quite by accident that framed sites are compatible with handhelds, provided that the noframe tag is coded. Actually I tried only with a Blackberry. I used a minimum of code for the demo.

If you want to see the effect immediately try first with a regular browser and then with a blackberry:


I have included the code for completeness:

INDEX.HTM
<html><head><title>Handhelds and Framesets</title></head>
<frameset cols="30%,*" frameborder="0">
<frame name="MENU" src="menu.htm" />
<frame name="TEXT" /></frameset>
<noframe><body><br />Mobile Version<br />
</body></noframe></html>

MENU.HTM
<html><head><style>
body {color:white; background:blue}
a {color:white; text-decoration:none}
a:hover {color:red}
a:active {color:yellow}
</style><script>
if (top.location == self.location) {
self.location.replace ("index.htm")}
</script></head><body>
<div align=center>MENU<br /><hr /><table>
<tr><th><a target="TEXT" href="page1.htm">
Page 1</a></th></tr>
<tr><th><a target="TEXT" href="page2.htm">
Page 2</a></th></tr>
<tr><th><a target="TEXT" href="page3.htm">
Page 3</a></th></tr></table><hr />
</div></body></html>

PAGE1.HTM
<html><head><script>
if (top.location == self.location) {
self.location.replace ("index.htm")}
</script></head><body>
<div align=center>Page 1</div>
</body></html>

PAGE2.HTM
<html><head><script>
if (top.location == self.location) {
self.location.replace ("index.htm")}
</script></head><body>
<div align=center>Page 2</div>
</body></html>

PAGE3.HTM
<html><head><script>
if (top.location == self.location) {
self.location.replace ("index.htm")}
</script></head><body>
<div align=center>Page 3</div>
</body></html>

Clive
 
P.S.
On the Blackberry, after visiting a menu item, you need to press the back button to return to the menu.

I would be interested to know if this works with other handhelds if anyone would be kind enough to try it.

Clive
 
That's what the <noframe> element is for - displaying content to user agents that can't handle frames - so it's hardly surprising that it does so. I'd expect the Javascript redirect at the top of each page to give trouble to devices that understand script but not frames, though.

Best to avoid frames altogether, IMO, for a whole host of reasons.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Chris,

Actually you do not need the noframes tag for anything other than to display "Mobile Version". Since the blackberry ignores JavaScript it does not cause any problems.

Since there are plenty of threads on the frames debate I would just as soon not get into that. However, I would appreciate any feedback on how other devices work with the code.

Clive
 
The <noframes> is not there to say "Mobile Version", "Your browser does not support frames, get a new one you dinasour" or anything else that people put in there.
It is exactly for what Chris stated, providing alternative content for user agents that are not frames enabled, Screen readers, Braille devices, Search Engine spiders etc.
W3C NOFRAMES element.

so I would assume that from your example that the blackberry displays "Mobile Version" on screen (I'm not cool or trendy enough to even care about owning one much less actually doing so)

Chris.

Indifference will be the downfall of mankind, but who cares?
A website that proves the cobblers kids adage.
Nightclub counting systems

So long, and thanks for all the fish.
 
I made a mistake when I said that the noframes tag had to be used. The "Mobile Version" is only to reassure the user that they have reached a mobile friendly site. This message would not be seen when using the frameset in a normal browser. Frame should not be confused with frameset. Frames are the same as any HTML page.

I don't know about the UK but handhelds are widely used in the US and it is wise for site developers to take them into account. It doesn't take that much to make a regular site accessible by a mobile device. See:
Clive
 
CliveC said:
Frame should not be confused with frameset. Frames are the same as any HTML page.
Click to expand...

you'll have to explain what you mean here. Frames/Frame/Framset are part and parcel of the same thing or were you referring to inline frames <iframe> ?

And in the UK, in other than a few major cities, Blackberries are still something used to make jam [lol]



Chris.

Indifference will be the downfall of mankind, but who cares?
A website that proves the cobblers kids adage.
Nightclub counting systems

So long, and thanks for all the fish.
 
(... reading both thread and post with more care ...)

So what you're saying is that, when pointed at the index page, your Blackberry shows the contents of the first (MENU) frame, together with the contents of the <noframe> element. When you click on a link in the MENU, it ignores the target attribute and opens the desired page in the same window. Javascript is ignored in all cases.

That sounds broken to me - user agents are supposed to either show all the frames or the <noframes> content, not half-and-half. Basing your site on the buggy implementation of frames in one make of hand-held sounds dangerous to me. Can you be sure that others share this misbehaviour? Can you be sure they won't fix it?

Your pages are also going to fail when used outside the frameset by script-using browsers - because they'll just be bounced back to the index page. Can you be sure that Blackberry won't introduce Javascript support? (or that some hand-helds don't have it already?).

If you're developing with handhelds in mind (a laudable aim, though they are a tiny market here in the UK), with all their panoply of screen sizes and rendering engines, it seems to me that you should try to keep things simple. The added complication of using frames - which are pretty small-screen-unfriendly even when they work - does not seem worth the trouble.

Does the Blackberry understand the CSS [tt]@media handheld[/tt] rule? That's a much better way to rearrange and redefine content for handheld users, IMO.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
ChrisHirst

I was not referring to iframes. I meant exactly what I said.

The Blackberry has been in the US for about 6 years and has, I believe, upwards of 4 million subscribers.

For a heads-up you might want to read the following link regarding the UK:


Don't come crying to me if Santa brings you a Blackberry for Christmas. [pipe]

ChrisHunt

("... reading both thread and post with more care ...")
Click to expand...

Congrats! A star for you!
"So what you're saying is that, when pointed at the index page, your Blackberry shows the contents of the first (MENU) frame, together with the contents of the <noframe> element. When you click on a link in the MENU, it ignores the target attribute and opens the desired page in the same window. Javascript is ignored in all cases."
Click to expand...

Exactly!

The Blackberry browser version 3.7 (which is the one I am working with) is a standards compliant browser conforming to:
Version 4 does have support for CSS @media handheld and even Javascript in some form, but, as a configurable option.

I only used JavaScript in the example to highlight the fact that it does not cause problems and is simply ignored. In the same way framesets do not cause problems but are just rendered as a choice of frames. By not coding a source to the 2nd frame (in the frameset index.htm) the result is that the only choice that gets offered is the link to the menu.

There is no harm in coding the noframes section as:
Code: 
<a link href="menu.htm">Mobile Version</a>
but it produces a second link to the menu which might be confusing.

It might be worth putting instructions in the noframes section indicating that the user should hit the back button after visiting a menu item. The advantage here is that you do not have to include navigation in the small content screen.

I have been suprised by how easy it is to make a regular page work in a handheld. For instance in the thread that we both contributed to a couple of days ago, "Buttons as a link without javascript, thread215-960762", the method I described for placing a link on a button image rather than doing an "onclick" is a perfect example of cross-browser compliance. In the regular browser you see a nice button and in the handheld you see a simple link.

You may be interested to know that your own website works quite well in a blackberry (evidently by accident).

I was hoping to find someone with a mobile device that could indicate whether or not their device worked in the same way! Maybe I am in the wrong forum although I couldn't find anything specific to handhelds. [upsidedown]






Clive
 
I only used JavaScript in the example to highlight the fact that it does not cause problems and is simply ignored.
Click to expand...

Surely any browser will just ignore Javascript that it doesn't understand. The "problem" would come with it not working when it was relied upon for functionality.

I have to agree, that basing a navigation scheme on something that doesn't work as expected and "sounds broken" is a bit risky.

You are right though, it doesn't take much to make a site that works well in conventional as well as handheld browsers (or any other kind come to that). It's actually all the crap that "we" put in the way that causes the problems. A neatly coded page using semantic markup should work just fine no matter what it's viewed with.

That said, I have no idea how my site looks on a Blackberry.

- Web design and ranting
- Day of Defeat gaming community
"I'm making time
 
The Blackberry browser version 3.7 (which is the one I am working with) is a standards compliant browser
Click to expand...
No it's not - its implementation of frames is broken. It should show either the frames or the <noframes> content, not both.

It might be worth putting instructions in the noframes section indicating that the user should hit the back button after visiting a menu item.
Click to expand...
Only if you expect all your visitors to be using Blackberries, and they don't fix their frames support. It'll confuse the heck out of anyone using another frames-unaware browser like Lynx.

your own website works quite well in a blackberry (evidently by accident).
Click to expand...
Simple code, valid markup, no manky frames. No accident.

Nice to know, though (which of my websites did you mean?).

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
It seems to me that you simply like to be argumentative.

Standards-compliant means that an implementation meets minimum standards to be considered compliant. Market forces usually dictate additional features. This is how defacto standards are born.

Blackberry is standards compliant because the standard does not require frames recognition for obvious reasons of limited screen real estate.

The example I gave was simple and without frills. I assume that a programmer of your calibre would be able to query the user-agent if you considered it necessary. 3.7 docs explain how to do this.

If you are so sure that it is "no accident" that your websites would work in a handheld device you would not have to ask "which one".

I have a very compelling reason for using framesets in some of my projects. This reason dwarfs all perceived disadvantages. If you wanted to learn something new, instead of flaming people with tired arguments and uninformed opinions, you might ask what the reason is.

Clive
 
I disagree. Chris has not been argumentative.
The points he made are all valid within the scope of the thread. In contrast the response has simply been along the lines of "I do it because I know better".

"Standards compliant" does indeed mean "an implementation meets minimum standards to be considered compliant". What you are missing is that the minimum standard is set out by the W3C. The Blackberry browser, if it exhibits the behaviour indicated here, is not properly compliant. Most browsers fall short in some areas, though normally with newer incarnations of W3C standards. Most get frames right.

If the Blackberry browser properly supported frames to the standard outlined by the W3C it would adhere to, for example, the HTML 4.01 specs. Note the section about the NOFRAMES element.

Incidentally it may be of some help to your endeavours to know that in Firefox the URL shows a frameset (although the initial "main" page has no content"). While when using a Blackberry 7290 simulator I get redirected and then get a 404 error message. I've only just started playing with the simulator and I am not certain as to which browser version it uses though.

Using the simulator to view shows links to each of the frames making up the page AND the NOFRAMES content. This isn't quite the correct implementation of frameset compliance. I guess it's not going to fail but isn't needed if the NOFRAMES is used properly. That's the crux. I suppose the Blackberry developers added that feature since many people don't use NOFRAMES correctly.

Hope that is some help.

- Web design and ranting
- Day of Defeat gaming community
"I'm making time
 
I've just noticed that the code you posted uses a <noframe> element instead of a <noframes> element. Maybe that's why the Blackberry handles it in the way that it does. If so, its standards compliance is moot, since the standards don't explicitly state how to deal with invalid documents.

However, Blackberry's choice of half-and-half rendering seems unusual and not one that I would necessarily expect other manufacturers to follow. Relying on particular browser quirks to get certain effects is a risky practice, especially in a sector where you have lots of very quirky browsers that you're unlikely to be able to test (unless you have the budget to buy every handheld on the market).

It's an unnecessary risk when there are standards-compliant methods to achieve the same effect. If you want to display text to handheld users, try putting this in menu.htm:
Code: 
<p class="handheld">
Handheld Version
</p>
and this in your stylesheet:
Code: 
.handheld {
   display: none;
}

@media handheld {
   .handheld {
      display: block;
   }
}
That should work in any standards compliant browser.

The reason I keep banging on in my naturally argumentative way is that you're offering bad advice to people reading this forum who may not know any better. You appear to be saying "the <noframe> element is a good way to pass supplemental instructions to Blackberry users". Now that may be true, but it's bad advice nonetheless. It's bad because you're relying on a quirk of Blackberry's rendering rather than standards, and worse because you're ignoring how other browsers might render the same pages.

Heck, I don't care if you use frames or not, I'm sure they have their applications. But if you're going to use them, surely it's best to use them properly?.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Let me summarize, with brief bullet points, for the reading-impared: [3eyes]

1. I did not advise anyone to do anything, I merely shared a discovery and asked if others might try it with their mobile devices

2. I discovered that the Blackberry did not choke on Framesets even though it does not claim to support Framesets nor do the wc3 standards call for support of Framesets

3. The blackberry behaves as one would expect any browser to behave using the noframes tag. The only "quirk", if you want to call it that, is that it does not specifically require the noframes tag to be coded.

4. I also discovered that it is quite easy to make a regular page be handheld compliant by considering the things that the blackberry will ignore (e.g. Javascript, hard-coded buttons etc.)

5. The vast majority of blackberry users are not able to use "@media handheld"; that feature is available only in version 4.0.

I really do not see how there is anything here to argue about.


Clive
 
Let me summarize for those that seem to misconstrue constructive comment as an argument. :)

Your discovery is not one that could be of benefit (unless to serve as a red flag) since it is illustrating a method using a flawed implementation of a well documented standard. That is the point we are trying to make here. Nobody is arguing, you just seem unable to accept with the negative side to your "discovery".

The Blackberry does not behave in the way it should regarding the <noframes> tag. No browser specifically requires the <noframes> tag. The W3C spec, however, does require it so a site will not fail for users with non frames capable browsers.

It is precisely because of the "incorrect" behaviour that you should not use the method since it cannot be relied upon. If the site can be visited by a browser that does not like frames but does correctly use the <noframes> tag then your method would leave them high and dry. They would have no means to navigate the site!

There is a better way and that is properly use the <noframes> tag and include navigation within it (or at least a link to a navigation page).


Besides.. this is the wrong room for an argument. :)

- Web design and ranting
- Day of Defeat gaming community
"I'm making time
 
But he DIDN'T use a <noframes> tag, if what he wrote here was accurate. He used [red]<noframe>[/red], so all this "discovery" is irrelevant because of the misspelling. If in fact the actual page does have it spelled correctly, then it shows that the Blackberry browser has problems. Otherwise, all the browsers I'm aware of ignore unfamiliar tags, so the <noframe> tag would be treated as if it weren't there, and the text following it would be a part of the original page.

Lee
 
Not that I am involved in this "discussion" at all, but as an ouside reader who has seen this thread escalate into a barrage of personal insults I find myself in the rather awkward position of needing to call a Point of Order (faq1256-5539, #3).

--Chessbot

There is a level of Hell reserved for probability theorists in which every monkey that types on a typewriter produces a Shakespearean sonnet.
 
Might be nice if some of the highly-esteemed members of this forum took a look at faq222-2244. It's been adapted to suit many of the different forums and appears in many sig lines throughout the site

There is no copyright issue - just change the 'forum specific' items to suit this forum and you have a ready made FAQ.

Now, any volunteers?

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'If we're supposed to work in Hex, why have we only got A fingers?'

for steam enthusiasts
 
Status
Not open for further replies.

Similar threads

dkwel
  • Locked
  • Question
Working with Retina on a standard resolution
Replies
8
Views
150
audiopro
audiopro
aich69
  • Locked
  • Question
Web hosting with MS Office Live
Replies
0
Views
65
aich69
aich69
audiopro
  • Locked
  • Question
A Curious Problem With Chrome 2
Replies
3
Views
91
audiopro
audiopro
ebstarasia
  • Locked
  • Question
Twitter Widget with Joomla
Replies
1
Views
80
cutabovehost
cutabovehost
PPettit
  • Locked
  • Question
Seeking recommendations for CMS with Active Directory integration
Replies
4
Views
106
PPettit
PPettit

Part and Inventory Search

Sponsor

Back
Top