Browser Fingerprinting ㅗㅜㅑ

HTML5 성행 이전에는 브라우저 내 사용자 식별 가능한 유일한 수단은 쿠키 뿐이었다.
그러다가 HTML5 표준화 이후, 다양한 스토리지 방식(Local Storage 등)을 통해 임의의 키를 사용자에 주입해 특정 사용자를 식별하는 행위가 가능했다.
하지만 이들 방식은, 브라우저 캐시만 날려도 날아가는 등 아주 손쉽게 사용자 흔적을 없애버릴 수 없고,
요즘 부라우저들은 호락호락하지 않아서 보안 이슈가 컸던 제3자쿠키에 대해 엄격해지기 시작했다.

HTML5 가 실험적 단계였을 2012년부터, 이를 보완하여 사용자 식별에 유용해 왠만한 사이트에서 성행하기 시작한 2가지 몇 가지 사용자 식별 방법이 생겨났다.

Canvas Fingerprinting

캔버스 지문채취. <canvas> 태그에 임의의 폰트 문자를 렌더링 시켜 거기서 나오는 hash 값을 통해 사용자를 식별하는 방법이다.
구현하는 게 생각보다 쉽고, 무엇보다도 “시크릿 모드”에서도 같은 식별 코드가 렌더링 되어 광고 뿐 만 아니라 여러 기업에서 지금도 질리게 써먹는 기술이다.
심지어 KT는 공유기 사용자를 식별하기 위해 이 방법을 쓴다고 한다… 와우. 징한 놈들…

이 기술은 2012년 5월 샌디애고 캘리포니아 대학의 한 교수가 발견한 기술이다. Pixel Perfect: Fingerprinting Canvas in HTML5
이게 2년 뒤에 엄청난 화제를 불러 일으켰다.The Web never forgets: Persistent tracking mechanisms in the wild
생각보다 꽤 오래 전에 발견한 기술이었고, 한국 또한 화제거리로 떠오를 때 한 개발자 블로그에서 발췌했다. Canvas fingerprinting – 쿠키 없이 사용자 추적
이 방식은 꽤 높은 유일 해시가 나와 화제를 불러일으키기도 했다. 100%까지는 아니지만 무려 95%라는 엄청난 유일성을 지니고 있다.
더 무서운 점은 소셜공유 위젯 사이트 addthis.com이 화제 일으키기 전에 몰래 사용해왔다는 것이다.

또한가지, 같은 렌더링을 구현해도 같은 값이 나와서 쿠키가 굳이 필요가 없을 정도. (에이전트, IP와 같이 서버로 보내면 땡이니까.)

당연히 개인정보 문제가 발생 안할래야 안할 수 없었고, 결국 이를 방지하는 브라우저 플러그인이나, Firefox에서는 자체적으로 막을 수 있는 옵션을 제공하기까지 했다.
막는 원리 또한 간단하다. Canvas API 호출 시마다 임의의 노이즈를 생성시켜 해시 값이 다르게 나오게 하는 간단한 원리다. 요즘은 왠만한 애드블록 확장에서도 지원하기도 한다.

AudioContext Fingerprinting

예전에 내가 잠시 작곡놀이를 재미지게 했던 때가 생각났다. 그 와중에 브라우저에서 HTML5 기본 오디오 API는 나를 흥분의 도가니로 넣게 했다.
바로 순수 웹으로 드럼머신이나 신디사이저를 만들 수 있다는 것. 하지만 데스크탑 한정이고, 완벽하지도 않다.
그러나… 역시 브라우저에서 창조 가능하면 죄다 지문 채취가 가능한 것인가…

AudioContext Fingerprint Test Page

이 페이지는 캔버스 지문 방식으로 화제가 된 1년 뒤에 나온 페이지다. 최초 발견 또한 비슷한 시기이지만 크게 화제가 되지는 못했다.
왜냐면 발견 당시에도 그렇고 지금도 이걸 쓸 만한 매리트가 없기 때문이다. 캔버스보다 느리고, 데스크탑만 몇몇 브라우저에서 지원한다.
원리는 캔버스 방식과 비슷하다. 파장을 생성하고, 압축(Compress)한다. 파장만 생성하면 일정하기 때문에 압축하는 과정도 거친다. 거기서 유일한 파장이 나온다고 한다.
재밌게도 폰트 채취는 덤. IE를 위해 플래시가 활성화된 경우 플래시를 이용하는 위엄까지 보여준다.

