1. The `data-readonly` attribute behaves different from the native readonly attribute, developers may use the native readonly attribute in their own customized components. I don't want developers to get stuck in such situations. That's why the native readonly attribute is not overridden in Luda.
About native HTML validation: Native validation popovers can not be easily customized in all browsers. Maybe some developers still want to validate forms in JS instead of the native HTML validation. It's a choice to developers how to validate forms, Luda does't limit the ways.
2. CSS grid is an awosome feature, I'm sure it will be implemented in future versions. But before version 1.0.0, making Luda stable is the main target.
3. Luda aims to be a modern framework, so any new features will be considered seriously, including CSS scrollbars in Firefox.
At last, the styles of the form components may be changed due to some problems, not only the contrast accessibility.
I'm very happy you look into Luda for details, please keep an eye on future versions if you're interested. Your suggestions are import to me. Thanks!
To avoid misunderstanding, I want to clarify that negative feedback and positive feedback are both important to open source projects. I like guys like you who has a forthright attitude.
Then, let me explain my decisions when I built Luda.
1. The `<label>` tag and the `for` attribute are essential in forms, and WAI support is important if we want to make an application with good accessibility. The reason why I don't include these things in the documentation is that I want to make the sample code snippets as short as possible. So developers will focus on how to use the framework without having to figure out too many topics. Luda doesn't limit developers to use WAI attributes nor write a good form.
(I know Bootstrap includes these topics in their documentation, but that's not my choice, please correct me if I'm wrong.)
2. About the `required` attribute and native HTML validation: Native validation popovers can not be easily customized in all browsers. Maybe some developers still want to validate forms in JS instead of the native HTML validation. It's a choice to developers how to validate forms, Luda does't limit the ways.
3. The form-dropdown component is an alternative to the native `<select>`, it supports customization more flexable. It's OK if someone wants to stick to the native `<select>` tag. It's just another choice to developers, use the native `<select>` tag to follow the best practice or use a simulated one with a better style customization support.
4. I admit I made bad examples for the placeholder attribute and grouped checkboxes/radios, I'll correct those code snippets.
1. I get that short and simple code snippets are important in order to understand the fundamentals of a framework, but people with little experience will just copy the code in your documentation 1:1. I believe that semantic and accessible code snippets are very important. The way you constructed some elements[1] also suggests that there are no labels necessary.
2. & 3. There seems to be a general misunderstanding with a lot of frameworks about what needs to be customized. Native browser elements are always to be preferred - they are known by the users, accessible, and just work. Custom elements often are a lot more about design than usability and not wanting to "break" the designer's creation. A server-sided validation is of course necessary in both cases nevertheless. Custom client-sided validation can be useful in complex forms though.
3. You’re right, there are examples of both custom and native select elements.
Its painful to read on my FHD Dell. Constrast is poor with white on red and grey on dark gray. Most frameworks apart from Bootstrap and Material are unreadable on older screens and people still use 768p screens that dont show in outdoor light.
Luda has just been released for 2 days. Before this release, I used it in some internal projects of the company I'm working for. I'm sorry for unable to share these projects currently.
Personally, I'm using it to build my blog with Rails, the blog will come out soon!
* _Every_ input needs a <label>.
* Use the `for` attribute to connect labels and inputs.
* Placeholders are not a replacement for labels. You don’t need placeholders just for the sake of it.[2]
* Do not build custom form elements if it can be done without them. There is no need for the dropdown, just use <select>.
* Do use <fieldset> and <legend> to group multiple checkbox/radio inputs.
* Error texts should be connected to the particular input via `aria-describedby`.
* Do use the `required` attribute if form fields are mandatory.
[1]: https://oatw.github.io/luda/0.1.x/elements/form, https://oatw.github.io/luda/0.1.x/patterns/form-group
[2]: https://www.w3.org/WAI/tutorials/forms/instructions/#placeho...