네이버 탑페이지 HTML 유효성 검사 통과
site | 2008-03-10
다음에 이어서 네이버도 탑페이지의 문법기준을 강화하여 HTML 유효성 검사를 통과했다. 가끔 문제가 발생한다고 하지만 내가 체크 했을 때 통과를 못했던 적은 없었다. 인라인으로 들어가 있던 스타일과 스크립트도 상당히 많이(거의 200~300줄 정도) 줄어들었다. 페이지 용량도 플래시를 제외하면 300KB도 안될 정도로 가볍다.
HTML 유효성 검사는 아주 기초적인 것이고 많은 퍼블리셔들이 이를 기본적으로 지키고 있지만 실제로 웹사이트가 이를 통과하는 경우는 드물다. 난이도가 높은 일이기 때문은 아니고 최종 코드 유지에 퍼블리셔가 깊게 관여하여 기존의 "걸레 HTML"을 만들던 프로세스를 바꿔야 하기 때문에 어려운 것이다.
다음이 이를 가장 먼저 실천에 옮겼고, 드디어 네이버도 그 뒤를 따르게 되었다. 둘다 국내 최고의 포털 기업이고 최고의 이름에 걸맞게 선두적으로 이러한 큰 변화를 이룩해 냈다. 내부적으로는 수많은 이슈사항, 반발들이 있었을 것이다. 그 모든 어려운 과정을 거치고 이런 대단일 일을 이뤄낸 NHN WS팀에 박수를 보낸다.
Share on
Recent Comments
- ㅇㄴㅇㄴ 사무직을 하다가 그만두고 국비지원 학원을 다닌 후 현재 리액트 개발자로 일하고 있습니다 다행인지 불행인지(?) 컴퓨터 학원을 간게 아니라 디자인 학원을 가게 되었고 그곳에서는 퍼블리셔와 프론트엔드 개발자의 용어를 혼동해서 사용하였습니다 즉 저는 한동한 "HTML 마크업 + 스타일링 + 약간의 이벤트" 오로지 "사용자가 보고 있는 부분"만 다루는 작업이 "프론트엔드 개발"로 알고 있었습니다 ============> 우리가 흔히 퍼블리셔라고 불리는 영역입니다 하지만 학습할수록 사용자 영역과 소위 백엔드라고 불리는 영역과의 호환이 필요하다는 것을 알게 되었고 그때부터 지금까지 배웠던것과 전혀 다른 역할과 기능들을 학습하게 되었습니다 즉 자바스크립트도 event와 document 부분이 아닌 배열과 객체를 편집하는 것을 배워야 하고 API를 호출해 어떻게 사용자 영역으로 가져와야 하는가 등등 기존 퍼블리셔 역할군과 전혀 다른 것들을 다루게 되었습니다 ============> 이것이 프론트엔드 영역입니다 제가 두 가지 길을 모두 걸어본 바 프론트엔드 개발은 퍼블리셔의 완벽한 상위 호환이고 추구하는 목적도, 기술도 완전히 다릅니다 처음부터 다른 길을 가야하고 생각의 구조도 다르게 가야합니다 그런 의미에서 처음에 퍼블리셔라는 말이 처음에는 편가르기 하는것처럼 싫었지만 지금은 명확하게 길을 제시한다는 관점에서 좋다는 생각을 해봅니다 2024-05-20
- 잘 읽고갑니다. 마이크로소프트에 대한 저자의 태도가 인상적이었네요 2024-03-15
- southRain 좋은 글과 댓글 잘 보았습니다. 저 역시 이 업계의 일을 하는 사람으로써 '웹퍼블리셔' 라는 단어를 만드신 분을 이제 알았네요. 해당 용어를 만들어주셔서 감사합니다. 그 덕에 제 업무에 대한 명확한 기준을 세울 수 있었습니다. 전 이제껏 '웹퍼블리셔' 라는 직무에 부끄러운 적 없었습니다. '웹 퍼블리셔' 라는 직무를 부끄러워 하는 건, 본인이 해당 업무를 제대로 이해하지 못하고 잘 수행하지 못하기 때문이라고 생각해요. 해외와 국내의 개발업무 포지션에 대한 단어가 다를 뿐인데, 유독 국내 개발자들 중에는 굳이 급을 나누는 분들이 많더라구요. 근데 그렇게 급을 나누는 만큼 기본이 되어있는지 의심스러울 때도 많았습니다. 퍼블리셔와 상의없이 css framework 로 화면 대충 만들다가... 디자이너 요청 대로 화면 수정 못하고 대뜸 찾아와서는 수정해달라고 하는 적도 많았고... 만들어 준 화면도 자기 맘대로 이것저것 손대다가 오히려 화면 다 틀어지는 경우도 많이 봤습니다. 이런 걸 보면 오히려 '프론트엔드 개발자' 라고 본인을 지칭하는 분들이 해외와 전혀 다른 개념으로 이해하고 있는 게 아닌가 라는 생각도 들었습니다. 이제는 면역이 되서... 그런 분들 만나면 '그러려니...' 하고 말지만요. ㅎㅎ 각자가 맡은 업무가 있는 거고, 각자의 업무를 서로 존중하는 환경이 필요하다고 생각합니다. 그리고 각자의 자리에서 본인 업무를 충실하면 되지 않을까 싶습니다. 2024-03-05
- 리베하얀 할말이 많지만... 한국에만 있는 직업이라는 것에 대해서 전혀 개의치도 않고 부끄러워할 이유도 없다고 봅니다. 이 직업군에 대해서 이해라며녀 00년대에 무슨일이 일어났었는지.. 알필요가 있고 국내만의 특수한 환경때문에 만들어진 직업군이고... 근래에 들어 국제화가 되면서 문제시 몇몇분이 문제삼는것 같은데... 본인의 업무 바운더리는 본인이 만드는거지.. 그 단어안에 갇혀서 본인의 수준이나 인식을 만든다고 보지 않습니다. 코더니 UI개발자니, 퍼블리셔니, FE니.. 웹마스터니 풀스택이니 ㅎㅎ 많은 직업군으로 불리우고 있지만 솔직히 본인의 역량에 따라 불리운다고 생각합니다. 당시에 신현석님이 던진 하나의 단어에 여전히 밥먹고 살고 있고, 때때론 자부심도 느낍니다. 2023-11-26
- Sarah Jeong 안녕하세요. 이런 글타래가 있는지 이제야 알게되어 흥미있게 글타래를 읽어보았네요. 제가 방금 글타래라고 쓴것처럼, 댓글이라는 단어에도 여러 다른 이름이 존재한다는 것을 우리는 암묵적으로 알고 있을 거라 생각하는데요 EX 1.) 글타래(민 우리말. 인터넷 게시판에서 어떤 게시글과 그에 대한 답신으로 쓰여진 게시글들의 모임. [NAVER 국어사전 글 인용]) = 댓글(게시물 밑에 남길 수 있는 글을 표현한 단어) = 코멘트(영어 코멘트를 한국어로 표현한 단어) = 리플(영어 reple을 한국어로 표현한 단어) = 스레드(thread) EX 2.) Height(사물의 높이, 사람의 키&신장, 키가 높음, 지상으로부터의 고도) 해당 단어는 발음에서 논란이 된적이 있습니다. (설마.. 고인물만 아는 거일지도...T^T..) 미국, 영국 등 주요국가에서는 해당 단어의 발음을 한국어 발음 표현으로 '하이트' or '하잍' 라고 읽으나, 스페인어로 해당 단어는 '헤이트' or '헤잍' 라고 읽습니다. 전 세계적으로 스페인어를 쓰는 인구는 2019년 3월 기준으로 4억 6천만명이며, 영어를 사용하는 인구는 3억 7천만명이라고 구글검색에 나옵니다. EX 3.) 2023년 현재 우리나라에서는 각 세대 별로 쓰는 한 가지 표현에 대한 단어들도 다릅니다. 50대 이상이신 분들은 한자어를 주로 사용하신 세대들이고, 10대 ~ 20대분들은 줄임말 또는 은어를 만들어 주로 사용하고 있습니다. 위의 예시와 같이 한 가지를 가리키는 명사에 여러가지 표현이 존재하고, 모든 사람들이 표준어 하나만 사용하고 있지 않으며, 전라도, 충정도, 경상도 방언이 존재한다는 사실도 암묵적으로 우리는 알고 있다 생각합니다 물론, 표준어처럼 한 가지 표현만 존재하면 다시 한번 확인하는 절차없이 의사소통이 원활할테지만, 우리는 일상속에서도 방언이나 댓글, 줄임말 등의 다른 표현들을 받아들이고 있는 존재들입니다. 만드신 분의 말씀대로 그저 지나온 과거에서는 그 표현이 필요하여 쓰여졌었다고 이해하고 넘어가시면 어떨까하여 주절대며 나불거려보았네요.. PS. 쓰잘데기 없는 제 생각을 읽어주셔서 고맙습니다.. AI도 발전해나가고 있는 마당에 같은 인종끼리 싸우지 맙시다~~~ㅋㅋㅋ 2023-11-13
- 신현석 김진원님 알려주셔서 감사합니다. 본문을 수정했습니다. 2023-06-03
- 김진원 php도 더 적은타이핑으로 가능합니다. [$a, $b] = [$b, $a]; 2023-06-03
- 김정규 PHP… ㅋㅋ 2023-06-03
- 신현석 규모 작은 프로젝트에 적용해 보고 있어요. 2023-01-07
- 문지훈 스벨트킷으로 정하셨군요!! 진짜 쉽게 시작할 수 있겠더라구요. 2023-01-07
Comments
아임 컴백! ㅎㅎ 아직 재활 중이지만 참지못해 돌아왔습니다. ㅎㅎ
탑 페이지 뿐만 아니라 전부 해주세요!
단순 통과인줄 알았는데, 마크업도 좀 신경썼네요~ :)
저도 오늘 소스를 쭉 훑어봤는데 재밌네요. 겉보기로는 바뀐게 없지만 코드가 전보다 훨씬 나은 모습이네요.. 박수 짝짝짝~
anchor의 name과 바로 위의 div id가 충돌하는 문제라던가 스크립트가 돈 후의 결과물은 처참합니다만 신경을 쓰기 시작했다는 것에 일단 박수를 ~
격려 감사합니다. 직접 참여했던 프로젝트는 아니지만 저희팀에서도 이것을 작성 성취라고 생각하고 있습니다. 한편 나름 최적화된 코드에도 불구하고 로딩속도에 대한 숙제와 고민은 여전히 진행중입니다. 좋은 하루 되세요!
언제 이렇게 작업하셨는지...대단하네요..이렇게 조금씩 변하는게 보기 좋네요..
겐도님, 약간의 착오가 있으신것 같습니다. anchor name 과 div 의 id 는 충돌하는 것이 아닙니다. Valid 한 부분입니다. 그 부분은 현존하는 스크린리더의 anchor 관련 버그에 대응하는 코드로서 스크린리더가 id 로 처리된 anchor 의 목적지에 반응하지 않기 때문에 a 태그에 name 을 추가적으로 사용한 부분입니다. 문법적으로 유효하지 않았다면 사용하지 않았을 것입니다. ^^
스크립트가 돈 후의 처참한 결과물이 어떤건지 알고싶어요~~^^;
정찬명님. 사용하게 된 이유는 느낌이 왔었습니다만 (브라우저 호환성 문제로) http://www.w3.org/TR/html401/struct/links.html#h-12.2.3 illegal example에 잘 나와 있을 것입니다. 해결하려면 구조를 바꿔야 할지도요.
앵커에 사용한 것을 문서에서 id와 name 둘다 사용하면 안되는 군요. 아마 밸리데이터에서 이것까지 검사는 안하나 봅니다.
허걱 ㅡㅡ; 겐도님 말씀이 옳았군요. Validator 에서 정말 체크되지 않은것도 신기하구요. 일단 초기화면 담당자에게 전달하겠습니다. 날카로운 지적에 감사드립니다.
validator를 통과해서 의심하지 못했는데 따로 쓰면 안되는거였군요^^; 감사합니다~^^
왠지[?!] 기분 좋은 소식이군요. 네이버는 항상 그렇지만... 전체 기업 경영 이념(쉽게 전 '개념'이라고 합니다. ^^;; )보다는 그 안의 구성원들의 한 발짝이 참 마음에 듭니다. 개인적인 좋고 싫음을 떠나서 네이버도 힘냈으면 좋겠네요!!
코드에 관에서 평가하시는분들 많은데요. 그러타면 정말 마크업 잘되있고 핵도 최소화한 여러분이 "아~잘만들었네" 라고 생각하시는 사이트있으면 알려주셔요~ 보고 배울려고요;ㅠ 책으로읽고 네이버/다음같은곳보며서 배우고있는데 제실력에 부족함을 많이 느끼고 있어서요. 물론 직접해보는것이 최고지만 부족한 경험을 빠르게 채우고 싶은 마음에;ㅠ
사이트 규모도 크지 않고 접근성 좋은 사이트로는 정보통신 접근성 향상 표준화 포럼 사이트(http://iabf.kr)가 좋을 것 같습니다.