재정경제부 종합투자계획 토론 사이트 오픈

[hyeonseok]

http://jumpkorea.mofe.go.kr

DTD 는 HTML 4.01 Transtional 이지만 실제적으로는 거의 XHTML Strict 이고,

작업 도중에 validation 체크를 하지는 않았는데 일부 개발자가 삽입한 javascript 나 앰퍼샌드, 일부 한문 등 에서만 에러가 발생합니다.

총 제작 기간은 5일입니다.
짧은 시간에 비해 개인적으로는 꽤나 만족 하고 있습니다. -o-;

많은 질타 바랍니다.

[Channy]

많은 질타 바랍니다.

너무 훌륭합니다. 멋집니다.
텍스트형 스타일 하나를 추가해서 "장애인용" 메뉴를 하나 만든 다음 적용하게 하면 어떨까요? 그러면 접근성 높은 훌륭한 레퍼런스가 될 것 같습니다.

[박민권]

http://jumpkorea.mofe.go.kr

많은 질타 바랍니다.

<a href="javascript:viewArticle"> 는 잘못된 것으로 알고 있습니다.
<a href="#" onclick="viewArticle()"> 로 수정하심이 맞습니다.

------------------------------------------------------------------------------------

<link rel="stylesheet" type="text/css" href="/include/css/default.css">
<link rel="stylesheet" type="text/css" href="/include/css/layout.css">
<link rel="stylesheet" type="text/css" href="/include/css/main.css">

이 부분에서는 통합적인 default.css 만 불러오고 나머지는
default.css에 @import url(laycout.css); 이런식으로 불러오는게 좋지 않았나
싶습니다. 그때그때 필요한 것만 불러 쓰는 것도 좋지만 좀더 간편한 소스를
위해서는 하나로 임포트를 이용한 전체 및 그룹적인 통합을 하는게 좋다고 봅니다.

--------------------------------------------------------------------------------------

5일의 짧은 기간이라서 그런지 디자인은 화려하지 않은 것 같습니다.
뭐 사용자 입장에서는 디자인보다 자료가 중요하지만 워낙 국내는 화려한것을 좋아하니

--------------------------------------------------------------------------------------

질타를 부탁하셔서 잘못을 올렸지만 훌륭한 사이트 입니다.
개발자 입장에서는 훌륭한데 일반유저 입장 및 클라이언트 쪽에서는 디자인을
중요시 하니 그 훌륭함을 보지 못 할 것 같아서 마음이 아픔니다.

그런데 글 쓰고 보니 hyeonseok님 이셨군요. ㅎㅎ

[소프트원원트]

아주 깔끔해 보이내요..^^ 제 사이트도 심플,깔끔하게 만들어야하는 데, 디자인이 너무 맘에 드내요..

적당한 선에서 Tab은 정리를 해서 최대한 소스크기를 줄여보시죠.

그리고 아래 소스를 보았는 데, 서식과 불필요한 의미없는 태그가 들어가 있는 것같은 데, 스타일시트에서는 span에서 지정하고 있는 게 보이지않던데..

<span>토론마당</span>

그리고 하단에 있는 것..

<div id="copyright-block"><img src="/images/nav/copyright.gif" id="copyright" alt="Copyright 2004 by Ministry of Finance and Ecomomy, Republic of Korea. All Rights Reserved."><br>
<img src="/images/nav/address.gif" alt="경기도 과천시 관문로 88번지 정부과천청사 재정경제부 (우)427-725, 전화:02-2110-2331">
</div>

굳이 이미지를 사용해야할까요? 레이아웃을 떠나서 텍스트를 필요로하는 사용자도 있지않겠습니까? 물론 모질라 사용자의 경우 alt 태그 내용을 복사해올 수 있지만, 그것을 아는 사용자도 드물고 IE사용자에겐 그렇지도 못하니까요.

CSS를 사용하기 때문에 레이아웃에 맞게 글꼴크기를 조절할 수 있으니, 텍스트를 우선으로 했으면 하내요.

[소프트원트]

제가 못 보았군요..

#main-content h1 span {
display: none;
}

그런데, 이를 써야할 이유는 모르겠는 데, 어짜피 이미지를 쓰기로 했다면, 또다시 텍스트를 사용해서 보이지않게 한 것을 쓸 이유가 있는가요?

브라우저 호환성 문제 때문인가요? 어떤 이유인 지 알려주세요. 유용하면 저도 써먹게요... ^^

생각으로는 스타일시트를 지원하지 않는 브라우저를 염두에 둔 것같기도 하고...

[박민권]

제가 못 보았군요..

#main-content h1 span {
display: none;
}

그런데, 이를 써야할 이유는 모르겠는 데, 어짜피 이미지를 쓰기로 했다면, 또다시 텍스트를 사용해서 보이지않게 한 것을 쓸 이유가 있는가요?

브라우저 호환성 문제 때문인가요? 어떤 이유인 지 알려주세요. 유용하면 저도 써먹게요... ^^

생각으로는 스타일시트를 지원하지 않는 브라우저를 염두에 둔 것같기도 하고...

간단하게 생각하면 일단 이미지가 들어가기전에 텍스트로 했다가
추후 이미지가 삽입되고나서 나중에 뭔가에 쓰려고 안지웠다던가...

