NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


SmartEditor™ 공개 프로젝트 리뷰.

본문 건너 뛰기

2008년 12월 31일 스마트에디터가 세상에 공개 되었습니다. 알파 버전(공개 테스트용 버전)으로써 잘 드러나지 않는 버그가 남아 있지만 개선되는 것은 시간문제 입니다. 스마트에디터는 곧 안정화 되는대로 ‘XE‘의 기본 에디터로도 탑재될 예정입니다. 제가 참여한 부분은 UI개발 분야로써 기존에 네이버에서 사용되고 있던 스마트 에디터의 HTML/CSS 레거시 코드를 사용하지 않고 완전히 새롭게 만들었습니다. ‘SmartEditor Basic’은 ‘Naver SmartEditor’와 서로 다른 버전의 ‘Javascript Library’를 사용하고 있으며 포함된 스펙이나 HTML/CSS 코드 및 Accessibility 성능도 확연히 다릅니다. 사실상 SmartEditor라는 이름과 디자인만 공유하고 있을 뿐 보이지 않는 부분은 완전히 다르다는 거죠.

  • Demo : SmartEditor Basic 데모 확인.
  • Skin : Javascript가 적용되지 않은 HTML 페이지.
  • default.css : 에디터용 스타일 시트.
  • style.css : 콘텐츠용 스타일 시트. 스마트에디터에서 작성한 문서가 출력되는 곳에 필요.
  • Download : SmartEditor Basic 최신버전 내려받기.

다른 에디터와 구별되는 특징.

  Korea Global
Brand SmartEditor Basic Naver SmartEditor Daum Editor OpenMaru Xquard FCKeditor TinyMCE markItUp
License LGPL NHN Corp. Daum Corp. LGPL GPL, LGPL, MPL, CDL LGPL MIT/GPL
Demo Yes None None Yes Yes Yes Yes
Cross Browser IE/FF/CR/SF/OP IE/FF/CR/OP IE/FF/CR/SF/OP IE/FF/CR/SF/OP IE/FF/CR/SF/OP IE/FF/CR/SF/OP IE/FF/CR/SF/OP

기존의 네이버 카페, 블로그 등에 사용된 스마트에디터는 Safari 브라우저의 글쓰기를 지원하지 못했으나 현재 공개된 버전은 Safari를 포함하여 대중적인 브라우저에서 모두 글쓰기가 가능 합니다. 또한 LGPL 라이선스를 적용하여 코드 안에 저작권 명시와 수정된 라이브러리를 공개해야 한다는 조건만 지키면 상업적으로 거의 아무런 제한이 없이 사용이 가능한 실로 유용한 제품 이라고 생각합니다. 전 세계적으로 사랑받고 있는 다른 에디터와 비교하면 현재로써는 글쓰기에 필요하다고 판단되는 최소한의 스펙만을 포함하고 있지만 라이선스를 공개한 이상 그 확장 가능성은 무궁무진 합니다. 필요한 사람은 얼마든지 자유롭게 가져다가 모든 목적으로 사용한 후 다시 사회에 환원하면 됩니다.

기존 스마트에디터와 구별되는 특징.

기존의 네이버 스마트에디터보다 공개된 스펙이 더 가볍고 견고하게 설계됨. 확장 가능성과 접근성 문제도 해결됨.

  Naver SmartEditor SmartEditor Basic
Design/Layout 디자인된 드롭다운 메뉴 레이어 사용. 고정폭 레이아웃. 드롭 다운 메뉴에 브라우저 기본 콘트롤 사용. 가변폭 레이아웃 사용. 현재 데모는 고정폭이나 가변폭으로 변경 가능하고 브라우저 크기를 극단적으로 줄이는 경우 편집 도구모음이 다단으로 흐름.
HTML/CSS 레이아웃을 위한 테이블 사용 등 표현을 위한 마크업이 사용됨. 브라우저 호환성 문제를 해결하는데 주력. 전경 이미지 기법 사용으로 대부분의 버튼들이 서로 잘게 분리되어 있어 http 요청이 많음. 이미지 예. 스킨 변경시 HTML/CSS 코드를 모두 수정해야 함. 기존의 레거시 코드를 모두 제거하고 처음부터 다시 제작. 브라우저 호환성 문제뿐만 아니라 웹 표준 기반의 의미론적 마크업 준수. 이미지를 모두 배경으로 처리하는 IRImage Replacement 기법과 Image Sprites 기법을 사용하여 http 요청을 최소화. 이미지 예. 스킨 변경시 CSS 코드만 수정하면 됨.
Javascript 자체 개발 Jindo1 Framework 미공개 버전사용. 오픈소스 아님. 자체 개발 Jindo Framework(LGPL) 사용.
Accessibility 콘텐츠 배치 순서가 논리적이지 않음. 편집 도구모음에 키보드 접근 불가. 편집창에 한번 들어가게 되면 키보드만으로 빠져나올 수 없음. 콘텐츠 배치 순서가 논리적이며 모든 항목을 키보드로 제어 가능. 편집 도구모음을 건너 뛸 수 있는 숨은 링크 사용. 키보드만으로 편집창에서 빠져나올 수 있음.
Extensibility 현재는 특정 서비스에 최적화 되어 있기 때문에 차기 버전 제작시 레거시 코드를 버리는 편이 비용이 적게 들어갈 것으로 예상됨. 차기 버전 제작시 레거시 코드를 재활용 하는것이 비용이 적게 들어갈 것으로 예상됨. 확장 가능성이 높음.

