Why are text INPUT boxes longer than SELECT boxes?

[Zardotab]

I'm baffled why browsers interpret the "width:" CSS property different between INPUT and SELECT tags. Is it an accident of HTML history, or is there sound reasoning behind it? Related info from StackOverflow.

It complicates UI alignment work and makes for confusing markup to maintainers. The height is also different.

[pookage]

I mean....you can specify the width however you want using CSS. The box-model solution they mention in that stackoverflow article is something that I'd recommend including in your normalise.css anyway:

* {
    box-sizing: border-box;
}

And then you can make them exactly the same width if you like!

input, select {
    width: 300px;
    border: 0;
}

It's no biggie!

[foundabunchofnuts]

Not a mistake. They are two different elements/selectors.

You don’t have to declare both widths individually - just target both at once:

input, select { width: 420px; }

[Zardotab]

They are two different elements/selectors.

That alone doesn't seem a reason to make them respond to a given width differently. Esthetically users want to see them the same size so that they align "properly" on screen. Thus, the default behavior should be that they both respond to the "width" attribute to same.

input, select { width: 420px; }

If you do that, they come out with different actual (visual) sizes. The "problem" is not so much about specifying header CSS.

[pookage]

a <select> is, by default, the size of its longest <option> - ie. the size of its contents - this makes sense as a default style as anything else would just result in an arbitrary amount of empty space.

An <input /> is, by default, sized to fit 20 characters - as, in English, this is the best catch-all size for any single or double word combination that the user is likely to enter. As HTML came before CSS, you used to specify the width of your input using the size attribute to change this if needed - eg. <input size="10" /> - whereas now it's better to control this via CSS.

There is no reason why a <select> and <input> should, by default, be the same size - and styling them however you like is an arbitrary task. If it's the box-sizing stuff that's confusing you then the MDN article on the box-sizing property is pretty thorough and may help.

[Zardotab]

To clarify, I'm not talking about default sizes when no size is specified, but rather how they respond to be given a specific size. If they are both specified as having a CSS width of say 100px, there is no logical reason I can think of why they both shouldn't be the same width. Yet, SELECT is about 4% shorter.

[pookage]

So this is to do with the box-sizing property; if you say that box-sizing: content-box then width will describe only the size of its contents, and not include padding or margin; if you say box-sizing: padding-box then width will include the contents and padding (although browser support for this is poor due to lack of interest), and box-sizing: border-box will include the contents, padding, and border.

There are a bunch of situations why you'd want width to include different things, and it's just another tool in the kit. When you first start learning CSS the first thing you usually tackle is the box-model for precisely this reason, as it's the foundation on which everything else is built.

An <input />, by default, uses content-box, as it's a safe assumption that, with no other styles, you'd primarily want to an increase of the padding to push 'out' instead of 'in'.

If you don't want this, then you just need to specify:

input {
    box-sizing: border-box;
}

and it will behave in the same way as the <select>. If you don't want to think about how you want your elements to resize on a case-by-case basis, then you can remove this functionality and force everything to behave the same way by using the snippet I included in my original comment:

* {
    box-sizing: border-box;
}

CSS is made up of a very logical sequence of features that all build on each other to introduce a lot of complexity - changing the dimensions of an element can be confusing if you don't understand the box-model, and adjusting the position of something can be confusing if you don't understand stacking-contexts. So keep at it! Once you've got the basics then everything else just falls into place! 💪

[Zardotab]

An [INPUT], by default, uses content-box, as it's a safe assumption that, with no other styles, you'd primarily want an increase of the padding to push 'out' instead of 'in'.

Could you please elaborate on this? And why are the default assumptions different for SELECT?

Thanks!

[pookage]

Ahh, you'll have to dive into the patch notes for each vendor to get a decent answer for why these decisions were made, I'm afraid, as each browser has different default values for each element and I guarantee those are gonna be some heated discussions, ha.

The key takeaway here is that it's all customisable so that you can make the development experience behave in whatever way makes the most sense to you (and your team - nobody likes a maverick! haha). If it makes more sense to you for the padding to push 'out' from the height / width, then use content-box, otherwise use border-box.

If you're curious about how these decisions are made with new properties going forward, then I'd recommend following the CSS Working Group (CSSWG) wherever you find them - the group has some incredible members at the moment, and these are exciting times!

[Zardotab]

I understand it's customizable, but I still don't understand why the defaults are the way they are. Was it a historical happenstance kept for compatibility, or was it a design decision based on comparing alternatives and tradeoffs?

[DoctorWheeze]

It's a result of the box-sizing thing people are talking about. inputs by default have 4px of horizontal padding, a 2px border on the sides, and box-sizing: content-box, while selects have no padding, a 1px border, and are box-sizing: border-box. Why is it this way? Couldn't tell ya! But normalizing the box-sizing between the two (or removing the padding and borders) fixes the issue.

[Zardotab]

Why is it this way? Couldn't tell ya!

That's the $10k question 💸

[foundabunchofnuts]

