Add a "disabled" parameter for <<button>> and similar macros

[HiEv]

It would be nice to have a "disabled" parameter for <<button>> and similar macros which look different when disabled, especially if they have a transition time.

Currently, if you add a <<button>> to a passage which is already visible, there is no way to have it default to disabled, so you then have to disable it using jQuery, which causes it to "flash" due to the button's "transition" CSS, as it transitions from the non-disabled style to the disabled style.

It would be nice if this and any similar macros with noticeable transitions like that could be displayed in an initially disabled state by adding a "disabled" parameter to them. Such as:

<<button "Button Text" disabled>><</button>>

The documentation should probably also mention how to later enable such elements.

[tmedwards]

It would be nice to have a "disabled" parameter for <<button>> and similar macros which look different when disabled, especially if they have a transition time.

I'm not against the idea in general, however, we're talking about fifteen macros just from the standard library, some of which already have fairly a congested argument space.

Currently, if you add a <<button>> to a passage which is already visible, there is no way to have it default to disabled, so you then have to disable it using jQuery, which causes it to "flash" due to the button's "transition" CSS, as it transitions from the non-disabled style to the disabled style.

Do you have an example? I cannot replicate what you're seeing via (a) using :passagerender† to affect buttons that have already been rendered or (b) by running the code after injecting buttons into a displayed passage.

† The :passagerender event is what you should be using if you're attempting something like this, as everything else happens too late—far too late in the case of things like timeouts.

Examples of what I tried

(a)

@@#btn-group;
<<button "">><</button>>
<<button "1">><</button>>
<<button "2">><</button>>
<<button "3">><</button>>
<<button "4">><</button>>
<<button "5">><</button>>
<<button "6">><</button>>
<<button "7">><</button>>
<<button "8">><</button>>
<<button "9">><</button>>
@@

Lorem ipsum dolor sit amet, […]

<<script>>
$(document).one(':passagerender', function (ev) {
    $(ev.content).find("#btn-group button").ariaDisabled(true);
});
<</script>>

(b)

@@#btn-group;
@@

Lorem ipsum dolor sit amet, […]

<<link "Add Disabled Buttons">>
    <<replace "#btn-group">>
        <<button "">><</button>>
        <<button "1">><</button>>
        <<button "2">><</button>>
        <<button "3">><</button>>
        <<button "4">><</button>>
        <<button "5">><</button>>
        <<button "6">><</button>>
        <<button "7">><</button>>
        <<button "8">><</button>>
        <<button "9">><</button>>
    <</replace>>
    <<run $("#btn-group button").ariaDisabled(true)>>
<</link>>

[ChapelR]

You could create a macro that you wrap an input or element in that disables it. Not a super pretty solution but it'd work, e.g.

<<disable>> 
    <<button "I'm Disabled">><</button>> 
<</disable>> 

Just as an idea to solve the problem of adding such an argument to every macro that can be disabled.

[HiEv]

I had a sample, but I tried a whole bunch of variations to see if I could make it work, and it turned out that if I immediately disabled it after creation it was fine. But even putting a single other jQuery statement in-between creating it and disabling it, and then I'd see the flash.

So, yeah. It looks like the "flash" is preventable, but it's very sensitive.

If you want to close this, it's up to you. However, Chapel's idea isn't bad, if you could get it to work. Though, I'd add an optional conditional parameter to the <<disable>> macro, and if that parameter was there then the contained element(s) would only be disabled if the conditional parameter had a "truthy" value. That way you could control it with a variable.

Alternately, to deal with a "congested argument space", you might want to consider doing what I did with my <<textboxPlus>> widget, with an object for optional parameters.

Anyways, thanks for looking into it. :smile:

[Uzume]

I think this is a valid feature request and should be kept open. It might be applicable to move it to v3 if @tmedwards thinks he cannot get to it before that (and no one else steps up to do the work in v2).

[ChapelR]

I forgot about this. I can create a custom <<disable>> macro in the short term.

[ChapelR]

I added this in v2.7.0 of my custom macro collection for anyone interested.