자바스크립트나 php등의 언어에서 숨겨져 있는 저 값을 읽어오려고
했다던가...

이미지가 들어갈 부분에 텍스트로 해서 다른 디자이너한테 넘겼더니
기존꺼 지워야하나마나 고민하다가 숨겨놨다거나...

소스 검색시 단어검색을 통해 해당위치로 빨리 가려고 했다거나...
(그럼 그냥 주석이 나으려나?)

뭘까요? ㅡㅡ;

[Outvoy.com]

Image Replacement 가 아닌가요? 스타일을 지원하지 않는 브라우져를 위한거 같네요.

그리고 한가지 의문점이 있다면 한 문서에서 h1 엘리먼트를 여럿 사용하는게 구조적인 마크업인지 궁금하네요. 보통 페이지당 하나의 h1만 쓰던데. 글제목이던가 사이트 이름으로 쓰이더군요.

[빛알갱이]

많은 질타 바랍니다.

너무 훌륭합니다. 멋집니다.
텍스트형 스타일 하나를 추가해서 "장애인용" 메뉴를 하나 만든 다음 적용하게 하면 어떨까요? 그러면 접근성 높은 훌륭한 레퍼런스가 될 것 같습니다.

멋진 사이트를 만들어서 모범을 보여 주셔서 감사와 축하를 드립니다.

그냥 stylesheet를 복수로 준비해서 사용자가 원하는 것을 골라 쓰도록 하면 되겠지요. 그런데, alternative stylesheet 지원 기능이 미약한(없는) MS IE를 위해서 메뉴를 따로 만들 필요가 있기는 하겠군요.

몇 가지 지적 : HTML 4.01 transitional이니까 상관 없기는 하지만, href 등을 따옴표로 묶는 것이 나중에 XHTML로 옮겨 갈 때 비용을 줄이는 길이겠지요.

Code: Select all

<a href=javascript:viewArticle('21','forum')>

위와 같은 링크는 JS를 지원하지 않거나 꺼 놓은 사용자에게는 그림의 떡입니다. viewArticle() 함수가 그리 복잡하지않고, 어차피 페이지가 동적으로 생성되는 것이라면 href에는 '21'과 'forum'을 넘겨 받아서 viewArticle이 만들어 낼 URL을 직접 써 주고, 'onclick' 속성에 'viewArticle....'을 써 주시면 좋겠습니다.
사실, 팝업 창을 여는 것도 아니고, 그 자리에 새로 페이지를 여는 것이니 viewArticle이란 JS 함수는 아예 없애 버리고, 그냥 써버 사이드에서 모두 다 처리하는 것이 더 좋지 않을까요?

박민권님, 'href="#"'을 쓰는 것은 표준 검사를 통과하는 '꽁수'일 뿐 실질적으로 JS를 쓸 수 없는 사용자에게는 똑같이 frustrating합니다.

[빛알갱이]

박민권님, 'href="#"'을 쓰는 것은 표준 검사를 통과하는 '꽁수'일 뿐 실질적으로 JS를 쓸 수 없는 사용자에게는 똑같이 frustrating합니다.

쓸 수 없는 사용자: mobile 장치 중 메모리 제약이나 다른 이유로 JS engine을 넣지 않은 브라우저를 넣어 놓은 것이 있을 수 있습니다. 텍스트 모드 브라우저의 대다수는 아직 JS를 지원하지 않습니다. (Lynx, links, w3m-m17n 등에 JS 엔진을 넣자는 움직임이 있기는 한데, 아직...) 한국에서는 드문 일이겠지만, 어떤 곳에서는 JS 기능을 회사 정책으로 꺼 놓고 사용하는 곳도 있습니다. 또, 중요한 경우는 '기계들' (검색 엔진, crawler,robot 등). 뭐, 요새 똑똑한 '애'들은 JS engine을 가지고 있을 것 같기는 하군요.

[빛알갱이]

Code: Select all

<a href=javascript:viewArticle('21','forum')>

사실, 팝업 창을 여는 것도 아니고, 그 자리에 새로 페이지를 여는 것이니 viewArticle이란 JS 함수는 아예 없애 버리고, 그냥 써버 사이드에서 모두 다 처리하는 것이 더 좋지 않을까요?

즉, href 값으로 'http://...../forum/view.php?bbs_id=forum&article_id=21'을 직접 써 주는 것이 좋다고 생각합니다. 또, 이렇게 할 경우 또 장점은 POST 대신 GET을 쓰기 때문에 (JS에서도 물론 GET을 쓸 수 있지만) 이 글을 다른 곳에서 언급할 때 URL을 쉽게 얻을 수 있습니다.

[박민권]

박민권님, 'href="#"'을 쓰는 것은 표준 검사를 통과하는 '꽁수'일 뿐 실질적으로 JS를 쓸 수 없는 사용자에게는 똑같이 frustrating합니다.

꽁수라기 보다는 js함수를 불러오기 위해서는 href=""에 삽입하는 것보다
onclick에 기술하는것이 맞다는 뜻이었습니다. js를 꺼놓거나 사용할 수 없는 사용자들을 위해서 쓰자는 뜻이 아니라는 것이죠.

js는 사실 사용하는게 귀찮기도 하지만 개발시 쓰지 않을래야 안쓸수
없는게 js가 아닐까요?
js만이 아니라 css또한 제대로 지원 못하는 브라우저도 있죠.
그걸 다 맞추자면 html 만으로 페이지를 만들어야 할 것입니다.