All in one: FingerprintJS2

이젠 살다살다 저걸 화제로 불러일으킨 팀이 이걸 오픈소스로 공개하고 팔 생각까지도 했다.
파는 것까진 아니지만 이 기술은 중국에서 존나게 좋아하고 존나게 즐겨쓴다고 한다…

Valve/fingerprintjs2

이 라이브러리에서는 아래와 같은 식별자 정보를 제공한다.

  • 에이전트 (브라우저 및 OS 등)
  • 언어
  • 색상 깊이
  • 해상도
  • 시간대(Timezone)
  • 세션 스토리지 여부
  • 로컬 스토리지 여부
  • 인덱스DB 여부
  • AddBehavior 탑재된 IE 여부
  • open DB 여부
  • 플랫폼
  • DoNotTrack 활성화 여부
  • 설치된 글꼴 (플래시,JS,CSS 사용)
  • 캔버스 지문
  • WebGL 지문
  • 플러그인 (IE 포함)
  • Adblock 설치 여부
  • 언어 변조 여부 (예를 들어 한국어 플랫폼에 일본어 사용)
  • 해상도 변조 여부 (음?)
  • OS 변조 여부 (예: 에이전트 바꾸는 플러그인 등)
  • 브라우저 변조 여부 (위와 동일)
  • 터치 스크린 감지 및 지원
  • 픽셀 감도 (화면 비율, 예: 16:9)
  • 에이전트를 통한 논리 프로세서 개수 추측
  • 장치 메모리 (이건 시발 W3C에서 공식 지원)

그리고 이 개새끼들은 아래 기능도 지원할 예정이라 한다.

  • 멀티 모니터 감지
  • HashTable 지원 여부
  • WebRTC 지문
  • 수학 상수
  • 접근성 지문(…)
  • 카메라 정보
  • DRM 지원 여부
  • 가속도 지원 여부
  • 가상 키보드
  • 제스쳐 지원(터치 스크린 한정)
  • 픽셀 밀도 (레티나나 고밀도 디스플레이 감지)
  • 비디오 및 오디오 코덱 지원
  • 오디오 지문

아 시발 그냥 나도 쓰는게 낫겠다 어자피 불법도 아니고 사용자 식별은 하긴 해야 하니 시발…
끗… 근데 나 지금 백엔드 프로젝트 투입중이라 업무상 만질 일은 일단 없다.

composite / 2018년 6월 8일 / Piss Development / 0 Comments

태그에는

다들 HTML 배우면서 가장 간단하면서 많이 지키는 사항이 있다. 물론 맞는 말이다. 표준이기 때문에.

  • inline 요소 안에는 block 요소를 자식으로 가질 수 없다.
  • block 요소 안에는 inline 및 block 요소가 모두 허용된다.
  • 단, p 요소 안에는 inline 요소만 허용된다.
  • inline 요소 안에는 inline 요소만 허용된다.

근데 나모 웹에디터 때문에 <p> 요소에다가 <div> 넣는 등의 표준을 위반하는 사례가 있다. 그리고 IE 기반 위지윅 에디터가 그리한데, designMode 기능이 기본 문단 태그를 <p> 로 지정했기 때문이다. 그래서 초창기 위지윅 에디터가 상당히 말이 많았고, 그리고 이에 대한 문제를 고치느라 고생하던 시절이 있었다.

하지만 지금은 많은 위지윅 에디터가 문단 태그를 <div> 로 강제하였기 때문에 더이상 HTML 표준 위반 및 XHTML 표준 전선 이상 무!

자. 잡담은 끝내고 이제 본론으로 들어가보자. HTML 표준에는 일단 문장(inline) 요소에는 문단(block) 요소를 넣을 수 없게 되어 있다. 따라서 원래 <a> 태그에 <div> 태그같은 게 들어갈 수 없는게 정설이다.

하지만 HTML5 부터는 얘기가 달라졌다.

마치 p 태그가 인라인 요소만 허용한다는 예외 처럼, a 태그에도 예외가 생겼다.



두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구



