HTML5Crew

현대 브라우저는 아래와 같이 크게 두개의 쓰레드로 동작을 합니다.

메인 쓰레드 : 자바스크립트 실행과 Dom 엘리먼트 렌더링을 담당

컴포지터 쓰레드 : GPU를 이용하여 렌더링된 엘리먼트를 화면에 그리는 역할을 담당

두 쓰레드의 큰 차이점은 메인 쓰레드는 주어진 작업이 끝나기 전까진 다른 작업이 모두 블락 되는 반면에 컴포지터 쓰레드는 화면을 그리는데 있어서 특정 부분에서 블락이 된다면 그부분은 빈영역으로 대체 한채 다른 영역을 그리는 작업을 초당 60번 정도 반복 수행을 합니다.

여기서 컴포지터 쓰레드가 이용하는 GPU는 아래와 같은 작업들은 빠르게 수행합니다.

비트맵을 화면에 그리는 작업

같은 비트맵을 다시 그리는 작업

같은 비트맵을 다른위치로 이동, 회전, 크기를 변경하여 다시 그리는 작업

하지만 다음과 같은 작업은 상대적으로 처리속도가 느립니다.

자신의 메모리에 비트맵을 로드하는 작업

css 애니메이션을 그리는 방법들은 여러가지가 있지만, 위와같은 gpu의 특성때문에 같은 애니메이션 효과라도 성능의 차이가 느껴지는 경우가 있습니다.

대표적으로, 비슷한 애니메이션을 보여주는 엘리먼트의 transition: top 속성을 이용하여 위치를 이동하는 경우와 transition: transform 속성을 이용하는 경우를 들수 있습니다.

top의 값이 0px -> 100px로 1초동안 점차 증가하는 방식으로 애니메이션이 동작할때 top의 값이 1px씩 증가 할때 마다 메인쓰레드는 레이아웃과 페인팅을 새로해서 비트맵을 만들고 해당 비트맵을 컴포지터 쓰레드로 업로드 하며, 컴포지터 쓰레드는 이 비트맵을 로드하여 화면에 새로 그리는 작업을 반복합니다.

transform의 translateY값을 0px -> 100px로 1초동안 점차 증가하는 방식으로 애니메이션이 동작할 경우에는 최초 해당 엘리먼트에 대한 비트맵이 업로드 된 이후로는 해당 비트맵 업로드 없이 컴포지터 쓰레드가 기존의 비트맵을 가지고 위치를 1px씩 이동시키는 작업을 반복합니다.

그렇기 때문에 transform 처럼 비트맵 로드를 적게 하는 애니메이션이 top의 값을 이동하는 것처럼 비트맵 로드를 많이 하는 애니메이션보다 빠르고 부드럽게 동작합니다.

다음은 상대적으로 빠른속도를 가지는(비트맵 업로드를 적게 하는) css 변환 속성 들입니다.

css transform

css opacity

css filter(브라우저와 필터의 복잡도에 따라 다름)

이처럼 좀더 부드럽고 빠른 페이지를 위해서 css 애니메이션을 이용할 때는 위의 속성을 사용하는 걸 추천드립니다.

국내에도 함수형 프로그래밍 패러다임에 대한 관심이 조금씩 늘어가고 있는 것 같습니다. 올해에 두 권의 번역서가 출간되었는데요. 그중 자바스크립트를 기반으로 함수형 프로그래밍을 다루는 책이 있어 읽어봤습니다.

자바스크립트에 대한 기본 지식(prototype, scope, closure 등)이 있는 개발자가 함수형 프로그래밍에 대해서 알고 싶다면 추천해드립니다. 익숙치 않은 개념들과 더불어 함수로 조합하기, 재귀 호출의 한계 극복, 상태 변경 최소화, 흐름 기반으로 프로그래밍하기, 클래스를 사용하지 않고 코딩하기 등 많은 기법들을 설명하는데 한번에 완벽하게 이해하기는 힘들더군요. ^^; 여러 차례 읽어봐야 할 것 같습니다.

정말 오랜만에 MS의 소식으로 글을 올립니다.^^

6월 16일 MS에서 차기버전의 Internet Explorer에 들어갈 예정인 새로운 기능을 미리 사용해 볼 수있는 "Internet Explorer Developer Channel"을 발표하였습니다.

다시말해서 Chrome Canary처럼 미리 최신 기능들을 사용해 볼 수 있는 웹 개발자 용 Internet Explorer 입니다.

기존의 Internet Explorer 11과 함께 사용할 수 있으며 웹 개발자가 현재 개발중인 새로운 기능을 좀 더 일찍 사용해 보고 그 기술을 평가하거나 MS에 피드백을 할 수 있습니다.

그럼 Internet Explorer Developer Channel에 추가된 주요 기능들을 간략하게 살펴 볼까요.

현재 공개 된 Internet Explorer Developer Channel은 Internet Explorer 11의 모든 기능과 그 외에도 다음과 같은 새로운 기능이 추가되어 있습니다.

WebGL 지원 브라우저에서 3차원 이미지를 빠르게 렌더링하기 위한 사양. 이미 기존의 Internet Explorer 11에서도 WebGL을 지원하고 있지만, 기능추가 등으로 성능이 향상되었습니다.

(참고: WebGL updates in Developer Channel)

Gamepad API

Web 브라우저의 컨트롤 장치로 게임기의 컨트롤러와 같은 장치를 사용하기 위한 사양.

(참고 : W3C 게임 컨트롤러 대응의 표준 사양 "Gamepad API" 초안공개, Gamepad API in Developer Channel)

WebDriver Web 어플리케이션의 자동테스트를 위한 API. 원래 JavaScript 테스트 자동화 도구인 Selenium의 기능을 표준화하여 Web 브라우저에 추가할 예정으로 W3C에서 표준화를 진행하고 있습니다.

(참고 : W3C WebDriver 사양, WebDriver API in Developer Channel)

F12 도구 UI, DOM 탐색기, 디버거 등의 기능이 강화되었습니다.

(참고: F12 updates in Developer Channel)

최근 3월 11일 새벽에 iOS7.1이 정식 배포되었습니다. 링크

여러가지 업데이트 스펙 중에서도 특히, Mobile Safari에서 자동으로 UI를 최소로 줄일 수 있는 새로운 속성이 추가 되었는데요.

새로이 추가된 minimal-ui 속성에 대해 살펴보겠습니다.

minimal-ui란?

Safari 브라우저에서 페이지 로딩 시 상/하단 메뉴바를 사라지게 할 수 있는(최소화시키는) 속성

    아래 minimal-ui 적용 전과 후 테스트 페이지를 작성하여 비교해 보았습니다.

<일반버전(왼쪽)과 minimal-ui가 적용된 버전(오른쪽)>

minimal-ui 동작

    minimal-ui 동작상의 차이점을 요약하자면,

minimize : 페이지 로딩 시, 상/하 스크롤 시에도 메뉴바가 최소화 상태가 유지됩니다.

tapping url : 메뉴바를 다시 보이기 위해선(유일한 방법은) 상단 url을 tapping 해야 합니다. 

                        이 때, 컨텐츠 영역이 dimmed되고 그 영역을 터치하면 다시 최소화 상태로 돌아가게 됩니다.

minimal-ui 적용

    적용 방법은 상당히 간단한데요.

<meta name="viewport" content="width=1024, ... , minimal-ui">

    이처럼 viewport 메타태그 속성에 minimal-ui만 추가해주면 됩니다.

웹 개발을 하다보면 cookie 관련 작업을 종종 할 텐데요. cookie를 만들고 삭제할 때 유의해야 할 사항이 하나 있습니다.

바로 쿠키 생성시에 domain 값을 어떻게 생성하느냐에 따라 생성되는 쿠키의 domain 값이 달라지는 것이죠

아래 사진은 같은 도메인에서 다른 방식으로 쿠키를 생성한 경우입니다.

1. 아래 코드를 사용해서 m.daum.net에서 cookie 를 생성하면 domain 값이 m.daum.net 이 됩니다. 이 경우 해당 쿠키는 하나의 domain (m.daum.net) 에서만 사용이 가능합니다.

document.cookie = "foo=bar; path=/; domain="; // 또는 document.cookie = "foo=bar; path=/;";

* domain 값을 주지 않으면 자동으로 위와같이 빈 스트링이 들어가게 됩니다.

2. 반면 아래와 같은 형태로 m.daum.net 에서 cookie 를 생성하면 domain 값이 .m.daum.net 이 됩니다. 이 경우에는 해당 도메인의 subdomain 에서도 쿠키를 사용 할 수 있게 됩니다.

document.cookie = "foo=bar; path=/; domain=m.daum.net";

