이곳은 개발을 위한 베타 사이트 입니다.
기여내역은 언제든 초기화될 수 있으며, 예기치 못한 오류가 발생할 수 있습니다.

프레임(HTML 태그)

덤프버전 :

분류

파일:Framing Link 예제.png
개드립넷
1. 개요
2. 장점
3. 단점
3.1. 프레임 구조의 장점이 묻혀버린 이유
4. HTML5 규격에서 제외되다
5. iframe
6. 관련 문서


1. 개요[편집]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
Frameset Example










이 페이지를 보려면, 프레임을 볼 수 있는 브라우저가 필요합니다.

<div class="indent"></div>




</html>
1번 줄은 프레임셋을 위한 HTML 4.01의 DTD다. DTD의 개념이 보급되지 않던 시절에는 이것이 생략되고 바로 <html>부터 시작하는 경우가 많았다. 어쨌든 대략 아래와 같은 모양으로 나타난다.

Frameset Example
top.html
left.html
main.html

이런 식으로 복수의 웹 페이지가 구획별로 나뉘어서 동시에 표시되게 하는 태그이다. 물론 위의 그림은 진짜 프레임이 아니라 대충 테이블로 모양만 구현해 놓은 것이다.

w3schools.com의 프레임 태그 관련 설명

1990년대에서 2000년대 사이 인터넷에서 개인 홈페이지 열풍이 불어 우후죽순처럼 수많은 개인 홈페이지가 쏟아져 나오던 시절이 있었는데 당시 많은 홈페이지가 이런 형태로 되어 있었다. 이를테면 위쪽이나 왼쪽을 조금 잘라내 메뉴 부분으로 쓰고 나머지 부분에 내용이 나오게 하는 식이었는데 이를 위해 메뉴 부분용 HTML 문서를 따로 만들어 놓고 그 메뉴용 문서에 사이트맵을 링크해서 썼다.

지금은 사라졌지만 엔하위키 미러의 1999년 버전(아카이브)도 그 당시의 풍조를 재현하여 프레임 형태로 만들어져 있었다. 다만, 이쪽은 진짜 프레임 태그를 쓴 건 아니고 <div> 태그와 CSS를 이용하여 프레임처럼 보이게 흉내를 낸 것이다.

이런 특성 때문에 만약에 프레임이 가리키는 문서가 순환 참조면 인셉션마냥 프레임이 무한히 반복되는 괴랄한 현상이 일어나지 않을까 생각될지도 모르겠지만 브라우저에서 이런 경우가 생길 것을 대비하여 반복되지 않게 하거나 반복되더라도 몇 번째에서 중지되는 처리를 하고 있다.


2. 장점[편집]

이 방식은 다음과 같은 장점이 있어 그 당시 많이 쓰였다.
  • 메뉴 구성을 만들기 좋다.
  • 메뉴용 페이지만 만들어 놓고 프레임에 박아 놓으면 되기 때문에 각 콘텐츠 페이지마다 일일이 사이트맵을 붙일 필요가 없어진다. 메뉴 구성에 뭔가를 추가하거나 삭제하려면 모든 콘텐츠 페이지를 번거롭게 손봐줘야 하는 수고로움이 생기게 되는데 프레임을 사용하면 이러한 수고를 덜 수 있다.
  • 콘텐츠 페이지를 스크롤하더라도 메뉴 페이지는 고정되기 때문에 스크롤압박이 심한 페이지를 읽어도 다른 메뉴 항목으로 들어가려고 다시 스크롤을 올려야 할 필요가 없어진다. 그냥 키보드의 홈 키 누르면 되지 않나?
  • 메뉴 페이지를 통해 콘텐츠 페이지를 이리저리 옮겨다녀도 메뉴 페이지를 고정시켜 놓을 수 있기에, 웹사이트에 <embed> 태그 등을 써서 넣은 배경음악이나 플래시 같은 멀티미디어를 끊김없이 재생할 수 있다. <bgsound>는 말 그대로 배경음악을 넣기 위한 태그였는데 Internet Explorer 전용 비표준 태그라 다른 웹 브라우저에선 작동하지 않았다. 그래서 다른 웹 브라우저에서도 배경음악을 재생할 수 있도록 하기 위해 <embed> 태그로 대체하는 경우가 있었다. HTML5 규격에서는 <audio> 태그로 대체할 수 있다. 배경음악 태그를 콘텐츠 페이지마다 일일이 넣으면 옮겨다닐 때마다 음악이 끊어지고 처음부터 다시 재생되지만 항상 고정되는 메뉴 페이지에 넣으면 끊김없이 재생된다. 또한, 프레임 태그를 이용해 일종의 편법을 쓰면 노프레임 구조에서도 끊김없는 배경음악을 구현할 수 있다. 참고로 개인 홈페이지가 유행하던 시절 개인 홈페이지 운영자를 위해 제공되었던 무료 도메인 포워딩 서비스가 이와 비슷한 방식을 쓰고 있었다.

3. 단점[편집]

그러나 단점도 있었는데, 프레임이 지원되지 않는 브라우저에서는 당연히 표시할 수 없었다. 이런 경우를 대비해 <noframes> 태그가 있다고는 하나 프레임 미지원시 나오는 메시지를 표시하기 위한 태그일 뿐이다. 즉, 프레임이 지원되지 않는 브라우저를 배려하려면 아예 노프레임 페이지를 따로 만들어야 하지만, 그렇게 하느니 아예 처음부터 노프레임으로 만드는 게 낫다.

당시는 프레임이 지원되는 브라우저가 많이 보급된 상황이니 이 문제는 차치하고 넘어가더라도, 또 다른 문제로 이 구조가 접근성과 사용성에 부정적인 영향을 미친다는 지적이 있었다. 프레임 구조로 복수의 페이지를 한 화면에 나타낸다는 것은 곧 한 화면에 표시될 페이지가 둘로 쪼개진다는 것을 의미하기에, 그로 인해 따라오는 다음과 같은 문제들이 있다.
  • 웹 브라우저의 소스 보기 기능을 써 보면 나오는 건 프레임 뼈대 소스 뿐이고 각 페이지의 소스를 보려면 그 프레임으로 가서 마우스 오른쪽 버튼 누르고 소스 보기 하는 방법을 써야 한다.[1]
  • 웹 브라우저의 제목 표시줄이나 탭에 나오는 제목(<title> 태그를 써서 지정해 줄 수 있는 그 것)이 고정되어 버린다. 이는 프레임 구조의 문서는 제목을 프레임셋 본체의 제목으로 보여주기 때문이다. 그래서 각 문서로 갈 때마다 제목이 바뀌게 하고 싶어도 불가능해진다. 거기에 한 술 더 떠서 아예 제목이 '이 페이지를 보려면, 프레임을 볼 수 있는 브라우저가 필요합니다.'로 되어 있어서[2] 검색 엔진에서 그렇게 잡힌다면 들어가 보기 전에는 도대체 뭐 하는 페이지인지 직관적으로 알 수 없게 된다. 또한 기본적으로 프레임셋을 보여주는 URL이 고정되어 있어, 프레임의 특정 페이지를 포함하는 프레임셋으로 이동 및 링크할 수 없다.
  • 파밍[3]에 취약해진다. 각 프레임이 보여 주는 페이지가 어디인지 쉽게 알지 못하기 때문에 공격자의 페이지 변조 한 방에 눈 뜨고 코 베이는 상황이 일어날 수 있다. 이것은 <iframe>에서도 갖고 있는 문제.
  • 반응형 웹 사이트가 대세인 오늘날의 트렌드와 상극이다. 예를 들어 프레임을 통해 페이지가 좌우로 나뉘어져 있다고 했을 때, 일반적인 PC 모니터로는 폭이 넓어서 넉넉하게 페이지를 볼 수 있지만 스마트폰의 세로로 긴 화면에서는 안그래도 화면이 작은데 나뉘어져 있기까지 해서 페이지를 읽기 나쁘게 되어 버린다. 그래서 마치 플래시처럼 스마트폰 시대의 개막과 함께 프레임 구조의 대안으로 CSS를 이용한 반응형 구조가 부상하면서 빠르게 사장되어 갔다. 이는 표를 그릴 때 쓰는 <table> 태그를 레이아웃용으로 사용하지 말 것을 권고하는 추세와 맥락을 같이 한다.
  • 페이지의 파편화 문제가 생긴다. 검색 엔진에 등록시 프레임셋 뿐만 아니라 메뉴용 페이지와 콘텐츠용 페이지들까지 함께 크롤링한다. 즉, 프레임에 들어가야 할 개별 페이지까지 검색에 잡히는데 그 경로로 들어가면 당연히 프레임에 들어가지 않은 형태로 그 페이지만 한 화면을 떡하니 차지한다. 대개 이런 경우는 메뉴용 페이지에 오고 가는 링크를 거는 경우가 일반적인데 프레임에 넣어서 표시하도록 만든 페이지를 외롭게(?) 보여주니 당연히 접근성 저하가 올 수밖에 없다.
그 외에도 프레임 구조가 갖는 비효율성은 많다. 결정적으로 프레임 구조가 가지고 있던 장점도 CSS와 jQuery 등의 등장으로 인해 거의 묻혀버렸다.


3.1. 프레임 구조의 장점이 묻혀버린 이유[편집]

저 위의 '장점' 섹션에 서술한 장점을 반박하는 형식으로 작성되었다.

  • 메뉴 구성의 용이성
CSS와 jQuery 등을 이용하면 프레임이 없이도 좋은 메뉴 구성을 만들 수 있다. 이런 면에서 볼 때는 오히려 노프레임이 프레임 구조에 비해 메뉴 구성의 자유도가 훨씬 높다.

  • 메뉴 배치의 편의성
과거 페이지 전체를 사용자가 일일이 코딩해야 했던 시절에는 모든 페이지에 공통적으로 들어갈 부분을 프레임으로 따로 빼는 것이 효율적이었으나, XpressEngine이나 워드프레스 등의 CMS가 보급되면서 레이아웃 코드 하나 편집해서 전체에 적용되는 방식이 대세가 됨에 따라 그럴 필요가 없어졌다. 기존 프레임 구조에서는 메뉴로 쓸 페이지만 따로 분리하는 만큼 메뉴 부분에 변화를 줄 수 없다는 단점도 있었으나, CMS의 레이아웃 기능으로 자유도를 높임에 따라 이런 단점도 자연스레 해소되었다.

  • 메뉴 위치 고정에 따른 접근성 향상
CSS를 이용하여 메뉴를 플로팅으로 처리하는 방식이 등장하고 모바일 배려 차원에서 jQuery를 이용하여 홈 키의 역할을 수행하는 버튼을 넣을 수 있게 되었다. 따라서 노프레임 구조에서 스크롤압박이 심해지더라도 메뉴 접근성 저하가 발생할 걱정은 필요없게 되었다.

  • 끊김 없는 배경음악 재생
끊김 없는 배경음악 재생은