Patchworks @aquatype - Tumblr Blog

Semantics: Aside as sidebar

사이트 전체의 사이드바를 구현해야 하는데, HTML5 시맨틱 태그 중에는 헤더 푸터 심지어 메인은 있어도 사이드바라는 개념은 없다. 가장 개념적으로 근접해보이는 것으로 <aside>가 있는데, 이를 사이드바 마크업으로 사용해도 괜찮을지 궁금해서 리서치해봄.

일단 W3의 정의는 다음과 같다.

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.

보다시피 아주 두리뭉실한 정의이기 때문에 원본주의자와 해석주의자 간의 키배도 많았는데, 다행히도 W3가 이를 인지하고 '사이트 전체의 사이드바로 써도 된다'고 컨펌을 해 주었다고 한다. 하지만 여기서 다시 한 번 키배가 벌어지는데, 이번엔 '그럼 무엇이 사이트와 tangential하게 관련된 컨텐츠이냐'가 쟁점이다. '메인 로고' 및 '메인 내비게이션', 그리고 '다른 연관 컨텐츠'로 구성된 사이드바를 마크업하는 경우를 예로 들면,

원본주의자들은 로고나 내비게이션은 컨텐츠가 아닌 독립된 엘리먼트이므로 aside 내에 들어가서는 안 된다고 말한다. 따라서 그들의 마크업은 아래와 같다.

<body> <div class="sidebar"> <h1>Title of the website</h1> <nav> <h1>Main navigation</h1> <ul> <li><a href="#">1</a></li> <li><a href="#">2</a></li> <li><a href="#">3</a></li> </ul> </nav>  <aside> <h1>My last tweets</h1> <ul> <li><a href="#">quoque... </a></li> <li><a href="#">inleceb... </a></li> <li><a href="#">locaaer... </a></li> </ul> </aside> </div>

반대로 해석주의자들은 로고나 내비게이션 역시 사이트 그 자체에 종속적인 컨텐츠로 볼 수 있으므로 aside 내에 넣을 수 있다고 주장한다.

<body>  <aside> <h1>Title of the website</h1> <nav> <h1>Main navigation</h1> <ul> <li><a href="#">1</a></li> <li><a href="#">2</a></li> <li><a href="#">3</a></li> </ul> </nav> <section class="tweets"> <h1>My last tweets</h1> <ul> <li><a href="#">quoque... </a></li> <li><a href="#">inleceb... </a></li> <li><a href="#">locaaer... </a></li> </ul> </section> </aside>

사이드바를 컨텐츠와 디자인 중 어느 쪽의 개념으로 볼 지에 따른 이슈인데, 논리적으로는 전자가 맞다고 생각하면서도 개인적으로는 뒤의 마크업이 좀더 마음에 든다.

Reference:

Sidebar and Aside are different

#html #semantics

•18+ Adults Only

Watch Anya Live on Cam

Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.

✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality

Anya is LIVE right now

FREE

Free to watch • No registration required • HD streaming

JavaScript Float Math Problem

http://stackoverflow.com/questions/588004/is-floating-point-math-broken http://floating-point-gui.de

프로젝트에서 지수 서식(e)으로 출력되는 값을 부동소수점으로 변환하는 함수가 필요해서 코딩하던 중 자바스크립트 부동소수점 관련 이슈를 깜빡하는 바람에 한참 삽질함. 그냥 IEEE 754 표준을 따르기 때문이다~ 라고만 대충 알고 있었는데 이참에 정확히 알아두려고 검색해봄.

깨달음: 자바스크립트 부동소수점은 64비트 배정밀도를 사용하기 때문에 분모가 2의 배수가 아닌 유리수는 정확하게 표기하지 못한다! 그래서 엡실론 보정을 적용하는 함수를 사용해야만 정확한 결과를 얻을 수 있다!!

#javascript #math #fuuuuuuuuuuu

Stop Gratuitous UI Animation

https://medium.com/@sophie_paxtonUX/stop-gratuitous-ui-animation-9ece9aa9eb97

As a designer you need to realize that your UI is not entertainment.

#ui

Slack Recycler

http://inspired.crevisse.com/slack/

개인 프로젝트... 라고 해야되나 30분컷짜리인데. 아무튼

