<code> vs <pre> vs <samp> per frammenti di codice inline e block

335

Il mio sito avrà del codice foo()incorporato ("quando si utilizza la funzione ...") e alcuni frammenti di blocco. Questi tendono ad essere XML e hanno linee molto lunghe che preferisco avvolgere con il browser (cioè, non voglio usare <pre>). Vorrei anche inserire la formattazione CSS negli snippet di blocco.

Sembra che non sia possibile utilizzarli <code>per entrambi, perché se inserisco gli attributi di blocco CSS (con display: block;), si romperanno gli snippet incorporati.

Sono curioso di sapere cosa fanno le persone. Utilizzare <code>per i blocchi e <samp>per in linea? Usa <code><blockquote>o qualcosa di simile?

Vorrei mantenere l'HTML attuale il più semplice possibile, evitando le lezioni, poiché gli altri utenti lo manterranno.

html  semantic-markup 
— Steve Bennett
fonte
3
Usa Google Chrome e controlla il blog di Rick Strahl: weblog.west-wind.com/posts/2016/May/23/…, quindi usa i suoi attributi di foglio di stile. I suoi frammenti di codice sono molto chiari e facili da copiare / leggere.
— JoshYates1980,
1
<pre>e il suo comportamento può essere tenuto presente come la parola " precisamente"
— snr

Risposte:

351

Utilizzare <code>per il codice incorporato che può essere incluso e <pre><code>per il codice blocco che non deve essere incluso. <samp>è per l' output di esempio , quindi eviterei di usarlo per rappresentare il codice di esempio (che deve essere inserito dal lettore ). Questo è ciò che fa Stack Overflow.

(Meglio ancora, se vuoi che sia facile da mantenere, lascia che gli utenti modifichino gli articoli come Markdown, quindi non devono ricordarsi di usarli <pre><code>.)

HTML5 è d'accordo con questo in "l' preelemento" :

Il pre-elemento rappresenta un blocco di testo preformattato, in cui la struttura è rappresentata da convenzioni tipografiche anziché da elementi.

Alcuni esempi di casi in cui è possibile utilizzare l'elemento pre:

  • Compresi frammenti di codice informatico, con struttura indicata secondo le convenzioni di quella lingua.

[...]

Per rappresentare un blocco di codice del computer, l'elemento pre può essere utilizzato con un elemento di codice; per rappresentare un blocco di output del computer l'elemento pre può essere utilizzato con un elemento samp. Allo stesso modo, l'elemento kbd può essere usato all'interno di un elemento pre per indicare il testo che l'utente deve inserire.

Nel frammento seguente viene presentato un esempio di codice computer.

<p>This is the <code>Panel</code> constructor:</p>
<pre><code>function Panel(element, canClose, closeHandler) {
  this.element = element;
  this.canClose = canClose;
  this.closeHandler = function () { if (closeHandler) closeHandler() };
}</code></pre>
— Josh Lee
fonte
8
Questo potrebbe essere il modo corretto di procedere, ma penso ancora che sia stupido. Gli sviluppatori HTML hanno previsto la necessità di un <code>tag, ma hanno deciso di scrivere solo una riga? O immagino, perché non volevano avere due tag, un blocco e uno in linea? Ancora ... cosa c'è che non va nel creare <code>un livello a blocchi con i CSS? Pensavo che dovessimo scrivere HTML "semantico". <code>è buono e semantico, ma <pre>non così tanto.
— Aprire il
11
Non sono d'accordo. L'opposto del testo preformattato è semplicemente il vecchio testo nel documento. Rendere <code>a livello di blocco con CSS non è strano. In questo modo è consigliato in HTML5 .
— Josh Lee
1
Il problema <pre>è che modifica anche l'elaborazione degli spazi bianchi: tutti gli spazi vengono conservati e il wrapping viene disattivato. A meno che non ci sia un modo per spegnerlo?
— Steve Bennett,
3
@Steve Bennett, in CSS white-space: normal;Anche se non riesco a capire perché lo faresti per il codice. Anche questa <pre><code>cosa è stupida, il <pre>tag è definito molto chiaramente negli standard come "codice del computer" (e altre cose) come menzionato da @jleedev. È perché pensi che <code>sia un nome migliore? scusa che non lo rende più semantico. C'è un caso simile con il tag <address>, non suona davvero come "autore", ma lo standard dice che è quello che serve, quindi lo è.
— srcspider,
6
-1. La domanda centrale del PO era su come realizzare i frammenti di blocchi che avvolgono. Hai affrontato il codice inline e il codice a blocchi che non devono essere racchiusi, ma questo non risponde alla domanda principale del PO.
— Asad Saeeduddin,
80

