-
Notifications
You must be signed in to change notification settings - Fork 22.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Markdown] Decide how to represent code blocks #3512
Comments
Disagree regarding highlighting as I posted here: mdn/yari#2757 The highlighting was broken in the recent move to github backend. The highlighting exists for a reason and we should put it back, or we need to go through and find some other way to update all those docs that are now broken. Personally I would like the ability to specify lines and line ranges to highlight, but I'd also be happy with a way to add styling within the code block - e.g. to make some sections bold even if that is not the styling added by the renderer. It is a very useful feature. I have never seen a real use for line numbers except in conjunction with highlighting when you have multiple lines and want to talk about them separately. Could live with out them. Agree on the rest. |
Looks mostly good @wbamberg . Some comments on the points you highlight:
|
Yeah, I agree with all these points.
I think it's not so much, should we have these classes, as: (1) should we have line numbers in examples (in general, by default), and (2) if so, should we suppress them in cases like syntax blocks (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice#syntax)? If the answers are Yes and Yes, then we need some mechanism to control this. (FWIW I think we should not have line numbers in examples, which would mean we don't need this mechanism).
Could you point me at an example of this? I'm having trouble picturing it. |
I agree with you on this. We don't currently make any use of line numbers, and I don't see why we should start.
Here's one:
|
Thanks! So in this case it looks like we want to hide all the source, and only show the output. That seems like a more natural fit for EmbedGHLiveSample - since we have this example as a GitHub page already, is there a reason we couldn't do:
That seems to work, and has the advantage that we're not duplicating the code in the page and in GitHub. ? I'm seeing a similar pattern in https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grids. |
I agree with you @chrisdavidmills that highlighting is a pain for the author, but IMO it can be better for the reader, even in quite small blocks of code. On the other hand, the closer our markdown matches github flavour markdown the better. Either way though, we still need to fix the cases where it was used and the documentation says something like "see the highlighting". I know it exists, because I injected some when i wrote the Django stuff. |
I have to say I agree with you @wbamberg . So we have a plan for this case too! |
Yea, when the time comes to migrate it over, we'll just need to go through the list of highlighting instances, and update them. |
I'm closing this, since there's a resolution in https://developer.mozilla.org/en-US/docs/MDN/Contribute/Markdown_in_MDN#example_code_blocks. |
This issue is to decide how we will represent, in Markdown, blocks containing example code. I think it should be pretty obvious in general but it's worth going through the details, and you never know.
Currently we use
<pre>
blocks of course, with classes for syntax highlighting:In Markdown we can use fenced code blocks for this. The nice thing about these is that you can have an "info string" after the opening fence. From the GFM spec:
So we can use the first word to identify the language:
=>
We use other classes in code blocks, and the obvious suggestion is to support them, too, by putting them in the info string:
=>
But we might want to take the opportunity to clean things out a bit here. A quick survey of the JS docs yields the following classes on code blocks, in addition to language classes:
example-good
example-bad
highlight[x,y,z]
line-numbers
no-line-numbers
hidden
example-good and example-bad
Style this as a good/bad example (e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Illegal_character#mismatched_characters).
This is used extensively in the JS docs (~350 usages) especially the error reference. We should probably keep it.
highlight[x,y,z]
Highlight the lines with the given line numbers.
This isn't currently working, nor is is documented at https://developer.mozilla.org/en-US/docs/MDN/Guidelines/CSS_style_guide. Sometimes (about half the time apparently) people do
highlight:[x,y,z]
, and because it's broken and undocumented, I don't know which is correct.So for those reasons, although it does seem to be used several hundred times in our docs, I'd vote to discard it.
line-numbers and no-line-numbers
I count ~49 instances of
line-numbers
and ~500 instances ofno-line-numbers
across our docs. It doesn't seem to work, we seem to get no line numbers either way. I would like to discard this, and personally I like not having line numbers.But if we want to have line numbers for some examples, we need a way to switch if off especially for syntax box-type code blocks (e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice#syntax).
hidden
Don't render the block.
I think we need
hidden
for code blocks in live samples, where people want the code to contribute to the live sample but don't want to show it (for example, for a bit of CSS to make the example look nicer - although we might argue that it would be better and more consistent for our examples to use common styles by default...).But actually all the (several hundred) examples of this I can find that relate to live samples use it on a
<div>
, not a code block. For example, like this:content/files/en-us/web/css/text-justify/index.html
Lines 54 to 60 in 1d2c354
I'll talk about the general usage of
hidden
on<div>
in another issue, but for live samples, I wonder if we'll need to do some conversion like: if you see<div class="hidden">
, then applyhidden
to all code blocks in that<div>
.The text was updated successfully, but these errors were encountered: