3 ms·

> Code in examples doesn't change, and the way they are highlighted doesn't change. I'd consider it an accessibility issue - hardcoding the syntax highlighting

> Code in examples doesn't change, and the way they are highlighted doesn't change. I'd consider it an accessibility issue - hardcoding the syntax highlighting on the backend makes it more difficult for people to change using accessibility tools. Whereas with js-based highlighting, you can probably just change the theme and get readable output.

iudqnolq 6y ago
If you used semantic class names you could change the theme with just css.
detaro 6y ago
What kind of accessibility tools are you thinking of that would work with JS highlighting, but not server-generated? (Given that generally both would produce roughly the same in-browser DOM, which is what most modern accessibility tools work against)
- iudqnolq 6y ago
  You seem to be describing accessibility tools for completely blind users, and I think they were describing accessibility tools for users with other sorts of disabilities. For example, someone who uses a custom stylesheet or a browser extension to make the page have higher contrast.
  - detaro 6y ago
    No, the question applies to those just as much.
    - iudqnolq 6y ago
      As far as I know, parsing the accessibility tree is primarily limited to screen readers / brail displays. Am I missing something?
      - detaro 6y ago
        I'm speaking of the normal DOM representation of the HTML in the page. A server-side highlighter generates HTML with css classes or styling attached that gets turned into a DOM by the browser. A JS-based highlighter edits the DOM by adding css classes or attaching styling. The in-browser representation of the end result, which a browser extension likely works with, can be the same, and how it looks like exactly is more important for their functionality than if the server or JS did it.
- zimpenfish 6y ago
  > that would work with JS highlighting, but not server-generated? Mainly that JS highlighting normally works with a theme variable which is much easier to change to get, e.g., a high-contrast theme than having to muck about with 10-20 different CSS styles. Ignoring that option, working with a known set of CSS styles in the DOM is going to be easier than dealing with John Q Random's own particular set for highlighting (assuming they haven't used the same as a popular JS highlighter, of course!) (To my shame, whatever Hugo is now using for syntax highlighting makes an awful mess - everything is "style:color#123456", no semantic information - I'll be fixing that ASAP.)

iudqnolq 6y ago

If you used semantic class names you could change the theme with just css.

detaro 6y ago

What kind of accessibility tools are you thinking of that would work with JS highlighting, but not server-generated? (Given that generally both would produce roughly the same in-browser DOM, which is what most modern accessibility tools work against)

iudqnolq 6y ago
You seem to be describing accessibility tools for completely blind users, and I think they were describing accessibility tools for users with other sorts of disabilities. For example, someone who uses a custom stylesheet or a browser extension to make the page have higher contrast.
- detaro 6y ago
  No, the question applies to those just as much.
  - iudqnolq 6y ago
    As far as I know, parsing the accessibility tree is primarily limited to screen readers / brail displays. Am I missing something?
    - detaro 6y ago
      I'm speaking of the normal DOM representation of the HTML in the page. A server-side highlighter generates HTML with css classes or styling attached that gets turned into a DOM by the browser. A JS-based highlighter edits the DOM by adding css classes or attaching styling. The in-browser representation of the end result, which a browser extension likely works with, can be the same, and how it looks like exactly is more important for their functionality than if the server or JS did it.
zimpenfish 6y ago
> that would work with JS highlighting, but not server-generated? Mainly that JS highlighting normally works with a theme variable which is much easier to change to get, e.g., a high-contrast theme than having to muck about with 10-20 different CSS styles. Ignoring that option, working with a known set of CSS styles in the DOM is going to be easier than dealing with John Q Random's own particular set for highlighting (assuming they haven't used the same as a popular JS highlighter, of course!) (To my shame, whatever Hugo is now using for syntax highlighting makes an awful mess - everything is "style:color#123456", no semantic information - I'll be fixing that ASAP.)