키보드 조작을 위한 단축키 지원 현황.

OS단에서 기본적으로 제공하는 단축키와 스마트에디터가 추가로 지원하는 단축키 정리. 취소선은 아직 구현되지 않았거나 구현을 포기한 기능.

단축키 제공 주체 단축키 조합 명령
OS 제공 단축키 Ctrl+Z 되돌리기
Ctrl+Y 재실행
Ctrl+X 잘라내기
Ctrl+C 복사하기
Ctrl+A 전체선택
Ctrl+F 찾기
Right(→) 다음 글자로 커서 이동
Left(←) 이전 글자로 커서 이동
Ctrl+Right(→) 다음 단어로 커서 이동
Ctrl+Left(←) 이전 단어로 커서 이동
Ctrl+Shift+Right(→) 다음 단어 블럭 지정
Ctrl+Shift+Left(←) 이전 단어 블럭 지정
스마트에디터 지원 단축키 Ctrl+B 굵은 글꼴
Ctrl+U 밑줄
Ctrl+I 기울임 글꼴
Ctrl+D 취소선
Tab 들여쓰기
Shift+Tab 내어쓰기
ESC 리치 에디터에서 빠져 나오기

사용자 인터렉션 제어를 위한 HTML/CSS 가이드.

사용자가 편집 도구모음을 조작할 때 HTML 코드가 동적으로 어떻게 바뀌어야 하는지를 설명하는 명세.

인터렉션 작용 전 작용 후 설명
기본     아무런 조작을 하지 않은 상태.
HTML 편집모드 <div class="tool"> <div class="tool off"> 도구 버튼들은 반투명 상태가 되고 제어가 불가능 하게 된다.
<select> <select disabled="disabled"> 글꼴, 크기, 줄간격 콘트롤은 disabled 상태로 전환 된다.
<div class="input_area">
  <iframe style="display:block;">
  <textarea style="display:none;">
</div>
<div class="input_area">
  <iframe style="display:none;">
  <textarea style="display:block;">
</div>
iframe 대신 textarea를 출력한다.
버튼 오버 <button type="button"> <button type="button" class="hover"> 도구 버튼에 마우스를 올리거나(onmouseover) 키보드 포커스(onfocus)가 머무른 상태.
버튼 클릭 <button type="button"> <button type="button" class="active"> 도구 버튼이 클릭(onclick) 또는 키다운(onkeydown)된 상태. 또는 현재 편집중인 영역의 스타일과 버튼이 매칭될 때 관련 버튼이 활성화 된다.
글자 색 <li class="fcolor">
<div class="layer" style="display:none;">
<li class="fcolor">
<div class="layer" style="display:block;">
글자 색 팔레트를 출력한다. 이 명령은 사용자가 블럭으로 지정한 영역을 span 엘리먼트로 감싼 후 인라인으로 color 스타일을 적용하게 된다.
배경 색 <li class="bcolor">
<div class="layer" style="display:none;">
<li class="bcolor">
<div class="layer" style="display:block;">
배경 색 팔레트를 출력한다. 이 명령은 사용자가 블럭으로 지정한 영역을 span 엘리먼트로 감싼 후 인라인으로 background 스타일을 적용하게 된다.
인용 <li class="blockquote">
<div class="layer" style="display:none">
<li class="blockquote">
<div class="layer" style="display:block">
인용구 스타일 레이어를 출력한다. 이 명령은 사용자가 블럭으로 지정한 영역을 blockquote 엘리먼트로 감싼 후 blockquote 엘리먼트에 .q1~.q7 클래스를 적용하게 된다.
링크 <li class="url">
<div class="layer" style="display:none;">
<li class="url">
<div class="layer" style="display:block;">
링크 만들기 레이어를 출력한다. 이 명령은 사용자가 블럭으로 지정한 영역을 a 엘리먼트로 감싼 후 href 속성의 값을 채우게 된다.
<li class="table">
<div class="layer" style="display:none;">
<li class="table">
<div class="layer" style="display:block;">
표 삽입 레이어를 출력한다. 이 명령은 사용자기 지정한 영역에 table, tr, td 엘리먼트를 생성하게 된다.
<li class="table">
<div class="layer" style="display:block;">
<li class="table">
<div class="layer p1" style="display:block;">
표의 테두리색 레이어를 출력한다. 이 명령은 표의 배경색을 채운다.
<li class="table">
<div class="layer" style="display:block;">
<li class="table">
<div class="layer p2" style="display:block;">
표의 배경색 레이어를 출력한다. 이 명령은 셀의 배경색을 채운다.
특수문자 <li class="character">
<div class="layer" style="display:none;">
<li class="character">
<div class="layer" style="display:none;">
특수문자 삽입 레이어를 출력한다.
<ul class="nav">
<li><a href="#character1" onclick="return false">일반기호</a></li>
<ul class="nav">
<li><a href="#character1" class="on" onclick="return false">일반기호</a></li>
특수문자의 종류를 탐색할 때 선택된 메뉴 아이템을 볼드 처리한다.
<ul class="list" id="character6" style="display:none"> <ul class="list" id="character6" style="display:block"> 특수문자의 종류를 탐색할 때 선택된 메뉴 아이템이 참조하는 특수문자 목록을 출력한다.
찾기 <li class="find">
<div class="layer" style="display:none">
<li class="find">
<div class="layer find" style="display:block">
찾기/바꾸기 레이어를 출력한 뒤 찾기 탭과 찾기 인풋을 활성화 하게 된다.
바꾸기 <li class="find">
<div class="layer" style="display:none">
<li class="find">
<div class="layer replace" style="display:block">
찾기/바꾸기 레이어를 출력한 뒤 바꾸기 탭과 바꾸기 인풋을 활성화 하게 된다.
레이어 display : block | none 제어에 인라인 스타일 시트를 사용한 이유.
국산 화면낭독기가 인라인 선언된 display 속성만을 제대로 처리하기 때문에 숨은 레이어 콘텐츠를 그냥 건너 뛸 수 있도록 고려함. 한편 Javascript가 동적으로 이 스타일을 변경할 때 화면낭독기 ‘센스리더’가 이것을 캐치하지 못하고 display:block 상태로 전환이 된 이후에도 그냥 건너 뛰는 문제가 발생. 센스리더 측에서 이 문제를 해결할 수 있는지 확인 및 건의가 필요함. 이 문제는 동일한 다른 상황에서도 마찬가지로 발생하는 문제.