그러하다.
HTML5 에서는 <a> 태그 안에 아무 태그나 넣을 수 있게 되었다.
이 때문에, 플랫 디자인 다음이 뜬금없는 카드 디자인 패턴이 나온 것이다.
예제 코드를 보자.
<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>
이렇게 생겼다.
하나의 글 영역 안에 모든 것들을 링크 걸고, 그 안에 제목과 요약 내용, 그리고 read more 라고 링크를 부추기는 글을 넣는다.
이렇게 하면 장점이 뭐냐?
웹 접근성이 향상된다. 모바일이나 특수 컴퓨터 (시력장애인 등을 위한) 에서 링크 클릭에 대한 접근성이 향상된다.
또한 이런 접근성으로 인해 스크립트 의존성이 떨어지며, 원하는 문서를 손쉽게 이동할 수 있는 장점이 생긴다.
바로 접근성을 고려해서 W3C가 이렇게 HTML5 표준과 함께 내놓은 거다.
여담으로, XHTML2 에서는 모든 요소에 href 를 넣을 것을 고려했다고 한다. 바로 이런 접근성에 용이하기 위해.
하지만 알다시피 XHTML2 는 완전히 새로운 표준을 지향했고, 하위 호환성이 철저히 무시한 덕분에 많은 웹 관련 개발자와 디자이너, 연구진들이 반발했고, 그리고 무산된 표준이 바로 XHTML2 였다.
만약 XHTML2 표준으로 웹 페이지를 만들었고, 브라우저가 그걸 지원하려면 정말 엄청 머리 아팠을 것 같지 않은가?
왜냐하면 바로 하위 호환성이 사라지기 때문에, 엔진을 2개 만들어야 하는 꼴이 되니까. 당연히 달갑지 않았던 거다.
지금은 HTML5 에서는 이 표준이 아직 하위 호환성이 적잖아 문제가 있다. 모든 브라우저가 이 표준을 지원한다. 쿼크 모드에 대한 호환성 때문인데, 이 기능이 지원된 게 다행이라 생각하지 않는가? 만약 <div> 가 <a> 로 감쌌다고 지우면, 이건 정말 골치아플 수도 있다.
하지만 아직까지 현재 브라우저에 한계가 있는데,
비록 <a> 태그 안에 모든 태그가 지원된다 해도, 현재 표준에 의한 예외 사항이 있는데, 바로 테이블이다.
테이블 태그 안에 비표준 태그들을 싸그리 지우도록 엔진이 설계한 덕분에, <a> 태그를 <tr> 안에 넣지 못하는 사태가 일어난다.
이에 대응할 지는 아직 지켜봐야 할 단계지만, 이를 지원한다면, 웹 접근성 향상에 어느정도 기여할 것으로 기대된다.
자. 이제 찬양하라. HTML5를!
자세한 링크는 HTML5 에서 신뢰성 있는 정보를 제공하는 HTML5닥터 에서 보도록 한다.

composite / 2014년 2월 18일 / 미분류 / 0 Comments

composite / 2013년 12월 17일 / 미분류 / 0 Comments

비즈니스에서 node-webkit 에 관심가져야 하는 5가지 이유!

자바개발자던 닷넷개발자던 어자피 웹개발자라면 자바스크립트 쓸 줄은 아니 딴소리 마시고 읽어보고 판단하시길.

https://github.com/rogerwang/node-webkit

node-webkit 가 한국에서 점점 많이 알려진 점에 대해 기쁘게 생각한다.

프로젝트에도 쓰고 있고, 게다가 이미 공식 페이지에서 입증된 기술이다.

게다가 구글의 크롬 엔진이다. 크롬 엔진은 이미 웹에 앞서나간다는 업체라면 익히 알고 연구하거나 개발할 것이다.

그렇다면 무슨 말이 필요있겠는가? 이제 그런 강점에 촉진제를 넣어주도록 하겠다.

  1. 웹개발은 그대로 하면 된다.

기존 웹개발자가 갑자기 데스크탑 앱 만들라고 하면 시발 이게 무슨 소리여 할 것이다.

하지만 node-webkit 는 그딴거 신경쓸 필요 없다. 기존대로 웹개발만 하면 된다.

현재 개발자 중에 가장 많이 차지하는 게 웹개발자고, 그담 모바일앱 개발자다. 응용은 수가 적다. 물론 그만큼 희소가치가 있겠지만 웹이 더 싸게 먹히는게 웃지못할 정석이다.

node.js 개발이 별도로 필요하다고? 아니다. node.js 에서 그냥 님 웹페이지 띄울 수만 있으면 된다.

