▲

<Blink>와 <Marquee> (2020)

 (danq.me)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • 90년대 웹 초기에 등장한 <blink>와 <marquee> 태그는 당시 웹디자인의 상징적인 요소였음
  • <blink> 태그는 Netscape Navigator 2.0에서 도입되며, 장난스러운 목적과 심미성 부족에도 불구하고 널리 사용됐음
  • Microsoft는 이에 대응해 Internet Explorer에 <marquee> 태그를 도입해 텍스트 애니메이션을 한층 다양하게 제어할 수 있게 했음
  • 두 태그를 중첩해서 사용하면 브라우저 별로 다른 애니메이션 효과 제공이 가능했으며, 점진적 향상 원칙의 사례로 언급됨
  • 현재 <blink>는 사라졌고 <marquee>도 사용이 권장되지 않지만, 웹 역사와 온라인 노스탤지어의 대표 사례로 회자됨

서론: <blink>와 <marquee> 태그의 회상

  • 최근 동료 웹 개발자와 대화 중, HTML <blink>와 <marquee> 태그에 대한 농담을 했는데, 상대방 개발자가 이 두 태그를 모른다는 사실을 알게 됨
  • 이 태그들은 현재 젊은 개발자들에게는 생소하지만, 한때 90년대 웹디자인의 상징적인 요소였음

<blink> 태그의 탄생 배경과 역사

  • <blink> 태그의 창조자는 종종 Lynx 브라우저를 만든 Lou Montulli로 알려져 있으나, 실제로 그는 자신이 직접 코드를 작성하지 않았다고 밝힘
  • 그의 주장에 따르면 한 바에서 Netscape 엔지니어들과의 대화 중, Lynx 같은 텍스트 브라우저에도 사용할 수 있는 “텍스트 깜박임 효과”가 농담으로 제안되었고, 이를 바탕으로 다른 엔지니어가 밤새 작업해 구현함
  • 1995년 Netscape Navigator 2.0에 <blink> 태그가 정식 도입돼, 움직이는 GIF와 초기 JavaScript와 함께 개인 웹사이트 경험을 정의하는 데 일조함
  • <blink> 태그는 속성 없이 사용되며, HTML4에서는 공식적으로 농담용 태그로 기록됨에도 불구하고, 90년대 후반 대중적으로 남용됨
  • “최신 업데이트” 강조 등 각종 메시지의 주목성을 높이기 위해 많이 쓰였음

<marquee> 태그와 브라우저 간 경쟁

  • 같은 해 Microsoft가 발표한 Internet Explorer 2.0은 Netscape의 <blink>와 달리, <marquee> 태그를 도입함
  • <marquee> 태그는 스크롤 방향, 속도, 반복 여부 등 다양한 속성으로 애니메이션을 조정할 수 있음
  • <blink>가 농담조로 시각적 가독성을 해칠 수 있도록 했다면, <marquee>는 의도적으로 효과를 강조함
  • 90년대 말에는 두 태그를 함께 사용하는 방식—<marquee> 안에 <blink>—이 브라우저별(IE와 Netscape)로 서로 다른 효과를 제공하는 방법으로 유행함

점진적 향상(Progressive Enhancement)과 웹 호환성

  • <blink>와 <marquee>의 중첩 사용은 웹 브라우저가 미지원 태그를 무시하고 내부 콘텐츠는 그대로 렌더링하는 Postel’s Law(관용의 원칙) 와 관련됨
  • 새로운 HTML 요소(<video> 등)도 이런 이유로 종종 비자기 종료 태그를 적용, 호환성 보장에 힘씀
  • <blink>/<marquee> 같은 태그를 활용할 경우, 태그를 모르는 브라우저에서도 정보 콘텐츠를 읽을 수 있었음
  • 웹은 모든 사용자에게 정보를 제공하고, 일부 브라우저만 추가 효과를 즐길 수 있도록 하는 점진적 향상 개념에 기반함

다양한 브라우저에서의 변화와 지원

  • Opera 사용자는 유료 라이선스로도 <blink>나 <marquee> 효과를 거의 보지 못했으나, 콘텐츠 접근엔 문제가 없었음
  • Netscape 7은 <blink>와 <marquee>를 모두 지원한 거의 유일한 브라우저로, 동시에 스크롤 + 깜박임 효과를 구현할 수 있어 웹에서 가장 보기 힘든 효과 연출 가능했음

결론: 현재의 위치와 웹 디자인의 교훈

  • <blink> 태그는 현재 완전히 사라졌음(현대 브라우저 미지원), 필요하다면 CSS 애니메이션으로 대체 가능함
  • <marquee>는 일부 브라우저에서 여전히 기본 지원 또는 polyfill이 존재함에도 불구하고, 사용은 추천되지 않음
  • 웹의 역사와 과거 온라인 미학의 상징이자, 웹 표준과 접근성과 유지보수의 교훈적 사례로 남아 있음
  • 디지털 노스탤지어에 관심이 있다면, 예전 웹 디자인과 관련된 자료나 사이트를 참고하면 됨
▲
GN⁺ 10시간전  [-]
Hacker News 의견

  • 예전에 아래 링크와 같은 사이트가 있었던 기억이 있음 https://danq.me/2020/11/11/blink-and-marquee/">https://web.archive.org/web/20201111125145/…

  • 나는 3,000년 전부터 있었던 느낌의 사람임. 프레임 내비게이션이 나쁜 관행인지에 대해 격렬하게 논쟁하던 시절을 기억함 (iframe이 아니라 프레임임). 프레임을 아는 사람이 혹시 있으면 반가움. AJAX가 나오기 전에는 HTTP 204를 활용해 페이지 새로고침 없이 서버로 메시지를 보내는 방법을 직접 썼음. 2000년대 초반에는 이미지 맵도 작업함 이미지 맵 참고: https://developer.mozilla.org/en-US/docs/…. 드림위버로 지도 경계선을 여러 날 동안 그려서 클릭 가능한 국가 지도를 완성한 적도 있음. 드림위버 템플릿은 버전 컨트롤을 안 써서 업데이트하다가 수정사항 다 날리고 복구 불가능한 상황도 많았음. input type=image으로 이미지 클릭 위치를 백엔드에서 처리하던 기억도 있음. 모션 JPEG을 이용해 페이지에 스트리밍 업데이트도 구현했고, 아직도 크롬에서는 되고 파이어폭스에서는 약간 불안정함. IE에서 PNG 알파 블렌딩 문제 해결하려고 여러 방법을 시도하다가 결국 ActiveX 버전으로 좀 써먹었으나, 결국 플랫 디자인 유행하면서 필요 없어짐. 네비게이션은 JAVA, Flash, Silverlight까지 다 써봤음. 스페이서 GIF, 조건부 주석, Firebug 등장 이후 개발환경이 얼마나 편해졌는지도 생생하게 기억함. 언제 나이가 들었는지 모르게 시간이 흘렀던 경험임

    • 예전 프레임으로 웹 소프트웨어를 개발했는데 딱히 문제를 느끼지 못했음. 사람들은 접근성을 이야기하지만 구체적으로 어디가 문제인지 아직까지도 잘 모르겠음

    • IE6의 모든 괴상한 버그와 한계 속에서 지원을 요청하는 고객사를 위해 일했던 기억임. 디자이너가 포토샵으로 둥근 모서리 디자인을 넘기면 매번 한숨 쉴 수밖에 없었음. 그 당시에는 반응형이라는 게 사실 데스크탑 해상도 여러 개 대응하는 정도였음. 모서리를 이미지로 잘라 테이블 셀에 직접 배치해야 했음. 이런 수작업을 하면서 개발자의 정신력이 크게 강화됨을 느낌

    • 포토샵 slice 툴로 이미지를 세밀하게 나누고 gif로 내보낸 후 HTML 테이블에 정확하게 배치하려 애썼던 때를 기억함. 800x600 해상도에 최적화된 디자인이 많았던 시절임. 이 모든 추억이 시간 속에 녹아 사라진 느낌임

    • 지금도 프레임을 몇 번씩 방문하는 사이트가 있음. Open Group/POSIX 사이트는 여전히 프레임을 사용 중임

    • 프레임을 이용해 웹챗을 만든 적이 있음. 위에는 무한 로딩되는 채팅창, 아래에는 input box가 있었고, 메시지 보낼 때는 204로 새로고침을 막았음. 위쪽 프레임에는 user list가 있는 오른쪽 프레임을 reload하는 작은 script도 보낼 수 있었음. 2000년 즈음에 친구 몇 명과 함께 사용했음

  • 전에 순수 marquee 태그만으로 애니메이션을 구현한 사이트를 만들었음. JavaScript는 전혀 사용하지 않았고, 누군가에게 보여주면 다들 놀람 https://udel.edu/~ianozi/

    • marquee 태그 안 본지 20년은 된 것 같은데, direction 파라미터로 수직 스크롤도 가능하다는 사실을 몰랐던 것 같음

  • marquee 태그로 제일 좋아하는 트릭은 중첩해서 쓰는 것임. 방향을 다르게 하면, 안쪽 marquee를 반대 방향과 같은 속도로 맞추면 순간 정지했다가 움직이는 효과를 낼 수 있음. 속도를 다르게 하면 더 복잡한 움직임도 구현 가능했음. 이 방법이 제대로 작동하려면 inner marquee에 최대 너비를 설정해줘야 했던 기억임

  • 예전에 blink 태그가 워낙 싫어서 사용하던 브라우저(아마 Netscape)의 바이너리 파일에서 'blink'를 'blonk'로 바꿔서 더 이상 깜박이지 않게 만든 적 있음

    • 나는 이런 식의 바이너리 트윅을 주로 Slack 클라이언트에서 자주 함(Electron 앱이라 엄청 쉬움). 내가 싫어하는 기능(예: 알림 숨기기, 입력 중 신호 차단하기 등)도 쉽게 없앨 수 있음

    • 누군가 blonk 태그를 썼으면 이제는 blonking이 생겼을지 모름. 꽤 재미있는 해킹 같음

    • 바이너리 수정이 꽤 재미있음. "__gnu_warning"를 "__gnu_whining"으로 바꿔서 gets() 경고성 메시지를 없애곤 했음. 버퍼 오버런은 그럴 수도 있지만 대충 만드는 코드에서는 굳이 신경 안 씀

  • marquee 태그를 HTML 인젝션 테스트에 매우 유용하게 씀. 거의 아무도 안 쓰는 움직이는 태그라 공격이 먹혔는지 바로 알아볼 수 있음. 비기술자에게도 텍스트가 움직여야 하지 말아야 할 때 움직이는 걸 보여주면 bold 같은 것보다 훨씬 쉽게 위험성을 이해시킬 수 있음

    • HTML 정화(sanitization)할 때, 이스터에그 용으로 marquee만 화이트리스트에 남겨두고 나머지는 거의 다 막음

    • Hacker News를 커스텀 aggregator로 보고 있는데, 이 글을 통해 HTML 인젝션에 취약하다는 걸 알아냄. 2020년 글이 화면을 marquee로 돌아다니고 있었음

  • "야수는 복수의 소용돌이 구름에 둘러싸여 등장할 것. 불신자의 집이 파괴되고, 그들의 태그는 끝날 때까지 깜박일 것이다.” – The Book of Mozilla, 12:10 (about:mozilla)라는 멘트와 함께 지금 Mozilla도 사라지는 중이라는 생각을 함. 마치 종말 느낌임

    • 나는 아직도 Firefox를 기본 브라우저로 사용 중임

  • 대학 기숙사 플로어 웹사이트를 내 컴퓨터에서 돌린 시절을 떠올림. marquee로 997단어 분량의 긴 메시지를 올려뒀었는데, 거기에는 여자, 우울, 철학 등 여러 얘기를 주절주절 적음. 메시지 끝에 ! 표시가 있었고, 그게 숨겨진 페이지로 링크되어 있었음. 결국 누군가 view source로 긴 내용을 읽어보다가 그 페이지 찾아냈음

  • 내 친구가 항상 본인 미들네임에 blink 태그를 둘러서 escaping 누락 및 잠재적 xss 여부를 빠르게 테스트하곤 했음. 예전엔 이런 단순한 방식도 취약점 발견에 꽤나 효과적이었음

  • 이 코멘트는 현재 공사 중임. 자주 들러서 업데이트 확인 바람

    • 방문자 카운터랑 방명록은 어디에 있는지 궁금함

    • 이 페이지는 어떤 브라우저에 최적화되었는지 궁금함

    • [NEW] 표시를 잊지 않길 바람

답변달기