What is the difference between width and device-width in CSS? - iphone

What is the difference between width and device-width in CSS?
I know there have already been some questions around this, but I would like to understand these from a media query perspective to sniff browser/device, e.g. desktop/mobile/tablet.

The device-width and device-height features refer to the dimensions of the output device (that is, the screen size).
The width and height features, on the other hand, refer to the dimensions of the rendering surface, which is the viewport (for example, the browser window) for screen media, or the page box for print media.
http://reference.sitepoint.com/css/mediaqueries#mediaqueries__tbl_media-queries_media-features

Related

How to keep the same resolution of canvas on different screen resolution?

First of all, sry for my English mistakes, I'm not a native English speaker.
I'm trying to make an UI which is composed of a canvas within different gameObject, and I would like that my canvas scales to the dimension of the screen but keeps its original resolution (16x9 portrait). If it is displayed on a tablet resolution (4x3) then an image is displayed in the space that is not covered by the canvas.
But actually all I've got is a canvas which scales to every resolution, and it changes the aspect of its child (for example a square becomes a rectangle).
Thank you for showing interest in my query!
UI's are heavy beasts. Canvas in Unity have a component attached to themm called Canvas Scaler which is set by default on Constant Pixel Size. You may try to set this property on Scale With Screen Size and then specify the base resolution you want to work with (usually 1920x1080 is a console standart). This is your first step
Then, to avoid strange Image scaling, you may check the property Preserve Aspect, this way the ration of the Sprite into your Image will remain the same indepently of the ratio of the Image
Last, you may play a bit with anchors but this is another story, you should let those at plain center at the beginning and come back to it when you will feel ready
Hope that helped ;)
Your canvas should have a component called Canvas Scaler. Here it should say Constant Pixel Size, change this to Scale With Screen Size and it should lock the Canvas to be the same width / height as the screen. If you want to lock an image to a specific width/height ratio, go to the Image component on the image and check the Preserve Aspect checkbox. This way if you have a 100x100 image, the images width will always be the same as the height. If you have a 200x100 image, the images width will always be twice the height, etc etc etc.

Compensate resolution change with size of features in MapBox static API

I'm using MapBox's static API in a project. I have managed to load maps with the same width and height in terms of latitude and longitude regardless of the resolution. This is so that users see the same area regardless of their screen resolution, for example. The problem is that on larger resolutions features and —especially, text appear much smaller, relatively. For example, these two maps look very similar, except for the size of text (and some other details, like the thickness of lines):
https://api.mapbox.com/styles/v1/mapbox/outdoors-v11/static/0.63189425,46.195750258333334,14.3/540x285#2x?access_token=ACCESS_TOKEN
https://api.mapbox.com/styles/v1/mapbox/outdoors-v11/static/0.63189425,46.195750258333334,13.15/240x126#2x?access_token=ACCESS_TOKEN
Is there a way to compensate for this and have the text on the larger image print larger, and have thicker lines? (in pixel terms). The result being that, say, two 6 inch screens print text in the same real-world size (centimeters) regardless of their pixel count.
I have looked into layers and filters, but it does not seem like there is a straightforward way of achieving this. It looks like maybe designing new maps would be the way to go, but I'm using the default ones and I would not know where to start.
THank you
I'm a bit confused by the premise of your question here. The API's #2x parameter is meant to toggle resolution and should serve exactly the purpose you describe. The reason for different amounts of label information being included in the images you've shared is because you've used different zoom values (13.15 vs. 14.3) and the labels in Mapbox core styles are zoom-dependent, meaning they change based on the zoom value used to generate the map.
With a fixed image width, and no #2x parameter:
/styles/v1/mapbox/outdoors-v11/static/0.63189425,46.195750258333334,14.3/540x285?access_token=ACCESS_TOKEN
yields
With a fixed image width, and a #2x parameter:
yields
/styles/v1/mapbox/outdoors-v11/static/0.63189425,46.195750258333334,14.3/540x285#2x?access_token=ACCESS_TOKEN
⚠️ Disclaimer: I currently work for Mapbox ⚠️

How to make responsible camera for multiplie resolutions?

I m working and some 2d game for mobile phones relate to chess, and I have a trouble with show board for different resolutions of mobile screens.
Here u can see how it must be on 9:16 resolution:
https://drive.google.com/open?id=1MFt-FtEtqkk7QWQC2oAtMBA0WAgOIV4h
And how it looks on smaller screen:
https://drive.google.com/open?id=11WLYZwHEa9ijXbekzUbE5ZbjbEnjZ6Lb
How can I protect my chess board from cropping?
Answer: it depends on how you want it to look.
If you just want it to fit perfectly horizontally, you need to perform 3 steps:
Evaluate the width of the Sprite (with Sprite.bounds)
Evaluate the width of the current screen (with Screen.width and using the main Camera)
Scale the Sprite to fit the screen
If you are using UI elements, you can do the same thing but you won't need to use Camera, just scaling according to the Screen width (look for RectTransform.deltaSize to give you the size of a UI element).
If you are using UI, also consider using layout groups, they help you with fitting the content to screen size.
Anyway, in a device with small width, maybe the table will get too small and you might have to think about better options to display the board instead of just scaling with screen width.

how Width units like rem,em and px makes the openui5 responsive?

Hi I am new to OpenUI5 and the logo says "Code Once work on all devices" but like when we use px, rem and em as width units for controls they take standard width which will not resize according to the screen size then how does the responsiveness works as logo says. Why do OpenUI5 claims that is fully responsive which is not?
You are right. If we use width, height, etc, it will be not responsive. So we need to use layouts, percents, anchors, etc. Also we remember that OpenUI5 extended version of jquery.

Loading levels from xml and supporting screen resolutions in Ios

I am developing a game that uses levels. The levels are made at a default scene width and height resolution.
The thing i am worried about is when the game is played on IPads iphone 5′s etc, the position of sprites loaded from the level xml files will be out of place due to the screen size.
In my case, could someone tell me the best thing to do in this situation or some advice on the approach i should take?
Also if any has experienced this, please let me know.
Thanks. :)
Generally this has nothing to do with how or where you store the level data.
These are the standard approaches, which one works for you depends on your requirements and desired results:
design each screen resolution individually (error-prone, tedious)
design for one screen resolution, then scale up or down according to screen aspect ratio (can lead to skewing as the screen size scaling for width & height are likely to be different)
design for the smallest screen resolution, then center the contents on the screen (this leaves unused areas either at the top/bottom or left/right sides)
same as above, but zoom content to fill the screen (this will remove the letterboxing, but also partially remove one side's content from the view)
In essence this is the same problem as movies have in trying to fit to screens of varying aspect ratios.
In general this is all a matter of scaling the input (positions) to a desirable output. The easiest approach is to maintain aspect ratio and allow for letterboxing. However Apple may reject letterboxing apps if nothing is done to hide the letterboxes (black areas) since Apple requires apps to support widescreen resolution, and letterboxing does not normally fall into their definition of "supporting widescreen".