Perché non c'è un tag "campo" html?

Esiste, si chiama <input> .

Il tag <input> è arrivato per primo. Ma poi è venuto il desiderio di raggruppare gli input (e in particolare la varietà dei pulsanti radio in particolare) in gruppi visivamente distinti. Nomi come <inputgroup> o <inputset> non volerebbero. Ma <fieldset> suona abbastanza bene, quindi è il nome che hanno usato.

<input> non è stato rinominato in <field> per coerenza, poiché ciò avrebbe infranto ogni sorta di roba. E onestamente è davvero necessario quel tipo di coerenza? Questo è HTML, dopotutto.

FWIW, <legend> è stato introdotto allo stesso tempo per completare l'esperienza visiva. La combinazione dei due ti ha permesso di disegnare una scatola con un'etichetta attorno al modulo in questo modo:

È di nuovo Windows 95. Questo era un livello di sofisticazione dell'interfaccia utente precedentemente disponibile solo in ambienti di sviluppo così raffinati come Visual Basic 5.0. Portare quel tipo di capacità progettuale all'HTML era un grosso problema.

Why does bootstrap use the class 'form-group'?

Why does Wufoo use li tags for each field?

Le persone a cui dovresti rivolgere queste domande sono gli autori di queste strutture.

Enclosing related form elements into fields would add clarity.

Puoi farlo abbastanza facilmente con gli elementi standard così come sono ora. Un fieldset ti consente di raggruppare più input. Il tag label può essere usato per legare un input alla sua descrizione.

Every major front-end framework has some class or tag to differentiate each field.

Questo perché ogni framework ha un approccio specifico allo styling di questi campi e indipendentemente dagli standard, le persone continueranno a inventare i propri ... il che ci porta al punto ...

Why the heck don't we have a single HTML tag to bring some normality to form design?

Perché i tag HTML non riguardano il design. HTML dovrebbe rappresentare contenuto, la struttura delle informazioni e non come appare qualcosa . Apparentemente, le persone responsabili dello sviluppo dello standard considerano lo stato corrente della lingua sufficiente in questa materia. Ai web designer viene data molta libertà su come modellare questi elementi con i CSS e utilizzare elementi aggiuntivi intorno a loro, che è esattamente quello che hai osservato.

Per riassumere, il design non è ciò di cui parla la lingua. La semantica è il nucleo della specifica. Se mai provi a standardizzare i progetti, c'è solo un modo in cui ciò può accadere. Randall Munroe, l'autore di XKCD fa un punto eccellente su questo fenomeno:

È un elemento facoltativo per consentire il raggruppamento di elementi form .

Gli elementi del modulo, come input, esistono al di fuori di fieldset , li avvolgono all'interno di tag di campo quando all'interno di fieldset è ridondante.

La risposta breve è: perché <field> sarebbe ridondante (o peggio).

Che cosa sarebbe un "campo" in questo contesto? Beh, mi aspetto che significhi qualsiasi elemento associato al modulo nel campo set che potenzialmente fornisce input.

Ma non c'è bisogno di designarli come "campi" perché ... beh ... noi / il browser sappiamo già che sono campi. Il loro raggruppamento in un elemento <field> non consente quasi nulla ¹ . Dal punto di vista di qualcuno che legge / scrive l'HTML <field> sarebbe solo un rumore sintattico.

^{1 - Riesco a vedere un piccolo vantaggio per il codice javascript (etc). Un elemento <field> renderebbe più semplice per javascript interrogare il DOM per trovare tutti i campi designati in un fieldset ... o un modulo. Ma il rovescio della medaglia è che se <field> ha un significato speciale (ad esempio nei programmi Javascript), allora dimenticare un tag <field> è una potenziale fonte di errori.}