Committed, thanks.

cvs diff -u <filename>

Attached is a new iframe.php file with the preset sizes mentioned 
below, but they will display to the user as Small, Medium, Large, and 
Extra Large. This still seems a bit more intuitive, since most end 
users don't understand the concept of pixel sizes.



One of these days I'll make it easy and learn how to do the patch files.

Functionality is working fine; we can reopen the ticket if there's 
actually a new patch.

Do you still have this on your agenda?

Sounds good.

Jan,

I completely agree... I might make such a change in my implementation 
today. If you agree that it makes sense, you are welcome to commit it.



tevans,

For the custom value, you could probably have the value trigger a 
javascript prompt similar to how Kronolith prompts for a New Category 
name, or Turba prompts for a distribution (contact) list name (could 
probably even recycle the code from Turba fairly easily).

We currently use this feature to render individual photographs and 
other images that tend to have a non-standard height dimension.



Any chance that the proposed list of preset height values could 
include "Custom" with an appropriate user input field when needed? 
That would provide a balance between usablility and flexibility.  I 
don't know whether a single portal block parameter could be configured 
to accept multiple input modes (select list AND text field).

It would make even more sense then to give the labels names like 
"Small", "Medium", "Large".

I find it a little more helpful to have pre-determined heights in a 
drop-down list since the common user doesn't understand that height is 
a pixel measurement... nevermind what the heck a pixel is (in many 
cases).



That said: In my implementation, I changed the 'height' parameter of 
the iframe block as follows:



                                         'height' => array('type' => 'enum',

                                                                 'name' => _("Height"),

                                                                 'default' => '600',

                                                                 'values' => array('480' => _("480"),

                                                                         '600' => _("600"),

                                                                         '768' => _("768"),

                                                                        '1024' => _("1024"))));

You are correct. Committed, thanks.

Agreed ... and I believe the patch meets your request. The outer 
condition tests to see whether the height parameter is empty (default) 
before checking the browser. If a value exists for the height 
parameter (the outer "else"), we will use it regardless of browser type.

One request: you shouldn't set the height depending on the browser. If 
the user sets a height, he should get it always.

Thanks for looking this over. I have updated the patch for CVS HEAD 
(rev. 1.23).

It works fine for me with Firefox, but I don't have any objections. 
You need to update the patch though, because Chuck changed the block 
code in the meantime.

This seems like as reasonable a solution as any, I guess - any other thoughts?

The portal block for viewing an external web page does not fill its 
enclosing table cell even though it has a height="100%" attribute. 
This is true for both IE and Firefox (I did not test any other 
browsers using multiple skins.



As a suggested fix/workaround/enhancement (take your pick), I wanted 
to suggest the attached patch. By adding an explicit height parameter 
to the iframe block, we can give the user better control over the 
portal layout. Some of our users have already given us positive 
feedback about this small change.



Thank you for your consideration.



Tom Evans

Tachometry