2x Retina, or not 2x HD, that is the question.
First of all, I don't have a Retina display to test on, and the documentation seemed a little ambiguous to me. It is possible that the API handles things well. It is possible that it doesn't. It is possible that we must handle some of these things. Either way, it is not clearly documented.
Leaflet Icon object's iconAnchor property
For the Icon object, the iconAnchor property can be set so that the the "tip" is centered. How is this handled on a Retina display, when the image is (presumably) 2x larger in each direction? What if we can't make assumptions that every HD resolution will be 2x? What if the HD display has a 1.75x or 2.25x larger pixel ratio? Does Leaflet recalculate a new proportional iconAnchor, or do we do that manually in our load/detect/init setup, or is it a non-issue, or does it act in an undefined manner? Should we always be required to handle something manually which perhaps belongs hidden in the API, and a more generalized resolution handling of "stretchy" Icons?
The coordinates of the "tip" of the icon (relative to its top left corner). The icon will be aligned so that this point is at the marker's geographical location. Centered by default if size is specified, also can be set in CSS with negative margins. -- Leaflet Reference: Icon.iconAnchor
Leaflet Icon object
For the image-file based Icon object, there are the pair of properties: iconUrl and iconRetinaUrl (usually a 2x image), which are pretty self-explanatory. Just going by the documentation and nothing else, this seems like the only reliable way to handle icon sizes on higher resolution displays.
Leaflet divIcon object
Using the DivIcon object, we inherit the above mentioned URL properties, but we have no URLs to use, so they are not required, thus those are meaningless in this context. We do however inherit the iconSize property, and this is useful for setting the size on common displays. But there's no IconRetinaSize, etc. Resolution must be detected and set manually at initialization time. But it seems Leaflet has already done some resolution detection to some extent, with some internal code to choose between 1x and 2x image URLs based on 1x and 2x pixel ratio. If it already has that info, why not properly handle it's own properties as well?
Leaflet (and every JS library out there) uses CSS pixels - and the browser decides the relationship between CSS pixels and screen pixels (or "device pixels"). Read https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio .
The future might hold better resolution management, or maybe usage of the <picture> element instead of <img> for this. If you have any specific ideas on how to improve Leaflet, or how to improve its documentation, please do so by contributing to the project (pull requests are always welcome!)
I am getting started on mapbox studio. I want to be able to change the background image based on the zoom level - so far default way to set image is:
Map {
background-color: #land;
background-image:url(pattern/3.png)
}
I have tried adding zoom level conditions as follow.
Map {
background-color: #land;
[zoom>=5] {background-image:url(pattern/2.jpg);}
[zoom<=5] { background-image:url(pattern/3.png);}
}
appreciate if you can share any tips or point to resource and methods I can read.
Cheers :)
Properties in the Map object are global properties that cannot be filtered or changed by zoom level. In order to have different backgrounds at different zoom levels you will need to create a custom polygon layer to act as your background, but with more flexible styling. You would use polygon-pattern-file on this layer instead of background-image.
See the source quickstart tutorial for info about creating a custom source layer and adding it to your style project. You can use the 'bounding box' file from Natural Earth for this; it is a single polygon that covers the entire map.
I've got the following situation, and I need some help...
Two divs, same size, same location, one on top of the other
Everything works as expected on desktop browsers
On the iphone/ipad a faint line appears around the border of the divs
This faint line is not always on all four borders. It changes depending on the location of the divs. It looks to be happening as a result of the two divs not lining up properly, but according to their style settings, they are of identical size and location.
You can see the results here: http://www.thoughtartistry.com
Any ideas?
I had a similar problem in a recent project where I had background image masks with different background color to colorize the resulting icons in mobile Safari. The problem was that when the page was scaled down by Safari, there was a line of the background color showing around the image, even though it should have been masked. I never found a way to prevent that leaking of the background color when the page is scaled down. It's clearly an error in mobile Safari's algorithms that recalculate the background and mask. I did find a workaround: I put an outline on the element with the same color as the background of the element's parent. The outline is outside the element and therefore masks the part bleeding out. If your element's parent has a pattern background that's drastic, this won't work that well, but if it's a solid color, it'll do just fine.
A negative margin is the only way I found to prevent this.
For example, if you have a faint horizontal gap between 2 divs, adding a top margin of -1px to the second div will make it overlap slightly and the gap will not reappear as the page is scaled.
Some situations (like image sprites or repeat patterns) may need a little more tweaking, but the general idea is the same. For a sprite, make sure there is no big color change within 1 pixel of the cropping border. The bleed is never more than 1 pixel, so a 1 pixel adjustment is enough.
The problem is not only with divs matching together, but also with image sprites.
I followed the advise in this thread of setting initial viewport scale to 1.0. The sub-pixel bug was gone, but then I tested my website on other devices, like Android, and realized a full size page is annoying, since users have to re-scale every time it's loaded. So I preferred to disable the scale and wait until Apple fixes it. Then one day I was thinking how to solve the problem with the margins of the page, and I came to this simple solution in CSS:
html {
min-width: 1024px;
}
Devices capable of this resolution, such as iPad in horizontal position, will set the document scale to 1.0. In my case this is enough solution, since I can show the page is working just right, and the sub-pixel bug is in Safari/iOS, which will be solved in the future hopefully.
It totally depends on one's situation, but in our case we use negative margins as proposed by this thread or a box shadow since outline only applies to all borders and ie. outline-bottom does not exist.
/*
* Prevent faint lines between elements.
* #link http://stackoverflow.com/questions/5832869
*/
box-shadow: 0 1px 0 red;
I also solved the iOS sub pixel gap issue (on a full screen site) by using overflow-x: hidden; to stop side ways scrolling & viewpoint scale to stop pitch zooming. I also had holder divs set at width: 101%; and all the elements/image divs inside set to float: left;. This means the sub pixel gaps are all on the left hand site but pushed out of view by the holder div set at 101% width.
Remove "clear:both" (if there is) from div below the gap.
I also had to solve this. If you are using Div's to define sections only then.
//background.css
.background-color {
background-color: blue;
}
.background-color div {
background-color: inherit;
}
I'd try playing with meta/viewport options, specifically setting initial scale to 1.0 and disabling user zooming.
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
Is it possible to have a menu bar (navigation bar) on a web site that is independent of iPhone’s zoom (i.e. with fixed width and height) while the rest of the site can be zoomed in and out?
With meta "viewport" I can set the zoom of the whole website, I want to exclude some parts.
It seems that it can't be done by using iFrames or CSS transforms.
Is it possible to be done by tracking Gestures that scale elements, and using javascript to rescale my menu?
iPhone's zoom is a graphical thing - it does not change the html rendering of the page (although it may look at the html element for hints about what how much to zoom).
So, not really, no.
I am overlaying a transparent image on my VEMap control by rendering it as a single VEShape. The shape changes sizes dynamically depeding on the zoom level of my map and can be as large as 4000*4000px. In older browsers such as IE6 and early versions of Firefox 2.x, map control performance degrades rapidly when my shape gets larger than 1500*1500px. The mouse pointer moves slowly and the map responds very slowly to events. I don't see this issue at all in newer browsers (IE7+).
Are there any workarounds to boost performance of rendering a large shape for IE6 users?
The solution you're probably looking for is to actually use "Map Cruncher" to create map tile images from your image. Then these map tile images can be overlaid on the VEMap using a Custom Tile Layer, and will be rendered exactly the same way as the Map Images themselves.
http://www.microsoft.com/maps/product/mapcruncher.aspx