Chọn tham gia thử nghiệm alpha cho trình chỉnh sửa Stacks mới

Jan 27 2021

TL; DR : Chúng tôi đang thử nghiệm trình chỉnh sửa Stacks mã nguồn mở mới của mình , cung cấp cả các tùy chọn nhập văn bản đa dạng thức và Markdown. Nếu bạn quan tâm đến việc thử nghiệm nó và đưa ra phản hồi cho chúng tôi, bạn có thể chọn tham gia bằng cách truy cập trang tùy chọn của mình và bật Trình chỉnh sửa ngăn xếp. Bạn có thể chọn không tham gia bất kỳ lúc nào nhưng sẽ mất tới 10 phút để hoàn nguyên về trình chỉnh sửa cũ. Lưu ý, trình soạn thảo mới sẽ chỉ hoạt động khi soạn thảo hoặc chỉnh sửa câu trả lời trên MSE hoặc MSO trong quá trình kiểm tra alpha.


Khoảng sáu tháng trước, nhóm sản phẩm và nhóm Cộng đồng của chúng tôi đã bắt đầu khám phá xem liệu chúng tôi có thể đưa lên các trang web công khai của mình trình chỉnh sửa bài đăng văn bản có định dạng Stacks đã ra mắt trên Stack Overflow cho Nhóm (hoặc Nhóm) vào mùa hè hay không. Chúng tôi đã dành thời gian đó để thảo luận nội bộ về các nhu cầu và cũng nói chuyện với một số người dùng có mức độ tương tác cao nhất của chúng tôi về trình chỉnh sửa mới - Người điều hành và các thành viên của nhóm Charcoal - để hiểu những gì có thể cần thay đổi hoặc bổ sung để sử dụng trình chỉnh sửa mới một sự thay đổi dễ dàng từ trình chỉnh sửa cũ.

Thông qua quá trình này, chúng tôi đã nhận được hàng tá câu trả lời với các ý tưởng cải tiến, các lỗi cần được xử lý và sự nhầm lẫn về trải nghiệm người dùng cần được giải quyết. Chúng tôi đã giải quyết nhiều mối quan tâm mà hai nhóm này đã đề cập và sẵn sàng đưa nó đến với cộng đồng lớn hơn thông qua thử nghiệm alpha chọn tham gia trên MSE và MSO. Chúng tôi đang yêu cầu phản hồi mang tính xây dựng của bạn để xem có chỗ cần cải thiện để biến nó thành một công cụ mà cả những người cảm thấy thoải mái với Markdown và những người có thể cảm thấy thoải mái hơn với văn bản đa dạng thức đều có thể sử dụng thành công.

Đây là giao diện của hai chế độ xem - bạn có thể nhấp để xem hình ảnh lớn hơn:

Các bài kiểm tra

Mục tiêu của thử nghiệm alpha này là để có được hiểu biết ban đầu về mức độ tiếp nhận của trình chỉnh sửa mới này và cũng để khám phá bất kỳ mối lo ngại nào có thể phá vỡ quy trình công việc đối với những người dùng thích trình chỉnh sửa hiện tại hoặc muốn làm việc trong Markdown. Chúng tôi cũng muốn xem xét những người dùng có thể không quen thuộc với Markdown, vì họ tạo nên nhiều người dùng trên các trang web phi kỹ thuật của chúng tôi. Đây là giai đoạn công khai đầu tiên trong quá trình chúng tôi hy vọng sẽ kiểm tra và tinh chỉnh hoàn toàn trình chỉnh sửa để khi nó ra mắt trên toàn mạng, mọi người sẽ thấy dễ sử dụng và là một cải tiến lớn so với trình chỉnh sửa hiện tại.

Chúng tôi hiểu rằng mục nhập văn bản đa dạng thức là một điều khó thực hiện đúng và nhận ra rằng có thể mất vài tháng để tìm ra giải pháp phù hợp trước khi chúng tôi có thể đưa mạng trực tuyến này lên toàn bộ - và điều đó đi kèm với sự hiểu biết rằng có thể có những vấn đề không thể vượt qua - nhưng chúng tôi cảm thấy rằng làm việc thông qua quá trình này với các bạn, ít nhất sẽ giúp cải thiện trải nghiệm trình chỉnh sửa mới trên Teams và có thể kết thúc với một trình chỉnh sửa mới tuyệt vời cho mọi người sử dụng.

Đây là một phần của bài kiểm tra nhiều phần sẽ trông giống như sau:

  • Bản phát hành đầu tiên trên Teams với phản hồi từ những người dùng tương tác cao (ví dụ như Người điều hành) (Hoàn thành vào mùa hè năm 2020). Mục tiêu của việc này là nhận được phản hồi và biết rõ về mức độ chúng tôi cần thay đổi trình chỉnh sửa để nó hoạt động cho cộng đồng nền tảng công khai của chúng tôi. Điều này cho phép chúng tôi thử nghiệm nhiều (mặc dù không phải tất cả) các tính năng với một nhóm nhỏ người mà không ảnh hưởng đến trang web công cộng.
  • Thử nghiệm trên MSE và MSO thông qua thử nghiệm alpha chọn tham gia. Mục tiêu ở đây là cải tiến hơn nữa và xác định các giải pháp sẽ giúp trình chỉnh sửa mới được người dùng, chủ yếu là các thành viên tích cực của cộng đồng chấp nhận một cách công khai.
  • Các phiên kiểm tra khả năng sử dụng với người dùng ở một số cấp độ kinh nghiệm khác nhau. Mục tiêu ở đây là đảm bảo rằng các tính năng và trải nghiệm người dùng mà chúng tôi tạo ra sau khi phản hồi những người dùng tương tác cao của chúng tôi vẫn minh bạch với những người khác. Chúng tôi sẽ theo dõi cách người dùng ở các cấp độ trải nghiệm khác nhau tương tác với trình chỉnh sửa để xác định và thực hiện các cải tiến bổ sung với mục tiêu là trải nghiệm người dùng trực quan có đủ hướng dẫn khi cần thiết.

Theo dòng thời gian, điều này dự kiến ​​sẽ mất một thời gian để hoàn thành. Một trong những lợi ích của thử nghiệm alpha là mọi người có thể bật và tắt nó theo ý muốn. Trong thời gian còn lại của Quý 1 năm 2021, kế hoạch của chúng tôi là để chạy thử nghiệm để mọi người có thể dùng thử theo cách lâu dài hơn nếu muốn. Mặc dù chúng tôi sẽ sửa các lỗi lớn, nhưng chúng tôi sẽ không ưu tiên các tính năng hoặc điều chỉnh mới cho đến khi chúng tôi bắt đầu tìm hiểu phản hồi của bạn từ thử nghiệm này và phản hồi từ các phiên về khả năng sử dụng trong quý 2 năm 2021. Xem thêm một chút về điều này trong phần phản hồi bên dưới.

Giả sử các thử nghiệm này diễn ra tốt đẹp và chúng tôi tìm thấy các giải pháp giúp việc tạo và chỉnh sửa bài đăng dễ dàng hơn hệ thống hiện tại, chúng tôi sẽ chuyển sang giai đoạn triển khai dần dần, bắt đầu lại với MSE và MSO, sau đó đến các trang web có công cụ chỉnh sửa tiêu chuẩn, đặt trước các trang web với các tiện ích bổ sung trình chỉnh sửa chuyên biệt cho phần cuối để chúng tôi có thể đảm bảo rằng các công cụ của họ hoạt động chính xác khi khởi chạy.


Tại sao chúng tôi lại làm việc để đưa một trình soạn thảo văn bản phong phú vào các trang web của mình?

Mặc dù đã có một số yêu cầu về tùy chọn nhập văn bản đa dạng thức trong những năm qua (tùy chọn này có từ năm 2009 ), nhưng người dùng chưa bao giờ nhận được nhiều sự ủng hộ dành cho họ - trên thực tế, nhiều yêu cầu nhận được sự đồng tình mạnh mẽ từ những người dùng khác . Markdown là một công cụ tuyệt vời và nhiều người dùng đã hoặc đang quen với nó - tôi thừa nhận thường xuyên cố gắng sử dụng Markdown trong không gian văn bản đa dạng thức. Điều đó nói rằng, nhiều yêu cầu trong số này đã được thay thế Markdown bằng văn bản đa dạng thức và đó không phải là điều chúng tôi muốn làm.

Là một nền tảng được phần lớn các lập trình viên sử dụng, Markdown nói chung là một định dạng quen thuộc với nhiều người và họ rất thoải mái khi sử dụng nó, đặc biệt là bây giờ chúng tôi tuân theo các tiêu chuẩn CommonMark. Đối với những người không biết Markdown, chúng tôi mong họ học hỏi và chúng tôi sẽ hỗ trợ họ nhưng trong nhiều trường hợp, các bài đăng có định dạng kém và cần sự tham gia của cộng đồng để cải thiện. Nhiều chỉnh sửa của tôi trên Người học tiếng Anh hoàn toàn là để cải thiện định dạng bài đăng.

Ngoài ra, trình chỉnh sửa của chúng tôi đã xuất hiện ngay từ đầu với một số cải tiến trong thời gian đó, do đó, cần có một bản nâng cấp lớn và trong tương lai, chúng tôi cảm thấy rằng trình chỉnh sửa được thiết kế lại sử dụng Stacks sẽ dễ dàng được bảo trì và cải thiện hơn khi chúng tôi tiếp tục.

Các đội cần một tùy chọn văn bản có dạng thức

Chúng tôi có một đội ngũ tuyệt vời làm việc để nâng cao sản phẩm Teams nhằm đáp ứng nhu cầu của các công ty và tổ chức đang sử dụng nó để chia sẻ kiến ​​thức nội bộ. Một điểm khó khăn thường xuyên từ những người dùng này là thiếu trình soạn thảo văn bản đa dạng thức - đây là tuyên bố từ Ham, một trong những nhà phát triển của Teams:

Chúng tôi đã bắt đầu xây dựng Trình chỉnh sửa ngăn xếp mới để phản hồi phản hồi từ khách hàng Tràn ngăn xếp dành cho nhóm của chúng tôi. Mặc dù Markdown đã trở thành một định dạng phổ biến và thành công để viết nội dung - không chỉ tại Stack Exchange mà trên toàn bộ web - một số khách hàng trong Nhóm của chúng tôi nói với chúng tôi rằng họ không thoải mái khi viết nội dung của mình trong Markdown. Họ không biết cú pháp và phải đối mặt với một đường cong học tập trước khi họ có thể bắt đầu viết theo cách họ muốn. Viết câu hỏi và câu trả lời không dễ dàng như họ đã quen với từ những nơi khác. Đối với chúng tôi, điều quan trọng là làm cho việc đóng góp dễ dàng nhất có thể. Viết câu hỏi và câu trả lời nên cảm thấy tự nhiên và không có nhiều va chạm.

