Mentioning here because I found this confusing: these self-titled "web components" don't seem to actually use the body of browser features usually referred to as Web Components (e.g., Custom Elements, Shadow DOM).
The accessibility concerns are right on. Another thing to think about is not distributing them as a monolith, so that devs can pull only the features they want to use. One of the biggest benefits of an all-vanilla library should be a minimal download.
I didn't check all the examples but most of the ones I did seemed to lack basic support for keyboard operation or other capabilities to make them accessible.
Been looking for a good spread sheet component for the past couple of weeks, but not found one that fit my needs. On the surface, jExcel supports all of my UI requirements. I will drop it into my project and see how well it works with my code.
I am happy to help, let me know if you need anything. I am trying to bring more features to the Open Source version. It should be integrated with jTools soon.
https://bossanova.uk/jexcel
For a project created 22 days ago? I doubt it. (There are many other things called "jTools", though, so it's hard to tell if this is where it originally started.)
paulhodel: I think it should have a "Show HN:" at the start, since you posted your own work, and maybe not the self-promoting "Great".
I do like the datepicker, but wish they had a panel between the calender month view, and the year navigation that displayed the months of a given year. Date of Birth is a very common use case, and navigation between months would be faster for more than 1-2 forward/backward as an intersticial.
Didn't test for small displays, or the other components.
Aside: I would prefer they used the term Browser Components or HTML Components instead of "web components" as it makes people think of the Web Components standard.
I looked at a few, and there are some fairly serious issues with them, particularly with accessibility. Unfortunately my comment here is mostly negative, and I can’t recommend using these components as it stands—but I put this list of various concerns with it in the hope that you can learn more about how to do these things, and make these, and more, components good. Pray accept my bluntness in this spirit.
Dropdown: comparatively inaccessible to screen readers; the dropdown basically won’t be noticed while you’re typing, because the accessibility tech sees a text box that is incidentally followed by a bunch of words of no significance that change every so often while you type. Needs various ARIA attributes. That’s going to be true of a lot of things here, actually—though be careful, because as they say in https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better..., no ARIA is better than bad ARIA.
Input masking: broken in three notable ways: (a) select everything in the field and start typing a new value, and it refuses to accept it, leaving the old value in place; (b) it seems to be doing keyboard handling itself to at least some extent (which I may add scares me enormously, and my fear seems justified by a brief skim of the related code: the shiftUps business is just wrong; try it out with a variety of different keyboard layouts and see) and doesn’t check for modifiers, so e.g. `Ctrl+1` adds a 1 to the field rather than switching to my first Firefox tab; (c) due to inserting extra characters (such as leading zeroes and all kinds of separators), things like Backspace don’t behave as you’d expect. (I may also add that input masking in general is for the most part simply a bad idea; validating the value the user has entered with no additional fanciness is normally the best idea, or for something in between the two, normalising the value on blur. I basically never encounter them these days, but I think that I could count the number of ones that have been implemented completely satisfactorily on the fingers of one hand, and I don’t think any of them were on the web.)
Context menu: doesn’t take care to avoid falling outside the viewport.
Image slider: poor accessibility, most notably because nothing is focusable (you should basically never put a click handler on a <div>, unless you want to count the case where you use bubbling so you can have multiple links or buttons or such with only one event handler registered) and click modifiers aren’t checked. Escape works to close it, but arrow keys don’t cycle through the images. Normally also image sliders use different DOM elements for the thumbnails and for the large view (commonly called “lightbox”), but you’ve gone for these being the same elements. There is a reason why people normally use separate elements for the lightbox: so that the thumbnails can be small images, while the lightbox loads the full-sized images. Lets things load slimmer and faster.
Modal: again accessibility problems from missing ARIA attributes and lack of focus management. You click that button, a screen reader will do zip: it hasn’t been notified that a popup is now open or been told to announce any change; as far as it’s concerned, you clicked the button, and the button is still focused and nothing happened. (I also observed a JS error in Firefox at this point; `e.path[0]` is not a thing. If I recall correctly, that’s a Shadow DOM v0 thing, and composedPath() is the proper thing now—though without thinking at all deeply about it, I suspect that .target is actually what you want.)
Thank you for doing a more thorough first pass... I don't have the time right now, but did think a few of the controls are a good first pass. I do think there's a lot of room to grow though.
You have a bug on this page: https://bossanova.uk/jexcel/examples/table-styling under "HOW TO SET GLOBAL CSS RULES FOR YOUR JQUERY TABLES". Double click on Price twice and the top row displays an error.
