I'm new to Angular Material and just found out about the md-tabs directive. I was wondering whether there is an easy way to insert a non-md-tab element to sit on the left (or right) of all md-tab elements, but below the tabs header.
Mockup of what I am looking for:
I guess I could just duplicate the markup and insert it into every single tab, but that doesn't seem to be a very practical solution. In any case, just adding a non-md-tab element as first child of md-tabs did not work.
Edit: another solution I thought about would be to manually load tab content based on which element is selected in the header area - I know how to do that - but then I'd lose the smooth transition animation between tabs.
I'd use a directive for that, since you have to include it into your every tab's content. It would simply do the trick.
Or you can use only md-tabs without placing every tab's content into md-tab. Make use of md-selected of md-tabs and activate your html node visibilities in the right way. In this case you can have something on the left, since you'll define the layout.
Related
Issue: I have an accessibility issue that I am struggling with. I have an angular web application. A page loading spinner/indicator is shown when content is loading. And when the page content has loaded the spinner is hidden. This "div" is never removed from DOM.
Content of the loading div are not read (by NVDAor jaws) when the loading div is shown.
<div class='loading' aria-live='polite' aria-label='Do not refresh the page' tabindex="-1">Do not refresh the page</div>
I wouldn't like to change the structure of the application but work around using 'aria tags' to resolve this, just wondering if I will have to do anything more to make aria-live work?
Updated (27/July/2016)
Further clarification: I am not removing the content from DOM but using css to show/hide content (display: none to display: block and vice versa)
aria-live triggers screen readers when an element with aria-live (or text within an element with aria-live) is added or removed from the DOM. In contrast, when you unhide a hidden element, neither elements nor text are added or removed from the DOM, so the element's aria-live property doesn’t come into play.
To get screen readers to announce “Do not refresh the page”, either of these options should do the trick:
You can create the <div class='loading' aria-live='polite'> element and its text content from scratch and then add that element to the DOM.
Or you can start with an empty <div class='loading' aria-live='polite'> element and then populate its text content.
A few other tidbits:
As long as the text inside the element is what you want to be read aloud, you can omit the element’s aria-label='Do not refresh the page' attribute.
For icing on the cake, it can’t hurt to include a role attribute on the div that has aria-live. If you’re not sure which role to use, go with role="status"—that’s a pretty safe bet.
When or if the page is at a state where you no longer need to display "Do not refresh the page”, be sure to reverse the steps above. (That is, if you went with the first option and you added the whole element to the DOM, remove that entire element from the DOM. Or if you went with the second option and you populated the element’s text content, clear out the element’s text content.)
There are several issues with dynamically added or shown/hidden live-region.
Firstly a quote from MDN - ARIA live regions:
Simply including an aria-live attribute or a specialized live region role (such as role="alert") in the initial markup as it's loaded will have no effect.
Dynamically adding an element with an aria-live attribute or specialized role to the document also won't result in any announcement by assistive technologies (as, at that point, the browser/assistive technologies are not aware of the live region yet, so cannot monitor it for changes).
Always make sure that the live region is present in the document first, and only then dynamically add/change any content.
From my personal experience, even if a live regoin exists in the DOM on page load if you use show/hide then NVDA also has a bug which requires a small delay before a text update in a live region after it was shown initially. Apparently because the region didn't exist when the first text was added, so this isn't an "update". Regarding the timeout, you'd need to set it to something greater than the browser's refresh tick. I use 100ms. Disclaimer: I am strongly against such workarounds to make up for the issues with screen readers or browsers but it might be useful for someone in some cases.
I'm using Angular 2 - RC3.
My problem is, I have an item which is shown or hidden using a *ngIf.
When the item is getting shown or hidden I want to apply an animation.
I'am able to apply an animation when the item first shows simply by adding a class. But the problem is when it's getting removed, the item gets removed from the screen before the animation can start/finish.
I know you can overcome this by setting a timer to delay removing action so that the animation can finish. But I don't want to put timers everywhere I need this functionality.
Is there an easier way in Angular to achieve this?
I don't want to use JQuery is either.
Use [hidden] directive on your element, as it does not prevent the element from rendering like *ngIf does.
[hidden] mean it takes up space in your DOM document but it's display is set to : none !important.
*ngIf on the other hand removes the element from the DOM completly
I'm stuck with Angular. I have a directive that shows a list and when the user hovers over an item, I want to show a preview of the item, with the preview being given by the directive user.
Some tricks though... I want the user to be able to filter the list using an input [which is easy on it's own] and there is some basic styling surrounding the list that I would like the directive to handle, like adding the checkboxes that well be watched to create the model for the directive.
I want the directive user to simply be able to write:
<preview-list list='unfilteredlist'>
<div>
<h1><blink>{{title}}</blink></h1>
<h2><marquee>{{html extrodinaire}}</marquee></h2>
</div>
</preview-list>
I tried using ng-transclude, but it uses a sibling scope and I've been looking for work arounds and I can't find any. The only ones I found involved writing the entire template in javascript, which honestly I can't believe people think that's an acceptable solution.
Any solutions, or is this actually completely impossible in Angular?
As i see it you have two options :
Create a preview box for each member in your list and toggle visibility on hover. This is great if you have only a few values and the preview box is heavy.
Create a transcluded directive in which - the main scope will hold the list and the currently hover element. The sibling scope will hold the preview container. Once the selected value changes the preview box will update (according to your bindings) and only thing left to do is position it.
transclude is hard at first but it pays off.
Hope this helps.
I have a horizontally scrolling div that is contained within a directive, where the directive is placed in a view. Upon adding elements to my scrollable div I want to always scroll to the end of the div. I am attempting to do this by placing an id on the element I want to scroll to, and setting $location.hash('myElementId'). I then call $scrollToAnchor().
I am seeing two problems. First, I haven't been able to make this work at all, and am wondering if $scrollToAnchor() works for horizontally scrollable areas. Second, calling $scrollToAnchor() seems to trigger the controller() function of my view to run again, along with all the controller() functions of any directive contained in the view, effectively causing everything on the view to redraw, which is not my intention.
Is there a way to cause scrolling to happen for a particular scrollable div only? Does $scrollToAnchor() cause a 'refresh' of the view by design?
Thanks
Since the ComboBox and FilteringSelect use a 'dijitPopup' whose DOM element gets inserted just before the closing body tag (presumably to help with ensuring it appears above everything else z-index-wise) this means that if the ComboBox is contained in an element that scrolls independent of the window itself and the user opens the dropdown and then scrolls the window (or whatever containing element) using the scroll wheel, that the menu part doesn't move with the control itself.
Is there a straightforward way to ensure that the menu part of the view remains positioned correctly relative to the control itself rather than simply assuming that its starting position is ok?
EDIT: appears to be a known issue (http://bugs.dojotoolkit.org/ticket/5777). I understand why they put the dijit popup just before the closing body tag for z-index stacking and overflow clipping issues, but it seems like it's maybe not the ideal way to do things given the bug in question here and things like:
You can restrict the Dijit theme to only small portions of a page; you
do this by applying the CSS class of the theme to a block-level
element, such as a div. However, keep in mind that any popup-based
widget (or widgets that use popups, such as dijit.form.ComboButton,
dijit.form.DropDownButton, and dijit.form.Select) create and place the
DOM structure for the popup as a direct child of the body
element—which means that your theme will not be applied to the popup.
~ from http://dojotoolkit.org/documentation/tutorials/1.6/themes_buttons_textboxes/
Not sure if this is the very best solution, but here's what I came up with:
Since the widget may be programmatically added/removed, and to avoid coupling a solution with some particular surrounding markup that we can't always count on in all cases, what I did was to hook the _showResultList and _hideResultList methods of ComboBox and when the popup opens, traverse up the DOM till we reach the <html> tag, adding onscroll listeners on each ancestor.
The handler for the onscroll event is simply:
var myPos = dojo.position(this.domNode, true);
this._popupWidget.domNode.parentNode.style.top = '' + (myPos.y + myPos.h) + "px";
where this is the widget in question. I scope the handler to the widget using dojo.hitch. In the close method I remove the listeners. I have to clean up the code a bit before it's presentable, but when it's finalized I'll add it to this answer.
Note: I only show updating the y position here. Part of the cleanup is to add x position updating in case someone scrolls horizontally.
Though its old I just faced this same problem and it looks like a Dojo issue and the fix is available here https://bugs.dojotoolkit.org/changeset/30911/legacy