Điều này thật ý nghĩa. Sao chép và dán từ trình chỉnh sửa văn bản đa dạng thức như Google Tài liệu hoặc Word phổ biến hơn nhiều trong một công ty nơi bạn có thể chuyển thông tin từ tài liệu hiện có cho Nhóm, trong khi phần lớn nội dung trang web công cộng của chúng tôi được tạo từ đầu. Điều đó nói rằng, việc sao chép nội dung dưới dạng trích dẫn vào các bài đăng không phải là chưa từng có, trong đó tính năng phát hiện văn bản đa dạng thức sẽ hữu ích để việc thêm Markdown theo cách thủ công là không cần thiết.

Động lực chính cho sự phát triển của trình chỉnh sửa mới là cải thiện trải nghiệm của Teams cho người dùng hiện tại của chúng tôi và cung cấp cho nó một bộ tính năng sẽ thu hút thêm người dùng. Điều đó nói rằng, vì nhiều người sử dụng Teams là các nhóm lấy nhà phát triển làm trung tâm, họ cũng thường cảm thấy thoải mái với Markdown, vì vậy chúng tôi muốn đảm bảo rằng cả hai tùy chọn đều có sẵn. Nội dung khác của Ham:

Trình chỉnh sửa ngăn xếp mới cố gắng trở thành người tốt nhất của cả hai thế giới. Nếu bạn hài lòng với việc viết Markdown và thích cách mà trình soạn thảo cũ đã giúp bạn làm điều đó, thì trình soạn thảo mới sẽ cảm thấy rất quen thuộc. Bạn có thể viết Markdown, sử dụng các phím tắt quen thuộc, tải lên hình ảnh và hơn thế nữa. Nếu Markdown không phải là điểm mạnh của bạn, thì Stacks Editor cho phép bạn chuyển sang chế độ văn bản đa dạng thức mới cho phép bạn viết theo kiểu WYSIWYG hơn.

Chúng tôi vẫn nghĩ rằng Markdown là con đường để đi, nhưng chúng tôi cũng thấy những lợi ích của trình soạn thảo văn bản đa dạng thức đối với những người dùng ít kỹ thuật và / hoặc các trang web có thể quen với chỉnh sửa kiểu WYSIWYG hơn. Với Trình chỉnh sửa ngăn xếp mới, Markdown tiếp tục là định dạng hàng đầu cho nội dung của bạn và mọi thứ bạn viết sẽ được chuyển đổi và lưu trữ dưới dạng Markdown vào cuối ngày.

Vì vậy, trọng tâm của chúng tôi trong việc xây dựng trình chỉnh sửa mới là thêm tùy chọn văn bản đa dạng thức nhưng vẫn duy trì tiêu điểm Markdown vì chúng tôi yêu thích Markdown và nghĩ rằng đó là một trải nghiệm tuyệt vời cho những ai đã biết cách sử dụng nó và tương đối đơn giản để học nhưng chúng tôi cũng muốn đơn giản hóa hoặc cải thiện trải nghiệm cho những người có thể đang sao chép dán vào bài đăng hoặc những người không biết Markdown.

Không chỉ là văn bản đa dạng thức, chúng tôi đang đơn giản hóa công việc trong tương lai để phát triển

Trình chỉnh sửa hiện tại đã xuất hiện từ năm 2008 và mặc dù chúng tôi đã thực hiện các thay đổi trong quá trình thực hiện, nhưng nó hầu như không thay đổi và giờ đây việc tạo các tính năng mới trở nên khó khăn. Ngoài ra, bằng cách áp dụng và cải tiến trình chỉnh sửa Nhóm trên mạng công cộng của chúng tôi, chúng tôi đang đơn giản hóa công việc trong tương lai trên các trang hỏi, trả lời và chỉnh sửa cũng như duy trì các tính năng tương tự giữa Nhóm và mạng. Câu nói cuối cùng của tôi từ Ham:

Trình chỉnh sửa cũ của chúng tôi đã phục vụ tốt cho chúng tôi trong nhiều năm, nhưng do một số vấn đề (mã được thiết kế ngược khó làm việc, API không đủ để xử lý các vấn đề trên nhiều trình duyệt và hỗ trợ nội dung có thể chỉnh sửa đơn giản), chúng tôi không thể sử dụng nó làm cơ sở cho bất kỳ nâng cấp lớn nào. Ngoài ra, có nhiều lợi thế từ việc dựa trên một trình soạn thảo trên nền tảng hiện đại (như chúng tôi đã làm ở đây trên prosemirror ), có thể giải quyết nhiều mối quan tâm khó chịu về "nội dung có thể chỉnh sửa" và giữ cho mọi thứ an toàn hơn và nhiều trình duyệt hơn tương thích.

Đã tồn tại lâu như vậy, nó đã tích lũy khá nhiều vụn vặt và khó có thể duy trì và phát triển theo cách mà chúng ta mong muốn. Trong những năm qua, chúng tôi đã thử sửa đổi trình chỉnh sửa một vài lần chỉ để nhận ra rằng nó quá khó để thực hiện. Khi chúng tôi bắt đầu xây dựng các biên tập viên mới cho đội, chúng tôi biết đây sẽ là một cơ hội tốt để Greenfield một cuộc cải tổ biên tập mới mà cuối cùng sẽ được hưởng lợi tất cả người dùng của chúng tôi trên mạng.

Trên hết, chúng tôi đang mở trình chỉnh sửa để mọi người sử dụng và đóng góp. Giống như Stacks, trình chỉnh sửa mới có nguồn mở, vì vậy nếu bạn quan tâm đến cách nó được xây dựng hoặc muốn đóng góp để cải thiện nó, bạn có thể tìm thấy nó trên repo Stacks-Editor .

Việc xây dựng trình chỉnh sửa rất khó - đặc biệt là khi xử lý văn bản có dạng thức

Tôi đã học được những điều kỳ quặc của một loạt các trình soạn thảo khác nhau trong nhiều năm, cho dù đó là BBCode trên các diễn đàn mà tôi tham gia, Wikitext trên MediaWikis, Markdown tại đây trên Stack Exchange, hoặc bất kỳ trình soạn thảo văn bản đa dạng thức hoặc tổng hợp nào khác nhau các nền tảng tôi đã sử dụng (ví dụ: Jira, FreshDesk)… vì vậy tôi cảm thấy thoải mái khi thích nghi với các phong cách mới, nhưng tôi cũng thấy rằng một số biên tập viên đưa ra các giả định khiến tôi thất vọng và bối rối và khiến tôi không muốn sử dụng chúng nữa. Chúng tôi muốn tránh sự thất vọng này!

Bởi vì trọng tâm của chúng tôi là Markdown, với việc bổ sung định dạng đặc biệt cho bảng và trình sửa lỗi, chúng tôi có thể giới hạn những gì trình chỉnh sửa văn bản đa dạng thức của chúng tôi phải làm - chúng tôi không tăng các tùy chọn định dạng có sẵn (ví dụ: văn bản nhiều màu sắc hoặc gạch chân) đó là một cách chúng tôi đang làm việc để giữ cho việc triển khai văn bản có định dạng và việc chuyển đổi giữa văn bản có định dạng và Markdown đơn giản, dễ hiểu và không gây khó chịu nhất có thể.

Những thay đổi lớn

Ngoài mục nhập văn bản đa dạng thức tùy chọn, có một loạt các thay đổi khác, lớn và nhỏ, mà bạn sẽ thấy trong bài kiểm tra này. Dưới đây là một số cách lớn nhất bao gồm tổng quan ngắn gọn về cách hoạt động của mục nhập văn bản có định dạng. Rất nhiều nội dung được viết dưới đây được viết bởi Ben Kelly, người đã làm việc rất nhiều với Ham để giúp người biên tập này hoạt động và cực kỳ am hiểu về các tính năng, rất cảm ơn anh ấy vì điều đó!

Chế độ văn bản đa dạng thức

Chế độ chỉnh sửa này được thiết kế gần giống với phần mềm xử lý văn bản truyền thống mà nhiều người dùng quen thuộc. Tuy nhiên, chúng tôi đã thêm vào một số tính năng bổ sung:

  • "Quy tắc đầu vào" kiểu đánh dấu xuống cho cú pháp cấp khối
    • Gõ #, ##, v.v. sẽ tạo ra một tiêu đề; gõ> tạo một câu trích dẫn; * tạo một danh sách, v.v.
    • Chúng tôi có các quy tắc nhập nội tuyến (in đậm, in nghiêng, mã nội tuyến, v.v.) trên danh sách những điều cần điều tra để phát hành trong tương lai
  • Các công cụ chỉnh sửa liên kết và hình ảnh sẽ cho phép chỉnh sửa các URL liên kết cho các liên kết và bổ sung mô tả hình ảnh và tiêu đề cho hình ảnh.
  • Hỗ trợ sao chép / dán thông minh - Dán nội dung bên ngoài từ Google Tài liệu hoặc mã từ trình biên tập bạn chọn sẽ giữ lại hầu hết các định dạng hiện có của nó, miễn là định dạng đó nằm trong Markdown.

Cuối cùng, trình chỉnh sửa văn bản đa dạng thức được chuyển đổi trở lại Markdown và sẽ hỗ trợ mọi thứ bạn có thể làm trong Markdown, với một số lưu ý:

  • Dán văn bản đa dạng thức từ các nguồn bên ngoài không phải là hoàn hảo, đặc biệt là với nội dung rất phức tạp
  • Những gì chúng tôi có thể hỗ trợ trong chế độ văn bản đa dạng thức bị hạn chế bởi triển khai Markdown hỗ trợ của chúng tôi, vì vậy những thứ như ô đã hợp nhất trong bảng hoặc siêu / chỉ số con không được hỗ trợ, ngay cả khi chúng tôi hỗ trợ HTML (xem dấu đầu dòng tiếp theo).
    • Đây thực sự là một tính năng hơn là một nhược điểm. Chúng tôi <3 Markdown và cam kết hỗ trợ nó hạng nhất trong tương lai gần
  • Hỗ trợ HTML là CỨNG. Chúng tôi không hứa hẹn rằng bất kỳ HTML nào được viết ở chế độ Markdown sẽ có thể chỉnh sửa được ở chế độ văn bản đa dạng thức
    • Chúng tôi khuyên bạn nên sử dụng cú pháp dấu chung tương đương khi có sẵn. Chúng tôi đang tìm cách mở rộng cú pháp Markdown được hỗ trợ của mình để người dùng không cần phải nhập HTML nữa.
    • Đừng hỏi tại sao HTML lại khó . Đó là một câu chuyện dài có thể là một bài đăng trên blog của riêng nó.

Markdown - trình chuyển đổi văn bản đa dạng thức

