Henri

Email conversation

From	Henri
To	Me
Subject	problem with browser windows width detection in MSIE6
Date	15 February 2006 16:31
Attachment	Demo page

Hello Mark,

When I tried to beautify a crude script that I found somewhere
[URL]
on the WWW, I found some JavaScript code on your website
(Obtaining the browser window size
<http://www.howtocreate.co.uk/tutorials/javascript/browserwindow>) that
should do the trick.

Thus I copied your code into my pages and gave it a test. All works fine
in Firefox (exept for the scrollbar wich appears briefly when the image
is at the far right) but it's disatreous when viewed with Internet Explorer.

The goal is that the movement of the image is 'aware' of the size of the
browser window or the page size, even when it is used in an IFRAME
construction.

Note that I intentionally left the window _height_ detection in the code
though it's not really used for the movement of the image.

When I bluntly use 'screen.width' all works fine in both browsers but it
looks very bad off course.

I guess that the best solution will be to determine the width (and
height for the matter) of the enclosing table element, but how can I
achieve this?

I am an experienced HTML & JavaScript programmer but a newbie to the DOM
things.

In case the attachment gets lost, here are the URLs:
[URLs]

Thanks in advance for your help,
Henri

From	Me
To	Henri
Subject	Re: problem with browser windows width detection in MSIE6
Date	20 February 2006 09:56

Henri,

> Thus I copied your code into my pages and gave it a test. All works fine
> in Firefox (exept for the scrollbar wich appears briefly when the image
> is at the far right) but it's disatreous when viewed with Internet Explorer.

It also works beautifully in Opera ;)

You should read the width again each time you need it (so it copes with
resizing, and note that the width cannot be measures in Internet Explorer
until _after_ the page loads. Put the code for obtaining the width inside
your timer function.


Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/

From	Henri
To	Me
Subject	JavaScript slideshow
Date	14 April 2006 01:07

Hello Mark,

Finally I had some time to pick up an issue we discussed earlier. Please
take a look at [URL] and [URL]
(please note that this is a brand new site still heavily under construction)

You will notice that initially the images are neatly next to each other,
starting at the left side. I had to fix this brute force by defining a
table that is wide enough to hold a row of images filling the top of the
window at higher resolutions like, let's say 1600x1200. When looking at
the code you will notice that I placed the window-size detection inside
the timed function like you sugegsted.

As you can see, the moment the JavaScript routines kick in, the
scrolling of the thumbnails starts from the rightmost position, which
looks very bad.

Any suggestions?


Regards,
Henri

From	Me
To	Henri
Subject	Re: JavaScript slideshow
Date	15 April 2006 11:37

Henri,

> As you can see, the moment the JavaScript routines kick in, the
> scrolling of the thumbnails starts from the rightmost position, which
> looks very bad.

I am trying to work out what you want it to do.

At a guess, you want it to start at the left edge, and scroll left until
the right edge of the slide reaches the left edge of the window, then reset
it so that it is where it starts in your current demo.

The problem is that you reset it when left == 0. What you want to do is
reset it when left <= -1 * widthOfSlides.

You can find the width of the element using its offsetWidth property. I got
a better effect by changing this:
if (H <=0) {
to this:
if (H <=document.getElementsByTagName('table')[0].offsetWidth*-1) {

From	Henri
To	Me
Subject	Re: JavaScript slideshow
Date	18 April 2006 02:51

Hi Tarquin!

Your suggestion was excellent. The *result* 
[URL] is much better now.
There's one more thing I want to achieve.

Please take a look at *this* 
[URL]
(playing around with the parameters it turns out that in this situation the 
maximum width is 800 pixels, I guess the programmer is using an old laptop ;-) 
). It looks like this image
 
is moved to the end of the sequence when it has become completely invisible. 
Then this image becomes the left-most one:
 
.... and the proces continues _*without a gap*_ between the last image and the 
first when the latter re-appears at the right side. I guess you catch the drift....
At least this demontrates that my goal is realistic.

On the [brand] [URL] home page 
[URL] one can see another continuous slideshow. Helas, 
the JavaScript is been made hard to read. Do you know whether there is a 
reverse-engineering tool to cope with this?

Note that [URL] uses 1,2,..,8,9,10,.. for the numbering, 
I prefer to use 01,02,..,08,09,10,.. to avoid operating system quirks in the 
sorting of directories.

On itself I consider it a *minor* problem, but I noticed that the speed at which 
the images move is heavily dependent on the PC's processor speed. Do you happen 
to know a neat solution to this?

I am very curious about your response!


Kindest regards,
Henri

From	Me
To	Henri
Subject	Re: JavaScript slideshow
Date	20 April 2006 11:32

Henri,

> is moved to the end of the sequence when it has become completely
> invisible. Then this image becomes the left-most one:

I would take a completely different approach to this.

1. use a relatively positioned div as a container (where you are using your
table now), with its height set to the height of the images. Set overflow to
hidden on it to prevent a scrollbar on the page.

2. absolutely position all images inside it, so that they are side-by-side,
each one offset to the calculated sum of the widths of the images before it.

3. get all the images in the div (get a reference to the div, then use its
getElementsByTagName method to get all the images in it).

4. move each of them left by the stepping amount (1px or whatever).

5. if the left-most image position is less than or equal to
-1*width-of-the-image, then use appendChild to put the image at the end of
the list (this is not essential, just makes things easier to manage).
Recalculate its position, based on the width of the image beside it (its
previousSibling, assuming you do not leave any spaces between images in the
source of your HTML), and the position of that image.

Just be warned that after using appendChild, the getElementsByTagName object
recalculates all its children, so item 0 is now the second image, not the
first.

As for the speed vs processor problems you are having, you can reduce the
processor load by increasing the stepping (3px, for example) and increasing
the interval. Using absolute positioning is also a lot more efficient than
relative, as it does not force the whole document to reflow each time an
image is moved.

From	Henri
To	Me
Subject	(un)folding paragraphs
Date	18 January 2007 02:51
Attachment	Demo page

Hello Mark,

I have an interesting question for you.
The attached page does work excellent in Firefox but does not work at
all in Internet Explorer.

The goal is the have a page that initially only shows the headers, after
clicking on a header the corresponding paragraph with the body text is
revealed.
Cross-linking to a specific paragraph should be possible using the #
sign in the link, like flip-flop_pagina.html#alinea002 thus on loading
(and reloading!) the corresponding paragraph should be reveiled immediately.
Also, for maintenance reasons, the tags in the body should be as compact
as possible.
For the search engines etc. the plain old HTML-navigation without CSS
and JavaScript has to function as expected (obviously looking quit
horrible when rendered).
This is why I have that peculiar way of (not) showing the <hr>-tag.
Exceptions:
<span class="arrow">&gt;</span> in stead of just &gt; for later expansions.

Some Dutch-English translation help:
verberg = hide
toon = show
vorige = previous
alinea = paragraph
bovenkant = top

Do you have a solution for the MSIE problem?

Another question: you'll notice the multiple use of
(background-)color:#FFCC99 in the CSS definitions.
Is there a way to specify color value #FFCC99 just once and refer to
that specification for the rest of the CSS definitions as if it were a
variable?

Best wishes for 2007,
Henri

From	Me
To	Henri
Subject	Re: (un)folding paragraphs
Date	6 January 2007 18:39

Henri,

> The attached page does work excellent in Firefox but does not work at
> all in Internet Explorer.

IE (and Opera - to allow IE specific pages to work) implements a quirk where
name="foo" on certain elements is equivalent to id="foo" when using
getElementById.

Your page has this:
<a name="alinea001"></a><div id="alinea001" ...>

As a result, IE (and Opera) references the anchor instead of the div. Remove
the anchor and it works.

Note that the anchor is redundant anyway. All browsers use fragment
identifiers (aka ID attributes) as targets for #foo in URLs. So if a page
has this:
<div id="foo">
and you click this link:
<a href="#foo">
the page will scroll to the div.

> Is there a way to specify color value #FFCC99 just once and refer to
> that specification for the rest of the CSS definitions as if it were a
> variable?

No. CSS intentionally does not have variables, as it would increase the
complexity of the language. Apparently :)


Tarquin

From	Henri
To	Me
Subject	Re: (un)folding paragraphs
Date	7 January 2007 02:33

Hello Mark,

Excellent advice! Just for your website, I included the revised
document. It works perfect now.
Typical for Microsoft to mess things up like that.

Your writing "Also many people deliberately use browsers with limited
capability in order to increase browsing speed and reduce vulnerability
to exploits or viruses." applies very much to me.... :-)

About MSIE7: I operate three websites developed with MSIE5 en Firefox
1.0 as targets. After upgrading to MSIE7 and hearing many 'complaints'
about it, I must say that I noticed NO problems with the rendering or
functionality of my sites, actually no difference at all.
For me the proof that those who compain are bad programmers who did not
comply to standards!

Regards,
Henri

From	Henri (a different name, but the same quoted email...)
To	Me
Subject	userID @ Apache
Date	21 March 2007 00:26

Hello Mark,

I've replaced the JavaScript looplet stuff with a nifty Flash thingie for 
displaying the slideshow at the top of the pages. Now the speed is
independent of the CPU and memory of the client PC.

[Ed. boo! ;) ]

There is one other issue I am struggling with: how to identify a user (check if 
the user is logged in) on Apache. Any ideas?

This [URL] does NOT work:
|<?PHP
print "\n";
print 'var accountname = "';
print $HTTP_SERVER_VARS["REMOTE_IDENT"];
print '";';
print "\n\n";
?>|

Kind regards,
Henri

From	Me
To	Henri
Subject	Re: userID @ Apache
Date	21 March 2007 02:15

Henri,