위의 사이트처럼 js를 기술하면 디자이너 입장에서는 코드수를 줄여주고
링크수정또한 쉽게 할 수 있습니다. 그외 동적인 기능도 추가할 수 있죠.

js를 지원못하는 모바일용 기기등을 생각한다면 아예 모바일 따로
사이트를 개발하는 것이 좋다고 봅니다. 이 사이트를 계약한 클라이언트가
모바일 지원까지 부탁하지 않은이상 PC용 브라우저에도 돌아가면되지
굳이 js를 지원못하는 것까지 신경쓸 필요는 없다고 봅니다.

디자인만 신경쓰느라 IE전용으로 만드는건 문제가 되지만 IE도 MZ도
문제없고 디자인도 좋으며 동적기능을 위해 js를 사용하는건 나쁘다고
보지 않습니다.

단순한 링크를 저렇게 js를 썼다는 것에 js가 동작불가능한 사용자가
불편할 수도 있다고 느낄 수 있지만 프로그래머 입장에서 봤을때
코드를 효율적으로 사용했다고 봅니다.

다시 한번 말씀드리지만 js가 안되는 사용자를 위해서라면 기획단계부터
생각을 했어야 하며 5일이라는 시간안에 그리 크지 않은 돈으로 제작
했을텐데 클라이언트의 부탁이 없었다면 굳이 신경쓰지 않아도 된다고
봅니다.

js가 안되는 사용자까지 고려해서 하려면 위의 사이트 같은 경우만해도
상단메뉴를 사용할 수가 없게되죠. 개인사이트라면 별 신경안쓰고
정적인 텍스트 처리하면 되지만 돈받고 이쁘게 만들어서 팔아야 하는데
그렇게 했다면 당장 빠꾸먹어버리죠.

js미사용자를 고려하지 말자는 말도 아니고 href에 직접 링크를 기술해야
한다는 말이 틀렸다는 것도 아닙니다.
정리하면 위의 사이트의 제작기간등의 상황을 보았을때 훌륭히 잘하였고
js미사용자를 고려한다면 기획단계부터 고려해야 가능한 것이고
모바일까지 생각한다면 모바일용 페이지를 따로 제작하는 것이 맞습니다.

뭐 이 글을 쓰신 hyeonseok 님이 질타를 부탁하다보니 단점을 찾아내신
것이지 위 사이트를 나쁘게 봐서 쓴 글은 아니라는거 압니다.
오해없는 토론의 장이 되었으면 합니다.

[빛알갱이]

박민권님, 'href="#"'을 쓰는 것은 표준 검사를 통과하는 '꽁수'일 뿐 실질적으로 JS를 쓸 수 없는 사용자에게는 똑같이 frustrating합니다.

꽁수라기 보다는 js함수를 불러오기 위해서는 href=""에 삽입하는 것보다
onclick에 기술하는것이 맞다는 뜻이었습니다. js를 꺼놓거나 사용할 수 없는 사용자들을 위해서 쓰자는 뜻이 아니라는 것이죠.

현석님은 높은 standard를 지니신 분이므로 그에 걸맞는 '질책'(이라기 보다는 지적)을 하는 것입니다. 5일만에 완벽한 작업을 해야 한다고 말하는 것이 결코 아닙니다. href에 '#'을 쓰라고 하는 것은 'graceful degradation'의 원칙에 어긋나므로, 현석님과 같은 높은 기준을 지닌 분에 대한 지적 사항으로는 어울리지 않다고 생각해서 얘기한 것입니다.

js는 사실 사용하는게 귀찮기도 하지만 개발시 쓰지 않을래야 안쓸수
없는게 js가 아닐까요?
js만이 아니라 css또한 제대로 지원 못하는 브라우저도 있죠.
그걸 다 맞추자면 html 만으로 페이지를 만들어야 할 것입니다.

다른 기술을 쓰지 말라는 얘기가 결코 아닙니다. 제가 무슨 러다이트 운동을 하시는 것으로 생각하시는 것은 아니겠지요 ? 다른 기술을 쓰더라도 그런 기술을 쓸 수 없는 사용자도 내용 파악과 사이트 탐색에 장애가 없도록 하자는 것입니다.

위의 사이트처럼 js를 기술하면 디자이너 입장에서는 코드수를 줄여주고
링크수정또한 쉽게 할 수 있습니다. 그외 동적인 기능도 추가할 수 있죠.

저 페이지가 수동으로 만들어진 정적인 페이지라면 그렇게 얘기할 수 있습니다. 하지만, 저 페이지는 어차피 동적으로 서버측에서 자동 생성된 것입니다. 따라서, 개발 효율성, 편의성면에서 제가 지적한 특정한 경우에 JS를 쓰건 안 쓰건 거의 차이가 없다고 봅니다. 써버측에서 java, php, asp, perl 등이 할 URL 만드는 일을 클라이언트 측의 JS더러 하라고 하느냐 마느냐의 차이 밖에 없습니다. (아주 바쁜 써버라면 써버 로드를 줄이는 효과는 있겠지요.)