회사에서 슬랙을 쓰는데 유료 티어에 딱히 메리트를 느끼지 못해서 무료에 머무르고 있다(고 한다). 디자인팀에서 시안들을 전부 슬랙으로 공유하다보니 무료 티어의 얄팍한 5기가 용량제한이 금방 터졌고, 공유된 파일을 하나하나 찾아서 지우는 게 보기 안타까워서 좀 찾아보니 의외로 REST와 OAuth를 통한 API가 잘 돼 있더라. 그래서 대충 만들어봄

슈퍼어드민도 남의 파일은 못 들여다보는 강력한 프라이버시 정책 때문에 팀원 각자가 토큰을 발급받아서 직접 자기 파일 지우는 식이다. 더 찾아보면 더 편하게 개선할 수 있을지도 모르겠지만 아몰랑. 다들 만족스럽게 쓰니 나도 그냥 만족하기로 함

#personal project

Web Font Anti-Patterns

http://bramstein.com/writing/web-font-anti-patterns.html

섹션별 요약:

1. 남용하지 마라. 웹폰트는 본문이나 헤드라인을 위한 것이지 타이포나 레터링을 위한 것이 아니다. 그건 아트의 영역이므로, SVG를 써라.

2. 인라인 임베딩을 하지 마라. 웹폰트를 여러 개 쓸 경우 리소스 요청 오버헤드가 줄긴 하지만, 장점은 그것뿐이고 반대로 폰트 전체의 용량을 합친 만큼 렌더링이 늦어진다.

3. 서브세팅을 신중히 해라. 한글 웹폰트에 적용하자면 조합형 글꼴을 전부 날리고 완성형만 남기는 식의 극단적인 경우를 들 수 있겠다. 근데 한글은 그렇게 쳐내지 않으면 용량이 어 음... 어쩔 수 없잖아

4. 로컬 폰트 끌어오지 마라. 웹폰트는 타입페이스 네이밍도 다 다를 뿐더러 기본적인 틸팅이나 안티앨리어싱 설정도 전부 웹에 맞게 최적화되어 있다. 로컬폰트를 쓰면 재앙이 발생한다.

나머지 2개 섹션은 커밍순이라고 한다. IE 8이 슬슬 한국에서도 고인이 되어가고 있는 추세인데, 본격적으로 SVG를 배워 써먹어야겠다고 다짐해본다

#frontend #performance #webfont

•18+ Adults Only

Watch Anya Live on Cam

Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.

✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality

Anya is LIVE right now

FREE

Free to watch • No registration required • HD streaming

Finishing Touch: Project DRAW

이번 프로젝트를 통해 하고 느끼고 배운 것들:

- 국산 안드로이드 앱들, 특히 카카오톡이나 네이버 포탈앱이 사용하는 인앱 브라우저 엔진은 대체 뭘 커스텀한 건진 모르겠지만 하나같이 기묘하다. 웹킷 기반인 것 같긴 한데 하드웨어 가속 지원이 미비하거나 자바스크립트 연산 처리속도가 우주로 감. 가능한 최적화를 다 끝냈는데도 메모리 2GB 디바이스에서 카운터스톱이라니...

- 네이버 라인/밴드는 API가 정말 눈물날 정도로 미비하다

- UX는 개발에 대한 이해 없이는 잘 뽑아내는 게 거의 불가능하다

- iOS 사파리에서 absolute 또는 fixed 포지셔닝된 엘리먼트를 터치스크롤할 때 발생하는 특이현상의 원인을 알아냄. 뷰포트 높이를 초과하는 엘리먼트가 좌표 포지셔닝되어 있을 경우 터치-스크롤을 하면 문서의 스크롤탑은 내버려둔 채로 해당 엘리먼트만 강제로 스크롤을 해버린다. 관성스크롤 이펙트가 발생하지 않고 부자연스럽게 끊어지는 걸로 판별가능.

- 원인을 알아내긴 했지만 해결방안 그런건 업ㅂ다

- CSS와 AJAX templating을 이용한 분산서버 데이터 레이지로딩... 은 너무 거창하고, 아무튼 시스템 외적인 방법으로 동적 DOM을 심고 관리할 수 있는 방법을 시도해봤고 그럭저럭 성공함

