It seems there is no real standard for specifying "screen-size" in a http header from a user agent.
For example, the two headers below:
X-UP-devcap-screenpixels: 320x240
or
UA-pixels: 320x240
are two commonly used headers.
The second is used by Windows Mobile devices mostly.
The X-UP looks like it comes from the UP browser gateway.
Another option is
X-Screen-Width: 320
X-Screen-Height: 240
the X-Screen-Width might be made a up header.
My question is:
What is a good standard to adopt on our "transcoder" going forward? It's not really a full web browser, but is mostly for limited sites. But it should be the standard that would be adopted by Opera Mini/GWT etc.
Neither Opera Mini nor Google Web Transcoder sends this information through in their HTTP requests. I guess they expect the site to look up the phone model, and thereby the screen width and height, on the server side.
I actually found this RFC 4229 called HTTP Header Field Registrations. It's kind of outdated, and a mission to contribute fixes to.
If I had to see what's used mostly in the field, I would probably end up going with "UA-Pixels".
Some more references
Some devices (mostly Windows Mobile again) have a 320x240 value in the user-agent header
It's worse than you think.
UA-pixels: 320x240
Is often a lie. On IEMobile version <8 (Windows Mobile <6.1.4) devices with 640x480 pixels still report themselves as 320x240. In addition, in most versions of IEMobile the view may be zoomed to some extent so that the design size you have to hit is unrelated to the UA-pixels size.
The opportunities for liquid layout are limited prior to IEMobile 8. Yet in IEMobile 8 on WinMobile 6.5 you get about XGA resolution, zoomed out, whether you like it or not. Oh, and there is no way to sniff IEM8-on-6.5 vs. IEM8-on-6.1 from the headers.
I'm not sure what exactly the purpose of your application is, but outputting HTML/CSS that renders exactly to the size of the screen is practically impossible if your targets include the abysmal horror that is IEMobile.
Stumbled across this question and thought I would add a way to do this that is currently implemented in about three quarters of browsers.
Client Hints
Client hints have about a 75% availability in browsers at the time of writing, so they obviously cannot be relied upon across the board but for the browsers that do support them they can be useful.
You can't get screen height, but you can get width and Device Pixel Ratio (DPR).
To use client hints you need to either add a <meta> tag
<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width, Downlink">
or send a header
Accept-CH: DPR, Width, Viewport-Width, Downlink.
Browsers that support this will then send their response with each subsequent request.
Useful for?
Images!
You could rely on the <picture> element and supplying all the different variations of an image at different widths and resolutions, or you can use client hints to dynamically serve the right image size (and format)
GET myimage.jpg
DPR: 2
Viewport-Width: 1024
Accept: image/webp,image/*,*/*;q=0.8
We can then dynamically serve the correct size image and best format possible.
With the width header you could even decide which variation of a stylesheet to send based on desktop or mobile (although you would have to be very careful and this is probably not advised, just an idea of how you can use it for dynamic resource serving).
Here is a list of common screen resolution headers:
X-UP-devcap-screenpixels
or
UA-pixels
or
X-JPHONE-DISPLAY
I looked at the code snippet that Google give's for their Mobile Adsense and these are the three they check for so far.
Related
I use a tablet for all my schoolwork because I don't have a good computer, but websites often come up in mobile device format. Is there a way to set my browser to tell websites that it is a computer, and not a tablet? If it were possible, would this cause any other problems, like disabling the touchscreen, or anything like that?
There's a couple different ways to tell if you're using a tablet. Typically it's either by:
screen size (noting the typical width/height ratios of devices) and then styling by media query
the window.navigator object in the browser is aware of a handful of useful info, such as OS and browser details
Each site will determine this differently so I wouldn't be confident there's a catch-all solution to this one...that being said sometimes landscape will get desktop styling if the devs used the sizing method ¯_(ツ)_/¯
I'm newbie for developing mobile website. I very confused between two methods because I dont have any experience this it. Whats more better between two methods: css query when we using all of width device in css file or using jquery mobile that use php technique for differented user that use desktop or mobile [user->php?->mobile use jquery mobile/desktop use css standard]?
Many thanks for this answer
I will classify methods by their importance, from most important one to less important:
Client side detection
Using Modernizer javascript library to detect mobile / desktop environment
Server side detection
Using Modernizer Server or WURFL. Little complex then first solution but much more detailed (if you need more data about used device)
CSS media queries
Bad solution to detect desktop /mobile devices. Current mobile devices can have screen resolution equal to desktop platform
JavaScript based browser sniffing
Worst solution possible. Specially if you want to make distinction between smartphones and tablets.
To find more about this solutions, read my other article/answer with examples: https://stackoverflow.com/a/15055352/1848600
I have to post an answer in here since this comes first in search engines and accepted answer is not accurate.
There are two main concerns regarding responsive designs:
Content: Content should be restructured based on the width/height of the view port so the user can view the content without the need of constant zooming in and zooming out. This needs to happen solely based on the resolution of the view port regardless of the device. It could be a mobile device or a small window in desktop. This mainly involved the look and feel of the website and it is absolutely fine to use media queries. Even IMHO it is the best to use media queries to have the separation of concerns between your view and logic. No web designer likes to see random width or height showing up on their html elements during debug without knowing where are they coming from. Media queries will help you to resize the elements and show or hide them; however, in some situations you may need to move elements around; I usually do these using ng-if or ng-switch in angular js in combination with modernizer.
Functionality: If you need to turn on/off features based on the device functionalities, do not depend on the viewport specifications; use the vast libraries available in JS.
On a side note smartphone browsers seem to render at far lower resolution than actual device screen dimensions. Bust out a quick JS to show you your window resolution and run it on your phone.
Example: Chrome runs at 360x640px on my android screen of 1440x2560px.
We are developing an intranet backoffice. We've been investigating about safe area, and real viewport size of browsers in different OS.
Since it's internal software, we can "force" users to use browser and resolution we want. We would like to use 1280x1024 resolution in screens, and Chrome (or Firefox) as default browser.
We've checked with browser window maximized that the viewport size (in Chrome and Firefox) is 1263 pixels width. But we don't want to force so much, I mean, we think in 1240 as maximum width of web design.
Now, playing with CSS Grid generator software, I've found this config: 1240px = 12 columns of 85px each one plus 20px gutter.
What do you think about this ? Is it a good idea flexible enough for a backoffice ?
Any suggestions about this development ?
Thank you in advance
P.D. By the way, we were thinking about using BlueTrip CSS grid modified to 1240px ...
I don't see any point why you should limit your intranet app for certain browsers. In fact it may cause you more problems (browsers updates may break some layouts and elements since you are not forced to do proper cross-browser testing, monitor upgrades with different screen resolution). So, if it is flexible enough? No. Is the 12 columns grid enough? May be, depends on use. I would prefer to use fluid grid, responsible web design and media queries.
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
px? em? pt? seems like with varying device sizes and densities it's getting to be time to use something absolute like pts. Can anyone point me to a good, recent write-up of what to use when?
(I'm specifically targeting webkit-based mobile devices as my primary platform, though the site needs to work on large monitors, as well. I'm fine ignoring IE and older browsers for the most part.)
Check out this and that from Luke Wroblewski. Googling his name will find more.
As you say with high density phones you should avoid px but also pt that originally was for printing. As you setup your site to comply with most browsers, mobile or not, set your body font-size using percentage (historically better support I say without source) and then use em through your document. This allow your users to set their preferred font-size in their (mobile phones) browser settings and let you keep your relations between your different font-sizes.
As a web developer, I stick to pixels because this is already a standard for all digital display devices. Most mobile phones now come in screens based on pixels, and phones are able to resize to fit your content.
You simply have to make sure that you minimize the amount of content on each page for fast loading and rendering.
I think that you are best designing multiple CSS style sheets for browser window sizes,
Aside from that the best method in my mind is percentages - that way the content is always relative to the screen it is being viewed on. And then use em for font-sizes which is similar in the way it works to the way percentage works for layout sizes.