Width device width iphone

Медиазапросы: width против device-width

Довольно часто люди не понимают разницы между шириной (width) и шириной устройства (device-width) (и, более того, есть примеры с минимальной (min-device-width) и максимальной шириной устройства (max-device-width)), используя медиазапросы CSS. Это недопонимание приводит к написанию плохого кода и значительно большему количеству работы для разработчика. Этот вопрос очень часто встречается на форумах SitePoint, поэтому пришло время объяснить все подробнее. В этой статье будет затронута эта проблема, а также мы более подробно рассмотрим, какой вариант следует использовать, создавая отзывчивые сайты.

Основные определения

Давайте определимся, что мы имеем ввиду, когда говорим о медиазапросах, основанных на «ширине» и «ширине устройства». Нижеприведенные цитаты взяты из статьи MDN о медиазапросах, и там есть такое определение «ширины»:

Свойство среды «ширина» (width) описывает ширину отображаемой поверхности устройства вывода (например, ширину окна документа или ширину окна страницы на принтере)

А вот так MDN определяют «ширину устройства»:

Описывает ширину устройства вывода (означая полный экран или страницу, а не только область отображения, такую как окно документа)

Так что же это на самом деле значит? Простыми словами, «ширина» и «ширина устройства» относятся к ширине устройства, а не всей ширине области просмотра, которая может быть абсолютно другим понятием. Все, что вас должно интересовать – это ширина области просмотра, вне зависимости от ширины устройства.

При этом основным различием между шириной и шириной устройства является то, что ширина устройства не всегда соответствует области просмотра определенного устройства.

Большинство планшетов и мобильных устройств не всегда имеют 1 пиксель устройства на 1 пиксель CSS. Например, вам стоит знать, что у iPhone 4 стандартная область обзора экрана составляет 640×960. Это означает, что на данном примере device-width iPhone4 равна 320×480. Дело в том, что Apple понимают, что не каждый сайт создан отзывчивым и пытается сделать хорошо всем, предоставив ширину около 980px для отображения десктопного варианта сайта. Это значит, что если нет метатега области обзора, iPhone4 берет сайт и отображает его, как если бы он был 980px в ширину, при этом втискивая его в экран шириной 320px, в результате чего с точки зрения пользователя сайт будет отображаться уменьшенным.

Для начала, как и во всех случаях превращения сайтов в отзывчивые и использования медиазапросов, тег области обзора meta необходимо поместить в раздел вашего сайта. Базовая стандартная версия приведена ниже.

Как только на нашей странице появится этот сниппет, если мы будем просматривать страницу на разных устройствах, будут срабатывать разные медиазапросы. Без этого, при просмотре страницы на определенном устройстве, она будет отображаться просто как уменьшенная версия страницы; устройство будет пытаться вжать целый сайт в экран шириной 320px. И это не есть хорошо ни для вас, ни для ваших пользователей! Пользователи не любят увеличивать сайт, чтобы увидеть контент, и они точно не хотят скроллить его туда-сюда.

Например, давайте возьмем iPhone 4, у которого стандартная ширина области просмотра 980px. Без тега meta ваши попытки использовать медиазапросы не приведут ни к чему, и устройство будет неправильно обращаться к стандартной области просмотра. Большинство медиазапросов рассчитано на 500px или меньше. Это обычно выполняется с помощью простого медиазапроса max-width. Без тега meta вы не получите эффекта от этого запроса, так как iPhone 4 будет продолжать отображать версию сайта шириной 980px. Давайте рассмотрим приведенный ниже пример:

Ниже прикреплены два скриншота, сделанные с помощью iPhone 4. На обеих страницах есть вышеуказанный CSS, но на одной используется тег области просмотра meta, а на другой нет.

Показанная выше страница не содержит тега meta, и, в результате, фон отображается красным и имитирует стандартную область просмотра шириной 980px, вместо того, чтобы использовать мобильный медиазапрос на 500px.

В этом случае метатег на месте и iOS корректно отображает страницу такой, какой мы хотим: она основана на ширине 320px и позволяет нашим медиазапросам работать таким образом, как мы ожидаем.

Почему следует выбирать device-width?