- 모바일 한붓그리기 구현은 정말 영악하게 잘했다. 음 천재적이야. (진지, 근엄)

- 개인적으로 OOP 스타일 자바스크립트 프로그래밍을 좀더 연마해야겠다. 확실히 많이 늘긴 했는데 아직 미숙하다. 모듈화 스코프에 대한 결정력이 부족하고, 정석에선 좀 벗어난 방식을 학습하고 있는 것 같아 교정이 필요한 듯

- 애자일 방법론을 점진적으로 팀 내에 전파하려고는 하는데... 힘들다. 이번 프로젝트는 팀 레벨에서 Finishing Touch가 예정되어 있으므로 그 때 정식으로 발안해보려고 함.

#project #postscript

Breaking down Amazon’s Mega GNB

http://story.pxd.co.kr/655

http://okjungsoo.tumblr.com/post/46659644754/amazon%EC%9D%98-mega-dropdown-menu-%EC%BD%94%EB%93%9C%EB%A5%BC-%EB%B3%B4%EA%B3%A0

우와아아

#frontend #codegeeks

RAIL performance model

http://www.smashingmagazine.com/2015/10/rail-user-centric-model-performance/

RAIL(Response, Animation, Idle, Load)은 구글 크롬 팀에서 퍼포먼스의 정의를 ‘유저’ 중심으로 개편하면서 창시한 UX 모델이라고 한다. 대충 요점만 추리자면

1. RAIL은:

- 유저 경험을 키 액션(탭, 드래그, 스크롤, 로드 등)로 쪼개어 정의하는 UX 모델임 - 그러한 키 액션에 대한 퍼포먼스 골을 제공함. 예를 들면 탭에서 페인트까지 100ms 이하라던지. - ‘퍼포먼스’에 대한 (일관성있는) 개념적 구조를 제공하여, 디자이너와 개발자가 가장 효율적인 방법을 선택할 수 있도록 도와줌

2. ‘느리다’

- 절대적으로 느린 프로세스는 없음. 컨텍스트에 따라 상대적인 것이고, 중요한 건 그 컨텍스트마다 유저가 기대하는 성능 기대치가 전부 다르다는 것임. - 구글의 #1 철칙: “유저에 집중하면 나머지는 알아서 따라온다” - ‘느린가?’ 대신 ‘유저가 쓸 때 어떤 느낌을 받을까?’를 고려할 것

3. 유저 경험

20년 전부터 업계 정석인 연구 결과에 요즘 대세인 애니메이션에 대한 내용을 쪼끔 섞어서, 구글에서는 다음과 같은 threshold를 설정해두고 있다:

- 100ms 이내: 유저는 ‘즉시’로 인지한다. 이보다 길면 액션과 리액션 사이의 연결성이 희미해진다. - 1초 이내: ‘작업의 자연스럽고 연속적인 진행’으로 인지한다. 이보다 길면 유저는 그들이 하고 있던 작업에 대한 포커스를 잃어버린다. 페이지 로드를 생각하면 됨. - 16ms: 닌겐은 동작 추적에 특히 뛰어나기 때문에, 주사율 문제든 랙이 걸리든 해서 모션에 대한 기대치가 충족되지 않으면 부정적인 경험으로 인식한다.

일반적인 유저 인터렉션을 분석해보면 유저가 하는 행동을 로드하고 / 애니메이션을 보고 / 잠깐 멍때리다가 / 기능을 사용하는 4가지로 나눌 수 있는데, 이게 RAIL이다.

4.1 Response

버튼을 클릭했다 치면, 앱은 유저가 랙을 느끼기 전에 거기에 대한 반응을 해야 한다. 이게 유의미한 시간 내에 되지 않으면 액션-리액션 사이의 체인이 깨져버린다. Response에서 중요한 건 지연시간latency다. 응답이 너무 늦으면 이게 과연 내가 클릭한 걸 알아먹긴 했나 생각하게 되잖아? 그게 안되는 거라고.

