51–60 of 414 posts
I've been "sanding" my personal website ( https://dustinbrett.com ) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed. On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song. When you consider the scale of these apps, the…
Reading this on Safari on my iPad, the favicon for this tab is the Youtube logo. I genuinely have no idea how this bug came about, but it's been like that for months now.
I've been "sanding" my personal website ( https://dustinbrett.com ) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
This attention to detail is what separates the mediocre frontend devs from the rest. How the heck do I improve our hiring process so we get more of you!!!
I think the article has good sentiments about it. Actually using your application a lot helps polish it down a ton. However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.
> However, wouldn't putting the input inside of the label (before the label text) be a better solution The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue. This might actually be a good thing for some desi…
> on mobile it might lead to miss-clicks while trying to scroll past the s
You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
It’s where much of the beauty and craft of something is developed. It requires a craftsperson to not just “call it done and move on”, but instead to be intrinsically motivated to spend time with the creation intimately, rolling it around in your hands/brain. Guiding a vine here and there, plucking a leaf or two… until it ‘feels’ right.
On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed. On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song. When you consider the scale of these apps, the…
I believe that the iPad behavior you describe is intentional. I’m not sure I’m right here, and there are tradeoffs. I get frustrated with it too. But I think Apple is going for clarity, lack of ambiguity. If your text remained in place but the control were not focused, what would that control then indicate? In Safari now it _always_ indicates (a) the current page, or (b) your current typing. To do otherwise would be…
You can show the current state when not in focus and show the edit state when in focus.
Or view it from the angle of the input. Show the current state or edited, but the input device could be smart enough to auto-fill a field if you click off and click back onto it within a short time period.