Честно говоря, заголовок этой статьи изначально подразумевает неиспользование device-width. Однако для device-width есть свое место. Если вы делаете сайт для определенных устройств, тогда да – вам следует использовать device-width.

С точки зрения CSS и RWD, хороший сайт – это тот, который на самом деле «агностичен к устройству» и не пытается потакать ширине каждого отдельного девайса. Таргетинг на отдельные контрольные точки для различных «типов» устройств (например, планшетов или мобильных телефонов) достигается путем фокусирования на то, как контент отображается на определенной ширине области просмотра, а потом путем внесения соответствующих изменений в медиазапросы. Поэтому не устройство диктует контрольные точки, а макет и контент, и в конечном итоге это может привести к оптимальным результатам, как с вашей точки зрения, так и с точки зрения пользователей.

Это может и быть той причиной, почему у стольких людей проблемы с созданием отзывчивого дизайна, и почему они жалуются, что это сложно. Но если они пытаются создавать дизайн под отдельные устройства, они ввязываются в заведомо проигрышную битву: количество устройств, которые необходимо учитывать (чтобы охватить всё), слишком огромное и просто сводит все к плохому коду. Также стоит упомянуть, что если вы решили использовать device-width, вы также должны задавать отдельные правила для ориентации (книжная или альбомная): ширина устройства не изменяется только из-за того, что вы повернули устройство на бок. Для этого нужно еще больше кода, а это означает еще больше головной боли.

Однако давайте посмотрим на другой возможный вариант

Что насчет “width”?

Я придерживаюсь мнения, как и многие опытные разработчики, что полностью отзывчивая страница, которая ведет себя так, как от нее ожидают, на всех возможных размерах экранов – это самый простой и наиболее выгодный способ получить наиболее эффективный для всех устройств макет.

Чтобы создать полностью отзывчивую и гибкую страницу, разработчик должен просто обеспечить, чтобы учитывались все области просмотра, а страница изменяла структуру и размер при необходимости в соответствии с контентом и дизайном.

Все что вам нужно для полностью отзывчивой страницы – это гибкий сайт и немного продуманных медиазапросов для таргетирования на стандартный ряд мобильных устройств, планшетов, компьютеров + области просмотра. Я предпочитаю использовать Foundation’s Media Queries, которые являются наиболее точными и охватывают все необходимые области просмотра.

Конечно, как и все в разработке, использование только запросов на основе ширины не является решением всех проблем с макетом. Это скорее необходимо для тестирования на мобильных устройствах в поисках различных багов и странностей отображения. Но, имея возможность видеть, как все будет отображаться на различных мобильных устройствах – это так же просто, как изменять размер окна вашего браузера.

Для тестирования я использую расширение для Chrome Responsive Web Design Tester. Оно позволяет выбирать определенное устройство. Вы увидите размер устройства и то, как ваша страница будет отображаться на таком устройстве.

Еще одно небольшое преимущество, которое хотелось бы упомянуть, это что использование запросов на базе ширины гарантирует, что будущие устройства будут отображать сайт полноценно. Это довольно перспективный подход, так как вы ориентируетесь на что-то более глобальное – общий размер области просмотра – а не на определенное устройство.

Вы все еще планируете использовать device-width в медиазапросах? Приведенные аргументы оказались недостаточно убедительными? Использование обычной «ширины» и области просмотра устройства упрощает отзывчивый дизайн и в конечном итоге является лучшим вариантом, который следует использовать практически всегда.

Источник

How to get device width and height?

In Objective-C we can get device width and height by using following code :

How can do this in with Swift ?

13 Answers 13

I haven’t tried but it should be..

Swift 4.2

@Houssni ‘s answer is correct, but since we’re talking Swift and this use case will come up often, one could consider extending CGRect similar to this:

Then you can use it like:

If you want to use it in your code. Here you go.

(Swift 3) Keep in mind that most width and height values will be based on device’s current orientation. If you want a consistent value that is not based on rotation and offers results as if you were in a portrait-up rotation, give fixedCoordinateSpace a try:

Exactly like this, tested it also.

Since you’re looking for the device screen size the simplest way is:

While @Adam Smaka’s answer was close, in Swift 3 it is the following:

A UIScreen object defines the properties associated with a hardware-based display. iOS devices have a main screen and zero or more attached screens. Each screen object defines the bounds rectangle for the associated display and other interesting properties