js를 지원못하는 모바일용 기기등을 생각한다면 아예 모바일 따로
사이트를 개발하는 것이 좋다고 봅니다. 이 사이트를 계약한 클라이언트가
모바일 지원까지 부탁하지 않은이상 PC용 브라우저에도 돌아가면되지
굳이 js를 지원못하는 것까지 신경쓸 필요는 없다고 봅니다.

모든 경우에 제 '방식'이 맞다고 주장할 생각은 전혀 없습니다만, 모바일 기기를 위한 페이지를 따로 만드는 것은 그다지 권장할 일이 된다고 여기지 않습니다. 내용과 표현 분리의 원칙을 문자 그대로 따른다면, 다중 장치나 다른 능력을 가진 사용자, 다른 환경의 사용자를 위한 사이트를 별도로 개발하지 않아도 내용은 가만히 둔 채로 표현 방법만 달리 해서 원하는 결과를 얻어 낼 수 있을 것입니다. 물론, 이것은 '원칙'이므로 실무에서 언제 어디서나 항상 적용 가능하다고 얘기하는 것은 결코 아닙니다.

이 특정한 경우에는 JS를 써서 얻는 이득이 전무하다시피한 상황에서 거의 관성적으로 JS를 쓴 듯한 인상이 들었기 때문에 지적한 것입니다. 그리고, 저의 또다른 지적 사항은 POST 대신 GET을 쓰는 것이 더 낫다입니다. 이 부분은 JS 사용 여부와 관계가 없고요.

다시 한번 말씀드리지만 js가 안되는 사용자를 위해서라면 기획단계부터
생각을 했어야 하며 5일이라는 시간안에 그리 크지 않은 돈으로 제작
했을텐데 클라이언트의 부탁이 없었다면 굳이 신경쓰지 않아도 된다고
봅니다.

JS는 꼭 필수 불가결한 곳에만 쓰는 것을 원칙으로 한다면 결과는 같은 시간, 같은 비용, 같은 요구 조건 하에서도 얼마든지 달라질 수 있습니다. 제가 이미 보인 바와 같이 이번 경우는 JS를 써서 얻을 수 있는 것은 거의 없고 (개발 비용, 개발 시간, 개발자 편의성, 보수 및 유지 편의성), 아무리 극소수일지라도 일부 사용자에게 사이트 사용을 못 하게 만드는 결과를 초래했습니다. (단, 인력 배치 및 작업 분담의 차원에서 차이가 생길 수는 있겠군요.) 물론, 모든 경우가 이런 경우와 같지는 않으므로, 박민권님의 생각이 잘못되었다고 얘기하려는 뜻은 없습니다. 여러 가지 제약 ㅤㄸㅒㅤ문에 '타협'을 해야 하는 상황은 현실적으로 얼마든지 많습니다.

js가 안되는 사용자까지 고려해서 하려면 위의 사이트 같은 경우만해도
상단메뉴를 사용할 수가 없게되죠.

JS를 지원하지 않는 w3m-m17n나 Lynx에서도 상단 메뉴를 잘 사용할 수 있는데요. 지금 당장도요 현석님이 그 부분에서 'graceful degradation'의 원칙을 잘 따라 주었기 때문입니다. 그 부분을 잘 하셨기 때문에 포럼 글을 볼 수 없도록 해 놓으신 것에 대한 지적을 한 것이고요.

오해없는 토론의 장이 되었으면 합니다.

저는 오해한 게 없는데... 글로 쓰다 보면 - 말로 한다고 해도 그것을 피할 수 있는 것은 아닙니다만 - 오해가 생기곤 합니다. 제 의도와 달리 언짢은 부분이 있었다면 (지금 이 글에서도) 제 뜻이 아니라는 점을 밝혀 드립니다.

어쨌든, 웹 표준 보급을 위해 현장에서 많은 노력을 하고 계신 박민권님께 이 기회를 빌어 감사의 뜻을 전합니다.

참, 끝으로 사이트에서 한 가지 '티' 하나 더 : 내부 페이지는 다 문제가 없는데, 맨 첫 페이지에서 <meta...>를 쓴 charset 선언이 <title> 다음에 나옵니다. 원리원칙대로 하자면, <head> 다음에 바로 그것이 나와야 합니다. 한 가지 더 지적하자면 <html>을 <html lang="ko">로 바꿔서 언어를 명확히 해 주시면 더욱 좋을 것입니다.

[빛알갱이]

잘 만드시는 사이트에 대해서 자꾸 지적을 해서 죄송. 잘 만드셨으니, 더 잘 해 주시기를 바라는 뜻에서.

제가 '정책 담당자와의 만남' 게시판에 HWP로 파일을 올려서 볼 수 없으니 HTML로 올려 달라고 글을 썼습니다. 그랬더니, 바로 HTML로 파일을 올려 주셨습니다. 그런데, 문제가 하나 있습니다. HTML 첨부 파일을 내보내면서 HTTP 헤더에서 Content-Type 값으로 'application/octet-stream'를 보냅니다. 따라서, 모질라에서 바로 보여 주지 않고 저장하라고 합니다. HWP 파일의 경우는 적절한 MIME type (HWP 제작사에서 이것도 MIME type을 IANA에 등록하면 좋겠군요)이 없으니 부득이하게 'application/octet-stream'을 쓰지만, html이라면 적절한 MIME type을 C-T를 통해 내보내 주시면 좋겠습니다. 또, 파일 형식에 따라 Content-Disposition 헤더에서 처리 방법을 달리 하시는 것도 고려하십시오. 즉, 현재는 무조건 'attachment'로 되어 있는데, 'text/*'를 비롯한 몇몇 형식은 'inline'을 쓰는 것이 더 낫지 않을까요?

