Show HN: jTools – a collection of JavaScript web components with MIT license

You can do this safer with:

https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

an then just removing what you don't want to have via querySelectorAll() and remove().

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.

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.)