레이블이 웹개발인 게시물을 표시합니다. 모든 게시물 표시
레이블이 웹개발인 게시물을 표시합니다. 모든 게시물 표시
2021년 9월 26일 일요일

2020년 CSS 사용 경향

The State of ~ 시리즈의 2020년 자료를 조금만 훑어보고 정리하자. 시간이 조금 지났기는 했지만 지금도 유의미하게 도움이 될 것이다.

The State of CSS


먼저 The State of CSS다. 2020년도에 CSS 개발자들의 생각을 다양한 통계를 통해서 엿볼 수 있다.


우선 The State of CSS 설문에 참여한 사람들 대부분은 영미권에서 CSS를 다루는 개발자들이다. 이를 감안하고 아래의 통계를 들여다 보자.


설문에 참여한 사람 절반 정도가 프론트엔드엔지니어였다. 그 다음 27.5%가 자신을 풀스택 엔지니어라고 했으며 세번재로는 17.2%의 사람들이 웹개발자였다.

예상대로 프론트엔드엔지니어들은 CSS를 능숙하게 다루어야 하니 가장 많은 사람이 CSS를 쓴다고 했다. 백엔드 개발자들은 고객과 만나는 최접점에 있는 화면단 기술인 CSS에는 무관심하였다. 의외로 UI/UX 디자이너들이 CSS를 다루는 사람이 적었다. 영미권에서도 이들은 그래픽 도구로 그림이나 화면 그리기만 끝내고 자신들의 할일을 끝내나보다.


70%에 가까운 사람들이 2010년 이후에 CSS를 다루기 시작한 사람들이다. 확실히 프론트엔드 쪽의 인기는 젊은 사람들에게 높다. 주니어들이 시니어들보다 더 잘 하는 분야이기도 하다. 10년에서 20년 정도 경력이면 나이대가 30대 후반에서 50대 초반인텐데 오랫동안 짬밥을 먹은 시니어들이다. 20년 이상인 사람들은 WWW이 시작할 때부터 이 분야에서 밥벌이를 한 사람들이다. 노년기에 접어든 사람들이 많을텐데 여전히 현역에서 뛰고 있는 게 대단하다. 우리나라도 이렇게 변해야 한다고 생각한다.


CSS 마스터 레벨 즉, CSS의 모든 선택자와 규칙에 대해서 90~100% 수준으로 다 알고 있다고 답한 사람이 5.5%나 된다. 정말 대단하다. CSS 마스터라고 자부하는 나도 가끔 신기한 선택자와 규칙들을 발견할 때가 있다. 그래서 100% 다 안다고는 절대로 말하지 못한다. 그런데 100%라고 대답하는 분들이 저렇게나 많다니 역시 세상은 넓고 고수는 많다.

지표를 보면 많은 CSS 개발자가 CSS의 전체 규칙 중에서 절반 조금 넘어서는 수준만을 알고 있거나 이해하고 있는 듯 하다. 물론, 실무를 하다보면 모든 걸 알아야 할 필요는 없다. 자주 사용하는 규칙들은 대부분 정해져 있고 한정적이다. 그래서 저 정도만 안다고 해서 특별히 실무를 하는데 큰 장애는 없을 것이다. 다만 하나라도 더 알면 어렵게 처리할 작업도 손쉽게 끝낼 수 있을 것이다.


분야별로 많이 쓰는 기능들을 묶은 것이다. 희미한 부분은 '기능을 사용하는 방법에 대해 알고 있다'는 것이고 그 안에 진하게 칠해진 것은 '실제 실무에서 사용한 적이 있다'는 것을 표시한다.

좀 의외인데 CSS를 다루는 사람들 대부분이 애니메이션과 관련된 기능을 굉장히 많이 알고 있고 또, 잘 쓰고 있다는 것이 놀랍다. CSS의 주된 기능은 일단 애니메이션 기능이 아니기 때문이다. 시맨틱하게 잘 구성된 네이키드 HTML 문서를 이용자들이 보기 좋게 옷을 입히는 것이 CSS 사용의 주된 목적이다.

그래서 기본적으로 당연히 사용해야 하는 font-family나 예전에는 float로 처리했지만 요즘은 레이아웃을 잡는데 flex를 많이 사용하니 저것들의 사용량이 높고 CSS 개발자들의 지식 수준이 높은 것도 이해는 한다. 애니메이션은 정말 의외였고, CSS를 이용해서 사용자 인터렉션이나 동적 효과를 주기 위해서 애니메이션을 조금 더 적극적으로 활용할 필요가 있겠다고 느꼈다.

