Button types

@adactio someone needs to dare me to make a web component for all these 😅(Ps. Typo for “interfa es” on the 4th paragraph, after the quote)

@DavidDarnes @adactio do we need to dare you? You seem to be doing just fine on your own 😉

@adactio I would love a “Find” functionality that triggers the browsers on-page find functionality

@adactio <button type=“cookies-accept”><button type=“cookies-decline”>

Having a standard like that would mean it’s trivial for browsers to auto accept or decline.

@adactio cc @stubbornella

@adactio it’s funny because I’m usually going on about more complex controls (tabs pls) but more semantic buttons would be most welcome

@brianleroux @adactio I’ve wondered about something like “buy” or “add to cart” too

@brianleroux @adactio which then naturally leads to <product>

I’m not sure it all makes sense though

@stubbornella @adactio I’m here for it. Personally think we fully maxed out the imperative side and much low hanging declarative fruit exists. CSS feels like it’s leapfrogging rn

@adactio Any JS API that requires a user activation!

Far better to have a button JS can try to `.click()` than vendors having to figure out which which user gestures are allowed to transiently/stickily activate a delegated browsing context’s capability to request for permission with some bespoke permission UI during the next cycle of the event loop/macrotask queue/microtask merry-go-round, because the latest httparchive just dropped and 93% of the new API’s usage was for scamming people.

@brianleroux @adactio certainly trying to make it leapfrog! There is a lot of FUD around having CSS do “too much”. We’ve been fed imperative kool-aid for a long time.

@westbrook @adactio @DavidDarnes we made (and shipped) <clipboard-copy> at GitHub! https://github.com/github/clipboard-copy-element

GitHub - github/clipboard-copy-element: Copy element text content or input values to the clipboard.

@adactio In a perfect world, you could polyfill these with `<button is=”share-button”>` and web components, but WebKit is opposed to extending built-in elements so we can’t have nice things 🙁

@adactio I am also maybe still just a little bit bitter about `<button type=”menu”>` getting promised and then axed from the HTML5 specification

@adactio Media control (play/pause/volume) buttons have been proposed before; not sure why they didn’t happen. A declarative approach would both clarify the user-interaction permissions and allow devices to map their own special keys or gestures to the button action.

I think a `for` attribute (pointing to another element’s ID) should be sufficient for media control, fullscreen, and probably even `copy`. Maybe also `share`, to share an image or text quote instead of, or in addition to, the URL.

@adactio @evert I like these! 🙌

@royalicing @adactio This!!

@royalicing @adactio Except fraudulent sites who steal user data for a living would only implement such buttons if the law required them to. I love the idea, though!

@AmeliaBR @adactio Excellent ideas! 👌🏼 I would love every single one of your suggestions.

@stubbornella @brianleroux @adactio Most things that can be done declaratively, especially with HTML, is objectively better than an imperative alternative.

I’m a proud member of the Anti-JavaScript JavaScript Club and share @slightlyoff’s opinion of imperative having gone too far with modern JS frameworks.

So, I agree: Bring the floodgates down and let the declarative juices flow!

https://anti-javascript-javascript.club

Anti-JavaScript JavaScript Club

@bitbear @stubbornella @adactio @slightlyoff hehehe, yes I too am sporting the sticker to many a raised eyebrow haha

@brianleroux @bitbear @stubbornella @adactio Whoa, who made the site?

@slightlyoff @bitbear @stubbornella @adactio haha I assumed u did

In response to Button types on Adactio, about useful everyday JavaScript APIs which should have a declarative equivalent.

 button type="share" button type="fullscreen" button type="print" button type="bookmark" button type="back" button type="forward" button type="refresh" button type="copy"

I agree with this list. If they are common functionality with buttons that could be included in any web page, by anyone of any ability, why should someone have to reach for JavaScript?

Thinking of these things as native features could help during the standards phase, rather than a vaguer concept in JS.

Now we just need a `what` attribute to declare what content ID will be fullscreened, shared, printed, copied etc.

AdvertisementPrivacy Settingswasmart.cmd.push(function() {sas.render(“sas110354”);});window.stq = window.stq || [];window.stq.push( [‘extra’,{xwordadssmart: ‘rendersas_110354’,},] ); Related

@brianleroux @slightlyoff @bitbear @stubbornella @adactio I wouldn’t let that kerning out of the house.

@brianleroux @adactio I will say, I have some hesitation about spending limited time on things that *don’t do anything*. Ex. Imagine today I had to choose between prioritizing an <accordion> vs <section>. They are both semantic, but only the first one has user interactions and eliminates JS.

@adactio I propose a `<button type=”close”>` to close dialogs, details or any other closeable element

@adactio It feels like such a logical suggestion that doesn’t make me think about -if-. It makes me think about what use cases would be a good match. Open? Expand? Close? Cancel? Deny? Update?

I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).

I wrote about the reason for a share button type as well as creating a polyfill. I also wrote about how this idea would work for other button types: fullscreen, print, copy to clipboard, that sort of thing.

Since then, I’ve been very interested in the idea of “invokers” being pursued by the Open UI group. Rather than extending the type attribute, they’ve been looking at adding a new attribute. Initially it was called invoketarget (so something like button invoketarget="share").

Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.

Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.

The next step is to use command and commandfor for controlling audio and video, as well as some form controls. I very much approve! I love the idea of being able to build and style a fully-featured media player without any JavaScript.

I’m hoping that after that we’ll see the command attribute get expanded to cover JavaScript APIs that require a user interaction. These seem like the ideal candidates:

• button command="share"
• button command="fullscreen"
• button command="print"
• button command="copy"
• button command="install"

There’s also scope for declarative options for navigating the browser’s history stack:

• button command="back"
• button command="forward"
• button command="refresh"

Whatever happens next, I’m very glad to see that so much thinking is being applied to declarative solutions for common interface patterns.