Code: Select all

Content-disposition: attachment; filename=문답자료.htm

또, C-D에서 filename 파라미터는 그냥 위에 보인 것처럼 쓰면 안 됩니다. 원칙대로 하자면 RFC 2231을 따라 해야 하는데, 그렇게 할 경우 MS IE가 이해하지 못 하는 문제가 있습니다. '꽁수' 중 하나는 'name'이란 parameter에는 저렇게 그냥 쓰고, filename에서 RFC 2231을 지키는 것입니다. HTML4의 저자들조차 이 문제를 헛갈려서 명확히 해 놓지 않은 '오류'를 범했습니다. 따라서, RFC 2231을 꼭 쓰라고 할 생각은 없습니다. 모질라는 현재 4단계 보호막을 두어서 온갖 경우를 다 처리합니다. 단, 다음 단락에서 거론할 문제는 서버측에서 꼭 고쳐야 합니다.

RFC 2231을 쓰지 않을 경우에는 filename이나 name parameter의 값을 따옴표로 묶어 주어야 합니다. 사용자가 올린 파일 이름 중간에 공백이 들어 가지 않으면 상관 없지만, 공백이 들어간 경우 묶어 주어야 합니다. 일일이 검사할 필요 없이 항상 묶어 주면 무난합니다.

아래 모질라 버그를 보십시오. 아주 흔한 실수여서 사용자들이 좀 봐 주라고 하지만 (모질라 코드를 고쳐서) 저는 봐 줄 생각이 전혀 없습니다. 그렇게 할 수 없는 이유 중 하나는 그것을 봐 주기 위해서는 관련 코드가 아주 지저분해지기 때문입니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=221028

[박민권]

href에 '#'을 쓰라고 하는 것은 'graceful degradation'의 원칙에 어긋나므로, 현석님과 같은 높은 기준을 지닌 분에 대한 지적 사항으로는 어울리지 않다고 생각해서 얘기한 것입니다.

이 부분은 미처 몰랐습니다.

어디선가 봤는데 href="javascrit:함수()" 보다는 href="#" onclick="함수()"가
맞다고 해서 맞는건줄 알았는데 잘못 알고 있었나보군요.

그리고 오해없는... 이라는 말은 님의 답변을 오해한 것이 아니라 혹시 제 답변으로
알갱이님이 안좋게 오해하실까봐 쓴 글이지 알갱이님의 답변에 오해하지는 않았습니다.

좋은지식 하나 알아서 기쁨니다. 감사합니다.[/quote]

[hyeonseok]

텍스트형 스타일 하나를 추가해서 "장애인용" 메뉴를 하나 만든 다음 적용하게 하면 어떨까요?

이부분은 스크린 리더라는 것에 얽매여서 미처 생각하지 못했던 부분인데 좋은 아이디어 같습니다. 구체적으로 검토 해봐할 것 같습니다. 감사 합니다. ^^

<a href="javascript:viewArticle"> 는 잘못된 것으로 알고 있습니다.
<a href="#" onclick="viewArticle()"> 로 수정하심이 맞습니다.

흐...이부분에 대한 논의가 많군요.
결론부터 말씀 드리자면 페이지이동을 javascript 로 해서는 안됩니다.

href 는 hypertext 가 value 로 들어가야 합니다.
따라서 href="javascript:~~~" 도 맞지 않고 href="#" 도 맞지 않습니다.

게시판 등에서 쿼리스트링을 post 로 넘기는 것은 개인적으로는 해서는 안될 "짓" 이라고 생각하는데...뭐 개발자가 그렇게 하겠다면 일단은 어쩔 수 없죠. 설득을 못해낸 제가 잘못이죠.

javascript 를 사용하겠다고 하면...

<span style="cursor: pointer;" onclick="myFumction()">어쩌구</span>
이 맞겠지요.

popup 창이라고 해도 href 안에 javascript:window.open~~ 라고 하면 안됩니다. popup 창은 엄연히 url 이 있으니까요.

관련된 내용은
http://hyeonseok.com/home/archive_javas ... opupWindow

이 부분에서는 통합적인 default.css 만 불러오고 나머지는
default.css에 @import url(laycout.css); 이런식으로 불러오는게 좋지 않았나
싶습니다.

이부분은 저도 미처 생각지 못했었습니다. 좋은 의견 감사 합니다. 다음에는 꼭 이렇게 해보아야 겠군요! ^^

굳이 이미지를 사용해야할까요? 레이아웃을 떠나서 텍스트를 필요로하는 사용자도 있지않겠습니까? 물론 모질라 사용자의 경우 alt 태그 내용을 복사해올 수 있지만, 그것을 아는 사용자도 드물고 IE사용자에겐 그렇지도 못하니까요.

이부분도 저도 참으로 안타깝습니다. 하지만 제가 이러한 것들 이미지 안쓰고 text 로 넣겠다고 하면 디자이너가 아주 싫어 할 것 같습니다. ^^
일단 전체적인 디자인 자체가 이미지 텍스트가 더 어울리게 디자인을 하고 있고...
이게 우리나라의 현실이죠.

