You Don’t Need JavaScript for That, by Kevin Powell

[@NaserPapi-x7z]

Kavin is my number one hero in CSS, and I always enjoy his KZbin videos. Thank you for your kindness and the effective teaching techniques you're using...

[@killerwolle88]

Form vlidation: front-end: for the user, back-end: for yourself

[@pentexnyx5883]

Kingpin KP

[@nomadshiba]

37:40 you can bind them with any js state. similar to binding with input event.

[@MrWhiteav6]

Incredible stuff Kevin! Love your positivity brother and your knowledge is seemingly infinite 🎉

[@k16e]

So useful. So much fun. Thanks Mr. Powell and JetBrains.

[@angladephil]

Very useful, thank you Kevin ! On the forms, I dislike when fields go up and down when displaying or not an error message... Is there a way to avoid this ? Thank you.

[@merotuts9819]

Lord KP on JetBrains 🤩

[@clevermissfox]

Not that I think you should build a tabs component with CSS only especially because of all of the Aria attributes that need to be added and removed, but the comment about needing to be able to use your arrow keys with tabs to make it accessible made me wonder if it was possible to do that with radio groups for tabs? It was not long ago I had discovered that pressing the tab key on your keyboard when you're in a radio group (where they all have the same name) doesn't move to the next radio button, you need to use your arrow keys to navigate between the radio buttons. But as far as the table indexes go, if you have selected a radio button and it's checked , and all of the other table panels are to set to display none, then pressing the tab key should navigate into the active tab panel That said, making an accessible tabs component is much easier with JavaScript

[@nomadshiba]

for switch i prefer input[type="checkbox"] with [role="switch"] then style it

[@StingSting844]

I actually don't mind using these native features but what happens is that the corner cases between browsers keeps going up and it's so hard to maintain and there is no ROI

[@ahooton]

I discovered a small issue with the hint and error CSS when using this on my project... When clicking from a focussed text input to either a radio button or submit button, it was forcing me to click twice in order to focus the new element. I managed to debug the issue by removing display:block. Any suggestions as to how I can get this working properly?

[@phillduffy]

Hello Frontend Friends!

[@pookiepats]

😒

[@nulljeroka]

Awesome!

[@NickTheCodeMechanic]

For the password, I'd modify the regex to limit the total number of word chars and number chars, respectively. E.g. (?=....){,8}(?=...){,4}, where the first group your word chars and your 2nd your numbers. Also, I get the ^ and $. Those makes sense, maybe. But the `.*` and `.+`, why would that be allowed in a password field when you already have ^ and $ bounding (but not limiting) user input? I'd test it to see if you can't copy paste a whole script in there... I know I'm probably nit picking, but regex is kind of my thing (literally just finished a refactoring engine using regexes).

[@imkow]

Phone apps can use these, right?

[@CoolTebza-eh7ig]

Possible depends on how go about it. What platform where it ran ,etc.. use case. It's up to you what you to run on.

[@PaulAllsopp-rh5gb]

You simply don't use something if you don't need it, just because you know how to. Put another way, the tool you use for everything is not necessarily the best tool for the job. Or another way still: don't write code for something the browser can do already, learn how to call the browser method. Expand your toolset.