박민권 wrote:빛알갱이 wrote:
박민권님, '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">로 바꿔서 언어를 명확히 해 주시면 더욱 좋을 것입니다.