모질라, 크롬의 NPAPI 지원 중단(사용불가) 계획 진행 상태.

모질라, 크롬에서 NPAPI 지원 중단(사용불가) 얘기는 갑자기 나온건 아니고 일년전부터 꾸준히 준비해오던 것이고 그 계획에 따라 내년 9월이면 크롬브라우저에서는 NPAPI가 완전 퇴출(동작하지 않음)된다. 현재는 많이 쓰이는 몇몇 NPAPI 사용 플러그인에 대해 화이트리스트 형식으로 허용하고 있는 상황이고 새로 추가되지는 못함.

그전에 잠깐, NPAPI가 뭐냐면 Nescape Plugin Application Programming Interface의 약자로 브라우저 등장 초창기에 브라우저의 기능을 확장할 수 있는 표준 메커니즘을 제공하기위해 소개되어 오디오/비디오 재생 등의 현대적인 웹 플랫폼 기능들이 이 NPAPI를 활용해서 제공되었다.

웹과 브라우저 자체가 향상되면서 이 NPAPI는 이제는 너무 낡은 방식인데다 꼬리표 처럼 달고 다니는 보안 문제를 해결하기 위해 이 NPAPI 퇴출 프로그램이 진행되고 있는것이다.
NPAPI가 제거되면 실버라이트, Java(애플릿 / 웹스타트), 오픈뱅킹, 유니티(멀티플랫폼게임엔진) 등을 사용할 수 없게된다.
특이하게 크롬에서 내장 플래시, PDF뷰어는 NPAPI를 사용지 않기(PPAPI를 사용)때문에 영향은 없다고 하네요.(다른 브라우저는 사정이 다를 수도 있지만..)

구글 측에서 제시하는 대안 기술로는 NaCL , APPS , Native Messaging API, 구형브라우저지원이 있다.
2014/11/28 14:18 2014/11/28 14:18
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

OS - 웹 브라우저별 화면 캡처

사이트를 개발하다 보면, 혹은 호기심에라도 특정 URL이 여러 OS와 다양한 브라우저에서 보여지는 모습을 확인할 필요가 생기기 마련이다.

이런 경우 간편하게 온라인상에서 각 OS별로 웹브라우저에서 보여지는 웹 화면을 캡처 해주는 사이트가 있다.

http://browsershots.org/

사이트의 소개에 따르면 Johann C. Rocholl씨가 만들었고 Open Source로 진행되고 있는 서비스라고 한다.

XML-RPC도 지원하기 때문에 외부에서 매쉬업 할 수있는 길도 열어 놓았다.

어떤식으로 브라우저를 캡처해 내는지 궁금해서 소스를 내려받았는데 파이썬으로 되어있네..
파이썬의 P도 모르는 게 못내 아쉬운 순간이다.

2008/12/17 13:49 2008/12/17 13:49
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

IE8의 IE7 에뮬레이션 CSS Hack

일전에 IE8 은 기본적으로 web standard 모드로 동작한다는 글을 올린적이 있습니다.
IE8을 설치하면  'Emulate IE7' 메뉴가 있는데요. 이는 개발자, 디자이너가 아니라면 'Emulate IE7'를 클릭하여
기존 IE7으로 웹서핑을 하듯이 브라우저를 이용 할 수 있습니다.
Emulate IE7

IE7 에뮬레이션 버튼


하지만 사이트를 사용자들에게 'IE7모드로 사용해 주세요.'와 같이 요구하는것은 심리적 반발감을 일으킬수도 있을겁니다.

이의 우회방법으로 버전타겟팅을 이용한 편법이 있습니다.
메타태그를 이용하여 ie7렌더링 엔진을 사용하게 함으로써 레이아웃이 망가지는것을 피하는 방법입니다.
[code]
<meta http-equiv="X-UA-Compatible" content="IE=7" />

