evolt.org Interviews Eric Meyer
Saturday January 25th, 2003
evolt.org has an interview with Eric Meyer, who works as a Standards Evangelist for Netscape. Eric has written many books and articles about Web standards, runs his own weblog and regularly contributes to Netscape DevEdge. The interview concentrates on CSS and features a healthy amount of plugs for Eric's latest book, Eric Meyer on CSS.
#18 Re: Re: Re: Re: Re: Really?
Monday January 27th, 2003 5:27 PM
You are replying to this message
> You mean 120px wide, no? If I set the padding to 0, should that mean that the border is right next to the test? With the above style rules, what should happen when the button is clicked
Yes, it would be a total of 120px wide my way. With no padding the border would but against the top and bottom of "Test" but it would still be the declared width (I'd assume that Submit, Reset and Button inputs would have an implicit "text-align: center" by default). According to my attempt to graft current CSS rules onto the button, nothing would happen when it's clicked, except for the button text moving slightly as the button is "pressed," unless something like input[type=submit]:active were used. I'm not saying my way's perfect, just that it's right ;)
> (try it in Mozilla?)
Hey, it does what I think it should! Sign me up! :)
> On the contrary, I think they would be quite common (as evidenced by the fact that there have been bug requests for it and the fact that that's what some tookits mean by a "button border").
I'll have to defer on that. Of course, the people that agree with me aren't filing bug reports 'cause it's already doing what they want.
> In any case, the problem is that both renderings are OK per the CSS2 spec.
Agreed. Where's Hixie when ya need him?
> > Likewise, the border of a radio button or checkbox would be the beveled edges and the background would be the "hole".
> It's not clear that this makes sense either (and some UAs implement the border as a border _around_ the bevel and the background as the space between the bevel and the border). Again, both renderings are fine per the CSS spec.
OK, I never would've thought of that. But again, I'll agree with the need for a spec. In the mean time, anything Mozilla does is correct -- including nothing. I have some minimal form styling on my site, but that's just to import the site's color scheme into the form. Nothing will break if the development teams decide that forms should be unstylable until there's something definitive to go on.
> > An <input type="file"> would be the only one that I couldn't see styles working with as they're currently written.
> <select>. No way to style the dropdown; no way to style the little drop-button, etc, etc.
I've seen <select>s get partially styled, probably using "background" and "color," so that one didn't come to mind. If the CSSWG decided to make forms stylable they'd probably need to do something like what I "proposed" for <input type="file">. Messy, but it'd get the job done. Of course, there's nothing to prevent them from coming up with something better :)
> Why not? It is my understanding that doing what you describe with a positioned div is quite possible on the Mac with native form controls (though NS4 may not do it, of course, being NS4). Yeah, it may not be possible on Windows, but why should MacIE or Chimera or Safari developers and users be punished for the drawbacks of Windows?
They shouldn't. My knowledge of browsing on a Mac is limited to N4, given that I never use a Mac for anything. (I hear they have some new OS based on UN*X ;) ) As fasr as Windows goes, I really don't know. Not even IE uses native widgets for everything.
Given that some browsers will prefer to use native widgets, I'd assume any form styling would be optional, like support for "text-decoration: blink".