2016년 9월 미국 보스턴에서 진행된 CSSCONF 참관기를 공유합니다. 배영, 김세희님이 실을 대표해 참관해 주셨고, 본 후기를 직접 작성해 주셨습니다. 내용이 다소 길어 2편으로 작성합니다.
컨퍼런스 소개
CSSConf는 OOCSS로 유명한 니콜 설리반(Nicole Sullivan)이 주축이 되어 2013년 미국에서 첫번째로 개최되었습니다. 그 후로는 유럽, 호주, 아시아 등 세계 곳곳에서 열리고 있습니다. 컨퍼런스 대상은 세상에서 가장 멋진 UI 개발을 위해 노력을 마지않는 디자이너와 개발자입니다. 각 세션 발표자들은 참석자들에게 CSS 관련 각종 최신 기술과 테크닉, 툴에 관한 설명을 해줌으로써 가능한 최대로 CSS의 사용성을 높이고자 하는 목표를 가지고 있습니다.
저희는 이번에 보스턴에서 이틀동안(9/26-27) 열린 CSSConf US에 참석했습니다. 장소는 캐주얼한 분위기의 스탠드업 코미디 전문극장인 Laugh Boston에서 개최되었습니다.
컨퍼런스는 총 16개의 세션으로 이틀동안 진행되었는데, 오전에 3개의 발표를 듣고 90분의 점심시간 후 다시 3개, 그리고 30분의 휴식을 가진 뒤 2개를 듣고 끝나는 구성으로 아침부터 저녁까지 이어지는 발표 내용에 세션 내용을 소화하기 조금 빡빡한 감이 있었습니다. 또한 실시간 자막 CART가 제공되었는데, 이는 2016년 네이버 본사에서 열렸던 널리 세미나에서 쉐어타이핑 기술을 통해 자막을 제공해 주었던 것과 동일한 역할을 하였습니다.
청각 장애인 뿐만 아니라 영어가 제 2외국어인 사람, 억양이 강한 발표자, 자리가 멀어 잘 들리지 않는 사람, 기록 목적 등 모두의 편의를 위한 목적으로 자막이 제공되었기 때문에 유니버셜 디자인의 한 부분을 직접 체험해는 좋은 기회였습니다. 다만 아직은 일일히 스크립터가 듣고 입력하는 것이기 때문에 오타가 있거나 문장이 미완성되는 내용이 일부 있었습니다. 발표 영상은 각각 녹화되어 유투브에 업로드되었기 때문에 내용을 다시 확인 가능합니다.
각 세션은 약 35분간의 프리젠테이션과 컨퍼런스 공식 트위터 계정으로 선정된 질문을 대답하는 시간으로 이루어졌습니다. SassConf, GothamSass의 공동 설립자 클라우디나(Claudina Sarahe)의 간단한 인사와 함께 컨퍼런스가 시작되었습니다.
세션요약
전체 세션 주제를 임의대로 나눠보자면, 크게 네 가지로 볼 수 있습니다. 첫째로는 기존에 꽤 논의가 되었지만 중요하기에 재소개된 주제입니다. 둘째는 최신 CSS 스펙에 관한 주제이고, 셋째는 특정 플랫폼이나 프레임워크를 소개하는 주제, 그리고 마지막으로는 코딩에 대한 새로운 시각을 부여해주는 주제입니다.세션요약
# 새롭지는 않지만 중요하기에 재소개된 주제
1. UI 테스트: 버그 보이지 않음 (No Bug in Sight)
[embedyt] http://www.youtube.com/watch?v=8nSUIAFpNhE[/embedyt]
code.org에서 소프트웨어 엔지니어로 일하고 있는 브라이언 조단(Brian Jordan)은 시각적 테스트를 진행하면서 어떤 과정을 밟아왔는지 그 여정에 대해 발표했습니다. 시애틀에 위치한 이 회사는 프로그래밍이 수학(algebra 1,2)처럼 학교 정규과목이 되기를 바라며, 이를 위해 필요한 학생과 선생님의 관련 교육을 제공하는 것이 목표라고 합니다. 이 목표를 실현 시키기 위해 중요한 문제인 ‘교육의 시간과 비용’을 줄이기 위해서 자동화 테스팅을 사내에 도입하기 위해 시도해본 여러가지 노력을 소개하였습니다.
code.org의 개발자들은 한정된 인프라와 비용 문제 때문에, 테스트의 범위를 사이트 전체가 아닌 ‘깨져서 보이는 것들’에 집중한다고 합니다. 웹 애플리케이션 UI 자동화 테스트 도구인 셀레늄(Selenium) 웹 드라이버와 행동 주도 개발(Behaviour Driven Development, BDD) 방식의 테스트 소프트웨어인 큐컴버(Cucumber)를 조합하여 사이트 UI테스팅을 진행했습니다.
모든 팀원들이 각자 자기가 담당하고 있는 개발 기능의 테스트 케이스를 직접 작성했으며, 테스트를 진행하면서 자주 반복되는 패턴은 따로 모아서 라이브러리화 하여 언제든지 재사용 및 참고가 가능합니다. 테스트용 더미 데이터와 화면 테스트에 유용한 스타일 가이드 마련 및 큐컴버의 어노테이션(annotation) 기능 사용을 곁들여 테스트가 원할하게 진행될 수 있습니다. 또한, 셀레늄이 테스팅을 진행하는 화면을 영상으로 녹화하여 만일 실패가 뜨면 어디서 문제가 발생했는지 쉽게 추적할 수 있습니다.
더 나아가 반응형 사이트에 좀 더 적합한 테스트 방식을 고민하다 스크린샷을 이용한 visual testing을 추가하게 되었고, 애플릿툴스(Applitools)에서 제공하는 이미지를 비교하는 API를 활용하였다고 합니다. 병렬 테스팅이 가능해 한번에 50개 이상의 브라우저에서 테스트 실행이 가능하지만 로컬 서버에 병목현상이 일어나기 때문에 이를 감수해야 한다고 합니다.
UI 테스트 후 결과는 저장소 댓글로 공유하고, 잡힌 버그는 위키 페이지에 올려서 서로 공유합니다. 테스트 실패가 발생하게 되면, 그 실패가 발생한 기능의 개발자를 ‘오늘의 개발자’로 선정하여 문제를 해결해야 하는 임무를 준다고 합니다. 그는 ‘테스트는 작게 시작하고, 모두가 참여하며, 주기적으로 테스트 속도를 높이는데 투자한다’라는 메시지를 전달하며 발표를 마무리하였습니다.
2. CSS 애니메이션: CSS로 비단결 같이 부드러운 애니메이션 만들기 (Silky Smooth Animation with CSS)
[embedyt] http://www.youtube.com/watch?v=bEoLCZzWZX8[/embedyt]
UX 엔지니어이자 자바스크립트 개발자인 윌 보이드(Will Boyd)는 조금 더 부드러운 애니메이션을 만들 수 있는 방법과 그 예시를 소개하였습니다.
브라우저에서 하나의 애니메이션 프레임을 처리한다는 것은 애니메이션 구현에 필요한 모든 계산 과정과 계산을 통해 얻어진 픽셀 자리를 업데이트 하는 것까지 포함합니다. 목표는 브라우저가 이 과정에서 할일을 최대로 줄여서 초당 60프레임 정도의 부드러운 애니메이션(크롬 브라우저 기준)을 만드는 것입니다.
처리 과정은 4단계로 크게 나눌 수 있는데, 불러오기(loading), 그리기(rendering), 칠하기(painting), 그리고 보여주기(displaying)입니다. 애니메이션 구현에 필요한 요소는 한번 로딩이 완료되면 다시 로드할 필요가 없으므로 첫번째 불러오기 단계는 우선 성능 문제에서 고려하지 않겠습니다. 우리가 할 수 있는 일은 렌더링과 페인팅 단계의 일을 줄여주는 CSS 속성을 선택하여 사용하여 브라우저가 가능한 디스플레잉 단계만 신경쓰게 하는 것입니다.
CSS 애니메이션 구현 비용과 직접적으로 연관되어 있는 것은 재(再)조정(reflow)과 재(再)색칠(repaint)을 일으키지 않는 속성들입니다. 이 두 가지 현상을 모두 일으키지 않는 속성들이 GPU 가속화를 이끌어 내기 알맞은 것인데, 이는 GPU 스레드가 돌아갈 때 페이지에 존재하는 독립 합성 레이어 위에서 처리되기 때문입니다. 이러한 성능 향상의 도움이 되는 속성들은 transform , filter (재색칠이 일어나는 blur와 drop shadow는 제외), opacity가 있습니다.
윌이 발표를 위해 준비한 물고기 애니메이션 데모를 보면 모두 키프레임 애니메이션으로 물고기를 움직입니다. 첫번째 예시 ’20 fish swimming poorly’에서는 top 과 left속성으로 물고기를 움직이고, 두번째 예시 ’20 fish swimming excellently’에서는 transform속성을 사용하는 방법으로 동일한 형태의 애니메이션을 구현하였습니다. 겉으로 보기에는 별다른 점이 없는 두 가지 애니메이션의 성능을 비교하기 위해서는 크롬 개발자 도구를 열어 Rendering > Paint Flashing 기능을 활성화하고 리페인팅이 일어나는 부분을 초록색 사각형으로 표시하게하여 확인하는 방법이 있습니다. 첫번째 예시는 모든 물고기 주변에 사각형이 그려지는 반면 두번째 예시는 사각형이 나타나지 않는 것을 볼 수 있습니다. 즉, 브라우저는 transform속성이 적용된 애니메이션 요소에는 리페인트를 하지 않아도 된다는 것입니다. 단 20마리의 물고기를 가지고서는 리페인팅의 성능 차이를 크게 체감하기 어려우므로 다음으로는 천마리의 물고기가 헤엄치는 애니메이션을 예로 보여주었습니다. 크롬 개발자 도구의 Rendering > FPS Meter 기능을 사용하면 1초당 처리하는 프레임의 수를 확인할 수 있는데, GPU 가속화가 되지 않은 ‘Bad fish party’ 애니메이션은 초당 프레임 수가 15인 반면 가속화가 된 ‘Good fish party’ 애니메이션은 이상적인 60 FPS를 유지합니다.
이어서 소개한 실무 성능개선 사례로는 진행 막대(progress bar) 애니메이션의 예를 들었습니다. 막대가 차오르는 애니메이션을 width속성 대신 transform: scaleX()를 사용하는 것만으로도 훨씬 부드러운 애니메이션을 구현 할 수 있습니다. 또한 버튼의 배경색을 바꾸는 애니메이션을 추가하는 경우에도 background-color속성으로 색상을 직접 지정하기보다 filter속성을 이용하면 더 자연스러운 전환 효과를 구현할 수 있습니다. 개발자 입장에서는 사용자가 어떠한 사양의 디바이스를 사용하는지 미리 알 수가 없고, 그러한 경우 외에도 복잡한 스크립트 처리와 같은 이유로 CPU의 여유가 없을 수 있음을 인지해야 합니다. 그러므로 항상 CSS 속성을 선택할 때에도 애니메이션 성능에 미치는 영향을 고려할 것을 권하였습니다.
3. CSS 단위: 픽셀 사용을 그만두자(Stop Thinking in Pixels)
케이스 그랜트(Keith J Grant)는 한계가 있는 픽셀 단위의 사용을 그만두고 CSS 상대 단위를 적극적으로 사용하자는 발표를 준비하였습니다.
먼저 em 단위와 rem 단위에 대해 살펴보면 절대값으로 표현되는 px 단위와는 달리 유연하게 가변하는 값을 가지는 상대 단위입니다. 아래 그림 예를 보면 ‘M’자가 들어있는 네모 박스 둘 다 동일하게 width1em 값과 heigh1em 값을 가지고 있습니다. 하지만 왼쪽의 ‘M’자가 더 크기 때문에 이와 같이 콘텐츠에 맞게 크기가 변경 된 것을 볼 수 있습니다. 이처럼 em 단위는 font-size의 영향을 받습니다.
em 단위의 사용이 어려운 이유 중 한가지로는 다음과 같은 경우가 있습니다. em 단위는 상속된 font-size 를 기준으로 브라우저에 의해 크기가 계산되어 화면에 표현되는 과정을 거칩니다. 이때 상속되는 폰트의 크기도 em 단위를 가지고 있고 또 이런 식으로 em 단위의 상속이 계속해서 중첩된 상태라면 작업자는 점점 em의 크기를 가늠하는 것이 매우 어려워 집니다. 이러한 혼란을 방지하기 위해 케이스는 자신이 추천하는 가이드라인을 제시하였습니다. 레이아웃을 만들 때 em은 line-height 를 제외한 그 밖의 모든 속성들(padding , margin , border-radius등 콘텐츠에 따라 크기가 가변이 되게 만드려는 요소들)에 사용하기를 권장하지만, font-size 에는 rem 단위를 사용할 것을 권장하였습니다. rem 단위는 ‘root em’의 줄임말이며, 문서의 루트 엘리먼트(일반적으로 <html>)의 폰트 크기에 기준하는 상대 단위입니다. em과는 달리 중첩이 되더라도 항상 같은 기준인 루트에 비례한 상대값을 가지게 되어있습니다. 마지막으로 px 단위는 변동폭이 없거나 미미한 border-width 같은 스타일을 정의 할 때 사용하는 것을 추천하였습니다.
또한 케이스는 font-size 에 상대 단위를 적용하는 것이 접근성 측면뿐만 아니라, 코드를 더 정확하고 간단하게 만들어준다고 말하였습니다.
디자이너가 폰트 사이즈를 고를 때 1, 2, 3, 4px 이렇게 무작정 1px 단위로 더해가며 사용하는 것이 아니라 9, 10, 11, 12…24, 36px 등 널리 사용되는 특정 픽셀 범위가 있습니다. 이 비율에 근거한 픽셀 범위는 글자간의 가독성과 위계성을 지킬 수 있도록 계산된 것으로, 90년대 초반에 만들어진 책 The Elements of Typographic Style 중 ‘타이포그래픽 스케일’에 나오는 내용이라고 합니다. 케이스는 책의 저자가 ‘타이포그래픽 스케일’을 만든 이유가 우리가 현재 사용하는 고정된 픽셀값(책에서는 프린트물 기준인 pt값으로 나와 있습니다)의 폰트처럼 사용할 일부 글자 크기를 정해주려고 만든 것이 아니라, 글자간 비율에 의미를 두고 만들었으며 이것이 상대 단위를 사용한 요소처럼 보기 좋은 비율(의도한 디자인의 비율)을 유지하도록 하는 맥락과 동일하다고 말하였습니다. 흔히 픽셀 변환기와 같은 툴을 이용해 px 값을 가지고 em 값을 계산하는데, 결국 처음부터 비율을 이용한다면 불필요한 계산 과정이 줄어들 것이라고 설명하였습니다. 그는 가능하다면 너무나 세세하게 CSS를 관리하려(micromanage)하지 말자고 말하였습니다.
em의 강력함은 ‘가변적(resizable) 모듈’을 만들 때 느낄 수 있습니다. 모듈의 루트 요소에 rem을 사용하고, 그 자식 요소에는 em으로 관리한다면, 루트 요소의 값만을 변경함으로써 모든 부분이 알맞게 줄어들거나 늘어나는 것을 볼 수 있습니다. 또한 덧붙여서 vw , vh , vmin , vmax 와 같은 브라우저창 상대 길이를 사용하면 미디어쿼리의 사용을 조금이나마 줄여볼 수 있습니다. 픽셀값과 em을 같이 사용하는 것은 자칫하면 관리하기 힘든 코드를 만들어 냅니다. 만일 em 사용이 주저된다면, 작은 사이드 프로젝트 하나를 만들어서 시험해보기를 추천합니다.
4. 이미지 최적화: 증오스런 용량(The Hateful Weight)
앙리 헬베티카(Henri Helvetica)는 다양한 이미지 포맷에 대한 자세한 설명과 페이지 용량 최적화의 필요성에 대해 발표하였습니다.
먼저 그는 웹 개발자들이 이미지 최적화에 신경써야 하는 이유를 여러 통계 자료를 통해서 설명하였습니다. 대표적인 요인 중 하나로는 2012년에 요청 한번 당 평균 696KB에 불과했던 이미지 용량이 2016년에는 1.5MB로 늘어난 것을 볼 수 있습니다. 또한 현재 이미지 파일의 용량은 전체 페이지 용량의 64% 정도를 차지하는 경향을 보이는데, 이는 반응형 디자인과 레티나 이미지 대응 케이스가 훨씬 증가했기 때문입니다.
적절하게 최적화되지 않은 이미지를 사용하면 당연히 페이지 속도가 느려져서 사용자 경험에도 좋지 못한 영향을 끼치고, 호스팅 비용 증가에도 한몫을 하게 됩니다. 우리나라와 같이 인터넷 사용 환경이 좋은 곳에서는 작은 이미지의 용량 차이로 큰 속도 저하가 발생하지는 않지만, 전세계 중 북아메리카 대륙을 제외한 대부분의 나라에서는 여전히 2g 혹은 3g를 사용하고 있다고 합니다. 이러한 이유로 각 브라우저에서는 자체 데이터관리 기능을 제공하기도 합니다. 이미지의 픽셀을 깎아내 용량을 가볍게 하는 오페라 터보 서비스의 데이터 절약 모드(Data Saving Mode)를 예로 들 수 있습니다.
2016년 현재 사용되고 있는 이미지 포맷으로는 SVG(1%), WEBP(1%), GIF(25%), PNG(29%), JPG(44%)가 있습니다. GIF는 무손실이지만 오래된 만큼 이미지를 표현하는 방식이 낡았으며, 너무 느리고 용량이 크므로 만일 GIF가 필요한 상황이라면 무조건 대체 포맷을 사용하기를 권장하였습니다. PNG와 JPG를 사용할 경우에는 파일 내에 포함된 EXIF 메타데이터를 삭제하여 용량을 줄여야 합니다. WEBP는 2010년 구글에서 개발한 이미지 포맷인데, 아직은 크롬을 제외하고는 대부분 브라우저 지원이 되지 않는 상태입니다. 하지만 최근 애플에서도 사파리 브라우저의 WEBP 포멧을 테스트 중이라고 트위터로 소식을 전하였다고 하니 기대를 걸어 볼 만한 차세대 데이터 포맷입니다. WEBP의 큰 장점은 데이터를 매우 효과적으로 아낄 수 있다는 것입니다. 5MB 용량을 가진 PNG 파일을 예로 들어, 이를 85%의 품질의 WEBP 포맷으로 전환한다면 고작 340KB의 작은 용량의 파일로 변경할 수 있다고 설명하였습니다.
성능 최적화는 글로벌 마켓 대응뿐만 아니라 사용자 경험 향상에도 중요한 부분을 차지하므로 각 이미지별 포맷의 장단점을 잘 파악하여 개발팀에서 올바른 이미지 선택 전략을 수립해야 할 것입니다.
5. Sass Map: Sass Map Magic
단순히 웹사이트나 애플리케이션을 완성해서 판매하기 보다는, 미리암의 팀은 개발의 토대가 되는 좋은 설계도를 만들어내고 이를 클라이언트의 사내 개발팀에게 직접 넘기는 식의 작업을 한다고 합니다. 좋은 설계도를 만들기 위해서는 일관성 있는 코드 사용으로 좋은 패턴을 만들어 내는 것이 중요하다고 합니다. CSS는 패턴을 만들어내는(pattern-making) 언어입니다. Sass를 적절히 사용한다면 더 많은 의미를 CSS 코드에 부여할 수 있습니다.
이를 위해서 Sass 작성을 할 때에는 ‘의미 있는 추상(meaningful abstraction)’을 형성하는 것이 필요합니다. 키(Key)와 값(Value)을 쌍으로 가질 수 있는 맵(Map)은 그런 차원에서 아주 유용하게 사용될 수 있습니다. 맵의 대표적인 사용 예로는 컬러 팔레트 생성이 있습니다.
// individual definitions $color--brand-orange: hsl(24, 100%, 39%); $color--brand-blue: hsl(195, 85%, 35%); $color--brand-pink: hsl(330, 85%, 48%);
상단의 코드 예시는 일반적인 Sass 변수 선언 예시입니다. 각각 주황, 파랑, 분홍 HSL 색상값을 변수로 할당한 코드입니다. 이것을 맵 변수에 넣어 좀 더 활용하고자 한다면 아래와 같이 재작성 할 수 있습니다.
// grouped definitions
$colors: (
'brand-orange': hsl(24, 100%, 39%),
'brand-blue': hsl(195, 85%, 35%),
'brand-pink': hsl(330, 85%, 48%),
)
앞에 적힌 색상의 이름이 키(key)이고 뒤에 따라오는 HSL 색상값이 키의 값(value)입니다. Sass 맵의 작성법은 자바스크립트와 같은 일반적인 프로그래밍 언어의 객체와 매우 닮은 형태를 띄고 있습니다. 이렇게 미리 작성해둔 맵을 가지고 필요한 값을 가져다 사용하면 됩니다. map-get() 함수는 가장 기본적인 방법으로 해당 맵과 키값을 가져오는데 사용합니다. 또한 만들어진 맵끼리 병합시킬 수 있는 함수인 map-merge() 등을 사용하여 키값들을 더 세밀하게 그룹핑하여 정리할 수도 있습니다.
:root {
background: map-get($colors, 'brand-blue');
}
추가로 소개한 Sass 맵을 응용한 예시로는 웹폰트의 정보를 맵에 담아 불러오는 방법, 함수를 작성하여 맵의 변수를 동적으로 생성하는 방법, 함수와 믹스인 테스트 결과 데이터를 저장하는 용도로 사용하기 등이 있습니다. 맵의 사용을 극단적으로 밀어 붙이다보면, 사람들이 흔히 하는 걱정은 ‘과도하게 엔지니어링(overengineered)’된 것이 아닌지 물어보곤 합니다. 하지만 모든 방법에는 장단이 따르게 마련입니다. 웹 레이아웃 프레임워크 Susy 작업 당시 도중에 Sass 맵 기능이 새로 추가되었는데 기존에 작성한 코드를 버리고 처음부터 다시 작업하였다고 합니다. 그로인해 기본 설정을 비롯한 모든 세팅을 맵으로 구현하고 맵에 들어간 데이터를 파싱 및 머징하는 함수도 만들 수 있었다고 합니다.
미리암이 맵을 적극적으로 사용하는 이유는 사람과 기계가 모두 쉽게 읽을 수 있는 데이터 타입이며 동적으로 접근이 가능하고, 변수에 담겨진 데이터를 json 형식으로 추출하여 스타일가이드를 작성할 때 편리하게 활용할 수 있기 때문입니다.
6. 실생활에서의 SVG
발표에서 다룬 스매싱 매거진 작업 당시 사라는 디자이너가 넘겨준 디자인을 기존 DOM 구조를 거의 건드리지 않고 입혀야하는 어려움이 있었다고 합니다. 일부 컨퍼런스 참여자들은 이해 할 수 없다는 리액션을 보이거나 놀라움을 표하기도 하였는데요. 저희는 공통 모듈을 가지고 서비스별 커스텀을 한다던지, 한가지 컴포넌트를 여러 이유로 전혀 다른 모양으로 만들어내는 일이 꽤 있기 때문에 마음이 전혀 동하지는 않았습니다!
예를 들어 디자인은 유동적 텍스트 영역을 가진 반응형 페이지인데 우측에는 다른 콘텐츠(타이포그래픽 텍스트 및 사진)가 위치해 있으며 페이지의 좌측 중간쯤부터 시작되는 본문 텍스트 영역이 이상한 니은자(ㄴ) 모양으로 애매하게 걸쳐있을 경우, 구조변경 없이 CSS만으로 어떻게 레이아웃을 구현해야 할지 이틀을 고민했다고 합니다. 결국은 텍스트 디브 내에 가상 엘리먼트를 생성해 흰색 배경 페이지에서 보이지 않을 흰색 네모 박스를 만들고 float: right를 주어, 니은자(ㄴ)로 겹쳐있어야 할 부분에 항상 가상 엘리먼트가 텍스트를 밀어내어 해결하였다고 합니다. 핵(편법)은 누구나 싫어하고 좋은 것은 아니지만 필요시에는 이와 같이 창의성과 기지를 발휘할 수 있다고 말하였습니다.
또 다른 창의적인 CSS 사용 예시로는, background-color 속성을 사용해서 형광펜과 유사한 블럭 효과를 구현할 때 두 줄 이상 텍스트인 경우 줄바꿈 되는 부분 양끝에 어떻게 패딩을 넣을 수 있는지에 대한 팁(Multi-Line Padded Text, CSS-Trick 참고)을 소개하였습니다. 비슷한 내용으로 타이포그래픽 제목 텍스트에 밑줄을 친 듯한 디자인 효과를 줘야 했던 경우에는 알파벳의 descender(g, y, p처럼 baseline보다 아래로 더 뻗어 내려가는 것)가 밑줄선과 겹치지 않게 하기 위해서 shadow속성을 blur없이 선언하여 각 알파벳 캐릭터에 투명한 보더가 있는 것과 같은 효과(Clearing the descenders, Designing Medium의 글 7번 내용 참고)를 주었던 경험도 공유하였습니다.
그 외에도 링크 안의 링크가 있는 디자인의 키보드 접근성과 논리적 순서를 준수하기 위해 고민한 내용과, SVG를 사용할 때 잊지 말아야 할 지원 범위 및 PNG 폴백(fallback) 등 접근성에 관한 주제도 살짝 다루었습니다.
CSSCONF 참관후기 #2로 이어집니다.
1개의 댓글
jeongsic yoo · 2017년 2월 11일 11:10 오전
좋은 내용 잘보았습니다! 감사합니다 🙂