I’m trying to create a HTML box that is 250 px in height having scrollbars for contents that are bigger than the box.
I have set “Overflow” to “Scroll” and tried to set a fix height of the HTML box; but always I do so, my height value is being overwritten by the actual size.
What have I missed ?
Alternatively I could use the “scroll” action, but the site is intended to work on IE 6 as well and I don’t know whether or not the scroll action will behave there correctly.
Thanks, this worked great (had to came about myself…)
Unfortunately previewing the site in FW isn’t nice, since there the HTML box still appears in its original size. It doesn’t matter for now but could be an issue on more complex designs. Maybe there is another trick to manage this ?
In Freeway 5, you no longer need to use this approach - the item can
be resized to whatever height you would like, regardless of the size
of its content.
Stewart
On 2 Apr 2008, at 13:56, tobiaseichner wrote:
Thanks, this worked great (had to came about myself…)
Unfortunately previewing the site in FW isn’t nice, since there the
HTML box still appears in its original size. It doesn’t matter for
now but could be an issue on more complex designs. Maybe there is
another trick to manage this ?
Thanks Stewart, I didn’t know that. I have just found one problem with this: if I set the overflow to “auto” or “scroll”, I can’t see the overflowing text to edit it.
Either the scroll bar should actually work on the Freeway page, or the text should behave like text on a “Stickies” note: if there is too much text for the height of the note, you can make the hidden text appear by using the down arrow.
Yes, I experienced the same behavior… however clicking into the text box makes the entire text to appear and editable - and unfortunately overlays other contents, so depending upon the “background” it is hard to edit.
I also think the best solution would be to have the scrollbars right away in Freeway when editing…
Hmm, that’s a little odd - when I edit the text, the background
behind the text outside the item is set to white and so it blocks out
anything else on the page while it’s being edited - even content in
items that are in front of the item containing the text being
edited… Is this not what you’re seeing?
Stewart
On 3 Apr 2008, at 09:59, tobiaseichner wrote:
Yes, I experienced the same behavior… however clicking into the
text box makes the entire text to appear and editable - and
unfortunately overlays other contents, so depending upon the
“background” it is hard to edit.
I also think the best solution would be to have the scrollbars
right away in Freeway when editing…
Strange, I gave it a try instantly: Some PNG images where kept in front, while other elements (HTML boxes, JPEG images) have been disappeared as I tried to edit the text box.
I then rebuilt the PNG images and forced to re-create the entire site (just to be sure), now also these images are hid and the text can be edited without problems.
I should mention that this is a FW4 project that was converted (and the PNG images are graphical text generated by FW). Not sure if this could be the reason…
I can only edit the text if the overflow is set to “visible”. If it is set to “scroll” or “auto”, the HTML box extends downwards when I click on the text, but all I see is a white rectangle (which indeed covers other items). I can click somewhere in the rectangle and the cursor will blink: it’s clear that it’s somewhere in the text, but I cannot see the text itself.
I’ll repeat my suggestion: when the overflow is not set to “visible”, it wold be best to make the text behave as it does on an Apple “Stickies” note, instead of extending the box downwards.
I can only edit the text if the overflow is set to “visible”. If it
is set to “scroll” or “auto”, the HTML box extends downwards when I
click on the text, but all I see is a white rectangle (which indeed
covers other items). I can click somewhere in the rectangle and the
cursor will blink: it’s clear that it’s somewhere in the text, but
I cannot see the text itself.
Could you send your document (if it’s less than 10MB) to
supportATsoftpressDOTcom along with some directions as to which item
is not doing this correctly. It seems that there may be a bug to be
found here.