An example of the cufon breaking is when I add a product to my cart,
example here http://joemeetsjoy.com/products
When you click buy now then click ok on the pop up box the cufon breaks. It also happens if you go the the shopping cart and choose a shipping option.
Any ideas why this happens?
I ran a Cufon.refresh() call, which restored the Cufon (running Chrome 15 on Mac) after clicking the "Buy Now" button (which did, as you say, "break the Cufon").
You may want to consider altering the behavior of the onClick handler of that button to run this function. A DOM update or reflow might be causing the Cufon to break as I noticed the onClick handler makes an AJAX call.
Related
we are developing with fullcalendar and try to activate the print option for our customer. We use the latest version of fullcalendar and we use event urls to open a lightbox / fancybox after clicking on an event.
But, when it comes to the print view, and to printing for example a week, all the event urls are shown within the events. We really tried everything so far, to hide them from the print view, no success.
ajax_envent
I try to attach a photo. Any ideas or solutions on this?
Kind regards
Mike
Background: for Windows users on Chrome and IE, dropdowns that reload or change the page are no good for accessibility. As soon as a user presses the down arrow button, the page reloads. This means that the user can only access the very first menu option. Here is an example: http://html.cita.illinois.edu/script/onchange/onchange-example.php
This is covered in the WCAG rule:
“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”
EXCEPT the user can very easily open up the dropdown and explore all the options without triggering an onchange event. The user does this with a space bar press. This is a very commonly known keyboard trick that I've seen all tested users to already be aware of or be able to figure out quickly.
In my system, we are using a dropdown for pagination in long directories.
EG: "you are on page [1^] of 16" (with the [1^] being a browser default dropdown menu). The designers will not allow any kind of visual [go] button. This happens across thousands of pages, javascript fixes I've seen need to account for every dropdown, and this is impossible on our case.
Using space bar, the user can see all the options and make a selection from anywhere on the list using only the keyboard. So why are dropdown page menus that automatically reload onchange still considered inaccessible? And would they be considered accessible if we included screen-reader only text which said "press space bar to open this menu, making a selection will load your next page"
Well except that in Firefox, the keyboard command is actually F4, you are correct - this is not a WCAG 2 violation but rather a best practice
Here is a page where you can test this: http://dylanb.github.io/onchange_select.html
I added a button to a toolbar and when I run the application, it is grayed (desactivated) I could not click on it. I tried to add events when I click on it, but still gray.
How could I make it active?
Make sure there's a handler for the button. MFC will automatically disable a button if there's no ON_COMMAND handler for it.
Otherwise you need to implement ON_UPDATE_COMMAND_UI to enable the button.
Ok it works now, I had to add the ID into tha Accelerator table, weired but it worked at least.
I nailed down a weird behavior on JQM.
Since the page is based on JQM Boiler plate, I do not include the full page here. I published the code on jsfiddle.
Here is a summary of the behavior click actions:
Here is the extract of the relevant code:
<div id="oneapart"
data-add-back-btn="true"
data-back-btn-text="List"
data-role="page"
data-title="Home page">
I do not understand why the last click on the List button (a jquery mobile back button) requires 2 click to actually act on the link. In fact, the weird behavior is that a first click highlight the button in blue, but it remains as is without switching to the previous page until a second click happens.
Any help will be appreciated.
Regards.
This issue can be fixed by adding the data-rel="back" to the button in the popup.
The issue posted on Github has been marked as resolved because of that.
The issue happens because data-rel="back" is missing in the link of the large cancel button in #jerone his fiddle. See "Closing dialogs" here: http://jquerymobile.com/test/docs/pages/dialog/index.html
The back button on pageTwo is dynamically created. When you don't use data-rel="back" on the link that brings you back from dialogThree (which is also a page) to pageTwo it adds an item to the history stack. That's why the back button on pageTwo then requires two clicks to actually bring you back to pageOne.
The active state is removed from a (back) button on the pagehide event. On the first click you stay on the same page, so this event doesn't fire and the button keeps the active state.
I added data-rel="back" and then everything works as expected: http://jsfiddle.net/jEesE/6/
Closing as resolved.
The bug you're describing consists of 2 parts;
why does it require two clicks to revert?
why stays the button active (blue)?
The first part of the bug is not a bug; you open a popup, but instead of going back (e.g. data-rel='back' you open a page that is the same as the previous one. So if you press the back button, it reopens the previous page that is actually the same page as you were on right now (if it make sense).
Why the button stays active, I don't know...
EDIT: I cleaned up your code a bit: http://jsfiddle.net/jerone/jEesE/3/
i am using icefaces 1.8.2. For some command buttons, sometimes i need to click the button twice. previously whole applivcation was working fine with single click. after upgrade to 1.8.2,i am facing this problem......Any suggestion,what could be the reason???
Thanks
Maybe some component loses the focus when you click the button. That could cause a partialSubmit and the server sends an update. This update replaces the part of your page containing the button.
But that a total wild guess into the blue.