Qualcosa che mi mancava completamente: il comportamento non avvolgente di <pre>può essere controllato con CSS. Quindi questo dà il risultato esatto che stavo cercando:

code { 
    background: hsl(220, 80%, 90%); 
}

pre {
    white-space: pre-wrap;
    background: hsl(30,80%,90%);
}
Here's an example demonstrating the <code>&lt;code&gt;</code> tag.

<pre>
Here's a very long pre-formatted formatted using the &lt;pre&gt; tag. Notice how it wraps?  It goes on and on and on and on and on and on and on and on and on and on...
</pre>
Espandi frammento

http://jsfiddle.net/9mCN7/

— Steve Bennett
fonte
41

Personalmente lo userei <code>perché è il più semanticamente corretto. Quindi per distinguere tra inline e block code aggiungerei una classe:

<code class="inlinecode"></code>

per codice inline o:

<code class="codeblock"></code>

per blocco di codice. A seconda di quale è meno comune.

— slebetman
fonte
sì, sto iniziando a pensarlo anche io. Ho chiesto una soluzione senza lezioni, ma sembra che non ce ne sia una buona.
— Steve Bennett,
3
@Steve: la cosa principale è definire un <code>blocco predefinito senza una classe per il caso d'uso più comune. Quindi chiunque voglia fare la cosa insolita deve solo aggiungere la classe. Farlo in altro modo chiederà comunque all'utente di digitare extra. In questo modo l'utente può pensarlo come aggiungere un tag speciale anziché utilizzare una struttura completamente diversa.
— Slebetman,
17

Per <code>uso normale in linea :

<code>...</code>

e per ogni luogo in cui <code>è necessario l'uso bloccato

<code style="display:block; white-space:pre-wrap">...</code>

In alternativa, definire un <codenza>tag per il blocco del rivestimento interrotto <code> (nessuna classe)

<script>
</script>
<style>
  codenza, code {}     /*  noop mnemonic aide that codenza mimes code tag  */
  codenza {display:block;white-space:pre-wrap}
