[zichy]

Whenever I stumble upon yet another UI/CSS framework, I always check the form elements first. Here we go.[1]

* _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...

[memco]

To add to this:

- check the contrast accessibility: it seems very poor for read-only fields due to the opacity. Even the default seems low for body text.

I think there’s great documentation of customization, but I had a few questions related to design decision:

Why data-readonly and not use readobly and other browser native html5 attributes like validation?

Why flexbox and not grid? If you’re only targeting latest browsers: this could provide some greater power.

Another thing I noticed is that FF is noted as not supporting CSS scrollbsrs, but it is coming: will Luda be updated when it’s available?

[oatw]

Hello memco!

Thanks for the good questions!

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!

[oatw]

Thanks for the checking!

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.

Thanks again!

[zichy]

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.

4. Cool, thanks!

[1] e.g. https://oatw.github.io/luda/0.1.x/elements/form#select-field

[oatw]

Very professional advice!

I cannot promise to follow all the directions, but I'll do some modifications in Luda according to your advice.

Thanks!