GitHub đã gây rối với Markdown - thay đổi 666 thành DCLXVI


729

Kho lưu trữ GitHub của tôi không có gì ngoài một readme trong đó. Trong readme này, tại địa phương tôi đã viết điều này:

Factoids:
 - There are about six different ways to do everything in Forked.
 - There are actually six different ways to enter loops.
 - There are six directionals and six I/O commands.
 - 666. ha.

Nhấn mạnh vào dòng cuối cùng. Những gì GitHub quyết định thể hiện là không 666 .

dclxvi

DCLXVIlà số La Mã cho 666 .

Điều này thực sự làm tôi thất vọng. Tập tin cục bộ của tôi và tập tin thô đều hiển thị 666.

GitHub đang làm gì và tại sao phần thụt vào danh sách không được đánh số lại bị rối? Đây có phải là một quả trứng Phục sinh, hoặc một số lỗi satan?


15
Bạn đã thử - 5. whatevernó sẽ biến thành ·V whatevernếu tôi thấy nó chính xác
Hans Koch

8
Chỉ cần tự kiểm tra và tất cả các số chuyển đổi thành chữ số La Mã: github.com/NoahCristino/Forked/tree/ mẹo
Noah Cristino

27
@immibis sử dụng dấu gạch nối cho đạn là đánh dấu tiêu chuẩn phải không?
ESR

16
@EdmundReed Không phải là ký hiệu danh sách lồng nhau cũng đánh dấu tiêu chuẩn?
dùng253751

4
Đừng lo lắng về số Latin thực tế. Con số đó có lẽ hoàn toàn không có ý nghĩa gì đối với những hiểu biết chung là do lỗi dịch thuật.

Câu trả lời:


474

Điều này dường như được theo sau bởi vấn đề github / markup 991 , trong đó trên danh sách phụ được sắp xếp, các chữ số thập phân sẽ tự động chuyển thành chữ số La Mã.

Tôi đã tìm ra nguyên nhân của vấn đề. Nó là CSS

Đây là cách dự kiến ​​để các danh sách được sắp xếp lồng nhau hiển thị trong HTML.

Điều này không được mong đợi trong HTML. https://jsfiddle.net/tf5jtv8s

Chúng tôi không thực hiện bất kỳ sửa đổi nào đối với hành vi HTML mặc định.

ol ol,ul ol{list-style-type:lower-roman}

Tôi không biết CSS nhưng tôi hiểu rằng đây là nguyên nhân của vấn đề. Tôi có thể nhận được kết quả mong đợi bằng cách vô hiệu hóa CSS. (Tôi đến từ điện thoại di động nên không thể sử dụng trình kiểm tra trình duyệt)

Như đã đề cập trong " Một thông số chính thức cho GitHub Flavored Markdown ", GitHub markdown spec GFM: GitHub Flavored Markdown Spec được xây dựng trên đỉnh của CommonMark Spec .

Và như Tommi Kaikkonen đã đề cập trong câu trả lời của mình , danh sách được sắp xếp là do dấu chấm sau 666. Xem phần GFM Spec 5.2 .

Như đã đề cập trong phần 6.1 , bất kỳ ký tự dấu chấm câu ASCII nào cũng có thể được thoát dấu gạch chéo ngược, để tránh vấn đề này.
Điều đó có nghĩa là:

- 666\. ha.

(như được hiển thị rõ ràng trong câu trả lời của ForNeVeR )

Đó là lý do tại sao 666số đó được thay đổi thành chữ số La Mã trong phần đánh dấu GitHub README.


Mike Lippert bình luận:

yếu tố đầu tiên trong danh sách đó vì vậy nó sẽ hiển thị là ikhông dclxvi.
Danh sách theo thứ tự Markdown bỏ qua số thực tế được sử dụng và số liên tục và tôi chưa thấy cách nào để thay đổi điều đó.

Tuy nhiên, không: nó hiển thị dclxvi, bởi vì mã html được tạo <ol start="666">là phù hợp với thông số kỹ thuật của GFM :