Transitions, Transforms는 94%가 넘는 높은 사용률을 보였다. Animations도 91%가 넘는 이용자가 이용했다.


다른 건 나도 종종 쓰고 익숙한데 perspective라고 하는 신기한 프로퍼티가 보인다. 원근법이라고 하는데 완벽한 3D 기능을 구현할 수 있는 건 아니지만 이 기능을 사용하면 Z 축을 하나 만들어서 거리감을 표현할 수 있게 도와주는 것 같다. 나도 아직 완벽하게 이해는 안됐지만 대충 그런 것 같고 따로 시간을 내서 이 프로퍼티에 대해서 공부를 해봐야 할 것 같다. 잘 쓰면 재미있는 효과를 낼 수 있겠다. MDN Web DOC에 소개된 perspective


@font-face는 외부 폰트를 쓰려면 사용해야 하니 거의 대부분의 프로젝트에서 사용되는 듯 하다. line-break 프로퍼티는 CSS3에서 새로 추가된 것인데 CJK(한중일) 문장의 줄바꿈을 할 때 유용하다. 글자나 문자가 애매하게 잘리면 보기 싫게 되기 때문에.


calc()의 사용률이 92%에 육박할 정도로 올라왔다. 이제는 CSS 개발자들도 calc()를 능숙하게 쓰는 듯 하다. 예전에는 자바스크립트를 써야 했던 일부 계산을 calc()를 사용하면 CSS로 바로 처리할 수 있다. 예를들어서 가변적인 너비를 가진 컨테이너 안에 들어있는 block 엘리먼트의 너비가 컨테이너보다 항상 20픽셀 작은 상태에서 변동하길 원한다면 width: calc(100% - 20px)이라고 사용하면 된다. 정말 간단하다. +, - 기호 사이에는 공백이 있어야 한다.


사용하는 치수 단위는 당연하게도 고정값을 위한 px와 유동값을 위한 %가 가장 많다.

그 다음 vh, vw, em, rem은 모바일 기기나 반응형 웹에 대응하기 위해 많이 사용하는 치수들이다. vh와 vw는 각각 높인와 너비를 100등분 하여 기기의 높이나 너비 대비 얼마의 치수를 만들 것이냐 하는 것이고, em과 rem은 루트 엘리먼트의 폰트 크기로 부터 폰트 사이즈를 상속받아 폰트 사이즈를 반응형으로 대응하는데 사용된다. 실제로 모바일 페이지를 만들 때, px와 em, rem이 표현하는 방식이 매우 다른데, 각자 장단점이 있으니 프로젝트 특성에 맞게 사용하면 된다.

vmin과 vmax는 브라우저 지원이 아직은 불안정하다. 그래서 사용률이 확 떨어지지만 잘 알고 있으면 유용하다. 너비와 높이 중 더 긴 것을 vmax, 더 짧은 것을 vmin에 대응한다. 따라서 너비 300픽셀, 높이 1000픽셀의 기기가 있다면 1vmin은 3픽셀 1vmax는 10픽셀을 반환한다. 다양한 기기에 대응해야 하고 이 기기들의 정확한 높이와 너비에 맞는 div를 씌우고자 한다면 100vmax, 100vmin을 적용하면 된다. 사용하기 까다로운 height: 100% 같은 것을 사용하지 않아도 되고, 스크립트를 쓰지 않아도 된다.


역시 Pseudo Element 중 가장 많이 사용하는 것은 :before와 :after다. 과거에는 브라우저 지원이 미비해서 무작정 사용하기가 애매했지만 이제는 대부분의 최신 브라우저에서 잘 지원한다. :before와 :after를 잘 사용하면 불필요한 마크업 낭비를 줄이고 다양한 기교를 부리고 가상의 디자인적 요소를 표현할 수 있다.


이 부분은 CSS의 이름에서 알 수 있듯이 Cascading의 핵심인 부분이다. 자손 연결자는 당연히 100%가 사용되어야 하는 거 아닌가 하는 생각이 들었지만 사용률이 98%였다. 나머지 2%의 사람들은 그냥 직접 클래스나 아이디 선택자를 사용하고 자손 연결자는 사용하지 않는 것 같다

직속 자식만을 선택하는 > 선택자는 진짜 오래전에 브라우저들이 CSS의 기능들을 어설프게 지원할 때 후임 한명이 저걸 쓰길래 쓰지 말라고 엄청 혼냈었던 기억이 난다. 이제는 브라우저들이 잘 지원하기 때문에 자유롭게 써도 된다.

마크업을 잘 구성하고 CSS 설계를 잘 하면 +와 ~를 사용할 일은 거의 없지만 알아두면 급할 때 요긴하게 쓸 수 있을 것이다.


