XFrame과 HTML 프레임...
최근 HTML의 프레임을 대체하기 위한 XFrame 규격 작업이 한창이다. HTML은 다음과 같은 이유로 다양한 비판을 받아왔다.
- 히스토리 관련 문제: 프레임으로 나누어진 페이지에서 [앞으로], [뒤로] 등은 사용자가 생각한대로 동작하지 않는다. 사용자는 자기가 페이지를 네비게이션 한 순서대로 [앞으로], [뒤로] 하는 것을 원하겠지만 브라우저는 포커스가 간 프레임의 [앞으로], [뒤로]를 수행하게 된다.
- 즐겨찾기 문제: 프레임 페이지별 이동을 URL로 나타낼수 있는 방법이 없기 때문에 프레임 페이지의 어떤 상태를 즐겨찾기에 추가할 수 있는 방법이 없다. 추가 가능한 것은 프레임 내의 한 페이지거나 프레임 페이지의 초기 페이지 뿐이다.
- 스크롤 문제: Page UP, Page Down등을 수행하는 경우 사용자가 원하는 대로가 아닐 수 있다. 프레임 각각이 따로 스크롤 되므로 사용자는 이러한 것을 항상 신경써야한다. 이는 특히 PDA나 핸드폰과 같이 마우스가 없는 환경에서는 더욱 큰 문제가 된다.
- 검색엔진문제: 검색엔진이 찾아 낼 수 있는 것은 프레임 페이지가 아닌 프레임 내에 포함된 페이지 뿐이다. 프레임 페이지에는 아무런 내용도 없고 특정 프레임 내의 포함된 페이지가 로드된 상태를 URL로 나타낼 수도 없으므로 검색이 불가능하다.
- 보안문제: 프레임을 이용한 Cross Site Attacking 문제는 항상 문제가 되어 왔다. 예를 들어 어떤 사이트가 프레임으로 페이지를 만들고 그 페이지 중 하나를 egloos로 이동시킨뒤 사용자가 입력한 비밀 번호를 스크립트로 읽어 온다. 물론 요새는 도메인이 틀리면 접근이 안되는 방법을 사용하기는 하지만 호스팅이 많이 이루어지는 요즘 도메인이 같다고 해서 안전하다는 보장을 하기는 힘들다.
- 규격문제: 사실 프레임이 HTML 언어 내에 포함될 이유는 전혀 없다. 이론적으로 프레임 내의 페이지는 HTML뿐만 아니라 SVG, SMIL등 다른 마크업 언어나 JPG, PNG등 이미지를 포함하지 못할 이유는 없다. 따라서 HTML 언어내에 포함되는 것 보다는 별도 규격인 편이 더 낫다.
- 레이아웃문제: HTML의 프레임은 가로분할 또는 세로분할의 바둑판형 레이아웃만을 제공한다. 하지만 tabbed 형이라던지 자유형(여러 개의 팝업 같은 형태)등의 요구는 스크립트에 의해 다루어져 왔다.
그래서 이러한 문제를 해결하고자 XFrame 규격을 작업하고 있다. 물론 모든 문제를 해결하지는 못하지만...
XFrame의 가장 큰 특징은 프레임의 상태를 URL로 나타낼 수 있다는 점이다. 이러한 특징은 히스토리나 즐겨찾기 등의 문제를 해결하는데 큰 역할을 할 것으로 보인다.
---------
| a | |
|----| c |
| b | |
---------
이와 같이 3개의 프레임에 a.xhtml, b.xhtml, c.xhtml이 열려있다고 한다면 아래와 같은 URL로 나타낼 수 있다.
home.xframes#frames(one=a.xhtml,two=b.xhtml, three=c.xhtml)
여기서 one, two, three 등은 xml:id로 나타낸 프레임의 식별자이다.
XFrame 의 또 하나의 특징은 바로 레이아웃을 CSS 또는 더 적합한 언어(비록 현재는 없지만...)에게 맡겼다는 점이다. 기존에 존재 했던 크기에 대한 속성은 없어졌으며 style 태그를 통해 아래와 같이 CSS를 크기를 지정할 수 있도록 되어 있다.
#one {height: 10em }
#two {width: 20%}
#three {height: 4em }
또 한 기본적인 형태 또한 가로/세로 분할을 나타내는 horizontal, vertical 뿐만 아니라 탭 형을 나타내는 single, 자유 형태를 나타내는 free가 추가되었으며 유저 에이전트에 따라 QName을 이용해 지정할 수도 있도록 되어 있다.
과연 이러한 조치가 프레임의 문제를 모두 해결할지는... 글쎄다. 여전히 스크롤이 어렵다는 문제는 해결하지 못한다. 하지만 프레임을 URL로 지정할 수 있다는 사실 만으로도 최소한 기존 프레임 보다는 훨씬 유용해 보인다.
http://www.w3.org/TR/xframes/
- 히스토리 관련 문제: 프레임으로 나누어진 페이지에서 [앞으로], [뒤로] 등은 사용자가 생각한대로 동작하지 않는다. 사용자는 자기가 페이지를 네비게이션 한 순서대로 [앞으로], [뒤로] 하는 것을 원하겠지만 브라우저는 포커스가 간 프레임의 [앞으로], [뒤로]를 수행하게 된다.
- 즐겨찾기 문제: 프레임 페이지별 이동을 URL로 나타낼수 있는 방법이 없기 때문에 프레임 페이지의 어떤 상태를 즐겨찾기에 추가할 수 있는 방법이 없다. 추가 가능한 것은 프레임 내의 한 페이지거나 프레임 페이지의 초기 페이지 뿐이다.
- 스크롤 문제: Page UP, Page Down등을 수행하는 경우 사용자가 원하는 대로가 아닐 수 있다. 프레임 각각이 따로 스크롤 되므로 사용자는 이러한 것을 항상 신경써야한다. 이는 특히 PDA나 핸드폰과 같이 마우스가 없는 환경에서는 더욱 큰 문제가 된다.
- 검색엔진문제: 검색엔진이 찾아 낼 수 있는 것은 프레임 페이지가 아닌 프레임 내에 포함된 페이지 뿐이다. 프레임 페이지에는 아무런 내용도 없고 특정 프레임 내의 포함된 페이지가 로드된 상태를 URL로 나타낼 수도 없으므로 검색이 불가능하다.
- 보안문제: 프레임을 이용한 Cross Site Attacking 문제는 항상 문제가 되어 왔다. 예를 들어 어떤 사이트가 프레임으로 페이지를 만들고 그 페이지 중 하나를 egloos로 이동시킨뒤 사용자가 입력한 비밀 번호를 스크립트로 읽어 온다. 물론 요새는 도메인이 틀리면 접근이 안되는 방법을 사용하기는 하지만 호스팅이 많이 이루어지는 요즘 도메인이 같다고 해서 안전하다는 보장을 하기는 힘들다.
- 규격문제: 사실 프레임이 HTML 언어 내에 포함될 이유는 전혀 없다. 이론적으로 프레임 내의 페이지는 HTML뿐만 아니라 SVG, SMIL등 다른 마크업 언어나 JPG, PNG등 이미지를 포함하지 못할 이유는 없다. 따라서 HTML 언어내에 포함되는 것 보다는 별도 규격인 편이 더 낫다.
- 레이아웃문제: HTML의 프레임은 가로분할 또는 세로분할의 바둑판형 레이아웃만을 제공한다. 하지만 tabbed 형이라던지 자유형(여러 개의 팝업 같은 형태)등의 요구는 스크립트에 의해 다루어져 왔다.
그래서 이러한 문제를 해결하고자 XFrame 규격을 작업하고 있다. 물론 모든 문제를 해결하지는 못하지만...
XFrame의 가장 큰 특징은 프레임의 상태를 URL로 나타낼 수 있다는 점이다. 이러한 특징은 히스토리나 즐겨찾기 등의 문제를 해결하는데 큰 역할을 할 것으로 보인다.
---------
| a | |
|----| c |
| b | |
---------
이와 같이 3개의 프레임에 a.xhtml, b.xhtml, c.xhtml이 열려있다고 한다면 아래와 같은 URL로 나타낼 수 있다.
home.xframes#frames(one=a.xhtml,two=b.xhtml, three=c.xhtml)
여기서 one, two, three 등은 xml:id로 나타낸 프레임의 식별자이다.
XFrame 의 또 하나의 특징은 바로 레이아웃을 CSS 또는 더 적합한 언어(비록 현재는 없지만...)에게 맡겼다는 점이다. 기존에 존재 했던 크기에 대한 속성은 없어졌으며 style 태그를 통해 아래와 같이 CSS를 크기를 지정할 수 있도록 되어 있다.
#one {height: 10em }
#two {width: 20%}
#three {height: 4em }
또 한 기본적인 형태 또한 가로/세로 분할을 나타내는 horizontal, vertical 뿐만 아니라 탭 형을 나타내는 single, 자유 형태를 나타내는 free가 추가되었으며 유저 에이전트에 따라 QName을 이용해 지정할 수도 있도록 되어 있다.
과연 이러한 조치가 프레임의 문제를 모두 해결할지는... 글쎄다. 여전히 스크롤이 어렵다는 문제는 해결하지 못한다. 하지만 프레임을 URL로 지정할 수 있다는 사실 만으로도 최소한 기존 프레임 보다는 훨씬 유용해 보인다.
http://www.w3.org/TR/xframes/
