티스토리 툴바

WebSniper - http://freeutil.net/board/?document_srl=150&mid=pds_freeutils&sort_index=readed_count&order_type=asc IE6~7 웹퍼블리셔&웹개발자를 위한 만능 툴(실시간 태그 검색, 소스보기, 소스분석, 실시간 소스편집)

이런것도 있었군....

저작자 표시 비영리 동일 조건 변경 허락


그동안 본 블로그를 통해서 어떤 사람들이 웹퍼블리셔가 되는지, 웹퍼블리셔들은 어떤 일을 해야 하는지, 문서화의 중요성, 웹퍼블리셔들에게 필요한 가이드라인커뮤니티 사이트 소개, 어떻게 표준화를 지켜갈 것인지, UI개발자와 웹퍼블리셔라는 명명의 문제, 개발 프로세스(웹 개발 프로세스) 등 적지 않은 이야기들을 나름대로 풀어 놓았던 것 같다. 하지만 아직도 뭔가 부족한 것이 있다는 생각을 갖고 있었는데 며칠전 가까운 지인들을 만난 자리에서 한 친구가 중요한 사실 하나를 깨닫게 해주는 이야기를 들려 주었다.

협업은 함께 완성해 나가는 작업이다

어떤 분야든 사람은 혼자서 모든 일을 온전히 해내기란 쉽지 않다. 특히나 우리가 업으로 삼고 있는 IT. 그 중에서도 웹과 관련된 직종은 기술이 점차 발전하고 사용자의 욕구가 높아질 수록 디테일해지고, 세분화 되는 경향을 보인다. 웹퍼블리셔라는 직군만 해도 최근 몇년 사이에 새롭게 등장한 것이며, 근래에는 UI개발자, 마크업개발자, 자바스크립터, 웹퍼블리셔 등 업무의 범위에 따른 구분이 보다 심화되고 있는 실정이다. 하지만 여전히 큰 틀에서 바라보면 웹은 웹기획자와 웹디자이너, 웹개잘자 그리고 웹퍼블리셔(UI개발자)의 협업으로 완성된다. 내가 친구로부터 새삼 깨달은 것이 바로 이것이고, 지금 말하고 싶은 것이 바로 이것- 협업에 관한 것이다.

업계에서는 흔히 Co-work 이라고 부르는 이것은 사실 새삼스러울 것도 없고, 특별한 설명이 덧붙여지는 것도 아니다. 하나의 프로젝트를 위해서 각기 기술을 가진 이들이 서로 의견과 생각을 나누고, 업무를 나누며, 일사분란하게 일을 처리해서 완성해 나간다는 것인데 웹퍼블리셔에게 있어 이 협업이 다른 직군보다도 중요한 요소일 수 있다고 본다.

웹퍼블리셔 중심의 웹 표준 개발 프로세스

웹퍼블리셔 중심의 웹 표준 개발 프로세스

웹 개발 프로세스 에서도 언급했던 내용인데 웹 표준으로 진행되는 프로젝트의 경우 점차로 웹퍼블리셔의 역활이 중요해진다. 기획 단계에서부터 사이트 오픈과 이후의 유지보수까지 전 단계에 걸쳐 웹퍼블리셔는 빈 자리를 찾아 볼 수 없다. 기획자와 함께 스토리보드를 대신하는 구조적 HTML 문서(마크업)를 만들고, 웹디자이너와 웹접근성 관련 이슈들을 논의하면서 최적의 디자인 가이드라인을 만들어야 하며, 이에 맞는 적절한 CSS를 작성한다. 개발자와는 오픈 이후에도 웹표준을 준수하는 사이트를 위한 표준화 가이드라인을 제작하면서 검증 작업을 수행해야 한다. 오픈 이후의 유지보수를 통해서도 사이트의 웹표준 준수를 유지시켜야 할 책임도 가진다. 꽤나 부담스러울 있기는 하지만 그만큼 웹퍼블리셔에게 있어 다른 직군들과의 협업 문제가 중요함을 집어낼 수 있다.