Để cho phép di chuyển giữa các chế độ văn bản đa dạng thức và Markdown, chúng tôi đã thêm một nút chuyển. Khi dấu chấm ở bên phải (nền xanh lá cây), bạn đang ở chế độ Đánh dấu; ở bên trái (nền xám), bạn đang ở chế độ văn bản đa dạng thức. Mặc định hiện tại cho tất cả người dùng là Markdown nhưng sau khi bạn sử dụng trình chỉnh sửa, hệ thống sẽ ghi nhớ tùy chọn được sử dụng gần đây nhất của bạn làm mặc định. Vì vậy, nếu bạn gửi một bài đăng hoặc chỉnh sửa trong khi ở chế độ xem Markdown, bạn sẽ thấy rằng vào lần tiếp theo khi bạn mở trình chỉnh sửa; nếu bạn làm như vậy trong văn bản đa dạng thức, đó sẽ là chế độ xem bạn có khi sử dụng nó lần sau. Cấu hình mặc định cho người dùng có thể được thay đổi theo từng trang web, vì vậy nếu một trang web cảm thấy rằng văn bản đa dạng thức có ý nghĩa hơn như mặc định của họ, chúng tôi có thể cho phép điều đó.

Bản xem trước được thu gọn vào chế độ xem văn bản có định dạng

Trong những năm qua, chúng tôi đã nhận được rất nhiều câu hỏi về việc liệu chúng tôi có thể tối ưu hóa bản xem trước để nó không chiếm quá nhiều không gian trên màn hình hay không. Nếu bạn đã từng viết các bài đăng dài, bạn có thể quen với cảm giác phải thực hiện rất nhiều thao tác cuộn để chuyển từ cuối bản xem trước trở lại cửa sổ chỉnh sửa. Với trình chỉnh sửa mới, bạn có thể xem bản xem trước bằng cách sử dụng nút chuyển đổi Markdown để chuyển đổi giữa chế độ Markdown và văn bản có định dạng và vì bản xem trước văn bản có định dạng là một phần của trình chỉnh sửa, bạn có thể chỉnh sửa ngay trong bản xem trước thay vì phải tìm cửa sổ chỉnh sửa lần nữa. Điều này cũng thuận tiện hơn rất nhiều cho người dùng di động, với màn hình nhỏ hơn của họ, nơi việc cuộn qua ngay cả một bài đăng ngắn cũng có thể mang lại rất nhiều công việc.

Aaron, Nhà thiết kế sản phẩm chính của chúng tôi cho các hệ thống Thiết kế giải thích giá trị của bản xem trước có thể chỉnh sửa:

Chúng tôi nghĩ rằng đây không chỉ là một vấn đề về bố cục. Chúng tôi có thể đặt các bản xem trước này cạnh nhau hoặc chuyển đổi giữa chúng như GitHub, nhưng tôi nghĩ rằng việc có một bản xem trước là điều chúng ta có thể tiến xa hơn. Chú thích nhỏ: Tôi đã làm việc trên trình biên tập của GitHub vào năm 2016! Chúng tôi có thể khám phá các lựa chọn thay thế như có một nút khởi chạy bản xem trước toàn màn hình, nhưng tôi nghĩ đó là nỗ lực lãng phí khi chúng tôi có thể viết trực tiếp trong trải nghiệm xem trước.

Web đã phát triển vượt mức yêu cầu cú pháp Markdown và các bản xem trước rời rạc. Tại sao bất kỳ chỉnh sửa văn bản nào nên cung cấp trạng thái xem trước chỉ đọc vào năm 2021? Việc viết, xem trước, nhận thấy lỗi và quay lại trình chỉnh sửa có thực sự tốt hơn việc chỉ có thể chỉnh sửa văn bản không? Bạn có chấp nhận mô hình tương tác này trong trình xử lý văn bản của mình không? Trong ý niệm? Trong Google Tài liệu? Ở mức trung bình?

Chúng tôi cảm thấy đây là một sự thay đổi tích cực vì những lý do này và nhiều lý do khác nhưng chúng tôi hiểu rằng đó là một sự khác biệt lớn so với định dạng hiện tại. Vui lòng dành chút thời gian để xem cảm giác của quy trình làm việc mới này và cho chúng tôi biết suy nghĩ của bạn và cách chúng tôi có thể cải thiện điều này. Tôi biết rằng nhiều yêu cầu trước đây dành cho bản xem trước song song để phục vụ cho các màn hình rộng hơn mà nhiều người có, đặc biệt vì điều này phù hợp với nhiều trình chỉnh sửa Markdown khác. Thật không may, điều này có thể phức tạp trên các màn hình nhỏ hơn, đòi hỏi vị trí khác nhau và khá phổ biến khi có các bản xem trước tách biệt với biểu mẫu nhập, như với định dạng hai tab của GitHub.

Chúng tôi có một số vấn đề đã biết ở đây:

  • Mặc dù việc chuyển đổi giữa các chế độ vẫn duy trì vị trí cuộn gần đúng của bạn, nhưng nó không nhớ vị trí con trỏ của bạn. Bất kỳ lúc nào bạn chuyển đổi, con trỏ của bạn sẽ di chuyển trở lại đầu bài đăng thay vì giữ nguyên vị trí của bạn.
  • Không có lịch sử khi chuyển đổi chế độ, vì vậy việc lật giữa các chế độ xem sẽ khiến bạn mất khả năng hoàn tác / làm lại các thay đổi từ chế độ xem khác.
  • Vì bản xem trước văn bản đa dạng thức sẽ diễn giải Markdown của bạn, mọi Dấu ấn (MD) không chính xác có thể bị trình chỉnh sửa văn bản đa dạng thức loại bỏ. Khi bạn quay lại chế độ xem MD, bạn sẽ có thể sửa các lỗi này.

Đánh dấu cú pháp trong chế độ Markdown

Bạn sẽ nhận thấy trải nghiệm Markdown của mình bớt đơn điệu hơn một chút vì giờ đây nó đáp ứng với Markdown mà bạn sử dụng bằng cách thay đổi văn bản trong ngăn - tiêu đề sẽ lớn hơn, văn bản in đậm sẽ xuất hiện đậm, cũng như in nghiêng và các liên kết sẽ có màu xanh lam và mã sẽ có màu xám. Tôi thấy điều này thực sự hữu ích trong việc soạn thảo các bài đăng vì nó xác định rất nhiều lỗi Markdown mà tôi có thể đã mắc phải, điều này khiến tôi thậm chí ít có khả năng phải xem bản xem trước. Điều này hiện không tuân thủ CommonMark nhưng chúng tôi đang cố gắng cải thiện nó.

Các thay đổi đối với các nút định dạng

Chúng tôi đã xóa một số nút và thêm một số nút mới vào những nút có sẵn để định dạng. Đây là giao diện của thanh định dạng bây giờ:

Đã xóa:

  • Hoàn tác / làm lại - các tính năng này vẫn hoạt động với các tổ hợp phím tiêu chuẩn của bạn nhưng chúng tôi đã tự loại bỏ các nút - chúng tôi cũng đã cải thiện hỗ trợ lịch sử hoàn tác / làm lại để về tổng thể đáng tin cậy hơn nhiều.
  • Stack Snippets (tạm thời) - Chúng tôi không thể tích hợp Snippets vào thử nghiệm alpha ban đầu, vì vậy nếu bạn cần thêm một đoạn mã vào bài đăng, bạn sẽ cần phải tắt alpha để làm như vậy.

Cập nhật / Mới:

  • Tables - nút này sẽ tạo một bảng ba hàng, hai cột mặc định và có các tùy chọn menu đặc biệt khi ở chế độ văn bản đa dạng thức cho phép thêm / xóa hàng và cột.
  • Headers - nút này đã được thiết kế lại và chuyển đến vị trí đầu tiên.
  • Các nút mã nội tuyến / khối mã / Đoạn mã ngăn xếp - một phần phản hồi từ các thử nghiệm ban đầu của chúng tôi là đối với văn bản đa dạng thức, chúng tôi cần phân biệt giữa mã nội tuyến và khối mã nhưng trên Nhóm, chúng tôi đã sử dụng lại cùng một biểu tượng cho các khối mã mà chúng tôi hiện đang sử dụng Stack Snippets - để cho phép cả ba tùy chọn, chúng tôi đã tạo các biểu tượng mới. Đoạn mã bị tắt cho alpha nhưng bạn có thể thấy bộ ba nút mới (từ trái sang phải - mã nội tuyến, khối mã, đoạn mã)

Chúng tôi dự định thêm phím tắt vào các nút định dạng nhưng chúng không phải là một phần của thử nghiệm alpha ban đầu này.

Chế độ Markdown là lựa chọn của bạn để tinh chỉnh các bài đăng

Chế độ đánh dấu sẽ cung cấp cho bạn toàn quyền kiểm soát các bài đăng của mình, như nó đã làm. Dưới đây là một số điểm bạn sẽ muốn gắn bó với MD khi soạn hoặc chỉnh sửa bài đăng:

  • Thêm ngôn ngữ vào khối mã cho mục đích làm nổi bật cú pháp - trong khi chúng tôi đang tìm cách thêm ngôn ngữ này vào văn bản đa dạng thức, thì bây giờ nó sẽ yêu cầu MD. Hệ thống vẫn sẽ tự động phát hiện ngôn ngữ dựa trên thẻ như thường lệ nhưng nếu bạn cần gọi một ngôn ngữ cụ thể, bạn sẽ cần sử dụng chế độ Markdown.
  • Đánh dấu yêu cầu HTML - chúng tôi vẫn hỗ trợ một số HTML trong bài đăng nhưng chế độ văn bản đa dạng thức sẽ không tạo nó, vì vậy nếu bạn cần đưa HTML vào bài đăng của mình để định dạng như chỉ số dưới hoặc chỉ số trên, bạn sẽ cần phải nhập chế độ Đánh dấu cho điều này.
  • Spoilers - giống như HTML, chúng được hỗ trợ nhưng chúng tôi không có nút cho nó, vì vậy bạn sẽ cần sử dụng chế độ Markdown để thêm chúng.
  • Tạo danh sách phức tạp - điều này có thể thực hiện được ở chế độ văn bản đa dạng thức, nhưng nó không trực quan bằng cách sử dụng Markdown, đặc biệt trong các trường hợp đặc biệt như danh sách có các khối mã được thụt lề.
  • Tinh chỉnh hình ảnh - thay đổi kích thước hoặc thêm liên kết đến nguồn hoặc hình ảnh có kích thước đầy đủ sẽ cần chế độ Markdown.

Văn bản nội tuyến và liên kết hình ảnh là tiêu chuẩn

Các công cụ hình ảnh và liên kết bây giờ sẽ thêm hình ảnh và liên kết nội dòng thay vì ở định dạng thư mục. Trong khi cái sau vẫn hoạt động, bạn sẽ phải tạo nó theo cách thủ công. Hiện tại, hình ảnh không có định dạng hình ảnh cộng với liên kết nhưng chúng tôi đang làm việc để bổ sung định dạng đó trong một bản phát hành trong tương lai.

Làm thế nào để tham gia

Nếu bạn muốn chọn tham gia thử nghiệm alpha, hãy truy cập trang tùy chọn của bạn và chọn tham gia bằng cách bật tùy chọn chọn tham gia Trình chỉnh sửa ngăn xếp. Ngay từ đầu, trình chỉnh sửa mới sẽ chỉ có sẵn trên các câu trả lời - bạn sẽ không thấy nó trên các câu hỏi, trang hồ sơ, trang chỉnh sửa thẻ hoặc bất kỳ biểu mẫu chỉnh sửa nào khác xung quanh trang web. Việc chọn tham gia là toàn cầu, vì vậy nếu bạn chọn tham gia MSE, bạn cũng sẽ thấy trình chỉnh sửa mới nếu bạn đang sử dụng MSO. Nếu bạn quyết định chọn không tham gia, bạn có thể làm như vậy theo cách tương tự, chuyển thanh trượt theo tùy chọn của bạn, mặc dù có thể mất đến mười phút để trình chỉnh sửa trở lại bình thường.

