A bit off topic, but on the copying issue with dashes, you can wrap the whole key in a span styled with “user-select: all” to improve the copying experience. Well, on the web at least!
I was just about to post the same link. It is really cool tech and Smack Studio is when I first fell in love with the concept. What Adobe has is cool, but I've seen it already.
In summary, Smack Studio is a fighting game with a character editor that can rotate any 2D pixel art sprite as if it were 3D by extrapolating a depth map. You can export the resulting sprites for use outside of the game.
> 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 designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
Well with the CSS in the post they would end up as wide as their parent. If you made it an inline flex box then yes, that wouldn’t be an issue.
> You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.
A bit off-topic, and maybe it was just an example made without too much thought put into it, but I've noticed there seems to be a lot of people now who write button/links like this:
As far as I know that's technically invalid HTML. You can't have an <a> as a child of a <button> (or even the other way around.) I'm also ignoring the invalid type="submit" against the <a> tag in the example button component in the post.
I think it stems from people who want their links to take on the default button styling, but I'm not 100% sure. Has anyone else noticed this trend at all?
> As far as I know that's technically invalid HTML. You can't have an <a> as a child of a <button> (or even the other way around.) I'm also ignoring the invalid type="submit" against the <a> tag in the example button component in the post.
It definitely feels weird to have anything other than text nodes inside <button>, didn't realize it's actually invalid HTML.
> I used this approach mainly to have the button component behave as a link button and a form submit button.
Personally I think the "proper" way to do this would be use just <a> for links, and <button> for submitting forms, and then have the same CSS styles applied to both so that both <button>'s and <a>'s look the same visually if that's what you're going for.
I'm not particularly familiar with Go, but I'd either make the wrapping tag name itself a template variable (maybe an enum between "Anchor" and "Button"? again not familiar with Go) or have two components one for forms and one for links. If I've understood the syntax, something like this?
<{{.Tag}} class="button-container"></{{.Tag}}>
But given both <button>'s and <a>'s have lots of different attributes to manage its behaviour and state (name/value/type/disabled vs href/rel/target etc) I'd personally split them into two separate components, even if it ends up doubling up some of the logic and styles.
> What are the drawbacks of this approach? I'm pretty sure I've used this before, can't recall any downsides.
As others have mentioned, while it's technically invalid browsers will still happily accept it so there's no real issue with it, personally I just find it a bit quirky to read. There's no harm in leaving it just as it is :)
A button with type "submit" will happily submit the form when you click on it. If you want it to look like a link, use CSS. Putting the submit on the anchor tag is pointless- the lack of a type on the button itself means the browser is inferring the intended behavior and defaulting to type "submit" rather than type "button".
As others have mentioned, the main downside is likely accessibility.
Once the major browser engines support it, it's de-facto legal.
This also explains why there are so few alternative browsers. Writing a new browser that supports everything that happens to work in the major browsers is ridiculously hard.
The big innovation of the html5 spec was to specify how to handle all the “invalid” html states; recovery from user error is now part of the spec instead of wholly implementation specific.
Yes, html is one of the unique languages of our era. It's very forgiving and lenient.
> This also explains why there are so few alternative browsers. Writing a new browser that supports everything that happens to work in the major browsers is ridiculously hard.
IMO one of the reasons Chrome won was because they supported both Firefox and IE's interpretation of web standards.
Yep, the HTML5 spec has an agreed on way to parse and interpret invalid HTML, so all modern browsers should handle it pretty consistently.
I was more interested in finding out where this style had come from really, because I've seen a lot of devs doing something similar and semantically it's just always struck me as a bit odd looking!
I vaguely remember reading about this issue in the past, it’s actually down to the way the software running in the cars radio is using a backwards compatible “iPod” integration. It effectively (against Apple’s recommendations) sends a “play music” signal as soon as you connect your device.
Well behaved radios don’t send that signal immediately, and instead wait for you to hit play on your device, or on your cars radio/stalk.
I think the mention of Steam will be to do with the Steam Link app they released for Meta quest devices fairly recently that lets you stream your VR games from your desktop computer to the quest wirelessly https://help.steampowered.com/en/faqs/view/0E2C-406B-9135-38...
I’m pretty sure macOS does warn you that turning Bluetooth off will disconnect your keyboard/mouse/trackpad, if thats the only input device you’ve got connected.
Not sure when it was introduced but it’s definitely there on the latest version because I bumped into it the other day.
Interesting! If that’s the case, great! But I believe the couple in question is on an older iMac not upgradeable to the latest version of macOS, so they would still be out of luck.