그래서 웹퍼블리셔들에게는 대인 관계가 좋고 업무적으로 마찰을 줄이면서 효과적으로 협업을 이끌어 갈 수 있는  마음가짐 내지는 자세가 요구되고, 때때로 훌륭한 PM이나 팀장, 기획자들로부터 배울 수 있기도 하다.

경험적으로도 내부든 외부든 개발자들과의 소통이 원할하지 않아(대체로 개발자가 멍청하거나 무능력하다고 생각하면서- 또는 알면서도 게을러서 해주지 않는다고 생각하는-) 마무리 단계의 프로젝트가 산으로 버리는 경우가 많았다. 자신의 디자인에 자부심이 지나친 디자이너와 의견이 맞지 않아서 감정적으로 화가 나서 제대로 일을 처리해 주지 않았던 적도 있었다. 기획자는 또 어떤가! 훌륭한 기획자도 많지만 그렇지 않은 경우도 적지 않다. 그들과 일을 함께 할 때는 차라리 내가 기획을 하고 말겠다! 라는 전직의 희망(?)까지도 꿈틀대곤 했다. 이런 프로젝트는 분명히 엉망이 되어 버리곤 했다.

과거에는 기획자만이 디자이너와 개발자 그리고 클라이언트 사이를 오가며 온갖 원망과 모욕을 받아내며 버티곤 했다. 굳이 지금에 와서 웹퍼블리셔가 그 역활을 해야 한다는 것은 아니다. 앞으로의 웹퍼블리셔들에게 확실히 요구되는 것은 내 경험이나 지금 바로 현업에서 일을 하고 있는 웹퍼블리셔들이 이미 느끼고 있을 그것을 자신이 풀어야 한다는 것이다. 웹기획자와 웹디자이너 그리고 웹개발자. 조금 더 깊게는 클라이언트까지 충분한 지식과 경험으로 설득하고, 제안하며, 때로는 현실적으로 타협해 가면서 서로간의 업무가 단순히 기계적이지 않고 인간적으로 손을 맞잡고 함께 풀어가야 한다는 인식을 가져야 한다는 점이다.

HTML, CSS, JavaScript, DOM, Web Accessiblity 등 웹표준과 관련된 다양한 기술과 이론들을 충분히 배우고 알고 있더라도 협업에 대한 현실적인 마음가짐이 부족하다면 웹퍼블리셔로서의 당신은 충분한 자격이 없다고 봐야 할지도 모르겠다.

저작자 표시 비영리 동일 조건 변경 허락


이 글은 서버사이드 개발자님들께서 웹퍼블리셔로부터 받은 HTML문서를 작업하는데 있어서 최소한으로 알아주셨으면 하는 내용을 정리한 것입니다. 일부분 상세히 적지 않고(버전별 요소와 속성의 사용 유무 등) 최대한 쉽게 작성하는데 목적을 두었기 때문에 실 작업시에는 웹퍼블리셔와의 커뮤니케이션과 좀 더 정확한 스펙 문서를 참고해 주시기를 부탁드리겠습니다.

웹표준화와 관련하여 웹퍼블리셔는 정확한 Doctype 선언으로부터 마크업을 시작한다. 그리고 올바른 마크업(well-formed) 검증(validate)으로 작업을 마치게 된다. 하지만 많은 경우 사이트가 오픈했을validate를 통과가 어렵다. 이는 서버사이드 개발자들이 웹퍼블리셔로부터 받은 (X)HTML 문서를 수정(개발을 입히는 작업)하면서 올바르지 않은 요소와 속성을 사용하기 때문인 경우가 많다.