편집 도구 버튼 활성화 규칙.

사용자가 리치 에디터를 사용하고 있을 때 커서가 놓인 지점 또는 블럭으로 선택한 지점에 어떤 스타일이 적용되어 있는지 시각적으로 분명하게 표시하기 위하여 해당 버튼을 활성화 시키는 기능.

규칙 편집 도구 버튼이 .active 클래스를 갖는 조건
버튼 클릭 button 엘리먼트에 onclick 이벤트가 발생 했을 때
버튼 키다운 button 엘리먼트에 onkeydown 이벤트가 발생 했을 때
내용 편집 굵은 글꼴 사용자 커서가 <strong> 엘리먼트 안쪽에 머물 때
밑줄 사용자 커서가 <u> 엘리먼트 안쪽에 머물 때
기울임 글꼴 사용자 커서가 <em> 엘리먼트 안쪽에 머물 때
취소선 사용자 커서가 <del> 엘리먼트 안쪽에 머물 때
글자 색 사용자 커서가 {color} 속성이 적용된 엘리먼트 안쪽에 머물 때
배경 색 사용자 커서가 {background} 속성이 적용된 엘리먼트 안쪽에 머물 때
위 첨자 사용자 커서가 <sup> 엘리먼트 안쪽에 머물 때
아래 첨자 사용자 커서가 <sub> 엘리먼트 안쪽에 머물 때
왼쪽 정렬 사용자 커서가 {text-align:left} 속성이 적용된 엘리먼트 안쪽에 머물 때
가운데 정렬 사용자 커서가 {text-align:center} 속성이 적용된 엘리먼트 안쪽에 머물 때
우측 정렬 사용자 커서가 {text-align:right} 속성이 적용된 엘리먼트 안쪽에 머물 때
양쪽 정렬 사용자 커서가 {text-align:justify} 속성이 적용된 엘리먼트 안쪽에 머물 때
순차 목록 사용자 커서가 <ol> 엘리먼트 안쪽에 머물 때
비순차 목록 사용자 커서가 <ul> 엘리먼트 안쪽에 머물 때

참조

오류 정정

  • 최초 글 작성시 네이버 스마트에디터에서 사용하는 프레임웍과 스마트에디터 베이직 버전에서 사용하고 있는 Javascript Framework이 동일하다고 기술하였으나 사실 확인 결과 네이버 스마트에디터는 Jindo classic(혹은 Jindo1)으로써 현재 오픈 소스로 된 Jindo와는 다른 프레임웍 입니다. 그리고 네이버 스마트에디터에 사용된 Javascript Framework은 오픈소스가 아닙니다. 관련 내용을 모두 수정하였습니다.

 

분류: CSS,웹 기획,웹 접근성,웹 표준,자바스크립트 | 2009년 1월 1일, 22:41 | 정찬명 | 댓글: 33개 |
트랙백URI - http://naradesign.net/wp/2009/01/01/474/trackback/

