Archive for the ‘Development’ Category

Dynamically setting the height of an iframe

Monday, February 16th, 2009

This is reposted from blog.pixelmedia.com.


Recently, we had a situation that required us to pull in some content from one server to another using an iframe. Generally, this is something we would try to avoid, but we needed to pull some data from a new .NET application into a legacy ColdFusion application.

Unfortunately, the height of the page being pulled in would vary wildly. This led to a fairly disappointing experience where the page was either far too long, or content in the iframe was cut off and the user had to scroll within the iframe to see everything.

We came up with what we thought might be an interesting solution. If the page loading inside of the iframe (the child page) could calculate its height, and somehow let the parent page know, the parent page should be able to reset the height of the iframe.

With a little inspiration, we came up with a pretty neat solution that we’d like to share. Our solution requires that you have the ability to edit the code of both the parent and child pages.

The child page being loaded into the iframe will simply reset the location of the parent page, and include a hash with the height of itself.


<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.js"></script>
<script>
var parentUrl = "http://kingston/other/test/iframe-outside.html";

setHash = function() {
parent.location = parentUrl + "#" + $('body').height();
}();
</script>

We’re using jQuery here to easily get the height of the <body> tag.

On the parent page that includes the iframe, we’ll again use jQuery and write a small function that gets the height from the hash in the URL, and uses that to reset the height of the iframe.

function setHeight() {
var newHeight = parseInt(location.hash.substring(1)) + 50;
$('#hashFrame').attr('height', newHeight);
}

We ran into a bit of an issue: the page we were loading was taking a few seconds to load, and we didn’t want to set our height on the iframe until the content within the iframe had finished loading (and it had a chance to set the proper height to the url hash).

More jQuery to the rescue! The jQuery .load() method allowed us to call our setHeight() function after the iframe had finished loading.

$('#hashFrame').load( function() {
setHeight();
});

Putting it all together gave us a great way to use our new application inside our legacy application, and make it faily seamless to the end user.


Comments are closed. Please comment on the original post instead.

Almost Standards Mode?

Wednesday, July 5th, 2006

I came across an interesting discovery today regarding the Firefox rendering engine. Most web developers are aware of Standards vs Quirks mode in the current browsers, however I was never aware that Firefox actually had THREE different rendering modes; Standards, Quirks and Almost-Standards Mode.

I happened across this today when changing a site from a valid XHTML 1.0 Transitional doctype to an XHTML 1.0 Strict doctype, and it made a tiny rendering change in the page. When I switched to the Strict doctype, some content on my page moved down one pixel. Having always thought that since both were valid doctypes, both should render the page in standards mode, I went on a hunt to find the exact differences between the Transitional and the Strict doctype.

It seems that Almost Standards mode was created to keep table based layouts working properly once CSS layouts were starting to take hold - and according to Mozilla, rendering in that mode should affect nothing other than images within tables.

I beg to disagree.

While I couldn’t get a test page together, I did enough quick testing to tell that the issue I was seeing definitely was being created by an image. Putting the page in full standards mode made it render the same as IE. Once in full standards more I could turn the issue on or off by changing the display on the image from inline to block. Inline gave me the extra pixel, block took it away. The behaviour seems consistent with why Mozilla implemented Almost Standards mode in the first place. Images displayed inline get an extra gap for the decenders in lowercase letters.

I’m not sure why I’m seeing this issue on a site with no tables, and I’ve probably never come across it before because I hardly ever use a Transitional doctype. It is however a small annoyance, and will certianly keep me using a Strict doctype.

Professional Web Development through Firefox Extensions

Tuesday, April 4th, 2006

LifeHacker recently posted an article about how to install several Firefox extensions at once. Then, they posted some of their own homemade extension packs. While their web development one is ok, a serious web developer has many more tools available in the form on extensions. So, with that in mind, I’ve decided to post my pack of extensions that I use on a daily basis as a professional web developer.

This requires that you you have the Mass Installer extension installed first - then, simply provide that extension with this URL:

http://www.zymur.com/resources/webdevpack.txt

I’ll try my best to stay up to date on the URL’s as things get updated as well - hopefully, the existing URL’s won’t break and you’ll be able to at least do the install and then let Firefox check for any updates.

I’m posting this before even testing myself, so install at your own risk…

If you are brave enough to try it, let me know in the comments below if you find this useful!

Javascript Scroller

Friday, March 31st, 2006

Hang on - don’t shoot me yet! Why am I talking about something so 1999 as a Javascript scroller?

At work the other day I was working on a UI project for an internal system of a fairly large client. This UI required some navigation, but the space provided did not show the full navigation. The UI was designed this way (I did not design it), and I had to come up with a quick mockup of actual functionality so the client could see how things would work.

