최대 장치 너비 또는 최대 너비를 사용해야합니까?
CSS 미디어 쿼리를 사용 max-device-width하면 장치 너비 (예 : iPhone 또는 Android 장치) 및 / 또는 max-width페이지 너비를 대상으로 하는 을 타겟팅하는 데 사용할 수 있습니다.
을 사용 max-device-width하면 데스크톱에서 브라우저 창의 크기를 변경할 때 데스크톱 크기가 변경되지 않으므로 CSS가 변경되지 않습니다.
을 사용하는 경우 max-width데스크톱에서 브라우저 창의 크기를 변경할 때 터치하기 쉬운 요소 및 메뉴와 같은 모바일 지향 스타일이 표시 될 수 있습니다.
특정 브라우저 (및 장치?)를 대상으로 지정하는 것은 이제 더 이상 사용되지 않으며 대상에 대해 좀 더 불가지론 적이어야합니다. 미디어 쿼리에도 적용됩니까?
왜 다른 하나를 목표로 삼으시겠습니까? 권장되는 것은 무엇입니까?
다음은 프로덕션 웹 사이트에서 사용하는 미디어 쿼리의 예입니다.
@media only screen and (min-device-width: 320px) and (max-device-width: 480px) and (min-device-height: 480px) and (max-device-height: 640px) {
/* Change a menu to fit the screen better, etc... */
}
나는 max-device-width및 max-width.
TL; DR
반응 형 웹 사이트를 만드는 경우 더 넓은 범위의 화면 크기를 대상으로하기 위해 / 대신 미디어 쿼리에서 min-width/ max-width를 사용 하십시오 .min-device-widthmax-device-width
2018 Media Queries Level 4 사양 초안 에 따르면 device-width미디어 기능은 더 이상 사용되지 않습니다 . 이전 버전과의 호환성을 위해 유지되지만 피해야합니다.
뷰포트 (또는 페이지 미디어의 페이지 상자) 크기를 쿼리하려면 사용 가능한 공간에 관계없이 장치의 물리적 크기를 나타내는 , 및 대신
width,height및aspect-ratio미디어 기능을 사용해야합니다. 배치되는 문서. 미디어 기능은 또한 때때로 모바일 장치를 탐지하기 위해 프록시로 사용됩니다. 대신 작성자는 스타일을 지정하려는 장치의 측면을 더 잘 나타내는 미디어 기능을 사용해야합니다.device-widthdevice-heightdevice-aspect-ratiodevice-*
보조 노트로서, 지정 기억 뷰포트 메타 태그를 에 <head>문서의 섹션 :
<meta name="viewport" content="width=device-width, initial-scale=1">
설명
주어진 장치가 가질 수있는 가능한 모든 화면 해상도와 픽셀 밀도로 인해 픽셀은 픽셀이 아닙니다. 왜냐하면 몇 가지 고려해야 할 사항 (확대 / 축소, 픽셀 밀도, 화면 해상도 및 크기, 장치 방향, 종횡비 등)이 있기 때문입니다. ..). 이 경우 픽셀은 실제로 물리적 하드웨어 픽셀이 아니라 "광학 참조 장치"라고 합니다.
다행히도 브라우저 뷰포트의 너비와 배율을 제어하기 위해 문서 섹션 에서 뷰포트 메타 태그 를 지정할 수 있습니다 <head>. 이 태그의 content값이 width=device-width인 경우 화면의 너비는 기기 독립 픽셀 과 일치하며 모든 다른 기기의 크기가 조정되고 일관되게 작동해야합니다.
<meta name="viewport" content="width=device-width, initial-scale=1">
미디어 쿼리 측면에서는 뷰포트 (현재 브라우저 창) 를 대상으로하는 반면 장치의 실제 전체 화면 크기 / 해상도 를 대상으로하기 때문에 max-width대신 을 사용하는 것이 좋습니다 .max-device-widthmax-widthmax-device-width
즉,을 사용하는 경우 max-device-width데스크톱 브라우저의 크기를 조정할 때 적용되는 다른 미디어 쿼리가 표시되지 않습니다.과 달리 max-width장치의 실제 전체 화면 크기 만 고려되기 때문입니다. 브라우저 창의 현재 크기가 아닙니다.
브라우저 크기를 조정할 때 사이트가 응답하지 않기 때문에 적응 형 레이아웃을 만들려는 경우 큰 차이가 있습니다. 또한 max-device-width화면이 작은 장치를 대상으로하는 미디어 쿼리를 사용하는 경우 브라우저 창을 더 작은 화면 크기와 일치하도록 크기를 조정하더라도 데스크톱에 적용되지 않습니다.
2018 년 현재 최신 미디어 쿼리 사양 초안 은 실제로 device-width미디어 기능을 더 이상 사용하지 않으므로 피해야합니다.
또한 Google Developers에 대한 이 기사에서는 다음을 사용하지 않는 것이 좋습니다 max-device-width.
Google 개발자-웹 기초-반응 형 CSS 미디어 쿼리
를 기반으로 쿼리를 생성 할 수도 있습니다
*-device-width. 이 관행은 강력히 권장되지 않습니다 .차이는 미묘하지만 매우 중요합니다.
min-width브라우저 창의 크기에 따라 다르지만min-device-width화면 크기에 따라 달라 집니다. 안타깝게도 기존 Android 브라우저를 포함한 일부 브라우저는 기기 너비를 제대로보고하지 않고 대신 예상되는 뷰포트 너비 대신 기기 픽셀로 화면 크기를보고 할 수 있습니다.또한을 사용
*-device-width하면 쿼리가 브라우저 창의 크기가 아닌 실제 장치 크기를 기반으로하므로 창 크기를 조정할 수있는 데스크톱 또는 기타 장치에서 콘텐츠가 조정되지 않을 수 있습니다.
추가 자료 :
- Quirksmode.org-픽셀은 픽셀이 아니라 픽셀이 아닙니다.
- W3-미디어 쿼리 레벨 4 사양
- Google 개발자-웹 기초-뷰포트
- Google 개발자-웹 기초-반응 형 CSS 미디어 쿼리
- MDN-뷰포트 메타 태그를 사용하여 모바일 브라우저에서 레이아웃 제어
장치 너비를 피하십시오. 그 이유는 사용자 브라우저가 어떻게 반응하는지 알 수 없기 때문입니다.
For IOS, it seems to be simple, at least with Safari. It seems to be one single device-width response independent of orientation. Also, device-width is stated only for the shorter side of the device. I did test this on iPhone 4S and iPad. They did respond to 320 and 768 respectively no matter what orientation.
For Android it's more unpredictable. I tested six browsers on a Huawei Ascend Y330 (Android default browser, Chrome, Opera, Firefox, Firefox Beta, Dolphin). The response vary depending on browser type and orientation.
I tested on a page with query (max-device-width: ***px) and to find out what px-value I need to fill in to get the query in a true state. Four different values were needed (320, 480, 534, 800) depending on browser type and orientation. This makes device-width unusable.
If you use max-width, when you change the size of the browser window on your desktop, you might be shown mobile-orientated styling, such as touch-friendly elements and menus and that kind of thing.
It's shocking to me that it seems to be popular opinion that this is desirable. I haven't figured out if fluid/liquid design before mobile was considered bad for the wrong or the right reasons. It appears to me that this is just a fancier version of liquid layout, but one that designers are embracing for some reason.
When the design community at large chose to side with fixed layouts over liquid in the mid 2000s, it was because text reflows impeded legibility often resulting in widows and other typogrphical artifacts. Additionally, maintaining the codebase was often tricky from design to design to keep elements from colliding etc. The only difference between liquid layouts and responsive design is that responsive, due to better browsers and the proliferation of masonry-like frameworks make it easier to accomplish.
I personally use min/max-device-width because I prefer to follow desktop document conventions that have decades of precedence. Not all documents you open on the internet are going to behave this way on a desktop, nor are other types of documents or applications that you load on your desktop. Pages designed before the dominance of mobile, just like MS Word, Photoshop, etc. hold their scroll positions and do not change their layouts allowing users to keep track of content within the page flow when performing the unrelated task of window management.
I generally use 3 breakpoints: one for phones, one for tablet and one for desktop. The desktop and often at least the landscape portrait are fixed and the tablet portrait and below are liquid. This combination of adaptive and responsive allows the desktop to behave like a desktop site while keeping me from needed to layout 10-odd separate fixed-width mobile device layouts. The text doesn't reflow on mobile devices because the viewport can't be resized.
참고URL : https://stackoverflow.com/questions/18500836/should-i-use-max-device-width-or-max-width
'program tip' 카테고리의 다른 글
| auto_ptr은 더 이상 사용되지 않습니까? (0) | 2020.10.17 |
|---|---|
| SqlParameter는 이미 다른 SqlParameterCollection에 포함되어 있습니다. using () {} 치트를 사용합니까? (0) | 2020.10.17 |
| Golang의 날짜 / 시간 비교 (0) | 2020.10.17 |
| Rails 3 + activerecord, 조건을 충족하는 모든 레코드에 대해 단일 필드를 "대량 업데이트"하는 가장 좋은 방법 (0) | 2020.10.16 |
| Xcode 4 + iOS 4.3 : "아카이브 유형에 대한 Packager가 없습니다." (0) | 2020.10.16 |