Response의 주된 인터렉션은 ‘누르는 거’다. 버튼이든 아이콘이든. 여기에 반응형으로 응답을 하려면 1. 일단 피드백이 100ms 이하의 시간 내에 떠야 하고, 2. 그 피드백이 유저가 원하는 내용을 담고 있는 것이 이상적이다. 만약 로딩이 길어지게 되면 로딩 인디케이터나 버튼에 액티브 컬러 등을 넣어도 된다. 어쨌거나 유저가 내가 입력을 제대로 했는지 의문을 갖지 않게 만드는 게 핵심이다.

4.2 Animation

애니메이션은 다음을 포함한다:

- 비주얼 애니메이션. 시작과 종료 애니메이션, 트위닝, 로딩 인디케이터 등 - 스크롤링. 유저가 스크롤을 시작하고, 놓았을 때, 페이지가 흘러내려가는 것을 말함 - 드래그. 유저의 드래그 인터렉션에 100ms 이하로 반응하기 위해서는 애니메이션이 필요함

애니메이션을 제대로 수행하려면, 60FPS 기준으로 매 프레임은 16ms보다 적은 시간에 수행되어야 한다.

4.3 Idle

Optimistic UI 패턴을 참고. 완료가 되어야 하는 작업 중에는 ‘response’나 ‘load’를 배제하면 critical time window 내에서 실행될 필요가 없는 것들이 많다. 부트스트래핑, 컴포넌트 이니셜라이징, 검색과 정렬, 통계데이터 전송 등은 브라우저가 대기 상태일 때 처리해도 상관없는 것들이다.

대기 시간을 현명하게 사용하기 위해서는, 이런 작업들을 50ms 이내로 수행 가능한 블럭 단위로 모듈화하는 것이 좋다. 사용자가 인터렉션을 시작하면 100ms 이내에 응답을 해줘야 하니까.

4.4 Load

페이지 로딩이야말로 꾸준히 발전해 온 퍼포먼스 해킹의 핵심이며, 유저에게 유의미한 first paint를 빨리 보여주는 것이 중점이다. 그 이후엔, 앱은 유저가 사용함에 있어 어떠한 장애도 없도록 responsive한 상태를 유지해야만 한다.

1초 이전에 meaningful first paint를 발생시키는 것이 목표이며, 이보다 길어질 경우 사용자의 관심은 우주로 가기 시작하고 앱에 대한 집중도가 떨어지게 된다. 크리티컬 렌더링 패스를 구축하고, Idle 시간에 지연 로딩deferred loading을 수행하거나 아예 온디맨드로 구현하는 등의 방법론이 수반된다.

번역해놓고 보니 음... 그냥 실무에서 보편적으로 고려하는 UX의 골든룰을 정형화해놓은 거에 지나지 않는 것 같긴 하다. 다만 일반적인 퍼포먼스 최적화 방식과는 다르게 철저하게 유저를 중심에 놓고 거기에 맞춘 threshold를 설정한다는 게 인상깊은 점.

#ux

What forces layout thrashing / reflow

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

레이아웃 트리거 목록. 저자는 Paul Irish.

사실 레이아웃 스래싱은 정말 의식적으로 디버깅을 하지 않으면 코딩 레벨에선 방지하기가 거의 불가능하다. 저 문서의 어펜딕스에서도 룰을 정의하고 있는데

1. DOM 구조를 즉석에서 읽고 수정하는 형태의 for 루프는 최악의 퍼포먼스 히트를 보임. 절대 하지마라 2. 타임라인을 이용해서 항상 리플로우를 체크할 것 3. FastDOM이나 Virtual DOM 등을 활용해서 batch write / read 형태로 코드를 실행할 것

3은... 뭐 물론 라이브러리를 쓰면 더 좋겠지. 일단 1과 2는 항상 염두에 둬야 할 부분.

#frontend #performance

Responsive image techniques chart

https://docs.google.com/spreadsheet/ccc?key=0Al0lI17fOl9DdDgxTFVoRzFpV3VCdHk2NTBmdVI2OXc#gid=0

마술같은 올인원 솔루션은 없는 것으로

#frontend #backend

•18+ Adults Only

Watch Anya Live on Cam

Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.

✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality

Anya is LIVE right now

FREE

Free to watch • No registration required • HD streaming

World of Script Loading

http://www.html5rocks.com/en/tutorials/speed/script-loading/

이전에 스크립트 로더 모듈 다시 만들면서 참고했던 좋은 글.

