Alert dismissal change

[EricWarnke]

Changed the alert dismissal from remove() to hide(). It's kind of wonky if one wants to show that alert again and it's completely missing from the DOM.

[nkryptic]

Perhaps this might be better as an option you can set with something like $.fn.alert.defaults and/or another data- attribute?

[fat]

If you want to just hide it when a user clicks the close button... just add an event handler and handle that:

$('#myAlert .close').on('click', function () {
  $('#myAlert').hide()
})

[EricWarnke]

My problem is that the default action is counterintuitive. Close
should not mean remove.

On Feb 8, 2012, at 23:58, Jacob Thornton
reply@reply.github.com
wrote:

If you want to just hide it when a user clicks the close button... just add an event handler and handle that:

$('#myAlert .close').on('click', function () {
 $('myAlert').hide()
})

---

Reply to this email directly or view it on GitHub:
#1845 (comment)

[dittore]

Spend few minutes wondering why I can't show my alert again after dismissing it...this might explain it.
So dismiss == remove and not hide ?

I agree with EricWarnke, this is stupid behavior and should be changed to hide instead.

[gonzalocasas]

Same here, spent several minutes trying to get what was happening. Could this be changed to hide by default? Isn't it what most people would expect...?

[raad]

Yep - I hit this too. Can't see why removing should be preferable to hiding - it's no faster or easier and it's less flexible.

+1 for hiding

[osuritz]

+1 for hiding... maybe the following to remove it (so non breaking change)

data-dismiss="alert"

and the following to hide:

data-hide="alert"

[dondi]

+1 for adding the option to hide. This will support reusable alerts without encoding them in JavaScript. I know it can be done in other ways, but less code will be used, and a similar design will be maintained, if the option to hide is available.

Two tweak the comment above, presumably we will want the same data property name, so I would revise the suggestion to:

data-dismiss="alert"

for the current behavior (removing the element upon dismissal), and:

data-dismiss="alert-hidden"

to hide the element but retain it in the DOM tree.

[bramski]

+1 for hide. I have a lot of resuable alerts in my code and this is adding a lot of bloat. I would agree with osuritz, for "data-hide" to not break existing behavior.

[ecairol]

I had this same problem, but the solution for it is pretty simple: just remove the attribute "data-dismiss" from the button.

<button type="button" class="close">×</button>

Then, as mentioned above, just bind the click function to a hide behavior>

$('.alert .close').on('click', function () {
  $(this).parent().hide();
})

[migueldiab]

+1 for hide... It is indeed counter intuitive. Also the function should be changed from

function removeElement() {

to

function hideElement() {

Why would you have a 1 in a lifetime alert? Most likely this alert can happen again or even better, reuse the same component for different alerts.

[tgirardi]

+1 for:

data-hide="alert"

[DR9885]

+1 for:

data-hide="alert"

[brikou]

👍

[terrapass]

I agree with the pull request author: this is extremely counterintuitive.

What's the point in deleting the alert from DOM altogether, when it can (and quite probably has to) be reused?

[ArturKwiatkowski]

👍

[jpaas]

+1

[navarr]

+1 for data-dismiss="alert" hiding. This is how Modals work and it's nonsensical that alerts do something completely different with the same button and attribute.

One of our interns this summer thought to work around it by doing $('.close').on('click', function() { $(this).parent().hide(); }); which, of course, caused other problems down the line.

This pull request was made two years ago and has tonnes of comments.

[guillaumevincent]

everything has been said
+1 for this pull request

[cvrebert]

FYI: This change cannot be made until Bootstrap v4 anyway, due to SemVer backwards-compatibility constraints.

[navarr]

This isn't code code for it, anyway. The function removeElement() probably shouldn't simply hide the element.

[fat]

there are a handful of better ways to handle to this problem.

If you don't want to use "hide" yourself, you should just store a reference to the alert - we don't kill that.

Here's a simple example: http://jsbin.com/sodunowuho/1/

[twbs-lmvtfy]

Hi @fat!

You appear to have posted a live example (http://jsbin.com/sodunowuho/1/edit), which is always a good first step. However, according to Bootlint, your example has some Bootstrap usage errors, which might potentially be causing your issue:

• W002: <head> is missing X-UA-Compatible <meta> tag that disables old IE compatibility modes
• W003: <head> is missing viewport <meta> tag that enables responsiveness
• line 11, column 3: W007: Found one or more <button>s missing a type attribute.

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[fat]

good looking out twbs-bot

[navarr]

@fat While that works, it just doesn't make sense that bootstrap is removing an element from the DOM. I'm impressed that this is being revisited three years later, but nobody has stated why removing the object from the dom is the preferable solution to hiding it.

I feel like most people (in fact, everyone prior that had commented on this issue) agree that hiding should be the default, with removing from dom available either through bootstrap options or dev intervention.

It's the difference between having to intercept default functionality and change it, and having to listen for default functionality and perform additional functionality.

[kkirsche]

Personally I don't mind the removal and never have. Rather than a default behavior change I'd rather just see a hide or remove option so it decides what to do based on what you tell it.

[mdo]

Few thoughts on it:

• Keeping alerts around dirties the DOM. Keep that stuff lean and clean whenever possible.
• Dismissable alerts are removed by users, so they've acknowledged (or ignored lol) the alert and want it gone. Theoretically, there's no more need for that alert.
• Removing the alert programmatically should likely happen after some kind of validation event. Have some form error states? Check on keystroke and remove it. No need for it after that either.
• Hiding means you're showing the same thing to users again. Something about that tells me you might want to revisit something that's prompting a user with the same exact alert.

That's coming from someone who's not writing much JS mind you, but look at it from a user experience and designer point of view.

[navarr]

@mdo An immediate thought is a warning or info level alert caused by JavaScript. The user does something wrong, you show an alert. They click the X, they do the same thing, and .. suddenly there's no alert to re-show.

It is not the CSS framework's job to keep the DOM clean. Only to render it as the code says, is my opinion, personally.

[osuritz]

Yeah my similar use case was imagine a delete button for a record. That button is associated with a modal to confirm the deletion. Use dismisses (thus canceling the delete operation). Now if they click the same delete button, the same dialog should presented.

On Tue, Jun 9, 2015 at 7:55 PM, Navarr Barnier notifications@github.com
wrote:

@mdo An immediate thought is a warning or info level alert caused by JavaScript. The user does something wrong, you show an alert. They click the X, they do the same thing, and .. suddenly there's no alert to re-show.

It is not the CSS framework's job to keep the DOM clean. Only to render it as the code says, is my opinion, personally.

Reply to this email directly or view it on GitHub:
#1845 (comment)

[patrickhlauke]

@navarr

It is not the CSS framework's job to keep the DOM clean

However, Bootstrap is more than just a CSS framework, as clearly the issue you're having here is how Bootstrap's JavaScript components behave.