To get Height/width of ur user’s device with swift 3.0

This works great for Xcode 12

Источник

Get the device width in javascript

Is there a way to get the users device width, as opposed to viewport width, using javascript?

CSS media queries offer this, as I can say

This is useful if I’m targeting smartphones in landscape orientation. For example, on iOS a declaration of max-width:640px will target both landscape and portrait modes, even on an iPhone 4. This is not the case for Android, as far as I can tell, so using device-width in this instance successfully targets both orientations, without targeting desktop devices.

However, if I’m invoking a javascript binding based on device width, I appear to be limited to testing the viewport width, which means an extra test as in the following,

This doesn’t seem elegant to me, given the hint that device width is available to css.

12 Answers 12

You can get the device screen width via the screen.width property. Sometimes it’s also useful to use window.innerWidth (not typically found on mobile devices) instead of screen width when dealing with desktop browsers where the window size is often less than the device screen size.

Typically, when dealing with mobile devices AND desktop browsers I use the following:

One issue with Bryan Rieger’s useful answer is that on high-density displays, Apple devices report screen.width in dips, while Android devices report it in physical pixels. (See http://www.quirksmode.org/blog/archives/2012/07/more_about_devi.html .) I suggest using if (window.matchMedia(‘(max-device-width: 960px)’).matches) <> on browsers supporting matchMedia.

I just had this idea, so maybe it’s shortsighted, but it seems to work well and might be the most consistent between your CSS and JS.

In your CSS you set the max-width value for html based on the @media screen value:

Then, using JS (probably via a framework like JQuery), you would just check the max-width value of the html tag:

Now you can use this value to make conditional changes:

If putting the max-width value on the html tag seems scary, then maybe you can put on a different tag, one that is only used for this purpose. For my purpose the html tag works fine and doesn’t affect my markup.

Useful if you are using Sass, etc: To return a more abstract value, such as breakpoint name, instead of px value you can do something like:

Create an element that will store the breakpoint name, e.g.

Now you can act on same breakpoint names as you do in sass, e.g. sass: @include respond-to(xs) , and js if ($breakpoint = «xs) <> .

What I especially like about this is that I can define my breakpoint names all in css and in one place (likely a variables scss document) and my js can act on them independently.

Источник

How to set viewport meta for iPhone that handles rotation properly?

So I’ve been using:

to get my HTML content to display nicely on the iPhone. It works great until the user rotates the device into landscape mode, where the display remains constrained to 320px.

Is there a simple way to specify a viewport that changes in response to the user changing the device orientation? Or must I resort to Javascript to handle that?

9 Answers 9

Was just trying to work this out myself, and the solution I came up with was:

This seems to lock the device into 1.0 scale regardless of it’s orientation. As a side effect, it does however completely disable user scaling (pinch zooming, etc).

For anybody still interested:

This instructs Safari to prevent the user from zooming into the page with the «pinch» gesture and fixes the width of the view port to the width of the screen, which ever orientation the iPhone is in.

You don’t want to lose the user scaling option if you can help it. I like this JS solution from here.

You’re setting it to not be able to scale (maximum-scale = initial-scale), so it can’t scale up when you rotate to landscape mode. Set maximum-scale=1.6 and it will scale properly to fit landscape mode.

I have come up with a slighly different approach that should work on cross platforms

So far I have tested in on

Samsun galaxy 2

• Samsung galaxy s
• Samsung galaxy s2
• Samsung galaxy Note (but had to change the css to 800px [see below]*)
• Motorola

This is a massive lip forward with mobile development .

I had this issue myself, and I wanted to both be able to set the width, and have it update on rotate and allow the user to scale and zoom the page (the current answer provides the first but prevents the later as a side-effect).. so I came up with a fix that keeps the view width correct for the orientation, but still allows for zooming, though it is not super straight forward.

First, add the following Javascript to the webpage you are displaying:

Then in your — (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation method, add:

Additional Tweaking can be done by modifying more of the viewportal content settings:

Also, I understand you can put a JS listener for onresize or something like to trigger the rescaling, but this worked for me as I’m doing it from Cocoa Touch UI frameworks.

Источник