자바스크립트 속도 때문에 골치를 앓고 있는 이라면 당장 설치하길…

암튼 좀 짱임.

단어를 드래그, 더블클릭 등으로 선택하면 선택된 단어를 번역하여 보여주는 북마클릿, 이름하여 inline translator를 만들었습니다. 개인적으로 영문서 읽기 성공률을 올려보고자 만들었는데 생각보다 쓸만한 것 같아 공유해봅니다. :)

Google AJAX Language API를 사용하였고 API 지원하는 모든 언어가 번역되어 보여집니다.

아래의 링크를 북마크에 추가하신 후 원하시는 페이지에서 실행하여 사용하시면 됩니다. ( IE7 이상과 파이어폭스, 오페라, 사파리 등의 최신 브라우저에서 사용 가능합니다.)

간단 단어 번역

추가: 파이어폭스 애드온

다운로드: Inline Translator 파이어폭스 애드온

아직 정식 애드온으로 등록되지 않은 관계로 로그인 후 받으실 수 있습니다. 정식 애드온이 되었으면 하시는 분들은 리뷰 작성 부탁드립니다. 그런데 영어로 작성하지 않으면 의미가 없다니 고려해주세요. ㅠㅠ 감사합니다. ^^

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 HTML 표준에 대한 이해가 수반된다면 크게 복잡한 과정이 아닙니다. 웹 사이트 개발에 들어가기 앞서 위의 과정을 이해하고 있다면 접근성을 해치면서(?) 사용하는 자바스크립트와 같은 비용으로 자바스크립트가 불가능한 환경의 접근성, 검색엔진 최적화(SEO) 등의 이득을 챙길 수 있습니다. 접근성을 보장하는 것이 그렇지 않은 것에 비해 추가비용을 필요로 하는 것은 사실이지만 그 추가비용 안에 위의 언급한 이득은 포함되어 있지 않습니다. 즉, 위의 이득들은 꽁짜란 얘기죠. ㅋ 실제로 미투데이라는 서비스의 경우 자바스크립트를 제거한 상태에서도 정확하게 원하는 기능을 사용할 수 있고, 자바스크립트가 이 기능들을 좀 더 편하고 신속하게 이용할 수 있는 보조장치로 쓰인 모습을 볼 수 있습니다.

그 다음엔?

자… 그럼 이렇게 하면 끝일까요? 사실 아닙니다. 그 이유는 말빨이 부족한 제가 설명하는 대신 유명한 웹 접근성 관련 블로그인 456 Berea Street의 Roger Johansson옹의 글 Reading up on WAI-ARIA에서 따왔습니다.

One of the more problematic areas of web accessibility is how to handle the custom widgets and dynamic changes to content used in most web applications and on many content-based websites.

Using JavaScript to add custom behaviour and update content can cause problems for people who rely on assistive technology (AT) such as screen readers. The problems often consist of the AT not being aware that content on the page has changed, the user not noticing that something has changed, or the user being aware that something changed but not what.

웹 접근성에서 상당히 골칫거리인것들 중에 하나가 커스텀 위젯이나 대부분의 웹 어플리케이션이나 많은 컨텐츠 중심 웹 사이트들에서 사용된 컨텐츠의 동적인 변경을 어떻게 다루느냐하는 것이다.

자바스크립트를 사용하여 특정 동작을 추가하고 컨텐츠를 갱신하는 것은 스크린리더와 같은 보조기기에 의지하고 있는 사람들에게 문제를 일으킬 수 있다. 그 문제란 대개 보조기기가 페이지의 컨텐츠가 변경된 것을 감지하지 못하여 사용자가 무엇인가 바뀌었다는 것을 알지 못하거나, 혹은 사용자가 무엇인가 바뀌었다는 것은 알지만 그게 무엇인지는 모르는 문제를 가리킨다.

그래서 나온게 WAI-ARIA입니다. 자, 그러면 당장 적용을 시키면 되나? 그렇습니…다라고 말씀을 드려야 하지만 좀 상황이 편하지만은 않습니다. WAI-ARIA라는 스펙 자체가 초안(Working Draft) 상태라 아직 표준으로 인정할 수 없는 상태이고 국내에서 유명한 스크린리더인 센스리더는 WAI-ARIA의 W자도 찾아볼 수 없습니다. 구현이 전혀 안되어 있다는 얘기죠.

구글리더는 ARIA 기능을 사용할 수 있는 감춰진 링크를 제공하고 있다.

보조기기들도 지원안하는 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 하실 수 있습니다. 마찬가지로 센스리더 등의 보조기기 제작사에서는 구현된 사이트도 없는데 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 할 수 있고요. -_-;;;