:first-child, :last-child, :nth-child()도 이제는 정말 많이 쓰인다. 모두 90%가 넘는 사용률을 보인다. 불과 몇년 전 까지만 하더라도 여전히 구형 브라우저를 사용하는 사람들이 많았다. 그래서 이게 편리하고 좋은 걸 알면서도 쓰지 못했다. 그래서 불필요하게 클래스 네임을 지정해서 별도로 스타일시트 구문을 추가하거나 스크립트로 컨트롤을 해야했다.

그러나 이제는 간단하게 가장 첫번째 요소, 마지막 요소, 그리고 원하는 순서의 요소, 특정한 순서 패턴의 요소들을 CSS만으로 간단하고도 자유롭게 컨트롤 할 수 있게 되었다.

아래의 의사결정 클래스들도 정말 유용한 것이 많지만 아직 사용률이 낮은 것은 그만한 이유가 있다. 다양한 기기와 브라우저 대응이 아직은 어렵기 때문이다.


엘리먼트의 속성에 접근하는 선택자도 이제는 정말 많이 쓴다. ele[foo="bar"]의 사용률은 95%가 넘는다. ele[foo]도 브라우저 지원율이 높지만 ele[foo="bar"]가 더 많이 쓰이는 이유는 폼의 동적인 부분을 스크립트로 처리하지 않고 CSS만으로 처리할 수 있기 때문이다.

체크박스나 라디오버튼을 예로 들면, 박스가 체킹 되었을 때와 체킹이 해제되었을 때 디자인을 따로 적용할 수 있는데, 예전에는 이런 부분을 별도 CSS클래스를 작성하여 스크립트로 처리하였다.

그러나 지금은 checkbox[checked="checked"]와 같이 체크가 되었을 때 상태 한줄만 추가하면 된다. 폼 요소의 경우 이것마저 줄일 수 있는데 :checked로 간단하게 컨트롤이 가능하다.

이와 같은 방법으로 스크립트로 처리할 부분의 상당 부분을 CSS에서 처리할 수 있으니 UI 드로우 처리가 훨씬 빨라질 수 있고 개발도 편리하다.


:link, :visited와 같은 선택자는 설명할 것도 없이 유명하고 앵커 태그 등에서 웹 초창기부터 자주 쓰이던 고전적 선택자다. 


:hover, :focus:, :active 클래스는 엘리먼트가 마우스의 위에 올라 가 있는지, 엘리먼트에 포커싱이 되어 있는지를 감지하여 스타일링을 할 수 있다. 이 역시 오래도록 애용되고 있는 고전적인 선택자다. 앵커 태그에서는 상당히 잘 작동하지만 앵커 태그 이외의 엘리먼트에서는 일부 브라우저에서 동작이 되지 않을수도 있으니 체크하면서 작업을 해야한다.


폼 요소들의 상태를 체크할 수 있는 CSS 선택자들이다. :checked와 같은 것은 널리 쓰이고 있으며 자바스크립트를 사용하지 않고도 라디오 버튼이나 체크박스의 상태를 자유롭게 디자인 할 수 있기 때문에 편리하게 사용할 수 있다.

폼의 활성 상태를 체크하는 :enabled, :disabled와 같은 선택자도 유용하게 쓸 수 있으며 기본 요구사항을 감지하는 :required와 같은 선택자도 유용하게 사용할 수 있다. 대부분의 브라우저에서 잘 지원한다. 그러나 일부 선택자는 11이상의 높은 버전의 브라우저에서도 지원되지 않을 수 있으니 확인을 해가면서 사용을 할 필요가 있다.

폼 요소들의 상태를 체크하는 CSS 선택자는 잘 알아두고 활용하면 스크립트 작업 노가다 시간을 많이 줄일 수 있다.


Sass의 경우에는 설문에 참여한 대부분의 CSS 개발자가 만족하고 있으며 사용하고 있는 기술이라고 답변했다. 이것을 보면 이제는 단순한 퍼블리싱이든 전문 FE를 하던 세계적 추세는 FE 환경에서 CSS를 개발하고 또 Sass와 같은 전처리기를 쓰는 것이 대세를 넘어 기본이 되었음을 알 수 있다. Sass를 아직 안 써 본 CSS 개발자는 없겠지만, 혹시 계시면 써 보시길 추천한다. 정말 끝내준다! 한번 사용하면 CSS 날코딩의 세계로 돌아갈 수 없다.

