Monthly Archives: December 2007

W3C의 HTML5 스케줄은 신뢰할 수 없다?

오늘 WHATWG Wiki에서 흥미로운 내용을 접했다. W3CHTML5 스케줄은 신뢰할 수 없으며 2022년이나 그 이후에나 W3C의 권고안이 될 것 같다는 내용이다.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That’s actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 still, more than ten years later, hasn’t reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren’t interoperable, and the spec has hundreds if not thousands of known errors that haven’t been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

HTML5가 W3C 권고안(Recommendation)이 되는 시점은 2022년 혹은 그 이후가 될 것으로 추정됩니다. 이것은 2004년 중반에 시작하여 대략 18~20년의 개발 기간이 되는 것입니다. 그것은 사실 그렇게 황당한 게 아닙니다. HTML4의 작업은 90년대 중반에 시작하여 10년이 넘었지만 아직 우리가 HTML5를 통해 도달하고 하는 레벨에 이르지 못했습니다. 실제 테스트 슈트가 없고, 많은 부분의 스펙이 현실에 충족하기에 부족하고, 수백·수천의 알려지지 않은 오류가 수정되지 않았습니다. HTML4가 나왔을 때, 권고안은 현재의 그것보다 훨씬 흥미가 작아졌습니다.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

현재 어떤 스펙이 권고안이 되기 위해서는, 100%의 완성도와 완벽한 상호 작용이 필요합니다. 이 말은 각각의 요소가 수천번의 테스트 케이스를 완전하게 통과함을 뜻합니다(대략적으로 20,000개의 테스트가 필요할 것으로 추정됩니다). 당신이 그런 많은 테스트 케이스를 작성하는 데에 걸리는 시간을 고려한다면 각 기능을 구현하는 시간이 얼마나 걸릴지 이해할 수 있을 것입니다.

(In the interests of full disclosure, the W3C’s official line is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, as of December 2007 the W3C had already missed the first milestone on that same timetable, First Public Working Draft, by 6 months, with no reason to believe publication would come soon. You can make your own judgements regarding the W3C timetable’s credibility.)

(완전한 공개를 위하여 W3C의 공식적인 라인은 HTML5 스펙이 2010년 말에 상호 운용성을 보장하며 완료될 것이라고 합니다. 그러나 2007년 12월 현재 W3C는 이미 같은 스케줄에 표시된 공개 초안 초판(First Public Working Draft)이라는 첫번째 마일스톤을 6개월이나 놓치고 있습니다. 게다가 이 마일스톤은 곧 출시될 것이라고 믿을만한 이유가 없습니다. 여러분은 W3C 스케줄의 신뢰성에 대한 심판을 스스로 할 수 있을 것입니다.)

FAQ의 When will HTML5 be finished(HTML5는 언제 완료되나?)

위의 번역은 정확하지 않을 수 있음.

생각해보면 이전에도 W3C의 스케줄은 그다지 신뢰를 주지 못했던 것 같다. CSS3의 스케줄만 해도 예정이 1년이상 지난 것들이 많다. HTML5의 Milestone – 2008년에는 W3C에서 초안으로 라는 글을 얼마전에 썼었는데 W3C HTML Working Group의 마일스톤은 수정되어 있다. 그것도 꽤나 큰 기간 차이를 가지고 – 마무리 시점은 동일하지만.

그러나 위에 언급한 2022년이라는 숫자에 놀랄 필요는 없다. 글 내용에도 나왔듯 HTML4 조차 아직도 부족함이 있고 – 정확히 무엇이 부족한지는 잘 모르겠다 – 실제로 2010년 정도가 되면 어느정도 기기나 브라우저들이 지원해 줄 것으로 생각된다. 물론 그 때도 거의 대다수가 HTML4 혹은 Invalid HTML을 사용할 것으로 생각되지만.

Miya Validator 0.2 버전 출시.

Miya Validator에 몇가지 기능을 추가하여 0.2 버전을 공식배포합니다.

변경 사항

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님께 진심으로 감사드립니다.

이전 글들을 복구하였습니다.