그 이상 신경 안써도 된다. 고급 기술을 채용하고 싶다면 그냥 node.js 개발자 뽑으면 된다. 아니면 님이 배우던가.

  1. 배포가 쉽다.

node-webkit 는 배포가 졸랭 쉽다. 소스 파일을 zip 압축해서 nw 로 바꿔 nw.exe 에 배치파일 걸어 실행해도 되고, love2d 처럼 nw.exe 내장시켜 단일 응용 프로그램으로도 배포 가능하다. 전혀 어려울 것 없다.

근데 그러면 어자피 소스가 다 까일텐데 걱정이 태산일 것이다. 웹 프로젝트 할건데 node-webkit 에다가 뭘 집어넣게?

굳이 해야 한다면 암호화/복호화 API 지원되니 그걸 쓰덩가. 데스크탑에 수행해야 하는 게 없지 않는 이상 크롬에 지원되는것들 다 지원되므로 걱정 붙들어 매기 바란다.

알리미 API? 그건 조금 아쉽긴 하지만 크롬처럼은 아직 지원이 어렵고 대신 구현은 가능하다. 링크 누르고 보고 따라하면 된다.

그정도면 비즈니스 앱 만드는데 불만은 없을 것이다. 이제 직원들에게 파일 하나만 딸랑 배포만 하면 되니까.

데스크탑에서 탭이라던가 그런것들 구현하고 싶다면 그냥 웹 그대로 하라. node-webkit 에서 해야할 일은 웹 페이지를 띄우는 것 뿐이다.

자동 업데이트? 님 응용 만드삼? 웹이잖아 웹. 웹 업뎃하면 그게 자동 업뎃이지 뭐야?

  1. 크로스 브라우징이 필요없다.

존나 고생하는거 안다. 시발 IE 조까튼 개새끼인거 안다. 이제 해방하라. 크롬 위주의 코딩을 해도 웹표준 그대로 따라간다.

W3C 에서 신기술 제의하는 대표적 기업이 구글, 모질라는 비영리단체고, 마소 등의 브라우저 만드는 기업이 포함되어 있으며, 표준안을 제시하며 그걸 그대로 따라간다. 따라서 카나리같은 개발자 전용 기능을 쓰지 않는 이상 HTML5/CSS3/Javascript 1.7 이상 표준 그대로 따라가도 된다. 쫄지마.

당신이 크롬 위주로 코딩한 95% 이상은 불여우와 IE 11 에서도 돌아가니 쫄지말고 코딩하라.

  1. 비즈니스 보안성이 향상된다.

비록 크롬 내장형 엔진이지만, 더이상 외부에 노출할 염려는 하지 말자. 물론 사내IP만 필터링 하면 되겠지만, 외부직원의 업무는 SSLVPN도 있고 하고. 하지만 문제는 아무래도 보안이다.

그런 면에서 액티브엑스 달린 웹은 보안성과 성능을 둘 다 씹고 똥컴 만드는 주범이다.

만약 보안성에 신경써야 한다면, 웹개발자는 웹에만 신경쓰게 냅두고, node.js 관련 보안 개발자를 통해 보안 모듈을 이식할 수 있다. 브라우저에 UUID 개념을 만들고 관리하여 인가된 사용자만 허용하게 할 수 있으며, 브라우저 헤더에 쳐넣을 수 있다. 아까도 말했듯이 암/복호화 API 제공하니 그거 써도 되고, 자체 보안 기술 가지고 있으면 C++ 확장 만들 수 있다.

사슬 edge.js 를 통해 .NET 코드도 돌릴 수 있긴 한데 문제는 .NET 4.5 이상이 요구되고 (윈도우 8 이상은 기본설치됨)

자바의 경우 node-java 가 있긴 한데 edge.js 에 비해 안정성 보장이 불확실한 점이 있다.

그러므로 응용 -> 웹 으로 이동하는건 문제가 아닌데 보안땜에 엑티브엑스 써야한다면 액티브엑스 개발자에게 node.js 모듈을 제안하던가 아니면 웹 보안에 맡기는 게 좋을 수 있다.

하지만 한가지 확실항 점은 바로 사용자 컴퓨터는 제어할 수는 없지만 node-webkit 프로그램을 쉽게 제어할 수는 있다는 것이다.

