WTF, CSS?


  • Considered Harmful

    <!DOCTYPE html>
    <html>
    	<head>
    		<title></title>
    		<style type="text/css">
    			/* These elements display with exactly the same width and height in Firefox, IE, and Chrome. */
    			input[type="text"], select { display: block; outline: 0; padding: 1px; border: solid 1px #000; margin: 0; font-size: x-small; }
    			input[type="text"] { width: 260px; height: 17px; }
    			select { width: 264px; height: 21px; }
    		</style>
    	</head>
    	<body>
    		<input type="text" value="Test">
    		<select>
    			<option value="" selected>Test</option>
    		</select>
    	</body>
    </html>
    


  • The width I can understand. A <select> has the arrow identifier (at least in Firefox) that takes up extra space. As for the height... maybe some similar reason. But hey, if it works, run with it. It is not ours to question why...



  •  It's not the arrow. <select> elements use border-box sizing; most elements use content-box sizing.



  • @Goplat said:

    content-box sizing.

    TRWTF. If I want an object 200 pixels wide, I want it 200 pixels wide including padding and border, but excluding margin. So, I define it that way, realize it doesn't look right, look for what causes the issue, and 5 minutes later, I facepalm, curse CSS and fix it. And that process happens every time. Why does this have to be?



  • @derula said:

    @Goplat said:
    content-box sizing.

    TRWTF. If I want an object 200 pixels wide, I want it 200 pixels wide including padding and border, but excluding margin. So, I define it that way, realize it doesn't look right, look for what causes the issue, and 5 minutes later, I facepalm, curse CSS and fix it. And that process happens every time. Why does this have to be?

    Fuck why does SELECT even exist? Why isn't it INPUT TYPE="SELECT"? Why does TEXTAREA exist, for that matter?

    The whole thing's fucked to high heaven.



  • @blakeyrat said:

    Fuck why does SELECT even exist? Why isn't it INPUT TYPE="SELECT"? Why does TEXTAREA exist, for that matter?

    The whole thing's fucked to high heaven.

    I'm going to take a wild guess and say it's because SELECT should contain OPTION child elements, TEXTAREA may contain a child text node, and other INPUTs shouldn't contain any children.

    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?



  • @Zecc said:

    @blakeyrat said:

    Fuck why does SELECT even exist? Why isn't it INPUT TYPE="SELECT"? Why does TEXTAREA exist, for that matter?

    The whole thing's fucked to high heaven.

    I'm going to take a wild guess and say it's because SELECT should contain OPTION child elements, TEXTAREA may contain a child text node, and other INPUTs shouldn't contain any children.

    Still I think INPUT TYPE="BUTTON" and INPUT TYPE="SUBMIT" sound just wrong. So the type of input is button? I input a button? And I input... submission?

    I don't know how to input a radio or a checkbox either.



  • @Zecc said:

    @blakeyrat said:

    Fuck why does SELECT even exist? Why isn't it INPUT TYPE="SELECT"? Why does TEXTAREA exist, for that matter?

    The whole thing's fucked to high heaven.

    I'm going to take a wild guess and say it's because SELECT should contain OPTION child elements, TEXTAREA may contain a child text node, and other INPUTs shouldn't contain any children.

    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?

    If a set of linked radio buttons had to all be children of the same element, it would be difficult to lay them out on the page non-contiguously.

     



  • @Someone You Know said:

    @Zecc said:
    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?

    If a set of linked radio buttons had to all be children of the same element, it would be difficult to lay them out on the page non-contiguously.

    It would still be nicer to have something like

    <radio name="group" value="yes"/>Yes

    <radio name="group" value="no"/>No

    and

    <checkbox name="opts" value="fnf"/>FILE_NOT_FOUND?

    <checkbox name="opts" value="meme"/>Meme?



    the way it was done with <button> than use the vauge <input> elements with lots of attributes that aren't even necessarily applicable.



  • It just needs to be consistent. Either make a new tag for every type of field input, like BUTTON, SELECT and TEXTAREA that already exist. Or have a single INPUT tag that handles all those cases. The weird mish-mash we have now is just stupid. (And HTML5 doen't help it.)



  • @Xyro said:

    @Someone You Know said:
    @Zecc said:
    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?
    If a set of linked radio buttons had to all be children of the same element, it would be difficult to lay them out on the page non-contiguously.

    It would still be nicer to have something like

    <radio name="group" value="yes"/>Yes

    <radio name="group" value="no"/>No

    and

    <checkbox name="opts" value="fnf"/>FILE_NOT_FOUND?

    <checkbox name="opts" value="meme"/>Meme?



    the way it was done with <button> than use the vauge <input> elements with lots of attributes that aren't even necessarily applicable.

    Also, inner options in a checkbox don't make sense.

    How about having to set an INPUT[type='submit']'s "value" to set its text? That's another of my pet peeves. It breaks separation of concerns with localization too.



  • @blakeyrat said:

    The weird mish-mash we have now is just stupid.
     

    DING DING YOU ARE CORRECT

    there is no prize money



  • @Zecc said:

    @Xyro said:
    @Someone You Know said:
    @Zecc said:
    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?
    If a set of linked radio buttons had to all be children of the same element, it would be difficult to lay them out on the page non-contiguously.

    It would still be nicer to have something like

    <radio name="group" value="yes"/>Yes

    <radio name="group" value="no"/>No

    and

    <checkbox name="opts" value="fnf"/>FILE_NOT_FOUND?

    <checkbox name="opts" value="meme"/>Meme?



    the way it was done with <button> than use the vauge <input> elements with lots of attributes that aren't even necessarily applicable.

    Also, inner options in a checkbox don't make sense.
     

    They would if you wanted to have a "choose X of these Y options" construct (where X > 1), which HTML lacks native support for. But it would still be a bad idea to force all of the options to be children of the same parent.

    Perhaps a good approach would be to add another element (not necessarily positioned hierarchically with the options) that controls the grouping and defines the maximum number of choices. The browser would then render the options as radio buttons if that maximum is 1, or checkboxes otherwise.



  • @Someone You Know said:

    @Zecc said:

    @Xyro said:
    @Someone You Know said:
    @Zecc said:
    On the other hand, why is it <INPUT TYPE="checkbox"> and <INPUT TYPE="radio"> rather than their own elements with inner OPTIONs?

    If a set of linked radio buttons had to all be children of the same element, it would be difficult to lay them out on the page non-contiguously.

    It would still be nicer to have something like

    <radio name="group" value="yes"/>Yes

    <radio name="group" value="no"/>No

    and

    <checkbox name="opts" value="fnf"/>FILE_NOT_FOUND?

    <checkbox name="opts" value="meme"/>Meme?



    the way it was done with <button> than use the vauge <input> elements with lots of attributes that aren't even necessarily applicable.

    Also, inner options in a checkbox don't make sense.
     

    They would if you wanted to have a "choose X of these Y options" construct (where X > 1), which HTML lacks native support for. But it would still be a bad idea to force all of the options to be children of the same parent.

    Perhaps a good approach would be to add another element (not necessarily positioned hierarchically with the options) that controls the grouping and defines the maximum number of choices. The browser would then render the options as radio buttons if that maximum is 1, or checkboxes otherwise.

    Also to consider: sometimes you want to select from pre-defined values (as with checkboxes/radios), but other times you want some sort of use-customizable value. Ultimately, though, what the server sees is just a set of name=value pairs. If we could somehow tie in all these features into a single, reusable, generic object, we'd get the maximum impact for this new form control.

    As you mentioned, based on if we want one or more selectable values or use-customized value(s), the browser would figure out how to display it. I think this is a great feature, to make the browser do the figuring out of how to match the UI display to the desired behavior. (These parameters to define the type and behavior of values would just be standard attributes.) Since the element's function in life is to report on user input to the server, why don't we just call it something simple like "input"?



  • @Xyro said:

    Since the element's function in life is to report on user input to the server, why don't we just call it something simple like "input"?
    But... but what if, for design reasons, you'd like to force a certain type of input to be displayed?

    You would need to allow an optional attribute to be specified to define the input's "type".



  •  @Someone You Know said:

    They would if you wanted to have a "choose X of these Y options" construct (where X > 1), which HTML lacks native support for.

    Never heard of using the multiple attribute on a select tag, have you?



  • While I could explain what is wrong in a select with "multiple on", I'll let this guy to the talking for me:

    the select multiple form field has always been a usability challenge

    While it may be clear to you and me how to select multiple items here, it’s not obvious to most people. Furthermore an accidental click causes all previous selections to be lost.



  • @Zecc said:

    While I could explain what is wrong in a select with "multiple on", I'll let this guy to the talking for me:

    the select multiple form field has always been a usability challenge

    While it may be clear to you and me how to select multiple items here, it’s not obvious to most people. Furthermore an accidental click causes all previous selections to be lost.

     

    I too, am in favour of a checklist instead of a multiselect.

     


  • 🚽 Regular

    @dhromed said:

    I too, am in favour of a checklist instead of a multiselect.
     

    You know, this just made me realize, I can't remember the last time I've had to CTRL-click on a multi-select. We've all seemed to move onto checkboxes nowadays, which is an awesome thing.

    That being said, there's nothing that ever said a browser could not render a multiple-select with checkboxes, AFAIK.


Log in to reply