gendoh 작성:

HTML 사이 영역은 에디터가 손대지 않는 부분이었으면 하는거죠. 야리꾸리한 코드를 넣고 에디터가 도저히 이해하지 못하도록 한 경우에도 전혀 지장이 없길 바란다는 것입니다. 만약 이런 부분이 없다면 에디터가 사용자의 코드를 임의 수정할 가능성이 존재하고 따라서 특정 코드는 삽입이 불가능해 질 수 있죠.

[HTML][/HTML] 안의 코드를 에디터가 건드리지 않도록 하는건 이 토픽과는 다른 얘기같습니다. 위지윅에서 아무런 처리를 하지 않아도 IE같은경우는 iframe에 innerHTML로 한번 넣었다 빼면 태그가 모두 대문자로 바뀐다던가 하는 일이 일어나게 되니까요.. 말씀하신 용도를 만족시키려면 위지윅모드로 진입이 불가능하도록 하는 옵션이 있어야 할 것 같습니다..

수정해봤습니다..
http://crizin.xyanblue.com 에서 테스트 해보실 수 있는데요 말씀하신 코멘트 개수랑 사이드바의 최근 올라온 글 옆의 코멘트 개수가 제대로 바뀌는지, 방명록에서 댓글 작성하고 삭제할때도 문제가 없는지 등을 체크해주시면 확인후 소스트리에 반영하겠습니닷

그건 그렇고 <span id="commentCount123></span> 같이 빈 태그가 곳곳에 남아있는게 찝찝하네요..;

78