Image Replacement 가 아닌가요? 스타일을 지원하지 않는 브라우져를 위한거 같네요.

이미지 리플레이스 맞습니다. 이미지 텍스트에 대한 접근성을 높이기 위한 방법이고...
관심있이신 분들은 google 에서 검색해보면 많이 나옵니다. ^^ css 를 이용한 방법, javascript 를 이용한 방법 flash 를 이용한 방법 등 많습니다. outvoy 님 블로그 가봤습니다. 반갑습니다~ 특히나 em 을 이용한 폰트 테스트...플랫폼 디팬드 하긴 하지만 아주 좋았습니다. ^^

한 문서에서 h1 엘리먼트를 여럿 사용하는게 구조적인 마크업인지 궁금하네요.

저도 이것을 많이 고민 했었는데요...heading element 는 section 에서 주요한 내용 순으로 정하게 됩니다. 문제는 이 section 이라는 것을 어떻게 이해 할 것이냐 인데요. 저는 잠정적으로 section != document, section != page 라고 이해 했습니다. 그리고 문서 자체는 page 로서의 h1 이 중요한 것이지 그 문서가 mozilla.org 안에 있다는 사실이 중요한게 아니기 때문에 h1 으로 사이트 이름을 적는 것도 딱히 좋은 방법은 아닌것 같더군요. 그래서 저는 h1 은 여러개 사용해도 될것 같다고 생각 했습니다. 관련된 내용이 웹스탠다드그룹에서 오고 갔었는데...그분들도 의견이 분분하더군요. ^^

HTML 첨부 파일을 내보내면서 HTTP 헤더에서 Content-Type 값으로 'application/octet-stream'를 보냅니다.

이부분은 제가 생각을 해본 적이 없는데 개발자와 상의해 보도록 하겠습니다. php 에서 처리를 제대로 안해준 것인가 봅니다. 근데 application/octet-stream 으로 나와도 저장과 열기를 사용자가 선택 할 수 있으니 크게 문제 되지는 않지 않나요? 일단 그 첨부라는 것이 링크라기 보다는 1차적으로 다운로드를 유도 했다고 할 수도 있고...웹서버에 등록된 mime-type 을 사용할 경우 서버에서 run 될 수도 있기 때문에 보안상 막아 놓은게 아닌가...싶네요. 불편하기야 한데...^^

[빛알갱이]

게시판 등에서 쿼리스트링을 post 로 넘기는 것은 개인적으로는 해서는 안될 "짓" 이라고 생각하는데...뭐 개발자가 그렇게 하겠다면 일단은 어쩔 수 없죠. 설득을 못해낸 제가 잘못이죠.

개발자가 그렇게 하려는 이유가 뭘까요? 저는 아무리 생각해도 왜 그렇게 하겠다는 것인지 알 수 없는데요. URL이 드러나지 않으면 사람은 물론이고 (특정한 글을 refer하고자 하는. 이처럼 POST를 쓰는 곳이 많기 때문에 한국에서 유달리 글 퍼나르기가 유행인지도. 글의 URL을 주고 가서 볼 수 있게 하는 대신), 기계도 애를 먹습니다. (기계가 애를 먹는다는 사실을 가볍게 여기면 안 됩니다.) 요새 "구글"은 똑똑해서 POST 값도 따로 저장하고 있다가 볼 수 있도록 할지도 모른다는 생각이 들기는 하지만요. 하지만, 구글 같은 큰 회사가 아니라 특정 분야를 위한 전문 검색 엔진이나 웹 크롤러를 만들어야 할 필요가 있는 연구자들이나 open source 검색 엔진을 만드는 이들은 한정된 자원, 시간, 인력을 가지고 이런 것까지 다 하려면 힘이 듭니다.

popup 창이라고 해도 href 안에 javascript:window.open~~ 라고 하면 안됩니다. popup 창은 엄연히 url 이 있으니까요.

관련된 내용은
http://hyeonseok.com/home/archive_javas ... opupWindow

이것은 두말하면 잔소리지요 어쨌든, 사이트 개발자를 설득해서 그 viewArticle 함수를 JS에서 제거하고 dummy form도 HTML에서 제거한 후 그 기능을 PHP에서 하도록 하실 생각 없으십니까? 그 사이트가 로드가 많이 걸릴 곳도 아니고, 서버측에서 처리해서 손해 볼 것이 없어 보입니다.

HTML 첨부 파일을 내보내면서 HTTP 헤더에서 Content-Type 값으로 'application/octet-stream'를 보냅니다.

이부분은 제가 생각을 해본 적이 없는데 개발자와 상의해 보도록 하겠습니다. php 에서 처리를 제대로 안해준 것인가 봅니다. 근데 application/octet-stream 으로 나와도 저장과 열기를 사용자가 선택 할 수 있으니 크게 문제 되지는 않지 않나요? 일단 그 첨부라는 것이 링크라기 보다는 1차적으로 다운로드를 유도 했다고 할 수도 있고...웹서버에 등록된 mime-type 을 사용할 경우 서버에서 run 될 수도 있기 때문에 보안상 막아 놓은게 아닌가...싶네요. 불편하기야 한데...^^

[/quote]


