1. 개요
{{{#!syntax xml
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"><html>
<head>
<frameset rows="15%,*" border="0">
</html>
<title>Frameset Example</title>
</head><frameset rows="15%,*" border="0">
<frame src="top.html" name="top" scrolling="no" noresize>
<frameset rows="1*" cols="15%, *" border="0">
<noframes>
</frameset>
<frameset rows="1*" cols="15%, *" border="0">
<frame src="left.html" name="left" scrolling="yes" noresize>
<frame src="main.html" name="main" scrolling="yes" noresize>
</frameset><frame src="main.html" name="main" scrolling="yes" noresize>
<noframes>
<p>이 페이지를 보려면, 프레임을 볼 수 있는 브라우저가 필요합니다.</p>
</noframes>
}}}
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>태그를 레이아웃용으로 사용하지 말 것을 권고하는 추세와 맥락을 같이 한다. - 페이지의 파편화 문제가 생긴다. 검색 엔진에 등록시 프레임셋 뿐만 아니라 메뉴용 페이지와 콘텐츠용 페이지들까지 함께 크롤링한다. 즉, 프레임에 들어가야 할 개별 페이지까지 검색에 잡히는데 그 경로로 들어가면 당연히 프레임에 들어가지 않은 형태로 그 페이지만 한 화면을 떡하니 차지한다. 대개 이런 경우는 메뉴용 페이지에 오고 가는 링크를 거는 경우가 일반적인데 프레임에 넣어서 표시하도록 만든 페이지를 외롭게(?) 보여주니 당연히 접근성 저하가 올 수밖에 없다.
3.1. 프레임 구조의 장점이 묻혀버린 이유
저 위의 '장점' 섹션에 서술한 장점을 반박하는 형식으로 작성되었다.-
메뉴 구성의 용이성
CSS와 jQuery 등을 이용하면 프레임이 없이도 좋은 메뉴 구성을 만들 수 있다. 이런 면에서 볼 때는 오히려 노프레임이 프레임 구조에 비해 메뉴 구성의 자유도가 훨씬 높다.
-
메뉴 배치의 편의성
과거 페이지 전체를 사용자가 일일이 코딩해야 했던 시절에는 모든 페이지에 공통적으로 들어갈 부분을 프레임으로 따로 빼는 것이 효율적이었으나, XpressEngine이나 워드프레스 등의 CMS가 보급되면서 레이아웃 코드 하나 편집해서 전체에 적용되는 방식이 대세가 됨에 따라 그럴 필요가 없어졌다. 기존 프레임 구조에서는 메뉴로 쓸 페이지만 따로 분리하는 만큼 메뉴 부분에 변화를 줄 수 없다는 단점도 있었으나, CMS의 레이아웃 기능으로 자유도를 높임에 따라 이런 단점도 자연스레 해소되었다.
-
메뉴 위치 고정에 따른 접근성 향상
CSS를 이용하여 메뉴를 플로팅으로 처리하는 방식이 등장하고 모바일 배려 차원에서 jQuery를 이용하여 홈 키의 역할을 수행하는 버튼을 넣을 수 있게 되었다. 따라서 노프레임 구조에서 스크롤압박이 심해지더라도 메뉴 접근성 저하가 발생할 걱정은 필요없게 되었다.
-
끊김 없는 배경음악 재생
끊김 없는 배경음악 재생은<iframe>태그를 이용해도 할 수 있는데다가, 오늘날의 홈페이지 배경음악은 개별 기사에 삽입하는 정도고 예전처럼 홈페이지 전체적으로 배경음악을 넣는 경우는 점점 드물어지는 추세로 가고 있다.
-
모바일 웹의 득세와
반응형 웹의 등장
모바일에서는 프레임 자체가 상당한 불편을 초래한다. 게다가 반응형 웹 디자인이라는 새로운 디자인 구조는 프레임과는 그야말로 상성이 상극이다.
-
AJAX의 등장
AJAX라는 대체 기술이 등장하면서 노프레임 구조에서도, 그것도 더 효율적인 작업이 가능해졌다.
-
TLS의 보편화
TLS는 특성상 모든 구성요소를 https로 불러오게 처리해야 하는데[4], 프레임 구조에서는 상대적으로 해야 할 작업량이 많아지기 때문에 TLS 환경에서는 프레임 구조가 사실상 사장되었다.
4. HTML5 규격에서 제외되다
이러한 이유로 W3C에서는 프레임 구조의 사용을 지양할 것을 권고하면서 프레임 구조로 된 웹 사이트는 점점 줄어드는 추세로 돌아섰고 HTML5 규격에는 아예 빠져버렸다. 다만 아직 프레임 구조로 된 웹 사이트들이 남아있기 때문에 브라우저에는 여전히 지원하고 있다. 구글에 '이 페이지를 보려면 프레임을 볼 수 있는 브라우저가 필요합니다'라고 검색해 봐도 꽤 나온다(...).하지만 이런 사이트들을 들어가 보면 높은 확률로 오래 전에 만든 사이트들이고 오늘날에는 프레임 구조가 거의 사장된 상태라 장래에는 웹 브라우저에서도 프레임셋 태그(
<frame>, <frameset>, <noframes>)를 아예 지원하지 않게 될 수도 있다.이미 폐기된 태그를 브라우저에서 지원 중단시킨 선례가 존재한다.
<basefont> 태그가 그 예. 말 그대로 페이지에서 기본으로 표시될 글꼴을 지정하는 태그였는데 사용 빈도가 그다지 높지 않았고
CSS가 보급된 이후로는 점점 사장되어 갔다.
Internet Explorer에서는 9을 끝으로 지원이 중단되어 버렸고 다른 웹 브라우저도 마찬가지로 지원을 중단하면서 현재 어느 브라우저에서도 <basefont> 태그를 지원하지 않는다.5. iframe
iframe은 inline frame의 줄임말이다.<iframe>은 문서 전체가 프레임인 게 아니라 문서 안에 박스형으로 프레임을 넣을 때 쓴다. 이
태그는
HTML5에서도 계속 지원된다. 물론 iframe도 남용하면 웹 접근성이 저하되는 건 똑같다.-
<iframe>: 페이지 안에서 또 페이지를 볼 수 있다. 예를 들면 문서에서 구글 지도 등을 넣는 것이 있다. - src: 넣을 페이지의 주소를 지정한다.
- height, width: 프레임의 높이, 너비를 지정한다. 물론 CSS를 쓰는 것이 더 좋다.
- sandbox: iframe에 샌드박스 정책을 지정한다. 주로 사용하는 값은 allow-same-origin, allow-popups, allow-scripts 정도.
- frameborder: 프레임의 테두리 표시 여부를 지정한다. 0은 표시하지 않음, 1은 표시함.[5]
- allowfullscreen: HTML5에서 지원하는 속성으로, 전체 화면 모드로 전환할 수 있도록 허용한다.[6]
{{{#!syntax xml
src="https://www.facebook.com/plugins/video.php?href=https://www.facebook.com/mbckpopshow/videos/3354735674627506"
width="560" height="314" scrolling="no" frameborder="0" allowfullscreen="true"
allow="clipboard-write; encrypted-media; picture-in-picture; web-share"
sandbox="allow-same-origin allow-popups allow-scripts">
</iframe>width="560" height="314" scrolling="no" frameborder="0" allowfullscreen="true"
allow="clipboard-write; encrypted-media; picture-in-picture; web-share"
sandbox="allow-same-origin allow-popups allow-scripts">
}}}
{{{#!html
</iframe>}}}
이런 식으로 영상 등을 첨부할 수 있다.
Safari에서는 실제 지정된 영역에 상관 없이
<iframe>의 내용 전부를 뿌리는 문제가 있다. 특히 가로가 좁은
iPhone에서 이 문제가 두드러진다. 이 때문에 Safari 한정으로 <iframe>을 다른 블록 태그로 감싸줘야 하는 등 예외 처리를 해 줘야 한다.6. 관련 문서
[1]
구글 크롬의 경우 프레임 구조로 된 페이지에서 마우스 오른쪽 버튼을 눌러 보면 '페이지 소스 보기'와 '프레임 소스 보기'가 따로 나오는데 페이지 소스 보기를 하면 프레임 구조의 소스가 나오고 프레임 소스 보기를 하면 그 프레임 안에 있는 페이지의 소스가 나온다.
[2]
나모 웹에디터로 만든 페이지에서 발견되는 현상이다. 물론 소스 코드를 고쳐서 바꿀 수 있다.
[3]
악성코드나 통신 도중의 HTTP 요청 변조로 인해 본래 페이지와 유사하게 만든 가짜 페이지로 끌여들여 개인정보를 빼내는 수법
[4]
하나라도 https로 안 해놨다면 경고를 띄우거나 로딩 요청을 씹어버린다.
[5]
HTML5에서는 deprecated 되어서 CSS로 대체하는 것이 원칙이나,
YouTube를 포함한 대부분의 사이트에서는 아직까지도 널리 사용되고 있다.
[6]
네이버
스마트에디터 2.0 버전은 이 태그를 날려버리는 버그가 있어서 네이버에 올린 유튜브 영상은 전체화면으로 전환할 수 없다. 스마트에디터 ONE은 이런 버그가 없지만 기존에 작성한 글들은 여전히 전체화면이 안 된다.