I went on the hunt for a javascript that would let me use CSS to hide the overflow from the navigation area, and use JS to scroll the area up and down. The best I found was this Absolutely Positioned Scrollable Area, which is the SAME exact script I had used back in 2000 to do something similar.

Well - I didn’t like the looks of the script at all, with it’s browser checking and whatnot, so I kept looking until I came across Chris Heilmann’s DOMnews script. Not exactly what I was looking for, but it had potential.

Now, let me say that Chris is Javascript guru and certainly much more skilled than I when it comes to the ways of writing good code. I use his Unobtrusive Javascript tutorial quite often.

Anyway, I grabbed his script and started hacking away at it until I got more or less what I needed. Under normal conditions, I probably wouldn’t share this but because there seems to be a lack of anything like this that is at all up to date, so without further ado:

Javascript Scroller

It should be pretty easy to figure out what’s going on, and modify for your own needs. Hopefully someone finds it useful - let me know in the comments what you think.

Table based design at it's finest!

Wednesday, March 29th, 2006

At work yesterday, I was just minding my own business, listening to iTunes and some of the music that was on my computer already when I was given it. A song came on that I somewhat enjoyed and I decided to google the artist. Her homepage came up of course:

Rachel Loy

Aside from the short music clip which assaulted me (and kept repeating itself, over and over and over again), it’s not a bad looking page. But WOW! Take a look at the table the site is using for it’s layout - it’s spectacular!

I’ve you have the web developer extension just outline the table cells. Or, try turning off the images. You can really have some fun with this one! Not an alt attribute in sight! Oh - sorry that’s a lie - they are there….they are just empty.

Anyway I found it a bit amusing and thought I’d pass it on. Take some enjoyment from the fact that as long as there are people out there coding sites like this, there should be work available in our field when they need to be updated in the future. Long live table based design!

Don't forget your DOCTYPE!

Tuesday, February 7th, 2006

In the course of helping people at Experts Exchange, I’ll see a lot of questions about layouts that don’t work in multiple browsing enviornments. The common theme running through most of them is the lack of a proper DOCTYPE.

If you have a website that looks great in one browser, but different in another, make sure your site has a DOCTYPE!

What’s a DOCTYPE?

A DOCTYPE is a “document type declaration” - it lets the browser know what type of document it’s trying to display.

Why do I need one?

You need a DOCTYPE because if your webpage doesn’t have one, the browser goes into “Quirks Mode.” You don’t want this - it will mean a higher chance of your layout not working the same between different browsers.

But I’ve already got one!

Ok, great! But is it a valid one? Does it include a full URL to a .dtd file on w3.org? If not, it’s not doing you much good as far as the browser is concerned.

Ok - so what do I do to fix it?

While there are a few choices for DOCTYPEs out there, I’m going to recommend you use the one for HTML 4.01 Strict.

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01//EN”
“http://www.w3.org/TR/html4/strict.dtd”>

This will allow you a bit of leeway in your coding that an XHTML DOCTYPE wouldn’t, but will still force you into good habits, assuming you run your code through the HTML Validator

Your advice broke my page!

I’m sorry. No really, I am. That sucks. But, if you take the time to fix your code to work with your new valid DOCTYPE, you’ll be saving youself a lot of hassles in the future. You’ll have better code that works more consistently in different browsers, you’ll be better prepared for new technology, and you’ll be helping to make the web a better place. Isn’t that worth it?

More Information

There are plenty of resources out there about DOCTYPEs, and this was just meant to be a very basic starting point. If you want to read more into why you need a DOCTYPE, please check out these pages:

Shaping the future of the web through the beginners

Tuesday, February 7th, 2006

Sometimes, we lose track of the beginners. There’s so much information to stay on top of that gets crammed into our minds as web developers, that we sometimes forget where we came from. Thankfully, it’s easy to remind ourselves by offering our time and help to those who are new to the business. Personally, I answer questions over at Experts Exchange when I have free time. There are plenty of other forums or newgroups where one can offer assistence as well.

The quality of questions at EE range from those just starting out, to those needing assistance with some pretty high level stuff. While the high level stuff is fun to assist with, it’s the ones who are just starting out that usually need the help the most. You’ll see a lot of questions about layouts that don’t work in different browsers, CSS that is doing funny things, and people who just really don’t have a good grasp on the web technologies and what they all do.

A big part of helping some of these folks is the teaching aspect that goes along with it. Rather than simply providing a code fix, you can explain to them why they should be doing something a certain way. Why they should be using CSS instead of tables for their layouts, why HTML is different than ASP or PHP, why their should run their site through the validator. A lot of these folks might not care, but if you can impart some knowledge to those that do, you can help the future of the web. You can not only be responsible for making your own web sites better, you can help others make their betters as well.