</style>`

Test: (NB: il seguente è uno scURIple che utilizza un data:protocollo / schema URI, quindi i %0Acodici di formato nl sono essenziali per preservarli quando tagliati e incollati nella barra degli URL per i test - quindi view-source:( ctrl- U) sembra buono precedere ogni riga sotto con %0A)

data:text/html;charset=utf-8,<html >
<script>document.write(window.navigator.userAgent)</script>
<script></script>
<style>
  codenza, code {}     /*  noop mnemonic aide that codenza mimes code tag  */
  codenza {display:block;white-space:pre-wrap}
</style>
<p>First using the usual &lt;code> tag
<code>
  %0A     function x(arghhh){ 
  %0A          return "a very long line of text that will extend the code beyond the boundaries of the margins, guaranteed for the most part, well maybe without you as a warrantee (except in abnormally conditioned perverse environs in which case a warranty is useless)"
  %0A     }
</code>
and then 
<p>with the tag blocked using pre-wrapped lines
<code style=display:block;white-space:pre-wrap> 
  %0A     function x(arghhh){ 
  %0A          return "a very long line of text that will extend the code beyond the boundaries of the margins, guaranteed for the most part, well maybe without you as a warrantee (except in abnormally conditioned perverse environs in which case a warranty is useless)"
  %0A     }
</code>
<br>using an ersatz tag
<codenza>
  %0A     function x(arghhh){ 
  %0A          return "a very long line of text that will extend the code beyond the boundaries of the margins, guaranteed for the most part, well maybe without you as a warrantee (except in abnormally conditioned perverse environs in which case a warranty is useless)"
 %0A     }
</codenza>
</html>
— ekim
fonte
14

Mostra il codice HTML, così com'è , usando il <xmp>tag (obsoleto) :

<xmp>
<div>
  <input placeholder='write something' value='test'>
</div>
</xmp>
Espandi frammento

È molto triste che questo tag sia stato deprecato, ma funziona ancora sui browser, è un tag cattivo. non c'è bisogno di sfuggire a nulla al suo interno. Che gioia!

Mostra il codice HTML, così com'è , utilizzando il <textarea>tag:

<textarea readonly rows="4" style="background:none; border:none; resize:none; outline:none; width:100%;">
<div>
  <input placeholder='write something' value='test'>
</div>
</textarea>
Espandi frammento

— vsync
fonte
Mi manca sicuramente qualcosa, ma a quanto pare, questo è l'unico modo che ho trovato per mostrare il codice HTML non
— elaborato
@sphakka (& vsync), Vedi la mia risposta qui che suggerisce l'uso di ciò <textarea readonly>che fa lo stesso, è attuale e ha molto più controllo se lo desideri.
— www-0av-Com,
@ user1863152 - è un pessimo uso di un IMHO textarea poiché il codice non può essere evidenziato da script esterni, come ad esempio Prism . e inoltre, non si adatta all'altezza e alla larghezza del contenuto, come <xmp>fa, o qualsiasi altro blockelemento. Non lo consiglierei come una soluzione reale, solo come teorica.
— vsync,
@vsync, sì, sono i cavalli per i corsi (e ti ho dato un voto a proposito). Uso textarea per le mie esigenze. Ho provato xmp e non ricordo perché ho trovato xmp insoddisfacente per le mie esigenze. Naturalmente il suo stato deprecato certamente scoraggia. Uso PRE quando devo evidenziare e CODE per l'uso in linea. Non riesco a immaginare come Prism si evidenzi all'interno di un XMP - alcuni maghi CSS?
— www-0av-Com,
Non ne sono troppo sicuro. Sì, funziona, ma è obsoleto dal 3.2 e rimosso completamente in 5? Anche se non molti tag sono stati completamente rimossi dai browser, ne <blink>è un esempio, sarei ansioso di usarlo per tutto ciò che deve essere a prova di futuro.
— spacer GIF
9

Considera TextArea

Le persone che lo trovano tramite Google e cercano un modo migliore per gestire la visualizzazione dei loro frammenti dovrebbero anche considerare <textarea>che dà molto controllo su larghezza / altezza, scorrimento ecc. Notando che @vsync ha menzionato il tag deprecato <xmp>, trovo che <textarea readonly>sia un ottimo sostituto per visualizzare HTML senza la necessità di sfuggire a qualsiasi cosa al suo interno (tranne dove </textarea>potrebbe apparire all'interno).

Ad esempio, per visualizzare una singola riga con il ritorno a <textarea rows=1 cols=100 readonly> capo controllato, considera il tuo html o ecc. Con qualsiasi carattere tra cui tab e CrLf</textarea> .

<textarea rows=5 cols=100 readonly>Example text with Newlines,
tabs & space,
  html tags etc <b>displayed</b>.
    However, note that &amp; still acts as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;
</textarea>
Espandi frammento

Per confrontare tutto ...

<h2>Compared: TEXTAREA, XMP, PRE, SAMP, CODE</h2>
<p>Note that CSS can be used to override default fixed space fonts in each or all these.</p>
    
    
<textarea rows=5 cols=100 readonly>TEXTAREA: Example text with Newlines,
tabs & space,
  html tags etc <b>displayed natively</b>.
    However, note that &amp; still acts as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;</textarea>

<xmp>XMP: Example text with Newlines,
tabs & space,
  html tags etc <b>displayed natively</b>.
    However, note that &amp; (&) will not act as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;
</xmp>

<pre>PRE: Example text with Newlines,
tabs & space,
  html tags etc <b>are interpreted, not displayed</b>.
    However, note that &amp; still acts as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;
</pre>

<samp>SAMP: Example text with Newlines,
tabs & space,
  html tags etc <b>are interpreted, not displayed</b>.
    However, note that &amp; still acts as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;
</samp>

<code>CODE: Example text with Newlines,
tabs & space,
  html tags etc <b>are interpreted, not displayed</b>.
    However, note that &amp; still acts as an escape char..
      Eg: &lt;u&gt;(text)&lt;/u&gt;
</code>
Espandi frammento

— www-0av-Com
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.