native vs negative? > 자유게시판

자유게시판

native vs negative? 정보

native vs negative?

본문

미디어 쿼리 없이 자스만으로 반응형 웹 구현하기 라는 허접한 팁에 대해 cshop 님이 토론할 꺼리를 던져주셨네요.
고맙습니다. 제가 관심 있는 주제에 대해 떠들 기회가 한번 더 생긴 것 같아서요.

발원지

cshop님의 주장은 다음과 같이 요약할 수 있습니다.

브라우저에서 css 로 지원하는 기능을 왜 굳이 무거운 library 를 사용해가며 구현해야 하는가?

native 하지 않아서 negative 하다는 재밌는 주장입니다. :)
말장난하기도 좋네요.ㅋㅋㅋ

좋은 지적이면서도 한편으로는 아쉬움이 남는 지적입니다.
왜그러느냐? 하면

1. 크로스 브라우징
2. jquery 사용의 편리함과 다른 이펙트 사용
3. css 만으로 해결할 수 없었던 문제

1. 크로스 브라우징

이건 cshop 님도 스스로 댓글에 달아놓으셨죠. ie 를 제외하면 모두 미디어 쿼리를 지원한다구요.
댓글 속에 답이 있습니다.

반응형 웹을 크로스 브라우징하기 위해선 respond.js 류를 한번 더 호출해야 합니다.
다음 2번에서 jquery 의 이펙트 사용까지 고려하면 어차피 호출해야 하는게 jquery 라는 거죠.

2. jquery 사용의 편리함과 다른 이펙트 사용

jquery 가 너비 계산용으로만 쓰기에는 무겁고 비효율적인 것은 인정합니다.
윈도우 창크기가 변경될 때 다시 한번 계산하도록 해놨는데, 열에 한번 정도 계산이 제대로 안 되는 경우가 있어서 사실은 library 사용을 하지 말아야 하나 하는 고민을 하는 것도 사실입니다.
근데 이게 jquery 를 써서 그런 건지, 제가 미숙해서 그런 건지도 아리송합니다. ㅎㅎㅎ;;

그런데 Test 하는 경우가 아니면 일반 사용자가 창크기를 열심히 늘렸다 줄였다 하는 경우는 매우 드물 것이라는 판단입니다. 또한 주말 저녁 잠들기 전 간단한 아이디어로 구현해보기에 jquery 만큼 효과적이고 쉬운 library 는 없는 것 같습니다.

물론 fade 효과 같은 다른 효과를 사용할 계획인 것도 있죠.

3. css 만으로 해결할 수 없는 문제가 있습니다.

문제보기


좋은 지적인 것은 제가 한번 더 생각해볼 기회를 주셨기 때문이고,
아쉬움이 남는 이유는 본문을 제대로 읽지는 않고 제목만 보고 어라 요놈 봐라? 식으로 달린 듯한 댓글 때문입니다. ;)

3번 문제는 css3 의 calculate 모듈? 함수?로 해결할 수 있을 것 같긴 한데, 안드로이드 뿐만 아니라 지원을 제대로 못하는 브라우저가 꽤 있는 것 같습니다. 1번 크로스 브라우징에 상충되는 문제점이죠.



그래서 저는 native 하지 않은 방법을 썼지만 positive 하다고 봅니다.
자 이제 cshop님 턴입니다.
추천
0
  • 복사

댓글 10개

저는 효율을 따지기 전에 개발의 용이성에 중점을 둡니다.
미디어쿼리가 사용하기 편한가 jQuery가 사용하기 편한가의 문제는 둘째치고, 일단 내가 개발하기 편한게 장땡입니다.
지운아벗님이 위에 쓰신 문제점을 해결 하기 위해선 당연히 JS가 도입되어야 하는 부분이고, 이왕 JS를 쓸꺼면 jQuery를 이용하는 편이 좋다고 생각합니다.
3. css 만으로 해결할 수 없는 문제가 있습니다. - 지운아빠님이 구현하고자 하는 것을 css 만으로 구현한 예제가 몇개 있으니 구글링 해보시구요. (자스나 css 나, php 나, 일단 내가 그걸 구현하고자 하기보다, 다른 사람들이 그런걸 구현한 적이 있는지 찾아보는 것도 나쁘지 않습니다.)

2. gilynh 님이 말씀하셨듯이 본인 능력 것/선호하는 방식으로 하시면 되는 겁니다. 단지 어짜피 jQuery 를 불러오는데, 내가 추가로 jQuery 코드 를 더 짜 넣는다고 페이지 로딩이 느려지는 것도 아니지 않느냐에 대해서는: 그렇지 않습니다.  잘못 이해하고 계신 겁니다.

1.  responsive layout 을 굳이 IE9 이하에서도 구현하시고자 한다면 (그 필요성이 뭐죠? 아이폰에서 IE8을 쓰는 사용자를 위해서?  저는 아이폰에서 어떻게 IE8 을 설치하는지도 모릅니다.) 는 요즘은 사스로

대응 하는 방식이 선호됩니다. 

https://github.com/jakearchibald/sass-ie

다운받아서 참조해 보세요.
3. 구글링 해보세요.
이 말이 전 참 아쉽네요. 링크라도 몇개 던져주실 줄 알았는데... :)
브라우저별 지원 스펙이 다른 css3 말고 css2.1 로 구현된 사례가 있다면 부탁드립니다. 가능하다면 js 가 완전히 배제되었다면 더 좋겠네요.
더군다나 calculate 는 본문에서도 말씀드렸지만 안드로이드에서는 지원이 원활하지가 않네요.

