인터넷을 형성한 HTML 해킹 기술

 (tedium.co)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 초기 웹 개발자들은 브라우저마다 표준 구현과 결함이 달라, 유효한 HTML/CSS만으로 원하는 레이아웃과 동작을 안정적으로 보장하기 어려웠음
  • Netscape 4, Internet Explorer 5/6/7, Safari/WebKit, Outlook 같은 환경은 CSS, PNG 투명도, 주석, 선택자, 이메일 미리보기에서 브라우저별 우회 코드를 낳았음
  • HTML 테이블 레이아웃, sIFR, Chrome Frame, 반응형 디자인은 원래 의도와 다른 조합으로 디자인 제약과 구형 브라우저 문제를 넘어서려 한 사례임
  • 이런 해킹은 접근성 저하, 비표준 코드, Flash·플러그인 의존 같은 한계를 가졌지만, 당시에는 호환성과 시각적 표현을 확보하는 현실적 수단이었음
  • 웹 표준의 이상과 실제 사용 방식은 계속 충돌했고, 개발자와 디자이너의 반복적인 우회가 웹 디자인, 이메일 HTML, 모바일 대응 방식에 오래 남음

브라우저 결함을 피해 가던 CSS 해킹

  • Netscape Navigator 4.0의 @import 해킹은 Netscape가 지원하지 못하는 CSS를 일부러 @import로 불러와, 해당 브라우저가 고급 스타일을 적용하지 못하게 막는 방식이었음
    • 기본 CSS는 <link>로 불러오고, 더 발전된 CSS는 @import로 분리해 불러오는 구조였음
    • CSS Cookbook은 이 방식이 Netscape에서 작동하지 않는 CSS 파일을 함께 로드하는 효과를 냈다고 정리함
    • Netscape는 CSS 대신 JSSS를 밀었고, W3C가 CSS를 선택한 뒤 1997년 여름 Netscape 4에 CSS를 급히 구현함
    • Netscape 4에서는 JavaScript를 끄면 CSS도 꺼지는 부작용이 있었음
  • Internet Explorer 6 대상 CSS 해킹은 _width처럼 속성 앞에 밑줄을 붙여 IE6만 해당 선언을 해석하게 만드는 방식이었음
    • W3C의 박스 모델은 width가 border와 padding을 제외한다고 봤지만, Internet Explorer는 padding과 border를 다르게 처리해 브라우저 간 레이아웃 차이를 만들었음
    • 예시는 width: 300px; _width: 320px; padding: 10px;처럼 표준 CSS로는 유효하지 않은 선언을 IE6용 보정값으로 쓰는 형태였음
    • !important 뒤에 느낌표를 하나 더 붙여 IE7 이하에만 다르게 동작하게 하는 식의 IE 전용 해킹도 있었음

레이아웃을 위해 의미 구조를 비틀다

  • HTML 테이블 레이아웃은 원래 표 형식 데이터를 표현하기 위한 <table>을 시각적 페이지 배치 도구로 사용한 대표적 해킹이었음
    • David Siegel은 전통적인 디자이너의 시각으로 웹에 접근했고, HTML의 시각적 결과를 브라우저가 결정한다는 관례를 거슬러 더 보기 좋은 웹사이트를 만들려 했음
    • Creating Killer Web Sites에서 그는 구조적 마크업을 우회하고, 이미지를 이용해 2차원 배치를 만들고, 테이블이 등장하자 열에 텍스트를 넣는 방식을 다룸
    • The History of the Web의 Jay Hoffman은 HTML/XML 순수주의자들이 디자인과 코드 구조의 혼합을 큰 금기로 봤다고 정리함
    • 테이블 레이아웃은 접근성을 망가뜨렸고 이를 복구하는 데 시간이 걸렸지만, 개발자가 웹 포털을 시각적으로 구성할 수 있다는 가치를 보여줌
  • 반응형 디자인은 테이블 레이아웃처럼 기존 기술을 새 방식으로 조합했지만, 웹 표준의 범위 안에서 화면 크기에 맞춰 레이아웃을 바꾸는 방법이었음
    • 2000년대 웹 디자인에서는 3개 열이 페이지 하단까지 이어지는 “Holy Grail layout”을 CSS로 구현하는 문제가 큰 논쟁거리였음
    • 배경 이미지로 가짜 열을 만드는 등 여러 우회가 있었고, 이후 CSS는 그리드 기반 레이아웃을 지원하게 됨
    • 스마트폰이 보급되면서 기존 3열 레이아웃의 의미가 약해졌고, 별도 모바일 웹사이트에 돈을 써야 하는 상황이 생겼음
    • Ethan Marcotte는 A List Apart의 responsive web design 글에서 미디어 쿼리를 사용해 웹사이트 배치를 화면 형식에 맞추는 방식을 제시함
    • 반응형 디자인은 당시에는 생소한 미디어 쿼리를 활용한 해킹처럼 보였지만, 웹 디자인을 장기적으로 바꿨음