Gửi phản hồi

Giai đoạn phản hồi này là một phần cực kỳ quan trọng của quá trình này, vì vậy chúng tôi thực sự đánh giá cao bất kỳ bạn nào dành thời gian dùng thử trình chỉnh sửa. Nếu bạn gặp lỗi, các vấn đề về khả năng sử dụng hoặc nếu bạn nghĩ về các tính năng sẽ cải thiện trải nghiệm của bạn với trình chỉnh sửa mới, vui lòng để lại câu trả lời tại đây - mỗi câu trả lời một - để chúng tôi có thể xem xét và trả lời từng tính năng. Các bước để tái tạo một cách đáng tin cậy luôn được đánh giá cao cùng với / trình duyệt mà bạn đang gặp lỗi trong đó, và đặc biệt là khi nói đến các trường hợp góc cạnh khó hiểu hoặc các vấn đề về khả năng sử dụng tinh vi. Ngoài ra, vì dự án này có nguồn mở nên đối với các lỗi kỹ thuật thực sự, bạn có thể gửi chúng dưới dạng sự cố trên repo GitHub - nếu bạn cảm thấy thoải mái với điều đó - nếu chúng tôi nhận được báo cáo được gửi ở cả hai nơi, chúng tôi sẽ liên kết chúng.

Kế hoạch của chúng tôi là chuyển các vấn đề từ hệ thống nội bộ của chúng tôi sang kho lưu trữ GitHub và thêm bất kỳ vấn đề mới nào xuất hiện ở đây để bất kỳ ai quan tâm có thể xem chúng tôi đang làm gì và chúng tôi đang ưu tiên công việc này như thế nào.

Mặc dù thật tuyệt khi được nghe những suy nghĩ chung của bạn về người biên tập, nhưng nếu có quá nhiều thứ trong một bài đăng, điều đó có thể khiến việc trả lời trở nên khó khăn, vì vậy hãy cố gắng giữ từng câu trả lời tương đối ngắn gọn. Bạn sẽ có cho đến cuối alpha để thêm câu trả lời ở đây. Sau khi kết thúc, chúng tôi sẽ cho bạn biết cách tốt nhất để đưa ra phản hồi.

Cảm ơn

Dự án này không thể thực hiện được nếu không có công của rất nhiều người và tất cả họ đều xứng đáng được ghi nhận. Đặc biệt, tôi muốn ghi nhận Ben Kelly, Ham Vocke, Aaron Shekey, Des Darilek và Adam Lear vì tất cả những nỗ lực mà họ đã bỏ ra. Ngoài ra, gửi đến những người đã dành thời gian để kiểm tra và đưa ra phản hồi trong khi biên tập viên chỉ có trong Nhóm, cảm ơn bạn!

Trả lời

283 Makyen Jan 27 2021 at 04:44

lập kế hoạch

Việc tự động chuyển đổi "dấu ngoặc kép" thành "dấu ngoặc kép thông minh" là một thảm họa đối với các trang web tập trung vào mã.

Khi ở chế độ Rich Text, trình soạn thảo auto-converts double-quote characters into “smart quotes”, even for text entered in inline code format, nhưng may mắn thay, không ở trong các khối mã.

Điều này sẽ gây ra sự cố lớn trên các trang web tập trung vào mã như Stack Overflow và có khả năng gây ra sự cố nghiêm trọng trên ít nhất một số trang web khác.

Nói rõ hơn: ít nhất đối với các trang web tập trung vào mã, không nên có chế độ nào trong trình chỉnh sửa tự động chuyển đổi các ký tự dấu ngoặc kép thẳng thành “dấu ngoặc kép thông minh”. Để có một chế độ tự động thực hiện chuyển đổi đó sẽ dẫn đến việc chuyển đổi “báo giá thông minh” tự động được thực hiện thành mã, điều này sẽ phá vỡ mã. Có một chế độ như vậy sẽ tăng thời gian và nỗ lực trung bình cần thiết cho mỗi bài đăng trong tất cả các mục nhập gốc, chỉnh sửa, kiểm duyệt, xác định các vấn đề thực tế, v.v. Người dùng thường nhập mã dưới dạng văn bản thông thường, họ có thể hoặc không, sau này áp dụng mã định dạng thành, do đó, việc bật "dấu ngoặc kép thông minh" tự động ở bất kỳ chế độ nào sẽ gây ra thêm các vấn đề. Có một chế độ như vậy sẽ làm giảm sự hài lòng tổng thể của người dùng đối với tất cả các trang web tập trung vào mã, do các vấn đề bổ sung được đưa vào.

Về cơ bản, việc chuyển đổi tự động các ký tự trong dấu ngoặc kép thành “dấu ngoặc kép thông minh” là một tính năng mà một số người nghĩ rằng “dấu ngoặc kép đẹp”, nhưng lại gây ra các vấn đề cơ bản cho người khác (và một số người thực sự rất ghét “dấu ngoặc kép thông minh ”). Làm ơn, làm ơn đừng gây ra những "dấu ngoặc kép thông minh" cho chúng tôi.

234 E.P. Jan 28 2021 at 00:28

Tuyên bố từ chối trách nhiệm:

Hãy để tôi bắt đầu bằng cách xin lỗi vì giọng điệu thẳng thừng trong bài đăng này. Tôi đánh giá rất cao tinh thần cởi mở và làm việc chăm chỉ làm nền tảng cho phía phát triển và tôi muốn cảm ơn các bạn vì đã nỗ lực cải thiện giao diện người dùng cũng như thời gian và sự sẵn lòng dành cho việc thu hút ý kiến ​​phản hồi của cộng đồng. Tôi đưa ra phản hồi này với một số khía cạnh cùn vì điều đó quan trọng - bạn đang làm việc rất tốt, nhưng nếu bạn không làm công việc đó một cách cẩn thận thì rõ ràng có khả năng gây ra tác hại đáng kể và hầu hết các dấu hiệu tôi có thể thấy chỉ ra rằng quỹ đạo hiện tại của bạn đi theo hướng gây hại đó.

Những gì sau đây chỉ nhằm mục đích chỉ trích mang tính xây dựng, và tôi hy vọng nó sẽ đọc như vậy =).

Mà nói:

Sự thay đổi này là cực kỳ đáng báo động từ góc độ MathJax.

Triết lý thiết kế có ý nghĩa đối với nhiều trang web, nhưng một số thay đổi được đề xuất (cụ thể là xóa bản xem trước trực tiếp) sẽ là một thảm họa đối với các trang web mà MathJax là một phần phổ biến hoặc thiết yếu của trải nghiệm trang web. Xin nhắc lại, đây là không ít hơn 42 trang web trong tổng số 176 trang web , tức là 24% các trang web mạng.

(Ngoài ra, như đã chỉ ra trong các ý kiến, có bài định dạng một số plugin trang web cụ thể cần thiết khác mà đang ở trong một tình huống giống với MathJax, các ví dụ rõ ràng nhất trong số đó là cờ vua , đi , furigana và ký hiệu âm nhạc .)

Đây là những điều khiến tôi lo lắng nhất:

Chúng tôi có thể đặt các bản xem trước này cạnh nhau hoặc chuyển đổi giữa chúng như GitHub, nhưng tôi nghĩ rằng việc có một bản xem trước là điều chúng ta có thể tiến xa hơn.

uh ... không, không phải vậy.

Tại sao bất kỳ chỉnh sửa văn bản nào nên cung cấp trạng thái xem trước chỉ đọc vào năm 2021? Việc viết, xem trước, nhận thấy lỗi và quay lại trình chỉnh sửa có thực sự tốt hơn việc chỉ có thể chỉnh sửa văn bản không? Bạn có chấp nhận mô hình tương tác này trong trình xử lý văn bản của mình không?

Vâng, tôi sẽ. Tôi đã làm. Đây là phương thức làm việc chính của tôi. Trong lĩnh vực chuyên môn của tôi - tương tự như nhiều công cụ được đại diện trong các trang SE có MathJax - trình xử lý văn bản tiêu chuẩn của ngành là LaTeX. Có một trình chỉnh sửa và xem trước riêng biệt không chỉ là tiêu chuẩn mà nó còn là cách duy nhất để làm việc hiệu quả.

Ít nhất, xây dựng một trình soạn thảo WYSIWYG cho toán học là một công việc chính của phần mềm. Tuy nhiên, nói thẳng ra, không có giải pháp nào hiện có, với quỹ đạo hàng thập kỷ, biến quầy bar trở thành một tiêu chuẩn chuyên nghiệp. (Để rõ ràng: sẽ hoàn toàn vô nghĩa nếu thử nó ở đây.) Việc chỉnh sửa toán học hoàn toàn yêu cầu cấu hình mã và xem trước. Như vậy, nếu triết lý thiết kế của bạn là "có một bản xem trước là thứ mà chúng tôi có thể vượt qua", thì triết lý thiết kế của bạn không phù hợp với các yêu cầu của các trang web kỹ thuật.

Tất nhiên tôi thông cảm với mối quan tâm này:

Nếu bạn đã từng viết các bài đăng dài, bạn có thể quen với cảm giác phải thực hiện rất nhiều thao tác cuộn để chuyển từ cuối bản xem trước trở lại cửa sổ chỉnh sửa.

và thực sự nó có thể gây khó chịu (mặc dù, như đã được chỉ ra, không phổ biến ). Nhưng quan điểm đó đang thiếu một khía cạnh quan trọng khác về cách MathJax hoạt động trên Stack Exchange và đó là sự tiện lợi tuyệt vời và cực kỳ tiện lợi khi có một bản xem trước tức thì được hiển thị cùng với nguồn Markdown / MathJax văn bản thuần túy. Trong thực tế, các biên tập viên hiện nay là nhiều thuận tiện hơn so với các biên tập viên LaTeX chuẩn, do tốc độ và sự kiên trì của refresh xem trước - nó làm mới càng sớm càng thay đổi bất cứ điều gì, và nó chỉ bị giới hạn bởi (rất nhanh) tốc độ của đồ họa .

Trong các thay đổi được đề xuất (nguồn Markdown và bản xem trước đa dạng thức trên cùng một ngăn, với một nút để chuyển đổi giữa chúng), việc viết và chỉnh sửa toán học sẽ trở nên khó hơn đáng kể. Nói một cách thẳng thắn, việc loại bỏ chế độ xem trước đồng thời sẽ làm trục trặc các trang web kỹ thuật lớn, bigtime.