그래도 css 만으로 구현 가능하다는게 반갑네요. 제가 부족한 때문이겠죠?

2. cshop 님이 말씀하신 것들에 대해 합리적인 이유가 있다면
모자란 능력은 개발하면 되고, 선호도는 바꿀 수도 있는 것이라 생각하는데요. :)
선호도 따라서만 개발할 거라면 cshop 님에게 이렇게 다시 질문하지는 않았을 겁니다.

1. 반응형을 ie9 이하에서도 구현하고자 하는 이유는 사실 애매모호해 보일 수 있습니다.
굳이 이유를 붙이자면 저같은 경우 브라우저 크기가 항상 1024 이상으로 맞춰져 있지는 않습니다. 저만 그럴 것이라고 생각하기도 어렵구요.
제가 오히려 되묻겠습니다. 반응형을 모바일만 고려해야 하는 이유가 뭐죠?
pc 에서는 n스크린 환경을 고려할 필요가 전혀 없나요? 그렇다면 노트북이나 넷북은요? :)
저도 살짝 끼어들어가 보면, (원글 읽었을때) 두가지 궁금한 점이 있었습니다. (지운아빠님께 궁금한것이 아니라 제 자신이 궁금한 점 ^^;)

1. 미디어 쿼리 - 반응형 웹
말장난일수도 있지만, 반응형 웹을 하기 위해서 꼭 미디어 쿼리가 필요한지 입니다.
사실 고정 폭을 쓰지 않는다면, (원래) 웹은 어떤 스크린에서도 좌우스크롤없이 사용할 수 있을테니까요..
게다가 원하신 레이아웃을 어떻게 (화면 경계치별로 나누어서) 미디어쿼리로 구현할까 궁금하기도 했고요..

2. css 와 js
어제 원글을 봤을때 가장 궁금한 부분이,
원하시는 레이아웃 중 특히 좌우와 상단을 (동적으로) 같은 마진을 주는 것이 css (2.1)로 가능한지 였습니다.
어제 자기전에 간단히 검색해봤는데 잘 못찾겠더라구요..
그래서 cshop님이 링크몇개 알려주시길 내심 기대했구요.. ^^;

어쨋든 위 두분의 토론 계속 기대합니다.
1번은 처음 생각해보게 되네요. 워낙 미디어 쿼리가 일반적이라 그러려니 했던 면도 있는 것 같습니다.

사실 처음 출발은 사진을 그냥 쭉 좌에서 우로 나열하고 싶은데 마지막에 생기는 여백이 꼴보기 싫어서였습니다. css 만으로 크로스 브라우징이 되면서 해결할 방법이 있다면 저부터가 쌍수를 들고 환영합니다. ^^;;
크로스 브라우징이라고 말씀하시는데, 사실 IE 대응이죠.  IE9 이하 대응을 할것인가 말것인가. 그리고 데스트탑 resolution 에서 IE9 이하 대응을 한다면 어떤 방식으로 할 것 인가.

작년에도 전진님 한테 말씀드렸었지만, 저는 client-side responsive 에 회의적이었고, 결국 요즘 대세는 RESS 입니다.  오래전 부터 데스트탑에서 로딩되는 resource 와 모바일 플랫폼에서 로딩되는 resource 를 server-side 에서 추려내야 한다고 (이게 RESS 죠.) 얘기했었습니다.

저라면 모바일은 로딩 속도가 관건이니 무조건 media query 로, 데스트탑은 respond.js 나 css3-mediaqueries.js 같은 자스로 IE 대응을 하겠죠.  (대응해달라는 요구사항이 있다면.)  그리고 다들 이렇게 하구 있습니다.

그렇다고 이게 가장 좋은 방법이라고 말할수는 없죠. 

There are 100 different ways to skin a cat. - 고양이 가죽을 벗기는 방법은 100가지다. 

Stackoverflow 에서 얼마전 누가 이런 얘기를 하는데, 참 인상적이었습니다. 

* 그리고 생선은 누가 잡아주는걸 받아 먹는 것 보다, 직접 잡는게 더 재미있고 본인에게도 유익합니다.
대세란 말씀을 참 좋아하시는군요. 영어로 표현하자면 mainstream 쯤 되나요?

결국은 개발이나 운영에서 약점이 있기 때문이라기 보다는 본인의 '선호도'와 맞지 않기 때문에 문제제기를 하신 것으로 이해하면 될 것 같은데 맞는가 모르겠습니다.

고맙습니다. 더 생각해 볼 기회가 되었고, 나름대로 새로운 고민을 얻었네요.

* 낚시에서도 포인트라는게 있죠? 잘 잡히고 잘 안 잡히는 포인트요. 잘 잡히는 포인트를 아시는 것 같아 여쭤봤습니다.

좋은 하루 되세요.
시도 보다 대세가 먼저일 수 없습니다. 지운아빠님 처럼 이러한 방식을 접목해서 더 좋은 대세를 만들 수도 있는데 너무 비관적으로 보시네요..
두분의 대담이 개발자들의 방향제시에 큰~~~ 이정표가 되리란 생각에 추호의 의심이 없습니다.
좀더 깊이 있는 대담이 이루어 지고 향후의 방향을 잡는데 좋은 밑그름이 되기를 빌어 마지않습니다...
어쭙잖은 초보가 드리는 말씀에 노여워 마소서...^;^
© SIRSOFT
현재 페이지 제일 처음으로