Internet Explorer 시대의 이미지와 주석 우회

  • AlphaImageLoader는 Internet Explorer 5와 6이 PNG 투명도를 제대로 지원하지 못하는 문제를 Microsoft 전용 필터로 우회했음
    • Internet Explorer는 버전 4부터 PNG를 지원했지만 여러 경우에서 제대로 렌더링하지 못했고, 특히 IE5/IE6의 투명 PNG 미지원이 큰 문제였음
    • Perishable Press의 Jeff Starr는 PNG fix for Internet Explorer에서 당시 해결책들이 Microsoft의 전용 AlphaImageLoader 투명도 필터를 요구했다고 다룸
    • 예시는 IE에는 filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)를 적용하고, 비 IE 브라우저에는 [class] 선택자로 일반 배경 이미지를 적용하는 방식이었음
    • 이런 작은 기능 공백은 2000년대 후반과 2010년대 초반 개발자가 브라우저별 해킹을 계속 고려하게 만들었음
  • 조건부 주석(Conditional Comments)은 Microsoft가 IE 버전별로 특정 HTML을 렌더링할지 결정하도록 만든 HTML 주석 확장이었음
    • Internet Explorer가 웹사이트 구현에 너무 많은 해킹을 요구하자, Microsoft는 그 해킹들을 관리하기 위한 또 다른 해킹을 도입함
    • 원래 실행용이 아닌 HTML 주석이 IE 버전 조건에 따라 동작하는 구조로 바뀜
    • Internet Explorer 5에서 처음 도입됐고, Windows용 Microsoft Outlook의 복잡한 이메일 디자인에는 여전히 필요한 경우가 있음
    • Jens Oliver Meiert는 2007년 글에서 조건부 주석이 IE 버전 대응 시 각 문서나 템플릿의 HTML을 다시 조정하게 만들어 구조와 표현의 분리를 해친다고 비판함
    • 조건부 주석은 IE9 이후 제거됐고, JavaScript의 conditional compilation이 대체 수단으로 쓰일 수 있었음

