Web Platform

UI를 만들다 보면 내용은 없는데 wrapper만 남는 경우가 있다. 카드의 보조 설명 영역, 필터 결과 안내 영역, 혹은 children을 받아서 그리는 작은 레이아웃 컴포넌트가 그렇다. 실제로 보여줄 내용은 없는데 padding이나 border가 적용된 부모 요소만 화면에 남으면,…

화면 전환은 늘 애매한 영역이었다. 기능 명세에는 잘 안 들어가지만, 막상 없으면 서비스가 묘하게 둔하게 느껴진다. 목록에서 상세로 들어갈 때, 필터를 바꿨을 때, 카드가 확장될 때 화면이 자연스럽게 이어지면 사용자는 “빠르다”고 느낀다. 반대로 데이터는 이미 바뀌었는데 화면만 툭 끊기…

이 포스트는 Sunkanmi Fafowora가 CSS-Tricks에 올린 CSS Color Functions 게시글을 번역한 것이다. 번역하는 과정에서 다소 의역이 있을 수 있으며, 일부 번역에는 사견이 포함되어 있기도 하다. 웹에서 색을 다루는 일은 이상하게 만만해 보인다. #000,…

CSS는 오랫동안 정적인 선언 언어처럼 다뤄졌다. 물론 calc()도 있고, 커스텀 속성도 있고, 미디어 쿼리나 컨테이너 쿼리도 있으니 실제로 그렇게 단순한 언어는 아니다. 그래도 반복되는 계산이나 디자인 시스템의 규칙을 재사용하려고 하면 금방 한계가 보인다. 값은 변수로 빼둘 수 있지…

모달과 팝오버를 칼로 베듯 나눠서 생각해본 적은 별로 없었다. 화면 한가운데 떠서 다른 작업을 막으면 모달, 버튼 옆에 붙어서 옵션이나 보조 정보를 보여주면 팝오버, 정도로 느슨하게 이해하고 있었다. 실제 UI를 만들 때도 대체로 그 정도 감각이면 굴러간다. 문제는 브라우저가 이 둘을…

프론트엔드 개발자들이 모인 자리에서 “어떤 스타일링 도구 좋아하세요?”라고 물어보면 못해도 30분은 이야기할 수 있다. 내 경우에는 여러 번 말했듯이 Tailwind CSS와 CSS Module을 선호한다. 그런데 이 취향을 말하면 거의 정해진 질문이 돌아온다. “그거 동적 스타일링하기…

박스의 높이를 제한해 두면, 내부 콘텐츠가 많아질수록 넘침(overflow)은 피하기 어렵다. 가장 단순한 해결책은 overflow: hidden이다. 하지만 그렇게만 두면 텍스트가 그냥 잘려 나간다. 사용자는 뒤에 내용이 더 있는지 알기 어렵고, 화면은 어딘가 덜 만든 것처럼 보인다.…

우리는 보통 브라우저 주소창에 URL을 입력하고 엔터를 누르는 것으로 네트워크 통신을 시작한다. 하지만 그 짧은 동작 뒤에는 수많은 프로토콜과 계층이 맞물려 동작하는 복잡한 과정이 숨어 있다. 요청 하나가 서버에 도달하고, 다시 응답이 돌아오기까지 컴퓨터는 생각보다 훨씬 많은 일을 처리…

웹 애플리케이션을 만들다 보면 반응형 디자인은 거의 기본값처럼 따라온다. 화면 크기와 디바이스가 워낙 다양하니, UI가 좁은 화면과 넓은 화면에서 다르게 보이는 일 자체는 특별하지 않다. 오래 동안 이 역할은 CSS 미디어 쿼리가 맡아왔다. 뷰포트 너비를 기준으로 레이아웃을 바꾸는 방식…

요즘 백엔드를 만지작 거리면서 계속 '이런 상황에서는 내가 어떤 상태코드로 리스폰스를 돌려보내야 하는 거지?'하는 의문이 들었다. 프론트 할 때는 크게 신경쓰지 않고 대충 숫자가 200대면 문제 없구나, 300대면 어디 다른 데로 가야하는 구나, 400대면 내가 문제가 있구나, 500대…

상황 진행중인 프로젝트에서 기존에 사용하던 module css가 아닌 tailwind를 사용하기로 결정되었다. 작업 빨리 쳐내야 할 때 클래스 검색하는 거로 시간을 쓰는 게 싫어서 공식문서도 읽고 카카오FE의 사용 후기도 읽어보면서 이것저것 테스트해보는 시간을 가지고 있었다. tailw…

프론트엔드 개발을 하다 보면 자연스럽게 “이 상태를 어디에 저장해야 하지?”라는 질문과 마주하게 된다. 로그인 상태, 테마 설정, 폼 입력 값, API 응답 캐시, 오프라인 대응 데이터까지. 이 모든 것은 결국 브라우저 어딘가에 저장되어야 한다. 브라우저는 이미 여러 가지 저장 수단을…