In mail.css there you created a CSS selector for #preview as you see below. I then was able to make IE6 work with the next 2 selectors.
The first one is a little more specific than the first selector so it will override the values from the first selector and use that expression to set the height for the preview panel. The next selector is a child selector which is only recognized by Firefox, IE7 and other modern browsers. That basically resets the height back to the default. The layout works as well in IE7 as it does in Firefox, so that is good. And this change does make it work for IE6, but once you adjust the size of your window the measurments are changed. My guess is the CSS expressions may not be reevaluated when the window changes size. But if you were to reload the page in IE6 it will fix the height so the preview works right.
My guess is that IE6 does not handle the bottom style rule very well in this case. So setting the height with a dynamic value was the way I fixed it.
Below is the CSS.
#previewpane { position: absolute; display: none; top: 85px; left: 200px; right: 40px; bottom: 40px; border: 1px solid #999999; border-top: none; background-color: #F9F9F9; overflow: auto; /* css hack for IE */ width: expression((parseInt(document.documentElement.clientWidth)-240)+'px'); }
div#previewpane { height: expression(( parseInt(document.documentElement.clientHeight) - parseInt(document.documentElement.clientHeight/2) - 64 )+'px'); }
body > div#previewpane { height: auto; }
Brennan Stehling http://brennan.offwhite.net/blog/
On Thu, 07 Sep 2006 08:47:33 +0200, Robin Elfrink elfrink@introweb.nl wrote:
Brennan Stehling wrote:
I can probably fix your IE6 issues.
Oh, that would be very nice.
Can you place a Zip of the full RC installation someplace where I can
download it?
Here it is:
....
Robin
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
Brennan Stehling wrote:
In mail.css there you created a CSS selector for #preview as you see below. I then was able to make IE6 work with the next 2 selectors.
The first one is a little more specific than the first selector so it will override the values from the first selector and use that expression to set the height for the preview panel. The next selector is a child selector which is only recognized by Firefox, IE7 and other modern browsers. That basically resets the height back to the default. The layout works as well in IE7 as it does in Firefox, so that is good. And this change does make it work for IE6, but once you adjust the size of your window the measurments are changed. My guess is the CSS expressions may not be reevaluated when the window changes size. But if you were to reload the page in IE6 it will fix the height so the preview works right.
My guess is that IE6 does not handle the bottom style rule very well in this case. So setting the height with a dynamic value was the way I fixed it.
Below is the CSS.
#previewpane { position: absolute; display: none; top: 85px; left: 200px; right: 40px; bottom: 40px; border: 1px solid #999999; border-top: none; background-color: #F9F9F9; overflow: auto; /* css hack for IE */ width: expression((parseInt(document.documentElement.clientWidth)-240)+'px'); }
div#previewpane { height: expression(( parseInt(document.documentElement.clientHeight) - parseInt(document.documentElement.clientHeight/2) - 64 )+'px'); }
body > div#previewpane { height: auto; }
Brennan Stehling http://brennan.offwhite.net/blog/
On Thu, 07 Sep 2006 08:47:33 +0200, Robin Elfrink elfrink@introweb.nl wrote:
Brennan Stehling wrote:
I can probably fix your IE6 issues.
Oh, that would be very nice.
Can you place a Zip of the full RC installation someplace where I can
download it?
Here it is:
....
Robin
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
Really, all you need is to define the height in the first selector.
Since we're working with IDs, there should never be more than one on the
page (so no p, span, h3, table, form, or other ID named "preview"). So
your 3 selectors can come down to one: #preview, and body > #preview.
Brennan Stehling wrote:
My guess is that IE6 does not handle the bottom style rule very well in this case. So setting the height with a dynamic value was the way I fixed it.
Below is the CSS.
Oh, very very nice, thanks.
I had been trying to do something like that, but getting height from #mailcontframe but couldn't get it to work.
Now if only, after resize, both #mailcontframe and #previewpane would recalculate the use half of the space each.
Robin
Robin Elfrink wrote:
I had been trying to do something like that, but getting height from #mailcontframe but couldn't get it to work.
Now if only, after resize, both #mailcontframe and #previewpane would recalculate the use half of the space each.
Oh nevermind, got that too, now:
height: expression(( parseInt(document.documentElement.clientHeight) - parseInt(document.getElementById('mailcontframe').clientHeight) - 125)+'px');
Now for Internet Explorer to break long lines, didn't even see that before, was too busy resizing <div>s ...
Robin
Good morning,
On 7-Sep-06, at 7:37 AM, Robin Elfrink wrote:
Now for Internet Explorer to break long lines, didn't even see that before, was too busy resizing <div>s ...
I've used the following "hack" before to force long lines to break.
In my testing, it works in Safari / Firefox / IE / Opera without hassle.
The <wbr> tag is non-standard though so any XHTML validators will
complain ... but it's the best I could come up with that was the most
compliant and compatible:
<span><wbr style="content: '\00200B'" /></span>
If you insert that every so often into long strings, it creates an
optional line break that doesn't otherwise affect copy/paste or
create any odd visual artifacts if no break is required.
(I tend to insert it every 15 characters in strings longer than 15
characters.)
I don't have any PHP-foo do to that automagically, but here's my Perl-
foo that does it. I can feed arbitrary html and it'll intelligently
insert it, without clobbering html <tags> or anything... if someone
can help convert it into PHP, simply add it to the output function
for your emails (or anywhere you need it) and it should work. I just
call:
my $html = '<div><p>some html <a href="/
somethinglonginatagthingy">here</a> with
reallyreallyreallylongstringsofcharacters and other things.</p></div>';
print html_splitter($html);
Output:
<div><p>some html <a href="/somethinglonginatagthingy">here</a> with reallyreallyrea<span><wbr style="content: '\00200B'" /></ span>llylongstringso<span><wbr style="content: '\00200B'" /></ span>fcharacters and other things.</p></div>
Let me know, I'm happy to address comments / concerns / criticisms of
the technique :-)
(note for Perl-isms: all the HTML::Entities stuff is needed to
properly work with embedded entities without splitting in the middle;
so that & is recognized as one character and preserved and not
split half-way through)
---begin perl---
#
# call as: html_splitter( $string [, length] )
# returns: your string, with a
#
# <span><wbr style="content: '\00200B'" /></span>
#
# inserted every [length] characters (15 by default) on
inter-tag
# "words" (non-space characters actually) longer than [length]
#
# the effect (so it seems with testing so far) of letting
# browsers and email clients split real long strings (such as
# email addresses or urls) while retaining their copy-and-paste
# ability
#
# Note: this code doesn't validate, as <wbr> isn't a W3C
official entity
#
# Note: we assume the string may contain markup, and so we
don't process
# and text between <> (tag-like sequences)
#
# Note: to prevent splitting HTML entities (& for
example), we decode
# all string fragments into multi-byte chars, do the
splitting (if needed),
# then re-encode into HTML entities
#
# Compatibility: tested thus far with Firefox, Safari, IE,
Opera
#
sub html_splitter {
my $string = shift;
my $length = shift || 15;
# find interesting bits and turn to next subroutine
$string =~ s/(^|>)([^<]+)(<|$)/$1 . string_splitter($2,
$length) . $3/egs;
return $string;
}
# # used by html_splitter() to actually break the chunks # sub string_splitter {
my $string = shift;
my $length = shift;
# first, decode any entities
HTML::Entities::decode_entities($string);
# next split any long words in this bit
$string =~ s/(\S\S{$length,})/word_splitter($1,$length)/eg;
return $string;
}
# # used by string_splitter() to do the work # sub word_splitter {
my $string = shift;
my $length = shift;
my $strlen = length($string);
my $out = HTML::Entities::encode_entities(substr($string, 0,
$length));
for (my $i = $length; $i < $strlen; $i += $length) {
$out .= q|<span><wbr style="content: '\00200B'" /></span>|;
$out .= HTML::Entities::encode_entities(substr($string, $i,
$length)); }
return $out;
} ---end perl---
Robin
-Michael
Michael Burns Cosbit Technologies 403-701-2672 / michael.burns@cosbit.com
GTalk: cmikeburns AIM: cmikeburns MSN: cmikeburns _______________________________________________________
Box 2173, Station M • Calgary, Alberta, Canada • T2P 2M4 http://cosbit.com
Yes, you can compact it a little. I just did it that way to make sure my change was obvious.
It is going to be very interesting to see how quickly IE7 replaces IE6. Then these annoying little problems will go away.
Brennan
On Thu, 07 Sep 2006 08:18:02 -0400, Brett Patterson brett@bpatterson.net wrote:
Brennan Stehling wrote:
In mail.css there you created a CSS selector for #preview as you see
below. I then was able to make IE6 work with the next 2 selectors.
The first one is a little more specific than the first selector so it
will override the values from the first selector and use that expression to set the height for the preview panel. The next selector is a child selector which is only recognized by Firefox, IE7 and other modern browsers. That basically resets the height back to the default. The layout works as well in IE7 as it does in Firefox, so that is good. And this change does make it work for IE6, but once you adjust the size of your window the measurments are changed. My guess is the CSS expressions may not be reevaluated when the window changes size. But if you were to reload the page in IE6 it will fix the height so the preview works right.
My guess is that IE6 does not handle the bottom style rule very well in
this case. So setting the height with a dynamic value was the way I fixed it.
Below is the CSS.
#previewpane { position: absolute; display: none; top: 85px; left: 200px; right: 40px; bottom: 40px; border: 1px solid #999999; border-top: none; background-color: #F9F9F9; overflow: auto; /* css hack for IE */ width:
expression((parseInt(document.documentElement.clientWidth)-240)+'px');
}
div#previewpane { height: expression(( parseInt(document.documentElement.clientHeight) - parseInt(document.documentElement.clientHeight/2) - 64 )+'px'); }
body > div#previewpane { height: auto; }
Brennan Stehling http://brennan.offwhite.net/blog/
On Thu, 07 Sep 2006 08:47:33 +0200, Robin Elfrink elfrink@introweb.nl
wrote:
Brennan Stehling wrote:
I can probably fix your IE6 issues.
Oh, that would be very nice.
Can you place a Zip of the full RC installation someplace where I can
download it?
Here it is:
....
Robin
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
Really, all you need is to define the height in the first selector. Since we're working with IDs, there should never be more than one on the page (so no p, span, h3, table, form, or other ID named "preview"). So your 3 selectors can come down to one: #preview, and body > #preview.
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
Robin Elfrink wrote:
Now for Internet Explorer to break long lines, didn't even see that before, was too busy resizing <div>s ...
A simple <pre> did the trick.
I've put up my patch for preview pane support in the trac system, ticket number 1484008.
http://trac.roundcube.net/trac.cgi/ticket/1484008
Robin
Hi Robin,
Thanks a lot for your efforts on this RoundCube feature. Let me just add my 2 cents...
I guess the preview box is something that is defined and styled by the skin. This implies that it's position and it's size is completely controlled by the skin. The only thing the app.js should do is to check whether there is a container to display the preview or not. I don't like the behavior that the message list is cropped to half size when you first click a message. Either the preview pane is available (again, it's the skin that enables it) or it isn't at all.
As already mentioned, the preview pane should not be controlled by the application but only by the skin. This also means, the there should not be any configuration parameters related to the preview pane. If your skin does not provide it, what's the configuration parameter for? At least, that's something your users may ask.
Please don't get me wrong. I like what you've done so far, but I just like to keep things separated and not mashed up.
Regards, Thomas
Robin Elfrink wrote:
Robin Elfrink wrote:
Now for Internet Explorer to break long lines, didn't even see that before, was too busy resizing <div>s ...
A simple <pre> did the trick.
I've put up my patch for preview pane support in the trac system, ticket number 1484008.
http://trac.roundcube.net/trac.cgi/ticket/1484008
Robin
Thomas Bruederli wrote:
Please don't get me wrong. I like what you've done so far, but I just like to keep things separated and not mashed up.
No problem, it's just that I need a preview pane in order to get an OK from management to replace our webmail with roundcube, and I thought I'd just share what I have so far.
When I have things up and running I'll have more time to make it work the 'proper' way :)
Robin
-
Brennan Stehling -
Brett Patterson -
Michael Burns -
Robin Elfrink -
Thomas Bruederli