컴퓨터까지 통제해야 한다면 그건 그 업체 보안사항에 의한 별개의 문제고, 이 프로그램 연동과 상관 없으므로 알아서 생각하도록 하라.

그래도 쌩판 브라우저에서 실행되는 것보다는 보안성이 좋다. 브라우저를 제어하는건 불가능하지만 이 node-webkit 제어하는건 가능하기 때문이다.

  1. 많은 업체와 프로젝트를 통해 입증되었다.

node-webkit 의 개발자는 CPU 만드는 인텔 계열사인 오픈소스 업체의 사람이다. 인텔이 설마 신경 안썼겠는가?

게다가 많은 프로젝트와 업체가 생겼다. 개발자가 중국인이라(대만인가?) 중국업체가 대거 끼어들긴 했지만.

직접 눈으로 보려면 https://github.com/rogerwang/node-webkit/wiki/List-of-apps-and-companies-using-node-webkit

응용처럼 실행되지만 이것들이 모두 웹으로 만들었다. 믿겨지겠는가?

웹처럼 개발하고 응용처럼 실행되는 이상적인 환경에 이미 많은 프로젝트를 통해 입증했다.

아 피곤해. 당장 도입하겠다는 생각보다는 아무래도 고민이 앞설 것이다.

하지만 크롬은 크롬 앱을 통해 데스크탑 앱 시장에 손을 대고 있고, 웹으로 개발하고 응용처럼 사용하는 시대가 바짝 다가온만큼 비즈니스에서도 기존처럼 IE밖에 모르는 응용처럼 만들고 웹처럼 쓰는 고비용 저효율 자태 그만 뽐내고 이런 새로운 시대에 대응하는데에 고민을 하고 초첨을 맞추기 바란다.

composite / 2013년 12월 9일 / 미분류 / 0 Comments

HTML5 망했어요,

물론 한국에만 해당됨.

왜냐?

정부 IT를 주릅잡는 애들이 바로 그냥 자바같은 하이레벨 개발자들이 주류. 자바나 C# 같은 언어 개발자들.

HTML 를 전문으로 연구하거나 개발한 인력? 없어. W3C 한국위원 빼면 시체.

작년에 정부가 HTML5 인재양성을 외쳤다. 3천명을 1달 속성으로.

지랄을 해라 아주.. HTML5 컨텐츠가 옛날 관리프로그램처럼 서버에만 맡기면 다인줄 아는

HTML 자체에 대해서 모르는 것들이 외치는 것들.

거기다가 저건 그냥 단가 싸구려인 개발자 양성에만 힘을 쏟겠다는 발전이 전혀 없는 개소리다.

일단 기사를 보자. http://www.zdnet.co.kr/news/news_view.asp?artice_id=20121121093337

기사냈을 당시에는 네이티브가 없어도 다된다고 했다. 뭐 물론 기대감은 크겠지만 사실 개소리다.

아무리 표준이 완성되도 웹은 한계가 있기 마련이다. 이걸 깨기 위해 제작년부터

모질라와 구글 각각 웹에 네이티브 기술을 임베디드하는 기술을 개발하고 있다.

물론 액티브엑스처럼 컴퓨터 리소스를 이용해여 성능을 극대화하고 웹의 한계를 뛰어넘지만,

개인정보 보호를 위하여 파일 직접 접근이 불가능한 안전장치. 즉, 샌드박스 내에서 돌아가는 네이티브 앱.

기존 액티브엑스와 자바 애플릿의 장점을 살리고 단점을 버린 브라우저 내의 네이티브 기술을 이용하는 것.

내년 되봐라. 브라우저는 곧 플랫폼이 된다. 마치 게임의 플랫폼 스팀처럼. (여담이지만 팀포2 재미쪙.)

이런 동향을 아는 사람은 과연 몇이나 될까. 특히 정부나 업계 관리 프로그램에 몸담고 있는 웹 개발자들 말이다.

아마 적을 것이다. 직접 관심을 가지지 않는 이상. 돈과 시간에 쫒기기만 하면 당신은 도태된다.

지금 HTML5 동향은 마냥 HTML에 없었던 기술을 추가하는 데에 그치는게 아니다.

웹을 플랫폼으로 만들기 위한 조용하면서도 위험한 전쟁에 당신은 휘말리고 있다는 것이다.