매우 간단한 것 같지만 주의해야할 점이 있는데요. 바로 쿠키를 삭제할 때도 생성할 때와 같은 domain 값으로 삭제해야 한다는 겁니다.

또한 위 두가지 방식 모두로 생성한 경우 같은 이름의 쿠키가 있을텐데요. 이 경우 쿠키의 적용 우선순위는 해당 도메인에 적용되는 모든 쿠키(위 두가지 방법 모두 포함)들 중에 1. Path value 가 긴(자세한) 쿠키가, 2. Path value도 같은 경우에는 먼저 만들어진 쿠키값이 우선 적용됩니다.

혹시나 예전에 생성한 쿠키가 잘 지워지지 않거나 새로만든 쿠키가 잘 적용되지 않는 문제가 있다면, domain attribute 를 한번 잘 살펴보는게 도움이 될 것 같네요 !

지난 1월 28일 Chromium Blog에서 Mobile Chrome Apps 프로젝트가 공개되었습니다. (링크) 

사실 해당 프로젝트는 이전부터 github 에서 진행해온 것으로 알려졌는데요. 2013년 12월 Chromium Google Groups 에서 언급된 이후 공식적으로는 처음 소개되었습니다.

Mobile Chrome Apps란?

Mobile Chrome Apps는 데스크탑 크롬앱을 Apache Cordova를 기반으로 한 Android와 iOS 하이브리드 웹앱으로 포팅하기 위한 도구입니다.

Mobile Chrome Apps 프로젝트를 살펴보기 전에 먼저 Chrome Apps 와 Apache Cordova를 간단히 살펴보도록 하겠습니다.

Chrome Apps

Desktop Platform 에서의 Chrome Apps 는 이미 브라우저 확장 프로그램에서 벗어나 점차 별개의 네이티브 앱과 유사한 모습을 갖추어 가고 있습니다. (참고 : A new breed of Chrome Apps)

오프라인에서 구동되고, 네이티브 앱에서만 사용 가능한 각종 API들을 사용할 수 있으며, Chrome App Launcher 를 통해서 앱을 바로 실행할 수 있게 된 것이죠.

물론, 이 모든것을 HTML, CSS, Javascript 와 Chrome Apps API 를 사용하여 개발 가능합니다. 또한 크롬 웹스토어에는 이러한 유형의 Chrome Apps 를 위한 별도의 카테고리가 존재합니다.

Apache Cordova

Apache Cordova 는 HTML, CSS 와 Javascript 를 사용하여 하이브리드 모바일 앱을 개발하도록 해주는 도구입니다. 이전 이름이었던 PhoneGap 이라는 이름으로 더 잘 알려져 있습니다. (Adobe 사가 PhoneGap을 인수한 이후 Apache 재단에 기부하였으며 현재 Apache Cordova로 이름이 변경되었습니다.)

Apache Cordova를 사용하면 네이티브 앱에서만 사용 가능한 카메라나 앨범과 같은  각종 네이티브 API를 사용할 수 있습니다.

Mobile Chrome Apps

이제 다시 돌아와서 Mobile Chrome Apps 를 살펴보면, Desktop Chrome Apps 와 같은 API를 Apache Cordova 의 Custom Plugin(주로 iOS와 Android용) 형태로 구현하고 있다는 것을 알 수 있습니다. Mobile Chrome Apps 의 Dev Workflow를 따라 cca 라는 Command Line Tool을 이용해서 프로젝트를 생성하면, Chromium plugin을 포함하여 생성해 줍니다.

현재 크롬 API의 구현 상태는 아래 링크에서 볼 수 있습니다.

https://github.com/MobileChromeApps/mobile-chrome-apps/blob/master/docs/APIStatus.md

아직 개발되지 않은 API들이 있지만 지원되는 API를 사용하여 Dev Workflow를 따라해보면 Mobile Chrome Apps를 쉽게 사용해 볼 수 있습니다.

현재 iOS 6+ 와 Android 4.x+ 를 지원하며, 개발을 위해서는 

nodejs > 0.10

Android : JDK7, Android SDK > 4.4.2, Apache Ant

IOS : Xcode5, ios-deploy, ios-sim

CCA (command line tool)

가 필요합니다.

만약 이전에 만들어둔 Chrome Apps를 Hybrid Mobile App으로 포팅하고 싶다거나 Desktop 과 Mobile 에서 모두 작동하는 Chrome Apps를 만들어 볼 계획이라면 이 프로젝트를 눈여겨 봐야 할 것 같습니다.

