After a lot of digging around in the code, I figured out the problem. If your template includes another file that has repeatable regions, the repeatable regions in your main template will stop working when you edit the page again. As described, the cursor will move up and down the existing regions instead of adding new regions.

For example, I have a navigation template that has repeatable regions.

1
2
3
4
5

<ul id="nav">
<!-- TemplateBeginRepeat name="Navigation" --> 
<li><!-- TemplateBeginEditable name="Nav Item" --><a href="#">Home</a><!-- TemplateEndEditable --></li>
<!-- TemplateEndRepeat --> 
</ul>

I included that file via the standard PHP include . When editing, Contribute seemed to get confused about the repeatable regions in the navigation when Contribute manually imported the navigation file.

The fix is either to not use repeatable regions in your include files (not an option) or to trick Contribute into not trying to include the included file. Contribute is at least smart enough to know how to do the standard PHP includes. So, I had to break a rule and use eval like this:

1

<?php eval("include('./nav.php');"); ?>

PHP evals the string and ultimately includes the file. Contribute doesn’t understand the code and does nothing, which removes the problematic code and causes repeatable regions to work as expected.

function loadMyMovie(clipName, depth, loadInClip, funcbefore, funcafter) {
	var watchLoad = function() {
		if(_root[clipName].getBytesLoaded() == _root[clipName].getBytesTotal() && _root[clipName].getBytesTotal() > 0) {
			funcafter.call();
		} else {
			setTimeout(watchLoad,1);
		}
	};
	_root.createEmptyMovieClip(clipName, depth);
	_root[clipName].loadMovie(loadInClip);
	funcbefore.call();
	watchLoad();
}

funcbefore and funcafter should be the functions that show and hide your loading message.

I haven’t tested this exact bit of code, but that’s the basic principle.

Dynamically Visible DIVs Don’t Appear

I used a tab-based navigation for the beta version. When you click on a tab (composed of an h2 and an a), the corresponding div would appear, hiding all the others. This was achieved by adding and removing a value in the .className. In IE, though, the tab would work for two tabs, but would only hide tabs after that. The new tab wouldn’t appear.

To make matters worse, if I alerted something in the loop that set or unset the .classNames, it would work. I tried various things like .display="none" while I was modifying things, then setting it back to block when I was done, but none worked.

The solution turns out to be that you need to remove the container element, then reinsert it. For example:

1
2
3
4

var tabcont = document.getElementById('tab-container'),
	pn = tabcont.parentNode,
	ns = tabcont.nextSibling;
pn.insertBefore(pn.removeChild(tabcont), ns);

DOM Created TABLEs Don’t Show Content

I also needed to dynamically create tables. This can be done via straight text with .innerHTML or via the DOM with document.createElement and .appendChild. In some areas, the tables could use thead because the row headers were on top of the table. Other times, the th was in the same tr as the td it matches.

In instances where there was a thead, I also created a tbody. Where there weren’t, I didn’t bother because the browser usually figures that stuff out. IE does not. So, if you’re using the DOM method of creating tables, make sure you explicitly use a tbody.

For the record, I was also using a caption. So, that may have triggered something in IE that wanted an explicit tbody. If your stuff seems to be working fine without the tbody, it may have more to do with caption being present.

option in the
Develop

menu of Safari. It turns out that browsers do their own hacks to certain known problem sites to make them work. Safari allows developers to turn off these hacks in the event that the developer is fixing a site that has hacks in Safari.

Opera, on the other hand, has a very advanced method for dealing with site specific hacks. It’s worth a read just so to know what kind of stuff goes on in the browser that most people, including developers, never think about. They also link to how other browsers deal with the problem.

Basically, where two borders meet (e.g. border-top and border-left), a diagonal line is drawn where they meet, making a neat bezel effect, rather than having the top border sit above the left border. For example:

On the div above, you can see the diagonal lines where the borders meet.

1

<div style="margin: auto; border: 10px solid red; border-left-color: blue; border-right-color: green; border-bottom-color: yellow; height: 20px; width: 20px; background: gray;"></div>

Taking advantage of this, it’s easy to set the color of some borders to transparent and end up with a polygon.

1

<div style="margin: auto; border: 10px solid red; border-left-color: transparent; border-right-color: transparent; border-bottom-color: transparent; height: 20px; width: 20px;"></div>

Take that principle and mess around with it, and you can make triangles. For example:

Above, you have north, south, east, west, northeast, northwest, southeast, and southwest (in no particular order).

1
2
3
4
5
6
7
8
9
10

 <div style="position: relative; width: 100px; height: 100px; margin: auto;">
  <div style="width:0; height:0; border-left: 5px solid transparent;  border-right: 5px solid transparent; border-top: 5px solid blue; border-bottom: 0; position: absolute; bottom: 0px; left: 50%;"></div> 
  <div style="width:0; height:0; border-left: 5px solid transparent;  border-right: 5px solid transparent; border-bottom: 5px solid blue; border-top: 0; position: absolute; top: 0px; left: 50%;"></div> 
  <div style="width:0; height:0; border-top: 5px solid transparent;  border-bottom: 5px solid transparent; border-right: 5px solid blue; border-left: 0; position: absolute; top: 50%; left: 0px;"></div> 
  <div style="width:0; height:0; border-top: 5px solid transparent;  border-bottom: 5px solid transparent; border-left: 5px solid blue; border-right: 0; position: absolute; top: 50%; right: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid blue;  border-right: 7px solid transparent; border-top: 7px solid transparent; border-bottom: 0; position: absolute; bottom: 0px; left: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid blue;  border-right: 7px solid transparent; border-bottom: 7px solid transparent; border-top: 0; position: absolute; top: 0px; left: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid transparent;  border-right: 7px solid blue; border-bottom: 7px solid transparent; border-top: 0; position: absolute; top: 0px; right: 0px;""></div> 
  <div style="width:0; height:0; border-left: 7px solid transparent;  border-right: 7px solid blue; border-top: 7px solid transparent; border-bottom: 0; position: absolute; bottom: 0px; right: 0px;""></div> 
 </div>

So, as you can see, it’s pretty easy to make a triangle. Adjust the border widths to make them bigger.

Safari seems to send the values of unnameed selects, despite these elements being invalid. So, you may get a query string like
text1=test&=selval

if your select that contained an option="selval" doesn’t have a name.

Internet Explorer 6 and 7 both mishandle buttons. Internet Explorer 6 sends all buttons with name attributes set, even though it should only send the button if it was clicked. Internet Explorer 7 doesn’t send unclicked buttons, but any time Internet Explorer 6 or 7 sends a button it sends the button‘s innerHTML instead of the value.

So, given the deficiencies above, here’s how to compensate. If you’re using PHP, you don’t need to worry about Safari sending nameless selects as PHP seems to ignore them (or at least in parse_str). If you plan to use buttons, never give them names or values. Use radio controls if you have to do conditional actions based on what the user clicks.

I still have some other testing to do, but these findings should help you cover your bases if you’re working with forms.

This has given clout to support Internet Explorer 8 (which is in Release Candidate version now) in addition to versions 6 and 7. Here’s hoping Microsoft forces Internet Explorer 8 upgrades now that version targeting has been implemented.

I still have some editing to do on older stuff and I there are still some areas of the CSS that I need to address. The pressing stuff is done, though. In the days ahead, I’ll concern myself with new stuff.

Until I get through all the old stuff (hopefully by the end of the week), please be patient.