> print $HTTP_SERVER_VARS["REMOTE_IDENT"];

From what I have seen, that variable is not to be trusted, but I really do
not know it, so I do not know how to use it. Suspect you may want to use
$_SERVER (the new name for $HTTP_SERVER_VARS), with one or more of the
variables like PHP_AUTH_USER or PHP_AUTH_PW (note that these do not mean
that the user is logged in, but that the user has sent a username and
password, and now your script is supposed to check if they are valid).

See the PHP docs for more information. Sorry, but I cannot be any more help
with this, as I have never used REMOTE_IDENT.

http://www.php.net/manual/en/reserved.variables.php

From	Henri
To	Me
Subject	Re: userID @ Apache
Date	21 March 2007 11:33

Hi Mark,

Thanks for the hint. Via http://www.php.net/manual/en/reserved.variables.php I 
found that I need to enable those |$_SERVER| variables in the .htaccess file. 
Helas, the solutions proposed there are either much too complex for my purpose 
or (once again) totally wrong, for example:
|$_SERVER['REDIRECT_UNIQUE_ID]'
$_SERVER['REDIRECT_SCRIPT_URL]'|
etc. will never work! ;-)

Adding |ExtendedStatus on| to .htaccess generated a website-wide internal server 
error....
Same for |php_flag register_globals on| in .htaccess (found this on the 
[URL] page)....

To make testing safer I moved the PHP script to 
[URL]
The .htaccess file in this directory contains just one line:

    |php_flag register_globals on|

Of course it will inherit everything from the .htaccess file that resides in the 
root directory.
Note that I changed the PHP script in such a way that the actual userID will 
never be send over the (insecure) connection, only a simple 'YES' or 'no'. Can 
you verify if this new PHP code is syntactically correct? See attachment.

Please note that the goal is to find out if a visitor has logged in so it can be 
decided if requests to [URL] (public 
area) should be redirected to 
[URL] (members-only area) when 
the corresponding link (Companions) is clicked on from one of the pages that are 
common to both the public area and the members-only area, for example 
[URL] - this avoids the nesessity to have 
duplicates of the pages that are common to both areas. It turns out that using 
cookies is not a very good way to keep track as this option may be disabled in a 
browser or when using an anonymising proxy. The use of MySQL is no good eighter 
- in that case one has to 'invent' an entire login-procedure depending on the 
database in stead of using the simple .htaccess & .htpasswd mechanism.

In all the above may turn out to be an interesting case for you to publish...?

Regards,
Henri

From	Me
To	Henri
Subject	Re: userID @ Apache
Date	21 March 2007 12:32

Henri,

>     |php_flag register_globals on|

You do not need to use this unless your scripts actually rely on it. It is
not recommended unless you know you need it, and you understand the
implications of it.

> Note that I changed the PHP script in such a way that the actual userID
> will never be send over the (insecure) connection, only a simple 'YES'
> or 'no'.

Not really true. The PHP might not send it, but the browser will send it for
every request to that server/realm once the user has successfully logged in,
until they close their browser (though you can improve matters significantly
with digest instead of basic authentication). That is how basic HTTP
authentication works.

> Can you verify if this new PHP code is syntactically correct? See
> attachment.

looks fine, although you could shorten it to:

<?php
print "\nvar validuser = \"'.(isset($_SERVER['PHP_AUTH_USER'])?'YES':'no')."\";\n\n";
?>

The .htaccess and .htpasswd files will take care of making sure that files
are protected, but have a basic response of either telling the user to log
in, or having them logged in. The user cannot simply choose to log in while
already looking at the page unauthenticated. Once logged in, the header will
be sent.

This assumes you are using something like this in .htaccess:
AuthType Basic
AuthUserFile /path/on/server/to/.htpasswd
AuthName "Our private stuff"
Require valid-user

> In all the above may turn out to be an interesting case for you to
> publish...?

Pretty much all emails sent and received for this site are published, so the
information will be available (without references to your sites etc.).

From	Henri
To	Me
Subject	Re: userID @ Apache
Date	21 March 2007 13:18

Hi Mark,

>> |php_flag register_globals on|
> You do not need to use this unless

Thats why I moved the stuff to a separate directory named 'userID'. Besides the 
.htaccess and the userID.php it's empty.

> the browser will send it

You can't have it all....

> <?php
> print "\nvar validuser = \"'.(isset($_SERVER['PHP_AUTH_USER'])?'YES':'no')."\";\n\n";
> ?>

Thanks, that looks much better.

> This assumes you are using something like this in .htaccess:

With this addition to that .htaccess file:

<Files .htaccess>
order allow,deny
deny from all
</Files>

> Pretty much all emails sent and received for this site are published, so the 
> information will be available (without references to your sites etc.).

I wouldn't mind a *link* [URL] to our website.... ;-)

[Ed. Sorry. Please see the policy.]

Regards,
Henri

From	Henri
To	Me
Subject	CSS troubles
Date	30 March 2007 00:35

Hello Mark,

I've two pages with unexpected results in Firefox:

[URL]
Here the height of the bordered text part is too short in Firefox.

[URL]
Here the height of the bordered text is to long in Firefox.

Do you have a suggestion on how to fix this?

Thanks in advance for answering my questions,

Henri

From	Me
To	Henri
Subject	Re: CSS troubles
Date	30 March 2007 10:57

Henri,

> [URL]

This page gives me a 404, and due to it also getting 404s for the
stylesheets and iframe 404 content, it goes into an infinite loop of loading
pages and images. After loading 700 images, I found it a little painful and
closed the page. You should make sure your 404 page does not recursively
load itself.

> [URL]
> Here the height of the bordered text is to long in Firefox.

And it is also too long in Opera - please give results for Opera in future
communication <http://www.opera.com/download/>.

You are trying to make div.content use a percentage height: 65%. According
to the spec, that should be 65% of the parent's computed height. The parent
element (div.envelop) has no height specified, so its computed height is
"auto". 65% of "auto" is "auto", so Opera and Firefox do the right thing,
and allow it to grow to fit its contents.

IE has a bug where it will keep walking up through the ancestors until it
finds an element with specified height, and it will use that instead. So
although IE's response is what you want, it is actually wrong.

The solution is to make div.envelop use the height 65% (which will be
relative to the body, which has specified height), then make div.content use
100% of div.envelop's height:
div.envelop { height: 65%; }
div.content { height: 100%; }

This change will fix both of the problems you mentioned.

From	Henri
To	Me
Subject	Re: CSS troubles
Date	30 March 2007 17:41

Hi Mark,

Sorry about that 404.... A cumulation of changes:
[1] [URL]
    (note the addition of the "-"-sign)
[2] bad implementation (my own doing) in .htaccess (now repaired)

Now the original problem: somehow it still does nog work the way I want it.
The maths:
HTML height: 100%
BODY height: 100%; max-height: 100% (child of HTML)
div.header height: 30% (first child of BODY)
div.envelop height: 67% (second child of BODY)
div.content height: 100% (child of div.envelop)

I tried div.envelop {height: 70%;} but then I gets really ugly:
Firefox does not display the .content-part correctly.
The trade-off was 67%.

Help!!!!!!
(I'm lost)

Regards,
Henri

From	Me
To	Henri
Subject	Re: CSS troubles
Date	31 March 2007 18:56

Henri,

> Firefox does not display the .content-part correctly.

As I asked in the last email, please save me some time and effort by
checking in Opera as well:
http://www.howtocreate.co.uk/sendEmail.php#testbrowsers
http://www.opera.com/download/

> Now the original problem: somehow it still does nog work the way I want
> it. The maths:
> div.header height: 30% (first child of BODY)
> div.envelop height: 67% (second child of BODY)

Nearly right, but not quite.

You have a HTML comment in the document _before_ the DOCTYPE, which
throws IE into quirks mode. Remove that comment so IE behaves like
Firefox and Opera, and renders the page correctly, known as "standards
mode".

In standards mode, the height is the height of the content, _without_
the padding or border. So the outer height of div.envelop is:
padding-bottom: 48pt; + height: 67%;
_NOT_ just:
height: 67%;

The same happens with div.content; its height is not 100%. It is:
height: 100%; + padding-top: 12pt; + 2 x border: 3px

From	Henri
To	Me
Subject	accompanyment (French)
Date	3 April 2007 18:33

Hello Mark,

After fixing [URL] with the line
|<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">|
some problems arose that did not exist before the change.

|<font face="Wingdings">(</font>| is not displayed using the Wingdings font
any longer in Firefox and Opera.

In Firefox and MSIE the text 'shakes' when you hover over it with the mouse.

NOTE
Please don't publish the LINK to this (just the content if you wish):
[URL]
(you better rename the script to something like demo.php or so)
I guess you can figure out how to make use of the above....

Can you help me solve this?

Regards,
Henri


PS You might have noticed that I took your advice and test with Opera as
well from now.

From	Me
To	Henri
Subject	Re: accompanyment (French)
Date	3 April 2007 22:12

Henri,

> |<font face="Wingdings">(</font>| is not displayed using the Wingdings
> font any longer in Firefox and Opera.

This is a little odd. Turns out that wingdings violates some parts of
unicode, and as a result is not rendered by standards compliant browsers.
Firefox has a deliberate bug (known as a quirk) to allow it to work if you
do not trigger standards mode. Opera does not render it in any mode. There
is more explanation here:
http://groups.google.com/group/opera.page-display/browse_frm/thread/...

Turns out the suggested approach is to use HTML entities to use the unicode
character:
&#9990;
Sadly with IE's poor font switching, it will not find the character without
some help. So you will have to specify a font family that contains it, such
as 'Arial Unicode MS' and hope that IE users have it installed.

I really do not have a reliable suggestion using real fonts, I am afraid.
All I can say is that Wingdings is not a good font to rely on, especially
given its lack of support on most operating systems. The only reliable
alternative is to use an image.

> In Firefox and MSIE the text 'shakes' when you hover over it with the
> mouse.

Opera also has a variant of this - it only does it once though, the very
first time you hover the document.

These lines:
 :hover img         {border: 1px dashed RGB(102,0,0);}
 :hover img         {-moz-border: 1px dashed #000000;}
should be like this:
 a:hover img         {border: 1px dashed RGB(102,0,0);}
 a:hover img         {-moz-border: 1px dashed #000000;}

In standards mode, :hover detection works on any element, not just links. IE
initially had a bug where it would only work on links (finally got fixed in
IE 7). As a result, pretty much all browsers have decided to add that same
bug intentionally into their quirks modes.

> PS You might have noticed that I took your advice and test with Opera as
> well from now.

Thanks, makes things a lot more easy :)

From	Henri
To	Me
Subject	solution # 1: accompanyment (French)
Date	4 April 2007 05:25

Hello Mark,

The 'shaking' of the text etc. is solved now. Remaining problem: the
Wingdings font.

Found on http://en.wikipedia.org/wiki/Zodiac
#{{unicode|♈}} Áries  (0°)
#{{unicode|♉}} Taurus (30°)
#{{unicode|♊}} Gémini (60°)
#{{unicode|♋}} Cancer (90°)
#{{unicode|♌}} Léo (120°)
#{{unicode|♍}} Virgo (150°)
#{{unicode|♎}} Libra (180°)
#{{unicode|♏}} Scórpio (210°) - should render like
#{{unicode|♐}} Sagittárius (240°)
#{{unicode|♑}} Capricornus (270°)
#{{unicode|♒}} Aquárius (300°)
#{{unicode|♓}} Pisces (330°)

This should provide a cross-platform solution.

Bad thing:
[URL showing use of @font-face rule]
Embedded fonts are (as far as I know) only supported by MSIE and bound to a
list of domains somehow included in the .EOT

Other solution:
as replacement for |<font face="Wingdings" class="Wingdings">$</font>|
HTML-code:
|<img src="../../images/spectacles.png" style="display: inline;" NOsave 
border="0" width="24" hspace="0" vspace="0" galleryimg="no">|

To do:


  To be continued....


Regards,
Henri

From	Henri
To	Me
Subject	solution # 2: accompanyment (French)
Date	4 April 2007 21:45

Hello Mark,

Remaining problem: the Wingdings font.

For some reason [URL] is still fine 
but [URL] was not.... This fixed it:
Graphic
	Old
	New
	Character
	<font face="Wingdings" color="#FF6600">§</font>
	<font color="#FF6600">&#9632;</font>
	■
	<font face="Wingdings" color="#00CC00">ü</font>
	<font color="#00CC00">v</font>
	√
	<font face="Wingdings" color="#CC0000">û</font>
	<font color="#CC0000">*×*</font>
	*×*
	
	<font color="#6FDEE8">?</font> 	?

Most of the other Wingdings are controlled by the common JavaScript library so I 
was lucky: only 1 small change for the entire website. The Wingdings have no 
significance for search engines so the use of tiny images as replacement has no 
unwanted impact on that.

One more hurdle to take: the _zodiac signs_.

Regards,
Henri

PS www.unicode.org/charts/symbols.html didn't help!

From	Henri
To	Me
Subject	scrollbars: accompanyment (French)
Date	4 April 2007 23:23

Hello Mark,

After the last modicfication some pages still display with a coloured
scrollbar but others now display with the default scrollbar in MSIE.

Bad scrollbar:
[URL]
[URL]
[URL]

Good scrollbar:
[URL]

What did I do wrong?

Regards,
Henri

From	Henri
To	Me
Subject	Re: CSS troubles
Date	5 April 2007 08:58

Hi Mark,


I've got a weird bug (I think):
[URL]
[URL]
Parts of [URL]/common.css :
h4.special          {display: inline; float: left;}
h4.special + p      {display: inline; float: left; margin-left: 12pt;
  font-style: italic;}
h4.special + p b    {font-size: 10pt; font-style: italic; font-weight:
  bolder;}
h4.special + p + p  {clear: left;}

Firefox: bullet okay

Opera: bullet too low

MSIE: bullet near the end of the line in stead of the front
coincidently the bullet is on top of the delimiter (comma in Dutch and dot
in English)


Firefox & MSIE do render [URL] as intended. Opera does not: the text that is
supposed to be between "November, 1st 2006"/"1 november 2006" and the next
item "August, 1st 2006"/"1 augustus 2006" shows up at the bottom
in Opera. What's wrong?


Thanks in advance for your help,
Henri

From	Me
To	Henri
Subject	Re: scrollbars: accompanyment (French)
Date	6 April 2007 17:05

Henri,

> After the last modicfication some pages still display with a coloured
> scrollbar but others now display with the default scrollbar in MSIE.

The pages where it works are displayed in quirks mode because they use the
wrong DOCTYPE. The pages where it currently fails use the right DOCTYPE so
they are rendered in standards mode. In standards mode, the scrollbars are
applied to <html> not <body> but your stylesheet applies the scrollbar
styles to the body.

From	Me
To	Henri
Subject	Re: CSS troubles
Date	6 April 2007 17:35

Henri,

> Firefox: bullet okay
>
> Opera: bullet too low

That'll be a bug in Opera (they are aware of it). It does not like the first
contents of a list item to be a float.

> MSIE: bullet near the end of the line in stead of the front

That's a worse bug in IE ;) It is basically the same problem as in Opera,
but a lot worse in its result.

Basically, there is no easy workaround to this problem (I can easily make a
workaround for Opera using generated content, but that is not supported in
IE), but there is a possible solution:
Set the LI to display:block;list-style-type:none;
Put &middot; at the start of each of the H4s
Use a negative margin to pull the H4 to the left, so the middot appears to
the left of the text content.

> Opera does not: What's wrong?

You are only allowed to have one <thead> per table, according to the HTML
spec. After that, you can have as many <tbody> sections as you need, but you
are still only allowed to have a single thead. Your table has two of them,
so the browser is left to use error handling to work out what you were
trying to do - each browser has its own approach, but it seems Opera's is to
put each <thead> up at the top of the table, where you expect only the first
to appear. Change the second <thead> to a <tbody> and it will work
properly.

From	Henri
To	Me
Subject	Re: scrollbars: accompanyment (French)
Date	8 April 2007 11:05

Hi Mark,

This was an easy one to fix (for a change)! Thanks to your advice.
Old
body {scrollbar-base-color: RGB(102,0,0);}
New
body, html {scrollbar-base-color: RGB(102,0,0);}

I simplified it here to make it clear to read.

Now it looks like I intended it to look.

Thanks,
Henri

From	Henri
To	Me
Subject	troubles
Date	9 April 2007 01:05

Hello Mark,

Here is an interesting bug:
[URL]

You will see that Firefox handles the CSS-lang thingies okay but MSIE doesn't.

Also, MSIE shows a dotted grey border around the video object when you hover 
over it. Do you know how to get rid of that?

But the big problem is that Firefox, MSIE & Opera do no longer center the 
content vertically. This occurred after I added this line:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">

Any suggestions?

You also might notice I found a solution for the Ç-problem: ◄┘. This satisfies 
me much better than the use of an image: the :hover still works the same without 
complicated additional CSS definitions.

Last but not least:
On [URL] I can predict 
what happened as I am the author of this page, but assume someone found it using 
[a search engine]. There are two possibilities (depending on the user's settings):
(1) Page opened in the same window
(2) Page opened in a new window
Is there a way to detect this?

Thx,
Henri

From	Me
To	Henri
Subject	Re: troubles
Date	9 April 2007 12:47

Henri,

> You will see that Firefox handles the CSS-lang thingies okay but MSIE
> doesn't.

IE does not support the :lang selector. You can use the attribute selector
instead as long as you do not need to detect inherited lang values:
span[lang="en-GB"]
However, this is also not supported in IE 6. If you need IE 6 support, you
will need to apply a class to the elements that says what lang value they
have, then use a normal class selector instead.

> Also, MSIE shows a dotted grey border around the video object when you
> hover over it. Do you know how to get rid of that?

http://www.howtocreate.co.uk/noclicktoactivate.html

> But the big problem is that Firefox, MSIE & Opera do no longer center the
> content vertically.

The DOCTYPE triggers strict rendering mode, where the <html> element is
attached to the viewport but can change size as needed. Before, it was using
quirks mode. Most (but not all - Safari would be an exception) browsers have
a quirk in their quirks mode that attaches the <body> to the viewport, and
does not allow it to change size.

In strict mode, since the <body> and <html> elements can both have auto
height, your table uses 100% of auto, which resolves to auto. What you need
to do is give the <html> and <body> elements an explicit height to make them
both 100% of the height of the viewport:
html, body { height: 100%; width: 100%; margin: 0; padding: 0; }

> On [URL] I can predict what happened as I am the author of this page, but
> assume someone found it using [a search engine].
> Is there a way to detect this?

Not entirely sure what you want to know here.

You can use the referer header to see where they came from. If the header
shows your own site, they came from a page on your own site. If it shows a
search engine's URL then they came from that URL. If it is blank, they typed
it in manually, or used a bookmark. It's not perfect because for privacy
reasons, some users disable sending of the referer header.

As for detecting if it was opened in the same window or a new window, you
would have to be able to check if the window has any back history. This is
not possible, for privacy reasons. It is possible to check if the window was
opened by a script as a popup by checking for the window.opener property
using JavaScript. A few browsers also provide this for windows opened by the
user using the "open in new window" option from their context menu, or in
rare cases, also if they click a link with target="_blank". However, that
behaviour is incorrect according to the JS spec, and should not be relied
on.


Tarquin

From	Henri
To	Me
Subject	Re: troubles
Date	10 April 2007 09:25

Hello Mark,

I'll leave the span[lang] for what it is.

[URL about click-to-activate] - Microsoft... again! I am not 
going to fix that dotted gray border eighter with a work-around. Visitors can 
send their complaints to this addresses:
[Microsoft support addresses]
;-)

A simple on-off switch for embedded music was needed to prevent mixing with the 
audio-tracks of the pop-ups with the [brand] videos. When searching the Internet 
for a solution nothing applicable turned up withing the top results of the 
search engines. Thus I created someting of my own. Secondary benefit: the page 
load faster with embedded sound switched off as default. You might want to 
publish this AJAX trick at your website. It needs only one thing fixed: I want 
it to remain visible when the rest of the content is scrolled up or down. Can 
you tell how to accomplish this?
Also, the OFF-switching does not work in MSIE. Any suggestions?
Opera: the OFF-switching makes the thingie jump to some lower position in the 
window, my fix: |style="...; height: 1px; width: 1px;"|

Here is the English variant: [URL]
|<script type="text/javascript" Language="JavaScript"><!--
 fix_ActiveX('<embed id="music" style="display: inline;" 
src="../audio/Suba_Felicidade.MP3" volume="100" delay="3" hidden="true" 
autostart="true" loop="false"></embed>');
// --></script><NOscript><embed style="display: inline;" 
src="../audio/Suba_Felicidade.MP3" volume="100" delay="3" hidden="true" 
autostart="true" loop="false"></embed></NOscript>|
Did not work in this page....

In Opera [URL] renders serveral items at 
the wrong position: "Last modified on ..." and the date is wrong (1/1/1970).

MP3s in Firefox & Opera: after playing the first ½ second it aborts the playback 
and restarts. MIDI does not have this problem at all.

Something different, what is the easiest way to count the link-total on 
[URL] using JavaScript?

Regards,
Henri

From	Me
To	Henri
Subject	Re: troubles
Date	14 April 2007 11:40

Henri,

> It needs only one thing fixed: I want it to remain visible when the rest
> of the content is scrolled up or down. Can you tell how to accomplish this?

position:fixed;
Not supported in IE 6-.

> Also, the OFF-switching does not work in MSIE. Any suggestions?

Plugins are _really_ not my area. I generally browse with them disabled for
various reasons (let's just say that I absolutely despise them, and leave it
at that ;) ). From the looks of it, you are using a hack based on display in
the hopes it will influence a plugin, which in IE's case it does not. With
many plugins in IE, the element has a .stop() or .Stop() method, but in this
case there isn't one. I do not know what to suggest.

> In Opera [URL] renders serveral
> items at the wrong position: "Last modified on ..."

Your document uses quite an impressive set of invalid markup :) Amongst
other things, you have a blockquote, div, p, and noembed all inside a H6,
which is not allowed to contain any of those things. As a result, the
browser's error handling is having to come into play, and I am afraid it is
not working as well as you need. However, ignoring the other problems, there
is a fairly easy fix. You have an iframe that is set to align="left" and
width="100%". The align attribute is not needed, since it is 100% width
anyway. Remove that attribute, and the browser's error handling then works
well enough to cope with the rest of the page.

> and the date is wrong (1/1/1970).

Your server is not sending the Last-Modified header. The browser is left to
assume what date it was modified. Firefox assumes it was modified today
(whatever today is). Opera follows the original spec, and says that if there
is no Last-Modified header, then the lastModified property should return the
date at UNIX timestamp 0 (1970-01-01T00:00:00). Make your server provide the
correct LastModified header, and it will work properly in all browsers.

> MP3s in Firefox & Opera: after playing the first ½ second it aborts the
> playback and restarts. MIDI does not have this problem at all.

This seems to be a bug in the plugin that they are using. I cannot reproduce
that problem here.

> Something different, what is the easiest way to count the link-total on
> [URL] using JavaScript?

javascript:alert(document.links.length)

From	Henri
To	Me
Subject	text alignment
Date	10 April 2007 15:24

> Change the second <thead> to a <tbody> and it will work properly.
The rendering by Opera and Firefox seem okay now after I changed *the page* 
<[URL]> brute force: removal 
of the <UL> & <LI> tags. The problem in Opera with the *press page* 
<[URL]> decribed above are solved 
too. Exept for _one detail_: MSIE does not align the text correctly when the 
table element contains a <sup>-tag. It look okay in Firefox & Opera. yes I know: 
formally I should change the <th> into <td>, but what the hack?

Regards,
Henri

From	Me
To	Henri
Subject	Re: text alignment
Date	14 April 2007 11:49

Henri,

> MSIE does not align the text correctly when the table element contains a
> <sup>-tag.

That'll be a bug in IE's line-height algorithm. If you set the
vertical-align:top style on the SUP, IE will behave, although the text in
the SUP then looks a little too big in other browsers. This works well in
all of them:
<sup style="vertical-align:top;font-size:0.8em">st</sup>

From	Henri
To	Me
Subject	Re: troubles
Date	14 April 2007 16:41

> As a result, the browser's error handling is having to come into play

This was fixed easily, I moved the </H6> tag. Off course I also removed the 
align-attribute.

> Your server is not sending the Last-Modified header.

Partial solution is adding this line to the <head>~</head> section:

    |<meta name="last-modified" content="<!--#echo var='last_modified' -->">|

I found this on [URL] alogn with this VERY 
stupid suggestion:

    Try something like (in .htaccess) :
    header set last-modified "Sun Jul 18 00:32:50 EDT 2004" 

> This seems to be a bug in the plugin that they are using. I cannot reproduce 
> that problem here.

On my PC Firefox & MSIE _*both*_ are configured to play MP3s using Apple 
QuickTime. Yet, only Firefox has this problem....
Here is a link where the controls for the audio plug-in are visible:
[URL]
I'll have to figure out how to select WinAmp as default MP3 player for the 
embedded audio objects.

> javascript:alert(document.links.length)

Crude but effective.... Now for something more complex, only the links that 
start with "/visit.php?url=http://"?
Is this possible?

Thanks again,
Henri

From	Henri
To	Me
Subject	Re: text alignment
Date	14 April 2007 16:54

> <sup style="vertical-align:top;font-size:0.8em">st</sup>
Hello Mark,

I took a slightly different appoach and added to common.css:
h5 sup              {vertical-align: top; font-size: 0.8em;}

Thanks for your advice,
Henri

From	Me
To	Henri
Subject	Re: troubles
Date	15 April 2007 08:55

Henri,

> On my PC Firefox & MSIE _*both*_ are configured to play MP3s using Apple
> QuickTime. Yet, only Firefox has this problem....

They still use a different plugin, since they have a different plugin
architecture. IE uses an ActiveX control, where all other browsers use a
Netscape compatible plugin API. The two plugins may still be provided by the
same product, but they are still separate plugins.

> Here is a link where the controls for the audio plug-in are visible:
> [URL]

Ok, reproduced the problem here. And here's the thing; it only goes wrong if
your animating header flash movie is playing. If you remove the iframe, it
works. I see that Quicktime is having buffering problems whenever the Flash
movie is running.

Perhaps the Netscape plugin API has limited memory available for plugins,
and the Flash movie is using almost all of it, so very little is left for
the Quicktime movie. Just guessing, of course.

> I'll have to figure out how to select WinAmp as default MP3 player for the
> embedded audio objects.

What plugin gets used depends on what mimetype you use, and what plugin the
user has installed and registered for that mimetype. You will have very
little influence over that.

>  only the links that
> start with "/visit.php?url=http://"?
> Is this possible?

Not so easy, but yes - note that it will only be reliable in browsers that
do not resolve href when using getAttribute.

var foo = 0, l = document.links;
for( var i = 0; i < l.length; i++ ) {
if(l[i].getAttribute('href').indexOf('/visit.php?url=http:\/\/') == 0) {
foo++;
}
}
alert(foo);

From	Henri
To	Me
Subject	Firefox MP3 troubles
Date	18 April 2007 22:38

Hello Mark,

I think the problem is not the iFrame with the Flash object. See 
[URL]
[program] says:
[apparently nothing - at a guess, this was an HTML email that contained some
images here, but since I only ever view emails as plain text, I see nothing]

So it might be the case that MPEG 1.0 is not properly handled by Firefox. Or the 
absence of the CRCs in the MP3....

Do you know how to replace QuickTime as the default player of embedded MP3 files 
in Firefox (or for all the browsers at once)?

Btw, in Mozilla 1.7.13 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.7.13) Gecko/20060414] the same problem occurs.

Regards,
Henri

From	Henri
To	Me
Subject	Firefox MP3 troubles 2
Date	19 April 2007 00:33

Hello Mark,

I tried <object> as alternative sulutuion for the MP3 embedding.
[URL]

Opera: the default for the volume is 0 (silent) [?] and the autoplay
goes wrong.
This additional parameters fixed it:
<param name="AutoStart" value="true">
<param name="Volume" value="100">
To fix: the alignment.

Firefox: the control is invisible, this is ignored:
<param name="ShowAudioControls" value="true">

Older Netscape (Mozilla): nothing happens, object-tag is ignored?

MSIE: all of a sudden Windows Media Player is used in stead of QuickTime
(used for the embed-tag), otherwise it's fine. With one exeption: on
load the video-part is displayed for a brief moment and then disappears
leaving only the audio-control visible. I tried to find out in the
FrontPage help files what to do. That was wasted time. This is ignored:
<param name="ShowDisplay" value="false">

Both Opera & MSIE: youi need to click the pause button twice to halt the
playback.

Local time is 01:31 here now, so I have to catch some zzz....

Regards,
Henri

From	Me
To	Henri
Subject	Re: Firefox MP3 troubles
Date	21 April 2007 11:33

Henri,

> Do you know how to replace QuickTime as the default player of embedded
> MP3 files in Firefox (or for all the browsers at once)?

This is not under your control. It will use whatever is registered for that
MIME type on the user's computer/browser.

From	Me
To	Henri
Subject	Re: Firefox MP3 troubles 2
Date	21 April 2007 11:38

Henri,

> Firefox: the control is invisible, this is ignored:
> <param name="ShowAudioControls" value="true">

Support for these parameters is controlled by the plugin itself. Perhaps
Firefox is using a different plugin to Opera, or perhaps Firefox is using
the embed not the object (assuming you have used both like most developers
do).

> Older Netscape (Mozilla): nothing happens, object-tag is ignored?

Plugin probably not installed for that browser install - check for the
relevant dll in its plugin folder.

> Both Opera & MSIE: youi need to click the pause button twice to halt the
> playback.

That would be this:
http://www.howtocreate.co.uk/noclicktoactivate.html

From	Henri
To	Me
Subject	[weird] - native size display
Date	27 April 2007 18:40

Hello Mark,

I've been having a very busy week:
[unrelated]

[company] is not like that, if you like it I will add a *strong*
link to your www.howtocreate.co.UK site: we owe you al lot! Just ask
me.... And keep a look out for [advertisments] - something is coming....

Some improvement on the plug-in probblem (or, maybe the opposite): I
managed to force usage of the Micosoft Media Player but I have no idea
on what happens on an Apple Mac:
[URL]
Can you shine some light on this?

Regards,
Henri


Handy .htaccess stuff:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.net/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(weblog\.)?domain.net/.*$ [NC]
RewriteRule \.(gif|GIF|php|swf|wmv|wpl)$ - [F]

[Ed. I warn you not to use this, as it breaks if someone has referrers
disabled in their browser for privacy reasons, or if they find images
through search engines.]

From	Henri
To	Me
Subject	improvement? not!
Date	28 April 2007 07:27

Hi Mark,

I figured, well let's force some type of plug-in for the MP3-playback.
[URLs]
Change: addition of |*type="application/x-mplayer2"*|
This only works in combination with |*hidden="false"*| (cross-browser)
Firefox: works pretty much ok now using Microsoft MediaPlayer
MSIE: suddenly uses QuickTime - the bug I noted before in Firefox now appears 
here!!!!
Opera: satisfactory using Microsoft MediaPlayer

Backdraws: personalisation using skins makes the width/height ratio 
unpredictable. I have no idea wheather Microsoft MediaPlayer is available for 
Apple-Mac and Linux. Possibly not.

"When the mountain does not come to Mohammad, Mohammad must go to the mountain."

I surrender! Though I despise using plug-ins in general and macromedia Flash in 
particular. Reason: web sites like www.spatialeffects.nl (check out the list of 
'helpers, friends & experts' :-) ).
On [URL] you can spot I deviated from my 
habit of not using Flash. The difference is that this last page works fine when 
the support for Flash is absent. The Litmus-test: 
[URL] - Webpages built entirely in Flash are not 
indexed.

Just like the slideshow at the top of the 'design' page I want to use a Flash 
plug-in for the MP3-playback.

Do you know where to get a fancy one?

Regards,
Henri

From	Henri
To	Me
Subject	improvement? a little...
Date	28 April 2007 08:26

Hi Mark,

> MSIE: suddenly uses QuickTime - the bug I noted before in Firefox now appears 
> here!!!!

I managed to switch from QuickTime to Microsoft MediaPlayer - the weird bug 
(restart of playback after ½ second) is gone now. Mini HowTo:

   1. close all browser windows
   2. disable MP3 support in the options of QuickTime
   3. close QuickTime
   4. enable MP3 support in the options of MediaPlayer
   5. enjoy the show....

> Opera: satisfactory using Microsoft MediaPlayer

Well, I was premature:
[more images for HTML emails?]

Opera displays some kind of video preview area, then removes it - but forgets to 
'reclaim' the space.

Display in InternetExplorer:
[more images for HTML emails?]
width=300 height=45 (auto-sized)
In Firefox & Opera the autosizing fails, thus the following parameters are needed:
|* width="300" width="45"*|
Fixfox works fine after this addition but Opera still forgets to reclaim the 
video preview area (or whatever it's called), it sezes al right though (the 
audio volume control is now visible).

Note: |*type="application/x-mplayer2"*| & |*volume="100"*| do not combine well!

Conclusion: I'm closing in on predictable plug-in behaviour!

Regards,
Henri

From	Henri
To	Me
Subject	Better Things?
Date	28 April 2007 11:14

I had another go at the avoidance of the 'click here to activate this control' 
thing:

[URL]
Massive Attack & the Mad Professor: "Better Things" ("No Protection")

MSIE: okay
Firefox: volume control invisible, otherwise fine but  |*player.hidden='false'*| 
is ignored (does not show up in the DOM)! Luckily 
|*player.setAttribute('hidden','false');*| works (?)
Opera: plain crappy

Now watch this page:
[URL]
I magaged to turn up the volume! For reasons unknown to me a negative value does 
the trick....

Firefox & MSIE: satisfactory -- exept for the horizontal scrollbar
Opera: plain crappy

Any suggestions?

Henri

From	Henri
To	Me
Subject	Re: improvement? not!
Date	2 May 2007 09:42

Hi Mark,

[URL about Webkit on Windows] :

> If Apple's (horrible) version of Quicktime for Windows is any indication of 
> how well they'll port Safari, they can keep it. Apple's software tends to 
> integrate well with their own operating system, but they're not that great at 
> Windows software.

What is your opinion on www.webkit.org ? Is this an option for testing Safari on 
a machine running Microsoft Windows? I could not find a suitable build for XP. 
[URL] links to www.webkit.org ....

Btw, why do you think Opera is significant?

Can you visit [URL] just once USING *Opera*? This 
is probably the least popular weblog in the world (13 visitors after I activated 
the statistics) so I can check whether this browser is counted correctly and not 
added to the heap "MSIE 6.0" or so.

Regards,
Henri aka 'Henri' (to the outside world)

Actual data derrived from visitors-statictics ([Another unreliable stats
service]):
[more images for HTML emails?]

From	Me
To	Henri
Subject	Re: improvement? not!
Date	2 May 2007 10:08

Henri,

> What is your opinion on www.webkit.org ? Is this an option for testing
> Safari on a machine running Microsoft Windows?

webkit.org produces the browser engine used by Safari, which is its primary
use (the secondary being its use on mobiles, such as some of the new Series
60 phones), so my opinion of it is basically my opinion of Safari:
http://www.howtocreate.co.uk/why.html#br-konq
They also have efforts to port it to Windows, which I have talked about
here:
http://www.howtocreate.co.uk/swift.html

> I can check whether this browser is counted correctly and not added to the
> heap "MSIE 6.0" or so.

http://www.howtocreate.co.uk/nostats.html

Whether a browser is important or not is very much up to your audience, but
there is no reliable way to say who that is (and I will never trust
statistics on browser usage). However, Opera is the browser with the highest
level of DOM and CSS support, and is important for devices as well as
desktops. Nintendo's Wii, for example, uses Opera as its browser, and there
is no alternative.

I do not believe in "supporting" any browser. I believe in coding to
standards, and adding workarounds for browsers that are just too popular to
ignore; IE being the main culprit here. Opera is a standards compliant
browser, same as Safari, Konqueror etc. By supporting standards instead of
browsers, you make sure that no matter what your visitors choose to use, it
has the best possible chance of rendering the page correctly, since there
are actually rules written down for how that should be.

If you test in Opera and Firefox/Mozilla, then that means you have the
responses of two standards based browsers to compare. If the page works in
both of them, then chances are it will work in all other standards based
browsers as well. That makes your pages more likely to work in future
browsers too.

As for why I ask you to test in it when you are asking for my help, I have
given details here:
http://www.howtocreate.co.uk/emails/JohnTHansen.html#specialone

From	Henri
To	Me
Subject	additional comment
Date	2 May 2007 19:31

I have not finished reading your previous e-mail message but I would like to add 
some comment on www.howtocreate.co.uk/nostats.html :
I totally agree, what you decribe is a good example of a *self-fulfilling 
prophecy*. I had no plans whatsoever to fall in this trap.

> you will not be able to identify browsers that do not support JavaScript, or 
> have it disabled

It's even so that I 'suspect' part of the visitors of using an anonymising proxy 
server that ignores JavaScript. Some of those proxies generate a different IP 
address for each subsequent page visit 'originating' from a different country 
(according to the IP address)!

> This only gets worse if a page uses scripts or conditional comments to serve 
> extra content to specific browsers.

This is how many programmers, scripters, and webmasters make themselves 
indispensable (they think). A few years ago I was part of a team dedicated to 
automated reverse engineering. We made those arrogant guys dispensable!

"Fanboys": that's funny!!!! A variant: many (free) counters with statistics have 
no means of excluding certain IP addresses, including the IP address of the 
webmaster himself. So, when a web site gets let's say 500 hits a day and the 
webmaster checks the result of his work let's say 50 times a day he is 
responsible for 10% of the visits!

Conclusion:
I can think of only one good reason to use statistics - *use it as 'proof' when 
reporting to the management* to make your point.... In my case I used it as an 
argument for putting extra time in the design to make it look well in Firefox, 
not just MSIE. Soon I will do this again to cope with the migration of users to 
bigger screens (rough fugures):
3 years ago: 50% used 1024x768 and 45% used 800x600
currently: 45% uses 1024x768 and 50% uses 1600x1200

[Ed. so long as you realise that you are telling lies to your management,
and use them only to initiate good causes, such as supporting standards,
and do not start believing your own numbers]

Complying to standards is one thing - design is another:
Small screen: [more HTML email stuff?]
	Big screen: [more HTML email stuff?]
This is just a stupid text to demonstrate the difference in rendering around an 
image using different screens.
This is just a stupid text to demonstrate the difference in rendering around an 
image using different screens.
[yep, I do not like HTML email]

This is in my opinion a good reason to re-design some or all pages on my sites.

Regards,
Henri

From	Henri
To	Me
Subject	justified text & hyphens
Date	3 May 2007 03:28

Hello Mark,

Please take a look at this page:
[URL]

MSIE looks okay to me

Firefox - known issue: no &shy; support

Opera - did I do something wrong? Most of the hyphens do not show up at
the end of a line when a word is hyphenated.

Any ideas?
Henri

From	Me
To	Henri
Subject	Re: justified text & hyphens
Date	3 May 2007 10:19

Henri,

> did I do something wrong? Most of the hyphens do not show up at
> the end of a line when a word is hyphenated.

They are there, but you are cutting them off. Basically, the &shy; algorithm
is very badly defined, and that is almost certainly why Mozilla chose not to
implement them. The various standards cannot agree on how they should be
implemented, and browsers have to rely on this from HTML 4.01:

"The soft hyphen tells the user agent where a line break can occur. ... If a
line is broken at a soft hyphen, a hyphen character must be displayed at the
end of the first line. If a line is not broken at a soft hyphen, the user
agent must not display a hyphen character."

This does not say if the visible hyphen should be treated as part of the
text itself, and therefore also does _not_ say that a browser should take
its size into account when creating a linebreak. What it does say is that
the browser should work out where to break the line based on where the
character appears within the text - implying that its expanded size should
_not_ be taken into account. Then after creating the linebreak, it has to
add the hyphen.

Of course, that hyphen may now be too big to fit on the end of the line, so
if it is, it extends beyond the bounds of the element, and overflows.

On your page, you apply overflow:hidden to #main - line 282:
  overflow: hidden;     /* fix for long non-text content breaking IE sidebar
float */

This cuts off any hyphens that are overflowing. IE does not implement it in
this way, and takes the expanded width of the hyphen into account when
creating a linebreak. It's what you want, but it does not seem to be correct
according to what I can read into the spec.

For what it's worth, iCab also does not support &shy; while Safari and
Konqueror do not support it correctly inside a word (they just break the
word without a hyphen), and on its own, they always display it as a hyphen.
IE on Mac (dead) displays it as an unknown character. What a mess.

Anyway, to your problem. I think Opera's behaviour, although not
tremendously useful, is closest to the spec. So assuming you want to make it
work in Opera, you should make sure that you do not cut it off. This means
that either you need to remove the overflow:hidden, or make sure that when
it overflows, it does not go far enough out that it gets clipped by the
hidden overflow. The easiest way would be to make sure it has a margin to
extend into, that is inside the #main container. Personally, I would change
this:

.post {
    margin:8px 0 24px 0;
}

to this:

.post {
    margin:8px 0.5em 24px 0;
}

From	Henri
To	Me
Subject	Re: justified text & hyphens
Date	3 May 2007 19:09

Hi Mark,

Thank you for your explanation and solution. It works much better now
both in Internet Explorer and in Opera.
Only this pieces render wrong in Opera:
[sample text]
Internet Explorer has somewhat similar behaviour but the mistakes appear
less dramatic to me. it seems that the justify attribute is indeed not
very well implemented.

Though it might not be defined well in the HTML/CSS standards, in
Holland we have so called NEN-norms that cope with things like this and
these are at the same level as common law, at least for civil servants.

Regards,
Henri

From	Henri
To	Me
Subject	disabling right-click
Date	4 May 2007 09:13

Hello Mark,

On [URL] I have the click on the right mouse 
button disabled.
Currently this only works for Internet Explorer.
Firefox and Opera still operate normally.
How can I disable the right-click function for this two browsers as well?

Thanks in advance for your answer,
'Henri' (ak to you as Henri)

code for the HTML-document:
|<head>
<script type="text/javascript" src="library.JS"></script>
</head>
<body onLoad="blockclick();">
</body>|

library.JS code:

[Ed. code removed to discourage its use]

From	Me
To	Henri
Subject	Re: disabling right-click
Date	6 May 2007 22:45

Henri,

> On I have the click on the right mouse
> button disabled.

Sorry, but I hate this whole approach to browsing. Browsing is for users -
your customers. I know very well why you want to do this, but I do not
endorse it, or want to help you do it. Think of your customers, and please
stop breaking their interface.

> Firefox and Opera still operate normally.
> How can I disable the right-click function for this two browsers as well?

In Opera, you cannot, unless the user has chosen to allow you to break their
interface, since Opera prides itself on being an accessible browser, and the
right click menu is very important for accessibility and usability. In
Firefox, you can, but as I said, I do not want to help you work out how to
do it. I want to encourage you not to do it.

From	Henri
To	Me
Subject	Re: disabling right-click
Date	7 May 2007 09:13

Hello Mark,

In priciple I agree with you and I respect your point of view. In my
defence: our stuff was copies 32.000 times till this day without even 1
'thank you'. At least the imagery part of my sites is protected against
piracy in a basic way. (Yes I know about Alt+PrintScrn.). [Ed. and wget
or curl, or looking in the browser's cache...] The main
reason is that most [employees] want their photo's completely gone from the
Internet in the event of quitting the [...] business. The stupid thing
is that I have hundreds of on-line photo's available for 3rd parties,
totally free. Anyway, let's consider this case closed: we are both
entiteled to have different opinions.

In my opinion it is close to using plain mailto: URLs in stead of hiding
them with JavaScript. All functions of a web site should work without
JavaScript (and without cookies for that matter) but helas, the
spam-maffia forces web masters to take drastic actions. This is, of
course, also just my opinion.

I have another question, orginal code: [URL]. This is an excellent article
about incorporation of multiple style sheets (CSS). I tried some trick from
it on [URL] (see top right side) but it
does not work in any browser I tried (FF,MSIE,Opera).
I suspect I made just 1 little mistake but cannot detect it. Any idea?

Regards,
Henri

From	Me
To	Henri
Subject	Re: disabling right-click
Date	7 May 2007 17:28

Henri,

> [URL]
> I suspect I made just 1 little mistake but cannot detect it. Any idea?

Open Opera. Use Tools - Error console. Press the "Clear" button if there are
any errors showing already. Now load that page in it. Take a look at the
first JavaScript error that it displays. It will tell you the mistake. (It
results from a ; that should not be there.)

(Some of the "Expected ruleset" CSS errors that Opera reports, relate to the
fact that it does not support @font-face rules as they were removed from CSS
2.1, not something you have done wrong. So you can ignore those errors.)

Note that I do not offer help with implementing other people's scripts like
this - you should ask the author of the script for help. However, I will
point out that the script you are using has some bugs with the way it checks
names of cookies and stylesheets, meaning that it can pick up the wrong
ones. It also fails with some browsers that it should be able to work with.
My own stylesheet switching script does not have these problems:
http://www.howtocreate.co.uk/jslibs/script-swapstyle

From	Henri
To	Me
Subject	Re: disabling right-click
Date	8 May 2007 11:05

Thanks,

I should have detected that ';' myself.

www.howtocreate.co.uk/jslibs/swapstyle.js
Line 62: 'stylsheets' sould be 'stylesheets' ;-)
I will implement it anyway, of course.
Like everybody else I dislike failing web pages, whatever the reason may
be.

About the @font thingies: this is 'work in progress' as well. We
corresponded on this subject before so I want to read what you published so
far thus avoiding redundant questions.

Gr Henri

From	Henri
To	Me
Subject	LVP
Date	10 May 2007 16:15

[URLs]

Hello Mark,

Just out of curiosity: I noticed that the above style sheet contains
many values surrounded by quotes.
In Firefox the result seems to be that the Verdana (or Arial) font is
NOT used: in stead I see a generic font with serifs.

Any ideas?

Regards,
Henri

From	Me
To	Henri
Subject	Re: LVP
Date	10 May 2007 18:32

Henri,

> [URL]

Eek. Just about the whole thing is invalid.

1.
<!-- CSS Stylesheet -->
HTML comments are not allowed to be used this way inside external CSS
stylesheets. This will be treated as invalid selectors and rules, and will
be dropped.

2.
margin-top:"0%";
Margin declarations expect length values. These cannot be quoted, since
quotes mean string values. These styles will all be dropped. Same applies to
border, padding, font-size, color, background-color, text-decoration, and
text-align. _ALL_ of those styles have invalid string values, and are being
ignored in standards compliant browsers (not IE).

3.
font-family:"Verdana, Arial";
This asks for a single font, whose name is "Verdana, Arial". There is no
such font, so your browser reverts to its default font, which happens to be
a sans-serif font. While individual font names can be quoted (except for
generic families like serif, sans-serif, etc.), and in fact must be quoted
if they contain spaces, they should be quoted separately. If a font name
contains no spaces, there is no need for quotes at all:
font-family: Verdana, "Arial New", Arial, sans-serif;

Basically, the three comments at the top should be /* CSS comments */ and
all quotes should be removed. It looks like a completely different page.
Feel free to contact the site authors (assuming it is not you), and ask them
to fix it. The latest version of the tool they used does not seem to make
these mistakes.

From	Henri
To	Me
Subject	Re: LVP
Date	10 May 2007 20:18

No no no: it's not mine at all.
I have no connection whatsoever to that site.
[Unrelated content]

I will forward your message to the sysop though.

Regards,
Henri

From	Henri
To	Me
Subject	Re: LVP
Date	10 May 2007 21:09

It's not the only mistake!
See the strikethrough-parts on 
[URL]
This is a copy-of-a-copy.
In the next 'edition' I will make the 'strike'-tags disappear.

Regards,
Henri

From	Henri
To	Me
Subject	weird bug?
Date	24 May 2007 12:09

Hello Mark,

In MSIE & Opera this looks as expected:
[URL]
In Firefox the content of the first <textarea> thingie renders a bit too
much to the left, outside the box.
Did I do something weird or is this another bug in Firefox?
How can I fix this?

Regards,
'Henri' (real name: Henri)

From	Me
To	Henri
Subject	Re: weird bug?
Date	24 May 2007 13:24

Henri,

> Did I do something weird or is this another bug in Firefox?

You have a lot of invalid markup (suggest you try running it through the W3C
validator <http://validator.w3.org/>), however the problem is actually a bug
in Firefox, requiring a fairly unique combination to produce it.

1. The textarea must be in a table cell, _not_ the first cell in a row.

2. The textarea must be in a paragraph inside the cell.

3. The paragraph must have the text-align style set to left.

4. The stylesheet must have a rule targetting the paragraph's ::first-line
pseudo-element - the rule can even be empty, it makes no difference.

5. The previous cell in the row must have less content than at least one
other cell in that column.

Your page manages to have all of those conditions, so the text spills out of
the left side of the textarea until it butts up against the text in the cell
before it. Change any one of them, and the bug will be fixed. It is also
fixed in Firefox 3 alpha, but not yet in current releases.

From	Henri
To	Me
Subject	CSS2 Media Types
Date	20 May 2007 14:15

Hello Mark,

When I look at [URL] and 
www.w3.org/TR/CSS21/media.html I notice there are TWO different way to address 
audio output using CSS: "aural" & "speech". Also, "audio" is mentioned without 
further explanation. To make things worse, on www.w3.org/TR/CSS21/aural.html is 
stated:

    * CSS 2.1 reserves the '_*speech*_' media type but _does not define_ which
      properties do or do not apply to it.
    * The type '_*aural*_' is now _deprecated_.

Do you care to comment on this? I think this will be of interest to your 
website. Also, is there an easy way to test-drive a web site for audio-impared 
using this technique?

Regards,
Henri

From	Me
To	Henri
Subject	Re: CSS2 Media Types
Date	22 May 2007 10:08

Henri,

> Do you care to comment on this?

Aural is from CSS 2, speech is from CSS 3. Same basic thing, different name.

Emacspeak <http://emacspeak.sourceforge.net/> is the only browser I know of
supporting aural media (though I may have missed some other even more
obscure browser than Emacspeak). Opera on Windows is the only browser I know
of supporting speech media (which it does fairly well, but note that the CSS
3 speech module is still in draft, so Opera prefixes xv- to some of the CSS
property names that are new in CSS 3 speech).

Opera (and special versions of NetFront) also supports VoiceXML, so you can
write a program that interacts with the user and a Web page - allowing the
user to speak commands, etc. Tutorials here:
http://dev.opera.com/articles/voice/

> I think this will be of interest to your website.

I already mention that Opera supports speech media, and provide some
stylesheets for it here:
http://www.howtocreate.co.uk/accessibility.html

> Also, is there an easy way to test-drive a web site for audio-impared
using this technique?

Use Opera on Windows 2000 or XP (not tested Vista with voice yet). Select
some text on a Web page, right click, select 'speak'. The first time you do
this, it will download a voice module. To test the page, select-all then
right click - speak.

From	Henri
To	Me
Subject	purple haze
Date	8 August 2007 19:03

Hi Mark,

Actually, it's a blue haze:
[MySpace URL]
(sorry if it loads very slow: not in my control).

Does this have to do with:
|<style type="text/css">
form>img#someLogo
{
   
background-image:url(some.png
);
    background-repeat: no-repeat;
}
#someLogo
{
    vertical-align:bottom;
    width:120px;
    height:30px;
 filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='some.png',
   sizingMethod='image');
}
</style>|
Is the ">" after the word "form" a typo?

Btw, many thanks for your explanation on the audio-plugin for Opera.

regards,
Henri

From	Henri
To	Me
Subject	Some name
Date	15 August 2007 15:30

Hi Mark,

In both Firefox and MSIE this page looks fine:
[URL]
However, in Opera there is no white space between the images.
Do you have a suggestion?

Regards,
Henri

From	Henri
To	Me
Subject	Panic key
Date	15 August 2007 15:54

Hello Mark,

In [URL] I added the following ages ago:
|<a ws="" href="[Other URL]" accesskey="S" target="_parent" 
title="Secret Boss key"></a>|
Any idea why this does no longer work in Firefox 2 and Internet Explorer 7?
Is there a way to make Opera behave the same as the (old) MSIE or Firefox?

Thanks in advance for answering my question,
Henri

From	Me
To	Henri
Subject	Re: purple haze
Date	22 August 2007 12:13

Henri,

> Actually, it's a blue haze:

I see no problems there, only a typical horrible stylesheet from MySpace.
MySpace problems (without solutions) are discussed here:
http://www.howtocreate.co.uk/emails/DavidKnopfler.html

> Does this have to do with:
> form>img#someLogo
> Is the ">" after the word "form" a typo?

No, it is a CSS 2 descendent selector that IE 6- and IE 7 in quirks mode do
not support. That page does not use a doctype, so it is rendered in quirks
mode. All IE versions will ignore that style rule as a result (except IE 5.0
which will incorrectly apply it everywhere due to an unrelated bug).

> [URL]
> However, in Opera there is no white space between the images.

Works for me in Opera 9.2 - I assume you fixed it.

> |<a ws="" href="[Other URL]" accesskey="S" target="_parent"
> title="Secret Boss key"></a>|
> Any idea why this does no longer work in Firefox 2 and Internet Explorer 7?

Because the link has no contents? I do not see this code in the source for
the page. However, I tested it, and it seems to work in IE - Alt+S, Enter.
In Firefox, it breaks because you have chosen a key that conflicts with the
browser's menu shortcuts. Perhaps the same problem hits you in IE because
your localised version uses different letters for the shortcuts in the
menus.

> Is there a way to make Opera behave the same as the (old) MSIE or Firefox?

In what way? Opera understands access keys, but access keys suck in general,
since they conflict with the browser's own shortcuts - which is why I refuse
to use them on my own site. Using F as an access key in IE and Firefox
breaks the functionality of the Alt+F file menu, for example. Opera avoids
this by using a key combination to enter and leave access key mode.
Shift+Esc, F.

Note that Opera already has its own "boss key" shortcut -> Ctrl+H that
minimises it to the system tray ;)

From	Henri
To	Me
Subject	tooltips
Date	14 September 2007 13:58
Attachments	sample script for DHTML tooltip

Hello Mark,

On [some other site] I noticed a very nice tooltip-'popup' that appears when
you hover over the image.

I tried to mimic this on [url] but though it displays the tooltip it does
not move when the mouse moves. Does this have to do with some z-index thing?

Note: the attached .JS is not an exact copy of the code used in my bLog and
the .CSS is an unmodified copy of the original.

Hopefully you can help me out with this....

"Henri"

From	Me
To	Henri
Subject	Re: tooltips
Date	15 September 2007 09:47

Henri,

> On [some other site] I noticed a very nice
> tooltip-'popup' that appears when you hover over the image.

My contact page requests that you contact the author of a third party script
if you are having trouble with it. Since this is someone else's script, you
really should contact them if you are having trouble with it, not me.

> it displays the tooltip it does not move when the mouse moves

It will really help in future if you can tell me the browsers that are
affected by this sort of thing. In this case, it failed in Firefox, but
worked in Opera and IE.

The problem is caused because your doctype triggers strict rendering mode,
but the script is broken, and expects quirks mode, where unitless lengths
are allowed in CSS.

These lines:
    ele.style.top = gMouseY;
    ele.style.left = gMouseX;
should be:
    ele.style.top = gMouseY + 'px';
    ele.style.left = gMouseX + 'px';

Even with this fix, the position will be wrong, because it is inside a
relatively positioned DIV (content-wrapper), and the position will be taken
relative to that. This does not affect Opera and IE because the script
calculates the positioning relative to the container in those browsers. If
you put the tooltip DIVs outside the content-wrapper, it will behave
correctly in all of them.

As a side note, you have used this:
<p><img .../></a><div class="tooltip" id="tooltip1">text</div></p>
DIV is a block level element. P can only contain elements whose default
display is inline (it's ok to change their display to block with CSS, it's
only their default that's important). The DIV is not allowed inside the P.
Put it after it instead - the effect will be the same.

From	Henri
To	Me
Subject	Re: tooltips
Date	20 September 2007 10:49

Thanks for making an exeption when answering my question. I'll try not to
make this mistake again. About the wrapper: I have no real control over it,
it is generated by the [brand] server. Though I must say this system is
the best I found so far of the available bLog servers I know about when it
comes down to adding JavaScript and/or CSS fun to it, even this system fails
every now and then, most likely due to very bad bottom-up programming (see
attached screendump where suddenly German text appeared).

The whole thing started with [URL] - an experiment with transparency. I
abandonned this 'project' when I noticed the big rendering differences
between Firefox|IE|Opera. IE & Opera show accepable results after a lot of
experiments but Firefox continues to fail.

Regards,
'Henri'

From	Henri
To	Me
Subject	tables: vertical alignment
Date	8 November 2007 13:02

Hello Mark,

Can you shine some light on the table at 
[URL]
Code:

    |<table border="0" cellpadding="0" cellspacing="0">
    <tr>
    |

        |<td rowspan="3" align="right" valign="middle">
        <a href="[URL]"
        style="vertical-align:middle; line-height:1em; padding-bottom:1pt;"
        target="_blank">homoniemen</a>
        </td>|
        |<td rowspan="3" align="center" valign="middle"
          style="line-height:5em;">
        <font face="Times New Roman" style="font-size:5em;
        font-stretch:ultra-condensed; font-weight:lighter;">{</font>
        </td>|
        |<td align="left" valign="bottom" style="line-height:1em;
        padding-bottom:1pt;">
        <a href="[URL]"
        target="_blank">homofonen</a>
        </td>|
        ||

    |</tr>
    <tr>
    |

        |<td style="font-size:6pt; line-height:6pt;">&nbsp;</td>|
        ||

    |</tr>
    <tr>
    |

        |<td align="left" valign="top" style="line-height:1em;
          padding-bottom:1pt;">
        <a href="http://nl.wikipedia.org/wiki/homograaf"
        target="_blank">homografen</a>
        </td>|
        ||

    |</tr>
    </table>|


Microsoft Internet Explorer: as intended
Firefox: first column is *not* exactly centered
Opera: *complete mess*: all aligned to the top of the cells

At first I started simple with the accolade ("{" symbol) with
height of 3em but 
this turned out bad. Also, the CSS style attributes font-stretch &
font-weight 
seem to be ignored in all the browsers mentioned above.

Thanks in advance,
Henri

From	Me
To	Henri
Subject	Re: tables: vertical alignment
Date	9 November 2007 10:04

Henri,

> Microsoft Internet Explorer: as intended
> Firefox: first column is *not* exactly centered

The font specifies that the { character does not sit on either the baseline
or the top of the line-height. There is nothing you can do about that
(except perhaps shrink the line height and allow it to overflow).

> Opera: *complete mess*: all aligned to the top of the cells

This has nothing to do with alignment within cells at all. Put a border on
the table and you will see that it is the cells themselves that have a size
that you did not expect. You are relying on browsers to all respond the same
way when you do not specify the heights of the cells. This will not happen.
IE and Firefox choose to space it out amongst the cells in proportion to the
height of their contents. Opera chooses to give the line height to the first
two, then the remainder to the final cell.

Here's the thing though; neither approach is wrong. The automatic table
layout is one of the most under-specified parts of CSS (and is not defined
at all by HTML). Browsers have absolutely nothing to base their algorithm
on, and are all expected to make up their own ways. This sucks for you as an
author, but even ten years after tables were introduced, there is still no
proper description for how they should behave. To put it simply, you should
never rely on tables if you want something to look perfect.

Even if you specify height on the cells (and make sure you also specify a
fixed height on the table if you want to use percentage heights on the
cells) it will not work. There is nothing to say how that should work when
cells in the same row have rowspan, so the height will not work the way you
expect. Basically, this makes it almost impossible to achieve the effect you
want with your current table.

So it needs to be done without rowspan. Without using CSS positioning, that
leaves you with only one alternative; nested tables (extremely ugly, but
whatever). The idea is to have only one row in the main table, then for the
third cell which you want to span 3 rows, use a nested table (with height
set to 100% and make sure the outer table also has a fixed height). The cell
heights in the nested table can be set with percentages or ems or whatever
to get the height you want:

<table style="height: 10em;" border="1">
  <tr>
    <td valign="middle">first</td>
    <td valign="middle">{</td>
    <td>
      <table style="height: 100%;" border="1">
        <tr>
          <td height="40%">one</td>
        </tr>
        <tr>
          <td style="font-size:0.6em;">&nbsp;</td>
        </tr>
        <tr>
          <td height="40%">two</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

It's a mess, but that's where tables get you. At least it works.


Tarquin

From	Henri
To	Me
Subject	Re: tables: vertical alignment
Date	10 November 2007 11:49

Hi Mark,

Your solution got closer to what I want, but failed too. Your comment is
very explanatory, though.
Here is some code that looks better, inspired on your suggestions:
|<table height="120" border="0" cellpadding="0" cellspacing="0" 
style="border:1px dotted White;">
<tr>
|

    |<td Valign="middle"><a href=""
    target="_blank">homoniemen</a></td>|
    |<td Valign="middle">|

        |<table height="100%" border="0" cellpadding="0" cellspacing="0"
        style="border:1px dotted White;">|
        |<tr>|

            |<td><font face="Times New Roman" style="font-size:5em;">{
            </font></td>|

        |</tr>|
        |</table>|

    |</td>|
    |<td>|

        |<table height="100%" border="0" cellpadding="0" cellspacing="0"
        style="border:1px dotted White;">|
        |<tr>|

            |<td height="40%" Valign="middle"><a
            href=""
            target="_blank">homofonen</a></td>|

        |</tr>|
        |<tr>|

            |<td style="font-size:6pt;">&nbsp;</td>|

        |</tr>|
        |<tr>|

            |<td height="40%" Valign="middle"><a
            href=""
            target="_blank">homografen</a></td>|

        |</tr>|
        |</table>|

    |</td>|
    ||

|</tr>
</table>|

Opera & Firefox: acceptable
MSIE: the accolade is cropped at the top and bottom

I thought about replacing the accolade sign with four transparent GIFs (top, 
bottom, middle, and the in-between part) but the problem is that this sign is 
very curvy - using images would destroy that.

[brand] uses XHTML, may there be a solution there?

Regards,
Henri

From	Me
To	Henri
Subject	Re: tables: vertical alignment
Date	18 November 2007 08:27

Henri,

> MSIE: the accolade is cropped at the top and bottom

Not surprising. IE does not like displaying things outside their line-boxes.
I guess you can't use the line-height workaround then (or perhaps you can if
you include it in normal CSS, then redclare it not to use that in
conditional comments, so only IE uses it).

> [brand] uses XHTML, may there be a solution there?

It uses HTML. It may look like XHTML, but since it works in IE, there is no
way it is being served as XHTML because IE does not understand XHTML. They
are serving it as HTML, so browsers are using their HTML parsers, even
though it looks like XHTML. More info here:
http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML&withHeader=1

From	Henri
To	Me
Subject	weird bug
Date	24 March 2008 16:28

Hello Tarquin,

Can you explain why some visitors of [URL] see the menu on the left only and
not the rest of the page content?
I recently uploaded this new version of the site.

Thanks in advance for helping me out,
Henri

From	Me
To	Henri
Subject	Re: weird bug
Date	29 March 2008 08:42

Henri,

> Can you explain why some visitors
> see the menu on the left only and not the rest of the page content?

I assume (though you have not said) that they are using IE 6 on Windows.
IE 6 has a bug with positioning inside tables. Basically, positioned
elements (div.scrolling) should take percentage widths relative to their
container, which in this case is the viewport (inside of the browser
window). IE 6 takes them relative to the parent table cell if they are
inside a table.

Combine that with a separate bug; if you make a table 100% of the
available width, but then you only give non-positioned contents to the
contents of the cells in one column, then the other columns will have no
width. Even if you restrict the width of the column with contents so
that the remaining space should be devoted to the other columns, it will
not be.

87% of 0 is 0, so the overflowing div (and the header div above it) are
both 0 pixels wide, causing the scrolling overflow to make it disappear:
http://www.howtocreate.co.uk/ieBugs/ie6gone.html

The underlying problem is that you are trying to combine table layout
and positioning, which is a recipe for disaster. The overlying problem
is that some of your visitors are using IE 6. You can choose what to do:
waste time finding a workaround to the IE 6 bugs, or just ignore IE 6.
IE 7 has been around for long enough, and anyone who still uses IE 6 is
just causing problems for Web developers. They should be encouraged to
use a browser that does not suck.

From	Henri
To	Me
Subject	Re: weird bug
Date	29 March 2008 14:59

Hello Mark,

Thank you very much for the explanation! I will discuss it with te owner of
the web site.
As it happens, ALL my fallback machines failed to boot, due to the situation
that they have not been used for over at least a year. I am assembling a new
test machine from parts of the old ones so I am able to run W98 & IE6 (still
in use by many visitors). Don't nag to me about unreliable stats. I know!
It's only an indication.

Basically we can do two things:
(1) put a message in the menu on the Home page with a link to the download
page for IE7, or even better: FIREFOX! [Ed. or any of the other standards
compliant browsers]
(just my opinion)

(2) put a link to the old version of the site: helas, there is no working
web form.... of course there's always plain e-mail

If I had to decide on my own I would go for option (1). Btw, of course I
know Opera and I know that you are a great fan of it. I have to tell you
this: it failed running the automatic update just like at the time the
previous update went online. For me a reason not to mention this product
with option (1) for now. Any ideas?

[offtopic]

Greets,
Henri

From	Me
To	Henri
Subject	Re: weird bug
Date	4 April 2008 12:25

Henri,

> it failed running the automatic update just like at the time the previous
> update went online.

It's not an automatic update, just an update notification. When you download
the update, you are just downloading the installer exactly the same as if
you went to http://www.opera.com/download/ and downloaded it. It runs just
like a regular installer would. You have to close the program before trying
to update it (once the installer has started up), otherwise the OS refuses
to allow the installer to overwrite the files with their new version
(Firefox gets around this by forcing you to close it in order to run the
update). That is the usual cause of update problems, so I assume that is
what is happening for you.

Tarquin.

From	Henri
To	Me
Subject	Re: weird bug
Date	4 April 2008 15:10

[offtopic]

Thanks for your reply! Next occasion I will catch a screendump of Opera to embed 
in the posting above.

][enkie

Henri

Navigation

Search

Site navigation

Email conversation