evolt.org Interviews Eric MeyerSaturday January 25th, 2003evolt.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. I'm sorry to hear that this book includes a section on styling forms.... That implies that he says more about it than "Don't do it". :( From the sample code on the companion site it seems the styling is aimed at a) Making a form easier to look at and less intimidating to fill in. b) Making a form display as a traditional form when printed (select boxes aren't much good there) No, I did not look at it -- I did not see the link to the companion site. Now that I've looked, it does not seem as bad as I was afraid of (though I can't find the part about printing <select>s and that part is the part I would be really worried about). He has a select box for a list of states a person can choose. For a printed version of the form, where the user fills it in with a pen, a select box obviously isn't an interface that works (unlike check boxes and radio buttons which have equal application in paper form) so in print mode the select box is replaced by an underline upon which the user would simply write their state (The text type input fields also look like this). I haven't actually looked at the source again to check, but my guess is that he sets display:none on the select box in print mode and displays the underline thing instead, rather than attempting to "restyle" the select to get it to look like a line. The former is vastly simpler, and almost certainly more portable. Styling form doesn't only mean make them nore colorfull, there's also generated content, which allowes you for example to add graphics an a select. See this: http://mozilla.linuxfaqs.de/select.xml This is exactly the kind of styling I'm against. the <select> should be a pure replaced element, with no CSS access to the <option> elements inside it. IMO. (And when Mozilla switches to XBL form controls that will be the case). I thought that the possibility to style form controls was one of the reasons that Mozilla years ago chose not to use native widgets? Well, the possibility of having, say, things on top of the form controls without the form controls shining through. Or form controls inside translucent divs (the _div_ is styled, not the form control). On some platforms, these things cannot be done with native widgets. On others, they can be. Browsers that target the latter should be free to use native widgets. I have much respect for Eric, he does a lot for the CSS community. =) What's wrong with styling forms? Obviously I missed something. =| > What's wrong with styling forms? The fact that it's undefined by the CSS spec and hence non-portable? (And that it is _very_ nonportable across platforms) Can you give a reference here? I always assumed since a form element is an HTML element, it could therefore be styled by CSS. Pragmatically, I can tell you it works and works well across browsers. Please describe to me a <input type="file"> in terms of the CSS box model? Should one be able to style the button and textfield separately? If so, how? When one sets a border-color, does that mean a border around both the button and the textbox, borders on the button and textbox, or what? What about <select size="1">? This has even worse problems. Forget that; even the meaning of "border" for radio buttons and checkboxes is not portable across browsers (try it in IE/Windows and Mozilla, for example). Similarly, "padding" on buttons means totally different things in different browsers. The list goes on and on. The only input that is at all close to being portably stylable is the text input and even _that_ is different between IE6 standards and quirks modes, eg. The kicker, though, is that a browser should be able to use the platform's native widgets for its form controls. This means they will look like the OS widgets, _period_, and not be stylable. The references are in the www-style archives.... a good one is http://lists.w3.org/Archives/Public/www-style/1999Apr/0019.html (this one talks about <select> but the same applies to most of the form controls). Basically, any styling of form controls we are doing right now is likely to be a violation of CSS3 and needing to be changed, which is why I would prefer if people didn't start getting cozy with it... ;) Good points. I suppose though, but feel free to correct me, that CSS does apply to form elements, but that the implementation is sometimes ambiguous and inadequate for the intended purpose. Basically (with some obvious exceptions like input type="file") I believe CSS can be used to style elements like buttons, textfields, checkboxes just fine. The fact that there are differences between browsers is in itself not a reason to dismiss the standard. I agree that a browser should allow OS native widgets to be used (as a preference). Mozilla gets styling of form elements right most of the time. IE is (in my opinion) really a bad example when discussing standards, its CSS support is too broken. I feel that the situation is not as bad as you describe. I'm sure CSS3 will address some of the issues with forms, but CSS 1/2 can be used (at least in part) to change the appearance of form elements. > The fact that there are differences between browsers is in itself not a reason to dismiss the standard. Of course not. The reason to dismiss it is that those differences are all allowed by the standard. That makes the standard ridiculously ambiguous, hence useless. Here's a simple question. What is the expected rendering (and why) of: <input type="button" style="width: 100px; border: 10px solid black, padding: 10px; background: black; color: white" value="Test"> OK, I'll bite. What the heck: <input type="button" style="width: 100px; border: 10px solid black, padding: 10px; background: black; color: white" value="Test"> In my opinion, this would be styled similarly to a <span>... a 10px blace border around a black area 100px wide, with "Test" written in white in the middle of it. I could see where someone might expect to have a black button with a "normal" beveled edge, with a 10px border around /that/, but I think those people would be in the extreme minority. Likewise, the border of a radio button or checkbox would be the beveled edges and the background would be the "hole". An <input type="file"> would be the only one that I couldn't see styles working with as they're currently written. Maybe CSS3 would implement something like input[type=file]:textbox and input[type=file]:button to make it stylable. UAs that use native widgets wouldn't be able to do that stuff, but they also wouldn't be able to place a positioned <div> "above" a form (like N4), so they suck by definition. > In my opinion, this would be styled similarly to a <span>... a 10px blace border around a black area 100px wide 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 (try it in Mozilla?) > but I think those people would be in the extreme minority 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"). In any case, the problem is that both renderings are OK per the CSS2 spec. > 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. > 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. > UAs that use native widgets wouldn't be able to do that stuff, but they also wouldn't be able to place a positioned > <div> 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? > 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". > Hey, it does what I think it should! Sign me up! :) Except the text does not move... ;) I wasn't saying we should not style forms. But we should start depending now on browser behavior that may be against the spec tomorrow.... that's all I was saying. ;) > > Hey, it does what I think it should! Sign me up! :) > Except the text does not move... ;) Hm. In my build from the 15th it does. Did that change recently? > I wasn't saying we should not style forms. But we should[n't] start depending now on browser behavior that may be against the spec tomorrow.... that's all I was saying. ;) True enough. I'd like to think my ideas for the simpler controls (<input type='text'>, <textarea> and buttons) would at least be mostly how things turn out. But if a CSS spec later on contradicts me I'll just change it. That's the price you pay for trying to stay ahead of the curve :) I believe the specs specifically say that the type="file" element isn't to be styled for security reasons. It might not be the specs, it might just be mozilla being security concious though. Also, if it's hidden and submitted I believe there is either a warning or nothing is sent... I can't remember the details, but I remember seeing stuff in bugzilla about it. |