(1 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

수정해두었습니다.. 감사합니닷 smile

ceris 작성:

방문해준 사람이 와서 댓글을 달았을 때 그거보고 다시 댓글을 달 때인데요.
지금은 쿠키로 이름이 있어도 이름란에 자동으로 포커스가 가네요..
쿠키가 있다면 내용란으로 포커스를 주면 좀 더 편리하지 않을까 합니다~

내용으로 포커스를 보내버리면 패스워드를 입력할때 다시 뒤로 돌아와야되니 좀 불편하지 않을까요?
그렇다고 패스워드로 포커스를 주는건 좀 어색하기도 하고..;

관련글 : http://dev.tattertools.com/wiki/105Requirements

디자인모드의 iframe에서 엔터를 누르면 IE의 경우는 p 태그를 넣어주고 FF는 br 태그를 넣어줍니다. 지금의 위지윅에디터는 IE에서 엔터를 누를때 강제로 br 태그를 넣도록 돼있구요.. 글을 작성할때 p 태그 사용을 원하시는분들이 많지만 소스 편집화면으로 들어가기 전에는 p 태그를 넣을 방법이 없다는게 문제인데.. 몇가지의 해결 방법이 있을 것 같습니다

1. 무조건 br 태그
2. 무조건 p 태그 (그리고 원하면 CSS에서 p {margin: 0} 하도록)
3. 엔터를 누르면 p, shift-엔터를 누르면 br 태그를 넣도록 한다
4. 엔터를 누르면 br, shift-엔터를 누르면 p 태그를 넣도록 한다
5. 환경설정에 항목을 추가해서 사용자가 선택하도록 한다

저는 1, 2번중 하나를 택해야 하는 상황이라면 1번이 좋고, 4번처럼 표준적인 과 반대로 가는 경우에는 여전히 귀찮기 때문에 별로라고 생각합니다.. 환경설정 항목을 추가하는 것 말고는 방법이 없는걸까요?

의견을 주세요~

gendoh 작성:

HTML이 사라지면.. 펌질할때 힘들어요. 잇힝.

Copy & Paste를 완벽히 지원하지 않는 이상은 다른 곳의 스타일이나 테이블을 깔끔하게 옮겨 오는 것은 힘들어 질것 같네요. 에디터가 Full Functionality를 가지기 전까지는(사실상 불가능하죠. MS-WORD정도는 되어야.. 그리고 되어도 부족한 것이고), 그리고 사용자들이 자신은 표준/비표준 상관없이 태그를 써야 하는 경우가 있을 수 있기 때문에 raw한 interface는 계속 존재해야 된다고 보입니다.

[HTML] 태그가 사라진다는 얘기는 텍스트 에디터 상에서 본문 전체를 항상 [HTML]~[/HTML]로 묶는다는 얘기랑 비슷합니다. [HTML][/HTML] 안에서 줄바꾸려면 br 태그 넣어야 되듯이 이제 텍스트 에디터에서는 항상 br 태그를 넣어야 되는거죠..

82

(4 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

본문 치환자를 만날때마다 함수를 호출하는 이벤트 방식은 괜찮은 아이디어 같네요..
지금은 기본 치환자들도 if(갤러리) 처리; if(이메이징) 처리; if(쥬크박스) 처리; 같이 단순하게 처리되고 있는데 이런 것도 core/components를 분리하는게 (가능하다면;;) 좋을 것 같습니다
TTML 가이드라인도 만들고 위지윅 에디터도 툴바버튼을 로딩할 수 있게 수정하고..
문제는 역시 시간이려나요 ;ㅁ;

saber 작성:
crizin 작성:

그리고 [CODE ][ /CODE] 블럭도 그냥 없애는게 어떨까 싶은데요.. HTML 코드를 보여주고 싶은 경우에는 <xmp> 같은 태그를 써 직접 적거나 플러그인을 이용하면 되고.. 아니면 위지윅에디터에서 작성후 4가지 박스 스타일을 클래식처럼 사용자가 지정할 수 있게 해서 쓰면 될 것 같습니다..

의견을 부탁드립니다~

그런데 xmp 태그는 XHTML 표준이 아닌 것으로 알고 있습니다만..
(HTML 4.0부터 제외되었는지 XHTML 1.0 부터 제외되었는지는 확실치 않지만..-0-)
w3schools 같은델 보면 xmp는 deprecated로 나옵니다.
pre 태그를 대신 쓸 수 있지만 귀찮아지는 면이 있기 때문에.. 코드 입력을 할때 모종의 자동화는 필요하지 않을까요?

음.. 그렇군요.. 근데 꼭 XHTML을 써야된다는 법은 없으니 플러그인으로 독립시켜 사용자의 기호에 맞기는게 좋을 듯 하네요~

[HTML][/HTML] 태그는 위지윅 에디터가 생기면서 사실상 애물단지가 돼버린 녀석인데요..

지금처럼 위지윅모드를 강제하지 않고 HTML편집/위지윅 환경을 환경설정에서 선택하게 하거나 마지막 편집 환경을 기억하도록 해서 HTML편집/위지윅을 적절히 띄워주게 된다면 굳이 [HTML] 태그는 필요가 없을거라고 생각합니다

이렇게 되면 바뀌게 되는 것들은,

1. 좋아지는 것
  1. 위지윅 에디터의 소스가 일부 간략해짐 -> 버그발생 가능성 낮아짐
  2. 포스트 출력할때 nl2br 하지 않고 그대로 출력하게 됨
  3. 텍스트 에디터에서 HTML을 작성할때 [HTML]태그로 묶거나 한줄로 붙여쓸 필요 없이 자유롭게 쓸 수 있음
2. 불편해지는 것
  1. 텍스트 에디터에서 글을 작성할때는 줄바꿈할때 <br/> 태그를 직접 넣어줘야 됨
  2. 1.0.4 이하 버전(클래식 이하 포함)에서 1.0.5 이후 버전으로 업그레이드 할때는 이미 입력된 [HTML] 태그를 제거하는 migration 작업을 해줘야 함

바꾸려는 이유는 소스코드 간소화도 있고, HTML 편집을 드러내서 HTML 에디터만 쓰는 사람들이 많이 생긴다면 지금처럼 한줄로 붙은 소스 편집하기가 쉽지 않기 때문에 원성이 자자할 듯 해서요.. 아무튼 지금 생각나는 문제들은 대충 이정도인데 2-2번이 가장 걸림돌이 될 것 같네요.. 또다른 문제점 있으면 얘기해주세요..

그리고 [CODE ][ /CODE] 블럭도 그냥 없애는게 어떨까 싶은데요.. HTML 코드를 보여주고 싶은 경우에는 <xmp> 같은 태그를 써 직접 적거나 플러그인을 이용하면 되고.. 아니면 위지윅에디터에서 작성후 4가지 박스 스타일을 클래식처럼 사용자가 지정할 수 있게 해서 쓰면 될 것 같습니다..

의견을 부탁드립니다~