이전에 tistory 블로그나 tenshi.pe.kr(현재 존재하지 않습니다.)에서 썼던 몇몇 글들을 복구하였습니다. 좀 어리숙하고 지금과는 맞지 않는 글이 많습니다만 그래도 제가 포스팅했던 글들이니 소중히 간직하고 싶어서요. 신변잡기나 푸념 같은 글은 뺐습니다. 코멘트는 복구하지 않았습니다. 왠지 복구하지 않는 게 맞을 것 같아서요. 더 옛날 글들은 어디론가 사라져 버렸습니다. 흑흑;;

내가 웹 표준을 하는 이유

스스로 웹 표준을 하는 이유에 대해 좀 정리할 필요를 느껴 간단히 적어 보았습니다.

남들이 하니까…

우스갯소리처럼 들리겠지만 사실 그렇지 않다. 어떤 일을 시작하는데 그런 일을 하는 다른 사람들이 모두 A라는 방식으로 일을 한다면 당연히 A로 하는 게 맞지 않는가? B라는 대안을 스스로 찾는다면 그것은 A를 충분히 이해하고 있을 때의 이야기이다. 아직 웹 표준에 대한 이해가 충분하다고는 생각하지 않지만 현재로서는 나도, 다른 이들도 웹 표준에 대한 대안을 가지고 있지 않다. 그리고 적어도 발전안은 있어도 대안은 존재하지 않을 것 같다.

의미있는 마크업 (Semantic Markup)

웹 표준이 아닌 마크업 예제

<font size="4"><b>웹 표준 관련 사이트</b></font>
<table cellspacing="0" cellpadding="0" border="0">
	<tr>
		<td><img src="bullet.gif"> Standard Magazine</td>
		<td><img src="bullet.gif"> KWAG</td>
		<td><img src="bullet.gif"> Web Standards Korea</td>
	</tr>
</table>

웹 표준 마크업 예제

<h3>웹 표준 관련 사이트</h3>
<ul>
	<li>Standard Magazine</li>
	<li>KWAG</li>
	<li>Web Standards Korea</li>
</ul>

위의 두 코드는 웹 브라우저에서 시각적으로 같은 결과물을 갖는다. 그러나 웹 표준이 아닌 마크업 – 웹 브라우저의 시각적 결과물에 의존한 – 은 시각적인 결과물 외에는 다른 의미를 갖지 못한다. 단어들 간의 상관관계, 중요도 등이 없기 때문에 시각적 요소를 인지할 수 없는 CUI 기반의 사용자, 스크린 리더 사용자, 기계(검색엔진 등) 등은 웹 표준이 아닌 마크업을 이해하는 데 웹 표준 마크업에 비하여 그 정도가 크게 저하된다.

웹 사이트 전체가 웹 표준이 아닌 마크업으로 구성되어 있다면 앞서 언급한 시각적 요소를 인지할 수 없는 사용자들은 웹 사이트에 표시되는 수많은 단어들을 차례대로 훑어가며 원하는 정보를 찾기 위한 쓸데 없는 노력을 해야 할 것이다. 그것도 그 단어들이 다행이도 텍스트로 되어 있을 때의 이야기지만.

상위 호환성(Forward Compatibility)

새로이 출시되는 웹 기반 기기나 소프트웨어는 대부분 W3C의 표준 명세를 준수하고 있고 그 비율 또한 증가되고 있다. 웹 표준에 기반한 마크업 문서는 이에 따라 상위 호환성을 갖는다. 그렇지 않은 문서에 비해 웹 표준에 기반한 문서는 그만큼 높은 가치를 갖는다.

대다수 웹 제작자들의 웹에 대한 인식 부족

이것은 웹 표준을 하는 이유라기 보다는 웹 퍼블리셔를 하는 이유이다. 국내에 "웹 퍼블리셔"라는 직종이 존재하는 이유라고도 여겨진다. 웹에 대한 인식이 부족한 웹 제작자들의 교육을 목적으로, 그 결과물의 보정을 위해 이러고 있다.

기업의 이윤 추구와 웹 표준

장사 하루 이틀 할 것 아니니까 웹 표준 합시다! 구구절절하게 따져보고 싶으시면 토론합시다. Standard Magazine에서 많은 분들에게 다양한 얘기도 들어보시면서 하시면 더 좋겠네요.