다운로드 여부를 결정하는 Content-Disposition 헤더 필드의 값이 'attachment'냐 'inline'이냐가 결정하는 것이지요. 그 값에 관계 없이 Content-Type에 적는 MIME 형식은 실제 파일 형식에 맞게 제대로 적어 주어야 합니다.

보안 상 막아 놓았을 확률은 거의 없다고 봅니다. 그런 것까지 생각했을 것 같지 않고, 그냥 흔히 하듯이 습관적으로 첨부 파일을 내보낼 때에는 PHP에서 header("Content-Type: application/octet-stream")을 쓰더라... 뭐 이런 식이었지 않을까요?


또, 이미 앞서 지적한 바와 같이 filename 파라미터의 값을 인용 부호로 묶어야 한다고 전해 주십시오. 공백 여부를 검사해서 없는 경우에 그냥 내보내고, 있을 때에는 묶는 세심함을 보였을 가능성은 별로 없어 보입니다.

[빛알갱이]

하나 더. CSS stylesheet에 보면 font 이름을 '돋음' 등과 같이 한글로만 지정해 놓았습니다. sans-serif fallback이 있기는 합니다만, 운영 체계와 브라우저에 따라서 (이것은 비한국어 Windows 9x/ME에도 해당될 확률이 높습니다) 한글 글꼴 이름을 인지하지 못 합니다. 따라서, "Dotum"이라고 로마자 이름도 꼭 같이 써 주어야 합니다. 리눅스와 맥 OS에서 흔히 쓰는 글꼴 이름도 같이 적어 주면 더욱 좋고요. CSS 글꼴 지정에 관한 글 참고하세요.

http://gregshin.pe.kr/bbs/view.php?id=u ... =asc&no=13



또, CSS stylesheet가 EUC-KR이라면 파일의 최선두에서

@charset "EUC-KR";

과 같은 줄이 들어가야 합니다.

[hyeonseok]

post 로 값은 넘기는 이유는....제가 다른 개발자한테 물어봤었는데...

1. url 이 깨끗하다 (이게 무슨!!)
2. url 글자 길이에 제한이 있다. (무슨 쿼리스트링이 그리 길길래 -_-)
3. 관리가 편하다 (쿼리스트링을 따로 관리 안하고 폼으로 해결하면 다루기가 간편한가 봅니다.)

이런 이유를 대더군요. 어쨋든 접근성 생각은 조금도 없는 듯...

파일 다운로드는...제가 구체적인 내용을 잘 몰라서...그러면 파일의 확장자를 체크 하여서 type 을 일일이 다르게 지정을 해야 하나요? attachment 와 inline 도 체크를 해야 하고요?

php 파일을 보니까 IE5.5 일때와 아닐때로만 나눠놨군요. IE5.5 는 뭔가 좀 다른건가...

CSS 폰트는...
영문으로 쓰니까 firefox 가 인식을 못하는 것 같아서(기본폰트인 바탕체로 폰트가 나오더군요.) 한글로만 적어 놓았습니다. 혹시 charset 설정을 안해주어서 그런 것인가요?

다음 부터는 charset 도 지정을 하고 영문폰트명과 한글 폰트 명을 둘다 써야 겠군요.

참..그러고...font 이름을 따옴표로 묶어 주는 것은 어떠할 때 해야 하나요? 폰트 이름 사이에 공백이 있을 경우?

질문이 많네요...ㅎㅎ

[빛알갱이]

post 로 값은 넘기는 이유는....제가 다른 개발자한테 물어봤었는데...

1. url 이 깨끗하다 (이게 무슨!!)
2. url 글자 길이에 제한이 있다. (무슨 쿼리스트링이 그리 길길래 -_-)
3. 관리가 편하다 (쿼리스트링을 따로 관리 안하고 폼으로 해결하면 다루기가 간편한가 봅니다.)

이런 이유를 대더군요. 어쨋든 접근성 생각은 조금도 없는 듯...

3번은 이번 경우에 대한 핑계로 애초에 성립할 수 없습니다. 어차피 써버 사이드에서 PHP로 생성해 내고 있으므로, JS로 viewArticle이 만들어 낼 URL을 써버 측에서 PHP로 생성하면 되니까요. 말씀하신 대로 1번과 2번도 말도 안 되는 소리고요. 접근성은 물론이려니와 macine agent한테 불편하다는 점도 큰 문제입니다. 또, 게시판이라면 글을 참조할 방법이 없다는 것도 아주 큰 문제이고요.

파일 다운로드는...제가 구체적인 내용을 잘 몰라서...그러면 파일의 확장자를 체크 하여서 type 을 일일이 다르게 지정을 해야 하나요? attachment 와 inline 도 체크를 해야 하고요?

php 파일을 보니까 IE5.5 일때와 아닐때로만 나눠놨군요. IE5.5 는 뭔가 좀 다른건가...

IE 5.5에 뭔가 다른 점이 있는지는 잘 모르겠습니다.

사실 가장 좋은 방법은 bugzilla에서 하듯이 파일을 업로드할 때 아예 업로드하는 사람에게 MIME type(혹은 파일 종류)을 지정하라고 하고, 그 값을 DB에 저장하고 있다가 누군가 다운로드하려고 할 때 그 값을 쓰는 것입니다. 하지만, 이것을 어려워할 웹 페이지 사용자들을 위해서 확장자와 MIME type 사이 매핑 정보를 참조해서 내보내는 방법을 차선으로 쓸 수 있을 것입니다. 또 다른 방법은 Unix/Linux의 경우 file 명령을 써서 파일 형식을 그때 그때 알아낼 수도 있습니다. (써버에 로드가 걸릴 것이 염려된다면 외부 DB 등에 caching하는 것을 고려할 수 있고요)

