The new update for the html5 widget has added an animation at the end that hides the waveform and shows sharing options and embed codes.
This breaks the effect that was desired in one of my clients sites that relies on the widget as its audio engine.
Is there a way to stop this animation or revert back to the older widget as it worked fine as it was.
The site is http://www.bushytunes.net
Play a track, skip to the end as see for yourself.
Thanks, James
-------UPDATE-------
On messing around with the iframes css in chrome web inspector, ive come across the .sound__sharePanel DOM element, all i require is the simple option to add display: none to this and the problem will be fixed.
I do belive i am passing a false boolean to the sharing paramater when loading the player iframe. Shouldn't this handle hiding the element as the api docs state that this parameter will 'Show/hide share buttons/dialogues.'
Related
Background:
When focused on a WebView control, TalkBack announces something to the effect of "Bing. WebView. Double tap and hold to long press" (note that focus is on the WebView control itself, not the content within the webview). However, as best I can tell, double tap and long pressing doesn't seem to do anything other than pass TalkBack focus into a control within the WebView itself. Our team has testers that specialize in accessibility which filed a bug on us for this "Double tap and hold to long press" announcement. The rationale within the bug states that since this action doesn't appear to do anything, the announcement will only serve to confuse TalkBack users.
This announcement doesn't appear to be specific to our app as I was able to reproduce this behavior on a new, blank Android app with a WebView that points to Google (there it announces "Google. WebView. Double tap and hold to long press"). As I think it helps show what focus I'm talking about, I have added a screenshot of the prototype app I built with the green TalkBack focus indicator below:
Questions:
Is there a reason for why Android insists on announcing the "double tap and hold to long press" piece for a WebView? If there is a functional reason for this, then any attempt to fix this issue may be moot.
Does anyone know of a way to stop TalkBack from reading the "double tap and long press"? Alternatively, is there a way to hide the WebView control itself from TalkBack without hiding the html content within?
What I've tried:
Unfortunately saw no luck setting isLongClickable to false, setting empty onLongClickListeners, and worked with a few of the suggestions in the stackoverflows here, here, here, and here. I tried all of the mentioned changes on a blank app to reduce the possibility that the complexities of our production app has interfered with the experiments I was running. Setting the ImportantForAccessibility field to "No" hides all of the inner html of the webview from Talkback so that is not an option either.
Sidenote that I find interesting: in my experimentation, I also tried setting the WebView's isClickable property to false and yet it was still clickable. So I am wondering if I am possibly focusing on setting properties on the wrong control (or if Android just completely ignores those properties on a WebView control).
In Touch UI, there is an iFrame called Content frame is added.
Can you please tell me
what is the reason of having an iFrame to display the page during the authoring?
There is an observer (/libs/cq/gui/components/authoring/editors/clientlibs/internal/page/js/observe.js) which observes the changes made to the DOM and sends post message accordingly.
What is the reason of sending postmessage and how this is helping?
The AEM developers realized that many problems arose from the fact that edit UI and WYSIWYG content view were rendered into the same context in Classic UI:
Edit UI would push content around, thus making it less WYSIWYG
Content styles could interfere with edit UI, accidentally misplace or hide it
Editor scripts could interfere with content scripts, meaning website authors would need to code around that
Edit UI inserts additional HTML element which need to be accounted for in content stylesheets and scripts
Which is why they decided on a better approach for Touch UI:
All content UI would reside in an iframe under the edit UI
Edit UI aligns to the content UI by measuring where it appears, not by inserting DOM nodes into the content
The observer is one of the few scripts still needed in the content UI to notify the edit UI when it needs to update its overlays
I've just started on a new project of my own.
What I would like to do is, on large screens, having a button activating a modal window BUT, on smaller screen (mobiles), I would like that modal window to become an off canvas section and when the button is clicked, the off canvas slides in from the side. Within that modal/off canvas part, there will be a form to fill out. (there will actually be multiple buttons that will need to activate the feature. Think something like multiple thumbnails with each a button to let viewers add comments)
I'm using Bootstrap 3 as my base framework. I would like to minimise the javascript (jQuery) functionalities but I understand I can't completely.
Questions I have,
do I have to create two HTML sections, one for the modal and one for the off canvas and then programatically hide/show according screen size?
Would it be best to create the form and then thru javascript, add the proper HTML around it according screen size? (though I think this option would be a tough to implement as my javascript skills are "advance beginner" at best)
How would I make the same button switch activation of the modal window or the off canvas form?
It seems to me that I need to detect screen size, no matter how I do the above, what would be the best way to detect the screen size, the safest and surest way?
Thanks for any insights you guys might have on this.
You will have to show code in your questions here, so i also vote to close your question.
I'm using Bootstrap 3 as my base framework. I would like to minimise
the javascript (jQuery) functionalities but I understand I can't
completely.
Angular JS decouples Twitter's Bootstrap from javascript. See: http://angular-ui.github.io/bootstrap/
Questions I have, do I have to create two HTML sections, one for the
modal and one for the off canvas and then programatically hide/show
according screen size?
Take a look to the Responsive Utilities: http://getbootstrap.com/css/#responsive-utilities
The screen detection of Twitter's Bootstrap is based on CSS media queries.
How would I make the same button switch activation of the modal window or the off canvas >form?
To give the same button different function based on sceensize you will need javascript / jQuery. See: Get the size of the screen, current web page and browser window you also could consider to use something like enquire.js, see also http://bassjobsen.weblogs.fm/responsive-banner-ads-2/
Or create two buttons and hide / show them with the the Responsive Utilities.
I'm experimenting with ways to have tooltips work across a variety of mobile devices. Unfortunately, the span of devices I need to support ranges from Nokias to iPhones.
Unfortunately, some of the browsers I'm dealing with don't support the use of the title attribute for tooltips on focus. As such, I need to come up with a different solution.
For starters, I'm playing with pure-css tooltips: http://psacake.com/web/jl.asp
This method uses the :hover pseudo class to position and set the z-index of a SPAN to create the tooltip.
On an iPhone, this produced an odd side effect. Tapping the link once exposes the tooltip require a second tap to actually activate the link.
However, applying a simple style to a different link's :hover pseudo-class (changing the background color) does not have the same effect. One tap triggers both the style and the link (you see the :hover style briefly before the next page loads).
I've solved this issue for mobile devices by switching to using the :focus pseudo-class which appears to not be triggered by the iPhone (and the Nokia touch device I am using). Of course, that's not ideal if this app were to be used on a desktop browser as well.
So...the question: Is there documented logic as to when the iPhone Safari browser decides to interrupt a click event on a link to expose the :hover pseudo-class vs. not interrupting and letting the link be triggered on the first tap?
I was trying to find you a link in Apple's documentation, but the most specific I could find about :hover was that it is emulated and can cause unexpected results. I did find one place that said it is only shown if the user taps and holds the object. That page (near the bottom, "Don't Use Unsupported iOS Technologies") also says that normal tooltips (using the title attribute) would be shown when that happens also.
If you will accept an assumption as to why the behavior is different for changing the style and displaying a tooltip, I would guess that it is similar to the way mousemove events are handled. This Handling Events page says that, if the contents of the page change during a mousemove event, the rest of the events in the chain (including mouseup) are not sent. I am assuming that this behavior also applies to :hover. If you are using display: none to hide the tooltip, you could try using visibility: hidden instead as it is interpretted as "the object is still here, but you can't see it."
Is there a way to make firebug (or any other browser, or using any other tool) stop any dom manipulation from happening? Sometimes layout debugging a screen filled with on hover events is impossible, as the elements may disappear, and you can't see their compound layout.
I freeze DOM Manipulation in FF with Firebug clicking right button on Node and set "Stop when add/change child"
Actually this is quite easy to do for pages that are not constantly and autonomously being altered (even comet applications can be relatively stable for a few seconds): just save the page using firefox. It will save the current state of it all, ignoring all javascript and events. More than that, the styles will be easily viewable.
i wish there was a better way to do this, i wonder if it would be possible to do with a bookmarklet, im surprised theres no button in firebug or chrome to just freeze the dom, or is there one, that i dont know about?