아래 어떤 분이 남기신 CSS스프라이트 기법에 관한 토론... 정보
아래 어떤 분이 남기신 CSS스프라이트 기법에 관한 토론...
본문
http://www.w3schools.com/css/css_image_sprites.asp
CSS스프라이트 기법에 관한 토론을 해보고 싶은데요..
어디에 사용하면 좋고,
어떤 점이 도움이 되는지.. 등등...
알고 계신 내용을 함께 나누면 어떨까 싶네요 ^^
스프라이트 기법을 사용함으로서
서버의 요청이 줄어들어 웹사이트의 속도가 빨라진다는 장점이 있으나,
(사실 이 장점이 엄청 크다는...)
일일히 좌표를 구해야 하는 번거로움이 있고,
(요즘은 좌표구해주는 사이트도 있는 것 같던데...)
네비게이션에서 사용할 경우, 메뉴가 늘어나거나 줄어들었을 때,
전체를 수정해야하는 귀차니즘이 있다는...
여러분들의 생각을 들려주세용 ^^
추천
0 비추천
0
0 비추천
0
댓글 14개
네이게이션에서 사용 안하는걸 추천합니다. ^^;
그렇죠, ㅎ
안그래도 퇴사한 선배가 만들어 놓은 사이트 유지보수 담당하게 되었는데,
네비게이션을 그렇게 만들어놔서 ㅠ ㅠ
메뉴가 하나 늘어났다가 줄어들었다가 하는데 무척 귀찮더라구요...
그럼 어디에 사용하는 것이 가장 좋다고 보세요?^^
안그래도 퇴사한 선배가 만들어 놓은 사이트 유지보수 담당하게 되었는데,
네비게이션을 그렇게 만들어놔서 ㅠ ㅠ
메뉴가 하나 늘어났다가 줄어들었다가 하는데 무척 귀찮더라구요...
그럼 어디에 사용하는 것이 가장 좋다고 보세요?^^
기본적으로는 추가로 늘어나지 않는 곳이 가장 좋겠죠.
최근에는 이미지를 최대한 안 쓰는게 대세라 저는 거의 이미지를 안 쓰려고
노력합니다만... 그래도 아이콘쪽은 확실히 쓰는게 좋다고 생각합니다.
물론 저는 안 만들어 씁니다만... T.T
메뉴쪽은 쓰면 유지보수에서 너무 문제가 커서...
쇼핑몰 만들때 기존 분이 그런 방식으로 쓴 게 있어서 맞춰서 수정 작업을 한 적이
있는데 죽는줄 알았습니다.
결론은 쓸데만 쓰자. 참 쓰고보니 쓸데 없는말을 길게 썼네요. -.-
최근에는 이미지를 최대한 안 쓰는게 대세라 저는 거의 이미지를 안 쓰려고
노력합니다만... 그래도 아이콘쪽은 확실히 쓰는게 좋다고 생각합니다.
물론 저는 안 만들어 씁니다만... T.T
메뉴쪽은 쓰면 유지보수에서 너무 문제가 커서...
쇼핑몰 만들때 기존 분이 그런 방식으로 쓴 게 있어서 맞춰서 수정 작업을 한 적이
있는데 죽는줄 알았습니다.
결론은 쓸데만 쓰자. 참 쓰고보니 쓸데 없는말을 길게 썼네요. -.-
감사합니다 ^^
저도 되도록이면 이미지를 안쓰고 싶은데,
고객들이 원하는 건 좀 다른 것 같아요 ㅠ ㅠ...
이미지로 표현하지 않으면 안되는 것들이라든가... 참 어렵네요 ^^
저도 되도록이면 이미지를 안쓰고 싶은데,
고객들이 원하는 건 좀 다른 것 같아요 ㅠ ㅠ...
이미지로 표현하지 않으면 안되는 것들이라든가... 참 어렵네요 ^^
저같은 경우는 일단 불릿같은 작은 아이콘을 모아서 세로로 한 줄 배치해서 사용하구요~
메뉴 네비게이션은 (요즘은 텍스트로 많이 처리해서 사용빈도가 줄 긴 했지만) header나 footer에 공통으로 쓰이는 이미지들을 한꺼번에 모아서 (물론, 하기 어려운 큰 이미지들은 문맥을 보고 넣을 때도 있고, 안넣을 때도 있고요) common.png 로 처리하는데, 이게 몇년하다보니 추가나 수정될 꺼를 고려해서 배치하게 되더라구요~
간격은 아래와 같이 10px단위로 끊어서 나열하기때문에 좌표를 구하는데, 딱히 힘든 점은 없어요.
그리고 컨텐츠에 들어가는 이미지나 사진등은 그냥 이미지처리 처리하구요~
(뭐, 요것도 상황에 따라서 스프라이트 할 만한하면 하구요~ㅎ)
결론은, 사이트의 특성에 맞게 스프라이트 하는 이미들을 분류해서 만들어요~
그리고, 유지보수는 생각만큼 헬게이트는 아니던데...
제가 배치하는 스타일이 바둑판 처럼 막 따닥따닥 놓는 게 아니라, 추가될 부분을 생각해서 세로로 아니면 가로로 배열하는 스타일이라~ㅎ
추가나 수정의 경우는 그냥 추가하면 되는거고~삭제의 경우는 공간의 비효율성은 좀 있겠네요ㅎ
(삭제한다고 해서 그만큼 공간을 땡겨서 다시 배치하지는 않고 있어요ㅜㅜ)
제가 이미지 스프라이트를 사용하는 이유는..
퍼포먼스 측면이 제일 크긴 합니다만~
이미지를 일일이 자르기 보다 PSD, CSS 둘 다 제작, 관리하기가 더 쉬운 것 같아요.
그리고, hover했을 때 백그라운드 포지션만 바꾸면 되니깐, 이미지 교체같은 기능도 스크립트를 안써도 되고~
모바일에서 레티나를 대응해서 이미지 해상도를 바꿔줄 때도 백그라운드 사이즈만 사용하면 되니깐 편한 것 같아요~
적고보니, 마지막 2개는 IR 기법의 장점에 더 적합하긴 하네요ㅎ
메뉴 네비게이션은 (요즘은 텍스트로 많이 처리해서 사용빈도가 줄 긴 했지만) header나 footer에 공통으로 쓰이는 이미지들을 한꺼번에 모아서 (물론, 하기 어려운 큰 이미지들은 문맥을 보고 넣을 때도 있고, 안넣을 때도 있고요) common.png 로 처리하는데, 이게 몇년하다보니 추가나 수정될 꺼를 고려해서 배치하게 되더라구요~
간격은 아래와 같이 10px단위로 끊어서 나열하기때문에 좌표를 구하는데, 딱히 힘든 점은 없어요.
그리고 컨텐츠에 들어가는 이미지나 사진등은 그냥 이미지처리 처리하구요~
(뭐, 요것도 상황에 따라서 스프라이트 할 만한하면 하구요~ㅎ)
결론은, 사이트의 특성에 맞게 스프라이트 하는 이미들을 분류해서 만들어요~
그리고, 유지보수는 생각만큼 헬게이트는 아니던데...
제가 배치하는 스타일이 바둑판 처럼 막 따닥따닥 놓는 게 아니라, 추가될 부분을 생각해서 세로로 아니면 가로로 배열하는 스타일이라~ㅎ
추가나 수정의 경우는 그냥 추가하면 되는거고~삭제의 경우는 공간의 비효율성은 좀 있겠네요ㅎ
(삭제한다고 해서 그만큼 공간을 땡겨서 다시 배치하지는 않고 있어요ㅜㅜ)
제가 이미지 스프라이트를 사용하는 이유는..
퍼포먼스 측면이 제일 크긴 합니다만~
이미지를 일일이 자르기 보다 PSD, CSS 둘 다 제작, 관리하기가 더 쉬운 것 같아요.
그리고, hover했을 때 백그라운드 포지션만 바꾸면 되니깐, 이미지 교체같은 기능도 스크립트를 안써도 되고~
모바일에서 레티나를 대응해서 이미지 해상도를 바꿔줄 때도 백그라운드 사이즈만 사용하면 되니깐 편한 것 같아요~
적고보니, 마지막 2개는 IR 기법의 장점에 더 적합하긴 하네요ㅎ
구체적인 이야기 감사드립니다 ^^
IR기법이라는 단어는 처음들어봤어요 !
검색해 보니까, 사용한 적은 있는 방법이긴 했는데, 확실히 단어까지 알게 되어서
많이 배우게 됩니다 감사합니다 ^^
확실히 전 페이지에 사용하는 버튼 등은 스프라이트 이미지를 사용하는 것이 편리할 것 같네요!
아직 혼자서 사이트를 전부 다 만들어본 적이 없어서 (부끄부끄)
첫 작업이 오면 꼭 해보고 싶네요!!
어떤 방법이 좋을까 항상 고민하면서 작업하는 것이
우리들의 역할이 아닐까 싶었어요 ㅎㅎ
IR기법이라는 단어는 처음들어봤어요 !
검색해 보니까, 사용한 적은 있는 방법이긴 했는데, 확실히 단어까지 알게 되어서
많이 배우게 됩니다 감사합니다 ^^
확실히 전 페이지에 사용하는 버튼 등은 스프라이트 이미지를 사용하는 것이 편리할 것 같네요!
아직 혼자서 사이트를 전부 다 만들어본 적이 없어서 (부끄부끄)
첫 작업이 오면 꼭 해보고 싶네요!!
어떤 방법이 좋을까 항상 고민하면서 작업하는 것이
우리들의 역할이 아닐까 싶었어요 ㅎㅎ
맞아요ㅎ
갈수록 이것저것 고민하는 시간이 더 늘어나서...
이 연차에도 불구하고 손이 느려요ㅠㅠ
갈수록 이것저것 고민하는 시간이 더 늘어나서...
이 연차에도 불구하고 손이 느려요ㅠㅠ
혹시 sprite 에 background-size 적용 어떤 식으로 작업하시는지 여쭤도 될까요?
저는 보통 클래스로 공통으로 한 번 이렇게 선언해주고 써요~
.icon {background-image: url(img_320.png); background-size: 200px 200px;}
@media screen and (-webkit-min-device-pixel-ratio:2) {
.icon {background-image: url(img_640.png)}
}
(잘 아시겠지만, img_640.png는 실제로는 400*400 짜리~)
그리고, 포지션은 한 번만 쓰면 되니깐...
뭐, 별다른 특별한 방법을 쓰는 건 아니라능ㅎㅎ
.icon {background-image: url(img_320.png); background-size: 200px 200px;}
@media screen and (-webkit-min-device-pixel-ratio:2) {
.icon {background-image: url(img_640.png)}
}
(잘 아시겠지만, img_640.png는 실제로는 400*400 짜리~)
그리고, 포지션은 한 번만 쓰면 되니깐...
뭐, 별다른 특별한 방법을 쓰는 건 아니라능ㅎㅎ
네 한번 써봤다가 제 생각대로 안 돼서 말았었거든요.
오늘 마침 글 읽고 잠깐 찾아보니 제가 잘못 썼던거더라구요.
답글 감사 ^^
오늘 마침 글 읽고 잠깐 찾아보니 제가 잘못 썼던거더라구요.
답글 감사 ^^
아, 넹넹ㅎㅎ
혹시 더 좋은 방법이나 새로운 기술있으면 좀 알려주세욥^^
혹시 더 좋은 방법이나 새로운 기술있으면 좀 알려주세욥^^
어섬 폰트 같은것만 사용하네요.
그외에는 귀찮아서 사용안함.
그외에는 귀찮아서 사용안함.
sp 보단 ir 로 하는게 더 유지보수가 편리하죠..
sp 로 해놓고 나중에 내용물이 많이 바뀌면 골치아픔;;;;
sp 로 해놓고 나중에 내용물이 많이 바뀌면 골치아픔;;;;
온라인 툴은 http://spritegen.website-performance.org/ 같이 많이 존재하구요.
기본적으로 sp 사용을 많이 하는데 모바일웹 (앱에서 앱뷰처리하는) 부분에서 많이 사용했었네요.
로고 이전 다음 버튼 등등 디폴트로 사용되는 부분을 각각 불러오는거보다 한번에 불러와서 좌표 쏴주는게 여러모로 이득이였습니다. 하지만 복잡한 페이지에서의 사용은 별로 추천하고 싶지 않네요.
이미지에 많은걸 넣다보면 오히려 단독으로 가져오는거보다 속도도 좋지 않고 유지보수에는 쥐약입니다.
기본적으로 sp 사용을 많이 하는데 모바일웹 (앱에서 앱뷰처리하는) 부분에서 많이 사용했었네요.
로고 이전 다음 버튼 등등 디폴트로 사용되는 부분을 각각 불러오는거보다 한번에 불러와서 좌표 쏴주는게 여러모로 이득이였습니다. 하지만 복잡한 페이지에서의 사용은 별로 추천하고 싶지 않네요.
이미지에 많은걸 넣다보면 오히려 단독으로 가져오는거보다 속도도 좋지 않고 유지보수에는 쥐약입니다.
