everdimension

8 ms·

1.
by everdimension 2mo ago
Yeah well I don't recommend your advice You're confusing utility CSS concepts with accidental tailwind quirks
2.
by everdimension 8mo ago
They've been blurring a lot lately
3.
by everdimension 2y ago
Come on, it's about replacements. They're easier to express (meaning literally easier to type out) with the author's syntax Great project
4.
by everdimension 2y ago
Title sounds like a dream, but I don't really see it happening yet. I honestly think you have to be retarded to put a touchscreen into a car. But they don't seem to be making less of those
5.
by everdimension 2y ago
While I mostly share the same opinion and tend to agree with your conclusion, strictly speaking your observations do not prove that the original doctors were wrong. One could argue that the "poorer" dentist offices are like that p
6.
by everdimension 2y ago
I addressed this elsewhere in the comment section, but there's not much "react" going on in the article. I do think that JSX is very expressive and the concern I cover mostly involves the declarative "component" mod
7.
by everdimension 2y ago
totally And if they fix it, it'll be fixed for everyone
8.
by everdimension 2y ago
Thanks, that's quite interesting and insightful! Thank you for sharing The fact that something provided by the browser can fail accessibility requirements is definitely ironic. We're always taught that the motivation to "use
9.
by everdimension 2y ago
Yeah this is exactly what I'm writing about in the article :)
10.
by everdimension 2y ago
> This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be. In a way, yes. I do think there's a lot to improve from the browsers' side. I guess what I'm tryin
11.
by everdimension 2y ago
I totally understand this. Having DOM elements as an entry to some API isn't the best thing. But firstly, I would consider what you're missing when you abandon native validation * On submit, the first field that needs attention ge
12.
by everdimension 2y ago
That's great advice! I also dislike the "character rejection" mechanisms, even though many people love it and products often ask to implement it. To add to the possible solutions mentioned in your article, I'd add the &q
13.
by everdimension 2y ago
That's weird! Have you tried submitting the forms in the examples? The custom messages are supposed to be shown in the native browser validation tooltips. The support for those is quite good! Even on mobile browsers
14.
by everdimension 2y ago
The HTML is created using JSX, that's true. But the validation that the browser performs is part of the HTML behavior.
15.
by everdimension 2y ago
The API I'm proposing would indeed bring much more benefit when used in a declarative way. That's the point I'm specifically trying to convey in the article. I don't think I understand how it would be "worse" f
16.
by everdimension 2y ago
Yeah, I am aware! Thank you for the concern :) I did address this in an adjacent comment, but I'll say again that I did contemplate over using JSX or not. Also yes, it may have been a good idea to add a disclaimer for the fact that the
17.
by everdimension 2y ago
It's definitely true that many developers would benefit a lot from learning more about the basic HTML and the web platform. But I refuse to support the notion that this is somehow React's fault. In my personal experience, react al
18.
by everdimension 2y ago
Sorry to disappoint, I did hesitate over this. But JSX is honestly very nice to read and also I didn't want to leave the impression that opting in to native form validation somehow forces you to not use javascript. And combination of j
19.
by everdimension 2y ago
Yeah well I promise it does read nicely when there's formatting which HN comments do not allow :)
20.
by everdimension 2y ago
That's exactly the case where the "customValidity" attribute shines! I have nothing against regex and the "pattern" attribute is the way to go for many cases, but having this is an alternative is also very nice: con
21.
by everdimension 2y ago
> Even in jsx its not required to add a boolean value Absolutely true! But I like to do it because I personally think it reads more nicely and is more explicit and that's what I do in all my projects. But it is indeed a matter of ta
22.
by everdimension 2y ago
Couldn't have said it better!
23.
by everdimension 2y ago
Great answer, exactly! Client-side validation isn't meant to remove the need for the server-side checks
24.
by everdimension 2y ago
> there's an enormous amount of other validation scenarios they don't cover Can you provide examples of those? Genuinely interested as I'm on a quest of creating a list of recipes that show that native form validation can
25.
by everdimension 2y ago
That's totally true! Invalid states shouldn't be shown sooner than necessary It's just that for the demos in the article it makes sense to show invalid states as soon as possible, but for a nicer UX in real apps you need to t
26.
by everdimension 2y ago
You usually create debounced inputs for that. This is similar to the autosuggest and typeahead inputs and comboboxes: sending requests to the server in response to an input change isn't something unusual
27.
by everdimension 2y ago
I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want. The problem is that it's quite tricky to c
28.
by everdimension 2y ago
It does suck, but I think not for the reasons you mention. I truly believe a nicer API would motivate developers to use it, and if native validations satisfy the product requirement, their styling does become a lesser concern. But surely st
29.
by everdimension 2y ago
That's actually a good argument for the point I was trying to make. Existing validity attributes such as "pattern" are cool, but not enough. E.g. the "repeat password" example is actually achievable without "se
30.
by everdimension 3y ago
Completely agree with "give people a better office" and completely disagree on what a good office is. But instead of arguing on details, I want to say that as always, people are different. Sometimes polarly different. I love an op

More ›