https://markodenic.com/css-tips/
https://markodenic.com/javascript-tips/
Happy coding!
131–136 of 136 posts
https://markodenic.com/css-tips/
https://markodenic.com/javascript-tips/
Happy coding!
Earlier quoted context omitted.
drag and drop rearrangeable lists as a form element!
Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost in time and ongoing overhead in time & bugs for everydamnthing else added to the UI after. I've seen business-side people favor terrible products because they have drag-n-drop, while a better alternative doesn't. They love it. It's heavy-weight, fragil…
This just made me laugh because it is so true. I thought it was just my stupid luck that I keep working with companies obsessed with drag and drop. But you are right. I have seen companies blow hundreds of thousands of dollars implementing drag and drop on a trivial feature. The same company will then complain about spending a few thousand dollars implementing a security feature or implementing training programs to teach employees about the importance of securely handling PII.
Edit: PII = Personal Identifiable Information (social security numbers, credit cards, birthdates, etc).
Earlier quoted context omitted.
Drag and drop is not actually very usable. It's nice to have it as an option, but the main approach to rearrangeable lists should just be a list widget w/ selectable items and [↑] [↓] buttons to shift the currently-selected entry upwards or downwards.
I strongly disagree. It’s the most natural thing in the world for GUI/mouse users to drag-n-drop objects. It’s even nice for touch with the right OS/hardware support.
You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use.
But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for them or might not work at all. It might be INTUITIVE on what the user is supposed to do, but it isn't USABLE. We have all encountered non-usable interfaces that we simply can not interact with for various reasons. This also becomes a concern for accessibility. A screen reader may not be able to read it to someone who is blind. An older device might not be able to display or operate the drag-able functionality. A user that relies on something like "Voice Control" may not be able to use your drag-and-drop system.
Ideally you would do both. You could show an interface that has up and down arrows for each item to move items manually. But also make those elements drag-able if users choose that option. But this takes more and more development time. That is the constant battle between software engineers and decision makers. Anything is possible with enough development time, but decision makers are quick to move developers along when the item is "good enough", which generally means the feature works on the decision-maker's devices.
Earlier quoted context omitted.
> Form validation should be built-in Have you used pattern attributes? https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
and the :invalid css option (I like to just make the bottom border red, dashed)
Earlier quoted context omitted.
I strongly disagree. It’s the most natural thing in the world for GUI/mouse users to drag-n-drop objects. It’s even nice for touch with the right OS/hardware support.
You are confusing "usable" with "intuitive". You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use. But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for th…
Very first tip: "Performance tip. You can use the loading=lazy attribute to defer the loading of the image until the user scrolls to them." Can someone explain to me when this is useful? As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling. As a content creator I understand the idea that I might potentially save the consumer some bandwidth, given they might - against al…
It's more about saving bandwidth on the server side, plus it allows for tracking without using JS.
Chrome seemed to behave this way as well when I tested it a while ago. It's covered in the spec: https://html.spec.whatwg.org/multipage/urls-and-fetching.htm...