둘 중 누가 먼저라는 걸 서로 주장하는 것도 웃깁니다. 오히려 서로 시급히 도입해야 할 판국이죠. 그렇지 않습니까? ^^

지금 당장은?

우여곡절 끝에 접근성을 해치치 않는 자바스크립트를 사용하고 그 위에 WAI-ARIA까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)

쬐금 공부해본 결과물을 공유합니다. 이미지의 모서리를 둥글게 하는 스크립트 예제입니다. 사용한 이미지가 조금 거시기하니 뭐 드시는 중이시거나 비위가 약한 분들은 조심하세요. -_-;;

원래 animated gif 파일인데 canvas를 사용하면 안되네요. 안되는건지, 제가 방법을 못 찾은건지… 원본이 궁금하신 분들은 원본 이미지를 보셔요. ㅋㅋ

변경 사항

MiyaValidator 클래스의 add 함수와 addGroup 함수의 리턴값이 변경되었습니다. 특별히 폼 유효성 검사 외에 다른 작업을 하지 않으셨다면 사용상 변화된 점은 없습니다.

add 함수의 리턴값

MiyaCondition의 instance에서 MiyaValidator의 conditions 변수의 해당 index값으로 변경

addGroup 함수의 리턴값

MiyaGroupCondition의 instance에서 MiyaValidator의 groupConditions 변수의 해당 index값으로 변경

추가 기능

fileonly 속성 추가

첨부파일의 확장자를 제한합니다. 이미지파일의 확장자를 검사하는 imageonly 속성과는 별도로 업로드 가능한 첨부파일의 확장자를 직접 선언할 수 있는 속성입니다. 다음과 같은 방식으로 사용하실 수 있도록 구현됩니다.

var v = new MiyaValidator(form);

v.add("somefile", {
fileonly: ["hwp", "doc", "xls", "ppt"],
message: "아래아 한글 또는 MS 오피스의 문서 파일만 업로드 하실 수 있습니다."
});

trim 속성 추가

입력값의 공백을 제거 후 검사할 수 있는 속성입니다. 공백 제거 방법에 따라 다음과 같은 값을 입력할 수 있습니다. 입력값은 trim 속성에 따라 공백이 제거된 후 검사되지만 실제 사용자의 입력값은 그대로 유지되며 전송시에도 공백이 사용자가 입력한 상태대로 전송됩니다.

"trim" 또는 true

입력값의 시작부분과 끝부분의 공백을 제거합니다.

"ltrim"

입력값의 시작부분의 공백을 제거합니다.

"rtrim"

입력값의 끝부분의 공백을 제거합니다.

"compress"

입력값의 모든 공백을 제거합니다.

minlength 속성 추가

HTML4의 maxlength의 반대개념으로 최소 글자수를 설정합니다.

min/max 속성 추가

입력된 값의 최소/최대값을 정의합니다. 값은 반드시 숫자로 입력되어야 합니다.

법인번호(jurino) 형식(MiyaFormat) 추가

오류 수정

requiremax 속성의 메시지 오류 수정

에러 메시지의 오류를 수정하였습니다. 프로그램 동작에 영향을 미치는 부분이 아니기 때문에 0.1 버전에도 수정 반영되었습니다. {requiremax}개 이상이하의 항목이 입력되어야 합니다.

Special Thanks To

0.2 버전의 모든 기능을 제안해주신 RedCat Caravan님께 진심으로 감사드립니다.

