[WEB4LIB] Inline forms in CSS problem

[Thomas Dowling]

At 10:15 AM 2/26/2002, Jody Cleveland wrote:
>Hi all,
>
>I am in the process of switching over pages I've made to use css rather than
>tables.  I'm getting the hang of it, but have a problem with forms.  I've
>got a menu bar across the top, with a search form to the right of that.  The
>problem is, in Mozilla, the form is on the right hand side, but it is
>shifted down.  Looks like there is a line break above it or something.  In
>IE, well, you have to see it.
>
>Any help you can give a css newbie would be greatly appreciated.
>
>web page:
><http://www.winnefox.org/wals/new/css.html>
>css:
><http://www.winnefox.org/wals/new/test.css>


[First things first: "font-size: 10px;" is bad.  You don't know how small 
10px is on the user's monitor.  Stick with relative sizes.]

[Second things second: Who invented <NOINDEX>...</NOINDEX> 
elements?  Proprietary/made-up stuff like that gets more and more likely to 
screw things up as browsers start expecting you to abide by your doctype 
declaration.]

[Third things third: if you're doing XHTML, you have to pay close attention 
to markup.  All element names lowercase, and all empty elements correctly 
closed.]


Part of the problem is that your search form is marked up as 
<span><form><div>...</div></form></span>.  Several problems there.

First, span is an inline element.  A parsing browser will end it, along 
with its style properties, if a block element starts before the span is closed.

Second, both FORM and DIV are block elements, and without style properties 
saying otherwise, usually start with a new line (especially the DIV: 
browsers may not enforce this for FORMs).


Here's something that helps me.  When I'm having getting CSS-styled 
elements to line up the way I think they should, I put different colored 
1px borders around them.  That gives me visual clues as to exactly which in 
a set of nested elements isn't shaped the way I think.


On something of a tangent, I think it's wrong to look at CSS and tables as 
dichotomous.  People are trying to strip all tables out of their markup, 
experimenting with pretty complex CSS positioning, getting dissatisfied 
with the results, and blaming CSS.  A table is a table*, and IMO it's 
perfectly defensible to describe a tabbed navigation bar as a one-row 
table.  Done right, that can help free you from device- and 
resolution-dependence, instead of locking you into it as your current CSS 
experiment does.

[* On the other hand, an entire page formatted within a big table, using 
columns for indentation, etc, cannot be fairly described as a 
table.  *That's* where CSS can "replace" tables.]

HTH.


Thomas Dowling
OhioLINK - Ohio Library and Information Network
tdowling at ohiolink.edu