[/code]
위와 같이 메타태그를 html 헤더에 삽입하면 됩니다만.. 문제는 ie7용 css 코멘트핵을 사용하고 있을 경우인데요.
메타태그로 렌더링은 ie7처럼 하게 되었지만 브라우저 자체는 ie8이므로 ie8의 핵을 이해하므로 아래와같이 ie7용
CSS를 적용해 주실 수 있습니다.
[code]
<!--[if gte IE 7]>
  <link type="text/css" rel="stylesheet" href="styleie7.css" />
<![endif]-->

[/code]
브라우저가 'IE7과 그이상'인 경우 styleie7.css를 적용하겠다는 뜻입니다.
2008/03/27 15:53 2008/03/27 15:53
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

브라우저별 DOM 과 innerHTML 수행 속도 비교

원문은 http://blog.naver.com/ungahah/40032248947
입니다. 블로그 원문에는 이미지가 보이지 않아서 부득이 편집 하게 되었습니다.

Gleb Lebedev 라는 사람이 아주 재미난 실험을 해서 소개 한다.
그는 간단한 페이지를 통해(구글메인같은) 자바스크립트의 성능테스트 를 하고 싶어했다.
그리고 그 결과를 오페라9, 파이어폭스 1.5, 익스플로러 6 에서 비교했다.

테스트는 이렇다.
그는 구글 메인페이지전체(라고해봐야 몇줄 안되지만..)를 innerHTML 속성과 document.createElement를 이용해 생성하는 함수를 짰다.(소스 )
그리고 그걸 1초동안 반복해서 실행한다.
결국 초당 구글 메인페이지를 몇번이나 만들어 낼수 있느냐를 테스트 한거다.

브라우저별 DOM 과 innerHTML 수행 속도 비교

이미지 출처 : http://ajaxian.com/archives/benchmark-dom-vs-innerhtml


결과가 아주 놀랍다.
오페가 9.01 는 innerHTML로 돌리리때 1초에 1320번이라는 경의적인 수치를 보여준다!
요즘 한참 잘나가는 불여우에 비해서도 3배가 넘는 수치다.
자바스크립트처리 성능만 놓고 볼때는 왜 오페라가 3브라우저중 밀리는지 이해불가다.
IE6은 초라하기 그지 없다. 더군다나 32비트, 64비트 버전이 별만 차이가 없다. (IE 7.0이 출시  됬으니 따로 한번 해봐야겠다. ^^)

브라우저별 성능은 이쯤하고..

중요한건 DOM과 innerHTML과의 비교다.
createElementinnerHTML은 모든 브라우저가 가각 3배 가까이 차이가 난다.
왜 이렇게 차이나 나는 것일까?
createElement는 W3C에서 정한 HTML DOM을 다루는 표준방식이며 HTML의 요소를 객체로 접근도록 해서 프로그램을 좀더 프로그램답게 무언가 '짜고 있다는' 느낌이 들게 하는 반면,  innerHTML은 HTML을 몽창 문자열로 넘겨서 무언가를 '쓰고 있다는'느낌들 들게하는데  말이다.
하지만 이건 조금만 생각해보면 당연한 결과다.
위의 소스를 보면 알겠지만, innerHTML은 이 속성을 한번 호출하는 것으로 끝나지만,
createElement는 그렇지 않다. 개별 HTML 요소를 모두 생성하여 해당 style과 property 값을 넣어주어야 하고, 그걸 형태에 맞게 append를 시켜야 한다.
위의 구글 메인을 만들어내는데 createElement는 자그마치 69번이나 호출된다.
느린게 당연한거다.

결국 용도에 맞게 쓰는것이 중요하단 무미건조한 결론을 내릴 수 밖에 없다.
이런 테스트가 별 근거없이 개발자가 자신의 기호에 따라 한쪽에 편향하기 보다, 성능과 객체 컨트롤의 용의함을 잘 저울질 해서 적절히 쓸 수 있었으면 좋겠다.

p.s. Ajaxian 에 가서 Comment를 보면 사람들이 자신의 PC에서 테스트 한 다양한 결과를 볼 수 있다. ^^
2007/07/07 01:32 2007/07/07 01:32
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다