웹 페이지를 제작하면서 자바스크립트를 어떤 부분에 사용해야겠다라고 마음 먹으면 우리는 자바스크립트를 표시하는 <script> 태그를 쓴다. 앞서 얘기한 설계대로 <script> 태그의 사용 가능하지 않은 경우를 위해 <noscript> 태그를 쓸 수 있다. 어플리케이션 레벨이 아닌 마크업이 잘 되어 정상적인 기능을 하는 HTML 문서에 부가적인 사용자 편의성의 증대를 목적으로 사용하는 자바스크립트라면 <script> 태그가 동작하지 않을 경우 자바스크립트가 없는 HTML 문서와 같이 작동하게 되므로 굳이 <noscript> 태그가 필요하지 않을 것이다.

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <a href="javascript:checkForm();">전송</a>
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
function checkForm() {
    var form = document.getElementById("f");
    if (form.elements["job"].value == "") {
        alert("직업을 입력해주세요.&quot);
    } else {
        form.submit();
    };
};
// ]]>
</script>

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <input type="submit" value="전송" />
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
if (document.getElementById && document.getElementById("f")) {
    var form = document.getElementById("f");
    form.onsubmit = function() {
        if (this.elements["job"].value == "") {
            alert("직업을 입력해주세요.&quot);
            return false;
        };
    };
};
// ]]>
</script>

모든 사용자가 당신의 자바스크립트 코드를 실행할 수 있을 것이라고 기대하지 말아야 한다. 또, 어떤 사용자는 당신의 자바스크립트 코드 중 어떤 부분을 제대로 해석하지 못한다는 것을 알아야 한다.

자바스크립트는 플래시, ActiveX와 같은 외부 플러그인과 개념 상 다르지 않다. 오히려 언급한 것처럼 사용자에 따라 불완전하게 실행될 가능성이 있기 때문에 더 다루기 어려운 기술임을 인식하여야 한다.

참고 링크

• Unobtrusive JavaScript – wikipedia
• Behavior Seperation – A List Apart
• 자바스크립트를 올바르게 사용하기 – Sangini World
• 접근성을 해치지 않는 자바스크립트의 사용 – 신현석

마지막 업데이트: 2008년 4월 25일 04시 30분

종류로는…

• element 얻기 – gE
• element 보이고 숨기기(table 기반 레이아웃에는 적합하지 않다..) – sE, hE
• z-index style 지정 – sZ
• element의 left position set – sX
• element의 top position set – sY
• element의 가로길이 set – sW
• element의 세로길이position set – sH
• clip set – sC
• write HTML – wH

등이 있다.

제목처럼 1k로 용량도 작은데다가, 개발자가 element handling에 있어 시간을 들여 cross browsing을 크게 신경쓰지 않아도 되니 여러모로 좋을 것 같다. :)

어떤게 JS고 DOM인게 무슨 소용인가? 아니다. 활성화된 커뮤니티에서 문제를 해결할 수도 있겠지만, 그렇지 못할 때에는 매뉴얼을 보아야한다. 에러가 난 부분이 JS인지 DOM인지 알아야 매뉴얼을 찾아볼 수 있지 않겠는가?

분류는 쉽다! html element를 가리키면 DOM이고 아니면 JS다. frame등을 가리키는 것도 DOM이다.

이제 DOM인지 JS인지 알았다면, 매뉴얼을 잘 찾아보는 일만 남았다.

DOM은 W3C DOM Technical Reports (HTML 접근 부분은 DOM Level2 HTML)에서 볼 수 있다.

JS는 Syncro.net의 Core JavaScript Reference (devedge.netscape.com이 좋은 reference 사이트였으나 없어졌다. ㅠㅠ)를 보면 되겠다.

<html>
<head>
<script type="text/javascript">
function checkForm(form) {
    if (form.elements["title"].value == "") {
        alert("제목을 입력해주세요");
        return;
    }
    form.submit();
};
</script>
</head>
<body>
<form action="someaction">
    <p>
        제목 <input type="text" name="title" />
        <input type="submit" value="전송" />
        <a href="javascript:checkForm(document.forms['someaction'])">전송</a>
    </p>
</form>
</body>
</html>

<html>
<head>
<script type="text/javascript">
function checkForm(form) {
    if (form.elements["title"].value == "") {
        alert("제목을 입력해주세요");
        return false;
    }
    return true;
}
</script>
</head>
<body>
<form action="someaction" onsubmit="return checkForm(this)">
    <p>
        제목 <input type="text" name="title" />
        <input type="submit" value="전송" />
    </p>
</form>
</body>
</html>

위는 나쁜 녀석이고, 아래는 좋은 녀석이다. -_-;;

위의 코드가 무엇이 나쁜고 하니.. JavaScript가 인식되지 않는 브라우저에서는 "javascript:checkForm()" 식의 링크가 어떤 지시를 내리는지 알 수가 없다. "checkForm()" 자체가 JavaScript니까… 따라서 폼 체크를 할 수 없고 서브밋은 꿈도 못꾸게 된다.

반대로 아래의 코드는 기본적으로 HTML에서 폼 서브밋에 사용되는 submit button이 있어 서브밋에 지장이 없다. 폼 체크의 경우에는 JavaScript엔진이 있으면 onsubmit 메소드가 호출되어 checkForm function을 탈 것이고 없다면 onsubmit 메소드가 무시되어 아무런 에러없이 서브밋이 될 것이다.

form 값을 받은 action page에서 해당 값들을 체크하는 센스는 당연히 가지고 있을 것으로 생각한다. :)

아! 근데 이런식이라면 text로 폼 전송을 못하지 않는가? 그렇다. -_-; 안타깝게도 HTML만으로는 단순한 text가 폼 전송의 역할을 할 수 없다.

우리나라 웹시장의 웹디자인 마인드로는 심각한 일이지만, 웹이라는 녀석의 기본 목적 상 큰 문제가 될 것이 없다는 것으로 결론을 내린다! 무책임하다고 하신다면 죄송할 따름.. ㅠㅠ

다음 시간에 계속 쓰겠습니다.. :)