서버사이드 언어인 ASP나 PHP, JSP 등은 문법오류에 대한 관용이 적기 때문에 즉각적으로 에러를 보여준다. 하지만 (X)HTML은 브라우저에 따라 관용적으로 처리되거나, 용납되는 경우가 많아 올바르지 않은 마크업을 하고도 화면이 정상적으로 보이는 경우가 많다. 하지만 이렇게 완성된 사이트는 결코 웹표준 사이트라고 볼 없거니와, 웹접근성 또한 보장받을 수 없게 된다.

XHTML 스펙을 살펴보면 잘못된 요소와 속성의 사용을 알 수 있지만 대부분의 경우 서버사이드 개발자들은 과거에 익혔던 HTML 문법만을 기억하고 있으며(그다마 올바르지 않은 문법) 새로운 XHTML에 대한 차이를 잘 알지 못한다.

다음은 W3C의 HTML / XHTML 스펙 문서 목록이다.

다음은 XHTML 기준으로 개발자 역시 함께 알아야 하는 내용들이다.

  • HTML 문서의 Doctype이 무엇인지 확인한다.

    HTML 4.01과 XHTML 1.0 에는 각각 'Strict(가장 엄격)', 'Transitional(전환형)', 'Frameset(프레임셋형)' 세가지 타입이 있다. XHTML 1.1은 'Strict'만을 지원하며, 표기는 XHTML 1.1로만 합니다.

    Doctype에 따라 사용 가능한 요소와 속성이 구분되며, CSS에도 영향을 미친다.

  • Doctype 선언 위에 출력되는 요소나 문자열이 없도록 한다.

    DTD는 HTML 문서의 최상단에 선언되어야 한다. 그렇지 않을 경우 일부 브라우저(IE 등)에서 비표준모드(Quirks mode)로 작동하게 된다. 일부 스타일이 제대로 적용되지 못하는 문제가 종종 발생한다.

  • XHTML일 경우 모든 요소와 속성은 소문자로 작성하며, alt와 title 속성을 제외하고 가능한 모든 속성에는 값을 넣어(대부분 넣지 않아도 에러가 나지는 않으나 alt와 title 속성을 제외하면 특별한 이유 없이 빈 값을 넣는 경우는 드믈다)준다. 또한, 모든 속성값은 반드시 인용부호로 둘러싼다.

    validate의 에러를 가장 많이 내는 주범이다.
  • XHTML일 경우 모든 요소는 반드시 닫아주어야 한다. 특히 <head>..</head>사이의 <meta> 요소 작성시 반드시 닫아주자! 또한, 요소의 위치관계를 정확하게 한다.
    <p>내용</p> , <br />, <img src="..." />, <meta ... />, <link rel=".." ... />

    (x) <a href="..."><span>링크</a></span>
    (o) <a href="..."><span>링크</span></a>

  • XHTML 1.1일 경우 <a>, <map>, <form>, <img> 요소에서 name 속성이 폐지되어 사용할 수 없다.

    id 속성만을 사용한다. 하지만 <form>내 <input> 등 요소에서는 name 속성을 사용할 수 있다.

  • MIME Type이 'application/xhtml+xml'일 경우 script와 style 요소는 '<!--'과 '-->'를 '<![CDATA[ '와 ']]>'로 대체한다. 단, 'text/html'일 경우는 과거처럼 주석 방식을 사용한다.

    CDATA는 script와 style 내 '<', '>', '&'와 같은 문자를 이스케이프 시키지 않고 그대로 사용할 수 있도록 한다. 또한, Doctype에 관계없이 script요소와 style요소를 </head>와 <body>사이에 삽입하는 경우는 없어야 한다. 되도록 script와 style은 외부 문서로 빼는 것이 좋다.

  • XHTML 1.1일 경우 다음의 요소들은 사용할 수 없다.

    <applet>, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>, <strike>, <u>

    특히 , <font>와 <center>, <iframe> 요소는 개발자들이 무분별하게 사용하는 대표 요소인데 Doctype에 따라 사용을 신중히 해야할 필요가 있다. <font>와 <center> 요소는 CSS로 정의할 수 있으며, <iframe>요소는 <object>요소로 대체된다.

  • XHTML 1.1일 경우 다음의 속성들은 사용할 수 없다. (일부 속성은 XHTML 1.0 Strict 에서도 지원되지 않기 때문에 주의 바랍니다.)

    <*> lnag
    <a> name, target
    <area> traget
    <body> background, bgcolor, text, link, vlink, alink
    <br> clear
    <caption> align
    <div> align
    <form> name, target
    <h1~h6> align
    <hr> align, noshade, size, width
    <img> align, border, hspace, vspace
    <input> align
    <legend>align
    <li> type, value
    <link> target
    <map> name
    <object> align, border, hsapce, vspace
    <ol> compact, start, type
    <p> align
    <pre> width
    <strict> language
    <table> align, bgcolor
    <td> bgcolor, height, nowrap, width
    <th> bgcolor, height, nowrap, width
    <tr> bgcolor
    <ul> compact, type

  • 가급적 요소에 직접 스타일(inline style)을 정의하지 않는다.

    <div style="...">
    단, <input>과 <img> 요소 등 개발시 변동이 잦은 요소들에 한해서 inline style로 width와 height를 지정하는 것은 괜찮다고 생각한다. 하지만 저속 인터넷 접속 환경에서는 느린 로딩으로 인해 이미지 요소들이 레이아웃을 잡지 못해 들쑥날쑥하게 전체레이아웃을 깨뜨리는 현상이 발생하기도 하므로 이에 대한 고려가 선행되어야 할 것이다.

  • 요소와 속성내 모든 문자열을 PCDATA(분석 처리된 문자데이터)로 작성한다.

    <p>LOVE & GHOST</p> ☞ <p>LOVE &amp;amp; GHOST</p>
    <a href="../../list.php?id=bomnun&val=2">링크</a> ☞ <a href="../../list.php?id=bomnun&amp;val=2">링크</a>

    * <style>과 <script>요소에서는 <![CDATA[ ... ]]>를 사용해서 문자열을 파싱하지 않고 그대로 사용할 수 있다.

  • XHTML일 경우 속성은 약술할 수 없다.

    <input type="radio" checked /> ☞ <input type="radio" checked="checked" />

  • Encoding Charset이 무엇인지 확인한다.

    HTML 문서는 utf-8인데, 파일 인코딩은 euc-kr인 경우가 종종 있고, 이 경우 한글이 깨져 보이는 가장 큰 이유가 된다. 또한, CSS나 JS 역시 인코딩이 다를 경우 제대로 작동되지 않기도 한다.

