I’m wondering what Atom’s philosophy is regarding standard HTML elements such as
inputs. The list of possible inputs per the spec is fairly long: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Attributes
Several related questions have been asked:
- Password fields when using EditorView subview
- How do you limit atom-text-editor mini input to numbers only?
Answers to the above questions include recommendations to reimplement native behavior by hacking
atom-text-editor, or to use (broken) native elements. Both approaches are quite limiting.
The problem with reimplementing all of these components for atom is that it’s redundant (Chrome already ships with working components), it’s error-prone (e.g. we would need to get all the details right regarding things like accessibility, security, etc) and not very straightforward in the case of hacking
The problem with native elements is that their behavior is largely broken in Atom. For example, backspace does not work, as documented in Backspace isn’t working in regular text fields :(. The suggested workaround is forcing Chrome’s native behavior by wrapping the
input with an element of class “native-key-bindings”, but this in turn breaks focus switching via
tab. Native inputs also need to be styled explicitly to conform to themes.
I see two options going forward:
- Atom embraces native
inputbehavior and provides style support in the form of a themed base stylesheet.
- Atom provides Atom-esque equivalents of all common
inputtypes for developers to use.
Maybe there are additional options, but the current situation is hardly scalable as demand for different element types increases. What are your thoughts on this?