I only recently stumbled across and I have to say, it's cool to have that available in vanilla HTML.
I'm betting on HTML
141–150 of 458 posts
Re: I'm betting on HTML
#142Very surprising to me was that there is a semantic difference in and (the same is also the case with and ) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.
What was also surprising is that there is a Slider as well as Color picker element.
Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation of those elements (if needed).
Re: I'm betting on HTML
#143Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2]
Quoting from the doc here's the stack:
- WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being actively extended with features such as WasmGC.
- WebGPU provides an API (to JavaScript) that exposes a modern computation and rendering pipeline.
- Accessible Rich Internet Applications (ARIA) provides an ontology for enabling accessibility of arbitrary content.
- WebHID provides an API (to JavaScript) that exposes the underlying input devices on the device.
This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.
Re: I'm betting on HTML
#144I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…
Extensibility is the problem here. Either you force everyone to use the a limited set of UI controls (won't happen) or you need to allow some way to create custom UI controls, which leads to JS (or some other programmable system).
Re: I'm betting on HTML
#145Earlier quoted context omitted.
I noticed this helping an elderly neighbor with her banking. "No, you don't click there, but there... you can tell because..." then realized there's literally no way to tell. It's all flat.
then realized there's literally no way to tell. It's all flat. I hate that. I'm waiting for that fad to be over. I kind of liked material design, but it's too much of a pain to put into everything. Flat, borderless, and unidentified is so easy to do. The all flat approach encourages dark patterns. Lists of trackers you can opt out of, scrollable, with no scroll bar and no window border. There are important buttons hi…
There is something nice about plain old default look and feel. It probably is the kind of feedback they give, that does not require me to always roll my eyeballs elsewhere for confirmation, that my click did actually cause some action to start.
Re: I'm betting on HTML
#146I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…
In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…
I think the idea is rather, that you "extend" by composing primitive elements, and not that you change the primitive elements. Kind of like "composition over inheritance".
Re: I'm betting on HTML
#147Very surprising to me was that there is a semantic difference in and (the same is also the case with and ) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference. What was also surprising is that there is a Slider as well as Color picker element. Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation o…
> Very surprising to me was that there is a semantic difference in and (the same is also the case with and ) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.
It is in the names:
= emphasized, as in "this part of the text should be emphasized in whatever way the styling dictates = italic, just a way to style directly = strongly emphasized = bold, just a way to style directly and do not make a statement about semantics, they are for styling, and probably not much used in modern valid HTML, or at least should not, if you have CSS available. and make statements about importance of a part of text, in whatever way you want to style that. It just happens, that the default styling for those is italic and bold.
Re: I'm betting on HTML
#148Earlier quoted context omitted.
JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility. Take the datepicker; the native mobile version works great, why annoy users with a custom component?
why annoy users with a custom component Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on. My users alwa…
You're absolutely right on the 'why' part, but sadly a lot of custom implementations are annoying in terms of UX and accessibility. My only point here is that building proper custom components is far from easy, it takes a lot of time and effort.
Re: I'm betting on HTML
#149Earlier quoted context omitted.
Valid point. Ironically the main benefit of semantic markup is now an abstraction to help the human developers effect styling and control.
Isn't the main benefit of semantic markup still accessibility?
That’s one of the main benefits, but if the machine can make sense of the content, it can still present it however is clearest for the user.
Re: I'm betting on HTML
#150Yeah do we need that disclaimer?
If I (non native English speaker) write a blog post it will be shit English and won’t read “smoothly”. Then ChatGPT makes it nice and smooth. I check if my intentions are left unaltered and then post. For professional stuff I used to ask my American colleague, now I don’t have to bother her anymore.