한때 대세로 여겨졌던 BEM 방법론은 만족하는 사람이 많지만 모든 사람이 BEM 방법론을 따르는 것은 아니다. 부트스트랩 CSS 프레임워크는 아주 많은 사람들이 사용해 본 적이 있지만 만족도는 지극히 낮았다.

눈여겨 볼 것은 PostCSS와 Tailwind CSS다. 사용해 본 사람들은 만족도가 아주 높다고 답했다. 그러나 아직 덜 알려져 있어서 이를 사용해 보았다는 사람은 매우 적었다.

PostCSS는 300여개에 달하는 플러그인을 사용할 수 있도록 도와주는 도구인데 CSS의 문법을 확장하거나 CSS 코딩을 매우 편리하게 만들어주는 도구들을 지원한다.

Tailwind CSS는 부트스트랩과 비슷한 CSS 프레임워크다. 정해진 디자인이 일관적이라 유틸리티 퍼스트 개발에 유리하고, 부트스트랩에 비해서 커스타마이징이 용이해서 만족도가 높다.

이 부분에서 새롭게 공부할 기술들이 몇가지 추가되었는데, PostCSS에 대해서는 꼭 한번 들여다 봐야겠다.


전처리기를 사용하였다는 의견은 전반적으로 다 높아졌다. 갈수록 CSS 작업을 할 때 날코딩이 아니라 전처리기를 거치는 것이 자리 잡고 있음을 느낀다. Less를 제외한 Sass, Stylus, PostCSS가 모두 사용한다는 응답이 늘었으며 특히 PostCSS의 사용량이 빠르게 증가하고 있다.


전처리기 사용 만족도는 Sass보다 PostCSS가 더 높았다. 전처리기 사용을 한다면 Sass 또는 PostCSS를 사용하는 것이 좋겠다. 특히, PostCSS는 Sass의 만족도가 소폭 감소한 상황에서도 되레 만족도가 더 높아지는 경향을 보여주었다. PostCSS 공부 욕구가 뿜뿜하지 않는가?


CSS 개발자들은 Sass에 대해 거의 대부분 인지를 하고 있었고, PostCSS에 대한 인지도가 빠르게 올라오고 있는 것도 확인할 수 있다. 조만간 PostCSS가 Sass의 인기를 밀어낼지도 모르겠따. 둘은 특성이 조금 다르기는 하지만 교집합도 많다.


개인적으로 CSS 프레임워크를 사용하는 것은 좋아하지 않는다. 밑단부터 하나하나 만들어 올라가는 걸 좋아하는데 의외로 CSS 프레임워크도 많이들 사용하는 것 같다. 우선 앞에서도 이야기가 잠깐 나왔던 테일윈드 CSS 프레임워크의 만족도가 높다.


인지도만 놓고 보면 부트스트랩이 단연 압도적인데 사용 후 만족도는 높지 않았다. Tailwind CSS는 최근에 인지도를 급격히 키워나가고 있다. functional한 CSS 이용이 가능한 프레임워크라서 이 트렌드에 올라탄 것으로 보인다.


프로젝트에서 테일윈드를 사용했다는 응답이 2019년 6%에서 2020년에 무려 26%로 20%p나 증가했다. 만일 CSS 프레임워크를 도입할 예정이라면 현재 시점에서는 테일윈드 CSS에 대해서 검토해 보는 것이 좋겠다는 생각이 든다. 가볍게 잘 만든 프레임워크인 것 같다. https://tailwindcss.com/

물론 나는 CSS 프레임워크를 쓸 생각이 없지만.


현재 가장 널리 알려져 있고, 많이 사용되는 CSS 코딩 방법론은 BEM 방법론이다. 어느 정도 규율이 있는 개발팀이라면 BEM 방법론을 도입한 곳이 많을 것이다.


그런데 CSS개발자들이 가장 만족감을 느끼는 방법론은 Atomic CSS 방법론이라는 서베이 결과가 나왔다. 물론 만족도는 BEM 방법론도 이에 뒤지지 않게 높았다.

Atomic CSS 방법론은 최근에 주목 받고 있는데 간단히 몇가지 특징을 언급하면 다음과 같다. Atomic CSS 방법론의 철학은 마크업과 CSS 파일이 애초에 분리된 게 이상하지 않느냐? 기본으로 돌아와서 템플릿 작업을 하면서 한꺼번에 스타일 작업도 하는게 논리적으로 맞지 않느냐는 가치관을 가지고 있다.

클래스 하나에 CSS 밑단 속성 하나가 대응된다. 검정색 1픽셀 선을 표현하는 border: 1px solid #000이라는 속성이 있다고 하면 이것을 .b10이라는 형태의 클래스로 만들고, 이것을 템플릿에서 직접 사용하는 것이다. 클래스 하나에 두가지 이상의 스타일시트 속성이 들어가면 Atomic CSS 규칙 위반이다.

