As can be seen here, the pointermove event cannot be used on iOS Safari, which is the most used browser of my target users. On an OpenLayers map, I'd like to show a tooltip when hovering on specific layers' feature. It works well on desktop with pointermove, but what's the best practice to include a similar behavior for mobiles? I'd like some guidance before I do too much in the wrong direction
Should I then listen to the click or singleclick event as well, to include mobiles?
If so, should I just add two listeners and refer to the same callback?
If so, should I check which device triggers the event, to avoid (possible?) weird behavior?
I am not sure of the tolerance on mobile devices for clicks: should I use the hitTolerance option of forEachFeatureAtPixel, and would I then need to programmatically make sure that I'm getting the feature closest to the clicked pixel and not some random one within the tolerance area?
Thanks for your help :)
Now all major browsers support Pointer events natively and Openlayers removed Pointer polyfill since v6.4. If you are targeting older browsers that do not support Pointer events, you now need to include a pointer events polyfill (elm-pep or pepjs) in your application. You'll then can use pointermove events on all platforms.
Related
This is my website for a school project, it is designed to be viewed on a phone. I have a dropdown menu on it near the top that uses hover, which does not work on touch devices. I need to make this work with clicking (I don't really care if hover still works, I need to click) but do not know how. How do I make this work with tapping on a touchscreen? I really want to stay away from javascript for now and just use HTML and CSS. I am very new to webdesign so I will need a very basic explanation. Also I know my images take a long time to load, any suggestions on how to address that would also be appreciated.
Thank you!
Most touch devices lack the ability to provoke a true hover interaction (some exceptions would be the Samsung Galaxy Note with pen, Microsoft Surface devices with pen, and the iPad Pro with pen).
That said, touching an element that has a :hover pseudo selector with associated styles (as you do) should invoke that hover event, even in mobile browsers on touch devices.
Have you viewed your website on a touch device? The menu appears as expected with tapping on my Google Pixel (with Chromium browser) as well as on my Surface device in tablet mode.
There may be some browsers/devices or combinations thereof that do not exhibit this behavior, but I believe it's quite standard.
If you need a more principled solution, I'd suggest making the nav toggle a <button> element and executing some basic JavaScript on click events. I realize you don't want to stray into that territory right now, but that's exactly the sort of use case at which JavaScript excels.
If you really want to avoid JavaScript and you don't like relying on the touch-invokes-hover-event approach, there's always the checkbox hack. As the name indicates, it's a hack. I wouldn't recommend it for your particular use case. But to each his/her own.
Here's a CSS Tricks article on all the interesting uses the checkbox hack can be applied to.
I am using native HTML5 drag and drop for a simple game application where user needs to drag the images of animals and place in to the correct bays (domestic /wild). When I am dropping (appending) the dragged element to the bay, I want to animate it and make it appear as if the elements are flying and getting dropped in the bay.
I have tried fadeIn(), but it happens after the element has been appended. I need the animation between the dragstart and the drop. Thanks for your help.
For what you are trying to achieve html5 drag'n'drop functionality might not be the best for precise visual experience you are looking.
As default behaviour slightly differs in browsers and most annoying is 'move back animation' once dragged item is dropped.
I have no idea why developers behind Chrome did that stupid "feature" that even delays the dragend event, which is even worse thing..
So you would need to write your own drag'n'drop functionality with very precise visual functionality, but I would not recommend using html5 drag'n'drop for your particular case.
I'm currently experimenting with HTML5 Drag and Drop API. Now I've got several questions:
1.
Am I right, that it's not possible to connect draggable elements with drop-areas?
Example: You have 2 different kinds of elements you want to be able to drag and drop: Files and Text-Labels. Now if I give some div an DragOver-Handler and a Drop-Handler it will respond to both, files and text-labels. I'm looking for a simple possibility to only respond to a specific type of draggable items.
A connected problem is the dropEffect cursor-style: At the moment I enable all possible drop-targets in the DragStart-Handler and disable all of them in the DragEnd-Handler (with "disable" I mean, that I remove all DragOver- and Drop-Handlers). If I wouldn't do so, it'll look like if you could drop a file on an element that should only react to text-labels.
2.
The dropEffect cursor-style is a mess. In Firefox I don't get them at all, in Chrome it will give me a big "plus"-icon (even if I have removed the DragOver- and Drop-Handlers from an element)
3.
Last feature I am looking for is multi-select: Select multiple Text-Labels and then drag all of them at a time. Is this possible? My first idea was to create a new div and move all selected elements inside this div and then drag the newly created div. Seems pretty hackish and looks quite ugly ;-)
I hope you guys have some answers for me. Thanks!
I don't think that HTML5 drag and drop (and friends) are supposed to be replacements for commonly used "drag and drop" Javascript libraries (although it COULD be used instead of them in some cases). The name is misleading.
Modern operating systems include APIs that allow cross-application communication: clipboard and drag-and-drop. Both APIs are quite similar and need to be quite low-level because of specific challenges:
the data must be sent across processes, so it must be somehow serialized,
the sender must have a way way of offering the data in many formats (eg. text/plain and text/html) and the receiver the ability to pick one that it likes best,
the sender and receiver may live in different processes, so they can never find out about each other (they might even be entities coming from different platforms, GUI frameworks, programming languages etc.), the only channel of communication is the data itself,
Current HTML5 APIS, as opposed to - say - JQueryUI draggables - are not meant to give programmer strict control of the look and feel of the dragging process, but rather enable tight integration with the native, system-wide mechanisms. Which may or may not be what the programmer needs.
So to answer the questions:
you cannot "connect draggable elements with drop-areas", because your draggable elements can even come from outside the browser. But you can make an area that rejects certain types of data (which is what user expects from native drag and drop).
"div" and "multiselect" are not things that operating system understands (we don't have native multi-cliboards or multiple-text-selections). You CAN implement such functionality if you make a with inner divs that can be toggled (eg. by clicking while holding shift). When someone tries to drag the outer dive, make a transfer object that says which inner divs were selected (you could even create an image that shows them).
If the above solutions sound a bit low-level, well - that's because they are. When you develop a desktop game or tool, you do not rely on native drag and drop for moving pieces across the chessboard or moving sliders in the GUI. I think it will be the same with JavaScript. JQueryUI Draggables are not going anywhere.
I want to isolate the 'play', 'pause', and 'stop' functions for my HTML5 player. I want to put those in random places on my homepage (i.e., stop at the top left, play at the bottom-right, and pause at the middle of the page). I also want to be able to isolate the tracker. So, for example, have the tracker on the bottom-left of the page.
Can anyone tell me what it would take to isolate out one of the controls? So, for example, "If the user clicks anywhere in div, "bottom-right", the audio will start to "play". The tracker, bottom-left, will start to track, and the stop and pause buttons will go to ready state....
I don't believe you can affect the controls of a browser's native audio player, at least to the extent you want to, through CSS or JavaScript. Therefore, you'll need to omit the controls attribute from your audio tag (which will give you a player with no controls) and write the controls, and the logic behind the controls, yourself.
This tutorial should give you enough to get started. However, you should note that, depending on the level of functionality you require, this may not be a trivial task.
You might also consider looking for a third-party library which supports the level of UI customisation you require. I haven't used it myself but have heard good things about audio.js.
[Edit]
This HTML5 audio test suite is quite handy as a summary of the API for the audio element and has links through to the appropriate entry in the W3 specification for each of the properties and events listed, though I would expect support to be inconsistent across the various browsers which support HTML5 audio.
I've created this fiddle which demonstrates an HTML5 audio player controlled by a very basic set of custom controls (only tested in latest version of Chrome).
I'm implementing a HTML5 game using canvas. Now I'm thinking about making all text overlays like tooltips, speechbubbles, infowindows and so on using HTML elements with position absolute over the canvas. So I can use many effects and transitions CSS3 offers.
But I'm not sure about performance. These overlays have to be added and removed frecuently (is something MMORPG like, so there will be a lot of speechbubbles and so on).
There are probably 2 questions regarding performance:
DOM traversal to add/remove. Maybe a cache can help?
HTML and CSS3 itself.
The other option is to manage these elements in the canvas itself, drawing them each frame. But maybe I have then again a performance penalty, because of the extra code, timeouts and stuff I would have to add, to achieve similar effects like in CSS3. And traversal of some data structure would be needed anyways.
Any advices, opinions, experiences?
Thanks in advance.
Consider using only one of the mentioned two technology. May be you can release that application in mobile or tablet. I think on these devices would be issues with handling both the same time. And another thing: if you stay in canvas there would be no worries about compatibility. Its not a techy but a thought-provoking answer.
The single best reason for using the DOM for UI elements in HTML5 games is event handling.
If you draw everything on canvas you will need to write your own logic to handle clicks and decide what has been clicked on, which can soon become very complex, expecialy if you have multiple layers of interface.
With DOM elements (especially when using a library like jQuery) this is trivial, and you can create a rich and interactive UI with minimal effort.
The only downside I can think of is that you may encounter browser inconsistencies, especially if using CSS3, but again jQuery will help with this.
I suppose another downside is that once you go down the DOM route, your game is always going to be a browser game, whereas if it was 100% canvas, there would always be the possibility of porting the code to another language and making it native, but I guess that would only be a downside for some people.
One way to approach this is to use a "dynamic" image map behind your canvas object. Then you can use the dom as required. Note you will need to pass the clicks on the canvas through to the image map.