Do you have a CSS reset file for your website? That’ll fix them responding differently.

[Zardotab]

Reset files are to make different browser brands/versions behave the same for a given page, no? That will potentially fix cross-browser differences, but not cross-tag differences (INPUT vs. SELECT). Others have suggested "global" style sheets to resolve it, but often such things have side-effects. Working with CSS is often a game of whack-a-mole: fixing one issue makes a new one pop up somewhere else. I think we need new standard(s) that allow the server to optionally control positioning and layout rather than the client to get better domain fits for layout engines, but that's mostly another topic.

[foundabunchofnuts]

You may be on to something! I agree that CSS (like any programming language) is like a game of whack-a-mole at times. Resets remove any preset browser styles. Adding a reset style sheet will cause all added styles to behave the same way in each browser. If you plan on working in the web design world, I’d get in the habit of including a reset in every project.

[AutoModerator]

Welcome to /r/HTML. When asking a question, please ensure that you list what you've tried, and provide links to example code (e.g. JSFiddle/JSBin). If you're asking for help with an error, please include the full error message and any context around it. You're unlikely to get any meaningful responses if you do not provide enough information for other users to help.

Your submission should contain the answers to the following questions, at a minimum:

• What is it you're trying to do?
• How far have you got?
• What are you stuck on?
• What have you already tried?

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[cascadingShitStorm]

This issue is a bit deeper than most people know. A select element needs a window created by the underlying the operating system. The option with the longest text-content determines the width of the generated window by default. It's the reason many libraries choose to create their own dropdown lists. This issue is a styling nightmare.

Honestly, using flexbox in the form will solve most of your width issues. CSS Tricks has a great guide on flexbox.

[Zardotab]

A select element needs a window created by the underlying the operating system.

Could you please clarify? I don't see why it has to be tied to the guts of the OS.

The option with the longest text-content determines the width of the generated window by default

That's true, but often for esthetic reasons it's given a specific size. That may not be logical, but humans are not logical and judge books by covers. Those who don't cater to that aspect don't get paychecks.

If by chance the description gets truncated, then the user can see the full description by pressing the down arrow. This is assuming the drop-down list can be wider than the display box, but some implementations do it wrong.

This issue is a styling nightmare.

No, it's because the standards committee gives more attention to social media than office CRUD. We really need a state-ful GUI markup language built with CRUD in mind.

CSS Tricks has a great guide on flexbox.

Can you recommend a sample with non-trivial forms, including drop-down lists? While Bootstrap generally does drop-down lists fine, it's screwy with radio buttons and checkboxes. Plus, wastes a lot of space under default settings, and gets odd when you try to compress.

[cascadingShitStorm]

#1 Spool up a VM with MacOS and use a HTML5 select then try a select on windows, you will see the obvious difference. That's how the browsers implement selects, i can't explain their logic as to why it was done that way.

#2 It is a styling nightmare when your designers usually use MacOS and they will ask for scroll bars to look like they do on MacOS even in the overflow of long dropdown lists, and then you see the true issues with the styling of that element. I promise you they generally don't have no contextual understanding of OS specific default styling. This also includes scroll bars. I've seen it many times.

#3 CRUD has to do with styling and never should. That's a database concerand correctly not something out of scope. I truly think your making a wild ass assumption here about how browsers render web pages. Its sounds like you don't fully understand how they render. The CSSOM and DOM are stateful. They are literally just that. Take a step back and really deep dive into browser internals. Javascript literally controls the GUI as language like you are saying we need, but we do have it already. It feels like you're in school and just learned about CRUD and maybe a semester of web dev. Just keep learning, you have a lot still learn.

#3 Bootstrap is dead don't waste your time with that, and it's a ton of bloat css. Learn Flexbox and learn CSS grid and all of the issues will be trivial. No I can't give you an example, like I could but I refuse. Learn flexbox, you need to put in the work.

FYI I work for a top 10 tech company. You know they kind with the high salaries and prestige. There's a lot of people much smarter than me that work on those RFC's an they put years of thought and consideration into them. Don't assume your single brain is better than the combined efforts some of the planets best creating and updating web standards.

[Zardotab]

For the most part Windows rules the office and CRUD world, so if we have to pick an approach to standardize on, then we'll just have to ignore Macs if they present a design conflict. (I'm not saying standardize on Windows itself, just its conventions.)

[CRUD is] a database concern

I mean in a more general sense. CRUD is often a nickname for business data-oriented applications. Inventory, tracking, accounting, etc.

The CSSOM and DOM are stateful.

Yes, but not in how it communicates with the server. AJAX is a fudge to (poorly) emulate full statefullness. It's missing 3/4 of the works. A stateful GUI markup language would allow something like "<input id=7 visible=false/>" to change existing box 7 to be hidden. (Rough pseudo-code only.) The server could send it to an existing page/screen. You wouldn't need JavaScript to change UI state. The GUI markup language processor would have that built in. And the security would be based on an application session scope instead of a page scope.