A lot of questions get asked over and over again, and I’ll hopefully start addressing a few of those in some articles here on the site. One of the big issues I’ve noticed lately are people with layout issues between browsers that are being caused by invalid code and a lack of a DOCTYPE, so stay tuned for the first of the series - “Don’t forget your DOCTYPE!”

IE 7 <label> bug

Thursday, February 2nd, 2006

So I bit the bullet and installed the IE 7 beta preview 2 on an extra machine at work. The install went fairly smoothly, checked out a few pages, a few small rendering issues but nothing major. Nothing, that is, until I check out some pages I had made with forms on them.

Oh no! What has happened to my beautiful forms? Their

(If you have IE 7 you can see the problem on this test page I’ve put up. If you don’t have IE 7 then check out the screenshot.)

Taking the form out of the table, or changing the text alignment to the left fixes the issue. However, the most usable, accessible form will have labels, and normally for usability the text will be aligned to the right.

Ok, ok - why is your form inside a table anyway, you might ask. Well on some of our older sites at work, the basic page layout is still done in tables. I know, I know - but I can’t fix everything all at once. And I’m sure I won’t be the only one with this issue.

I’ve submitted the bug to IETell@microsoft.com as they request on their blog.

Update: I submitted this bug to PPK, and he wrote back with some additional information:

“BTW: the bug seems to be generic: any element with a text-align
inside a TD has these problems.”

Thanks for the extra information!

Update 2: According to Markus at MS, this issue has been fixed in the latest builds.

Welcome the new job description, "Front-End Architect"

Sunday, January 15th, 2006

I am a “Front-End Architect”….or um, I’m trying my best to be one.

Garrett Dimon wrote a great article about the emergence of the Front-End Architect, and more specifically, what skills you need to be one these days.Garrett lists 14 seperate skillsets he believes is important for someone in that role, from the obvious (XHTML, CSS & JS) to others you’d expect (design, usability) but surprises a bit with how important he thinks programming knowledge is. While I’m not sure I completely agree with his example of the front end guy telling the back end engineer how to do things, I do agree that a good understanding of at least what is possible is a huge requirement.

This is a job title I’d love to see start showing up in Monster, as I (and others I hope) are starting to get pretty tired of job requirements that require the front-end developer to be a graphic designer as well, or the graphic designer to have a full understanding of how to take their Photoshop mockups and actually create the standards based XHTML and CSS from their designs as well.

I’m also glad that this role encompases more than the basic building of a web page, because it finally gives a bit more credability to the role, as most of these skills are not skills that the “amateur” using Dreamweaver in WYSIWYG mode would have.

Google Map API and IE's "Operation Aborted" error

Friday, January 6th, 2006

I was working on a website realign tonight, and finally got around to testing a page in IE that I had implemented a Google Map on. Alas! The page did not load, and gave only an “Operation Aborted” error message. The code I was using worked just fine in Firefox:


if (GBrowserIsCompatible()) {

function createMarker(point,html) {
// FF 1.5 fix
html = ‘

‘ + html + ‘

‘;
var marker = new GMarker(point);
GEvent.addListener(marker, “click”, function() {
marker.openInfoWindowHtml(html);
});
return marker;
}

var map = new GMap(document.getElementById(”map”));
var point = new GPoint(-71.473918, 43.330797);
map.addControl(new GLargeMapControl());
map.addControl(new GMapTypeControl());
map.centerAndZoom(point, 7);

var marker = createMarker(point,’My Text Here‘)
map.addOverlay(marker);
}

I took some time to do a bit of debugging, and found that when I removed the two divs surrounding my included file, things worked OK. However, that still left me with quite a problem. Thankfully, I was not the first one to have this problem. A quick Google search led me to a page on RyanGrant.net about the Operation Aborted error message. Ryan had run into the same problem, and it was suggested on the Google Maps Google Group to load the map script using an onload event. Unfortunately, this was probably something I should have been doing already in the interest of good coding. Thankfully, a quick fix to my code managed to clear up the problem.


function createMap(){
if (GBrowserIsCompatible()) {

function createMarker(point,html) {
// FF 1.5 fix
html = ‘

‘ + html + ‘

‘;
var marker = new GMarker(point);
GEvent.addListener(marker, “click”, function() {
marker.openInfoWindowHtml(html);
});
return marker;
}

var map = new GMap(document.getElementById(”map”));
var point = new GPoint(-71.473918, 43.330797);
map.addControl(new GLargeMapControl());
map.addControl(new GMapTypeControl());
map.centerAndZoom(point, 7);

var marker = createMarker(point,’My Text Here‘)
map.addOverlay(marker);
}
}

if(document.getElementById && document.createTextNode) {
window.onload=function(){
createMap();
}
}

Quite frustrating for IE to completely choke on the code as it was, and to provide such an abstract error message. Thankfully, it didn’t require any sort of hack, but only a simple cleaning of the code which improved it in the process anyway. Lesson learned - no more lazy coding!