Is there a way to listen to layout engine events ? , something like "finished_rendering_element" or something of that sort ? , i.e. : i want to be informed when a div with an id of "mydiv" has been rendered ? i could do that by including a settimout in the top of the page and testing the dom and execute approximately at the time it is avaliable but i was wondering if there is a better way ?
I am not aware of any JavaScript interfaces or events on this level being exposed by any browser.
And probably rightly so: I can hardly think of scenarios where such fine-grained event control would make real-world sense.
It is possible to place <script> tags after an element:
<a id="my_link">Link</a>
<script>....</script>
you can safely assume that the a element is available to you in the script.
Other than that, you are left with the DOMReady and load events.
Related
I'm building a component that uses an <iframe> to display another component. This component connects to an NGXS state which needs to reflect changes made to the state. After a lot of failures and testing I discovered the component will always only load the default settings of the state. I created a <button> to toggle a boolean and added an *ngIf to the <iframe> so I can force it to reload manually after trying things like this.Frame.(contentDocument || contentWindow).location.reload(true); didn't make any difference.
I created a stablitz app to demonstrate this issue however I think stackblitz blocks the use of <iframe>s in their platform so you might need to copy it into a local project to tinker with it. It's a simple app that shows the state outside of the <iframe> as well as inside with a button that toggles the <iframe> on and off so you can see how only the default values load after you update the value I have available for demonstration purposes. I'm not getting any type of errors and the issue isn't a matter of something being wrong with the code so I don't know what more to show that isn't in the stackblitz.
Does anybody know why and how <iframe>s do this and if there's a way around it? The only thing I can think to try is make a NestJS app to see if putting the data outside the app and making an API request from the component inside the <iframe> will be allowed, however I don't know why this issue is occurring to in turn know if that too won't be rejected for that same reason. How this can be handled?
The document running in an iframe is isolated from its host. They do not share memory- Angular does not provide a way to synchronize state between a host and an iframe on the page out of the box. The example is actually booting two Angular apps (one inside the frame and one outside). If you are using an iframe for security and isolation purposes, you'll need to devise a way to pass state between the host and the child via postMessage (and be aware that you are running two copies of your application). If this isn't for security/isolation, simply do not use an iframe to contain the child component.
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
How to handle History stacks while working with SPA based web applications? I can have my custom stack to track the pages visited, but since I'm just hiding/showing divs , and manipulating the 'history' object requires to push in URLs, I'm unable to understand how to go about handling the situation?
The URL will always remaining something like this : http://mywebapplication/#
I can't push any URLs into the history stack because for all divs being shown, the URL remains the same. Even if I'm somehow able to achieve the same, I don't think overriding the back button of browser should be considered a good practice?
Please suggest how to handle this situation.
In order to track your browsed divs you need some sort of routing solution. You can use Crossroads to register and manage your routes. Each route should have a handler, which enables the appropriate div in your single page.
var route1 = crossroads.addRoute('/page1/', function(id){
//enable div for page1 route
});
Then, you can use Hasher to manage browser history.
I tried using Window's ButtonDown event as well as Grid's ButtonDown (all window elements are inside this grid). However, these events never seem to fire.
Where, logically, should the code for handling button down events (as to implement hotkeys) be in a WinRT application?
I thought someone recently blogged about this, but I can't find the post right now. You can check these articles though: MSDN link, link.
Basically you would handle Window.Current.CoreWindow.KeyDown/Up, store the current state of the modifier keys (Ctrl, Alt, Shift) and respond to combinations to handle them. Then you should also specify accessibility and help strings like these on your controls:
ToolTipService.ToolTip="Shortcut key: Ctrl+P"
AutomationProperties.AcceleratorKey="Control P"
This is more of a best practices question rater than something technical.
I'm working on a mobile app using the Flex 4.5 SDK and I'm trying to figure out the best way to handle notification windows. In most cases these windows will be alerting the user to when something goes wrong. Ex: bad login, no data, cannot resolve server.
I'm using a singleton design pattern, I have a Requests class that handles server calls. Most popups will be originating from this class (IOErrorEvents from my loader being used to access the API). Since this class is a singleton and is used from all Views inside the app it is not aware of applications current view. I'm also not sure having this class keep track of the current view and having it push popups on top of it would be best practice.
I'm hoping that I can use PopUpManager to keep track of where to add popups and what popups are currently on the stage. Though all examples I've seen online about this show static Components being used in a views Declarations tag.
I'm really just looking for any examples or input on how you would solve this problem. Any help would be greatly appreciated!
I had the same problem, and sorted it by making an Alert popup component that you can call from anywhere in the code base, and it will pop up in the currently active window. It also has an always visible scrollbar text area which is handy
http://bbishop.org/blog/?p=502
It works for a view navigator application, but if your using a tabbed navigator application, you can add a call for that, or simply change the code to
mainTabbedNavigator = FlexGlobals.topLevelApplication.tabbedNavigator;
currentTab = mainTabbedNavigator.selectedNavigator as ViewNavigator;