I’ve been using the dialog element a lot lately. It’s super nice. Another thing that I don’t think enough people know about is the HTML Drag and Drop API. Too many people instantly reach for a package to do this when it’s overkill. HTML has that baked in already
I remember (back in the 2000s) coding a nested heirarchial form listbox (basically, accordions inside accordians) via Javascript, because it was much more efficient on network bandwidth for the browser to cache a copy of the list's raw data and dynamically populate the form listbox with it, than to statically include the list with every HTML page request. (This was a huge list with thousands of options nested into hundreds of categories, and highly prone to misclicks were it presented as a single flat list)
6:20 thats more of a `` expecting an input thats why it uses js. there is actually `popover` attribute to create popups that doesnt require js and also closes when you click on the backdrop unlike ``. also using all these over a js solution has other advantages as well, such as full accessibility support
I did know about all of those only because I've had to implement every one in an enterprise PWA. I took the checkbox styling in a different direction that uses the accent-color which provides very nice styling for checked and unchecked states so I don't need nearly as much CSS! Thanks for the video!
I love this kind of stuff. Semantic HTML + CSS is a lot better than a million divs with special class names that you have to remember to use in specific places. I try to avoid writing as much javascript as possible when building pages in plain HTML + CSS. I just wish there was more native styling for the select element, because I find myself using it a lot and being disappointed that CSS just doesn't do much for it. Thankfully our HTML pages are pretty simple (at work) so I can usually get away with the native select and some minimal styling.
Just to add more info for newbies (maybe even mid & senior level dev)? on top of the article, even though some of native components are fully functional nowadays across the browsers. But they are still working in subtle different ways in terms of the stylings and behaviors, which in worst case leads to inconsistent UX, the native components feels like out of touch from your entire application, and the feelings of bug. That's why eventually everyone moves to component libraries to ease out all the development hazards. As someone who actually implemented all of them in production and faced countless annoying issues from different browsers (mainly Safari, I just hate Safar every single day during that time). You definitely want to take the video, the articles with a grain of salt, as well as my opinion. Thing might change in the future. But it's good for you to at least implementing them once before using any component libraries. Always remember "it's working across browser" !== "functional with correct stylings and user interaction", people tend to forget the Frontend is not just about coding. You still need to do some manual tests even you have e2e.
They should all work in the 3 main browser engines, with the one exception being styling of the details marker in Safari which still uses a vendor prefixed property (details in the original article).
There are lots of HTML and CSS functionalities that help make better websites, without nested divs and unnecessary js. Remember many people live in places with limited connectivity or don't have the latest smartphone, let aside ads load.
I had no idea about a few of these, makes me realize I need to pay more attention to what HTML & CSS are up to because it could definitely make my life easier 😎
I don't think so. There have been a lot of cool features in HTML and CSS for a long time, but people don't tend to use them. The popular choice is always to install some JS-heavy alternative, and I don't see that changing. It's like how having a dozen nested DIVs all with utility classes (i.e. Tailwind) is preferred to just having one semantic tag and a couple of lines of CSS. It doesn't matter which is "better", trends gonna trend.
Nice one James. Best wishes for 2024 and thanks for sharing. I've used a few of them but the additional details are very helpful. I'll certainly look into Datalist. It might well be an alternative for my custom built "select" elements (200 lines of javascript) I do like our approach to let (latest) html and css do what they can best do.Bookmarked with 5 ******
I built a full component library leaning heavily on the use of HTML dialog for the modal. It has some caveats. A lot of things you would expect to work… just don’t. Clicking off the modal is not considered a close action. The back button will continue to navigate even with the modal up. But the hardest to deal with is scrolling. Scrolling will continue to be active in the window behind your modal. I had to implement a JS line that locks body scrolling when the modal opens. It’s not ideal.
I feel theres some people that skip html/css and are just enforcing js on a lot of stuff. They might still use div's for everything instead of semantic elements as well. Some of them still think Bootstrap is all the rave.
I’ve seen any number of junior devs create something like this because it just hadn’t occurred to them to use a link. Recreating basic HTML form behaviour is also common.
I use datalist for 10 years. It is always a good solution. Unfortunately Chrome on Android changed it to display the result list as bubbles at the bottom. Terrible ux imho
@@montebont True. The thig is I don't like having behavior split between HTML and JS, especially if I'm using a framework and the project tends to grow.
why would I not use javascript , internet speed is fast nowdays , phones has a large amount of memory , why even bother my self to hack the browser by using this complexe ::before and ::after
It's not about load times :-) Using what's available in html and css might save you a load of design/coding/testing time in JS. That is - IMHO - the point James tries to make...
For the life of me I don't understand what's so "crappy" about this? It's not James' opinion. He did put a lot of effort into making a video to share a few good ideas that might save you a lot of time and make you app less complicated by removing "custom code". You may very well disagree but that doesn't make it "crappy".
Great to see more people sharing how powerful semantic HTML/CSS is these days.
I’ve been using the dialog element a lot lately. It’s super nice. Another thing that I don’t think enough people know about is the HTML Drag and Drop API. Too many people instantly reach for a package to do this when it’s overkill. HTML has that baked in already
Collapsible boxes was something a stumbled on a few years back. Might've overforced it into everything, but I dig it!
I remember (back in the 2000s) coding a nested heirarchial form listbox (basically, accordions inside accordians) via Javascript, because it was much more efficient on network bandwidth for the browser to cache a copy of the list's raw data and dynamically populate the form listbox with it, than to statically include the list with every HTML page request. (This was a huge list with thousands of options nested into hundreds of categories, and highly prone to misclicks were it presented as a single flat list)
6:20 thats more of a `` expecting an input thats why it uses js.
there is actually `popover` attribute to create popups that doesnt require js and also closes when you click on the backdrop unlike ``.
also using all these over a js solution has other advantages as well, such as full accessibility support
I did know about all of those only because I've had to implement every one in an enterprise PWA. I took the checkbox styling in a different direction that uses the accent-color which provides very nice styling for checked and unchecked states so I don't need nearly as much CSS! Thanks for the video!
Wow, I'm really impressed with the "datalist" element. Thanks for sharing man!
I love this kind of stuff. Semantic HTML + CSS is a lot better than a million divs with special class names that you have to remember to use in specific places. I try to avoid writing as much javascript as possible when building pages in plain HTML + CSS. I just wish there was more native styling for the select element, because I find myself using it a lot and being disappointed that CSS just doesn't do much for it. Thankfully our HTML pages are pretty simple (at work) so I can usually get away with the native select and some minimal styling.
Just to add more info for newbies (maybe even mid & senior level dev)? on top of the article, even though some of native components are fully functional nowadays across the browsers. But they are still working in subtle different ways in terms of the stylings and behaviors, which in worst case leads to inconsistent UX, the native components feels like out of touch from your entire application, and the feelings of bug.
That's why eventually everyone moves to component libraries to ease out all the development hazards.
As someone who actually implemented all of them in production and faced countless annoying issues from different browsers (mainly Safari, I just hate Safar every single day during that time).
You definitely want to take the video, the articles with a grain of salt, as well as my opinion. Thing might change in the future. But it's good for you to at least implementing them once before using any component libraries.
Always remember "it's working across browser" !== "functional with correct stylings and user interaction", people tend to forget the Frontend is not just about coding. You still need to do some manual tests even you have e2e.
What’s totally missing in this video is the browser compatibility. Does it work in all major browsers? Chrome only? Firefox?
They should all work in the 3 main browser engines, with the one exception being styling of the details marker in Safari which still uses a vendor prefixed property (details in the original article).
Great tips man! I've only known about the native dropdown/accordion feature in HTML.
Accordian and dialog is neat, did use datalist earlier
There are lots of HTML and CSS functionalities that help make better websites, without nested divs and unnecessary js.
Remember many people live in places with limited connectivity or don't have the latest smartphone, let aside ads load.
I had no idea about a few of these, makes me realize I need to pay more attention to what HTML & CSS are up to because it could definitely make my life easier 😎
Really good article!! I think these ideas and HTMX will revive simpler frontend coding paradigms for certain.
I don't think so. There have been a lot of cool features in HTML and CSS for a long time, but people don't tend to use them. The popular choice is always to install some JS-heavy alternative, and I don't see that changing. It's like how having a dozen nested DIVs all with utility classes (i.e. Tailwind) is preferred to just having one semantic tag and a couple of lines of CSS. It doesn't matter which is "better", trends gonna trend.
Nice one James. Best wishes for 2024 and thanks for sharing. I've used a few of them but the additional details are very helpful. I'll certainly look into Datalist. It might well be an alternative for my custom built "select" elements (200 lines of javascript) I do like our approach to let (latest) html and css do what they can best do.Bookmarked with 5 ******
I built a full component library leaning heavily on the use of HTML dialog for the modal. It has some caveats.
A lot of things you would expect to work… just don’t. Clicking off the modal is not considered a close action. The back button will continue to navigate even with the modal up. But the hardest to deal with is scrolling. Scrolling will continue to be active in the window behind your modal. I had to implement a JS line that locks body scrolling when the modal opens. It’s not ideal.
Now that :has() has landed you can also use that, no js needed!
body:has(dialog[open]) { overflow: clip }
I feel theres some people that skip html/css and are just enforcing js on a lot of stuff. They might still use div's for everything instead of semantic elements as well. Some of them still think Bootstrap is all the rave.
I’ve seen any number of junior devs create something like this because it just hadn’t occurred to them to use a link. Recreating basic HTML form behaviour is also common.
I'm a pretty crappy frontend dev (not using any JS frameworks), which is probably the reason why I knew about all these features
I use datalist for 10 years. It is always a good solution. Unfortunately Chrome on Android changed it to display the result list as bubbles at the bottom. Terrible ux imho
1:36 daisyUi utilizes the check Box often
I would add another important thing that should not be done using JavaScript: Please do not use JavaScript to develop operating systems
i thought you were gonna talk about not using js for mysql
I seen them before but never used them myself :) but not all of them just saw this on another video
JS users: you mean there are elements other than DIV?
Programming is one, but what are the other four?
lmaooooo WILD!
Frameworks have generated lazy frameworkers. This is all very basic stuff.
Amen
Nope; no surprises here. All things I've been doing without JS for years now...
How to create button using HTML And CSS || CSS Round Checkbox Button || How to make CSS switch : ruclips.net/video/N0m1guFVs_M/видео.html
One day someone will make it possible to talk to the api from css........
You can, if the API is built with only GET requests and image URLs. 😅
Stop using javascript for: anything that doesnt go on your browser frontend.
yes i knew
Stop using JavaScript. Period.
htmx
I only use div.
So did I for a long time. At the end of the day 90% of html is a box. But the roles and behaviour are different
@@montebont True. The thig is I don't like having behavior split between HTML and JS, especially if I'm using a framework and the project tends to grow.
why would I not use javascript , internet speed is fast nowdays , phones has a large amount of memory , why even bother my self to hack the browser by using this complexe ::before and ::after
It's not about load times :-) Using what's available in html and css might save you a load of design/coding/testing time in JS. That is - IMHO - the point James tries to make...
Or just stop using JS
Some of us can't. In my line of work (engineering apps) I must do loads of calculations...
Stop using RUclips to spread crappy infos
Stop using YT comments to be a tired troll.
@@b1mind the Titel and you are Trolls Stop using Chrome and Go to wget and curl unqualified......
@@b1mindSTOP commenting on RUclips comments from tired trolls
For the life of me I don't understand what's so "crappy" about this? It's not James' opinion. He did put a lot of effort into making a video to share a few good ideas that might save you a lot of time and make you app less complicated by removing "custom code". You may very well disagree but that doesn't make it "crappy".