3 ms·

Who is in charge of these HTML changes? This is horrible. It’s bad enough that for the last three decades we’ve have to use the `selected` attribute, now we are

Who is in charge of these HTML changes? This is horrible. It’s bad enough that for the last three decades we’ve have to use the `selected` attribute, now we are going to have a `button` in `select` with a `selectedoption` tag? Please, just No! The CSS for the style of the element belongs with the `select` tag. And all that should be needed to demark the selected option is a matching `value` attribute. I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. We need functional design, polymorphism and simplicity, not just more kitchen sinks.

diggan 2y ago
> Who is in charge of these HTML changes? This is horrible. We all are, so thank you for this horrible proposed-but-not-yet-implemented change! Jokes aside, you can participate in the discussion yourself here: https://github.com/whatwg/html/issues/10520 https://github.com/whatwg/html/issues/10520 But be warned, you will probably not be able to convince people with just "Please, just no!". > I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. Yeah, that makes sense, it's a markup language, not a programming language. The targeted audience for HTML and CSS is way bigger than just programmers. For the people who want to build imperative UIs or even "immediate mode" GUIs there are a ton of options out there already. I get the sense that people complaining about HTML/CSS not being like a programming language enough are programmers, not document authors.
jaffathecake 2y ago
> now we are going to have a `button` in `select` with a `selectedoption` tag? Can you detail why this is such an awful thing? > The CSS for the style of the element belongs with the `select` tag That isn't even true today. A select is made up of multiple parts, the button that's always visible on the page, and the resulting menu/popover which contains multiple options. These can already be styled a bit depending on the platform. However, folks want to style them in more detail, and as a result they end up having to recreate a select from scratch, and in almost all cases they mishandle the keyboard navigation and accessibility. The aim here is to provide the freedom of styling whilst providing good keyboard and accessibility out of the box. > I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. I'm sorry to tell you that your sense is way off. The strongest voices in web standards are browser engineers, who tend to be more familiar with C++ than building web apps/sites. This is why we need to ensure that web developer voices are heard in these discussions, hence the post.

diggan 2y ago

> Who is in charge of these HTML changes? This is horrible. We all are, so thank you for this horrible proposed-but-not-yet-implemented change! Jokes aside, you can participate in the discussion yourself here: https://github.com/whatwg/html/issues/10520 https://github.com/whatwg/html/issues/10520 But be warned, you will probably not be able to convince people with just "Please, just no!". > I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. Yeah, that makes sense, it's a markup language, not a programming language. The targeted audience for HTML and CSS is way bigger than just programmers. For the people who want to build imperative UIs or even "immediate mode" GUIs there are a ton of options out there already. I get the sense that people complaining about HTML/CSS not being like a programming language enough are programmers, not document authors.

jaffathecake 2y ago

> now we are going to have a `button` in `select` with a `selectedoption` tag? Can you detail why this is such an awful thing? > The CSS for the style of the element belongs with the `select` tag That isn't even true today. A select is made up of multiple parts, the button that's always visible on the page, and the resulting menu/popover which contains multiple options. These can already be styled a bit depending on the platform. However, folks want to style them in more detail, and as a result they end up having to recreate a select from scratch, and in almost all cases they mishandle the keyboard navigation and accessibility. The aim here is to provide the freedom of styling whilst providing good keyboard and accessibility out of the box. > I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. I'm sorry to tell you that your sense is way off. The strongest voices in web standards are browser engineers, who tend to be more familiar with C++ than building web apps/sites. This is why we need to ensure that web developer voices are heard in these discussions, hence the post.