Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
LOL, that is the drawback of me not using TypeScript (any more). I don't learn where it fails.
Even more LOL to consider I worked in the Microsoft world for 15 years;
and "nudged" my Typescript colleagues unlearn ES3 patterns they applied to cool new TypeScript: Clark Kents' TypeScript Adventures
Native color pikers are all different and impossible to customize, so if cross-browser consistency is a requirement, then rolling with the native color picker is a "no-go". It may also be a requirement to align with other aspects of the consumer's design system. They also don't provide much in terms of a11y. In short, there may be many design requirements that lead to a custom color picker since native picker are (unfortunately) quite inflexible.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Good idea! As the focus of the post was custom elements and reactive controllers, I didn't cover all the bases, I'd love to see a remixed glitch that builds in accessibility code down here in the comments though. I'll add that idea to the "next steps" section
A nice a11y related feature is to include the ability to specify a background or foreground reference color, and show the color contrast along with WCAG AA/AAA compliance. In some contexts, this is an important (yet rarely implemented) feature as it goes beyond standard a11y to include authoring accessible content. I know your sample component wasn't meant to include all the bells & whistles though. Thanks for sharing this Benny!
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Hello! I am a Front End Web Developer! I have also a YouTube channel where I am posting programming tutorials: https://www.youtube.com/channel/UCFzeA3xC-_i4ZT-XwcwsJxQ
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Cool... but I am the laziest developer ever... drop the
thisin this:fine, but if you copy that into a typescript file, it will break everything.
That's not a criticism of your change as much as it's a criticism of typescript, though. Still, it bears saying.
LOL, that is the drawback of me not using TypeScript (any more). I don't learn where it fails.
Even more LOL to consider I worked in the Microsoft world for 15 years;
and "nudged" my Typescript colleagues unlearn ES3 patterns they applied to cool new TypeScript:
Clark Kents' TypeScript Adventures
Native color pikers are all different and impossible to customize, so if cross-browser consistency is a requirement, then rolling with the native color picker is a "no-go". It may also be a requirement to align with other aspects of the consumer's design system. They also don't provide much in terms of a11y. In short, there may be many design requirements that lead to a custom color picker since native picker are (unfortunately) quite inflexible.
Very cool Benny! Thanks for sharing. Wondering if you might have a clever way to make this sort of experience accessible to screen readers?
Good idea! As the focus of the post was custom elements and reactive controllers, I didn't cover all the bases, I'd love to see a remixed glitch that builds in accessibility code down here in the comments though. I'll add that idea to the "next steps" section
For production needs, check out <vanilla-colorful>
A nice a11y related feature is to include the ability to specify a background or foreground reference color, and show the color contrast along with WCAG AA/AAA compliance. In some contexts, this is an important (yet rarely implemented) feature as it goes beyond standard a11y to include authoring accessible content. I know your sample component wasn't meant to include all the bells & whistles though. Thanks for sharing this Benny!
I'd love to see a remix that includes this
Good point! if the native widget fulfills your needs, it would be irresponsible to use JavaScript of any flavour to deliver the feature.
There could be lots of reasons to want a custom element for this, though. Off the top of my head I can think of two:
To answer the question "Why write a blog post about making a colour picker?" - The specific content here isn't as important as the concepts of
@codingsafari do you have another idea for how to use a
MouseController? I'd love to see how you remix the glitchcool! This is very usefull!
I wrote a version of this example but using Haunted instead of extending HTMLElement directly:
hauntedhooks.netlify.app/docs/hook...
I added an a11y section, which I should have done in the first place. Thanks @westbrook and @thepassle