33개의 댓글이 있습니다.

  1. 정찬명의 생각…

    SmartEditor™ 공개 프로젝트 리뷰….

  2. miriya 댓글:

    제가 예전 회사에서 치를 떨면서 개선을 요구하던 에디터가 FCK의 아류작이었군요 ㅠㅠ 좋은 일 하셨습니다.

  3. 정낙훈 댓글:

    지금 XE의 에디터는 제가 관리자인데, 태그가 포함된 글을 쓰니 태그를 먹어버리더군요.

  4. 정찬명 댓글:

    아, 그러셨군요. ^^; 혹시 이와 관련하여 등록된 이슈트래커 글이 있으면 알려주세요. 아니면 이슈트래커에 등록을 부탁드립니다. 제가 확인해 보고 팀에 공유 하겠습니다. 현재는 정확한 증상을 잘 모르겠습니다.

    이슈트래커
    http://www.zeroboard.com/xe_issuetracker

    권한이 없으시면 그냥 여기 적어주셔도 됩니다. ^^
    감사합니다.

  5. 정낙훈 댓글:

    태그를 먹어버리고
    은 안 먹는데 <html 은 먹고..
    CR, IE7, FF3에서 발생하는 걸 보니 브라우저 상관 없이 발생하는 거 같은데
    전 이거 원래 그런 줄 알았어요. (http://eond.com/eond/162869 )

  6. 정낙훈 댓글:

    꺽쇠 변경을 안했네요. 위에 사라진 게 [div]와 [html]이었습니다.

  7. 정찬명 댓글:

    조금전 고영수 팀장님께 문의해 보았더니 자동링크 애드온이 문제를 일으키는 것 같다고 하시네요. 현상을 보면 태그 안쪽에 포함된 URL에 자동으로 링크가 걸리는 곳의 시작 꺽쇠가 사라지고 있습니다.

    조금 번거로우시겠지만 제 코멘트 설명을 참고하셔서 저희 이슈 트래커에 버그 등록을 부탁드립니다. 이슈 트래커 권한이 제한되어 있는줄 알고 있었는데 회원이면 누구나 등록할 수 있다고 합니다. ^^;

    이슈 트래커
    http://www.zeroboard.com/xe_issuetracker

    바로 바로 처리를 해 드리면 좋겠는데 중요한 다른 일들을 먼저 처리하느라고 바로 해결해 드리지 못하는점 이해 부탁드립니다. 감사합니다.

  8. pengdo's me2DAY 댓글:

    펭두잉의 생각…

    오.. nhn에서 공개한 스마트에디터 괜찮은데? 아샬님, 두잉 에디터도 바꿀까요? ㅎ…

  9. 정낙훈 댓글:

    이슈트래커에 아침에 등록했는데 저녁에 바로 해결이 되었다고 XE 사이트에 쪽지가 왔네요. ^^; 찬명님 입김이 바로 해결하도록 만들었습니다;; 감사합니다. 물론 배포판에는 포함이 되지 않았겠지만….이라고 쓰고 svn으로 받으면 해결됐을 줄 알았는데
    svn up 실행 후 다시 확인해보니 [html]과 [div]만 먹던 것이 이제는 거진 다 먹어버리네요.
    제가 원한 건 그냥 그대로 노출되는 것이었는데 말이죠^^;;
    http://eond.com/eond/162869
    긴 코드를 삽입했더니 페이지가 좀 길고 알아보기 어려우시겠지만;;
    마지막 연속된 찬명님 코멘트 이후로 2개는 텍스트 편집기였고, 그 뒤로는 에디터였는데
    제대로 안되는 것 같네요. 텍스트편집기에서는 완전히 html 사용인 것처럼 다 먹어버리고, 에디터에서는 부분적으로 이전보다 좀 더 먹는 것 같습니다.;;
    다시 한 번 더 XE 쪽에 문의드려봐야겠습니다.
    신경 써주셔서 감사합니다. ^^

  10. 정찬명 댓글:

    아, 그랬군요. ^^; 이 문제가 해결 될 때까지 지속적으로 이슈트래커에 피드백 부탁드립니다. 감사합니다.

  11. 정낙훈 댓글:

    문득 글을 스크롤하다 느낀 건데, 나눔고딕이 ‘초성’과 ‘ㅣ모음 중성’으로 결합될 때는 유난히 길어 보이네요.
    가로 읽기의 경우는 세로로 약간 긴 편이 가독성이 좋다고 하지만, ‘초성,중성,종성’의 결합이거나 혹은 ‘초성’과 ‘ㅡ모음 중성’의 결합일 때는 굉장히 잘 만들어졌다 싶었는데, 위의 경우에는 살짝 아쉬운 부분이 있네요.
    폰트도 버전업을 하지요? 나눔고딕도 약간씩 변형되었으면 하는 바람이 생기네요. 관련 포스팅도 아니고 관련 분야도 아니지만 문득 생각나서 댓글 달아봅니다. ;;;;
    아님 제가 잘못 느낀 걸수도 있는데, 특히나 본문에 작은 글씨가 그러네요.
    ‘사용자 커서가..’ 하는 부분에 글꼴 사이즈가 작은데, 본문의 큰 글씨는 그다지 그런 느낌을 못 받았는데 작은 글씨는 일부러 letter-spacing이 적용된 건가요? 하여간 그런 느낌이 있네요. ^^a

  12. 정찬명 댓글:

    나눔고딕이 11px 크기 일때 다른 크기에 비하여 세로로 늘씬하게 보이는 것 같습니다. 그리고 letter-spacing은 적용되지 않은 상태 인데요. 그렇게 느낄 수 있을만큼 자간이 촘촘한 느낌이 드는것도 사실이네요. ^^;

  13. 꿈트리 댓글:

    드뎌 스마트에디터가 세상 밖으로 나왔군요.^^
    축하드려요^^

    이제 부터는 버그 찾기…후다다닥~~

  14. 나에 댓글:

    [u]보다는 [ins]가 낫지 않을까 싶습니다만 (….)
    u가 b처럼 디자인적인 요소라서 단순히 언더라인하라는 뜻만 담겨져 있는걸로 알고 있어요.
    이왕이면 추가한다는 뜻이 담겨있는 ins가 나을 거 같아요.

  15. melt-snow 댓글:

    NHN deView 행사에서 봤을 때 곧 공개한다는 얘기를 듣고 언제가 되려나 했는데 드디어 공개가 되었군요. 그동안 SmartEditor 개발 팀 고생이 참 많았을 거라 생각합니다.

  16. melt-snow 댓글:

    위에 관련 얘기가 나온 김에 생각해왔던 바를 조금 적어봅니다.

    위지위그 에디터에서 가장 의아했던 부분이 바로 굵게, 기울이기, 밑줄, 취소선인데요. 전 이글루스 블로그의 에디터를 시작으로 텍스트큐브, 티스토리, 워드프레스 등을 써보면서 이게 제각각 의도하는 바가 다르다는 걸 알았습니다.

    어떤 에디터는 굵게라고 표시해놓고 b 태그를 쓰는가 하면, 굵게라고 표시하지만 strong 태그를 쓰는 경우가 있습니다. 마찬가지로 기울이기로 써놓고 i나 em으로 태그를 쓰는 경우도 있습니다.

    제가 볼 때는 에디터가 정말 의미론적인 의도로 태그를 생성하고자 한다면, 굵게 버튼은 매우 강조라고 쓰고 strong이라고 표시해야 한다고 봅니다. 문제는 사용자 입장인데요. 평범한 사용자가 볼 때는 매우 강조라는 용어가 좀 직관적이지 않을 가능성이 있습니다. 익숙함의 문제라면 시간만 필요하지만 그게 아니라면 섣불리 바꾸는 데 문제가 있습니다.

    본문의 표에서,
    굵은 글꼴 : strong은 강조 : strong으로 하거나, 차라리 굵은 글꼴 : b 로 쓰는 게 본래 의미에는 맞지 않을까 싶습니다. 밑줄 : [u] 는 의미 상 알맞다고 봅니다. 단, u가 모양을 꾸미는 태그이므로 엄격하게는 [span style=”text-decoration: underline”]foo[/span] 형식으로 들어가야 하지 않나 싶습니다.

    기울임 글꼴 : [em] 도 의미에 맞게 쓴다면 기울임 글꼴 : [i] 이거나, 강조 : [em]라고 써야할 것 같습니다. 취소선 : [del] 은 한때 고민한 부분인데, 취소선이라는 명칭에 맞게 한다면 [span style=”text-decoration: line-through”]foo[/span] 형식이 좋지 않을까요. 원래 del 태그의 용도가 문서의 지운 부분을 (의미론상으로) 표현하는 것이니 취소선은 의미가 맞지 않는 것 같습니다. 물론 이것도 strong과 마찬가지 문제가 있습니다.

    아마 본문의 결정을 내리게 된 과정에서 나름대로의 이유가 있었을 거라 생각합니다. 엄격하게 의미에 맞는 태그만 사용하려고 해도 사용자들의 인식 수준을 고려할 때 바로 적용하기 어려운 부분도 있을테고요. SmartEditor 개발자에게 스프링노트나 텍스트큐브처럼 구조화 된 문서를 작성할 수 있도록 h1~h6 지원을 해달라고 했으나, 역시 아직은 시기상조라는 얘기도 들은 바가 있습니다.

    아무튼 제 생각은 이렇습니다. 혹 추가 설명이 가능하다면 정찬명님의 생각을 듣고 싶습니다. ^^

    (바로 위 댓글 태그가 적용되어버려 엉망이 됐군요. 죄송하지만 실패한 위 댓글은 삭제해 주세요.)

  17. 정찬명 댓글:

    일단 나에님께서 제안해 주신 부분은 저도 처음에 고려했었던 부분이었으나 실제로 사용자들이 의미에 맞게 어떤 내용을 새로 추가한 경우에 밑줄을 사용하는 것은 일반적이지 않은 것 같습니다. 때문에 [ins] 요소를 사용하게 되면 오히려 의미에 맞지 않게 됩니다. [ins] 요소가 삽입을 의미하기 때문이죠.

    사용자들이 밑줄을 치는 이유는 아마 강조 때문일 껍니다. 하지만 의미론적으로 HTML에서 강조는 [strong], [em] 밖에 없기 때문에 다른 엘리먼트를 사용해야 했는데요.

    [span] 을 사용하자니 [span style=”text-decoration:underline”] 이렇게 표현이 길어 집니다. 의미 없는 요소를 사용할 꺼라면 차라리 코드도 간결하고 스스로 표현을 갖고 있는 [u] 엘리먼트를 사용하는게 좋겠다고 판단 했습니다.

    melt-snow님께서도 좋은 질문 주셔서 이어서 계속 쓰겠습니다. ^^

  18. 정찬명 댓글:

    melt-snow님께서 제안해 주셨던 [h1]~[h6] 엘리먼트 역시 공개버전 제작 초기에 제 제안으로 포함시키려 했으나 초기 스펙에 존재하지 않던 사안이라는 이유 때문에 보류 되었습니다. 사용자들에게 시기상조라는 표현을 누군가 사용했다면 그 부분은 잘 이해가 되지 않네요.

    ‘전문적인 글쓰기를 하는 사람들에게 제목요소는 필수적’이라고 생각하고 ‘제목요소’는 에디터가 가장 먼저 갖춰야할 필수 기능이라고 생각합니다. 현재는 포함되어 있지 않지만 기본 기능으로 제공되도록 지속적으로 의견제시를 할 예정 입니다.

    HTML 4.01 스펙은 강조에 관하여 다음과 같이 정의하고 있습니다.

    [strong] = 강한강조
    [em] = 통상의 강조

    그리고 보통의 사용자들이 실제로 ‘굵은 글꼴’이나 ‘이텔릭’ 서체를 사용하는 행태는 HTML 에서 정의한 스펙과 일치하는 목적을 가지고 사용한다고 생각합니다. 정말 강조하고 싶은 문장을 ‘굵은 글꼴’로 처리하고 그냥 강조하고 싶은 문장에 ‘이텔릭’을 적용한다는 점 입니다.

    이것은 HTML 요소의 본래 의도와 사용자가 의도하는 부분이 일치하기 때문에 [strong], [em] 요소의 사용에는 큰 망설임이 없었습니다. 만약 [b], [span]으로 처리한 다음 인라인 스타일을 주는 방식이었다면 사용자가 의도한 강조가 마크업에 포함되지 않기 때문에 바람직 하지 않다고 생각 했습니다.

    간혹 사용자가 강조할 의도 없이 ‘굵은 글꼴’이나 ‘이텔릭’ 서체를 사용하는 경우도 있지 않겠냐는 질문도 여러번 받아본 적이 있지만 저는 강조할 목적 없이 ‘굵은 글꼴’이나 ‘이텔릭’을 사용하는 경우는 존재하지 않는다고 생각합니다.

    [del] 요소 또한 마찬가지 입니다. 사용자가 취소선을 처리하는 목적은 해당 문장을 취소하고자 하는 의미를 가지고 있기 때문에 적합하다고 생각합니다.

    비록 에디터에 ‘강한 강조’ 대신 ‘굵은 글꼴’ 이라는 표현을 사용하고 있고 ‘통상의 강조’ 대신 ‘기울임 글꼴’이라는 표현을 사용하고 있지만 이는 어디까지나 일반적인 사용자들에게 익숙한 단어이기 때문에 선택된 표현입니다. 비록 스타일을 표현하기 위한 설명처럼 보이지만 실제로 뒤에서는 의미에 맞는 HTML 요소가 삽입되어야 한다고 생각 합니다.

    사용자가 ‘아무런 생각 없이’ 글자를 좀 굵게 표시하기 위해 ‘Ctrl+B’ 키를 눌렀을 때 우리는 그것을 ‘아무 생각 없다’고 받아들이면 안되고 ‘강한 강조’라고 받아들여야 한다는 생각 입니다.

    따라서 제 의견을 요약하면 이렇습니다.

    1. 우선은 되도록 의미있는 마크업을 사용해야 한다는 원칙을 세우고
    2. 사용자가 기대하는 의미(스스로 그것을 의식 했는지 못했는지는 중요하지 않음)와 일치하는 마크업이 있다면 반드시 의미있는 마크업을 사용하고
    3. 사용자의 기대와 마크업이 다른 의미를 갖고 있는 경우라면 차라리 의미없는 마크업을 사용하는 것이 좋겠다

    라는 생각 입니다.

    일단 의미있는 마크업을 사용해야 한다는 생각에는 melt-snow님이나 저나 같은 생각을 지니고 있지만 그것을 실제로 적용하는 과정에서는 약간의 견해 차이가 보이는군요. 의미 있는 좋은 주제를 언급해 주셔서 감사합니다. ^^

  19. melt-snow 댓글:

    상세한 답변 정말 고맙습니다. ^^

    시기상조라는 표현을 간단하게 줄여서 적었더니 오해가 생긴 듯합니다. 원래는 제가 행복한고니님에게 구조적 문서 작성을 위해 h1~h6을 자연스럽게 쓸 수 있도록 유도하면 어떻겠냐고 질문했더니, 아직 네이버에서 글을 쓰는 사람들이 그런 필요성을 느끼지 못하고 그 과정이 쉽지 않기 때문에 넣기 어렵다는 얘기를 들었습니다. (행사에서 구두로 들은 내용이라 당시 표현과 차이가 조금 날 수 있습니다. ^^;)

    그래서 그걸 간단히 시기상조라는 표현으로 적었습니다. 텍스트큐브에 적용된 h1~h6은 제가 건의를 했을 때는 큰 얘기가 없다가 어느 업데이트부터 갑자기 추가됐는데요. 블로그 돌아다니다가 텍스트큐브 사용한 곳을 보면 제목을 긁어서 선택한 소스 보기를 종종 해봅니다. 그러나 대다수 h* 태그를 쓰지 않고 그냥 font나 div, span을 쓰시더군요. 전 그 기능이 들어간 이후로 단락을 나눈 글은 h* 태그를 적용하도록 썼었습니다. 위지위그 에디터에서 아래 위 줄 간격이 의도대로 안 되거나 커서 버그가 일어나는 등 고생을 많이 했었죠.

    간혹 사용자가 강조할 의도 없이 ‘굵은 글꼴’이나 ‘이텔릭’ 서체를 사용하는 경우도 있지 않겠냐는 질문도 여러번 받아본 적이 있지만 저는 강조할 목적 없이 ‘굵은 글꼴’이나 ‘이텔릭’을 사용하는 경우는 존재하지 않는다고 생각합니다.

    이 글을 보니 정말 그렇겠다는 생각이 듭니다. 일반적으로 강조할 목적 없이 글자를 굵게 할 일은 없을 것 같습니다. 사용자에게 익숙한 용어를 선택함으로써 어색함 없이 굵은 글꼴 버튼을 누르고 내부에서는 시맨틱 요소로 처리한다는 것도 좋은 선택이라고 생각합니다. 다만, 이왕이면 XHTML 규격에 맞도록 u 태그를 사용하지 않는 방향이 없을까 하는 생각이 듭니다.

    몇 년 전, 일본 개인 홈페이지에서 설명된 글을 읽으며 웹 표준을 정말 해야할까? 하는 의문을 몇 번이고 느꼈지만 너무 완벽하게 100% 추구하려는 습관은 오히려 해가 될 수도 있겠다는 생각이 들더군요. 적절한 균형을 맞추면서 꼭 의미에 맞는 태그만 써야하는 건 아닐 수도 있겠다는 결론을 내렸습니다. 마치 w3c validator에 에러와 경고 하나도 없이 맞춰야만 하는 게 항상 옳은 건 아니듯이요.

  20. 정찬명 댓글:

    행복한 고니님 의견도 일리는 있습니다만 아마도 현재까지는 지원하지 않아서 사용자들이 익숙하지 않을 뿐 헤딩 요소를 지원한다면 구조적인 글쓰기 습관은 금방 익숙해 질 수 있을꺼라고 전망합니다.

    조금 삼천포로 빠지는 이야기 이기는 한데 고니님은 새해 첫날 저희 팀으로 전배 오셔서 XE 프로젝트에 함께 참여하시게 되었습니다. ^^

    다시 본론으로 돌아와서 [u] 엘리먼트는 사실상 deprecated 되어서 strict DTD를 사용하는 경우 문법 오류로 간주 하지만 transitional DTD에서는 아직 폐기하지 않고 HTML/XHTML 에서 모두 허용하고 있습니다.

    하지만 사용자들이 밑줄을 이용해서 강조하려는 경우를 보다 의미있게 처리하고자 한다면 [em] 요소에 인라인 스타일을 넣어서 [em style=”font-style:normal; text-decoration:underline”] 이렇게 처리하는 것도 하나의 방법일 수 있겠다는 생각이 듭니다.

    이 방법의 단점은 사용자가 ‘밑줄’과 ‘이텔릭’을 확연히 구분해서 사용하지만 결국 하나의 요소로 마크업 하는 것이기 때문에 의미가 ‘차별화’ 되지 않는다는 점. 그리고 CSS를 지원하지 않는 장치에서 ‘밑줄로 강조하고픈 사용자의 의도’가 반영되지 못한다는 점 인것 같습니다.

    [u] 요소를 사용한다면 CSS를 지원하지 않는 장치에서도 저자가 원했던 표현으로 노출되기 때문에 의미없는 마크업이지만 결국 읽는 독자에게는 ‘강조’라는 의미가 제대로 전달되고 이점은 아직 유용하다는 생각 입니다. 기계는 아무 의미 없이 받아들이겠지만 사람은 ‘강조’했다고 받아들일테니까요.

    HTML이 이런 현실을 받아들여서 ‘강조를 3개의 단계로 지원했다면 어땠을까?’ 라는 생각이 듭니다. ‘강한 강조[strong], 통상의 강조[?], 약한 강조[em]’

    HTML이 현실세계의 욕구를 즉각 반영하지 못하는 경우도 존재하기 때문에 맹목적으로 표준을 따르고자 한다면 오히려 부작용이 생길 수도 있다고 생각합니다. 표준은 가장 적절한 수단 은 될 수 있지만 목표는 아니라고 생각합니다. 저희들이 목표해야 할 것은 ‘상호 운용성’이나 ‘보편적 접근’이고 이런 목표를 달성하기 위해 표준을 이용할 뿐이죠.

    그런데 종종 ‘목표와 수단’을 혼동하시는 분들도 있는것 같습니다.

  21. 황준상 댓글:

    쌩뚱맞게 궁금한 점이 있습니다..

    defer=”defer” 와 window.onload 와의 다른점이 뭔지 궁금합니다.

  22. 정찬명 댓글:

    허걱, 저도 궁금한데요. ㅡㅡ;
    둘 다 문서가 로드되기 전까지 아무것도 실행하지 말라는 명령이 되는군요.
    분명 어떤 고수님께서 홀연히 나타나 답변 주시리라 믿습니다. ㅎㅎ.

  23. SmartEditor™…

    tagfree , 나모인터렉티브의 에디터를 걷어내려고 한다.
    물론 이것들이 가지는 기능중 MS-word와의 연동기능ë…

  24. 김주원 댓글:

    어익후…외계어 죄송합니다.
    wordpress설치후 트랙백을 처음 걸어봤더니 저모냥이네요;;아 골치야;;
    지저분한건 지우셔도 괜찮습니다.

  25. 정찬명 댓글:

    소중한 트랙백 잘 받았습니다. ^^ 링크가 깨진 트랙백만 지웠는데요. 글자는 왜 깨지는지 잘 모르겠네요. ㅡㅡ;

  26. 김대현 댓글:

    에디터 비교표에 보니까 FCKEditor 라이센스가 CDL밖에 없는데 오픈소스 라이센스로 GPL, LGPL, MPL도 같이 되어 있습니다. 혹시 빠트리신건가 해서요.. ^^
    http://www.fckeditor.net/license

  27. 정찬명 댓글:

    김대현님 감사합니다. 중요한 착오가 있었네요. 저는 그걸 왜 못 봤을까요. ㅜㅜ;

  28. 이영열 댓글:

    스마트에디터를 사이트에 적용하려 하는데 큰문제가 하나 있네요.
    상위(부모) div 태그를 display:none 으로 해놓은 상태로 페이지를 열면 에디터가 활성화가 안되네요.
    일단 숨겨두었다가 상황에 따라 에디터화면을 보여주려고 하는데 로딩시 상위태그가 display:none으로 되어 있으면 추후 display:block 으로 바꾸더라도 에디터화면이 안나옵니다.
    (정확히는 IE에서는 아예 안보이고, FF 같은데서는 일부만 보이나 에디터입력은 할수없음)

    여기저기 검색하고 dev.naver.com 에 물어봐도..해결책을 못찾았습니다.
    정찬명님 혹시 이것 관련 방법을 알고계시면 도움좀 주세요.

  29. 정찬명 댓글:

    @이영열
    스마트에디터의 특정 기능을 구현하기 위해 사용한 자바스크립트 때문인 것으로 알고 있습니다. 다시말해서 스마트에디터는 항상 페이지 로딩시에는 화면에 보여야 합니다. 원하는 기능(최초에 에디터를 안보이도록 하는것)을 구현하려면 일단 display:none 아닌 방법으로 에디터를 화면에서 숨겨보세요. visibility:hidden 으로 처리하고 영역을 차지하지 않도록 position:absolute를 주거나 또는 에디터를 감싸고 있는 div 높이를 0px 으로 설정한 다음 overflow:hidden 처리해서 보이지 않도록 하거나 이런 시도를 해보세요. 된다는 보장은 없구요. 일단 display:none 아닌 방법으로 숨겨보라는 조언을 관련 개발자가 해주더라구요.

  30. 이영열 댓글:

    아하 그런방법이 있었네요
    말씀하신 방법으로 로딩하니 제대로 동작합니다
    감사합니다

  31. 한덕용 댓글:

    multipul 이 지원이 되는지요? 한 화면에 5~10개의 에디터를 모두 열어서 저장을 하려고 합니다.
    identifier 이름으로 나누어서 화면에데는 각각 에디터가 생성이 되나 각 에디터의 데이터를 받는게
    좀 힘들더군요. 어떠한 방법으로 하면 좋을까요? iframe 으로 각각 페이지를 나우어서 불러오는 방법이
    좋을까요?

  32. 정찬명 댓글:

    @한덕용
    제가 그것까지는 잘 모르겠습니다. ^^ http://dev.naver.com/projects/smarteditor/forum 게시판에 질문을 올려보시는 것이 어떨까요?

  33. 한덕용 댓글:

    답변 감사합니다. ^^

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님