세세히 따지면 좀 더 있겠지만 대부분 위의 경우에 해당될 것 같다. 그리고 상위 4개 붉은색으로 표시한 것들이 validate를 통과하지 못하는 대부분의 이유가 된다. 서버사이드 개발자들이 위의 내용을 숙지만 하고 있다면(최소한 DTD의 차이만이라도 알고 있다면) 문법 오류를 최소한으로 줄일 수 있을것 같다.

이 글은 솔직히 서버사이드 개발자들을 '낚기' 위한 글입니다. 위의 내용은 이미 수차례 비슷한 주제의 블로그나 사이트를 통해서 널리 알려져 있는 내용입니다. 결국 복사된 내용의 재탕(웹표준교과서의 내용을 정리했음)이라는 것이지만 그럼에도 불구하고 서버사이드 개발자분들이 한번만이라도 관심 있게 읽어주기를 바라는 마음에 포스팅을 하게 되었습니다.

출처 : 봄눈님 블로그 http://www.pageoff.net/787
저작자 표시 비영리 변경 금지


Chris Coyier는 SMASHING MAGAZINE을 통해서 '12 Principles For Keeping Your Code Clean'이라는 제목의 멋진 글을 소개하고 있습니다. 그가 CSS을 사람들에게 가르칠 때부터 강조했던 원칙들로 다음과 같습니다.