당신이 조용히 크롬이나 파이어폭스, IE를 쓰고 있지만, 그걸 만든 업체나 재단은 소리없는 전쟁을 치르고 있다는 것이다.

이 동향을 국가에서 알지 못하고 대응하지 못하면, 여태까지 웹노가다 관리프로그램을 이제 HTML5 와 네이티브의 조합으로

더 빠르고 편리하고 예쁘게 구축할 수 있는 위력을 모르고 여전히 코드 ctrl+C ctrl+V 밖에 모르는

윈도우 XP에 IE6 으로 시간이 멈춘 웹 환경 구축과 인프라만이 당신을 반길 것이다.

정신차려라. 특히 개발자. W3C 한국 위원들이 HTML5 표준 재정에 힘쓰고 있을때, 그 동향에 참여하고 파악하고 발전하라!

composite / 2013년 4월 18일 / 미분류 / 0 Comments

IE 10 에 비상사태를 선포한다!

IE 9버전까지 먹혔던 !+”\v1″ 이게 IE 10에서는 false 로 나왔다.

또한 조건절 주석 (conditional comment) 가 안먹힌다고 한다. 아예.

(보고 링크 : http://phpschool.com/link/talkbox2/726643)

IE10 이 웹표준가 많이 가까워졌지만 조금 찝찝한 마음을 지울 수 없는데

IE 감지 스크립트가 안먹히니 이걸 우짜면 좋을까. 자신이 IE 인걸 포기한걸까 아니면.. 마소의 본격 웹표준을 선언한 것인가.

이것은 IE 따로 웹개발 한 웹개발자에게는 조금 당혹스런 문제가 아닐 수가 없다.

IE10 은 데스크탑에 한해 아직도 ActiveX 가 먹히는데..

이제 브라우저 판별법은 결국 navigator 객체에 맡기는 수밖에 없는 상황이 되고 말았다.

IE 따로 고생하는 개발자 여러분들은 참고하도록.

composite / 2013년 2월 28일 / 미분류 / 0 Comments

형왔다 받아라 – Windows Internet Explorer 10

님컴이 윈도우 7 또는 2008 R2인가?

익스 9가 아직도 부족한 감이 있는가

HTML5 를 갈망하고 있는가?

마소 스타일의 HTML5 표준을 지향하는 여기 익스 10을 이제 윈도 7에서 볼 수 있다.

얼렁 http://windows.microsoft.com/en-us/internet-explorer/downloads/ie-10/worldwide-languages 가서

한국어로 스크롤하고 자신에 맞는 운영체제 선택하고 다운받으면 끝!

브라우저 자동 업데이트 지원 여부는 모름. 내껀 윈도8이라 당연하겠지만.

composite / 2013년 2월 27일 / 미분류 / 0 Comments

[HTML] submit 도 폼양식이다.

웹개발하면서 폼 전송할 때 버튼이야 다들 아시죠?

아마 이렇게들 쓰실 겁니다.

<input type=”submit” value=”저장”>

<input type=”image” src=”이미지경로” alt=”저장”>

<button type=”submit”>저장</button>

여러분은 이 submit 과 image도 양식으로 서버에 전송된다는 점은 알고 계셨습니까?

이녀석도 폼 전송시 서버에 키와 값이 전송됩니다.

그렇다면 어떤 시점에 키와 값이 전송됩니까?

바로 “submit 버튼을 누른 해당 버튼의 name 과 value” 가 서버로 전송됩니다.

간단하게 예를 들어보겠습니다.

<form action=”” method=”GET”>

    <input type=”submit” name=”goto” value=”가라!”>

</form>

이걸로 HTML 작성하고 띄워보시면 가라 라는 버튼이 보일겁니다. 누르세요.

그럼 html?goto=가라 라고 주소가 변할 겁니다.

좀 더 이해가기 쉽게 코딩해봅시다.

<form action=”” method=”GET”>

    <input type=”submit” value=”날 눌러봐”>

    <input type=”submit” name=”goto” value=”나도 눌러줘”>

</form>

각각의 submit 버튼을 누르면, 날 눌러봐를 클릭했을 경우 전송 결과는 그냥 ? 만 나오고 말 것입니다.

하지만 두번째 버튼을 누르면 goto=나도 눌러줘 라는 내용이 URL에 출력됩니다.

이제 감이 잡히셨습니까?

submit도 폼 양식이란 거.

그렇다면, input type=’submit’ 과 input type=’image’ 와, button type=’submit’ 이 셋다 submit 버튼인데

차이점이 뭐냐? 오늘 이 셋의 특징을 나열하겠습니다.

<form action=”” method=”GET”>

    <input type=”submit” name=”submit1″ value=”전송하기”>

    <input type=”image” name=”submit2″ src=”이미지경로” alt=”전송이라도 해보기”>

    <button type=”submit” name=”submit3″ value=”전송해봐”>전송하랑께</button>

</form>

input type=’submit’ 은 가장 단순한 전송 버튼입니다. name이 키면 value 는 값 겸 버튼 내용이 되겠습니다.

어떤 버튼을 눌렀는지는 알겠지만 따로 값을 전송하기엔 불편함이 있겠죠.

input type=’image’ 는 이미지 전송 버튼입니다. name 이 키지만 value는 무시됩니다. 그럼 어떤 값이 보내지나?

바로 이미지를 누른 좌표입니다. name.x=0&name.y=0 이런 식으로 뜰 것입니다.

코딩하다보면 쓸데없이 name 속성값 점 x 와 y 키가 나오는데, 원래 그렇게 나온다는 뜻이 되겠습니다.

button type=”submit” 은 좀 더 다양한 스타일을 줄 수 있는 전송 버튼입니다. input
type=’submit’ 과 달리 하위 요소에 인라인 요소가 허용되기 때문에 일부 글씨를 굵게 하거나, 색상을 입히거나, 이미지를 넣을 수 있습니다. 벨류값과 내용을 따로
넣을 수 있기 때문에 폼전송 구분을 할 경우 이 태그가 유용할 것입니다.

이런 submit 폼의 성질을 가장 잘 이용한 사례가 바로 ASP.NET Webform 입니다.

postback 방식으로 어떤 버튼을 누르냐에 따라 다시 현재 페이지로 되돌아오기 전 해당 버튼을 눌렀을 때 서버에서 대응을 하는 식으로 설계되어 비즈니스 CRUD 프로그램 개발에 각광을 받았죠.

어쨌든 이 submit. 폼전송 용도로만 쓰신 분에게 지금은 어쩌면 사용 용도에 따라 감이 잘 오기 힘들겠지만

이것도 폼 전송 요소로 유용하게 쓰일 날이 올 것입니다.

composite / 2013년 1월 9일 / 미분류 / 0 Comments

HTML5 CSS3 튜토리얼 – 리본 형식의 헤더 만들기.

레노버 영문 사이트를 보시면 NEWS AND ALERTS 부분이 있습니다.

여기 보시면 입체감 있는 빨간 리본이 있을겁니다.

오늘은 이런 리본 헤더 부분을 이미지 없이 순수 HTML/CSS로 만들어 보겠습니다.

먼저 렌더링 결과를 보시겠습니다.

레노버 디자인보다 못하지만 목표대로 나왔습니다.

이제 어떻게 만드는지 마크업부터 보시겠습니다.

<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>DJ Defense</title>
</head>
<body>
  <div class=”aside”>
    <h1>Welcome Menu</h1>
    <div class=”ribbon”>DJ Defense</div>
    <ul>
      <li><a href=”#”>Menu 1</a></li>
      <li><a href=”#”>Menu 2</a></li>
      <li><a href=”#”>Menu 3</a></li>
      <li><a href=”#”>Menu 4</a></li>
      <li><a href=”#”>Menu 5</a></li>
    </ul>
    <div class=”ribbon”>By Composite</div>
    <ul>
      <li><a href=”#”>Menu 6</a></li>
      <li><a href=”#”>Menu 7</a></li>
      <li><a href=”#”>Menu 8</a></li>
      <li><a href=”#”>Menu 9</a></li>
      <li><a href=”#”>Menu 0</a></li>
    </ul>
  </div>
</body>
</html>

배경이 어두워서 일부러 밝은색을 사용했습니다. 글쓸때 너무 힘듭니다..ㅋㅋ

여기서 주목하실 부분은 바로 빨간 부분입니다. div 태그가 딸랑 하나 있습니다.

그 외에는 아무것도 없습니다. 그럼 어떻게 합니까?

바로 CSS 되겠습니다.

CSS2 표준에 재정이되어 있는 가상 컨텐츠 영역인 :before 와 :after 가 있습니다.

이 두녀석이 있으면 가상까지 합해 총 3개의 요소로 갖고 놀 수 있습니다.

여기서 :before 는 그림자를, :after 는 리본 입체 역할을 담당했습니다.

먼저 소스를 보여드리겠습니다.

.aside{background-color:#ccc;margin-left:2em;font:bold 1.5em verdana;width:480px;float:right;}
.ribbon{
  background:darkred;color:white;
  position:relative;z-index:0;margin-left:-1em;margin-top:1em;
  padding-left:1em;
  text-transform:uppercase;
  -moz-box-sizing: border-box;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
}
.ribbon:after{
  display:block;z-index:-2;
  border-top:0;
  border-bottom:.75em solid transparent;
  border-left:1em solid transparent;
  border-right:1em solid darkred;

  content:”;position:absolute;margin-left:-2em;
}
.ribbon:before{
  display:block;content:’ ’;position:absolute;z-index:-1;
  width:100%;
  -webkit-box-shadow: 0px 5px 5px rgba(50, 50, 50, .75);
  -moz-box-shadow:    0px 5px 5px rgba(50, 50, 50, .75);
  box-shadow:         0px 5px 5px rgba(50, 50, 50, .75);

  -moz-box-sizing: border-box;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
  margin-left:-1em;
}

먼저 리본 헤더의 기본 스타일은 겹치는 부분을 제외한 기본적인 스타일을 입히시면 됩니다.

이때 중요한 거는 리본이 앞으로 나와서 겹쳐야 하기 때문에 왼쪽 여백을 오히려 바깥으로 나가게끔 하는 것이 포인트!

그런 다음에 안쪽 여백을 통해 다시 돌려주면은 원래대로 돌아간 것처럼 실행할 수 있습니다.

중요한 거는 상대 위치로 지정하고 z-index를 지정해야 합니다. 그래야 하위 가상 요소의 표시 순서를 잡을 수 있습니다.

그리고 리본 겹치는 부분입니다. 리본 겹치는 부분은 after 로 줬습니다.

왼쪽 위에서 아래로 대각선으로 쭈욱 이어지는 삼각형 만들기의 비법은 바로 테두리 에 있습니다.

테두리로 삼각형 만드는 비법에 자세한 설명은 링크를 참조하시면 되겠습니다. firejune 님이 가장 잘 설명해 주셨더군요.

http://firejune.com/1533

리본 삼각형을 잡도록 위쪽 테두리를 없애고, 옆테두리에 100%를 부여할 경우 아래 테두리를 75% 정도로 크기를 부여했습니다.

그리고 왼쪽 및 아래쪽 테두리를 투명 표시 해서 오른쪽 테두리를 표시하게 하면 리본에 나오는 삼각형 만들기는 끝입니다.

그리고 절대 위치를 지정해서 표시 순서를 잡습니다. 위치는 지정하실 필요 없고 여백 조정을 통하여 상대 위치를 지정해 주면 됩니다.

여기서는 부모 여백의 2배 값으로 설정했습니다. 즉, 부모의 밖으로 빼낸 마진의 절대값+안쪽 여백값이 되겠습니다.

중요한 것은, content 속성을 부여해야 합니다. 또한 비어 있어야 합니다. 그래야 테두리가 표시되기 때문입니다.

마지막으로 그림자 부분입니다. 그림자는 CSS3 box-shadow 속성을 사용했습니다.

그리고 절대 위치로 잡은 뒤 여백은 부모와 똑같이 겹치도록 한 다음 표시 순서를 뒤로 잡습니다.

표시 순서는 부모>before>after 순으로 잡도록 설정해 주시면 되겠습니다.

이제 중요한 것은 content 속성을 부여해야 하는데, 빈 문자를 줘야 합니다. 스페이스바 공백은 안먹힙니다.

그래서 한글 ㄱ->한자->1번 문자를 통하여 공백을 표시했습니다. &nbsp;도 안먹히니 조금 슬프지만 이렇게라도 했습니다.

안그러면 그림자 표시가 안됩니다.

이렇게 하시면 완성입니다. 어때요. 참 쉽죠?

적용 예제 링크를 보여드리며 이번 강좌를 쿨하게 마치도록 하겠습니다.

<

p style=”text-align: left; clear: none; float: none;”>http://jsbin.com/usawah/2

composite / 2012년 12월 5일 / 미분류 / 0 Comments