YepNope...은 터졌고, RequireJS 같은 메이저한 대안도 있긴 한데, 기본적으로 나는 프레임워크나 플러그인을 덕지덕지 도배하는 걸 별로 좋아하지 않는다. 본문에서도 이런 라이브러리들을 언급하면서 끝에 이렇게 덧붙인다.

Basically, if you have to download an extra script file before even thinking about downloading other scripts, you've lost the performance battle right there.

#frontend

rAF polyfill implementation

http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

레거시 IE 대응이 필요한 프로젝트를 진행할 때 보통 Erik Möller의 폴리필을 카피페해서 쓰고 있었는데, 어차피 modernizr prefixed API도 거의 항상 들어가는 김에 그냥 쭉 털어낸 다음 기존 라이브러리에 번들로 합쳐버리자고 생각함.

var l = 0; // last call timestamp

window.requestAnimationFrame = Modernizr.prefixed('requestAnimationFrame', window) || function(callback, element) { var now = (new Date).getTime(); var then = Math.max(0, 16 - (now - l)); var id = window.setTimeout(function() { callback(now + then); }, then); l = now + then; return id; };

minified:

window.requestAnimationFrame=Modernizr.prefixed("requestAnimationFrame",window)||function(d){var o=(new Date).getTime(),r=Math.max(0,16-(o-l)),k=window.setTimeout(function(){d(o+r)},r);return l=o+r,k};

별것도 아닌데 왜 그동안은 생각조차 안했던걸까...

#frontend

Mobile touch-drag plugins

http://pep.briangonzalez.org/ http://touchpunch.furf.com/

모바일에서 dot-to-dot 게임을 구현해야 하는 프로젝트를 받았는데 음... 터치인 이상 대부분의 유저는 한붓그리기를 하려고 할텐데, 콜백으로 누덕누덕 기워야 구현이 가능하지 싶다.

#frontend #jquery

Centering the unknown

http://codepen.io/chriscoyier/pen/gsodI

다이나믹 엘리먼트를 센터링할 때 주로 display: table 어트리뷰트를 이용해왔는데, 너무나도 편법스러운 접근인 것은 둘째치고 마크업에 최소 하나 이상의 wrapper가 추가로 필요하기 때문에 항상 불만이었다. 그래서 찾아보니 역시, 영악하면서도 시맨틱한 해법이 있더라.

:before를 이용해서 뷰포트 내에 그 높이만한 엘리먼트를 생성하고, 센터링할 엘리먼트와 함께 vertical-align 어트리뷰트를 준다. 0.25em 마진값은 인라인 엘리먼트 마크업 사이에 포함되는 스페이스 하나 분량을 당겨주기 위해 넣은 것인 듯한데, 이건 별로 아름답지 않은 해법인듯. 부모를 font-size: 0으로 설정하고 자식에서 다시 맞추는 식이 나을 것 같다. 아니면 태그를 붙여버리거나.

#frontend #css

Client-side templating

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

- first paint time / last paint time 을 고려하는지의 여부, 처리하는 데이터의 규모에 따라 효율이 갈림. - 단위가 작을 경우 유의미한 차이가 서로 없음. - 서버사이드 처리가 first paint는 빠름. 하지만 클라이언트 사이드가 last paint를 압도적으로 빠르게 처리함. 데이터 규모에 따라 산술급수적 격차. - 이는 모바일에서도 마찬가지. - 용도에 맞게 쓰세요.

개발 패러다임의 변화에 따른 논쟁인데, 웹 어플리케이션이 점점 웹’앱’의 형태로 발전하면서 서버는 뼈대를 짜고 클라이언트는 내용물을 채우는 하이어라키에 반감을 가진 사람도 많은가보다. 개인적으로는 이쪽이 더 시맨틱한 접근이라고 생각함. 특히나 이소모픽이 대세인 요즘은.

#frontend

•18+ Adults Only

Watch Anya Live on Cam

Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.

✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality

Anya is LIVE right now

FREE

Free to watch • No registration required • HD streaming

Finishing Touch: Project Trashcan

1. 프로젝트 배경:

폰 초기화를 하기 전 노인정 단톡방의 로그를 별 생각없이 백업했는데, 의외로 한번도 정리한 적이 없는지 폰 리퍼받은 시점부터 약 1년치 대화내용이 고스란히 저장됨. 처음부터 읽어봤더니 간간히 주옥같은 개드립이 하나씩 껴 있길래, 예전에 다니던 모 IRC 채널에서 만담집을 만들어서 연말에 베스트 만담 시상식을 하곤 했던 기억이 떠올랐다. 그래서 개드립을 보존해둘 수 있는 프로그램을 만들어보자고 마음먹음.

2. 진행과정:

처음엔 단순히 APM 환경을 이용해 구축 후 수동으로 디비에 입력하면 그걸 뿌려주기만 하는 단순한 모양새였지만… 할일없던 차에 여기서부터 장잉정신에 발동이 걸림. 아래는 발전 과정.

- 대체로 모바일에서 보게 되겠지? : 반응형 웹 - 디비에 수동으로 입력하기 귀찮은데 : 글쓰기 페이지도 만들자 - 기왕 통신하는거 AJAX로 스무th하게 / REST API로 - 디비엔 이름/시간/대화내용만 있으면 되는데 카톡 로그 포맷을 복붙하고 있으니 후처리가 번거롭다 : JSON 포맷으로 압축하자 - 아 어차피 동적으로 그릴 거면 클라이언트 사이드 템플리팅도 해보자 : AJAX를 이용해 로딩 후 동적으로 클론해가며 컨텐츠 출력 - 내용 많아질 때를 대비해서 페이지네이션… 은 촌스러우니까 인피니트 스크롤! - 다음 컨텐츠 로딩할 때 로딩바가 필요할 것 같다 : 하스스톤식 개드립 인디케이터 - 적당히 오픈했더니 애들이 자기들도 글 쓸 수 있게 해달래 : 글쓰기 양식을 버튼식 위지위그 에디터로 수정 - 딴 사람들한테도 보여주고 싶다는데 몇몇 글은 내용이 좀 민망함 : 경고창 마스크 도입 - ??? - PROFIT!

3. 건의는 받았으나 제외된 것:

- 투표, 좋아요 기능 : 회원제가 아니므로 객관적인 수치가 아니라 의미없음 - 비밀번호 보호 열람 기능 : 뭐 누가 본다고 - 검색, 정렬 기능 : 귀찮아

4. 하고 느끼고 배운 것:

- 사실상 보일러플레이트를 정비해서 새로 제작했으니 프로젝트 2개가 연동된 것이나 다름없다. HTML5 시맨틱스 및 각종 최적화 테크닉을 전부 찾아보고 선별 적용했는데, 이건 추후에 한번 다시 정비할 필요가 있을 것 같다. 특히 스타일시트 임베딩 및 스크립트 로더 모듈. - 클라이언트 사이드 템플리팅은 뭐 찾아보고 만든 게 아니고 그냥 대충 이렇게 하는 거 아닐까? 하고 느낌적인 느낌으로 구현했다. 그래서 그런지 굉장히 비효율적으로 구현한 것 같음. template 태그를 활용해보고 싶었는데 이건 DOM을 클론하면 이상한 게 따라붙길래 일단 보류함. - 스코프를 딱 내 열정이 불타는 동안 커버할 수 있을 만큼만 명확하게 잘 잡았고, 그래서 1주일만에 훈늉한 결과물이 나왔다. - UX가 만족스럽다. 특히 글쓰기 프로세스 및 로딩 인디케이터 애니메이션은 모두의 찬사를 받음. - iOS 사파리의 버그를 발견했는데, input 엘리먼트를 동적으로 readonly로 바꾸면 키보드가 자동으로 뜬 뒤 입력이 불가능해진다. 강제로 blur나 아웃포커스를 줘 보기도 했는데, 사용자가 직접 터치로 해제하지 않으면 키보드는 닫히지 않더라.

포트폴리오로 손색없을 만한 개인프로젝트이긴 한데 내용이 내용인지라... 욕설과 섹드립이 가득한 걸 누구 보여주긴 좀 그렇잖아? 빨리 다른 프로젝트로 소스 돌려서 세탁해야겠다.

#frontend #personal project

Trending Blogs

Last Seen Blogs

Patchworks