CSS 폰트는...
영문으로 쓰니까 firefox 가 인식을 못하는 것 같아서(기본폰트인 바탕체로 폰트가 나오더군요.) 한글로만 적어 놓았습니다. 혹시 charset 설정을 안해주어서 그런 것인가요?

charset 미지정 탓은 아닙니다. 그렇다면, 오히려 한글로 써 놓았을 때 작동하지 않았어야겠지요.

아마 한국어판 윈도우즈에서 시험해 보신 모양이군요. 비한국어판 윈도우즈에서 시험해 보셨거나 리눅스나 Mac OS X에서 시험해 보셨다면 정반대의 결과가 나왔을 것입니다. 한중일 글꼴의 경우에만 이런 문제가 있는데, 제가 고쳐야 할 모질라 버그 중 하나입니다.

다음 부터는 charset 도 지정을 하고 영문폰트명과 한글 폰트 명을 둘다 써야 겠군요.

예, 그렇게 하시는 것이 가장 좋은 방법입니다. 또, 윈도우즈 이외의 플랫폼에서 널리 쓰이는 글꼴도 같이 지정해 주시면 더욱 좋고요.

참..그러고...font 이름을 따옴표로 묶어 주는 것은 어떠할 때 해야 하나요? 폰트 이름 사이에 공백이 있을 경우?

지금 기억이 가물가물... W3C CSS validator는 묶지 않아도 아무런 불평을 하지 않더군요. 다시 확인해 보아야겠습니다.

[greg]

개인 사이트가 아닌 정부 기관의 사이트로서 CSS 기반으로 디자인이 된 첫 사이트인 것 같아서 정말 기쁜 소식이 아닐 수 없습니다. 디자인하신 현석님께 정말 감사드리고 싶습니다.

아주 좋은 홈페이지라고 생각합니다. 추가로 그냥 몇 가지 생각나는 것이 있어서 적어봅니다.

1.

Code: Select all

<a href="http://blog.naver.com/kim5885four.do?Redirect=Log&logNo=80008396982" target="_blank">종합투자계획(한국형 뉴딜정책)이...</a>

에서와 같이 제목이 짤리는 부분에 짤리지 않은 전체 문장을 title 속성으로 넣어주시면 좋지 않을까 생각합니다. 일반 브라우저에서는 툴팁으로 보여서 좋을 것 같고, 장애인들에게는 맥락을 파악하고 선택할 것인지의 여부에 도움을 줄 것 같습니다.

2.

Code: Select all

<img src="/images/main/btn-more.gif" alt="more">

현재 같은 페이지에 more라는 링크가 상당히 많습니다. 그런데 링크만 모아놓고 보면 어떤 more가 어떤 게시판으로 연결되는지 좀 불분명해집니다. 그래서 "토론마당 전체보기" 등과 같이 정확한 기능을 설명해주는 alt 속성을 넣어주면 좋을 것 같습니다. 아니면 A 요소에 대한 title로 넣어줘도 되구요.

3. 사소한 문제일 수 있겠지만 날짜 부분인데요, 일반인들이야 그냥 12-14 라고 하면 12월 14일인가보다 알 수 있지만, 그냥 앞뒤 맥락을 파악하기 힘든 상태에서 시각 장애인들이 12-14라고 들으면 무슨 뜻인지 알기가 힘듭니다. 따라서 이런 경우도

Code: Select all

<span title="2004년 12월 14일">12-14</span>

이렇게 써주면 어떨까 제안해봅니다.

4. 그리고 제가 몰라서 질문을 하나 드리고 싶습니다.

Code: Select all

<a href="/news/list.php" onfocus="this.blur()">

에서와 같이 링크에 포커스가 가면 다시 blur시키도록 하는 코드를 다른 곳에서도 아주 많이 보았는데 왜 그렇게 하는지 잘 모르겠습니다. 굳이 간 포커스를 다시 감추라는 것인데... 사실 포커스가 간 곳을 다시 감춤으로써 얻는 시각적인 깔끔함이 얼마나 큰 것인지, 또 그것으로 인해 잃는 사용상의 편의성이 얼마나 큰 것인지 잘 모르겠습니다. 아무튼 위의 코드가 의도하는 바가 무엇인지 좀 알려주십시오.

5. 마지막으로, 작은 글씨가 잘 안 보이는 사람들이 큰 글씨로 봤을 때 pixel 단위로 고정된 레이아웃이 많아 좀 문제가 생기는 것 같습니다. 그래픽을 많이 써서 화려하게 해야 하는 요청자들의 요구를 들어주어야 하는 딜레마 때문에 쉽지는 않은 일이지만 그래도 앞으로 발전된 사이트에서는 그런 점도 고려가 되면 더 좋을 것 같습니다.

아무튼 훌륭한 사이트를 만들어주셔서 정말 기쁩니다. 우리 나라 공공 기관에도 이제 이런 사례들이 점점 늘어날 것 같습니다.