Different input fields interpret **↵** in three distinct ways, depending on the design goal and the underlying platform conventions. Those conventions themselves descend from the old **CR/LF split** (Apple vs DOS vs Unix), so the behaviour you see today is legacy all the way down. **1. “Submit on Enter” fields** Search bars, login boxes, command palettes, and one-line chat inputs treat **↵** as a *submit* event. The field is single-line by definition, so a newline has no meaning. Pressing **↵** triggers the form’s default action: search, send, submit. **2. “Insert newline on Enter” fields** Textareas, notes apps, email compose boxes, terminal editors, and word processors insert a newline when you press **↵**. Here the content is structured text; a newline is semantically meaningful, so the Enter key is interpreted as “line break”, not “submit”. **3. Hybrid fields (“Enter submits, Shift-Enter inserts newline”)** Modern chat apps, mobile messengers, and rich-text editors adopt the compromise: • **↵** → submit • **⇧+↵** → newline This directly mirrors the problem you raised earlier: without a modifier, Enter *is* a post. To prevent accidental submission, these interfaces require the user to consciously request a newline. --- **Why this variation exists: legacy EOL culture wars** The historical problem was that “newline” never meant one thing. **Unix** used **LF** (U+000A): One character = end of line. **Classic Mac OS** used **CR** (U+000D): Return = new line. **Windows / DOS** used **CR+LF** (000D 000A): Two characters = the line break sequence. So the meaning of **↵** (Return/Enter) was not conceptually unified. Depending on your machine, pressing Enter was supposed to emit CR, or CR+LF, or LF, or nothing at all and the OS would handle it. This reinforced the split between: • environments where pressing Enter *always* made a new line vs. • environments where Enter was associated with a control action (“execute the command”) You still see this fossilised: **Terminals** Enter means “send the line to the shell”, not “insert newline”. Yet text editors *inside the terminal* (nano, vim) treat Enter as “insert LF”. **Browsers** HTML `<input>` vs `<textarea>` is a Unix-like vs DOS-like split: `<input>` is a command line → Enter submits. `<textarea>` is a text file → Enter inserts newline. **Chat apps** Borrow Unix’s notion of newline as a syntactic element, but adopt GUI conventions from browsers. Hence the hybrid: Enter submits, Shift-Enter breaks. --- **Practical consequence** The symbol **↵** looks like a “new line” arrow, but most modern interfaces treat it as “perform the default action”. Text fields whose primary purpose is *text* treat Enter as EOL. Text fields whose primary purpose is *action* treat Enter as submit. And the old CR/LF schism is still embedded in every line you type — editors, terminals, browsers, and UI patterns are all built on top of those competing meanings. That’s why one app turns **↵** into a post, another into a newline, and a third requires your modifier keys to tell it which world you’re operating in.