브라우저 중립적인 웹페이지 만들기?
안녕하세요. 다름이 아니라 이번에 저희 학교의 사이트가 개편중에 있는데요. 새로 만들어진 몇몇 페이지들을 보니 자바 스크립트에서 어떤 식으로 레이어들을 썼는지 피닉스나 모질라에서는 메뉴가 제대로 보이지 않더라구요. 그래서 처음에는 개선을 요구할까 했는데, 실은 제가 개발자분들과 좀 친한 관계로 굉장히 바쁜-여기 업무가 좀 그렇습니다.-분들임을 알고 있고, 만약 요구한다고 해도 모질라에서 접속하는 사람은 이 학교에서 단지 저 뿐이라(게다가 지금은 윈도를 씁니다) 아무래도 IE쓰라는 말만 듣고 묵살될 듯 싶었습니다. 그래서 제가 자원해서 직접 문제를 해결하는 방향으로 가려고 했으나 막상 HTML 코드들을 보니 또 막막하더군요...
솔직히 어디가 문제인지 전혀 모른다는 게 문제였습니다. HTML 코딩은 늘 수작업으로 해왔던 저인지라 테이블 같은 거야 아무것도 아니지만, 곳곳에 삽입되어 있는 자바 스크립트는 정말로 할말 없게 만들더군요. 자바 스크립트는 웬만하면 대충 퍼와서 썼기 때문에 예전에 배운 것들은 다 까먹어버렸고, 그나마 레이어는 배우기 골때리니 퍼서 써라... 라는 소리 듣고 넘어가버려 전혀 모릅니다. 이런 상황이니 넷스케이프의 자바 스크립트 레퍼런스는 고사하고 자바 스크립트부터 다시 배워야 할 상황이구요.
이런 상황에서 여러분들께 여쭙고자 하는 것은 혹시 저와 같은-NS 혹은 모질라에게도 사이트를 제대로 보여주고자 한-경험이 있으셨다면 어떻게 그 일을 처리하셨는가 하는 것입니다. 국내의 IE 전용 사이트들에 메일을 보내고 문제점을 찾아 지적하기도 하셨던 분들의 이야기를 전에 게시판에서 본 기억이 있기 때문에 이 글을 올리는 거구요. 제가 알고자 하는 것은 보다 좋은 방법입니다. 노하우, 사이트, 레퍼런스, 디버깅 툴 등 그 어떤 것이라도 좋습니다. 사이트 라는 것은 자바 스크립트를 나열해 놓고 NS용과 IE용을 잘 구분해 놓은(물론 한글이면 좋겠죠;) 사이트나 커뮤니티를 기대하는 것이구요. 지금 제가 하듯이 영문 레퍼런스 사이트와 오라일리의 책들에만 의존하는 것은 완전 노가다... 돌려서 말하자면 제 조그마한 열정이 감당하기에는 너무 무서운 일 같아서 말입니다. -_-; 사실 어느 분에게나 마찬가지일 것이라고 생각합니다.
그럼 많은 답변 기대하겠습니다.
추신 1 : 쓰다보니 적당히 횡설수설이 되었는데, 아무쪼록 많은 답장 부탁드립니다. 그렇게 된다면 물론 이 페이지만으로도 하나의 소중한 문서가 되겠지만, 만약 제가 도움을 얻어 이 일을 제대로 마칠 수 있다면 이런 일을 하는 프로젝트건 HOWTO문서건 간에 어떤 식으로든 환원하겠습니다.(꼭 대선 공약같군;)
추신 2 : NS보단 모질라의 이야기를 부탁드립니다. 특히나 늘 이런 이야기만 했다 하면 등장하는 NS4는 이제 어떤 식으로건 고려 대상이 되지 않는다고 생각합니다. 뭐 전혀 현실성도 없다고 보구요.
추신 3 (잡담): 앞의 글에서 다소 의문을 가지시는 분이 계실 지도 모르겠는데, 사실 제가 몸담고 있는 학교란 정확히는 공공기관이고 매우 특수한 상황에 놓여 있는 곳입니다. 그 특수성 때문에 2년전 처음 여기를 들어올때는 어쩌면 한국에서 최초로 모든 데스크탑에 리눅스가 깔릴지도 모른다는 상상을 하기도 했고, 지금도 그 꿈은 많이 퇴색되긴 했지만 여전히 가지고 있기에 자꾸만 이런 일을 하게 되는 것 같습니다. 물론 이 일은 저 아래 작업실에 나란히 놓여 있는 10여대의 맥들에 모질라를 깔기 위한 것이기도 하지만 말입니다. ^^;
댓글
저는 현실적으로 어느 정도의 인지도가 있는 브라우저들이라고 생각됩니다.
저는 현실적으로 어느 정도의 인지도가 있는 브라우저들이라고 생각됩니다.
기본적으로 IE 5.x, IE 6.x 가 포함될거구요.
넷스케이프 4.x는 더이상 홈페이지에서 조차도 구할 수가 없기때문에 대상에서 제외가 되어야 된다고 생각됩니다.
6.x, 7.x 에서 제대로 되면 된다고 생각하구요..
Mozilla 를 기반으로 했으므로 O/S에 따라 차이가 있겠지만 크게 문제가 안될 것 같네요..
Linux 용 컨커러..(영어 이름을 정확하게 모르겠네요..) 와
Mac 용 IE (이거.. 윈도우용이랑 다르다고 들었는데 실제로 써본적은 없네요..)
Opera는 6.x 와 7.x (아직 베타죠..) 정도..
이정도 고려하면 되지 않을까 싶네요..
좀 뒤늦은 답글이지만제가작업해본결과 모질라,넷스,익스 등에서
좀 뒤늦은 답글이지만
제가작업해본결과 모질라,넷스,익스 등에서
꾀 정확하게 같은값으로 설정한바를 보여줄수있는
일련의법칙 따위가 있습니다.
아주 미묘하고 아슬아슬한 경계지만 말입니다.
팁이라면 해결방법으로 CSS가 위에 많이 제시되고
있습니다만, '택'도 없으니 CSS는 그냥 폰트
크기정도의 서포트라고 생각하시는게 속 편합니다.
약간의속성값정도는 조금더 먹힙니다만, 그게 그거죠.
실제로 잘 먹히진 않거든요, 범용으로서는.
남는건 HTML인데 테이블이 관건입니다.
내부테이블없이 한개채로이루어진테이들만으로
하나의페이지를 작성할수있는것에 관건이
있습니다.
이것은 대략적으로 몇개월간 HTML,CSS등
DHTML과 삽질을하면서 얻어낸 결과값입니다.
결과는 물론예제소스로서 유용하게 저장이되어있고
현재로서도 필요하면 참고하고 꺼내쓰고있지요..
이런식으로 좀 힘들더라도 작업하다보면 자기의
포트폴리오가 만들어집니다,그 후엔 일련의규칙이
대략적으로 눈에 보이니 작업의 능률이
훨씬 늘어나지요.물론 몇달동안 관련레퍼런스까지
참조해가면서 정말고생했습니다만...
간단하게 위지위그로도 할수있겠지만 소스가
너무지저분해지고 방대해집니다. 어느정도규모의
커뮤니티만되도 당연히 실격이죠. 트래픽이
너무 나오기 때문에.. 요는 최소한의 용량으로
최대한을 표현하면서 범용성을 실현하면되는것입니다.
자바스크립트를사용하는순간부터 범용성을 바라는것은
포기하시는게 좋구요 한 페이지로 모든 웹브라우저에서
거의 절대적인 호환성을 가진 것을 만들고싶으시다면
대부분 HTML에 매달리시는게좋을겁니다. CSS도
의외로 몇줄덜어주는 정도밖에는 도움이 안되거든요.
계속작업하다보니 원점은 HTML로 돌아가더군요.
-_-;내공을 좀 더 쌓으셔야겠네요. 자신이 못한다고 해서 안되는
-_-;
내공을 좀 더 쌓으셔야겠네요. 자신이 못한다고 해서 안되는 게 아닙니다.
여러 브라우저 지원이 되어야 한다는 사항은 맞겠습니다만,어느선까지가
여러 브라우저 지원이 되어야 한다는 사항은 맞겠습니다만,
어느선까지가 옳은 것일까요? 가령 위 사이트와 같은 곳의
스펙에 브라우저 지원 사항을 추가한다면...
1. MS IE 3.x, 4.x, 5.x, 6.x
2. Netscape 2.x, 3.x, 4.x
3. Mozilla 1.0, 1.1, 1.2, Netscape 6.x, 7.x
4. Opera (버전을 잘 몰라서... ^^)
5. lynx, links, w3m, w4등의 텍스트 브라우저
물론 다른 관점에서 볼 수도 있겠네요. HTML 4.0, DOM
지원이라든가 Javascript/JScript 버전이라든가...
또한 플랫폼도 문제가 됩니다. Windows 95, 98, ME, NT4,
2000, XP, Linux(2.0, 2.2, 2.4), FreeBSD(2.x, 3.x, 4.x,
5.x), Solaris(1.x, 2.x), AIX, HP-UX, IRIX, MacOS 9.x,
10.x 등등...
각 브라우저 뿐 아니라 버전간에도 미묘한 호환성 문제가
있는 것으로 압니다만, 과연 어느정도 선까지 지원이 된다면
최대한 많은 사람들을 만족시킬 수 있을까요?
단순히 IE와 모질라서에서만 잘 보이면 된다는 정도가 아니라...
p.s. 글을 올리신 분은 IE5, Mozilla 1.0, Windows, Linux가
그 범위라고 생각하시는것 같군요.
--
익스펙토 페트로눔
Amaya를 빼놓으면 이야기가 되지 않을 듯 합니다.Amaya는 W3
Amaya를 빼놓으면 이야기가 되지 않을 듯 합니다.
Amaya는 W3C에서 정한 표준을 어떻게 나타내어야 하는지를 보여주려고 만든 웹브라우저입니다. 또한 웹에디터이기도 합니다.
글쓴이입니다. 진작 마무리 글을 올렸어야 하는데 주제가 메인에서 떨어질
글쓴이입니다. 진작 마무리 글을 올렸어야 하는데 주제가 메인에서 떨어질 때까지 방치(?)해 왔군요. 반성합니다. 사실 그동안이 인터넷에서는 거의 근신하다시피 한 기간이었는지라...
우선 학교 홈페이지 문제는 해결 반 미해결 반 입니다. 즉 문제가 된 부분과 해결책까지는 알아 냈다는 건데, 앞에 적었다시피 가장 간단한 방법으로는 if NN식입니다. 문제는 if NN4 가 반드시 if mozilla는 아니라는 거지요. 전에 어느 분이 NN7 나왔다는 글 보고서는 if문 늘어나니 그만 좀 나오라는 말을 하셨던 것 같은데, 무슨 의미인지 깨달았다고나 할까요 -_- 심지어 어떤 사이트는 if opera까지 버전별로 명시해 놓았더군요.
그래서 생각하기를, 차라리 두 개로 나누어서 가는 편이 낫겠다 싶어서요. 한편으로는 아예 표준대로 완전히 새로 짜서 가기로 하는 방법인데, 때마침 자바 스크립트 1.5(모질라, IE6에서 지원)도 나오고, 2.0소식도 들려오고 하니 공부할 흥미도 생기구요. 다른 한편으로는 텍스트 기반 페이지를 만들어서 lynx~NN4(IE5?)까지 지원을 해 나가는 것이지요. 생각해보니 이 방식이 가장 현실적이더군요. 개발자분과 최근에 허심탄회하게 이야기 할 기회가 있었는데 뜻밖에 생각이 통해서, 제가 작업을 할 경우 얼마든지 지원을 해 주시겠다고 합니다.
휴... 그럼 이제 한 걸음인가요. 원래 이 일을 끝내면 IE전용 사이트를 뚝딱뚝딱 무료로 고쳐주는 프로젝트라도 할 생각이었는데, 시간 관계상 쉽지가 않겠더라고요. 여기 달린 쓰레드로 보아 예상보다 반응도 적고, 참여해 주실 분들도 확실치 않아서... 일단 HOWTO문서라도 내놓고 볼 생각입니다. 내용은 주로 바꾸어야 할 이유와 어디까지 고려되어야 하는지, 그리고 기술적인 문제들과 디버깅시 고려해야 할 사항들, 참고자료의 요약이 되겠지요. 쓰면서 필요하다 싶은 만큼 계속 늘릴 거구요. 여기서 답변 달아주신 분들의 글들은 좋은 참고자료 되겠습니다 ^^
그럼 여기서 매듭을 지을까 합니다. 답변 달아주신 분들 모두 감사드리고요. 즐거운 하루 되시기를 바랍니다!
MS가 윈98 부텀 윈도우탐색기와 익스를 혼합시키믄서 OS 대비 웹브라우
MS가 윈98 부텀 윈도우탐색기와 익스를 혼합시키믄서 OS 대비 웹브라우저의 사용빈도를 독점하믄서...
소위 Global을 표방하는 큰규모의 회사의 웹마스터(master란 칭호를 아무데나 써서 좀 웃기지만...)들의 고민이 시작되었을 겁니당.. 그전엔 익스페이지 넷스페이지 따로 썼고 스크립트 학습서를 봐도 꼭 등장하는 예제였던걸로 기억하네요...
노가다하믄서 열씸 페이징 해보고 2000년에 느낀건데요... 제약이 많은 쪽 환경에 맞춰서 코딩을 하는 방법 뿐이 없을 거란 생각이 드네요... 대신... 익스에서만 쓸수 있는 스크립트라든지 등등을... 다른방식으로 구현하는 한이 있어도 말이죠...
윗사람들이 보기에 껍데기도 껍데기지만.. 익스에선 되는데 넷스에선 안되면... 욕먹겠죠? -_-;
ps: web은 그림이나 잘라서 툭툭 던져주는 디자이너들의 밥줄이라 생각하지마라...
제약이 많은 쪽은 버전마다 차이점이 있는 것 같습니다. 단순히 표준만을
제약이 많은 쪽은 버전마다 차이점이 있는 것 같습니다. 단순히 표준만을 가지고 따지면 가장 구식의 브라우져는 익스플로러가 미약했고 조금 구식은 넷스케잎이 미약했고 최신예 브라우져들은 익스가 미약한것 같습니다.
그렇지만 기본적인 레이아웃을 위한 표준들은 둘다 지원하는 것 같더군요. css같은 것을 잘쓰고 "표준"을 쓰는것이 해법이지 않을까 생각합니다.
--
Lit.
L.I.T
''웹은 몇년후쯤이면 쇠퇴할것임이 자명하기에 그때까지 걍 편하게 작업
''웹은 몇년후쯤이면 쇠퇴할것임이 자명하기에
그때까지 걍 편하게 작업하시는게..''
근거 자료좀 어디있는지 알려 주시지요.
참고 좀 하게요.
태클아닙니다.
나올 애기는 다 나온것 같네요.validator.w3.org, css
나올 애기는 다 나온것 같네요.
validator.w3.org, css, xhtml
웹은 몇년후쯤이면 쇠퇴할것임이 자명하기에
그때까지 걍 편하게 작업하시는게..
프로토콜이 바뀌거나, 구현기술이 바뀔수는 있겠지만, 웹이 몇년후
프로토콜이 바뀌거나,
구현기술이 바뀔수는 있겠지만,
웹이 몇년후 쇠퇴할것이라고는 결코.. 생각하지 않습니다.
웹 이후에는 무엇이 나올까요? 궁금합니다~요걸로 포럼을 하나 만들
웹 이후에는 무엇이 나올까요? 궁금합니다~
요걸로 포럼을 하나 만들어도 될 듯~~
과연 웹을 뒤엎을 무엇이 나올까~~
아니면 뒤엎진 못해도 어떤 대체 개념으로 발표되는 것들은 어떤 것들이
있는지요?
개인적으로는 Flash Remote와 XUL이 가장 관심이 갑니다.전
개인적으로는 Flash Remote와 XUL이 가장 관심이 갑니다.
전세계 사용자가 다 익스를 쓴다면 닷넷이 될지도 모르겠군요 ㅡ.ㅡ;;
html문서는 w3c에서 표준을 정해놓고 있습니다.그러나 각 브라우져
html문서는 w3c에서 표준을 정해놓고 있습니다.
그러나 각 브라우져사마다 이러한 표준뿐만 아니라
자신의 고유의 표현문법을 다시 만들어 사용하고 있습니다.
가장 대표적인것이 MS사의 IE입니다.
지금은 그의 입지도가 커서 자기네 맘데로 만들어서 사용하는 코드들이 많습니다.
스크립트 또한 마찬가지구요.
그래서 모든 브라우져에 모두 표시 되도록 만들려면
각브라우져에서 공통으로 지원되는 코드들만을 사용해야 합니다.
각 브라우져마다 많은 테스트를 해봐야 겠습니다만
가장 기본적인 문법으로 자신만의 틀을 만들어야 할 것 같습니다.
저는 나름대로 정리해서 사용하고 있습니다.
아래 주소에서 HTML 기초부분을 참고 하시면 좋을듯 하네요.
http://javacenter.co.kr
여기가 제게 운영하고 있는 사이트 입니다.
좀 오래 되긴 하였지만 일일이 테스트 해서 정성
껏 만든 자료들 입니다.
조금이라도 도움이 되셨으면 좋겠네요.
http://kz.mpecc.com/pa/How to ... Them
http://kz.mpecc.com/pa/
How to ... Them Up
해결책은 아니고 현재 IE 판으로 돌아가는 현실에 대한 얘기가 있군요.
참고하세요~http://www.xs4all.nl/~ppk/js/i
참고하세요~
http://www.xs4all.nl/~ppk/js/index.html?version5.html
지금 저는 혼자서 사업할려고 작업 중입니다. 당연히 수익을 많이 낼려
지금 저는 혼자서 사업할려고 작업 중입니다.
당연히 수익을 많이 낼려고 모질라에 대한 고려를 하면서 작업하고 있습니다.
주관적인 느낌에 모질라가 다시 일반화되고 있습니다.
그런데 모질라를 사용하면서 느낀 것은 시간이 지날수록
차즘 익스플로화 된다는 것입니다.
이전에 네스케이프에서 다르게 나오던 것들이 차츰 사라지고 익스플로에 맞추어 지고 있다고 보입니다.
결국 작업자 입장에서는 별로 신경 쓸 것이 없어지지만 엉터리 표준화(?)를 따라 가는 것이 아쉽습니다.
본론으로 들어와 다시 이야기 하면,
1. 스타일 시트를 많이 사용한다.
- 일단 디자인 적인 요소는 CSS로 처리하는 것이 좋겠습니다.
하기야 CSS의 목적이 그것이니까요.
그것을 떠나 일단 자바 스크립트 같이 에러가 나지 않으니 참 좋습니다.
2. 자바스크립트로 처리 가능한 것 중에서
웹스크립트 언어가 처리할 수 있는 것들은 최대한 웹스크립트 쪽으로 넘긴다.
요즘 대형 사이트들고 자바스크립트 에러가 많이 나더라구요.
부하 보다는 안정적인 서비스죠!
3, 웹에디트를 사용하는 경우 '나모' 권장합니다. 경험적으로 나모에서 작업한 것들이 가장 안정적으로 문안하게 나오더라구요.
저와 비슷한 경험을 갖고 계시군요. 전문 HTML 코더 분들이 하지 말라
저와 비슷한 경험을 갖고 계시군요. 전문 HTML 코더 분들이 하지 말라고 하는 짓을 했습니다.
무슨 짓이냐고요? 학원에서 좋은 홈페이지를 만들려면 프론트 페이지나 나모는 사용하지 말라고 하더군요. 그러면서 자기들은 IE 전용 페이지를 만들죠. ㅡ.ㅡ;
확실히 현역 홈페이지 제작자가 학원 강사로 뛰고 있는 학원의 수업은 수준이 높은 듯 합니다. 하지만, 언제나라고 해도 좋을 만큼 IE 전용 페이지만 만들더군요.
그래서 저는 그분들이 하지 말라는 짓 - 프론트 페이지나 나모 웹에디터로 편집하기 등 - 을 했답니다. 프론트 페이지나 나모를 사용하면 좀 엉성한 페이지가 나오지만, 테이블에서 파라메터 하나하나까지 지정하게 되니까(저는 절대 초기값을 그대로 쓰지 않습니다. 초기값과 제가 원하는 값이 같더라도 하나하나 지정하죠.) IE와 NS 양쪽에서 모두 보이더군요.
또한 프론트 페이지도 나모도 그리고 다른 웹에디터도 모두 웹브라우저가 IE뿐이라는 생각으로 만들지 않으니까 오히려 여러 브라우저를 지원해야 할 경우에는 뜻밖에 많은 도움을 받을 수 있습니다.
또한 이미 만들어진 페이지도 나모나 프론트 페이지에서 불러와 다시 저장하면 약간씩 변형이 됩니다. 위지윅 웹에디터의 단점이지만, IE 전용 페이지를 NS에서도 볼 수 있게 고칠 때에는 도움이 되더군요.
나모를 사용하지 말라고 하는 건 브라우저 호환성 문제가 아닙니다.브라
나모를 사용하지 말라고 하는 건 브라우저 호환성 문제가 아닙니다.
브라우저 호환성 이전에 태그가 개떡이 됩니다.
뭐... 더 하시다 보면 알게 되겠죠. 나모란 게 어떤 물건인지.
개인홈페이지가 아니라 직업적으로 하실 거면 나모는 사용하지 않으시는 게 좋을 겁니다. 혼자서 취미삼아 개인 홈페이지만 만들고 사실거면 나모만큼 좋은 건 없습니다.
브라우저 호환성이 아닌 개떡이 되는 태그 때문에 사용하지 말라는 말은 이
브라우저 호환성이 아닌 개떡이 되는 태그 때문에 사용하지 말라는 말은 이해하며, 알고 있는 문제입니다.
그러나 나모를 사용하는 일은 개떡이 되는 태그와 브라우저 호환성 가운데 하나를 선택하는 일이라고 생각합니다.
제가 분명히 윗글에서 밝히고 있습니다.
나모를 포함한 위지윅 웹에디터가 소스를 마음대로 수정하는 단점을가지고 있다고. 물론, "약간"이라고 했지만, 사실 HTML 문서에 따라서는 어처구니 없을 정도로 바꾸기도 합니다.
PS>
취미삼아 개인 홈페이지만 만들고 살 생각은 없습니다.
드림위버가 낫지 않을까요? 호완성문제나 레이아웃문제나 다른 도구보다는 낫
드림위버가 낫지 않을까요? 호완성문제나 레이아웃문제나 다른 도구보다는 낫더군요. :-)
--
Lit.
L.I.T
슬라이드 메뉴가 어떻게 구성되어 있지요? 혹시 작업 진행 중에 막히시는
슬라이드 메뉴가 어떻게 구성되어 있지요? 혹시 작업 진행 중에 막히시는 부분들을 좀 더 구체적으로 올려주시면 도움이 될 지 모르겠습니다.
그럼...
냠... 답글을 잘못 달았네요. 죄송 :)
냠... 답글을 잘못 달았네요. 죄송 :)
드림위버 4 이상에서부터는.HELP 메뉴에 자바스크립트와 HTML
드림위버 4 이상에서부터는.
HELP 메뉴에 자바스크립트와 HTML의 크로스(?) 레퍼런스를 가지고 있습니다 타겟 브라우저를 지정하는 것도 기능은 기능이지만, 그 보다 명확히 지원 브라우저와 버전이 명시되어 있어서 썩 편하게 찾아볼 수 있죠. 원전은 역시 오렐리라는 군요.
사실, 쓸데없고 별로 예쁘지도 않으면서 CPU 점유율만 높이는 허접한 데코레이숑~으로서의 IE 기능은 디자인 측면에서도 많이 지양되야 합니다. 아예 IE 전용 임베디드 컴포넌트들이라면 사정이 다르지만. 단순히 DOM 모델이라면, 디자인 컨셉을 잘 잡는 것만으로도 거품을 걷어낼 수 있지요.
또 하나. 요즘엔 줄어드는 추세지만, 웹 기술에 대한 이해나 HCI까지는 들먹이지 않더라도 사용자 인터페이스에 대한 개념이 없는 전적으로 artist 로서의 주장만 일삼는 순수 디자이너들의 어이없이 창의적인(?) 디자인도 경계해야지요. art 와 민감한 관계가 있는 싸이트라면 모를까... 뭐 물론 창의적인 것은 언제나 좋습니다. 그러나 WEB 자체에 대한 더 본질적인 이해를 가지고 나서의 문제이지요. 기계 설계도 design 이라고 하듯이. 웹 디자인은 화면을 폼빨나게만 하는게 아니라, 폼도 나고 UI 나 네비게이션도 편안하도록 설계하는 것까지 포함되어있다는 초등학교적 진리를 뻔하지만 자꾸자꾸 생각해야 합니다.
한 번은 알바로서, 주로 웍스테이션 사용자들을 위한 서버어플리케이션의 웹 UI 를 작업한 적이 있었는데, 아예 시작 단계부터, 디자인 단계부터 염두를 하고 개발했더니 썩 괜찮은 개발 효율이 나오더군요. 그리고 넷스로는 만들기 불편한 것들을 포기하면서, 오히려, 어이없는 데코레이션보다 더 편안한 UI 구성에 디자인의 컨셉이 자연스럽게 가더란 말입니다. IE기능을 생각하면 정말 쓸데없는 장난감만들어놓고 오~~ 자아도취하다가 진도도 안 빠지고 그 많은 시간을 허비하던것을 깨닫게 되더란 말이지요. EIS 관련하여 VB 쪽 연동하여 리모트컨트롤 사용하는 개발 싸이트를 본 적 있었는데, 궁극에는 "이런 것도 해줘요"를 한아름 받아가더니, 처음에 그 프로젝트의 본질적인 목적에 충실한 웹 UI 인가? ..하는데 의문을 가진적도 있었구요..
머, IE 전용 페이지의 마이그레이션이라면 막대한 삽질이 발생하겠지만 ㅡ.ㅡ;;; 그 때 저는, GD 를 사용하다가 느려서, 애플릿 + 애플릿을 제어하는 자바스크립트 함수 버튼을 사용하였는데, 해보고나니까, 어지간한 것들은 "역시 귀찮니즘만 극복하면" 넷스에서도 할 수 있다는 게 결론이었습니다. ㅡ.ㅡ;;; 뭐, 사용자가 현란한 리모트 그리드 같은 것들을 구구절절 요구하면 좀 깝깝시럽겠지만서도... 이런 국소 인터넷의 엔터프라이즈 특정 요구가 아닌, 광역 인터넷의 서비스라면....... 뭐..
아...역시...귀차니즘을 극복하기란...-_-;;
아...역시...귀차니즘을 극복하기란...-_-;;
보통 저는 호환성이 없는 페이지를 보면,쓰레기라 칭합니다.연세
보통 저는 호환성이 없는 페이지를 보면,
쓰레기라 칭합니다.
연세대학 홈페이지도 이미 쓰레기로 전락했습니다.
최근 출강하고 있는 세명대학의 홈페이지도 쓰레기 요소가 있습니다.
국내 몇몇 연구기관의 홈페이지도 쓰레기 입니다. 또한 정부 홈페이지도 그와 같은 요소들을
많이 갖고 있습니다. 더불어 제가 속한 대한 의용 생체 공학회 홈페이지도 쓰레기 덩어리
입니다.
제가 지금 언급한 곳들에 해당하는 곳은 적어도 언어/하드웨어/소프트웨어에 독립적인
정보 제공을 해야하고, 구현할 수 있음에도 불구하고, 우리 나라의 경우 웹 개발자들이
아무 생각없이 수주하고 개발합니다.
저희 학교의 수장급들 분도 호환성을 고려하기 보다는 자신의 책상에 있는 컴퓨터에서
화려하고 뽀대가 나는 홈페이지를 보기 원합니다. 그 내용에는 관심이 없습니다.
일단 만들어지면 내용에는 생각이 없습니다.
이러한 문제로 쓰레기를 갖다 버릴 생각을 전혀 못하고 있는 것이 아닌가. 생각합니다.
--
임택균.
임택균.
쓰레기다 뭐다 하시기 전에 접속통계나 한 번 보시죠.대부분의 사이트가
쓰레기다 뭐다 하시기 전에 접속통계나 한 번 보시죠.
대부분의 사이트가 방문객의 99% 이상이 익스입니다.
세상엔 장애인보다 비장애인이 많습니다.단순히 숫자로 말할수 없는게
세상엔 장애인보다 비장애인이 많습니다.
단순히 숫자로 말할수 없는게 많지 않나 싶습니다.
"개인 사이트"가 아닌 관공서 사이트에서 한다면 정말 어이없는 일이고 상업적인 사이트들도 "오프라인"이었다면 그 1%도 잡기 위해서 노력했을겁니다.
마인드가 부족하다고 밖에 말할수가 없지요.
--
Lit.
L.I.T
답답하군요. 저는 그 홈페이지들이 지향하는 바가 무엇인지를명확히 하여
답답하군요. 저는 그 홈페이지들이 지향하는 바가 무엇인지를
명확히 하여야하는데, 그러지 못하였기에 쓰레기라 지칭한 것입니다.
1%를 위해서도 필요한 것이고, 그러지 못하였다면 쓰레기 입니다.
물론 개인적인 평가 입니다. 이렇게 답글을 달고 싶다면 저를
보러 오시지요.
--
임택균.
임택균.
택균님의 의견에 100% 동의합니다.최근에 상당 시간을 사이트 관리자
택균님의 의견에 100% 동의합니다.
최근에 상당 시간을 사이트 관리자들에게
메일 보내는데 투자합니다.
- 랍스터 -
저같은 경우엔 디자인하면서 익스랑 모질라 두개를 띄워놓고 삽질-_-을 합
저같은 경우엔 디자인하면서 익스랑 모질라 두개를 띄워놓고 삽질-_-을 합니다;
저장된 페이지를 두 브라우저로 열어보고.. 한군데라도 잘 안먹히는 부분이 있으면 또 다르게 구현(??)해 보고.. 또 안먹히면 아예 디자인 자체를 바꾸게-_-;
(그러다 보니 허접하단 소리를 자주 듣습니다.. 훌쩍..)
보통은 그렇게 하고, 자잘한 문법검사 좀만 해주면 문제 없이 돌아가더군요.
단지 시간이 너무 걸리는게 문제긴 합니다..;
음.. 어쩌다보니 저도 횡설수설-_-)
하나의 페이지를 여러 브라우져에 중립적으로 만들려면 힘이 들 것 같습니다
하나의 페이지를 여러 브라우져에 중립적으로 만들려면 힘이 들 것 같습니다. -_-"
그래서 방법은 대문에서 스크립트를 이용해서 사용하는 브라우져가 무언지 분별한 다음에
각 브라우져에 맞는 페이지로 바로 전환되게 하면 될 것 같습니다.
하나의 브라우져에 맞춰서 하나 만든 다음에
그 문서들을 그대로 다른 이름으로 복사한 다음에
다른 브라우져에 맞춰서 수정하는 것이지요. -_-"
방법이 넘 허접한가요. ^^
브라우저 중립적인 홈페이지를 만드는 것의 핵심은 CSS입니다. CSS를
브라우저 중립적인 홈페이지를 만드는 것의 핵심은 CSS입니다. CSS를 잘 활용하면 IE부터 lynx까지 커버하는 홈페이지를 만들 수 있습니다.
http://www.digital-web.com/tutorials/tutorial_2002-06.shtml
되도록이면 최대한 내용과 디자인을 분리해서 내용은 HTML만으로, 디자인은 CSS만으로 처리하는 것이 좋습니다.
몇가지 도움이 될만한 링크 몇개...http://www.mozil
몇가지 도움이 될만한 링크 몇개...
http://www.mozilla.org/start/1.0/demos.html
http://www.meyerweb.com/eric/css/edge/index.html
http://www.glish.com/css/
http://www.bluerobot.com/web/layouts/
http://www.thenoodleincident.com/tutorials/box_lesson/boxes.html
이 사이트가 많은 도움이 되지 않을까 합니다.http://www.
이 사이트가 많은 도움이 되지 않을까 합니다.
http://www.webstandards.org/
그리고 W3C의 표준 문서들도 아주 잘 쓰여져 있습니다. 원서 보기가 버거우시다면 번역본도 있습니다.
http://trio.co.kr/webrefer/html/cover.html
http://trio.co.kr/webrefer/css2/cover.html
http://trio.co.kr/webrefer/xhtml/overview.html
예전 Netscape 7.0이 나왔다는 글에서 IE와 NS진영의 싸움이
예전 Netscape 7.0이 나왔다는 글에서 IE와 NS진영의 싸움이 꽤 있었죠. :-) 이 글도 결국에는 그런걸 유도하는게 아닐까 하는 생각이 듭니다.더이상 이런 주제로 이야기 하고 싶지는 않는데 말입니다.
ps. 중립적인 웹페이지.. 만들고 싶으면 만드세요. 여기에 그런걸 토론주제로 적을것 까지는 없습니다.
흠. :-( 그런 의도는 전혀 없었는데요. 언급하신 글이 올라왔을 때 전
흠. :-( 그런 의도는 전혀 없었는데요. 언급하신 글이 올라왔을 때 전 내용들이 너무 뻔할거라 생각해서 별로 눈여겨 보지 않았습니다만, 지금 님께서 그런 식으로 물으시니 조금 의아합니다. IE vs NS라... 개인적으로 토론 주제로는 별로 맘에 안 드는군요. 시기상 이미 제 머릿속에는 부정적으로 명쾌한 답이 있으므로 그렇거니와, 또 '그렇게 싸움나서 얻을 게 뭐가 있지?' 가 제 솔직한 심정이니까요.
반면에 그러시는 님이야 말로 그렇게 돌려서 제게 말하고자 하셨던 바는 '현실을 직시하라'와 같은 것은 아닐까 하는 생각이 듭니다. 만약 그렇다면 충고는 감사합니다만, 전 개인적인 불편함을 해소할 수 있는 선에서 해소하고자 하는 것이니 그런 의미는 두지 말아주시면 좋겠군요. 더구나 그 과정에서 도움도 얻고, 또 저같은 다른 사람에게 도움을 줄수 있는 더 생산적인 일이 될 수 있다면... 뭐 해가 될 것은 없지 않겠습니까? 그간 리눅스-엔드-유저계(?장황하군요)에서 좀 뒹굴다 보니 제가 지금 하는 생각이나 행동을 이미 해 온 분들을 많이 봐서, 그분들이 서로 힘을 합치면 좋겠다는 생각을 줄곧 해온 것이 글을 쓴 원인이 되기도 했구요.
다만 제 글재주의 한계 때문에, 보시다시피 본문이 저렇습니다 ㅡ,.ㅡ 이는 너그러운 이해를 바랍니다.
추신 :
원제는 바꾼다는 것이었는데, 만들기가 되어버려서 그런지 다들 페이지 새로 짜는 방법을 가르쳐 주고 계십니다 ㅜㅜ... 개인적으로 좋아하는 CSS는 물고기 책을 참고중인데, JS의 롤오버까진 몰라도 슬라이드 메뉴에는 대안이 못 되네요... 안타깝습니다.
본문의 의도를 잘못 파악하고 계신 것 같습니다. "학교 사이트를 개편하는
본문의 의도를 잘못 파악하고 계신 것 같습니다. "학교 사이트를 개편하는데 모질라/넷스도 지원하고 싶은데 어떻게 하는 것이 좋을까?"라는게 어떻게 "과연 모질라/넷스를 지원해야 하는가?"로 해석이 될 수 있는지 궁금하군요.
설사 그렇다고 하더라도 토론 주제로 못올릴 것도 없다고 봅니다.
저는 "이 글도 결국에는 그런걸 유도하는게 아닐까 하는 생각이 듭니다."
저는 "이 글도 결국에는 그런걸 유도하는게 아닐까 하는 생각이 듭니다." 하고 말했습니다. 이글의 의도를 잘못 파악하고 있지 않습니다. 초등학교 제대로 나왔으니까요. 님이야 말로 제 문장의 의미를 제대로 파악하지 못하고 계신것 같군요. :-) ㅋㅋ
본문의도는 기술적인 측면에 대한 질문인데, 의도적으로 왜곡하고 계신듯.
본문의도는 기술적인 측면에 대한 질문인데, 의도적으로 왜곡하고 계신듯.
그 이전에 통신예절부터 지키셔야겠는데요? 초등학교 안 나온 사람처럼 보이는군요. :(
{R}
예~ 예~ 예~알았으니 그만 합시다. 더이상 이문제갖고 왈가불가 하고
예~ 예~ 예~
알았으니 그만 합시다. 더이상 이문제갖고 왈가불가 하고 싶지 않네요.
님도 그렇죠? :-)
도대체 무슨 글이길래 가려졌나 했더니..꽤나 건방진 님이시군요..
도대체 무슨 글이길래 가려졌나 했더니..
꽤나 건방진 님이시군요..
역겨워...
동감...
동감...
흠... 그럼 '과민반응'이라고 표현을 고쳐야 겠군요 :)
흠... 그럼 '과민반응'이라고 표현을 고쳐야 겠군요 :)
도와드릴 수 있는게 없군요. 화이팅입니다. ^ ^ 그리고
도와드릴 수 있는게 없군요.
화이팅입니다. ^ ^
그리고 결과물 기대하겠습니다.
어쩌다보니 익명으로 글 쓰는듯. . . -쫑아
중요한 팁을 빼먹었네요 :)모질라나 넷스를 쓰신다면 다음 링크로
중요한 팁을 빼먹었네요 :)
모질라나 넷스를 쓰신다면 다음 링크로 가셔서 사이드바에 레퍼런스들을 추가하시면 편합니다.
http://devedge.netscape.com/toolbox/sidebars/
CSS2/HTML 4.01/DOM2가 일목요연하게 사이드바에 정리되어 나옵니다.
그럼...
그런데 웃기는 것은, IE용의 자바스크립트 DOM모델은 W3C의 인증을
그런데 웃기는 것은, IE용의 자바스크립트 DOM모델은 W3C의 인증을 받지 않았다는 겁니다... 결국은, IE용의 자바스크립트 구문은 표준이 아니라는 것이죠....외국에 보면 이런거에 대한 논란이 자주 이는 것 같기도 한데...우리나라에서는 완전 IE가 표준인줄 알기 때문에....-_-;;;;
http://www.w3.org 가면 자바스크립트와 CSS의 표준이 자세
http://www.w3.org 가면 자바스크립트와 CSS의 표준이 자세히 나와 있습니다....설마 모르시는 분은 없으시겠지만....-_-
Wired News goes XHTMLhttp://no-smok.ne
Wired News goes XHTML
http://no-smok.net/nsmk/WiredMagazine
--
from [ke'izi] : where is [r]?
쓸데없는 시간 낭비라고 말하고 싶군요.
쓸데없는 시간 낭비라고 말하고 싶군요.
현재 데스크탑에서 접속하는 웹서버의 로그를 보면.. 99% 정도가 IE
현재 데스크탑에서 접속하는 웹서버의 로그를 보면.. 99% 정도가 IE 입니다.
KLDP처럼... 리눅스 사이트를 제외하고는..... 그리고 현재의 쇼핑몰이나.. 대부분의 보안인증이 필요로 하는 상거래 서버의 클라이언트 인증모듈이 이미 IE전용 플러그인(컨트롤)입니다.
아무리... 노력해봤자.... 상업용 혹은.... 퍼블릭한 사이트에서 노력해봤자... 효용가치가 없을듯 생각됩니다.
효용가치라... 딴지 걸고 싶진 않지만 그럼 님은 왜 리눅스 관련 페이지
효용가치라... 딴지 걸고 싶진 않지만 그럼 님은 왜 리눅스 관련 페이지에 와서 글을 올리십니까? 어차피 90% 이상의 사용자가 윈도우즈를 쓰는 마당에 그냥 컴퓨터 살 때 깔린 OS 쓰면 될텐데요.
본문 올리신 분이 모질라 호환 페이지를 만들면 돈을 더 많이 벌 수 있냐고 물어본 것도 아니고, 굳이 자기 시간 쪼개서 애쓰시는 분께 적절한 반응은 아닌 듯 합니다.
억지쓰고 딴지걸고 시비걸지 맙시다.지금 저 분이 무슨 말을 하는지 몰
억지쓰고 딴지걸고 시비걸지 맙시다.
지금 저 분이 무슨 말을 하는지 몰라서 하는 소리입니까?
땅파먹고 사는 것도 아닌데 1%도 안 되는 사람을 위해 두 배의 노가다를 하라는 것입니까?
님보고 하라고 한적 없습니다. 자기가 좋아서 자기 학교 페이지를 호환성있
님보고 하라고 한적 없습니다. 자기가 좋아서 자기 학교 페이지를 호환성있게 만들어 보겠다는데 뭐가 문제인지 모르겠군요.
글쓴이입니다. 사실 글을 워낙 두서없이 써서 글을 올리고도 후회만 하다가
글쓴이입니다. 사실 글을 워낙 두서없이 써서 글을 올리고도 후회만 하다가 하루가 지나도록 안 올라오길래 차라리 다행이다 싶었는데, 결국 이렇게 올라 오고 말았군요 X-p
각설하고, 방금 한시간 가볍게 워밍업-_-으로 삽질을 해 본 소감은... 나름대로 재미있다 입니다 ^^ 생각만큼 그렇게 어렵지 않았거든요. 사실 제 신분으로 보나 하는 일로 보나 분명히 님 말씀처럼 시간 낭비이기는 합니다(자바를 제쳐두고 JS라니...ㅜㅜ). 하지만 결코 쓸데없다는 생각은 들지 않는데요? 잠시 얼굴이 붉어지긴 했습니다만, 그건 아마도 님의 지나치게 완고한 표현에 대한 제 거부감에 불과한 것이고... 님께서 늘상 들어왔을 것으로 예상되는 다른 거창한 이야기들은 집어 치우고서라도 재미있다는 것 한가지가 우선 저한텐 쓸데없지 않은 가장 큰 이유이고, 저 위에 대선공약처럼 써 놓은 것처럼 후에 일어날 많은 일들을 상상해 보는 것도 즐거움이 되는군요. 물론 혹시라도 제 상상에 대고 비웃으시겠다면, 뭐 전 전혀 할말없습니다 ^^
참고로 현재까지의 경과는 이렇습니다. 모질라에 자바 스크립트 디버거라는 자못 훌륭해 보이는(물론 이름이) 녀석이 있어서 좀 써보다가 도무지 쓰는 법을 알 수가 없어서 때려치웠고, 대신에 아랫분 말씀 보고 자바 스크립트 콘솔을 써 봤는데 훨씬 간단하네요. 뭣보다 즐거운 점은 문제가 된 페이지에서 인클루드하는 JS 코드의 정체를 알아 냈다는 것인데, 해외 모 사이트에서 배포하는 것이더군요. 영어 잘하는 우리 아찌 만세... 만세까지 외치는 이유는 원래 NS4까지도 대응하는 것인데 정작 이쪽 코드를 보니 그 부분만 쏙 빼놨던겁니다(if!). 음... 다시 붙이면 어떻게 될지 흥분 만땅입니다.
그럼 나중에 다시 글 올리겠습니다. 원래 좀 더 눈치 보다가 글 쓰려고 했는데... 음... 그리고 밑에 종대님, validator는, 음... 차마 겁나서 못 할것 같군요 ㅡ,.ㅡ 제 100% css&text로만 된 홈페이지에서도 오류를 주루룩 뿜어내던 그 기억을 상기하면...(...) 역시 다음 기회로 미뤄야 할 것 같습니다 ㅡ,.ㅡ 고쳐야 될 게 너무 많아도 개발하시는 분들께 좀 죄송해서요. 직접 접근할 수 있는 것도 아니고, 모질라도 비표준을 요즘은 웬만큼은 먹어주니...(참고로 이분들 프론트 페이지 씁니다 ㅡ,.ㅡ)
헉. 글이 또 이상하게 길어졌네요. 그럼 다들 즐거운 하루 되시기바랍니다. [__] =3=3=3
최소한 HTML 부분이라도 validator.w3.org로 점검해보세요.
최소한 HTML 부분이라도 validator.w3.org로 점검해보세요.
transitional 인가요.. 그정도는 대충 어떻게든 맞추겠는데..
transitional 인가요.. 그정도는 대충 어떻게든 맞추겠는데..
strict 는... 인간이 할 수 있는 게 아니라는 생각마저 들더군요..--;;
css 까지 검사했는데.. 좌절입니다..
스스로의 부족함을 느끼고 싶으신 분들은 strict로 한번 해보시길 바랍니다.
제 개인홈은 xhtml 1.1 / css2 에 맞춰져 있습니다. (xht
제 개인홈은 xhtml 1.1 / css2 에 맞춰져 있습니다. (xhtml 1.1은 xhtml 1.0 strict 기반입니다.)
그리 어렵지 않습니다. 익숙함의 문제지요.. 아쉬운 거 있으면 dtd 재정의해서 쓰면 되고.
strict.. 익숙해지면 오히려 쉽고 편안하던데요.
한 때는 프로젝트에서 links/lynx까지 지원해주려고 노력한 적이 있
한 때는 프로젝트에서 links/lynx까지 지원해주려고 노력한 적이 있었는데 그 때는 validator가 도움이 많이 되더군요. 특히 img태그에 alt를 쓴다던지 하는 부분은 모질라/익스만 대상으로 코딩을 하다보면 간과하기 쉬운 부분 같습니다.
하지만 우리나라 사이트를 만들면서 자바스크립트를 안쓰는게 상당히 어렵더군요. 어쨌든 그래서 요즘에는 모질라/익스 정도만 맞추어 주고 있습니다.
경험상 가장 중요한 두 가지는 :(1) JScript와 JavaS
경험상 가장 중요한 두 가지는 :
(1) JScript와 JavaScript의 차이, 혹은 IE와 모질라의 DOM 구현의 차이를 아는 것입니다. 즉, myForm이라는 form 태그 아래 myField의 값을 참조할 때 IE는 개발자의 편의를 위해 표준적인 document.myForm.myField.value이외에 myForm.myField.value라는 축약을 허용합니다.
id로 참조하는 경우, myDiv라는 id를 지닌 DIV 태그는 IE의 경우 myDiv만 쓸 수 있지만 표준은 document.getElementById("myDiv")가 맞습니다.
대부분 모질라에서 버튼을 눌렀는데 스크립트 오류가 나는 경우 위와 같은 문제입니다.
(2) CSS를 정확히 사용할 줄 알아야 합니다 :
어차피 HTML을 어떻게 보여줄지는 브라우저 마음입니다. 이러한 문제를 해결하기 위해 나온 것이 CSS이며 사실 구현상의 미세한 차이는 있지만 CSS만 제대로 쓴다면 90% 이상은 동일한 모습을 볼 수 있습니다.
특히 테이블을 계속 중첩하거나 nbsp를 남용하는 등의 습관은 꼭 브라우저 호환성이 아니더라도 상당히 안좋습니다. CSS만 제대로 다뤄도 아마 기존의 소스를 50-60% 가까이 줄이면서 브라우저 호환을 얻을 수 있습니다.
......
나머지는 td의 margin/padding을 다루는 방식의 차이점 등인데 이는 경험으로 터득하는 수밖에 없습니다. 하지만 위의 두가지만 제대로 구사해도 실무 프로젝트에서 오히려 시간을 단축 시키면서 브라우저 호환을 얻을 수 있다고 생각합니다.
그럼...
한 가지만 더 추가하면, 기존에 IE 전용으로 디자인된 페이지를 모질라로
한 가지만 더 추가하면, 기존에 IE 전용으로 디자인된 페이지를 모질라로 옮기신다면 모질라의 자바스크립트 콘솔을 활용하시는 것이 좋을 것 같습니다. 디버거나 DOM inspector 등은 뽀대나는 것에 비해 크게 효용은 없는 것 같더군요 :)
저도 콘솔창 활용 추천..
저도 콘솔창 활용 추천..
댓글 달기