https://github.com/soulshined/ft-syntax-highlight
Pure CSS syntax highlighter, no Javascript required. Includes built-in tooltips with UI themes and syntax highlighting themes
https://github.com/soulshined/ft-syntax-highlight
css html nojs purecss syntax-highlighting themes tooltips
Last synced: 3 months ago
JSON representation
Pure CSS syntax highlighter, no Javascript required. Includes built-in tooltips with UI themes and syntax highlighting themes
- Host: GitHub
- URL: https://github.com/soulshined/ft-syntax-highlight
- Owner: soulshined
- License: mit
- Created: 2017-11-16T21:36:24.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2018-07-21T03:03:50.000Z (almost 8 years ago)
- Last Synced: 2024-05-02T05:06:42.903Z (about 2 years ago)
- Topics: css, html, nojs, purecss, syntax-highlighting, themes, tooltips
- Language: CSS
- Homepage:
- Size: 1.88 MB
- Stars: 69
- Watchers: 2
- Forks: 25
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# ft-syntax-highlight
A lightweight, **pure CSS** syntax-highlighter; no Javascript required. A syntax-highlighter with 8 custom built-in UI themes like dark, light, simple, burberry, midnight, bootstrap and more! Common-sense tagging, line numbers and custom, pure CSS tooltips for identifying elements! Supports all major browsers and HTML versions. Made specifically for those pure CSSers like me!
# Table of Contents:
| Point of Interest | Description |
| ---| ---|
| [Getting Started](#getting-started) | How to link to project & recommended usage |
| [About](#about) | Review the mission of this project & learn about the benefits of a pure CSS syntax highlighter over automated counterparts |
| [Understanding Selectors](#understanding-selectors) | Overview of why the tagging system is structured as it stands & best practices |
| [Support](#support) | Detail overview of supported languages, features, UI themes, syntax themes and browsers |
| [Road Map](#road-map) | Outlined vision and plans for future languages |
| [Technical Specs](#technical-specs) | Any relevant under-the-hood stuff; font used, fallbacks etc |
| [License](#license) | |
| [Links](#links) | Links to non-project related resources |
## Getting Started
[[top]](#table-of-contents)
#### Disclaimer:
>Due to the nature of this libraries scalable potential, the .css files structure is explicitly focused on organization, not so much on short-hand practices. Therefore, you will see, in most cases, selectors are not compounded, but individually styled based on its respective language.
The bare minimum for using ft-syntax-highlighter on a web page is linking to the library and adding a class selector to your ```
``` tag:
```html
```
We recommend downloading the file and placing it in your projects directory for offline use or otherwise.
**Linking to GitHub path directly.** Because of the nature of the project, the library is supported to work straight
from the source. However, we assume you understand the risks of using this method provided source code changes or files are altered without notice.
After you've added the class to your ```
``` tag you must identify the syntax using our `data` attributes for respective supported languages:
```html
...
```
This will initiate proper tooltips for the respective selection.
For syntax highlighting, you can pick from any of the syntax highlighting themes:
```html
...
```
Please note, that highlighting **ONLY** occurs in the `code` tag and there is **NO** default.
You can also specify a UI theme if you don't want the default dark theme.
**Example**
```html
<!-- This is a single line HTML comment -->
```
It is **highly recommended** you don't nest `
...
`
**BASICS**
What we mean by 'common-sense' tagging is simply put, keeping things as natural as possible. The end goal is to isolate elements on a per-language basis, while somehow trying to make all other languages tagging familiar so you’re not learning 20,000 different classes/tags.
For example, considering XML is a low-level language, it's elements are broken down simply to elements, attributes, attribute values, namespaces and comments. Those are exactly what we use for tags in this scenario.
However, consider Javascript as a higher-level language, there are multiple elements that could define an 'element' or 'variable' or 'selector'. We specifically oversimply the lingo in this regard so we aren't coding for astronomical amounts of identifiers. Variables, functions as variables, local variables etc. can all be targeted with a `` tab. And the same is true for jQuery, and PHP.
Although, we do specifically target identifiers like a Class, or UDF. These will still have an identifier prefix, but followed by a specific name: `...` || `...`
**BEST PRACTICES**
- `` should be reserved for when you reference an attribute's value for any language, not for things such as text. For example: `... || ...` the value for the style attribute is considered good practice for this tag.
- `` should be reserved for ALL languages' reserved words. (Things like `else`, `if`, `then`, `do`, `until`, `while`, `not`, `return` etc.). Each language has a predefined list of reserved words. This is considered good practice for this tag and works with all languages using ft-syntax-highlighter.css
- `` It's important to stress the value of this tag. Users could argue that they simply could type in the line number instead of using a dedicated `` tag. However, for the users that aren't aware, `::before` and `::after` pseudo classes don't allow user selection. In other words, when viewers go to your website then copy and paste code in the `` tag, the line numbers will not be included in the copied text due to being `::before` content. This is important when maintaining a 'pure CSS' solution. Additionally, because whitespace is preserved, it's recommended to use this tag inline with the left side of the `` tag. :
```html
...
```
- `` should be reserved for any case where a unit of measure, time, numeric value, temperature etc are defined
- `