[jacky]does anyone here play games on https://itch.io? I've been wanting to make something like bridgy for syncing game play info to one's site. It'll be easier via Itch versus Steam
reed, calebjasik, Abhas[m], batkin[m], nekr0z, gRegor, moose3333, doosboox8, rhiaro_, sknebel_, wagle_, deeden, sebbu, petermolnar, Kaja, Zegnat, capjamesg, hendursa1 and james joined the channel
capjamesgNow the button does not show up in Lynx, which is expected because it will only work with JS (otherwise, the button will not display on the user's page.
[Murray]Oh interesting. I assume Lynx just falls back to _showing_ the hidden text? Does Lynx have any dynamic states (CSS animations, hover states etc.)? (I've never seen the point of Lynx, so never used it)
Loqi[Murray]: capjamesg left you a message 1 hour, 27 minutes ago: The <details> element does not play so nicely with Lynx. But then again, neither did the JS button.
[Murray]!tell capjamesg Looks good to me. You'll want to add the `type` attribute with a value of `button` to that i.e. `element.setAttribute("type", "button");` Otherwise, I imagine that the `#interview_button` element is just an empty `<div>` or something? If so, seems good to me 🙂
Loqicapjamesg: [Murray] left you a message 8 minutes ago: Looks good to me. You'll want to add the `type` attribute with a value of `button` to that i.e. `element.setAttribute("type", "button");` Otherwise, I imagine that the `#interview_button` element is just an empty `<div>` or something? If so, seems good to me 🙂
capjamesgDefinitely very useful and they even talk about buttons that they have as semantic <a> tags for starting a form (where, as I have learned, a <button> tag would not be appropriate since no form action is being taken).
ZegnatA button element, by default (if nothing set) has the type "submit". If your button is not submitting a form, it is better to set it to type="button". This means browsers still treat it as a button, but will know it does not need to find form actions to associate with it.
ZegnatHope that makes sense :) In general people add buttons only to submit forms, so that makes sense as a default. For JavaScript created buttons that trigger a custom action, set type="button" manually.
Zegnat(The only other available type apart from "submit" and "button" is "reset", for clearing form fields within the some form as the button element.)
[Murray]and I can thoroughly recommend everything the GovUK team have done around accessibility and user experience; their blog posts are a gold mine of usual information and genuine user research
[Murray]given the new script you're using, I was tempted to say that it could just generate an `<a>` now but honestly, I think this is a rare case where both have some purpose
ZegnatI think you can easily make cases for both button and a elements. And I am not sure the distinction really matters here. I think my personal preference would actually be the a-element. Because it triggers a navigation event, and browsers can show me where an a-element takes me, I can opt to open it in a new tab, etc. Lots of browser functionality you are not getting from buttons.
ZegnatOh, yeah, they are specifically turning a link into a button there. I am not sure why you would want that? If you are going to such lengths, just use a button element
LoqiIt looks like we don't have a page for "more appropriate: link or button" yet. Would you like to create it? (Or just say "more appropriate: link or button is ____", a sentence describing the term)
ZegnatI think that question can only be answered from the UX point of view. Do you want the user to feel like they have pressed a button to trigger an action, or do you want them to navigate to a different page like a link.
ZegnatSure, but the semantics do not really matter for a user. Not really. And you can always patch up semantics with things like the role attribute (like what Gov UK is doing in the example you linked)
ZegnatSo what is the experience you want to create for the users. Because browsers will offer different options depending on whether you go with a button or a element.
ZegnatI personally really prefer normal links for navigational actions. Specifically because my browser stays in control of the navigation between pages. So I would just offer a completely normal a element.
ZegnatBut I am also not a fan of surprises, so I realise the random button is not really aimed at me in the first place. I would probably have done it more like this: https://gist.github.com/Zegnat/ec461133a38801fe10d8242090f0a61b (you can run that directly in the browser console on the interviews page)
ZegnatBut for navigation on blogs and similar text media, I always come back to a keep-it-simple approach of anchor tags and clear signaling to users what will happen when they interact with it
capjamesgThe button sort of sticks out in that it's not part of the logical flow of the page (there is no section specifically for the button, no title, no obvious progression between the text above and the button). A statement like "looking for a place to start?" solves this.
ZegnatThe beauty of a personal website is that you can put any button on there that you like ;) Make it sparkle and jump all over the place if that is more your fancy
capjamesgFor sure. I think adding a random article to the list itself might be a bit odd in terms of the flow of the page but having one with a designated message before hand ("looking for a place to start?" or "new to my interviews? check out ...") is interesting.
Zegnatyeah, that is definitely another interesting one. But there is actually a secondary actoin taken on a form field (the search field) so a button makes sense. It also cannot really give you the browser UI of a link, because the link is not yet known.
[Murray]Just to take it back to the semantics question: the best rule of thumb (as Zegnat hinted at) is to think about the action being taken. If you're navigating to a new page, use a link (`<a>`). If you're triggering any other kind of action, use a button. Style doesn't really matter (plenty of links look like buttons, plenty of buttons look like links; CSS/style is a different concern to semantics or functionality).
[Murray]Now you have an interesting grey area, because the action is to first run a JS script that picks a random page, *and then* navigate to that page. You're doing both things, which is why either option becomes valid.
[Murray]However, if you were to switch your code logic around for a second, I'd say an `<a>` becomes more semantically accurate. Instead of running the randomiser `onclick`, you could randomise the page url when the element is created and added to the DOM. If done that way, the actual element on the page will only ever do one thing: navigate. So I'd prefer an `<a>`. If you leave the randomising until the user clicks on the element, then I'd
jamietannaI find 7 days is quite good for apps that don't support refresh tokens (as they're still not implemented widespread) but I'm planning on reducing the lifetime of tokens for clients that do get refresh tokens to be ~1 hour, to limit the risk of those tokens being leaked
jamietannaFor the case where we want infinite access, I'd prefer to have a "personal access token" style token that i.e GitHub allows, as a user-driven thing that can issue a token, which can then be included in i.e. some config file
ZegnatI wonder if 1 hour might be too short. I know of a handful of APIs with such shortlived tokens that people basically do not bother with them and always use the refresh token first for every request. At that point I am not sure it still gives any real security benefit?
ZegnatChicken and egg. I do not think there is a huge problem with servers finding a common ground on how to handle refresh tokens (issueing etc) first
[jacky] does anyone here play games on https://itch.io? I've been wanting to make something like bridgy for syncing game play info to one's site. It'll be easier via Itch versus Steam
capjamesg I wanted to continue the discussion re: progressive enhancement. I have only just had the chance to make the change I wanted to make to my blog (not live yet). I now have a script tag which contains this text: https://gist.github.com/capjamesg/36f862b5bcd9bc1607497fc73dfa0e5a
Loqi capjamesg: [Murray] left you a message 8 minutes ago: Looks good to me. You'll want to add the `type` attribute with a value of `button` to that i.e. `element.setAttribute("type", "button");` Otherwise, I imagine that the `#interview_button` element is just an empty `<div>` or something? If so, seems good to me 🙂
[Murray] Their design system is one of my go-to resources these days as well: https://design-system.service.gov.uk/components/details/
Zegnat I think you can easily make cases for both button and a elements. And I am not sure the distinction really matters here. I think my personal preference would actually be the a-element. Because it triggers a navigation event, and browsers can show me where an a-element takes me, I can opt to open it in a new tab, etc. Lots of browser functionality you are not getting from buttons.
jamietanna Back to the token expiry chat yesterday barnaby, GWG, Zegnat and sknebel
sparseMatrix 0/