하지만 github 커밋 내역을 보면 알 수 있듯이 Mobile Chrome Apps는 아직 한창 진행중인 프로젝트이므로 완성도 있는 모바일 앱을 만들기 위해서는 좀 더 시간을 두고 봐야 할 것 같습니다. ^^

Mobile Chrome Apps 관련 URL

Sample Apps

Repository

Stack Overflow

G+ Developer Page

아래와 같이 하나의 페이지를 http, https 두 프로토콜 에서 동시에 지원하는 경우가 있습니다.

http://foo.bar/

https://foo.bar/

특히 https 페이지를 지원할 경우 브라우져의 보안 경고를 피하기 위해서 해당 페이지에서 사용하는 모든 리소스가 https 프로토콜을 사용하여야 합니다. 만약 그렇지 않을 경우 아래와 같은 경고창을 볼 수도 있습니다.

그렇다면 똑같은 페이지에서 단지 https프로토콜 지원을 위해 페이지내의 모든 리소스 호출 url을 https url로 바꿔야 할까요?

모든 리소스에 대해서 http와 https 프로토콜을 동시 지원할 수 있다면 protocol-relative URL 을 사용하여 이같은 문제를 쉽게 해결 할 수 있습니다.

리소스 호출 url을

http에서는 http://foo.bar/zoo.js

<script src="http://foo.bar/zoo.js"></script>

https에서는 https://foo.bar/zoo.js

<script src="https://foo.bar/zoo.js"></script>

로 각각 사용하는 대신에

http, https 둘다 //foo.bar/zoo.js

<script src="//foo.bar/zoo.js"></script>

둘 모두 위와 같이 사용해주면 되는 거죠.

그러면 http에서는 http 프로토콜 url로 호출을 해주고, https 에서는 https 프로토콜로 호출을 하게 됩니다.

위와 같은 Protocol-relative URL 은 RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax", Section 4.2. 에 명시된 표준 스펙입니다.

다만 ie 브라우저의 경우 버젼 7 이상부터 지원하며, 7, 8 버젼의 경우 link 태그 혹은 @import를 이용한 stylesheet 호출시에는 해당 리소스가 두번 다운로드 되는 버그가 존재 합니다. 동작에는 문제가 없으나 다운로드를 두번해서 성능적인 이슈가 발생하게 되는거죠.

지난 4일, 열여덟 번째 생일을 맞이한 주인공을 아시나요? 바로 자바스크립트입니다. 최초 공개 당시 보도 기사와 지금까지의 굵직한 사건들, 그리고 여러 통계 자료 및 나아갈 방향에 대한 포스팅이 있어 일부 흥미로운 내용을 추려 소개합니다. :)

원문 주소 : http://resin.io/happy-18th-birthday-javascript/

성능

동일한 하드웨어에서 FF3.5 부터 Chrome23 까지의 성능 테스트 결과를 비교한 챠트입니다. 초창기에는 업데이트마다 성능 향상의 폭이 컸지만 최근에 이르러서는 그 폭이 점점 줄어들고 있는데요, 각 엔진의 성능 최적화가 어느 정도는 충분히 진행되었다고 볼 수 있겠습니다.

생태계

NPM이 지난해 초부터 지금까지 10배에 가까운 빠른 성장세를 보이고 있습니다. 이런 추세라면 2015년 2월쯤엔 Rubygems, Maven Central을 따라잡을 수도 있다는 예측까지 나오고 있네요. ^^

채택률

위 챠트 분석에 따르면 새로운 프로젝트에서 사용할 언어를 선택할 때 높은 채택률을 보이던 루비를 점차 대체해가는 양상이네요.

엔터프라이즈

스타트업 생태계가 node.js를 중심으로 성장해가고 있고, Yahoo/PayPal/LinkedIn 같은 큰 회사들도 도입에 많은 투자를 하고 있다고 합니다. 심지어 Walmart 같은 곳까지!

클라이언트/서버 컨버젼스

클라이언트 JS 생태계가 전통적으로 서버측의 것으로 여겨졌던 영역까지 API를 확장해나가고 있습니다. (File API, Device API 등) Chrome Apps, Mozilla WebAPI, Tizen Web APIs 모두 하드웨어에 대한 완전한 접근을 목표로 많은 노력을 하고 있는데요, 조금 다른 방향으로 node-webkit이라는 흥미로운 프로젝트는 양측을 연결해주는데 집중하고 있습니다.