끝.

Opera Mini 4, iPhone Safari의 영향을 받다.

Opera Mini 4가 2007년 11월 4일 출시되었다. iPhone Safari의 영향을 받은 것일까? Opera Mini 4 역시 iPhone Safari와 동일한 일반 PC와 같은 소위 풀 브라우징을 지원한다.

Opera Mini 공식 사이트의 Features에서도 언급하고 있지만 Opera Mini 4는 기존에 기본으로 설정되어 있던 Mobile View라는 Opera Mini 특유의 기능 – 모든 컨텐츠를 선형화하는 – 이 별도의 옵션으로 숨어버리고, 풀 브라우징이 기본 설정이 되었다. 이동통신사의 회선을 사용하여 인터넷을 사용하는 이들은 여전히 Mobile View 옵션을 사용하겠지만, 풀 브라우징이 기본 설정이 되었다는 것만으로 해외 모바일 인터넷 시장의 동향을 간접적으로 알게 해주는 것 같다.

Dev.OperaOpera Mini 4 is here!이라는 글과 Opera Mini Simulator는 웹 사이트 제작 시 Opera Mini 4를 고려하고자 한다면 많은 참고가 될 것이다.

아직 우리나라에서 모바일 인터넷 기기의 접근성이나 사용성은 신경쓰지 않아도 될 만큼 사용자가 드물지만 1년 후만 되어도 얘기가 달라지지 않을까 생각한다. Firefox에서도 제대로 이용할 수 없는 대부분인 국내 사이트들, 걱정된다.

HTML5의 Milestone – 2008년에는 W3C에서 초안으로

HTML5의 2010년말까지의 일정이 W3C HTML Working Group 페이지에 공개되어 있습니다. 이하 공개되어 있는 일정입니다. 자세한 사항은 HTML Working Group Charter에서도 확인 가능합니다.

  • 2007-05 HTML5 and Web Forms 2.0 specs adopted as basis for review
  • 2007-11 HTML Design Principles First Public Working Draft
  • 2008-03 HTML5 공개 초안 초판 (First Public Working Draft)
  • 2008-06 HTML5 최종 초안 (Last Call Working Draft)
  • 2008-09 HTML5 권고안 (Candidate Recommendation)
  • 2010-06 HTML5 권고 후보 (Proposed Recommendation)
  • 2010-09 HTML5 권고 (Recommendation)

현시점에 HTML5는 W3C에 있어 Editor’s Draft입니다만, 내년부터 초안(Working Draft)가 되어, 2010년에는 권고(Recommendation)이 되는 일정을 예상하고 있습니다.

현단계의 W3C의 HTML5 Editor’s Draft (WHATWG에서는 Working Draft)에는, 아직 완성되지 않은 목차가 많이 있어, 나날이 눈에 띄일 정도로 업데이트 되고 있습니다만, 내년이래, Working Draft로서 일단 완성된 모습이 될 듯 합니다.

다음(daum)의 CSS 지원 향상

지난 수요일 시작된 email standard project과 관련하여 국내 유명 웹메일 CSS 지원 테스트를 올렸었는데 그새 다음(daum)CSS 지원의 향상이 있었다. 지금 막 확인한 사항이지만 테스트 시 지원하지 않거나 불완전하였던 background-image와 list-type-image의 지원이 추가되었다.

2007년 12월 3일 다음(daum) 웹메일 CSS 지원 테스트 결과

메일 컨텐츠 중 어떤 태크나 ID 값에 “x-” 라는 prefix를 붙였었는데 그 대상을 크게 줄인 결과인 것 같다(확인한 바로는 meta 태그에만 붙이는 것으로 변경되었다). ESP의 효과인지는 알 수 없지만 다음(daum)의 이번 변화는 훌륭한 것이라고 생각된다. 이제 모든 화살을 네이버에게…ㅋㅋ

다음(daum)은 이제 default CSS에 의해 덮어씌여진 font-family 속성을 사용할 수 있도록 수정하면 ESP의 추천사항을 전부 충족할 수 있다. cheer up!