Is there a way to make a repository's page on Github show its README.md above its list of top-level files? Scrolling past that list is tedious when it's long (for one's own repos), and when browsing others' repos (when the readme means more than the filenames).
Use this custom user stylesheet:
DIV.repository-content {
display: table
}
DIV.js-repo-meta-container {
display: table-caption
}
DIV.readme {
display: table-header-group
}
This turns the DIV that groups most of the page's elements into a table, and then makes the README element a table header. This moves it top of the "table." I also turned the "meta" element into a caption for the table so it appears above the README, because that's informative when browsing repositories.
Obviously this styleseet is fragile and will break when GitHub decides to redo how they style their pages.
For this custom stylesheet to work it needs to be set as a custom CSS in your browser. This may be easy (Internet Explorer), difficult (Firefox), needing an extension (Chrome), or impossible (Edge?).
Nope, I think github is just setup to always show files first. sorry :'(
Related
I'm writing a wiki in Git and I'd like to reference another section within the same page. I'm trying to reference a section that is within a drop down. It looks like this:
<details><summary>Component</summary>
### Section I'd like referenced
</details>
[Link to ### Section I'd like referenced]
Any ideas? Is this even possible in Markdown? Note that this is within the wiki, and not a .md file in the repo
In other Wiki engines, and I presume with GitHub as well, this doesn't work because the disclosure element's contents, and therefore the link, are hidden and the browser can't navigate to them. The best I could do is to link to something just above my disclosure element, might even add a hidden one myself, e.g. <span id="link-here"/>
I'm working on a GitHub page, my first one, and I don't think my CSS is linking properly. The CSS won't show up on the page.
My repository: https://github.com/EnderCodesLol/endercodeslol.github.io/tree/main/rockpaperscissors
My page: https://endercodeslol.github.io/rockpaperscissors/
Any reasons?
Add font size property instead of text-size . The css file is linked already
Is there anything in markdown syntax specifically on GitHub to support hidden text?
I just want to put some to-do notes in README.md for myself, not to be visible.
EXTRAS
As a tribute to the great answer by Tamas, and what's also asked a lot of times, below is an example of how to write foldable sections within MD files:
<details>
<summary><b>My section header in bold</b></summary>
Any folded content here. It requires an empty line just above it.
</details>
Just use standard HTML comments:
<!-- This is commented out. -->
(This DOESN'T work on GitHub, which strips out CSS. But it can work in other Markdown viewers/editors. The reason I am adding it is because this question came up first when Googling hidden field markdown).
You can hide the field using CSS, if the rendering process respects it and doesn't strip it out:
Is this worth the hassle, as opposed to using an HTML comment? Probably not in most cases, though it does allow toggling visibility on and off.
#### hidden field with metadata 👇
<div class="meta_for_parser tablespecs" style="visibility:hidden">{"dataname":"environment","colvar":"varname","colval":"value"}</div>
#### hidden field with metadata 👆
glow a Rust-based terminal viewer
Typora, on macos
Macdown, on macos
But not GitHub
I'm using Confluence 5.1 and I'd like to hide the sidebar - but only on a few pages. I only found a JQuery based solution which does not seem to work right in all browsers. It seems to hide the sidebar completely regardless of the default settings.
I found a CSS based solution for this after searching around the web for a long time.
Basically, all you need to do is add a CSS macro to the page which shouldn't have a sidebar containing the code below.
CSS Stylesheet macro
#splitter-content {
width: 100% !important;
left: 0px !important;
}
.vsplitbar{
visibility: hidden;
}
This CSS block spans the page content over the whole page width and removes the left margin normally reserved for the sidebar. It also hides the split bar which is normally used to change the sidebar size.
The nice thing is that you don't have to mess with cookies this way or make sure the sidebar is turned back on on the following pages.
There was a Confluence bug filed for this and it was rejected* due to a desire to have a more simplified configuration system. In that bug, a workaround is proposed.
Add this to a <script> stanza at the bottom of the <head> tag in your custom HTML:
AJS.toInit(function(){
if (AJS.$("div.ia-fixed-sidebar").width() > 55){
AJS.Confluence.Sidebar.toggle();
}
});
Since I don't have that level of control, I opted for a Greasemonkey script instead. This only affects me, but it does solve my problem (I just have to make sure I don't take too much advantage of the extra width this affords me). Here is a sample userscript for this, also posted to Github [install]
// ==UserScript==
// #name Confluence - Hide sidebar
// #namespace https://github.com/adamhotep
// #description Collapse the sidebar upon page load
// #include https://confluence.*
// #include http://confluence.*
// #version 1
// #grant none
// #license GPL
// ==/UserScript==
// from https://confluence.atlassian.com/confkb/how-do-i-remove-the-side-bar-in-confluence-5-330796984.html
if (typeof AJS === 'function') {
AJS.toInit(function(){
if (AJS.$("div.ia-fixed-sidebar").width() > 55){
AJS.Confluence.Sidebar.toggle();
}
});
}
This is theme-specific. The above code assumes the default theme and is not guaranteed to work in later versions of Confluence. See the "workaround" link for the code needed for the documentation theme.
* There's also another bug related to a cookie that is supposed to preserve whether or not to show or hide the sidebar. Supposedly, the bug is fixed, but this directly contradicts the first bug linked in this answer, so I can't make sense of it.
There's a module to do this in Drupal land, but I've been frustrated with the hacks that've been necessary in Wygwam. What is the best way to go about implementing this in such a way that you don't need to totally override the default image handling in ChannelImages/Wygwam?
Assets is a good suggestion, but I believe Devdemon's channel images might be a better fit for the workflow you're suggesting.
http://www.devdemon.com/channel_images/
Clients can add (and see) a caption and more and it's fully integrated with Wygwam and other editors. Devdemon's support is also excellent.
The Assets module from Pixel & Tonic allows you to double-click on the image (or any other file) and add metadata. You then have access to the metadata in your templates.
Check the screenshot: http://pixelandtonic.com/assets
You can also add metadata using the native File Manager. Click the edit icon from the File Manager and you'll see a few fields. You can use the File Entries tag to access it.
http://expressionengine.com/user_guide/modules/file/file_tag.html
I typically use Matrix with one column for the image, one column for the caption, and if a link is needed another column for the link. This of course works best if the image is in a fixed location within your template.
On possible way to accomplish this that I have used is to run some jQuery that looks for images within a certain area, and if they have alt attributes, rewrite the image tag within a tag with a tag inside.
so:
jQuery(document).ready(function() {
$('#page-content > .wrapper img').each(function(){
if($(this).attr('alt') !== undefined && $(this).attr('alt').length > 0){
if(!$(this).parent().hasClass('content-image')){
$(this).replaceWith("<figure class='content-image "+$(this).attr('class')+"'>"+$($('<div></div>').html($(this).clone().attr('class',''))).html()+"<figcaption>"+$(this).attr('alt')+"</figcaption></figure>");
}
}
});
});
will do just that. It's looking within a #page-content div for img tags with alt attributes. And then rewriting it as
<figure><img src='....' .... /><figcaption>This is the text that was in the alt attribute</figcaption></figure>
Soooo, that kinda works. The only caveat is that you had better not use any double-quotes within your alt text, or it will break thangs. Not the cleanest of solutions, but a solution, nonetheless.