임베디드 JS

종종 여러가지 이유로 모바일 웹에서 앱을 호출하고 싶을때가 있습니다.

보통 어떻게 하시나요? 

아마도 앱이 있으면 앱을 실행하고 그렇지 않으면 앱스토어로 이동하도록 custom URI-scheme을 사용하시고 있을 것 같은데요. 아이폰과 안드로이드에서 각각 몇가지 문제가 있어서 아마도 사용하실때 곤란함을 느끼실거라고 생각됩니다.

그래서 모바일 웹에서 앱 호출시에 알아두어야 할 사항을 간략히 정리해보았습니다.

아이폰

아이폰에서는 custom URI-scheme에 timeout을 사용하는 방식이 잘 알려져 있습니다.

function web2app_iOS() {

    setTimeout(function () {

        moveToStore();

    }, 25);

    launchApp();

}

우선 앱을 실행해보고 앱이 실행되지 않으면 마켓으로 이동하는 방식으로, 앱 실행시에는 스토어 이동이 취소되고, 그렇지 않은 경우에는 스토어로 이동하도록 타이머를 이용하는 방법입니다.

하지만 가끔 스토어로 이동후에도 timer가 취소되지 않고, 앱이 없을때 뜨는 시스템 얼럿이 뜬다는 단점이 있습니다.

그래도 현재, 앱을 실행하고 앱이 없는 경우 스토어로 이동시킬 수 있는 유일한 방법입니다 :D

안드로이드

반면 안드로이드에는 두가지 방법이 있습니다.

1. iframe을 embedding하면서 custom URI-scheme을 사용하는 방식

아이폰과 유사한 방식이지만 custom URI-scheme을 실행할때 iframe을 사용하고, 앱 실행 후 다시 웹으로 돌아왔을때의 시간차를 이용한 방식입니다.

function web2app_android_scheme(launchURI) {

    var clickedAt = new Date().getTime();

    setTimeout(function () {

        var now = new Date().getTime();

        if (isPageVisible() && now - clickedAt < 2000) {

            moveToStore();

        }

    }, 1000);

    var iframe = createHiddenIframe();

    iframe.src = launchURI;

}

보통 위와 같은 방식을 사용하고, 크롬을 제외한 대부분의 브라우저에서 잘 동작합니다.

2. intent-based URI를 사용하는 방식

모바일 크롬 25버전부터는 iframe을 embedding 하는 방식이 동작하지 않습니다.

구글에서는 iframe을 embedding하여 custom URI-scheme을 쓰는 방식 대신 intent-based URI를 사용하도록 하고 있습니다. 

킷캣부터는 웹뷰도 크롬기반으로 동작하고, 제조사들도 기본 브라우저를 크롬기반으로 개발하는 추세이니 intent-based URI 방식의 활용도가 점점 더 높아질 것으로 보입니다.

function web2app_android_intent(launchURI) {

    top.location.href = launchURI;

}

한가지 단점이 있다면 플레이 마켓 이동시 앱의 최종 타겟 링크가 아닌 중간목록으로 연결된다는 점입니다 -_-;;

* intent-based URI의 syntax는 아래에서 확인할 수 있습니다. 

https://developers.google.com/chrome/mobile/docs/intents

현재 안드로이드에서 모바일 파이어폭스와 오페라의 경우는 intent-based URI를 지원하지 않습니다. 크로미움을 기반으로 하는 오페라의 경우도 마찬가지 입니다.

소스 파일 마다 똑같은 내용이 적혀있는 jshint 주석 거슬리지 않으셨나요? 빌드 자동화를 위해 grunt 를 도입해놓고 보면 Gruntfile.js 에도 또 같은 내용을 넣어주어야 합니다. 게다가 여러분의 IDE에 integration 되어있는 jshint plugin 마다도 jshint 옵션이 들어있을겁니다. 중복!

사실 jshint 에는 다양한 옵션 설정 방법이 제공됩니다. 그 중 .jshintrc 파일 설정법을 사용하면 옵션 중복 문제도 해결하고, 프로젝트 전체에 공통 규칙을 적용하거나 협업하는 사람들간에도 일관된 규칙을 사용할 수 있어 좋습니다.

