Heights not correct in IE 6, form.inline not inline in Mozilla

Hi

I am building an admin environment for a CMS system. For the issues
described I have a testcase available at

http://www.ernstdeslebens.ch/csstest/

I am sorry the links are not useable as they lead to password-protected
pages; it is only this page for demonstration. Both HTML (strict) and CSS
validate.

IE issues:
- The two top containers (#corporate and #header) have the same total height
of 70 pixels; one 8px margin-top and 62px height, the other 10px margin-top
and 60px height. The containers below have both the same margin-top and
start with the same h2.ganzoben (with margin-top=0px). Though they do not
align in IE6.
- If you hover the link "e" in the "Optionen" box, the table below it is
moved for some pixels downwards.

Mozilla issues (v. 1.0):
- There are 2 forms in the footer of the table. Both are set to
display:inline. Also are the p elements inside of the forms. Though they are
displayed as block elements in Mozilla.

If somebody has an idea about that, I would be very thankful.

--
Markus

Markus Ernst wrote:

Mozilla issues (v. 1.0):
- There are 2 forms in the footer of the table. Both are set to
display:inline. Also are the p elements inside of the forms. Though they are
displayed as block elements in Mozilla.

What do you expect if you put block boxes into inline boxes? You may
make the p elements display inline as well. But why do you want the
forms to be display inline?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch wrote:

Markus Ernst wrote:
Mozilla issues (v. 1.0):
- There are 2 forms in the footer of the table. Both are set to
display:inline. Also are the p elements inside of the forms. Though
they are displayed as block elements in Mozilla.

What do you expect if you put block boxes into inline boxes? You may
make the p elements display inline as well.

What I wanted to say is: The p elements inside are display:inline, too. I
think the input elements are inline by default; setting them to
display:inline would make the hidden fields visible and though not change
the form display.

--
Markus

Markus Ernst wrote:

Johannes Koch wrote:

Markus Ernst wrote:

Mozilla issues (v. 1.0):
- There are 2 forms in the footer of the table. Both are set to
display:inline. Also are the p elements inside of the forms. Though
they are displayed as block elements in Mozilla.

What do you expect if you put block boxes into inline boxes? You may
make the p elements display inline as well.


What I wanted to say is: The p elements inside are display:inline, too.

Ah, yes. In current Mozilla (1.7.2), the two forms are side by side.
That's what you want?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch wrote:

Markus Ernst wrote:
Johannes Koch wrote:

Markus Ernst wrote:

Mozilla issues (v. 1.0):
- There are 2 forms in the footer of the table. Both are set to
display:inline. Also are the p elements inside of the forms. Though
they are displayed as block elements in Mozilla.

What do you expect if you put block boxes into inline boxes? You may
make the p elements display inline as well.


What I wanted to say is: The p elements inside are display:inline,
too.

Ah, yes. In current Mozilla (1.7.2), the two forms are side by side.
That's what you want?

Thank you Johannes - so that was a bug in Mozilla that has been fixed since
my last update.

Cheers
Markus

Markus Ernst wrote:

I am building an admin environment for a CMS system. For the issues
described I have a testcase available at

http://www.ernstdeslebens.ch/csstest/

I am sorry the links are not useable as they lead to
password-protected pages; it is only this page for demonstration.
Both HTML (strict) and CSS validate.

IE issues:
- The two top containers (#corporate and #header) have the same total
height of 70 pixels; one 8px margin-top and 62px height, the other
10px margin-top and 60px height. The containers below have both the
same margin-top and start with the same h2.ganzoben (with
margin-top=0px). Though they do not align in IE6.
- If you hover the link "e" in the "Optionen" box, the table below it
is moved for some pixels downwards.

Does nobody have an idea about these? I thaught strict mode triggers a fixed
box model in IE 6, but I may be wrong. It is not crucial, but I'd like to
fix that...

Thanks
Markus

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:

I have a testcase available at

http://www.ernstdeslebens.ch/csstest/

[snip]

Does nobody have an idea about these?

You'd stand a better chance if you create a *minimized* test case:
http://www.spartanicus.utvinternet.i...s_help_you.htm

--
Spartanicus

Spartanicus wrote:

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:

I have a testcase available at

http://www.ernstdeslebens.ch/csstest/

You are right, I hoped that it was known issues and somebody would just
recognize them from the descriptions without even looking at the test case.

I took all unnecessary stuff out of the test case now, included the css
definitions in the file, wrote the element names and the problems in the
elements, colored the heading elements yellow, and properly intended
everything.

Thanks for your patience.
Markus

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:

You are right,

What are you replying to? Put your reply beneath the actual bit you are
responding to, remove the rest.

I took all unnecessary stuff out of the test case now, included the css
definitions in the file, wrote the element names and the problems in the
elements, colored the heading elements yellow, and properly intended
everything.

It doesn't come close to a minimized test case, there's far to much
irrelevant stuff in there.

Instead of focussing on what may be one of the numerous IE bugs, I'd
suggest not using tables for layout, this will probably also solve the
issue you are seeing.

--
Spartanicus

Spartanicus wrote:

Instead of focussing on what may be one of the numerous IE bugs, I'd
suggest not using tables for layout, this will probably also solve the
issue you are seeing.

These are divs, the tables contained are used for tabular data. Using tables
for layout would actually fix the issue. Never mind, I can live with those 2
pixels.

--
Markus