Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); GitHub - sand7000/docs: This is the source of the seL4 docs. · GitHub
Skip to content

Repository files navigation

seL4 Documentation site.

These are the sources for the seL4 Documentation site located at https://docs.sel4.systems. It is for cooperatively developing and sharing documentation on seL4.

See CONTRIBUTING.md for information on how to contribute. TL;DR click edit on the page in GitHub, make your changes and then submit a pull request.

Ask on the mailing list or open an issue if something doesn't make sense.

We've tried to make sure the hosted site is WCAG 2.0 AA compliant. Please let us know if we have missed something. This is how we test it.

Diagnosing a problem

Our documentation is contained in a collection of Markdown files stored in this repository. We use Jekyll to generate a static html website that is then hosted on GitHub pages. Our continuous integration is configured to regenerate and update the live site whenever a pull request is merged. There is a timestamp in the source that indicates when it was last generated. Additionally, each page has a timestamp and revision hash from when it was last updated located in the footer based on the git history.

Our markdown pages are rendered using Kramdown, a ruby based markdown converter that is configured to interpret the markdown files (.md) as GitHub flavoured markdown (GFM). We are currently using the jekyll-theme-bootstrap theme that provides a sass implementation of bootstrap. Our custom styling is contained in assets/css/style.scss. HTML templates are in either _layouts or _includes.

Requirements

Building the site

  • ruby-bundler must be installed

Linters

Linting checks require the linters to be installed.

  • HTML output checking using tidy: make check_html_output
  • Liquid syntax checking using liquid-linter: make check_liquid_syntax

Building the docsite

To build and host locally:

git submodule init
git submodule update
# If this doesn't work see: https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/
bundle install
make serve
# Server address: http://127.0.0.1:4000/
# Server running... press ctrl-c to stop.

Or with docker:

make docker_build
make docker_serve

Makefile and JEKYLL_ENV=production version

Jekyll provides an environment flag for providing some content only in a production environment.

One way we use this is to show data generated by rules in the Makefile and saved in _data/generated.yml. If you want to serve the site locally in production mode there are make rules for this. You will need to call the make rule to generate the _data/generated.yml also.

Quick compliance, style and formatting checks

WCAG 2.0 AA conformance

There is a make rule to check conformance to all testable statements from the guidelines. make check_conformance. It requires the site to be hosted locally (using make serve) and a local server of Automated Accessibility Testing Tool (AATT).

make check_conformance will output a file named conformance_results.xml which is a junit testsuite output file that will contain a testcase for each generated html file of the site. A make rule make check_conformance_errors will grep for failing testcases and output the html page name. The idea here is to detect if any pages are failing and then manually using the AATT tool's webinterface to check what parts of the page violate the guidelines.

About

This is the source of the seL4 docs.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages