Hoje após duas horas desesperantes, descobri a solução para o problema do scrollTop no IE8, quando é usado dentro de um 'SELECT'.

Basicamente, no IE8 quando se adiciona um elemento 'OPTION', via Javascript a um 'SELECT' que seja do tipo 'multiple' (nota: estou a usar um 'size' de 10), não posiciona a scroll bar, de forma a mostrar o elemento 'OPTION' que foi inserido (já pré-selecionado).

Isto tem o inconveniente de o utilizador não se aperceber que o elemento foi realmente adicionado, se a combo não estiver na posição ideal.

Note-se que estou a inserir os elementos ordenados alfabeticamente, logo a inserção poderá ocorrer em qualquer posição, dependendo dos elementos já existentes e do elemento inserido.

Para corrigir este problema de usabilidade, defini o seguinte código após ter efectuado a inserção no 'SELECT', dentro de um objecto JS que o contém:

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll; // <=- linha problemática
   }

No entanto, após fazer debug da coisa, a 'linha problemática' aparentemente não executa !!!
Isto é, mesmo que o valor topScroll seja diferente de zero, o campo 'this.select.scrollTop' fica intocado.
É como se a instrução nunca tivesse sido executada !!!

Após perder umas centenas de neurónios, reparei que se eu forçar o valor no debugger a correcção funcionava !

Após mais algumas tentativas, para perceber o problema, cheguei ao momento Eureka!

O IE8, pega de empurrão!

Isto é a solução é insistir à canzana ! :)
Ou seja, repetir a instrução de atribuição !

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll;
      this.select.scrollTop = topScroll; // WE MUST DUPLICATE THIS LINE, due to an IE8 Bug !
   }

Incrível, mas é verdade ! E assim já funciona como esperado e é inócuo para os outros browsers, como seria de esperar.

Java decompiler para o Eclipse

O Eclipse Java Decompiler pode dar jeito, quando ao meio do debug, nos deparamos com uma classe de uma lib (jar) qualquer, da qual não temos a source disponível.
Permite fazer o decompile da class enquanto fazemos debug, para determinar a fonte do problema.

IE8 Document Mode é Sticky !

Mais uma "feature" do IE8!
Se tivermos uma página simples, que abrimos em dois tabs, mas no primeiro tab definimos o URL como 'localhost' e o outro tab com o URL com o nome da máquina propriamente dito ("wheat", no exemplo).

Vamos constatar que o IE8, vai fazer o 'render' da página com margin e offset distintos, para a tag BODY.

A página está definida com o seguinte DOCTYPE:
<!-- DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" -->

Após mais alguns testes, acabei por descobrir que o problema não era do URL, mas sim devido ao facto de ter reutilizado um tab (alterando o seu URL), que conteve anteriormente uma página que forçou o modo de compatibilidade 'IE7' no IE8, com o seguinte meta dado no head !

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

Resumindo e concluindo, o modo de compatibilidade aparentemente é uma propriedade do tab, e que não muda com a alteração do endereço (URL), como devia.

Isto implica que uma página que faça um render correcto, seguindo os standards, pode ficar completamente desfigurada no IE, se o tab tiver sido usado para aceder a outra página previamente, que tenha forçado o modo de compatibilidade do IE.

IE8 não gera evento form submit, em certas condições

Ultimamente, tenho andado a dançar o fandango com o IE8, ao fazer um 'port' de uma aplicação IE6 para IE8.

Infelizmente os bugs são mais que muitos: James Hopkins IE8 Bugs e Gérald Talbot's IE8 Bugs chegam para ter uma ideia dos problemas que se tem pela frente, já para não falar nos modos de (in)compatibilidade, que o bicho trás para o IE7.
Estranho é que alguns anos após o lançamento do IE8, a grande maioria dos problemas continua por resolver.

Mas voltando ao que interessa, o IE8 tem outro BUG ainda não documentado que consiste na falha em gerar um evento de 'submit' num form, em certas condições.

Se tivermos o seguinte código, o IE8 gera o evento 'submit' correctamente:

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input type="submit" value="Submit" />
</form>

Mas se quisermos adicionar um botão adicional, para por exemplo limpar o form (exemplo simplificado), o evento já não é despoletado.
NOTA: A implementação da funcionalidade em 'javascript' não é mostrada.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iClear" type="button" value="limpar" />
 <input id="iSubmit" type="submit" value="Submit" />
</form>

