현재 HTML 페이지를 만드는대
몇가지 창으로 쪼개져서 UI를 만들어 달라는 요청이 있어서
FRAME을 써야 하나, DIV 등으로 자바스크립등을 써써 요새 유행하는 XMLHttpRequest 등으로 동적으로 생성을 해야 하나..
고민 하다가 손이 좀 덜가는 FRAME을 써볼까 해서
FRAME 위에도 DIV LAYER가 달릴수 있을지 궁금해서 구글링을 하던 도중
여러 글들에서 다음과 같은 구문을 볼수 있었습니다.
Quote:
Frames are evil.
이렇게 해서 너무 궁금해져 버렸는대요, 웹에서 뭔가 할때 언젠가부터 FRAME이 금기시 되버린거 같은대요.
프레임을 쓰면 프레임 틀만 북마크해버리니 북마크 하기가 난감하더군요. 또 틀에 박힌듯한 느낌이 싫어서도 쓰지 않습니다. 언젠가부터 갑갑하게 느껴지더군요.
해상도에 따라서 다르게 보이는 것도 싫구요. 해상도에 구애되지 않는 디자인도 할 수 있지만.... 해상도가 낮은 곳에서 높은 곳에서 디자인 된 페이지를 보면, 네비게이션 바의 크기에 따라서 홈페이지 분위기가 다르게 보이는 것도 꺼려지더군요. 1024x768에서는 적당한 크기라고 생각했지만 800x600에서는 너무 크다 싶었던 적이 많았습니다.
프레임 관련 부분들은 표준에서도 Frameset으로 따로 분리되어 있습니다. 표준 만든 사람들의 의도는 그런게 아닐 수도 있었겠지만, 웬지 쓰지 말라는 의미로 느껴집니다.. :) 특별히 응용프로그램 수준으로 UI 따위를 제공하려는 웹페이지가 아니면 프레임을 안쓰는게 더 유익한 것 같습니다. 반복되는 부분을 줄이기 위함이라면, SSI 따위로 서버 쪽에서 뭉쳐서 보내주는 방법을 쓰는게 좋은 것 같고요.
최근에 frame을 쓰는 경우라면 일명 "히든 프레임"이라고 해서 주소창에 이래저래 query나오는걸 보여주지 않고 싶어하는 경우가 아니라면 거의 쓰지를 않습니다. 이런 경우에도 북마크가 문제가 되기는 하구요. 하지만 의도적으로 하위 페이지의 북마크를 막고 싶을때도 강제로 프레임을 거치도록 하기는 합니다.
하지만 상단, 왼쪽에 프레임을 줘서 메뉴를 둔다거나 하는 방식은 거의 사용하지를 않습니다. 차라리 레이어 형식으로 따라다니게 하는 경우가 많지요.
아마도 프레임은 동적인 웹페이지가 주류를 이루기 전에 어울리는 방법이 아니었을까 생각해봅니다.
논외지만 간혹 iframe을 써서 폼 전송을 처리하는 방법을 쓰기도 합니다. 그리고 iframe위로는 레이어를 올릴 수 있습니다.
프레임은 :evil:다 에 관한 아주 오래된 이야기로는, 뭐 "아직도 프레임을 지원하지 못하는 브라우져가 있기 때문이다."라는
이야기를 들은 적이 있습니다.
굉장히 오래된 이야기라서 아직도 그런 구버젼의 브라우져를 사용하는 사람들이 있을까.. 싶지만서도 세상일은 모르는거니까요.
제대로 표준을 지키지 않아서 비IE계열에서는 잘 볼 수도 없는 웹페이지들을 두고 자꾸만 수정 건의를 하는 비IE계열 브라우져 사용자들처럼 (물론 전 여기에 전적으로 동의하며 저도 보이는 족족 메일을 보내는 쪽입니다.),
혹시 이 지구상 어딘가에서 내가 만든, 프레임이 들어간 웹페이지를 잘 볼 수가 없어서 이를 가는 사람들을 위해선 가급적 사용하지 않는게 낫지 않을까요?
혹은 프레임용 웹페이지와 프레임을 사용하지 않은 웹페이지를 2개 만들어서 사용자를 배려할 수도 있구요.
이것도 어떻게 보면 웹 접근성 향상에 기여하는 일이라고 봅니다.
(그런데 어떻게 된게 기초 html 자습서들엔 온통 프레임 쓰는 법만 나와 있나 봅니다. 책을 보며 하나하나 홈페이지를 만들어가는 친구들 사이트에 들어가보면 죄다 프레임입니다.;;)
웹 페이지에 FRAME을 안쓰십니까?
현재 HTML 페이지를 만드는대
몇가지 창으로 쪼개져서 UI를 만들어 달라는 요청이 있어서
FRAME을 써야 하나, DIV 등으로 자바스크립등을 써써 요새 유행하는 XMLHttpRequest 등으로 동적으로 생성을 해야 하나..
고민 하다가 손이 좀 덜가는 FRAME을 써볼까 해서
FRAME 위에도 DIV LAYER가 달릴수 있을지 궁금해서 구글링을 하던 도중
여러 글들에서 다음과 같은 구문을 볼수 있었습니다.
이렇게 해서 너무 궁금해져 버렸는대요, 웹에서 뭔가 할때 언젠가부터 FRAME이 금기시 되버린거 같은대요.
혹시 FRAME을 쓰십니까? 쓰신다면 왜 쓰며 안쓰신다면 왜 안쓰는 겁니까?
새 생각 :)
프레임을 쓰면 프레임 틀만 북마크해버리니 북마크 하기가 난감하더군요. 또
프레임을 쓰면 프레임 틀만 북마크해버리니 북마크 하기가 난감하더군요. 또 틀에 박힌듯한 느낌이 싫어서도 쓰지 않습니다. 언젠가부터 갑갑하게 느껴지더군요.
해상도에 따라서 다르게 보이는 것도 싫구요. 해상도에 구애되지 않는 디자인도 할 수 있지만.... 해상도가 낮은 곳에서 높은 곳에서 디자인 된 페이지를 보면, 네비게이션 바의 크기에 따라서 홈페이지 분위기가 다르게 보이는 것도 꺼려지더군요. 1024x768에서는 적당한 크기라고 생각했지만 800x600에서는 너무 크다 싶었던 적이 많았습니다.
현실은 꿈, 간밤의 꿈이야말로 현실.
http://lv255.net/
http://willbefree.net/
http://netbsder.org/
문서의 구조화에도 좋지 않고,역시 내용만 북마크 해 버리게 되더군요.
문서의 구조화에도 좋지 않고,
역시 내용만 북마크 해 버리게 되더군요.
파일도 두 세개 만들어야 하니 지저분하게 널어 놓는 것 같기도 하구요.
보통 프레임을 쓰는 것이 정적인 문서들에서 메뉴 같이 중복되는 부분을 재사용하기 위해서 쓰지 않았던가요?
동적으로 페이지를 생성하는 경우는 frame이 별로 필요가 없지 않나 생각이 드네요.
저도 프레임 쓸일이 없었는데 얼마전에 애플릿 넣으면서 프레임이 필요하더군
저도 프레임 쓸일이 없었는데 얼마전에 애플릿 넣으면서 프레임이 필요하더군요.
로딩된 애플릿을 유지할려니 프레인을 안쓸수가 없드라구여
(혹시 방법이 있는데 제가 모르는건지..
프레임 안쓰고 애플릿 유지 하는 법 있나요?)
프레임 많이 쓴 사이트는 화면이 지저분하고 다루기도 불편하더군요. 그리고
프레임 많이 쓴 사이트는 화면이 지저분하고 다루기도 불편하더군요. 그리고 그냥 하나의 페이지로 다루는 것보다 디자인 상의 제약이 큽니다.
iframe의 경우에는 주의깊게 다루지 않으면 IE와 Firefox에서 내용을 제대로 확인하기 어려울 정도로 서로 다르게 보입니다. 그리고 iframe의 경우에는 스크롤이 좀 불편합니다.
표준..
프레임 관련 부분들은 표준에서도 Frameset으로 따로 분리되어 있습니다. 표준 만든 사람들의 의도는 그런게 아닐 수도 있었겠지만, 웬지 쓰지 말라는 의미로 느껴집니다.. :) 특별히 응용프로그램 수준으로 UI 따위를 제공하려는 웹페이지가 아니면 프레임을 안쓰는게 더 유익한 것 같습니다. 반복되는 부분을 줄이기 위함이라면, SSI 따위로 서버 쪽에서 뭉쳐서 보내주는 방법을 쓰는게 좋은 것 같고요.
최근에 frame을 쓰는 경우라면 일명 "히든 프레임"이라고 해서 주소창
최근에 frame을 쓰는 경우라면 일명 "히든 프레임"이라고 해서 주소창에 이래저래 query나오는걸 보여주지 않고 싶어하는 경우가 아니라면 거의 쓰지를 않습니다. 이런 경우에도 북마크가 문제가 되기는 하구요. 하지만 의도적으로 하위 페이지의 북마크를 막고 싶을때도 강제로 프레임을 거치도록 하기는 합니다.
하지만 상단, 왼쪽에 프레임을 줘서 메뉴를 둔다거나 하는 방식은 거의 사용하지를 않습니다. 차라리 레이어 형식으로 따라다니게 하는 경우가 많지요.
아마도 프레임은 동적인 웹페이지가 주류를 이루기 전에 어울리는 방법이 아니었을까 생각해봅니다.
논외지만 간혹 iframe을 써서 폼 전송을 처리하는 방법을 쓰기도 합니다. 그리고 iframe위로는 레이어를 올릴 수 있습니다.
웹서핑을해도 보이는 프레임은 본적이 전무하정도군요.
웹서핑을해도 보이는 프레임은 본적이 전무하정도군요.
프레임위에 레이어를 써서 경계를 벗어 나게 하는 경우가 참 힘들더군요..
프레임위에 레이어를 써서 경계를 벗어 나게 하는 경우가 참 힘들더군요..
레이어가 프레임에 들어 있는 부분에 종속적으로 되기 때문에 문제가 되더군요..
그래서 프레임의 구조에 상관 없이 레이어를 보여주기 위해서 사용한 방법이..
frameset 하는 페이지에 넣어주고 해결한 경우가 있습니다...
프레임도 잘쓰면 좋다는 생각이 듭니다... 그러나, 아무런 대책 없이 그냥 마구자비로 쓰는 경우는 정말 싫습니다. 그리고, 프레임 단위에서 스크립트로 넘나들면서 참조하는 경우는 더욱 짜증이 나더군요..
프레임을 쓰게 되면 좋은 점이라고 생각 하는 경우는 같은 데이터를 계속 가지 않아도 된다는 장점이 있는것 같습니다.
저도 왠만하면 안쓰려고 했으나, 쓸수 밖에 없더군요..일반 사이트
저도 왠만하면 안쓰려고 했으나, 쓸수 밖에 없더군요..
일반 사이트가 아닌, 제가 다니는 회사의 제품에 embedded 된
GUI를 만들다 보니..
무조건 안쓰자 보다는..
가능한 안쓰자 쪽이 옳다고 봅니다.
----------------------------------------------------------=>
Be supercalifragilisticexpialidocious, run for your life!
초창기부터 evil이라고 배척받았던 걸로 기억합니다. 기억엔 잘 나지 않
초창기부터 evil이라고 배척받았던 걸로 기억합니다. 기억엔 잘 나지 않지만 웹의 정신에 위배된다고 싫어했던 사람들이 꽤나 되었거든요.
개인적으로는 url을 얻기 힘든 점과 인터페이스가 불편한 점. 두가지 단점 때문에 프레임 자체를 싫어합니다.
게다가 프레임을 쓰는 홈페이지는 쓸만한 정보가 없다는 편견도 있어서 그런 홈피에는 아예 안 갑니다. (아 다나와는 예외입니다. ;;;)
- 죠커's blog / HanIRC:#CN
[quote="CN"]초창기부터 evil이라고 배척받았던 걸로 기억합니다
사견이지만 어느정도 맞는것도 같군요...
오죽하면 별명이 안나와이겠습니까...;; :)
덧 : 물론 다나와는 유용한 사이트 중 하나입니다. 좀 더 유용해졌으면...
───────────────────────
yaourt -S gothick elegant
khris'log
메뉴부분을 동적으로 생성해야 하는 경우에는 프레임을 쓰는게 낫지 않을까요
메뉴부분을 동적으로 생성해야 하는 경우에는 프레임을 쓰는게 낫지 않을까요??
프레임을 쓰지 않는다면 페이지 사이를 이동할 때 마다 메뉴도 계속 새로 생성해야
할텐데요, 이런 경우에는 프레임을 쓰는게 조금이라도 서버에 부하가 적지 않을까요?
프레임은 :evil:다 에 관한 아주 오래된 이야기로는, 뭐 "아직도 프
프레임은 :evil:다 에 관한 아주 오래된 이야기로는, 뭐 "아직도 프레임을 지원하지 못하는 브라우져가 있기 때문이다."라는
이야기를 들은 적이 있습니다.
굉장히 오래된 이야기라서 아직도 그런 구버젼의 브라우져를 사용하는 사람들이 있을까.. 싶지만서도 세상일은 모르는거니까요.
제대로 표준을 지키지 않아서 비IE계열에서는 잘 볼 수도 없는 웹페이지들을 두고 자꾸만 수정 건의를 하는 비IE계열 브라우져 사용자들처럼 (물론 전 여기에 전적으로 동의하며 저도 보이는 족족 메일을 보내는 쪽입니다.),
혹시 이 지구상 어딘가에서 내가 만든, 프레임이 들어간 웹페이지를 잘 볼 수가 없어서 이를 가는 사람들을 위해선 가급적 사용하지 않는게 낫지 않을까요?
혹은 프레임용 웹페이지와 프레임을 사용하지 않은 웹페이지를 2개 만들어서 사용자를 배려할 수도 있구요.
이것도 어떻게 보면 웹 접근성 향상에 기여하는 일이라고 봅니다.
(그런데 어떻게 된게 기초 html 자습서들엔 온통 프레임 쓰는 법만 나와 있나 봅니다. 책을 보며 하나하나 홈페이지를 만들어가는 친구들 사이트에 들어가보면 죄다 프레임입니다.;;)
--->
데비안 & 우분투로 대동단결!
저는 프레임 쓰고 있습니다. 표준이니 사용성따위를 따질 필요조차 없는 아
저는 프레임 쓰고 있습니다. 표준이니 사용성따위를 따질 필요조차 없는 아주 무책임하고 성의없는 페이지이기 때문에... 8)
http://saxboy.pe.kr
사실은 블로그와 위키와 제로보드를 프레임을 쓰지 않고 어떻게 한 메뉴에 넣을 수 있는지 잘 모르기 때문이라고나 할까요. 좀 더 근본적인 이유는 옛날 데이터들을 복사해 붙여넣기가 귀찮기 때문이지만...