Nếu mục danh sách được sắp xếp, thì nó cũng được gán một số bắt đầu, dựa trên điểm đánh dấu danh sách được sắp xếp "

(ở đây, ' 666' là điểm đánh dấu danh sách theo thứ tự)

Mike cho biết thêm:

@VonC Dành cho ai khác đây là một đoạn trích hữu ích khác từ liên kết doc của VonC:

"Số bắt đầu của một danh sách được sắp xếp được xác định bởi số danh sách của mục danh sách ban đầu. Số lượng các mục trong danh sách tiếp theo bị bỏ qua."


Ngoài ra, tại sao khoảng cách bị rối? Tôi đã không nắm bắt được điều đó trong câu trả lời của bạn

Bạn nhận được một danh sách được sắp xếp <ol>trong một mục danh sách chưa đặt hàng <li> :

<ul>
  <li>
    <ol start="666">
      <li>ha.</li>
    </ol>
  </li>
</ul>

Các quy tắc CSS của GitHub bao gồm:

.markdown-body ol {
    padding-left: 2em;
}

Nếu bạn đặt 3em, bạn sẽ nhận được thay vì
đệm chính xác

đệm sai


10
@MDXF Tôi nghi ngờ vì số được theo sau bởi một dấu chấm được chuyển thành một danh sách được sắp xếp trên cùng một dòng với một mục danh sách chưa được sắp xếp ('-'). Thông thường, <li> và <ol> không được hiển thị trên cùng một dòng ...
VonC

@MDXF Tôi đã chỉnh sửa câu trả lời với quy tắc CSS chính xác gây ra khoảng cách không chính xác.
VonC

2
Trên thực tế tôi nghĩ rằng đầu ra là một cải tiến đánh dấu mà tôi chưa từng nghe nói đến, hoặc là một lỗi. Có - .666 là một danh sách con được đặt hàng, TUY NHIÊN, nó là yếu tố đầu tiên trong danh sách đó vì vậy nó sẽ hiển thị như tôi không dclxvi . Danh sách theo thứ tự Markdown bỏ qua số thực tế được sử dụng và số liên tục và tôi chưa thấy cách nào để thay đổi điều đó.
Mike Lippert

2
@MikeLippert không, nó hiển thị tại dclxvi, bởi vì mã html được tạo <ol start="666">là phù hợp với github.github.com/gfm/#list-items : "Nếu mục danh sách được đặt hàng, thì nó cũng được gán một số bắt đầu, dựa trên điểm đánh dấu danh sách được sắp xếp "(ở đây, '666' là điểm đánh dấu danh sách được sắp xếp)
VonC

2
@VonC Cảm ơn, tôi đã không biết rằng việc tăng cường cho việc đánh dấu hương vị github và đã không tìm thấy nó với sự nhanh chóng trước khi tôi nhận xét. Đối với bất kỳ ai khác, đây là một đoạn trích hữu ích khác từ liên kết doc của VonC "Số bắt đầu của danh sách được sắp xếp được xác định bởi số danh sách của mục danh sách ban đầu. Số lượng các mục trong danh sách tiếp theo bị bỏ qua."
Mike Lippert

376

Thêm một khoảng thời gian sau khi 666làm cho nó một điểm đánh dấu danh sách theo thứ tự .

GitHub tuyên bố CSS biểu hiện các dấu danh sách được sắp xếp bằng chữ số La Mã:

ol ol,ul ol {
    list-style-type: lower-roman
}

Thoát khỏi giai đoạn với dấu gạch chéo ngược và bạn sẽ thấy đầu ra chính xác.


84

Mặc dù các câu trả lời khác rất tốt trong việc giải thích lý do tại sao bạn gặp vấn đề, nhưng họ không đưa ra cho bạn một ví dụ chính xác về cách khắc phục vấn đề đó.

Và dường như bạn đã giải quyết nó một cách không hoàn hảo , thay thế văn bản của bạn bằng

- `666`. ha.

Có một mẹo phổ biến để thoát dấu chấm sau số để làm cho nó trông giống như một văn bản bình thường (và không phải là nhãn danh sách được sắp xếp):

- 666\. ha. (this will render as you probably want)
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.