¿Debería markdown preservar nuevas líneas en blockquotes?

Question

Actualmente estoy trabajando en un reclamo de usuario, y no puedo determinar si el reclamo es un error real o no. Básicamente, el usuario dice que hay un problema con el sitio web porque las blockquotes no conservan sus nuevas líneas. Esto suena razonable, pero en cada comprobador de rebajas que he probado en línea, las comparaciones en bloque se representan igual que las mías. Por ejemplo:

hola ¿qué pasa? este es mi blockquote multilínea.

Aunque escribo esto como una comilla de líneas múltiples, las líneas nuevas todavía se pierden en la representación (incluso en StackOverflow). Así que supongo que mi verdadera pregunta es doble:

1. Estoy 99% seguro de que por este punto que blockquotes no deben preservar los saltos de línea, pero todavía me gustaría ver si hay diversidad de opiniones por si acaso . ¿Alguno de ustedes piensa que deberían preservarlos?

2. Si no deberían conservarlos, ¿es la forma correcta de conservar sus líneas nuevas en el descuento simplemente utilizando pre y el código?

Answer 1

Las "especificaciones" de rebajas originales son muy ambiguas y no se mantienen. Existe, por supuesto, el script perl markdown.pl, la "implementación de referencia", aunque tiene muchas rarezas familiares.

Puede unirse a la lista http://six.pairlist.net/pipermail/markdown-discuss/ que siempre se queja de la situación contradictoria en la que se encuentra el asunto debido a la corrupción de Gruber. Quizás los usuarios de la lista tengan la sensatez de tomar el asunto en sus propias manos, aunque las diferencias sutiles entre la implementación diferente y las diferencias no tan sutiles entre las diferentes extensiones hacen que esto sea poco probable o difícil. -Especialmente mientras Gruber no renuncie a todos los derechos en la materia, pero al mismo tiempo no avance ninguna especificación. Si se forma un comité, no podrá hablar de ninguna especificación como una especificación de Markdown.

En principio, está claro que las comillas en bloque se rigen por los mismos principios que las comillas sin bloque, por ejemplo, puede tener comillas en bloque en las comillas, por lo que su amigo está ciertamente equivocado. Puede probar esto a su usuario ejecutando markdown.pl en su texto. Cualquier otro principio sería confusión total. Tenga en cuenta esto,

la regla para hacer un salto de línea
con espacios adicionales al final de la línea

es totalmente clara
ya sea dentro

o fuera
comillas en bloque, por lo que podría explicárselo.

Tenga en cuenta que el analizador stackoverflow de reducción del precio es bueno aquí (me di cuenta de algo malo en la forma de salir de una cita bloque anidado para volver a la cita de bloque principal, sin embargo.) Sin embargo, el autor de la CSS hizo equivocadamente la espacio entre una cita de bloque y el texto circundante mayor que el que existe entre los párrafos. Esto no tiene sentido cuando los espacios de párrafo se comunican por espacio extra.Una cotización de bloque es parte del párrafo, de hecho típicamente de una oración. . Es similar a una sola palabra muy larga, como cualquier otra cita utiliza por escrito)

Tenga en cuenta que lo que está en la jerga lindo, empalagosa que se hace llamar "GitHub ™ rebaja sabor" trata todos saltos de línea - código fuera bloques, etc., a medida que el párrafo se rompe, una decisión que básicamente hace que la idea del descuento no exista. Puede ser que su usuario esté familiarizado con algo de eso, aunque al menos no rompa la regla de que lo que se mantiene en la cita del bloque es lo que se mantiene fuera de él. GitHub Inc. ha ... eh ... 'convencido' a Gruber de que este es un descuento legítimo 'para su caso de uso'. El fundamento para esto fue que las personas no instruidas podrían pensar naturalmente que una nueva línea hace que se rompa un párrafo. Gruber era presumiblemente consciente de que la base de usuarios de GitHub ™ está constituida por los programadores , por lo que muestra cuánto vale para él la idea de una especificación o estándar. Por supuesto, ha producido un caos total para la documentación compleja en GitHub. (¿Por qué no debería haber un "html legítimo para el caso de uso de Internet Explorer", mucha gente simplemente prueba cosas en IE, por lo que tienen ciertas expectativas legítimas? Por supuesto, la decisión de GitHub es mucho peor de lo que sería.)

No he pensado en esto por un tiempo, por lo que estas observaciones podrían no estar actualizadas, pero dudo que las cosas hayan cambiado desde que decidí no pensar en ello. Que exista y no haya ninguna especificación muestra que cada minuto que dedicas a pensar sobre el asunto es energía humana desperdiciada. Markdown ha engendrado bastante de eso ahora, gracias a la extrañeza de Gruber.