When you create a new element, you can assign tags to it, but the tags window constantly jumps around the screen as you type. Which is very annoying if you want to quickly select with the mouse by ready-made tags.
https://i.imgur.com/AccTcXZ.jpg
And here http://eucaly-tw5.tiddlyspot.com/ the owner has already screwed something up and the window does not move, and of course it is more convenient.
https://i.imgur.com/63boyVQ.jpg
What parameters need to be changed in order to get the same effect on myself?
This behaviour is controlled via CSS. One option would be to add the following value to a sitewide stylesheet (tagged $:/tags/Stylesheet):
.tc-edit-add-tag {
display: unset;
}
Related
I have a responsive layout that must be accessible for screen readers. The issue is around the order of buttons on desktop vs mobile.
On desktop the button order is
Cancel - Remind Me Later - Learn More
...and the screen reader reads left to right. However on mobile the button order is vertically stacked and is ordered as the reverse of the desktop:
Learn more
Remind me later
Cancel
The problem is the screen reader still reads as if user was in desktop mode - the visual order no longer matches.
Is there a way for the screen reader to change the reading order depending on the viewport?
In general, screen reading software ignores CSS (*). The order of your DOM is the order the screen reader will read it. Even if you used tabindex, that will only control the order of tabbing through the interface. If you use CSS to reposition elements, whether through flexbox or grid or float, the screen reading software will ignore that.
A screen reader user can simply walk the DOM (**) by using the up/down arrow keys. (** The user is not really walking the DOM but rather the accessibility tree, but it's similar to the DOM. Not every element in the DOM will be on the accessibility tree, but it's a similar analogy).
So, the only way to "control" the order that a screen reader hears the elements is by modifying the order of the elements in your DOM.
(*) (If you have a :before or :after pseudo-element with a content property, that property will be read by a screen reader as noted in step 2F of the "Accessible Name and Description Computation")
This is a common issue and there are a few solutions you can do. Without knowing much about your codebase, here are a few suggestions for you:
Not knowing how complex your markup is, you could provide a version of the form elements that are only visible on small screens. That way you can explicitly control the accessibility tree structure.
Another option, you can use CSS (flexbox or grid) to reposition the buttons based your media query for small screens.
While this would work, I would not advice using "tabindex="1", "2", "3" "..." to control tab order seeing as how your UI is not rendering in the correct order anyway.
Hope this helps. Good luck with your project.
Is there a way for the screen reader to change the reading order depending on the viewport?
One solution is to have two sets of the same menu and use your media queries to use one or the other
<div class="desktop">Cancel - Remind Me Later - Learn More</div>
<div class="mobile">
Learn more
Remind me later
Cancel
</div>
CSS:
.mobile {display:none}
#media screen and (max-width: 600px) {
.desktop {display:none}
.mobile {display:block}
}
This way, you will be free to let the DOM order match the visual order.
Anyone have some code to reorder a ng-repeat using drag and drop that does not require jQuery? (angularjs dependency only)
I've had good results with https://github.com/kamilkp/angular-sortable-view - it's brand new (first commit was last week!), but it's extremely easy to work with. You put an sv-root attribute on the element (probably a div) that's the ancestor of the ng-repeat you want to be able to reorder. Then you put an sv-element attribute on whichever element you're ng-repeating, and drag and drop is handled for you.
You can also optionally put an sv-handle attribute on some element (probably an image, or a Font Awesome icon) inside your ng-repeat, in which case that element gets used as the drag handle. You can also optionally set up "placeholders" (something that shows up as you drag to show where the dragged element will be positioned if you drop it right now) with an sv-placeholder attribute on whatever element is your placeholder. And finally, you can optionally specify an sv-helper attribute on some element to make that element the one that gets dragged. (So if the thing you want the user to see while dragging needs to be different from the thing they see inside the list, that's how you do it).
Oh, and both the sv-placeholder and sv-helper attributes can go either on elements outside the ng-repeat, in which case the same element will be used for every drag situation (use this, for example, if you want a blank gray box as a placeholder the way Trello does it when you drag cards around) -- or those attributes can go on elements inside the ng-repeat, in which case you have access to the local scope of that particular ng-repeat element (use this, for example, if you want your placeholder to be "the text of what I'm dragging around, with opacity 50%, and a dashed border around it").
The demos linked from the https://github.com/kamilkp/angular-sortable-view repo demostrate the usage pretty well, so rather than say more about it I'll just let you poke around in the demos. My personal experience so far has been very favorable.
Oh, and it has no dependencies other than Angular. No jQuery or anything else required.
I have a sliding carousel of items, each of which includes its own like button. I want the like buttons to have comments; that is, when the user clicks Like, he should be presented with a prompt to leave a comment (http://developers.facebook.com/blog/post/397/). I'm starting to doubt that these goals are compatible and would like to hear if anyone has already achieved it.
The comments on the Like buttons are wider than the items in the carousel, and correctly overflow onto other carousel items. However, some of these items are outside the clipping box, since the carousel items are necessarily inside a div with overflow: hidden (otherwise we wouldn't achieve the effect of the items scrolling into existence upon paging). Because of this, if I click Like on the rightmost item currently visible, the comments prompt that appears will be partially outside the clipping box and thus partially visible.
It appears to me the only possible hope of allowing the comments prompt to overflow the carousel container is to place the prompt outside the container in the dom. This way, assuming we can visually position the prompt next to its Like button where it belongs, it's no longer constrained by the container. This seems within possible, since at the time of this writing the comment prompt is implemented as a separate iframe from the button itself; i.e., this XFBML:
<fb:like width="450"></fb:like>
yields (approximately) this HTML:
<iframe src="facebook.com/like_button.php"></iframe>
<iframe src="facebook.com/comments_widget.php"></iframe>
But if I try to move the comments iframe in the dom, it instantly and permanently becomes empty. Even if I could find a way to detach certain events and prevent this, it shows that an intricate solution is called for, and one which Facebook can break at any time in the future with changes to their implementation. Thus, I can't move the comments in the dom, and thus, the prompt is always in danger of being clipped. Facebook says this on the subject:
If the Like button is placed near the edge of an HTML element with the overflow property set to hidden, the flyout may be clipped or completely hidden when the button is clicked. This can be remedied by setting setting the overflow property to a value other than hidden, such as visible, scroll, or auto.
Clearly in the case of a carousel it's not possible to remove overflow: hidden. Has anyone found a way around this, or should I give up and spend my time elsewhere?
Thanks
I need to change the color of certain attributes/tags. I am switching from Dreamweaver and making the skin has been really hard in TextMate.
As you can see, I want to change the a and img tags along with all of their attributes. The closest I've come to find is entity.other.attribute-name which only works with id for some reason entity.other.attribute-name.id
Bonus would be the scope selector for the value of an attribute, e.g. "Logo" alt in the above example.
Thank You!
TextMate's Bundle Development Plugin has a Show Scope and Copy Scope. Put your text cursor in say the middle of the area you want colored, then trigger one of those: does that narrow down the selector for you?
(Maybe that's how you got the selectors you mentioned in the first place, but thought I'd mention it...)
I'm checking if it would be possible to implement a GUI using HTML through PyQT and WebKit. One of the problem is that using the mouse you can select the text making up the interface. Can this behaviour be disabled?
Also, the mouse pointer changes to an insertion caret while over the selectable text. I would like to disable this, without disabling the hand mouse pointer which appears when over a clickable link.
That's how I am doing it:
cursor: default;
-webkit-user-select: none;
I am working on something quite similar, a desktop app with html/css-based interface.
The above code takes care of text selection and the caret. Set css property cursor to pointer for your links, something like:
a { cursor: pointer; }
You can use javascript to "return false" on the start selection event in order to disable the text selection.