E isto acontece apenas e somente, porque o IE8 não gosta que exista nenhum INPUT do tipo 'button', antes de um INPUT do tipo 'submit'. Isto é. aparentemente o IE8 procura o primeiro botão disponível e activa-o, mas se não fôr um botão do tipo 'submit', o form não é submetido, pois activa o botão errado.

A solução passa por ter o INPUT com o type='submit' aparecer em primeiro lugar no HTML.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iSubmit" type="submit" value="Submit" />
 <input id="iClear" type="button" value="limpar" />
</form>

Se não gostarem do botão à esquerda, até por questões de usabilidade, podem sempre posicionar os botões por css com um float:right, que na pratica vos inverte a ordem relativamente a existente no HTML.

Tabela com múltiplos THEAD versus TBODY (IE Quirk)

Caso se crie uma table com mais do que um thead, algo deste género:

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
 </thead>
 <thead class="days">
  <tr>
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>TESTE</td>
    ...
  </tr>
  ...
 </tbody>
 <tfoot>
  ...
 </tfoot>
</table>

Tudo funciona perfeitamente (em FF3.0.14 ou no IE6.02900), inclusive aplicar CSS específico ao thead cuja class="days".

Mas se tentarem aceder por javascript ao array the objectos tBodies da tabela, as coisas ai mudam de figura.

var myTable = document.getElementById( 'myTable' );

var rows = myTable.tBodies[0].rows;

alert( 'Dados da primeira coluna do body = ' + rows[0].cells[0].innerHTML );

No caso do FF, retorna exactamente o esperado "TESTE", no entanto, no caso do IE vai retornar "4" ou seja, o conteúdo da primeira coluna do segundo thead.

Isto acontece porque o IE, erradamente associa o segundo thead (days), como se fosse o primeiro tbody, o que claramente não é, inclusivamente é incoerente com a aplicação de estilos, que essa sim funciona correctamente.

A solução para o problema, passa por fugir dele :) isto é, evitar o uso do thead adicional, e aplicar o estilo (class) directamente no tr. Não esquecer de actualizar o CSS de forma a corresponder com a alteração efectuada.

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
  <tr class="days">
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
  ...
</table>

JSPs e comentários

Comentários em JSPs pode não ser tão linear como deveria ser. Vejam o código seguinte:

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
// usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> )
...
%>

À partida parece estar tudo bem, mas não está, porque o pre-processador das JSPs não gosta de tags embebidas (<% ... %>). Como executa/processa antes do compilador Java, e não considera os comentários java (// ou /* ... */) caput!
A solução passa então por comentar usando comentários JSP.

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
<%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%>
...
%>

Mas novamente, esbarramos com a limitação das tags embebidas não serem suportadas pelo Pre-processador JSP. Vamos resolver o problema fechando e abrindo o bloco envolvente de forma a evitar que um bloco fique contido no outro:

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
%> <%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%> <%
...
%>

E agora já funciona e até seria um resultado expectável, não fosse haver aqui algo estranho!
A formatação da data, que está em código JSP, está dentro de um comentário JSP, ora reparem bem:

<%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%>

Ou seja, tags para código JSP (<% ... %>) podem estar contidas em comentários JSP (<%-- ... --%>), mas o inverso não é verdade !
Confuso no mínimo.

CSS - IE6 versus Selector de Atributos

O IE6 não suporta CSS "attribute Selectors", como no exemplo seguinte:

div.Field input[type="text"]
{
   color: blue;
}

Assim, temos que circundar o problema, e a solução mais comum, é adicionar uma class específica para o caso que queremos resolver, e atribuir a class ao elemento respectivo, por exemplo:

div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Passamos então a representar o conteudo da seguinte forma:

<div class="Field">
   <label for="Name">Nome</label>:<input class="Text" type="text" id="Name" value="">
</div>

Mas numa perspectiva futura, podemos querer suportar ambas as regras, com algo como o seguinte:

div.Field input[type="text"],
div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Perfeitamente válido ! Certo ?
Sim, é perfeitamente válido segundo o standard; Mas não, não funciona no IE6!
E de nada vale trocar a ordem das regras, dado que o comportamento é exactamente o mesmo.

O problema é devido ao IE6 rejeitar as regras que não suporta, conjuntamente com qualquer outra que lhe esteja associada.

Para resolver o problema temos que duplicar as formatações, de forma a que a rejeição da regra não suportada, não afecte as restantes, ou seja:

div.Field input[type="text"]
{
   color: blue;
}

div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Saber isto pode poupar-vos muito tempo :)