얕은 영어 실력으로 제대로 번역은 어렵고, 제목 위주로 짧게 소개만 해 드리겠습니다.


  1. 엄격한 DTD를 사용할 것 (Strict DOCTYPE) 

    어떤 레이아웃을 위한 테이블 요소도 사용하지 않는다면 Transitional Doctype 은 필요 없다.


  2. <title> 속의 '&'를 인코딩할 것 (Character set &amp; encoding characters)

    <head> 섹션 안에서 문자 집합(Character set)을 가장 먼저 정의해 주도록 한다. 많은 경우 <title>을 가장 먼저 작성하면, <title> 안에 '&'와 같은 문자가 제대로 인코딩 되지 않는 문제가 생길 수 있다. 때문에 <title>과 <meta http-equiv="Content-Type" ... />의 자리를 바꿔 주는 것이 좋다.


  3. 적당한 들여쓰기를 할 것 (Proper indentation)

    들여쓰기는 코드의 가독성을 높여 준다. 표준 절차에서 새로운 요소가 시작될 그것의 자식 요소는 한 개의 탭(또는 약간의 공백)을 띄운다.


  4. CSS와 JavaScript는 외부에 둘 것 (Keep your CSS and JavaScript external)

    CSS와 JavaScript를 HTML 안에 경우 단 하나의 HTML 페이지만을 위해서 사용된다. 같은 코드의 많은 HTML 페이지들을 위해서라면 HTML 페이지 밖에 두는 것이 좋다.


  5. 태그를 바르게 감쌀 것 (Nest your tags properly)

    인라인 요소로 블록 요소를 감쌀 수 없다. 올바른 방법으로 태그를 감싸야 한다.


  6. 필요 없는 div를 제거할 것 (Eliminate unnecessary divs)

    div를 불필요하리만치 많이 사용하는 경우가 있다. 필요하지 않다고 판단되는 div를 제거하고 최소화 하자.


  7. 의미 있는 이름을 사용할 것 (Use better naming conventions)

    좋은 class와 id 속성의 이름은 "mainNav", "subNav", "sidebar", "footer", "metaData"와 같은 것들이다."red", "italic"과 같이 디자인을 기술하는 이름은 적당하지 않다.


  8. 영문자의 대소문자화 같은 타이포그라피는 CSS를 이용할 것 (Leave typography to the CSS)

    CSS를 이용하면 소문자를 대문자로, 대문자를 소문자로 변환할 수 있다. 마크업을 통해서 하지 말고, CSS를 이용하자. 하지만 한글에서는 사용되지 않는 기능이다.


  9. <body> class와 id 속성을 쓸 것 (Class/id the <body>)

    <body>에 class와 id 속성을 지정함으로써 다양한 디자인 변화에 대한 레이아웃(대체 레이아웃)을 유지할 수 있다.


  10. 유효한지 검증할 (Validate)

    유효성 검증을 실시하자. HTML 마크업과 CSS에 대한 W3C Validation이 있다.


  11. 논리적인 순서를 가질 것 (Logical ordering)

    풋터는 논리적으로 헤더나 사이드바보다 아래에 위치한다. 마크업 안에서도 역시 마지막에 위치하는 것이 옳다.


  12. Just do what you can

    order example
    중요한 것은 HTML을 제대로 작성하는 방법을 배우고, 그것을 정확히 사용하는 것이다. 그리고 다음에 새로운 프로젝트를 시작하게 되면 당신은 그렇게 할 수 있을 것이다.

원문에는 원칙별로 참조 문서를 링크하고 있어 12가지의 원칙을 읽으면서 여러가지 공부를 함께 해볼 수 있습니다. 시간내서 꼭 한번 살펴보세요.

출처 : 봄눈님 블로그 http://www.pageoff.net/841
저작자 표시 비영리 변경 금지