Bây giờ, tôi đánh giá cao những điểm được thực hiện liên quan đến tuổi của mã và độ khó của việc bảo trì mã cũng như sử dụng nó làm cơ sở để nâng cấp thêm. Hoàn toàn có ý nghĩa rằng cần phải có một cơ sở mã tốt hơn cho trình soạn thảo và nó phải được sử dụng trên toàn bộ mạng SE khi kết thúc triển khai.

... đó là lý do tại sao những mối quan tâm xung quanh MathJax lại là một phần của giai đoạn thiết kế ban đầu . Cái này :

Các trang web có MathJax là một trong những trang cuối cùng chúng tôi gửi trang này

là không đủ tốt. Các mối quan tâm xung quanh MathJax là một phần của các quyết định thiết kế cốt lõi cần được thực hiện. Nếu kế hoạch phải chờ đợi cho đến khi kết thúc, khi mọi thứ đã được hoàn thiện và tất cả các quyết định thiết kế đó đã được hoàn thành và hy vọng rằng những quyết định đó sẽ hiệu quả với hơn 40 trang web sử dụng MathJax, thì kế hoạch sẽ đọc "chúng tôi không quan tâm nếu các trang web kỹ thuật mathy kết thúc với tôi".

Nếu mục tiêu là có một cơ sở mã duy nhất hoạt động cho các trang web và Nhóm định hướng văn bản đa dạng thức cũng như cho các trang web kỹ thuật hướng MathJax, thì tính liên kết đó cần phải được công nhận ngay từ đầu: các quyết định thiết kế liên quan đến bản xem trước cần phải được tạo ngay bây giờ và một trang web mathy (math.se, Physics.se, stats.se, v.v. - lựa chọn của bạn) cần phải nằm trong số các trang web đầu tiên để kiểm tra nó.


Một điều nữa:

Đánh dấu cú pháp trong chế độ Markdown

Bạn sẽ nhận thấy trải nghiệm Markdown của mình bớt đơn điệu hơn một chút vì giờ đây nó đáp ứng với Markdown mà bạn sử dụng bằng cách thay đổi văn bản trong ngăn - tiêu đề sẽ lớn hơn, văn bản in đậm sẽ xuất hiện đậm, cũng như in nghiêng và các liên kết sẽ có màu xanh lam và mã sẽ có màu xám.

Thật tuyệt! Nhưng bạn cũng cần tắt nó bên trong dấu phân cách MathJax. Một số vấn đề trong số đó đã được chỉ ra , nhưng tôi sẽ nói rõ ràng ở đây: việc gây rối với định dạng như trong ảnh chụp màn hình này là cực kỳ mất tập trung, hoàn toàn vô ích (theo nghĩa là nó không đạt được bất kỳ mục tiêu nào, vì nó đang phản hồi cú pháp sẽ tạo ra kết quả khác với những gì mà công cụ đánh dấu nghĩ sẽ xảy ra) và nó không có chỗ trong trình soạn thảo toán học trong những năm 2010, chứ đừng nói đến những năm 2020.

107 SonictheCuriouserHedgehog Jan 27 2021 at 03:36

yêu cầu tính năng

Cho phép xem Markdown cùng lúc với văn bản đa dạng thức

Trong những năm qua, chúng tôi đã nhận được rất nhiều câu hỏi về việc liệu chúng tôi có thể tối ưu hóa bản xem trước để nó không chiếm quá nhiều không gian trên màn hình hay không. Nếu bạn đã từng viết các bài đăng dài, bạn có thể quen với cảm giác phải thực hiện rất nhiều thao tác cuộn để chuyển từ cuối bản xem trước trở lại cửa sổ chỉnh sửa. Với trình chỉnh sửa mới, bạn có thể xem bản xem trước bằng cách sử dụng nút chuyển đổi Markdown để chuyển đổi giữa chế độ Markdown và văn bản có định dạng và vì bản xem trước văn bản có định dạng là một phần của trình chỉnh sửa, bạn có thể chỉnh sửa ngay trong bản xem trước thay vì phải tìm cửa sổ chỉnh sửa lần nữa. Điều này cũng thuận tiện hơn rất nhiều cho người dùng di động, với màn hình nhỏ hơn của họ, nơi việc cuộn qua ngay cả một bài đăng ngắn cũng có thể mang lại rất nhiều công việc.

Như ai đó thay đổi nội dung faq bài viết ở đây khá thường xuyên, chắc chắn tôi hiểu được tình cảm ở đây. Phần lớn thời gian của tôi trong việc chỉnh sửa chúng là cuộn qua lại giữa bản xem trước bên dưới trình chỉnh sửa bài đăng và chính trình chỉnh sửa.

Tuy nhiên, trình chỉnh sửa mới loại bỏ khả năng xem kết xuất được hiển thị của văn bản cùng lúc với việc xem Markdown thô của nó. Là một người thường xuyên sử dụng các kỹ thuật Markdown nâng cao và các sắc thái tinh tế (và cả HTML không thường xuyên ) khi nhập bài đăng, việc phải liên tục lật qua lại công tắc mỗi khi tôi muốn xem bài đăng của mình trông như thế nào là một gánh nặng cực kỳ so với đơn giản di chuyển.

Điều này cũng khá quan trọng vì trong bản xem trước hiện tại, vì đầu ra được hiển thị chiếm nhiều không gian trên trang tổng thể như nó sẽ sử dụng khi được đăng (ít hơn một chút do thiếu lề trái cho các nút biểu quyết), điều này sẽ cho phép tôi ước tính sơ bộ thời lượng bài đăng của tôi, vì vậy tôi có thể điều chỉnh lại (ví dụ: loại bỏ các chi tiết không cần thiết) nếu nó quá dài. Bản xem trước mới khiến việc ước tính thời gian một bài đăng sẽ ở trên trang thực tế khi được đăng lên khó hơn nhiều, đó là điều mà tôi thường xuyên sử dụng đến mức phải cuộn.

Một lần nữa, tôi chắc chắn hoàn toàn hiểu được tình cảm đằng sau cách thiết kế trình chỉnh sửa mới hiện tại. Việc phải cuộn có thể khá khó khăn đối với nhiều người, đặc biệt là đối với các bài đăng lớn hơn (ví dụ: Câu hỏi thường gặp ở đây). Tuy nhiên, tôi là người thường xuyên sử dụng những thứ nâng cao hơn được kích hoạt bởi thiết lập hiện tại mà thiết lập mới sẽ gây khó khăn hơn cho tôi.

Xin vui lòng có một tùy chọn để xem bản xem trước hiển thị trực tiếp của một bài đăng cùng lúc như khi nhập Markdown thô vào trình chỉnh sửa? Điều này không cần phải ở dưới bài đăng như hiện tại, nhưng hãy xem xét điều này.


Tôi có lẽ nên lưu ý rằng với tư cách là thành viên của Nhóm, tôi đã có quyền truy cập vào trình chỉnh sửa này trong một thời gian khá dài. Tôi đã nhiều lần cố gắng làm quen với quy trình làm việc mới này, nhưng tôi vẫn chưa hài lòng.

Ngoài ra, những người đang tìm kiếm câu trả lời này cũng có thể muốn xem hai câu trả lời bổ sung được viết bởi Tinkeringbell, mở rộng dựa trên lập luận trong bài đăng này.

68 Glorfindel Jan 27 2021 at 02:54

tính năng-yêu cầu trạng thái-xem xét

Tôi không chắc tất cả người dùng sẽ hiểu cách hoạt động của nút 'Lựa chọn liên kết'. (Gợi ý: bạn phải chọn văn bản trước, sau đó nút mới được bật.) Các trình soạn thảo văn bản đa dạng thức khác mà tôi thường xuyên sử dụng có nút 'Chèn liên kết' nơi bạn có thể chỉ định cả liên kết và văn bản để hiển thị.

Vì vậy, một cái gì đó như thế này (xin lỗi vì mô hình xấu, hy vọng ý tưởng rõ ràng):

Hoặc bật nút này mọi lúc và nếu không có gì được chọn, hãy yêu cầu người dùng cung cấp một liên kết (như trình chỉnh sửa hiện tại) và chèn nó, với cửa sổ bật lên hiển thị để người dùng biết họ có thể chỉnh sửa cả văn bản liên kết và chính liên kết:

60 Tinkeringbell Jan 28 2021 at 01:13

yêu cầu tính năng

Nếu chúng tôi không thể có bản xem trước song song do hạn chế kỹ thuật, chúng tôi sẽ cần một giải pháp thay thế tốt hơn chế độ Văn bản có dạng thức để xem trước Markdown của chúng tôi . Thậm chí chỉ là một thiết lập hoặc chuyển đổi để đặt một cửa sổ xem trước trực tiếp bên dưới biên tập MD (như xem trước làm việc bây giờ) sẽ tốt hơn nhiều so với việc phải chuyển đổi giữa MD và RT biên tập viên .

Tôi sử dụng bản xem trước trực tiếp hiện tại rất nhiều khi viết bài. Khi viết các bài đăng có kích thước thông thường trên màn hình có kích thước thông thường, tôi luôn để mắt đến bản xem trước trực tiếp thay vì trình chỉnh sửa> 90% thời gian , có thể chỉ cuộn lên và rời mắt khỏi bản xem trước nếu tôi đang dán vào hình ảnh và hộp thoại yêu cầu tôi xác nhận hoặc nếu tôi quyết định thêm một câu khác vào paragaph. Quy trình làm việc thông thường của tôi bao gồm cuộn xuống trang web để xem bản xem trước trực tiếp so với việc thực sự nhìn vào trình chỉnh sửa nhiều lần.

Bài đăng nói rằng một lý do khiến trình chỉnh sửa RT có thể tốt hơn so với cách sắp xếp hiện tại là

Với trình chỉnh sửa mới, bạn có thể xem bản xem trước bằng cách sử dụng nút chuyển đổi Markdown để chuyển đổi giữa chế độ Markdown và văn bản có định dạng và vì bản xem trước văn bản có định dạng là một phần của trình chỉnh sửa, bạn có thể chỉnh sửa ngay trong bản xem trước thay vì phải tìm cửa sổ chỉnh sửa lần nữa. Điều này cũng thuận tiện hơn rất nhiều cho người dùng di động, với màn hình nhỏ hơn của họ, nơi việc cuộn qua ngay cả một bài đăng ngắn cũng có thể có rất nhiều công việc.

Chuyển đổi giữa hai chế độ trình chỉnh sửa để có được ý tưởng gần đúng về những gì bài đăng của bạn có thể trông như thế nào không phải là bản xem trước trực tiếp những gì bạn đang viết. Nó làm chậm quá trình viết. Và nói rằng "bạn có thể chỉnh sửa ngay trong bản xem trước" không thực sự đúng: Nếu tôi đang làm việc trong trình chỉnh sửa RT, sử dụng nó làm cả trình chỉnh sửa và xem trước cùng một lúc, tôi không thể tiếp tục viết trong Markdown . Tôi phải chuyển lại, mất "bản xem trước" của tôi. Thành thật mà nói, điều này là ít hơn lý tưởng. Trong khi nó ít cuộn hơn, nó cũng không hoạt động . Và trình chỉnh sửa RT thực hiện một công việc tồi tệ hơn trong việc hiển thị một bài đăng sẽ trông như thế nào so với bản xem trước trực tiếp hiện tại.