글꼴, 이메일, 구형 브라우저를 위한 비표준 조합

  • sIFR(Scalable Inman Flash Replacement)은 웹 안전 글꼴에 묶이지 않고 원하는 글꼴을 표시하기 위해 텍스트를 Flash 임베드로 바꾸는 JavaScript 기반 해킹이었음
    • Microsoft의 Core Fonts for the Web은 제한된 웹 안전 글꼴 사용을 사실상 권장했고, 이후 중단됐음
    • 초기 글꼴 대체 기법은 이미지 사용에서 출발했지만 접근성과 표현 한계가 있었음
    • Shaun Inman은 원하는 글꼴을 작은 Adobe Flash 파일로 대체하는 아이디어를 냈고, Mike Davidson은 sIFR을 통해 글꼴이 필요에 따라 확장되도록 만들었음
    • Davidson은 2004년 sIFR 공개 글에서 사용자가 설치하지 않은 커스텀 서체를 전달하는 문제가 아직 해결되지 않았다고 봄
    • sIFR은 실제 웹 글꼴 해법으로 가는 중간 단계였고, Flash가 모바일로 넘어가지 못하면서 오래 지속되지 않았음
  • 프리헤더 텍스트 해킹은 이메일 클라이언트의 미리보기 줄에 원치 않는 다음 본문 텍스트가 이어 붙는 것을 막기 위해 숨김 문자와 공백 문자를 넣는 방식임
    • 프리헤더는 이메일 수신함에서 제목 다음에 보이는 짧은 텍스트이며, 이메일의 부제처럼 작동함
    • 이메일 클라이언트가 HTML 태그나 관련 없는 본문을 미리보기로 끌어오는 경우가 있어, 의도한 프리헤더와 다음 텍스트 사이에 여백을 강제로 삽입함
    • Litmus가 추천한 예시는 display: none, max-height: 0px, overflow: hidden을 적용한 영역에 &#847;, &zwnj;, &nbsp;, &#8199;, &shy; 같은 문자를 반복해 넣는 형태였음
  • Google Chrome Frame은 Internet Explorer 안에서 Chrome 렌더링 엔진을 쓰게 해 IE6 의존 환경에서도 현대적 웹 기능을 사용할 수 있게 한 브라우저 플러그인이었음
    • 일부 기업은 강한 IT 부서와 IE6 기반 기술 의존 때문에 최신 브라우저로 옮기기 어려웠음
    • Google은 2009년에 Chrome Frame을 만들어 오래된 Internet Explorer에 현대적 엔진을 제공했고, 개발자가 여러 버전을 만들거나 새 기능을 포기하지 않도록 했음
    • Chrome Frame 은퇴 글에 따르면 당시 많은 사용자가 최신 기능에서 뒤처진 브라우저를 쓰고 있었음
    • Google Wave와 YouTube 같은 도구는 HTML5 기능을 필요로 했고, IE6 지원은 Google에 제약이었음
    • Chrome Frame은 5년 동안 시장에 있었고, 그 기간 이후 Chrome은 매우 지배적인 브라우저가 됐음

Safari/WebKit 전용 대응과 웹의 실제 진화

  • WebKit 전용 선택자 해킹은 @supports (-webkit-appearance:none) {}처럼 특정 브라우저 전용 CSS 지원 여부를 이용해 WebKit 계열 브라우저에만 CSS를 적용하는 방식임
    • Safari는 처음 나왔을 때 오픈소스 커뮤니티에 뿌리를 둔 엔진을 기반으로 했고, 초기에는 HTML/CSS 표준 지원이 강했음
    • Apple Mail은 WebKit을 사용해 이메일 코딩에서 대체로 잘 작동하는 환경으로 여겨졌음
    • 시간이 지나며 Safari 릴리스 일정이 Mac과 iOS 일정에 묶여 업계보다 늦어지는 문제가 생겼음
    • 개발자들은 Apple이 버그를 무시하거나 경쟁상 불리한 기능을 늦춘다고 비판했음
    • Reddit의 한 사용자는 Safari 개발 불만 글에서 API를 구현해도 버그가 많거나 나중에 망가진다고 썼음
    • 이 해킹은 WebKit 기반으로 시작한 초기 Chrome 버전에서도 작동했음
  • HTML의 의도와 실제 웹 사용 방식은 크게 달라졌고, 디자이너와 UI 전문가들은 이상한 코드에도 불구하고 인터넷 위에 시각적 표현을 구축했음
    • David Siegel의 설명처럼 표준화 단체는 HTML이 RSS처럼 최종 디자인보다 사용자와 구조를 중시하는 방식으로 작동하길 원했음
    • 같은 시기 등장한 Gopher 같은 프로토콜도 디자인 영향이 크지 않은 방식으로 작동했음
    • 그러나 인터넷 사용자의 창의성과 상업 인터넷의 시각 언어 의존 때문에 그 철학은 주류가 되지 못했음
    • 이메일 HTML에서는 표준 HTML/CSS로는 쉬운 투명 그라데이션 처리도 어렵고, 오래된 StackOverflow 댓글의 HTML 테이블 글리치 같은 우회가 여전히 해결책이 될 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 레이아웃에 표를 쓰는 건 꽤 이해할 만함
    하지만 표가 유행에서 밀려난 뒤 몇 년 동안은 레이아웃을 float로 짜는 게 전부였음. 그 시절이야말로 거칠었는데, 목록에서 빠진 게 의외임
    https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    “원래 텍스트 블록 안에서 이미지를 띄우기 위한 것이던 float 속성이 웹페이지의 다중 열 레이아웃을 만드는 데 가장 흔히 쓰이는 도구 중 하나가 됐다. flexbox와 grid가 등장하면서 이제는 원래 목적로 돌아갔다”

    • float가 처음 나왔을 무렵, 컴퓨터 수리 사이트를 FF에서 전부 개발했음
      마무리할 때쯤 IE에서 열어 보니 전체 디자인이 무너졌고, 타깃 고객은 거의 확실히 IE를 쓸 사람들이라 결국 표 기반으로 다시 작성해야 했음. 슬픈 날이었음
    • 애초에 표 기반 레이아웃을 해킹이라고 부르는 것부터 불쾌했음
      표가 밀려난 뒤 수많은 프런트엔드 팀이 “순수주의자”들의 신념을 지키려고 float 장난질에 누적 몇 달을 낭비하며 훨씬 덜 이해하기 쉬운 웹페이지를 만드는 걸 봤고, 거기서 중요한 교훈을 얻었음
      Joel Spolsky가 훌륭한 글에서 그런 개발자들을 Architecture Astronauts라고 불렀는데, 최소한의 노력으로 잘 동작하는 소프트웨어를 실제로 만드는 게 자기 일이라는 걸 잊는 유형임. 첫 EJB 명세의 우스꽝스러움이나 Java의 조롱받던 AbstractFactoryBuilderConstructor 같은 것도 그런 부류가 낳았다고 봄
      시간이 지나며 이런 성향을 잘 알아보고 멀리하는 편이 됐음
    • “몇 년 동안 float로 레이아웃을 짰다”는 건 faux columns라고 불렸고, 기본 3열 레이아웃조차 너무 어려워서 레이아웃의 “성배”라고까지 불렸음
      https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
    • W3Schools가 아직도 부르는 이름처럼, 새롭고 현대적인 clearfix 해킹임
      .clearfix::after { content: ""; clear: both; display: table; }
      [1] https://www.w3schools.com/howto/howto_css_clearfix.asp
    • 표와 flexbox/grid 사이의 시대는 힘들었음
      float는 까다롭고 제대로 맞추기 어려웠고, 많은 사람이 그냥 표로 돌아갔는데 솔직히 탓할 수 없었음

  • spacer.gif는 존중받지 못하나?
    물론 HN에는 아직 있고, 모든 페이지 요청에 포함됨
    https://news.ycombinator.com/s.gif

    • 표 기반 레이아웃 이야기는 스페이서 이미지 없이는 완성되지 않음

  • 좋아했던 것들 몇 가지가 있음
    Faux columns는 시각적으로 늘어난 것처럼 보여 사이드바가 본문만큼 긴 것처럼 만들었음: https://alistapart.com/article/fauxcolumns/
    더 나아가 9-patch와 9개의 div 또는 3x3 표로 축마다 배경을 반복해 직접 테두리를 흉내 낼 수 있었음. CSS3에서 border-image가 생겨 조금 도움은 됐지만, 이런 테두리 스타일은 이제 별로 유행하지 않음
    둥근 테두리도 9-patch로 만들 수 있었고, 많은 사람은 생성기로 여러 요소를 만들어 둥근 테두리를 시뮬레이션하는 HTML을 만들었음. 이 글이 설명함: http://benogle.com/2009/04/29/css-round-corners.html 보통은 추가 마크업이 이미지보다 바이트는 더 크지만 왕복 요청이 줄고 꽤 쉽게 할 수 있다는 인식이었음

    • 우리 팀은 3x3 방식을 너무 많이 써서 아예 그걸 위한 컴포넌트를 만들었음
      ActionScript 쪽에 더 가까웠지만 스타일링 아이디어는 같아서 글도 썼음: https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
      또 하나 좋았던 건 반복되지 않는 배경 스타일 패턴에 cicada principle을 쓰는 방식이었음
    • A List Apart를 눌러 봤더니 모바일에서 헤더가 깨져 있어 꽤 충격적이었음
      그래도 세월이 이렇게 지났는데도 여전히 깔끔함
    • 둥근 모서리를 위한 sliding doors 기법도 언급할 만함: https://alistapart.com/article/slidingdoors/
    • Faux columns는 아직도 우리 메인 웹사이트에 살아 있음. 더 현대적인 것으로 바꿀 시간이 늘 없어서 ;)

  • HN이 지금도 이 중 하나를 쓰는 게 마음에 듦: HTML 표로 레이아웃 구성
    좀 더 진지하게 보면, 이 목록은 표준 없이 개발하면 제어 정보가 여러 “그럭저럭 참을 만한” 부수 경로에 인코딩된다는 걸 잘 보여줌
    이런 혼란과 충돌 가능성은 현재 W3C 프로세스가 때때로 받는 경멸을 다시 보게 함. 이 프로세스는 표준 주도 웹 기술 진화와 브라우저 주도 혁신을 결합하고, 둘이 번갈아 앞서거나 나란히 진행되게 함
    자주 조롱받긴 하지만, 이전 방식보다 더 지속 가능하고 안정적인 방식으로 해석할 수도 있음
    새로운 W3C-벤더 규범을 비난하는 사람들 중 얼마나 많은 사람이 이 “기묘한 해킹 10가지”가 떠올리게 하는 들뜬 시절로 돌아가고 싶어 할지 궁금함

    • 그건 표준의 부재라기보다 필요한 기능의 부재에 가까움
      하고 싶은 일이 기능으로 다뤄지지 않으면 어떻게든 창의적으로 하게 됨. 표준은 충분히 성숙해 잠재적 요구를 모두 포착하지 못하면 오히려 경직성을 만들어 이런 상황을 낳음. 특히 웹처럼 필요에 맞을 수도 있고 아닐 수도 있는 표준에 묶이는 경우가 그렇다
      다른 분야에서는 보통 선택지가 충분해서, 그중 하나는 필요한 일을 할 만큼 유연하고 그걸 고르면 됨
      연구 쪽에서 오래 일해 보면, 하고 싶은 일이 해키한 기술 접근을 요구하는 경우가 놀랄 만큼 많음. 많은 표준과 기능 집합이 돈이 몰리는 비즈니스/소비자 상호작용과 그 주변 시스템을 중심으로 생기기 때문임
    • 안타깝게도 요즘 W3C와 TC39는 Google이 완전히 지배하고 있고, 절차에는 거의 형식적으로만 신경 쓰면서 많은 표준을 밀어붙임
      브라우저 기능에 의존하는 많은 플레이어들, 예를 들어 앱을 WebKit이나 Chromium 버전 안에서 돌리는 TV 벤더들은 표준 위원회에서 완전히 조용함. 그래서 사실상 Google, Apple, Mozilla의 3자 줄다리기에도 못 미침
    • 표가 “사라졌다”고 하더니 널리 Bootstrap으로 대체된 게 재미있음
      결과적으로 div 안에 들어간 표를 얻게 됨. 다만 12열짜리일 뿐
    • WHATWG는 영리 목적의 이해관계 말고는 누구를 위해서도 웹을 발전시키지 않았음
      HTML 3.2로 배웠기 때문에 IE와 Netscape 때문에 어떤 비잔틴식 헛짓이 필요했는지 잘 알고 있음. 하지만 그건 MS와 Netscape의 선택이었고, W3C의 존재감이 더 컸더라도 MS와 Netscape가 새 표준을 따를 보장이나 암시는 없었음
      그래도 지금처럼 한 대기업이 원하면 나머지 웹이 감당해야 하는 쓰레기 같은 상황보다는 그때가 나았음
      정말 훨씬 낫다니, 참 좋네 /s

  • 내가 “가장 좋아하는” 해킹이 빠졌음. 접근성용 제목을 -10000 위치에 둬서 화면에는 렌더링되지 않지만 스크린 리더는 읽게 하는 방식임

    • 이 방식과 가까운 변형은 아직도 꽤 흔함. 모든 경우에 보이지 않지만 스크린 리더가 접근 가능한 텍스트를 다루는 훌륭한 선택지가 여전히 없기 때문임
      aria-label 같은 것이 이 패턴의 일부 사용처를 대체했지만 전부는 아님
    • 아직도 동작하나? 아니면 ARIA를 써야 하나?

  • 모든 CSS보다 먼저 설치해서 브라우저 quirks를 없애던 html5 shiv 이야기가 없음
    https://paulirish.com/2011/the-history-of-the-html5-shiv/

    • reset, normalize 같은 것도 빠졌음

  • 표 셀을 얌전히 유지하려고 쓰던 투명 1×1 픽셀 GIF의 좋은 옛날이 기억남

    • “좋은 옛날”? 지금 보고 있는 페이지도 그걸 쓰고 있음 ;)
      https://news.ycombinator.com/item?id=38485665
    • 예전에는 큰 이미지를 격자 패턴으로 잘라 표로 붙잡아 두곤 했음
      왜 그랬는지도 기억이 안 남. 더 빠르게 로딩하려고였나?

  • 초기 시절에서 하나 더 추가하자면, 줄바꿈 없는 공백 문자 엔티티인 &nbsp;의 광범위한 사용이 있었음
    컨테이너 안에서 텍스트를 오른쪽이나 왼쪽으로 밀 때 썼고, 기억상으로는 표 셀을 얌전히 만들기 위해 1x1 스페이서 GIF처럼 쓰기도 했음. 어떤 페이지에는 &nbsp;가 수백 개씩 있었고, 여백이나 패딩을 넣는 범용 수단에 가까웠음

  • 현대 웹 개발자가 CSS Grid가 있고 IE가 죽어서 버릇이 나빠진 건지, 아니면 우리가 당시 현대 프레임워크와 빌드 과정의 복잡성을 안 겪어서 버릇이 나빴던 건지 가끔 모르겠음

    • 아마 둘 다일 것 같음
      다만 요즘이 더 쉽긴 할 듯함. 기술적으로 현대 프레임워크와 빌드 과정을 꼭 쓸 필요는 없고, 현대 CSS와 JavaScript만으로 예전엔 복잡했을 사이트와 앱을 쉽게 만들 수 있기 때문임
    • 웹 개발은 내가 일해 본 다른 분야와 비교해 독특한 뉘앙스가 있음
      업계가 바퀴를 더 복잡한 방식으로 계속 재발명하는 습관을 들였음
      가장 그럴듯한 추측은 웹이 신규 개발자나 경험이 적은 개발자가 더 자주 선택하는 분야라는 부작용이라는 것임

  • 반응형 디자인이 정말 해킹인가? 미디어 쿼리는 훌륭함
    조건 로직을 JavaScript에 넣는 대신 CSS에 두는 건 큰 승리임. 특히 서버 사이드 렌더링을 원할 때 그렇다

    • 서로 다른 매체를 지원하기 위해 미디어 쿼리를 쓰는 건 정확히 올바른 사용 사례처럼 보임
    • 실제로 알고 싶은 것을 질의하는 게 아니라, 필요한 것과 우연히 상관관계가 있는 것을 질의한다면 해킹이 됨
    • 해킹이 아님
      사용자 에이전트의 여러 특성을 질의하고 그 결과에 따라 다른 CSS를 제공할 수 있음. 이걸 해킹이라고 부르는 건 무지한 것이고, 반응형 디자인을 만드는 데 필요한 부분임
답변달기