사용법은 프로젝트 적당한 위치 - 대부분은 프로젝트 루트 - .jshintrc 파일을 만들고 JSON 형식으로 옵션값을 적어주시면 됩니다.

.jshintrc:

{ "curly": true, "eqeqeq": true, "eqnull": true, "browser": true, "loopfunc": true, "globals": { "clay": true } }

이제 Grunt 에서 rc 파일을 불러다가 사용할 수 있습니다.

Gruntfile.js:

grunt.initConfig({ jshint: { options: { jshintrc: '.jshintrc' }, // ... }

IntelliJ 에서도 .jshintrc 파일을 사용하도록 할 수 있습니다.

구글은 JavaScript를 대체할 목적으로 오픈소스 웹 프로그래밍 언어인 Dart를 만들고 있는데요, 최근(11월 13일/현지시간 기준)에는 'Dart SDK 1.0'을 공개했습니다[관련링크].

Dart의 눈에 띄는 특징들을 뽑아보자면 다음과 같습니다.

JavaScript의 superset 이 아니고,

자체적으로 제공하는 별도의 VM이 존재하여 Java처럼 독립적으로 실행될 수 있으며,

웹 브라우저에서 컴파일러(dart2js)를 이용하여 js로 컴파일하여 실행할 수 있다.

Dart에서 내세우고 있는 이런 특징들을 살펴보면, 단순히 JavaScript의 대안이 아닌 다양한 웹 어플리케이션 개발환경을 통합하고자 하는 더 큰 목표를 갖고 있는지도 모르겠습니다.

그런데 Dart 개발에 언어/VM/라이브러리/JS컴파일러/IDE Plugin/전용 IDE(Spark) 등 광범위하게 리소스를 쓰고 있는데 반해, 개발자 커뮤니티 호응은 그리 크지 않은 상황입니다. 경쟁/이해관계자들의 시선 또한 - 당연하게도 - 곱지 않은 듯 합니다. Spark를 보면 Chrome OS 의 개발 플랫폼 혹은 도구로 포지셔닝 하려는 것은 아닐까 하는 생각도 드네요.

제목은 coffeescript로 일부 적긴 했지만 본래 javascript 로 풀어쓰면 이런 코드 입니다.

window.addEventListener('load', function () { setTimeout(function () { window.scrollTo(0, 1); }, 0); });

주소창 숨기기

위 코드는 모바일웹에서 흔히 볼 수 있는 '주소창 숨기기'라는 기능을 수행하는 코드인데요. 코드만 봐서는 쉽게 이해가 가지 않지만, 실제로 위와 같이 페이지가 로드된 이후 timer를 통하여 scrollTo 시킬 경우 주소창이 부드럽게 애니메이션되며 사라지는 기능이 실행이 됩니다. 작은 화면에서 조금이라도 더 viewport를 넓히고자하고자 하는 노력이였죠. 브라우저의 공식 API로 제공되는 기능은 아니며, iOS에서 처음 소개된 이후 타 브라우저들에서도 따라 구현된 상태입니다. raising the bar on mobile 참고

iOS7은 주소창 고정

그런데 아시다시피 iOS7 부터는 주소창이 고정으로 바뀌었습니다. 어느 순간 보니 Android의 브라우저들도 많이 바뀐 것 같구요. 위 코드는 지금도 유효할 까요? 그래서 재검토 해보았습니다.

iOS7: 주소창이 항상 노출

Chrome For Android(구버전, 28 이전): 주소창이 항상 노출

Chrome For Android(최신버전): 주소창 노출 동작을 브라우저가 자체적으로 판단

Galaxy 시리즈의 Chromium 기반 스톡브라우저: 주소창이 항상 노출

Jelly Bean 이상의 스톡브라우저: 주소창 노출 동작을 브라우저가 자체적으로 판단

LG Optimus G Pro / JB 4.1.2: 해당 스크립트와 상관없이 자체적으로 주소창 숨기기 기능이 동작됨

Galaxy S4 / JB 4.2.2: 주소창 고정. 주소창 숨기기 동작하지 않음

Galaxy S3 / JB 4.1.2, Galaxy Note 2 / JB, Galaxy S2 / JB 4.1.2: 해당 스크립트와 상관없이 자체적으로 주소창 숨기기 기능이 동작. (간혹 동작하지 않는 경우도 관찰)

이처럼 최신 브라우저들은 주소창 숨기기가 불가능하거나, 브라우저 자체적으로 주소창을 숨기는 기능을 수행하고 있습니다. 이런 브라우저에서 위의 코드를 실행할 경우 scrollTo(0, 1) 의 부작용으로 의도치않게 화면이 1px 위로 스크롤되는 문제가 발생합니다.

부작용

사실 그 외에도 여러 부작용들이 있습니다:

페이지 로드 이전에 사용자가 화면을 스크롤 했을 때, 위 스크립트로 인하여 다시 화면 최상단으로 튕길 위험성이 있습니다. 우회법으론 touch event를 감지하여 사용자가 직접 스크롤 시켰을 경우 스크롤 시키지 않는 방법이 있습니다.

뒤로가기 기능을 통해 이동하였을 때 이전 보던 스크롤이 유지 되는게 아닌, 화면 최상단으로 튕길 위험성이 있습니다. Android에서 페이지 이동간에 pageYOffset 값이 일시적으로 부정확하게 나오는 문제로 인한 현상인데, 역시 몇가지 우회법은 존재합니다.

우회법들이 적용되면 대략 이런 형태:

setTimeout(function () { if (window.pageYOffset <= 0 && isUserTouched === false) { window.scrollTo(0, 1); } }, 400);

결론

그간 작은 화면을 조금이라도 더 넓게 쓰고자 주소창 숨기기 스크립트가 널리 활용되어 왔는데요. 위에 조사 결과처럼 최신 브라우저들은 알아서 처리해주고 있고, 부작용도 많고, 스마트폰 크기도 꽤 커졌고... 이제는 그 효용성이 다한게 아닌가 싶습니다. 여러분 웹페이지에 주소창 숨기기 스크립트가 아직도 남아있다면 이젠 은퇴시켜야할 때가 된 건 아닐까요? :)

지난 11월 21일 Chrome 브라우저의 최신판인 32 Beta가 출시되었습니다. 이번 Beta 버전에서 바뀐 부분들 중 눈에 띄는 것들은 아래와 같이  4가지 정도로 요약이 될것 같습니다.

모든 플랫폼에서 WebP의 애니메이션 이미지 지원

안드로이드 크롬에서 터치 반응속도 개선

NPAPI 차단

Vibration API 지원

그럼 변경된 부분들에 대해서 좀 더 자세히 살펴보도록 하겠습니다.'

Animated WebP

WebP는 기존에 사용중인 JPEG나 PNG를 대체하고자 구글이 내놓은 새로운 이미지 포맷입니다. WebP 애니메이션은 기존의 GIF 이미지를 대체하기 위한 포맷으로 GIF와 달리 alpha 채널을 제공하고, 손실/무손실 압축의 선택이 가능하며 파일용량도 GIF에 비해서 크게 줄일 수 있습니다.

이전 버전의 Chrome에서 WebP를 지원하고 있긴 했지만, WebP 애니메이션의 경우엔 성능상의 문제로 인해 지원을 하지 않고 있었는데, 이번 Beta 버전부터 WebP를 완전하게 지원하게 되었습니다.

touch 반응속도 개선

Android Chrome의 터치 반응속도가 빨라졌습니다. 터치속도의 고속화 방법을 들여다보면 기존에는 더블 탭 시에 줌인식을 위해 touch 이벤트간에 300ms정도의 지연이 있었습니다. 하지만 안드로이드의 Chrome 32 Beta 버전부터는 모바일 더블탭이 사라지게 되었습니다. 모바일 사이트에서는 자동으로 페이지 넓이에 맞게 포맷되어 있기때문에 바로 click 이벤트를 수신하고 빠르게 사용자의 입력에 대해 응답할 수 있게 되었습니다. 

NPAPI 기본차단

이전의 기사에도 나왔었지만 Netscape Plugin Architecture Programming Interface (NPAPI) 플러그인이 차단되었습니다. 1월부터는 stable 버전에서도 일부의 예외 플러그인(Microsoft Silverlight、Unity、GoogleEarth、Java、Google Talk、Facebook Video) 이외의 모든 NPAPI 플러그인은 차단이 됩니다. 이번 Beta 버전에서도 stable 버전의 출시에 앞서서 적용이 된 상태입니다. 물론 NPAPI가 기본적으로 차단되지만 사용을 위해서 아래의 화면처럼 주소창 우측에 표시된 차단/허용 버튼을 클릭해서 활성화 할 수있습니다.

참고 : NPAPI deprecation: developer guide

Vibration API

이번 안드로이드용 Chrome Beta 버전부터는 Vibration API를 지원합니다.

Chrome Apps and Extensions APIs

크롬앱과 크롬확장 API들의 변경사항들입니다.

signedInDevices API - 사용자가 서명한 장치의 목록을 검색할 수 있습니다.

MediaGallery API - Picasa에서 앨범가져오기를 할 수 있습니다.

The Identity API - 로그인/로그아웃의 이벤트를 제공합니다.

시크릿 창에서도 사용자의 동의에 따라서 확장프로그램의 사용이 가능합니다.

chrome.runtime API - 강력한 보안이 필요한 앱이나 확장프로그램에 TLS channel ID를 제공합니다.

그외

Chrome 31 Beta 버전에서 지원했었다가 31 정식버전에서는 제외되었던 "홈 화면에 추가하기"가 다시 추가되었습니다.

console.table 이란 메서드가 있었네요!

frontend web 개발에 첫발을 딛는 분들이 가장 많이 잘못 알고 쓰는 부분 중 하나가 DOM Events 인데요. 특히나 'javascript를 jquery로 배웠어요' 하는 분들에게는 더욱... 그런분들에게 - 그동안 그냥 막 써왔던 분에게도 - 참 좋은 글이 Smashing Magazine에 올라왔습니다. 차근차근 하나씩 설명해줍니다. 항목만 봐도 참 알차네요.

http://coding.smashingmagazine.com/2013/11/12/an-introduction-to-dom-events/

Listening For Events

Removing Listeners

Maintaining Callback Context: closure, bind

The Event Object

Event Phases: capturing, bubbling, event target

Stopping Propagation

Prevent The Browser’s Default Behavior

Delegate Event Listeners

요즘에야 node.js를 비롯해서 javascript의 활용 범위가 다양해졌지만, 일반적으로 javascript 프로그램은 웹브라우저 환경에서 동작하는 걸 가정합니다. 그렇다 보니 그동안 javascript 단위 테스트 자동화를 하기란 불가능해보이거나 꽤 지저분한 작업이었습니다. ant, rhino, selenium, httpunit, jsunit, qunit, jscoverage 와 같은 무언가 20%씩 아쉬운 도구들을 사용해야했고 이러한 도구들을 엮어주기 위해서 직접 스크립트들도 작성해야 했습니다. 특히 브라우저 환경과 터미널 환경과의 연계 작업은 참 골치아픈 작업이었죠.

이랬던 상황이 grunt와 phantom.js가 나오며 급변하고 있습니다.

먼저 단위 테스트 코드는 jasmine으로 작성합니다. jasmine을 BDD 프레임워크라고 하지만 이게 TDD인지 BDD인지는 쓰는 사람 마음속에 있는 겁니다. :)

javascript 개발, 빌드(transcoding or concat or minify) 과정은 grunt로 자동화 합니다.

그리고 grunt-contrib-jasmine task로 빌드 과정에 단위테스트를 연계시킬수 있습니다. 단위 테스트는 당연히 브라우저 호스트 환경(phantom.js)에서 실행됩니다.

웹브라우저에서 테스트를 돌리기 위해 웹서버를 띄워야 한다면 grunt-contrib-connect를 쓰면 됩니다.

grunt-contrib-watch task를 통해서 소스코드가 변경될 때 마다 자동으로 테스트를 실행시켜줄 수도 있습니다.

단위테스트 결과는 junit 포맷으로도 뱉어주기에 jenkins와 같은 기존 CI도구와도 손쉽게 연동됩니다.

테스트 커버리지는 istanbul을 통해서 확인할 수 있습니다.

istanbul로 instrument 하고 테스트 수행하고 결과를 뽑아내면 되는데, 이마저도 grunt-template-jasmine-istanbul 를 사용하여 간단히 처리할 수 있습니다.

결과물은 HTML 리포트로도 나오지만 cobertura(java진영의 커버리지 도구) 포맷도 지원해주기 때문에 역시 jenkins에 쉽게 연동할 수 있습니다.

단위테스트가 아니라 인수테스트가 필요하다면 jasmine 대신에 casper.js 를 사용하시면 됩니다.

적다 보니 무언가 복잡해 보이지만 결국 grunt task들만으로 손쉽게 테스트자동화와 관련된 문제가 해결됩니다.