Tôi thích ý tưởng về RT để viết trên thiết bị di động. Tôi hiếm khi sử dụng MD khi sử dụng điện thoại của mình, chỉ vì dấu hoa thị, dấu gạch nối và thẻ bắt đầu bằng # không phải là thứ chỉ cần một cú nhấp chuột khi nhìn vào bàn phím điện thoại của bạn. Nhưng ngay bây giờ, và hầu hết thời gian, tôi đang viết bài trên máy tính . Điều này có nghĩa là tôi có trên tay bàn phím và một màn hình đủ lớn để thực sự hiển thị cho tôi những gì tôi đang làm .

Toàn bộ bài đăng này ngay bây giờ dễ dàng phù hợp với màn hình của tôi. Và bản xem trước của nó được phát trực tiếp, và đó là thứ mà tôi trân trọng. Nó làm cho việc viết này dễ dàng hơn, nhanh hơn, tương tác hơn, trôi chảy hơn. Dù bạn làm gì, đối với những người viết bằng trình chỉnh sửa Markdown, đừng lấy đi bản xem trước trực tiếp của chúng tôi. Trình chỉnh sửa Văn bản đa dạng thức không phải là bản xem trước trực tiếp, chuyển đổi giữa hai luồng ngắt và bạn không thể viết Đánh dấu nếu trình chỉnh sửa của bạn đang ở chế độ Văn bản đa dạng thức trong khi xem kết quả vì bản xem trước trực tiếp cho phép ngay bây giờ.

58 Luuklag Jan 27 2021 at 04:43

tình trạng lỗi được lập kế hoạch

Đánh dấu này:

# one heading

## two heading

### three heading

#### four heading

##### five heading

###### six heading

hiển thị bản xem trước này trong trình chỉnh sửa đa dạng thức:

Nó được đăng như vậy:

51 Glorfindel Jan 27 2021 at 02:39

tình trạng lỗi được lập kế hoạch

Khi sử dụng dấu hoa thị cho chữ in nghiêng, nhưng không kết thúc nó, chẳng hạn như * này, bản xem trước hiển thị phần còn lại của dòng in nghiêng nhưng bài đăng được hiển thị thì không.

46 Tinkeringbell Jan 27 2021 at 16:03

yêu cầu tính năng

Sonic đã viết về việc thiếu chức năng xem trước. Tôi cũng vậy, nhưng tôi có một số lý do khác khiến tôi bỏ lỡ phần xem trước. Hai trong số đó là các vấn đề đã biết:

Mặc dù việc chuyển đổi giữa các chế độ vẫn duy trì vị trí cuộn gần đúng của bạn, nhưng nó không nhớ vị trí con trỏ của bạn. Bất kỳ lúc nào bạn chuyển đổi, con trỏ của bạn sẽ di chuyển trở lại đầu bài đăng thay vì giữ nguyên vị trí của bạn. [...] Vì bản xem trước văn bản có định dạng sẽ giải thích Markdown của bạn, mọi Dấu ấn (MD) không chính xác có thể bị trình chỉnh sửa văn bản đa dạng thức loại bỏ. Khi bạn quay lại chế độ xem MD, bạn sẽ có thể sửa các lỗi này.

Tôi đã sử dụng trình chỉnh sửa này một vài lần trên Teams và tôi không thực sự mong muốn bật nó ở đây, vì nó lưu tùy chọn được sử dụng gần đây nhất làm mặc định .

Quy trình làm việc thông thường của tôi diễn ra như sau:

  1. Bắt đầu viết một bài đăng trong Markdown.
  2. Nhìn vào bản xem trước để xem nó trông như thế nào.
  3. Lặp lại 1-2 vài lần.
  4. Cuối cùng, hãy xem kỹ bản xem trước trước khi đăng.

Mặc dù tôi nghĩ rằng tôi có thể quen với việc bật công tắc để xem bản xem trước (và không phải cuộn), thực tế là tùy chọn sử dụng cuối cùng của tôi được lưu lại là điều khiến trình chỉnh sửa mới này rất khó sử dụng.

Thông thường, 'bước 1' của tôi bao gồm một đoạn văn bản khá lớn trước khi tôi xem bản xem trước. Nhưng bước 4 của tôi có nghĩa là mỗi khi tôi đăng một cái gì đó, tôi nên a.) Quay lại chế độ Markdown trước hoặc b.) Trả trình chỉnh sửa về chế độ Markdown khi tôi bắt đầu viết bài tiếp theo. Và tôi không muốn chú ý đến sự chuyển đổi đó, tôi chỉ muốn bắt đầu viết. Có nghĩa là tôi thường chạy vào phần mà tôi viết Markdown trong trình chỉnh sửa văn bản đa dạng thức, sau đó phải chuyển và xóa tất cả các dấu gạch chéo hiện đang thoát khỏi Markdown:

Có bất cứ điều gì có thể được thực hiện, có lẽ là cài đặt hồ sơ, có nghĩa là tôi sẽ luôn bắt đầu viết ở chế độ Đánh dấu, điều này sẽ ghi đè cài đặt 'sử dụng lần cuối' và thậm chí có thể ghi đè mặc định của trang web cụ thể?

46 Rob Jan 27 2021 at 04:53

"Bản xem trước được thu gọn vào chế độ xem văn bản có định dạng"

Bản xem trước là một phần cần thiết của việc chỉnh sửa, đặc biệt là trên một số trang web, và đó là một sự thuận tiện tuyệt vời để có thể xem toàn bộ bài đăng và hiệu đính để dự phòng.

Việc bật trình chỉnh sửa mới trên Meta Stack Exchange sẽ phá vỡ trình chỉnh sửa trên các trang khác.

Lấy ví dụ câu hỏi này trên Physics.SE: " Toán tử đơn nhất tác động như thế nào lên vectơ này? ". Việc sao chép, dán văn bản ở đây cho thấy rằng nếu không có bản xem trước, việc đọc những gì bạn đã viết có thể khó khăn hơn:

Việc sao chép cùng một đoạn văn bản đó thành một câu trả lời trên trang Physics.SE cho thấy một vấn đề hiển thị, nếu không có bản xem trước, điều này lúc đầu sẽ không rõ ràng; dẫn đến rất nhiều chỉnh sửa bổ sung.

Xem ảnh chụp màn hình này (trình chỉnh sửa được bật trên Meta Stack Exchange):



Xem ảnh chụp màn hình này (trình chỉnh sửa bị tắt trên Meta Stack Exchange):

-

Lưu ý cách bật Trình chỉnh sửa văn bản có định dạng đã gây ra kết xuất sai trên một trang web khác nơi nó chưa được bật.

39 FranckDernoncourt Jan 27 2021 at 06:16

tính năng-yêu cầu trạng thái-xem xét

Tables - nút này sẽ tạo một bảng ba hàng, hai cột mặc định và có các tùy chọn menu đặc biệt khi ở chế độ văn bản đa dạng thức cho phép thêm / xóa hàng và cột.

Sẽ rất thú vị nếu có một số cách để chỉ định số hàng / cột khi tạo bảng (và không phải sau), ví dụ từ Google Document:

32 TimCampion Jan 30 2021 at 10:45

(Tôi xin lỗi vì định dạng không đồng đều trong bài đăng này - nó được viết trong trình chỉnh sửa alpha-testing. Tôi nhận thấy rằng ngay cả khi ở chế độ Markdown, các tính năng "đánh dấu cú pháp" quá mạnh - đến mức tôi thường xuyên bị không chắc liệu tôi đang ở chế độ Markdown hay chế độ rich text. Hơn nữa, cú pháp đánh dấu trong chế độ Markdown dường như không chính xác. Ví dụ: ở chế độ Markdown, hầu hết văn bản của bài đăng này hiện đang hiển thị ở dạng in đậm và nghiêng, trái với trường hợp ở chế độ văn bản có định dạng hoặc khi tôi xuất bản. Ví dụ khác, rõ ràng khi tôi viết ba dấu gạch ngang ban đầu bên dưới, ít nhất hai trong số chúng được viết ở chế độ văn bản có định dạng và được chuyển đổi thành dấu gạch ngang, do đó dòng phân cách bên dưới ban đầu đã không hiển thị đúng.)

Nhận xét của tôi về câu trả lời của EP đã quá nhiều, vì vậy hãy để tôi tiếp tục ở đây. Tôi hoàn toàn đồng ý với mọi thứ trong câu trả lời của EP. Giống như EP, tôi hiểu rằng không có ác ý đằng sau những thay đổi được đề xuất này và tôi hiểu rằng tất cả mọi người ở đây đều có thiện chí, nhưng giống như anh ấy, tôi cảm thấy rằng tình hình đòi hỏi tôi phải thẳng thắn. Trên hết, tôi đồng ý với luận điểm trọng tâm của EP rằng

Đây là điều cực kỳ đáng báo động từ góc độ MathJax.

Hơn nữa, như Rob đã chỉ ra , các vấn đề được nêu ở đây có thể sẽ mở rộng ra ngoài MathJax, đến nhiều plugin định dạng dành riêng cho trang web khác .

Về cơ bản, khi nghĩ về văn bản đa dạng thức,

Người dùng tập trung vào MathJax là một trường hợp sử dụng hoàn toàn khác với người dùng không tập trung vào MathJax.

Như đã thảo luận trong câu trả lời của EP và trong phần nhận xét của tôi ở đó, sẽ là một trò đùa khi đề xuất rằng người dùng lấy MathJax làm trung tâm soạn bài của họ ở chế độ văn bản đa dạng thức. Tuy nhiên, như dự đoán hiện tại, người dùng tập trung vào MathJax vẫn sẽ phụ thuộc vào chế độ văn bản có định dạng, sử dụng nó như một trình xem trước MathJax của một người nghèo . Nói cách khác, để kết hợp trường hợp sử dụng lấy MathJax làm trung tâm, trình soạn thảo văn bản đa dạng thức cũng sẽ được đánh dấu như một trình xem trước MathJax. Đây là một ý tưởng khủng khiếp bởi vì

Về cơ bản, MathJax không tương thích với biểu diễn văn bản đa dạng thức.

MathJax được thiết kế để viết trong một môi trường giống như Markdown và được biên dịch thành một đầu ra cuối cùng riêng biệt. Vì vậy, trình xem trước MathJax là một thứ hoàn toàn khác với trình soạn thảo văn bản đa dạng thức. Cố gắng tạo một trình soạn thảo văn bản đa dạng thức cũng là một trình xem trước MathJax chỉ gây rắc rối - đặc biệt là khi kinh doanh MathJax dù sao cũng là một suy nghĩ muộn màng. Như đã thảo luận trong phần nhận xét của tôi đối với câu trả lời của EP, nhiều người đã cố gắng làm điều này và không thành công. Nếu bạn cố gắng làm điều này, tôi dự đoán rằng cuối cùng bạn sẽ bỏ cuộc và ngừng hỗ trợ hoàn toàn MathJax, và sau đó chúng ta quay trở lại loại bạo loạn mà tôi đã nói trong phần bình luận của mình ở trên (ban đầu được viết dưới dạng nhầm lẫn hiểu rằng sẽ không có chế độ Markdown nào cả, nhưng sẽ có thể áp dụng như nhau trong trường hợp như thế này). Để rõ ràng:

Nếu MathJax không được hỗ trợ đầy đủ, rất có thể MathOverflow sẽ thực hiện tùy chọn theo hợp đồng để rời khỏi mạng Stack Exchange và các trang web như Math Stack Exchange cũng sẽ không hài lòng tương tự.

Giải pháp: Vì những lý do này, giải pháp duy nhất tôi thấy là:

Cần có một bản xem trước dành riêng cho chế độ Markdown mà không phụ thuộc vào trình chỉnh sửa văn bản đa dạng thức.

Bản xem trước chuyên dụng này cần hỗ trợ đầy đủ MathJax. Tương tự như vậy, nó cần phải hỗ trợ plugin sử dụng tại các địa điểm khác như cờ vua , đi , furigana và ký hiệu âm nhạc . Điểm chung của MathJax và các plugin này là sẽ không khả thi khi tạo một biểu diễn văn bản có dạng thức hỗ trợ đầy đủ chúng, đặc biệt nếu biểu diễn văn bản có dạng thức này cũng được cho là hoạt động như một bản xem trước của đầu ra đã xuất bản.

Đây là phần khởi động: các yêu cầu của loại bản xem trước cần thiết cho giải pháp này đã được đáp ứng và vượt quá so với bản xem trước trực tiếp hiện tại. Vì vậy, một bản xem trước như vậy là khả thi 100% và câu hỏi còn lại duy nhất là liệu Stack Exchange có sẵn sàng cam kết hỗ trợ các cộng đồng này bằng cách (lại) triển khai bản xem trước hay không.


Dưới đây là một số suy nghĩ thêm:

Như đã thảo luận ở đây , tôi đồng ý rằng bản xem trước trực tiếp tồn tại trong trình chỉnh sửa hiện tại, không phải văn bản đa dạng thức, về mặt nào đó là một bản nâng cấp so với nhiều trình chỉnh sửa LaTeX vì tính năng làm mới liên tục và tự động của nó. Tôi không cần làm mới quá thường xuyên hoặc tự động, nhưng đó là một điều tốt.

Nếu không có bản xem trước trực tiếp ở chế độ Markdown, tôi muốn có một số dạng xem trước mà tôi có thể xem bằng cách nhấn vào nút "biên dịch" giống như trong trình chỉnh sửa LaTeX tiêu chuẩn, mà không cần chuyển sang chế độ văn bản đa dạng thức, vì một số lý do:

  1. Trong các trình soạn thảo văn bản đa dạng thức mà tôi đã thấy có MathJax hoặc Latex, MathJax không hiển thị đầy đủ trước khi xuất bản (ví dụ: nó có thể không hiển thị macro do người dùng xác định). Có những lý do chính đáng cho điều này - MathJax / LaTeX không được thiết kế với sự hiểu biết rằng sẽ có sự tương ứng 1-1 giữa các ký tự bạn đang viết và các ký tự sẽ được xuất ra, vì vậy sẽ không khả thi khi tạo một thư như vậy cho các mục đích của một trình bày văn bản đa dạng thức.

  2. Vì lý do này và các lý do khác, tôi không tin tưởng rằng những gì tôi thấy trong phần trình bày văn bản đa dạng thức phản ánh đầy đủ những gì tôi sẽ thấy khi xuất bản. Điều này khiến bạn khó bắt lỗi trước khi xuất bản.

  3. Thật phức tạp khi chuyển đổi thường xuyên giữa các chế độ, điều mà tôi sẽ cần làm cho mục đích xem trước (tôi sẽ viết riêng ở chế độ Markdown, vì những lý do được thảo luận trong câu trả lời của EP và nhận xét của tôi ở đó, và xem trước ở chế độ văn bản đa dạng thức).

  4. Một lý do khiến nó cồng kềnh là tôi dự đoán sẽ có độ trễ thời gian khi chuyển đổi chế độ.

  5. Một lý do khác khiến nó cồng kềnh là tôi cũng dự đoán rằng sẽ có cảm giác như toàn bộ giao diện đang được làm lại khi chuyển đổi chế độ, đó là một hiệu ứng chói tai khi tất cả những gì tôi muốn là xem trước những gì tôi đã viết.

  6. Giao diện văn bản đa dạng thức có thể sẽ được thiết kế với giả định rằng người dùng đang soạn bài đăng của họ hoàn toàn ở chế độ văn bản đa dạng thức (và học cách sử dụng giao diện từ góc độ đó) nhưng vì tôi sẽ sử dụng chế độ văn bản đa dạng thức dành riêng cho việc xem trước, của tôi sẽ là một trường hợp sử dụng hoàn toàn khác với những gì dự định. Tôi dự đoán điều này sẽ dẫn đến trải nghiệm khó chịu cho người dùng lấy MathJax làm trung tâm khi sử dụng chế độ văn bản đa dạng thức dành riêng cho việc xem trước, cả khi học và sử dụng giao diện theo cách này.

  7. Để chuyển đổi giữa văn bản đa dạng thức và nội dung Markdown khi viết một bài đăng có độ dài bất kỳ, tôi phải cuộn lên để truy cập nút chuyển đổi. Điều này là phức tạp đối với trường hợp sử dụng dự kiến ​​của tôi, nơi tôi cần phải thường xuyên chuyển đổi giữa các chế độ, viết trong Markdown và xem trước ở chế độ văn bản đa dạng thức. Có điều, tôi đánh mất vị trí của mình trong những gì tôi đang viết và phải tìm lại nó sau khi chuyển đổi chế độ. Thật khó chịu gấp đôi vì khi tôi cuộn lên để chuyển đổi, tôi cần chắc chắn rằng mình đang thu hút cuộn trình duyệt chứ không phải cuộn biên tập.

30 RyanM Jan 28 2021 at 09:50

tính năng-yêu cầu trạng thái được lập kế hoạch

Tôi hết lòng ủng hộ các yêu cầu, dưới một số hình thức, cho phép đồng thời xem Markdown và bản xem trước . Nếu có thể, tôi muốn điều đó được thực hiện theo cách nào đó thay vì cách này. Tuy nhiên, nếu điều đó không thể được thực hiện ...

Chuyển đổi giữa Markdown và văn bản có định dạng để xem trước kết quả mà không cần chỉnh sửa bất cứ thứ gì không phải là một hành động phá hoại

Như một trong những CM đã lưu ý :

Tôi thực sự không xem trước các bài đăng của mình trên Teams vì tôi không thể chấp nhận rủi ro của RT mucking với MD của mình

Nếu người dùng chỉ chuyển đổi giữa Markdown và văn bản đa dạng thức (ví dụ: để xem bản xem trước) mà không thực hiện bất kỳ thay đổi nào, thì việc chuyển đổi trở lại sẽ ghi nhớ và khôi phục lại chính xác trạng thái trước đó. Có thể hiểu rằng không thể có sự tương ứng 1: 1 giữa hai và việc chỉnh sửa nội dung nào đó trong chế độ xem văn bản đa dạng thức có thể dẫn đến Markdown khác nhau khi quay lại.

Tuy nhiên, có thể trường hợp đặc biệt "không thay đổi bất cứ điều gì" và đưa người dùng trở lại trạng thái trước đó khi trở lại, cho phép trình chỉnh sửa văn bản có định dạng đóng vai trò như một bản xem trước của Markdown.

29 FranckDernoncourt Jan 27 2021 at 12:16

xem xét tình trạng lỗi

Việc trích dẫn một văn bản nhiều đoạn văn sẽ làm rối loạn việc phân đoạn đoạn văn.

Ví dụ

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au

Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.

trở thành

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au> u> Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.t.

28 Glorfindel Jan 27 2021 at 02:35

xem xét tình trạng lỗi

  1. Bắt đầu ở chế độ Markdown
  2. Viết bất kỳ văn bản nào
  3. Nhấn nút Enter

Tôi mong đợi trình chỉnh sửa đưa con trỏ của tôi đến dòng tiếp theo, nhưng nó không. Tôi cần nhấn Enter một lần nữa để con trỏ di chuyển, nhưng khi tôi bắt đầu nhập lại các từ, chúng xuất hiện trên dòng thứ ba . Nói cách khác, Enternút hoạt động, nó chỉ là con trỏ bị trễ.

Có thể sao chép trong Firefox 86, nhưng không sao chép trong Chrome 88.

21 Glorfindel Jan 27 2021 at 02:47

xem xét tình trạng lỗi

Nếu bạn bắt đầu viết ở chế độ Văn bản đa dạng thức và nhấp vào nút 'Quy tắc ngang', quy tắc này sẽ tự động được chọn và bạn không thể bỏ chọn nó, thậm chí không phải bằng cách nhấp vào bên ngoài hộp trả lời. Do đó, ngay sau khi bạn bắt đầu nhập, quy tắc ngang sẽ biến mất.

21 RyanM Jan 27 2021 at 10:52

bọ cánh cứng

Trình chỉnh sửa văn bản đa dạng thức không thoát khỏi HTML, nhưng hiển thị nó trong bản xem trước như thể nó đã được thoát.

Ví dụ: nếu tôi tạo một bài đăng với những nội dung sau:

Để tạo liên kết, hãy sử dụng văn bản <a href=[https://stackoverflow.com[> tại đây </a>

Đó là <cái này và> cái kia

Nó sẽ hiển thị là:

Để tạo liên kết, hãy sử dụng văn bản tại đây

Chính là nó

Tệ hơn nữa, việc chuyển đổi qua lại sẽ làm hỏng nó. Lưu ý rằng nó bắt đầu với các thực thể HTML thoát, sau đó chuyển đến HTML không thoát, sau đó loại bỏ các phần của HTML (không hợp lệ do dấu ngoặc kép thông minh). Nó cũng phá vỡ định dạng trích dẫn.

(Tôi không thể tạo bài đăng này trong trình chỉnh sửa mới do những lỗi này)

18 FranckDernoncourt Jan 27 2021 at 11:51

tính năng-yêu cầu hình ảnh được lập kế hoạch trạng thái

Làm cho hình ảnh được chèn có thể nhấp được (giống như trong trình chỉnh sửa cũ).

Trình chỉnh sửa mới sử dụng ![](https://i.stack.imgur.com/HvbcS.png), trình chỉnh sửa cũ sử dụng:

[![enter image description here][1]][1]

  [1]: https://i.stack.imgur.com/HvbcS.png

Làm cho hình ảnh được chèn vào có thể nhấp được rất hữu ích cho hình ảnh lớn.

18 41686d6564 Jan 27 2021 at 16:33

xem xét tình trạng lỗi

Nhấp ba lần sẽ chọn toàn bộ văn bản trong chế độ Đánh dấu

Thực hành tiêu chuẩn trong các trường văn bản hiện đại là nhấp đúp để chọn một từ đơn và nhấp ba lần để chọn một đoạn văn . Điều này đã hoạt động trong trình chỉnh sửa cũ, hoạt động trong trình chỉnh sửa Văn bản đa dạng thức, nhưng không hoạt động ở chế độ Markdown và thay vào đó, toàn bộ văn bản sẽ được chọn.

17 Glorfindel Jan 27 2021 at 03:10

tình trạng lỗi được lập kế hoạch

Trong chế độ Markdown, tô sáng cú pháp không biết về * dấu hoa thị thoát * - nó sẽ vẫn hiển thị các từ ở giữa (bao gồm cả dấu gạch chéo ngược ở cuối) ở dạng nghiêng.

17 Luuklag Jan 28 2021 at 15:46

tính năng-yêu cầu trạng thái-xem xét

Chúng ta có thể có một biểu tượng giống với một cái bàn hơn, sau đó là một chiếc máy tính không?

Đối với tôi, trường lớn ở trên cùng làm tôi liên tưởng đến màn hình máy tính, với các nút bên dưới nó. Tôi không nhớ đã từng sử dụng các bảng mà tôi đã hợp nhất các cột trong hàng tiêu đề.

17 Tinkeringbell Feb 02 2021 at 00:46

lỗi yêu cầu tính năng

Các công cụ hình ảnh và liên kết bây giờ sẽ thêm hình ảnh và liên kết nội dòng thay vì ở định dạng thư mục. Trong khi cái sau vẫn hoạt động, bạn sẽ phải tạo nó theo cách thủ công.

Trước hết: Điều này chưa hoàn toàn hoạt động.

Nếu bạn định cho phép thêm định dạng tiểu sử theo cách thủ công, vui lòng không để việc chuyển đổi chế độ trình chỉnh sửa gây rối với nó (trừ khi chúng tôi đang có một cách khác để xem bản xem trước so với trình chỉnh sửa Văn bản đa dạng thức: D)


Thứ hai, việc mặc định cho các liên kết nội tuyến và hình ảnh trong Markdown phá vỡ quy trình làm việc của tôi. Tôi đã sử dụng nút 'liên kết' rất nhiều trên các bài đăng dài hơn với nhiều liên kết đến các bài báo nghiên cứu, vì nó sẽ bắt đầu một thư mục. Định dạng thư mục giúp cung cấp ghi nhận tác giả dễ dàng hơn, đặc biệt nếu tôi đang sử dụng lại / trích dẫn các bài đăng hoặc bài viết giống nhau nhiều lần trong cùng một bài đăng. Tôi có thể chỉ cần gõ [text][number of link to reuse]và hoàn thành với nó. Mặc dù cú pháp cho các liên kết nội tuyến rất dễ nhớ, nhưng nó không cho phép sử dụng lại kiểu này.

Một lợi ích lớn từ các định dạng thư mục trong trình soạn thảo 'cũ', là nó cho biết thêm những hình ảnh như thế này: [![enter image description here][1]][1]. Nó giúp việc liên kết hình ảnh của bạn với một trang web khác dễ dàng hơn nhiều, như câu hỏi thường gặp này giải thích. Chỉ cần thay đổi số thứ hai và đặt một mục nhập khác vào danh sách thư mục ở cuối bài đăng. Trình chỉnh sửa hiện tại chèn hình ảnh bằng cách sử dụng ![enter image description here](https://i.stack.imgur.com/RRHYf.jpg)định dạng, điều này sẽ nhanh chóng lộn xộn nếu bạn muốn chèn thêm một siêu liên kết ... bạn phải ghi nhớ cách thực hiện điều đó nhiều hơn.

Và, trong các bài đăng dài với nhiều liên kết, việc có chúng ở cuối bài làm cho công việc của các biên tập viên tiềm năng tốt hơn một chút, đặc biệt nếu các liên kết được sử dụng dài.

Tôi không chắc tại sao lại đưa ra quyết định này, nhưng theo tôi thì nó làm cho các bài viết trở nên lộn xộn hơn, không gọn gàng hơn. Tôi không thấy nhiều câu hỏi hỗ trợ về meta từ những người đang gặp khó khăn với định dạng thư mục, vì vậy tôi không nghĩ đó là về 'tính dễ sử dụng'. Và mặc dù trình chỉnh sửa Rich Text có sẵn cho những người gặp khó khăn một chút với việc viết Markdown, nhưng trình soạn thảo đó không quan tâm đến cách các liên kết được viết trong Markdown, vì vậy những người đó sẽ không bao giờ phải biết.

Vì vậy, tôi muốn yêu cầu bạn xem xét lại việc mặc định cho các liên kết nội tuyến, cho cả liên kết và hình ảnh.

16 Dan Jan 28 2021 at 01:27

tính năng-yêu cầu trạng thái được lập kế hoạch

Thêm khả năng dễ dàng thay đổi ngôn ngữ của khối mã.

Điều này đã được đề cập trong một câu trả lời khác mà tôi tin rằng, nhưng tôi muốn thêm một số UX giả để có ý tưởng về cách nó có thể hoạt động và trông như thế nào.

Tôi vừa thêm một mũi tên bên cạnh ngôn ngữ để làm cho nó trông giống như một bộ chọn.

Khi nhấp vào ngôn ngữ, một hộp thoại sẽ xuất hiện với lựa chọn có thể. Ví dụ, một danh sách tương tự như sau.

✓ auto
-------
c#
css
html
javascript
plaintext
python

Một ý tưởng khác là hiển thị một đoạn hội thoại tương tự như đoạn hội thoại chi tiết của hình ảnh. Mặc dù điều này có thể gây phiền nhiễu và sẽ thích tùy chọn ở trên hơn.

14 Ollie Jan 27 2021 at 03:25

tình trạng lỗi được lập kế hoạch

Ở chế độ Đa dạng, những kẻ phá hoại không có dòng chữ "Tiết lộ Spoiler":

14 Luuklag Jan 27 2021 at 03:17

xem xét tình trạng lỗi

  1. Nhập một số văn bản

  2. Dán cái gì đó

  3. Nhấn Ctrl/Cmd+z

  4. Xem văn bản đã nhập của bạn đang được hoàn tác chứ không phải "văn bản rõ" đã dán của bạn

14 41686d6564 Jan 27 2021 at 15:51

lỗi / tính năng-yêu cầu trạng thái-xem xét

Tôi không chắc liệu điều này có phân loại là lỗi hay không nhưng đó là thứ luôn hoạt động và không hoạt động với trình chỉnh sửa mới.

Vì vậy, tôi đang sử dụng tiện ích Chrome kiểm tra chính tả / ngữ pháp hoạt động với hầu hết các trường văn bản. Nó hoạt động với trình chỉnh sửa cũ, với trình chỉnh sửa Rich Text mới nhưng vì một số lý do, nó không hoạt động khi chuyển sang đánh dấu:

Bây giờ, đó là một điều đáng tiếc vì tiện ích mở rộng này đã thực sự hữu ích trong việc viết (và đặc biệt là chỉnh sửa) các bài đăng, mà phần lớn nó sẽ được thực hiện ở chế độ Markdown.

Có thể khắc phục sự cố này không hay tôi nên đợi cho đến khi trình chỉnh sửa mới hoạt động và sau đó đưa “báo cáo lỗi” này đến Grammarly?

Cập nhật:

Kiểm tra phần tử trong các công cụ dành cho nhà phát triển của Chrome cho thấy rằng văn bản đánh dấu được bao bọc trong một <code>thẻ và đó có thể là nguyên nhân:

<pre class="s-code-block markdown">
    <code>test</code>
</pre>
13 Ollie Jan 27 2021 at 02:38

tính năng-yêu cầu trạng thái-xem xét

Trong trình chỉnh sửa cũ, nhấn CtrlLđưa ra điều này:

Trong khi nhấn điều đó trong trình chỉnh sửa mới sẽ hiển thị [text](https://www.stackoverflow.com/). Tôi muốn có cửa sổ bật lên này trong trình chỉnh sửa mới khi tôi nhấn phím tắt, vì tôi có thể chỉ cần dán liên kết của mình vào đó và chỉnh sửa mô tả liên kết, không phải liên kết mô tả.

13 Luuklag Jan 27 2021 at 03:46

xem xét tình trạng lỗi

Nếu tôi muốn thêm một số nút bàn phím ưa thích bằng cách sử dụng <kbd>X</kbd>

X

Chúng hiển thị hoàn hảo ở định dạng phong phú, nhưng khi đặt con trỏ của bạn đằng sau dấu X sẽ khiến bạn nhập vào bên trong phần tử kbd. Không có cách nào để gõ bất cứ thứ gì trên cùng một dòng. Thậm chí không buộc con trỏ của bạn xuất hiện ở đó bằng cách nhấp đúp (như sẽ hoạt động trong MS Word).

Các bước sao chép:

  • Bắt đầu ở chế độ đánh dấu

  • Thêm văn bản sau:

    <kbd>X</kbd>
    
  • Chuyển sang chế độ văn bản đa dạng thức

  • Đặt con trỏ bên trong phần tử kbd cho phép bạn chỉnh sửa nó, nhưng con trỏ của bạn bị kẹt và không thể rời khỏi phần tử

13 41686d6564 Jan 27 2021 at 06:20

tình trạng lỗi đã hoàn thành

Việc hủy bản nháp sẽ không xóa trình chỉnh sửa ở cả hai chế độ

  1. Bắt đầu nhập câu trả lời.

  2. Chờ cho đến khi bản nháp được lưu và Discardnút xuất hiện.

  3. Bấm vào Discard.

  4. Nó cho biết "Bản nháp đã bị loại bỏ" như thường lệ nhưng văn bản vẫn nằm trong trình chỉnh sửa.

  5. Khi cố gắng rời khỏi trang, một thông báo cảnh báo về việc “mất các thay đổi” sẽ hiển thị.

12 Luuklag Jan 27 2021 at 03:22

lập kế hoạch

Dán liên kết mạng không tự động biến nó thành liên kết trong bản xem trước khi ở chế độ đa dạng thức:

Chuyển đổi Bật và Tắt Markdown một lần nữa sẽ làm cho liên kết trông được định dạng đúng:

Dán liên kết ở chế độ đa dạng thức:

Liên kết khi chuyển sang chế độ Markdown:

Liên kết khi được chuyển trở lại trình chỉnh sửa đa dạng thức từ chế độ Markdown:

12 Dan Jan 27 2021 at 23:08

xem xét tình trạng lỗi

Trong khi thêm câu trả lời, nếu tôi sao chép văn bản ở chế độ đánh dấu và dán vào chế độ soạn thảo văn bản đa dạng thức, văn bản sẽ được dán dưới dạng khối mã. Tôi muốn văn bản được sao chép vào khay nhớ tạm mà không được định dạng khi ở chế độ đánh dấu.

Tôi đang sử dụng Firefox, nhưng không chắc liệu điều này có thể tái tạo được ở những nơi khác hay không.


Ctrl/ Cmd+ Clựa chọn sau

Ctrl/ Cmd+ Vtrong chế độ soạn thảo văn bản đa dạng thức

© Copyright 2021 - 2022 | vngogo.com | All Rights Reserved