Re: Styling form controls

(putting this back on the list, somehow I missed a reply-all). The
older message appears first.

The discussion took a turn when boris pointed out that the content of
the form element is really replaced content. Discussion continues
below.

Garrett Smith wrote:
> It doesn't require significant modifications to CSS spec. Just a new
> rule for CSS3 and a change to the CSS conformance page.

So what you're proposing is that some property basically controls whether the
element is replaced or not?

> What does "padding" mean in this context?
> Padding is padding on a block box or inline box, or whatever the
> display of the element is.

Note that CSS has two types of both of these -- replaced and not.

>> In what way?
> Block element's don't have check indicators.

Replaced blocks are allowed to look like anything they want to on the inside.

> Block element's don't have browser-added fake padding that can't be removed by using
> padding: 0.

Again.

You're not complaining that display:block on an image still paints the
image, right?

> Block element's are just what they are: block elements.

There are two types of block elements.

> Padding is defined for block level elements.

Indeed.

> Once the button element (or checkbox, et c) is rendered as a block level element, then it
> should look like any other block element. If I say padding: 0, there
> should be no padding.

There is no padding.  The content area happens to contain some space.

> Of course, the checkbox element can not have
> child nodes in HTML

It can in XHTML.

> but it should still be modifiable to look like a block element.

Again, should an image be modifiable to render its children instead?  If not,
how is this different?

> Don't confuse the appearance of a form element with the behavior of a
> form element.

I'm not confusing the two.  I question the requirement for form elements to act
like non-replaced elements, however.

> Ever try to float a button right and then position a div inside the
> float? Well, It breaks.

Indeed.  <button> Could perhaps be defined as a non-replaced element, and then
your solution might work, sorta.

> CSS in form elements is a crapshoot.

Indeed, for the reasons described in my previous mail.

> I proposed a CSS property in the bug: -moz-form-css. I think it is a
> good solution because it is fail-safe. E.g. Unless the css dev
> declares -moz-form-css: override and also declares a display value
> other than auto

"auto" is not a valid value of display....  And again, there are valid reasons
to use display:block on a replaced element -- CSS specifies the rendering.  So
overloading display here will not work.

-Boris
On 8/16/05, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
> >>> Of course, the checkbox element can not have
> >>> child nodes in HTML
> >> It can in XHTML.
> >
> > I find that odd, but interesting.
> 
> Well.  Per the DTD, it cannot.  But browsers tend to use non-validating parsers,
> and DOM manipulation can be used to add children to a checkbox even in a browser
> with a validating parser.
> 
> For that matter, DOM manipulation can add children to a checkbox in HTML as well.
> 
> >> Again, should an image be modifiable to render its children instead?  If not,
> >> how is this different?
> >>
> > For what purpose?
> 
> For what purpose would you modify a checkbox to render as something other than a
> checkbox?
> 
> > Form elements have behavior.
> 
> OK, say <input type="image"> instead of <img>.
> 
> > It makes it easy to build form controls with a custom appearance.
> 
> Isn't this what XForms is all about?
> 
> >> "auto" is not a valid value of display....
> >
> > So? -moz-use-text-color is not a valid value for border color.
> 
> Note the "-moz" prefix.
> 
> -Boris
> 


-- 
http://dhtmlkitchen.com/

Received on Tuesday, 16 August 2005 16:44:28 UTC