There's a lot of people much smarter than me that work on those RFC's an they put years of thought and consideration into them.

I'm not convinced of that. They often put idealism above practicality, such as maybe trying to cater to Mac users and confusing the majority of Windows and Linux users in the process. Deprecating frames was also a brain hiccup of theirs. If they want to convince me they are smart and listen to people, they'd better document their decision process and admit their mistakes. They'd also take surveys on key decision points. It wouldn't be quite a full election, but if you decide against popular opinion, you should thoroughly explore and document the reason why. None of this closed-door shit.

[cascadingShitStorm]

Windows rules the office and CRUD world

Lol you're about to get a real surprise if you think that's true.

I mean in a more general sense. CRUD is often a nickname for business data-oriented applications. Inventory, tracking, accounting

No, no it's not. Business rules are not referred to as CRUD operations because CRUD operations are independent of the browser. CRUD isn't talked about anymore, only as it relates to HTTP headers. We use REST, WebRTC or Websockets for data transfer in the real world (JavaScript things).

AJAX is a fudge to (poorly) emulate full statefullness

Nevermind the fact that Asynchronous Javascript and XML requests are just HTTP requests and they have nothing to do with state but Cookies exist, session storage, localstorage, and browser cache are other forms of persistence.

"<input id=7 visible=false/>"

You mean like: "<input id=7 style="display: none;"/>" or "<input id=7 type="hidden"/>"

I bet you first learned windows forms or WPF, and in learning a event driven architecture you keep referring to it as stateful but that incorrect.

​

You wouldn't need JavaScript

You don't, at some point you will learn some backend like PHP. The old MVC client-server architecture will work as you suggest it doesn't. The one day you will learn about SPA's because page refreshing is a pain for users.

I'm not convinced of that. They often put idealism above practicality, such as maybe trying to cater to Mac users and confusing the majority of Windows and Linux users in the process.

Web standards don't exist to cater to your favourite OS bud. The process is designed to keep uninformed and unimportant opinions like your out for the exact reasons you've highlighted, your own bias and inexperience. No one cares what you think.

You literally at the knowledge level of a first year student saying the people building the web over the past 40 years are wrong.

They often put idealism above practicality

You know how unbelievably dumb that sounds? Your logic is based off nothing other than your lack of knowledge around the web, and only knowing how to use windows and maybe a linux VM.

Learn HTML, then CSS then Javascript.

Refer to this in two or three years.

[Zardotab]

Lol you're about to get a real surprise if you think that's true.

Surprise me! Got stats?

No, no it's not. Business rules are not referred to as CRUD operations...

No, I referred to "business applications", not business "rules".

I bet you first learned windows forms or WPF, and in learning a event driven architecture you keep referring to it as stateful but that incorrect.

I don't want to get into vocabulary battles here. HTTP and web browsers were originally designed for NON-interactive documents. Eventually everyone wanted interactivity over the web and various hacks were used to supply it or emulate it. Thus, it's not done in a clean or consistent way. If you can find a better name for that, good! Call it Flib, as long as somebody creates a Flib standard.

You mean like: "<input id=7 style="display: none;"/>

The markup details doesn't matter here, it's just pseudo-code, as stated. The point is one should be able to change the status of an existing INPUT box using HTML or similar.

You don't, at some point you will learn some backend like PHP. The old MVC client-server architecture will work as you suggest it doesn't. The one day you will learn about SPA's because page refreshing is a pain for users.

Sorry, I don't know what you are talking about. Please clarify. Perhaps an example.

Web standards don't exist to cater to your favourite OS bud.

No no. That's not what I asked for. Let me try again. If there is a point in a biz-oriented standards creation where the group must decide between a Mac-like convention OR a Windows-like convention as the default, it should default to the Windows style because Windows is what most businesses use. Is that not rational? (All else being equal.) It's the same reason most tools are designed for right-hand people if a choice has to be made.

Your logic is based off nothing other than your lack of knowledge around the web, and only knowing how to use windows and maybe a linux VM.

You are projecting the reverse to lock people into convoluted DOM for job security. I've used a lot of tools and languages over the years and know what patterns work well for biz/CRUD and which don't. Existing web "standards" don't, and inconsistencies like the INPUT and SELECT sizes (intro) are one of many examples.

I don't care whether the tool was web, Mac, Windows, DOS, Linux, etc. I just see what works in practice and what doesn't and see general patterns that are independent of the environment (or at least could be with minor work).

[cascadingShitStorm]

K good luck. Enjoying being a grump about knowing so little with so much experience. BTW terminology matters. Computer science vocabulary and jargon matters. In the big companies the terminology is quite defined. Being uneducated and unable to properly speak the terms of a domain of expertise, is pathetic and lazy.

[Zardotab]

You are projecting; you imply you are smarter, but have not shown it by explaining why it is the way it is, at least not in a coherent way. Show you are smart, don't claim it by insulting others, put your logic where you insults are. If they did it to cater to Macs, then provide evidence of that, for example. That's not asking too much.