2011-08-23 7 views
16

현재 사용자 불만 사항을 처리 중이며 불만 사항이 실제 버그인지 여부를 판단 할 수 없습니다. 기본적으로 사용자는 차단 인용구가 새 줄을 보존하지 않기 때문에 웹 사이트에 문제가 있다고 말합니다. 이것은 합리적으로 들리지만, 온라인에서 시도한 모든 markdown tester에서 blockquotes는 내 것과 동일하게 렌더링됩니다. 예 :마크 다운에서 줄 바꿈으로 줄 바꿈을 유지해야합니까?

안녕 무슨 일이야? 이것은 다중 행 인용 부호입니다.

멀티 라인 인용 부호로 입력해도, 줄 바꿈은 여전히 ​​StackOverflow에서 렌더링시 손실됩니다. 그래서 난 내 진짜 문제는 두 가지 추측 : 나는 blockquotes가 줄 바꿈을 유지하지 않아야이 점에 의해 99 % 확신

  1. ,하지만 난 여전히 경우 서로 다른 의견이 있는지보고 싶습니다 . 여러분 중 누군가가 그들을 보존해야한다고 생각합니까?

  2. 그 (것)들이 그 (것)들을 보존하면 안된다 pre와 부호를 사용해서 단순히 새로운 줄을 마크 다운에서 보존하는 적절한 방법일까요?

+0

아, 그래. 이것은 http://ux.stackexchange.com/에서 더 잘 질문 할 수 있습니다. 바로 프로그래밍 문제보다는 사용자 선호의 문제입니다. –

+0

그게 내가 확신 할 수 없었던 것이고 - 왜 내가 여기에 물었는지. Markdown에는 따라야 할 사양이 있다고 생각했습니다. 그렇지 않습니까? – Eli

+2

우주의 모든 응용 프로그램과 사이트가 자신이 사용하지 않는 '경량 마크 업 언어'를 어떻게 만들어야하는지에 대한 아이디어가 없다면 분명히 그렇게해서는 안되기 때문에 '사용자 환경 설정의 문제'라고 부르는 것이 이상합니다. 구현 프로그래머에게 무작위로 발생합니다. 필요한 것은 공통적 인 것에 대한 광범위한 이해입니다. 다른 것은 사용자의 두뇌 능력의 낭비이며 일반적으로 경량 마크 업을 허용 할 수있는 사용자가 소프트웨어에서 도망 칠 수있는 원인이됩니다. – applicative

답변

20

원래의 마크 다운 '사양'은 매우 모호하며 유지 관리되지 않습니다. 물론 perl 스크립트 markdown.pl, 즉 '참조 구현'이 있지만 많은 익숙한 기이함이 있습니다.

그루버의 부패로 인해 문제가있는 모순 된 상황에 영원히 불평하는 목록 http://six.pairlist.net/pipermail/markdown-discuss/에 가입 할 수 있습니다. 아마도 목록 사용자는 서로 다른 구현 간의 미묘한 차이점과 다른 확장 기능 간의 미묘한 차이로 인해 이러한 문제를 스스로 해결할 수있는 감각을 갖게 될 것입니다. 특히 그루버 (Gruber)가이 문제에 대한 모든 권리를 포기하지는 않지만 동시에 아무런 진보도하지 않는 한. 위원회가 구성되면 Markdown의 사양으로 어떤 사양도 말할 수 없습니다.

원칙적으로 블록 따옴표는 블록이 아닌 따옴표와 같은 원칙에 따라 관리됩니다. 예를 들어 블록 따옴표로 블록 따옴표를 사용할 수 있습니다. 따라서 친구는 틀 렸습니다. 사용자는 자신의 텍스트에 markdown.pl을 실행하여이를 증명할 수 있습니다. 다른 원칙은 완전히 혼란입니다.

이 라인

의 끝 부분에 여분의 공백과 줄 휴식
을 만들기위한 규칙이 완전히 분명하다

이 주
내부 여부

또는 외부
따옴표로 묶어서 설명해주십시오. 유래 인하 파서 여기에 좋은 것을

주 (나는.하지만, 메인 블록 따옴표로 반환하는 중첩 된 블록 인용을 종료하는 방식에 문제를 발견) 그러나 CSS의 저자는 매우 잘못했다 블록 따옴표와 주변 텍스트 사이의 간격은 단락 사이의 간격보다 큽니다. 단락 나누기가 여분의 공간으로 전달되는 것은 말도 안됩니다.블록 견적은 단락의 부분이고, 실제로는 일반적으로 문장 인입니다. . 외부 코드를 - 그것은 매우 긴 하나의 단어에 가깝다, 다른 인용처럼 당신이 서면으로 사용) 귀여운, 지겨운 전문 용어에 무슨 일이 자신을 호출하는 것을

참고 "GitHub의 ™는 맛 인하는"모든 줄 바꿈을 취급 블록 등 - 단락처럼, 기본적으로 마크 다운의 아이디어가 존재하지 않는 결정. 그것은 당신의 사용자가 그런 것들을 잘 알고있을 것입니다 - 적어도 블록 따옴표에 무엇이 들어 있는지가 규칙 밖에 없다는 규칙을 어기 지 않아도됩니다. GitHub Inc.는 ... 어 ... 'Gruber에게 이것이 유스 케이스의 합법적 인 가격 인하'라고 확신 시켰습니다. 이것에 대한 근거는 미완성 인 사람들이 자연스럽게 개행이 단락을 일으킨다 고 생각할 수도 있다는 것입니다. Gruber는 GitHub ™의 사용자 기반이 프로그래머으로 구성되어 있다는 것을 알고 있었을 것이므로 사양이나 표준에 대한 아이디어가 그에게 얼마나 가치가 있는지를 알 수 있습니다. 물론 GitHub에 대한 복잡한 문서 작성에 혼란을 일으켰습니다. ("Internet Explorer의 유스 케이스에 대한 합법적 인 HTML"이 없어야하는 이유는 무엇입니까? 많은 사람들이 IE에서 테스트하기 때문에 특정 합법적 인 기대치가 있습니까? 물론 GitHub의 결정은 그런 것보다 훨씬 나쁩니다.)

나는 잠시 생각을하지 않았기 때문에이 발언은 최신이 아닐 수도 있지만, 생각하지 않기로 결정한 이후로는 변경된 사항이 없습니다. 거기에는 그리고 아무 사양도 없을 것입니다. 당신이 그 문제에 대해 생각할 때마다 낭비하는 것은 인간의 에너지입니다. Markdown은 Gruber의 단순함 덕분에 지금까지 꽤 많이 생성되었습니다.

+16

Stack Overflow에서 블록 인용 부호로 줄 바꿈을하는 법을 배우려고 시도하면서 Google이 나를 데려 왔습니다. 당신의 대답에 대한'edit' 링크를 클릭 한 후에도 제가하지 않은 동안 당신이 어떻게 일했는지 알 수 없었습니다. 답에서 ** [줄 끝의 두 칸을 놓으면 ... 줄 바꿈을 만듭니다.] (http://meta.stackexchange.com/a/186647/178985) ** – dumbledad

+1

@dumbledad 와우, 그게 짜증나. 두 칸 .... 내 실제 줄 바꿈에 경의를 표하는 건 어때? :( –

+0

정확!하지만 같은 문제가있는 사람들은 지금 이걸 찾아야합니다. – dumbledad

관련 문제