장점은 CSS 작업을 할 필요없이 템플릿 작업과 동시에 스타일 작업을 할 수 있다는 것이다. 그리고 죽은 CSS 코드가 거의 발생하지 않고, CSS의 크기도 줄일 수 있다. 그리고 functional 하기 때문에 직관적이다.

단점은 구현하고자 하는 CSS 스타일이 미리 다 구현이 되어 있어야 한다는 점이다. 그리고 사용하고자 하는 속성에 대응되는 클래스 이름을 모두 사전에 인지하고 있어야 하므로 익숙해 지기 전까지는 러닝 커브가 높다는 점이다.


역시 에디터는 Visual Studio Code가 대세!


브라우저 테스트는 역시 크롬 사용률이 압도적이다. 여전히 파이어폭스를 개발 테스트용 브라우저로 많이 쓰는 것은 신기하다. 익스플로러는 이제 거의 사장되어 가는 분위기다. MS에서도 더 이상 지원을 안한다고 하였으니. 여러모로 프론트엔드 개발자들에게는 다행이고 신나는 시절일 것이다. 옛날에 IE 6, 7, 8 맞추던 시절이 정말 최악인 시절로 기억될 것이다.


2020년 4월 1일 수요일

a와 button을 용도에 맞게 사용하기

출처 : unsplash.com

오랜만에 개발 관련 글을 쓴다. 아주 기초적인 부분인데 놓치고 있던 부분이 있어서 기록으로 남겨둔다. 코딩하는 습관은 한번 익숙해지면 고치기가 어렵다. 나는 여러가지 안 좋은 습관을 가지고 있다.

그 중 제발 좀 고치자 싶어서 노력하는 부분이 하나 있다. 바로 링크가 아닌 곳에서 <a>태그의 사용을 지양하는 것이다.

앵커 태그


WWW의 근간을 이루는 기술 중 하나는 HTML이다. HTML이라는 이름에도 들어 있듯이 HTML문서는 '하이퍼텍스트' 문서다. 하이퍼텍스트의 근간은 하이퍼 링크이며 이 하이퍼링크를 위해 존재하는 것이, 기본적으로 <a>태그이다.

<a>태그는 'href' 요소와 결합하여 하이퍼링크를 만든다.

따라서, <a> 태그는 페이지 간의 이동을 위해 링크를 생성할 때만 사용해야 한다. 기본중에 기본인데 과거에는 <a>태그에 href="#"을 넣거나, javascript:; 와 같은 것으로 페이지 링크와 스크립트 호출을 막아놓고, 동적 UI를 만들 때 버튼 기능으로 많이 사용했다. 이것이 시간이 흐르고 손에 굳어버리니 계속 이 방법을 고수했다. 이는 의미에 맞지 않는 매우 잘못된 마크업 사용법이므로 하이퍼링크 생성 이외에 페이지 내의 동적 UI 작성을 할 때는 <a> 태그의 사용을 지양하자.

버튼 태그


2000년대 중반부터 AJAX 기법이 널리 확산되었다. 그리고 나중에는 모바일 시대가 열리면서 SPA 앱 개발 방식도 널리 사용되었다. 웹페이지나 모바일 페이지는 심플하면서도 복잡해졌다. 어떤 인터렉션이 있기전에는 심플해졌고, 거기서 무언가 인터렉션이 발생하면 점점 복잡한 속살을 드러낸다.

지금의 웹페이지나 모바일웹 사이트들은 페이지 이동을 하지 않은 상태에서 수 많은 동작과 인터렉션을 요한다. 이런 페이지 내 기능들을 사용할 때 <a>태그 대신 <button> 태그를 사용하는 것이 조금 더 논리에 맞지 않을까 생각한다.

버튼 태그는 기본적으로 <input> 요소로 구현이 가능하다. 이 경우에는 form의 submit이나 reset 기능도 사용이 가능하다.

다만, <a>태그 대용으로 사용할 경우에는 이렇게 사용하지 말고 <button>..</button>으로 독립적 마크업을 사용하자. 이렇게 사용하면 버튼 안에는 이미지를 비롯해서 <span>등 다른 요소를 넣어서 조금 더 디테일한 스타일링도 가능하다.

W3C 링크


앵커 태그 명세 : https://www.w3.org/MarkUp/1995-archive/Elements/A.html
버튼 태그 명세 : https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#the-button-element

2020년 4월 1일
송종식