CSS, SASS(SCSS), LESS, STYLUS highlighting differences.

[w3suli]

A list of things to keep in sync:

See the css_consistency branch.

• vendor specific prefixes (attributes) (enh) Improve CSS consistency across CSS-like grammars #2425
• vendor specific prefixes (at-rules) (enh) Improve CSS consistency across CSS-like grammars #2425
• tag selectors (enh) Improve CSS consistency across CSS-like grammars #2425 (just adds tests)
• class selectors
• ID selectors
• pseudo selectors : (enh) Improve CSS consistency across CSS-like grammars #2425
• pseudo selectors :: (enh) Improve CSS consistency across CSS-like grammars #2425
• top level psuedo-selector :lang(de)
• selection attribute, i.e. a[href*="example" I] (See: (css) selector-attributes are not highlight correctly #2243)
• function highlighting, ie (grayscale(0.5))
• at-rules @import, etc.
• media at-rules highlighting ("@media", "not", "only" and "and")
• selection of @media attributes ("(orientation: landscape)" or "(min-width: 600px)")
• variables
• attributes
• What are we missing?
• use uniform TAG list
• use uniform PSUEDO-SELECTOR list
• use uniform ATTRIBUTE list
• !important

Sass bug list:

• attribute prefix -I like it but different from css and less - unfortunately bad (-webkit-animation-name:)
• for the selection attribute, the string is not highlighted (a[href*="example" I])
• lack of function highlighting (grayscale(0.5))
• at-rules with highlighting difference (@Keyframes "from" "to")
• lack of selection of @media attributes ("(orientation: landscape)" or "(min-width: 600px)")
• other differences: ":lang(de)"

Less bug list:

• for the selection attribute, the string is not highlighted (a[href*="example" I])
• lack of pseudo selectors highlighting (q::after)
• lack of function highlighting (grayscale(0.5))
• lack of selection of @media attributes ("not", "only" and "and")
• other differences: ":lang(de)"

Stylus bug list:

• attribute prefix -I like it but different from css and less - unfortunately bad (-webkit-animation-name:)
• lack of attribute selectors highlighting (a[href*="example" I])
• lack of pseudo selectors highlighting (q::after)
• lack of function highlighting (grayscale(0.5))
• lack of at-rules highlighting ("@font-face" "@Keyframes", "from", "to")
• lack of media at-rules highlighting ("@media", "not", "only" and "and")
• lack of selection of @media attributes ("(orientation: landscape)" or "(min-width: 600px)")
• other differences: ":lang(de)"

There is a lot of difference. If I have enough time, I'll make examples one by one. I welcome any help. Thanks in advance for all your help!

[joshgoebel]

I'll make examples one by one

Of each bug with each grammar? I'm not sure that's a great use of time. What really should happen here is to look at how to consolidate all of these, reuse some matchers, merge grammars where possible, etc. That might start to look like more of a ground-level rewrite - and then this exact list of bugs wouldn't be useful at all. It's be more useful to rebuild things on a solid foundation and then see where we stood.

It's possible Less/CSS/SCSS could likely become a single grammar... (or very close)... and SASS and Stylus are very similar also.

Optimally someone (with a lot of time) needs to dig in here and think about this at a very high level. If we can do something like build 5 on 2 core grammars... or 5 on 1... then keeping the features in sync with future improvements becomes much simpler.

Otherwise we could spend a bunch of effort today just to have them get out of sync again in the future.

[joshgoebel]

Your side by side is also potentially not accurate as you used the same source-source code... SASS and Stylus (at least) are an entirely different grammars AFAIK. They don't expect/require brackets or semi-colons, etc... so it's possible some of the issues you're seeing are because they aren't intended to highlight RAW css code, which is what it appears you're using.

To actually test them properly you'd need the same CSS, but converted to each actual language, though some of them might be interchangeable.

[joshgoebel]

Stylus sounds fun:

Stylus uses the .styl file extension and it allows us to write code in many different ways. We can use the standard CSS syntax, but we can also omit brackets, colons, and/or semicolons or leave out all punctuation altogether.

LOL.

[joshgoebel]

I'd really love to avoid having to include ALL the TAGS and ATTRIBUTES if possible.

[joshgoebel]

You might start by looking at which rules are "generic" in the sense that we could have them in a single place (like CSS) and then pull into the other grammars from there. And then CSS would become a requirement of the other grammars and common things (like list of tags, or attributes, if necessary) would live in CSS grammar.

CSS's FUNCTION_LIKE might be one example.

[joshgoebel]

attribute prefix -I like it but different from css and less

Not so much a feature as side-effect because it's only highlighting attributes it's heard of... but this shouldn't probably be "fixed" to highlight the whole attribute like elsewhere since (as discussed elsewhere) we don't really have a class for highlighting prefixes differently.

[w3suli]

Almost everything that came to my mind the last day was said.
I looked at the codes and saw that it was possible to set up dependencies.
I do not know all css preprocessors well enough. I know Sass and SCSS well. I am less familiar with LESS, STYLUS and PostCSS. As far as I know, all of them use the default css code and add more options. Therefore, they all depend on CSS.

The css preprocessors require thorough study for proper work. the difficulty is how to solve it so that everything is highlighted correctly, without having to specify each language element separately.

It would be good to solve this, but it takes a lot of work. However, if we did, we would get a more compact and efficient code.

In addition, the appearance of css highlights could show a consistent image, which improves clarity and looks nicer.

I would be happy if this could be solved.

[w3suli]

@yyyc514 Is it possible to call a language in another language by modifying its elements?

I started to create scss by rewriting the original css. goes well so far, but in many places you have to go into the original code.

What do you think would be a good solution?
The original recognition of css should be retained, since you can use css in scss as well. However, scss adds new elements to css, so the original css code needs to be modified in many places. However, it would be a bad idea to re-include the original css highlighter description everywhere.

It could be possible to highlight multiple languages within a language file if it is possible to resolve the add-on code snippets only for that alias scss stylus etc. switch on.
If the CSS language constants from another language are available. You could then inherit these constants by modifying the required parts.

What is possible in hljs?

[joshgoebel]

Take a look at arduino and CPP. One way to do this is to make them all depend on CSS and put all the "core" rules there (as much as makes sense)... then you build all the syntaxes based on those rules... For example if we REALLY need a list of all CSS attributes you'd put it in inside CSS then do:

var cssLang = hljs.getLanguage("css").exports
cssLang.attributeNames
// etc

Or some such...

This might be a lot easier to solve after we switch to modules and the new build system, which is why I wasn't in a rush to solve it. :-)

Honestly I wondered if CSS/SCSS could be a single language... but I"m not sure how feasible that is.

[joshgoebel]

There is also sublanguage support, but I don't think that's what we want to do.

[joshgoebel]

I'd start with VERY small snippets and then make your new grammars work with them, then expand.. and keep iterating... like start with:

body {
  background: green;
}

That is SCSS and CSS. Get it highlighting... then add another layer:

body {
  header {
    background: blue;
  } 
  background: green;
}

Make sure that works for both... then maybe more onto pseudo selectors, or @ rules, etc. I'm assuming trying to start from scratch.

[joshgoebel]

And if you also did Stylus and Less side by side then you'd see how they were all working at once... and if you did all this in a PR we could provide thoughts and advice as you went.

Then after you covered the basics you'd move on to extension specific things like variables, etc... though I guess variables are also part of CSS now too, lol... but you get the point I hope.

[w3suli]

Thanks for the help!

I'm exploring the possibilities. I hope I can put together a single compact solution and avoid duplication.

[w3suli]

@yyyc514 I'm still thinking about what to do with stylus. If you need to add css properties, which solution is good?

Currently used:

border-width|border-top-width|border-top-style|border-top-right-radius|border-top-left-radius|border-top-color|border-top|border-style|border-spacing|border-right-width|border-right-style|border-right-color|border-right|border-radius|border-left-width|border-left-style|border-left-color|border-left|border-image-width|border-image-source|border-image-slice|border-image-repeat|border-image-outset|border-image|border-color|border-collapse|border-bottom-width|border-bottom-style|border-bottom-right-radius|border-bottom-left-radius|border-bottom-color|border-bottom|border

Shorter version:

border-(bottom|top)-(left|right)-radius|border-image-(outset|repeat|slice|source|width)|border-(bottom|left|right|top)-(color|style|width)|border-(bottom|collapse|color|image|left|radius|right|spacing|style|top|width)|border

Most compact version:

border-((bottom|top)-(left|right)-radius|image-(outset|repeat|slice|source|width)|(bottom|left|right|top)-(color|style|width)|(bottom|color|collapse|image|left|radius|right|spacing|style|top|width))|border

The file size can thus be reduced. Because there are many such css properties.

I don't know how much it affects the speed, but it worsens the purity with the introduction of a new css feature.
It will be slightly more labor intensive to add a new feature in some cases.

[joshgoebel]

List them all out, the other just makes future maintenance hard. This is what gzip is for (saving bytes)... But I'd do even further and list then in array form now a string... I have a feeling we'll want to use them outside of keywords...

[joshgoebel]

I don't mind being smart for certain individual attribute though, such as for border:

border-(left|right|top|bottom)-(style|radius|width) etc...

That might actually make it easier to see what is going on and doesn't make maintenance harder since it's really part of a single attribute "border", so it's well grouped.

[w3suli]

I also saw a block solution, but there it finally generates a regular expression full of treasures out of the array with extra steps.
In your opinion, which solution should be used?

[joshgoebel]

If I was doing it I'd probably do a mix in an array:

PROPERTIES = [
 [string], 
 [string],
 [regex],
 ... 
]

Then you could use regex to describe some of the attributes that lended themselves well to that... or else just an array of literal strings.

[joshgoebel]

Though I still debate if you need an actual list. It seems you could just match something: as a property, no? CSS does just fine now without having any lists at all.

[w3suli]

So let's use it like this: PROPERTIES.join('|')

It's not good this way:

border-(left|right|top|bottom)-(style|radius|width)

In this case, non-existent properties are also formed.

[joshgoebel]

In this case, non-existent properties are also formed.

Properties that will never appear in CSS files anyways. And how much easier to maintain is that that writing out 100 different possibilities? Many of our grammars cheat in the same way.

But again, why not avoid the list completely?

[w3suli]

Yes css is good.
The problem is the stylus.
The list is important there. The language is so simplistic that the point of simplification is that you know the list.
With a stylus, you will surely need a list.

[joshgoebel]

The problem is the stylus.

How so? All the examples I see still have properties ending in :

Oh I see you can also write:

body
  color white

Ugh :-) Still isn't the first word always a property?

[w3suli]

The stylus leaves everything out, so incorrectly marked elements can be formed if there is no list.
Unfortunately for Stylus, the list of html members also seems to be necessary :(.

[joshgoebel]

Unfortunately for Stylus, the list of html members also seems to be necessary

I'm not sure this is true, but it MIGHT be. It's definitely easier if you have a list.

Isn't [single word] (, [single word])* always a list of tags?

[spacing][single word] [another word] is a property assignment.

[joshgoebel]

Seems 100% possible:

https://github.com/PrismJS/prism/blob/master/components/prism-stylus.js

If we can avoid a list that also means the syntax is always stays up-to-date... and we don't need to keep adding new CSS/HTML tags to it over the years. That's a big win.

[w3suli]

If possible, I'd like to avoid the list. But I wouldn't get a wrong selection either.
The most interesting are the nested elements where you have to decide whether a new selector or a property is the word.

nav
    margin 10px

    ul
        list-style-type none

        > li
            display inline-block

            &.current
                background-color lightblue

or

xy = red
nav
    margin 10px
    ul
        list-style-type none
        > li
            display inline-block
            background xy
            color green
            span
              padding 10px
            &.current
                background-color lightblue

Thanks for the link.
I'm investigating the solution.

[joshgoebel]

In that sample every "more than one word" is an property/value pair. The only "edge case" is > li and that's pretty easy to detect as a selector... (since it includes >)

By word I mean "contiguous sequence of characters".

[w3suli]

Yes, I think it will be necessary for a few more weeks.
There are even minor problems and issues to resolve.
There is no problem with basic css (scss, less, sass, stylus) rendering, that's fine.
The functions and other additional features of css preprocessors still give some work.

Regarding the list of CSS properties, I would suggest:
I think it would be a good idea to include items in both the experimental and recommended stages. For example, prism already highlights css --* as a variable.

:root {
  --first-color: #488cff;
  --second-color: #ffff8c;
}

#firstParagraph {
  background-color: var(--first-color);
  color: var(--second-color);
}

#secondParagraph {
  background-color: var(--second-color);
  color: var(--first-color);
}

#container {
  --first-color: #48ff32;
}

#thirdParagraph {
  background-color: var(--first-color);
  color: var(--second-color);
}

https://developer.mozilla.org/en-US/docs/Web/CSS/--*

I've collected a list of internal functions:
annotation()
attr()
blur()
brightness()
calc()
character-variant()
circle()
clamp()
conic-gradient()
contrast()
counters()
cross-fade()
cubic-bezier()
drop-shadow()
element()
ellipse()
env()
fit-content()
format()
grayscale()
hsl()
hsla()
hue-rotate()
image()
image-set()
inset()
invert()
leader()
linear-gradient()
local()
matrix()
matrix3d()
max()
min()
minmax()
opacity()
ornaments()
paint()
perspective()
polygon()
radial-gradient()
rect()
repeat()
repeating-linear-gradient()
repeating-radial-gradient()
rgb()
rgba()
rotate()
rotate3d()
rotateX()
rotateY()
rotateZ()
saturate()
scale()
scale3d()
scaleX()
scaleY()
scaleZ()
selector()
sepia()
skew()
skewX()
skewY()
steps()
styleset()
stylistic()
swash()
symbols()
target-counter()
target-counters()
target-text()
translate()
translate3d()
translateX()
translateY()
translateZ()
url()
var()

If I differentiate the built-in functions, I need to list them.
hljs.CSS_NUMBER_MODE is missing the units "fr", "Q", and "x". The "grad" and "rad" can be merged into "g?rad".

[joshgoebel]

The "grad" and "rad" can be merged into "g?rad".

Not worth it, just list them both.

That's not that long of a list... I think the real decision is whether there is value in differentiating built-in functions vs user functions. I think probably?

[joshgoebel]

I think it would be a good idea to include items in both the experimental and recommended stages.

No objection.

[w3suli]

Current state:

This is used by css:
<span class="hljs-built_in">calc</span>(<span class="hljs-number">100%</span> - <span class="hljs-number">80px</span>)

This is used by stylus:
<span class="hljs-function"><span class="hljs-title">sub</span><span class="hljs-params">(a, b)</span></span>

The two representations are clearly different.
It is true that the functions used in the property values are not highlighted by stylus at all.

If we do not differentiate them, then we have to decide what the uniform highlighting structure of the function should be.

Each solution has its advantages and disadvantages.

The benefit of differentiation is that it shows you where to look for the function. A non-built-in function in the style files, while a built-in function in the style language description.

[joshgoebel]

I'm not really sure what I'm looking at. It would probably help if you used the same underlying code for both examples and then showed what it looks like in the different languages.

I looks like you're using entirely different snippets so that makes it really hard to see anything (at least for me).

[w3suli]

The two solutions are very different. If the functions are not differentiated then a third solution might be good.
What is currently used by (stylus) is only the non-built-in functions highlighted. The parenthesis and all parameters within it. What css uses is highlighted before the parenthesis word as built-in. Brackets and other characters are not highlighted. Only numbers and strings are highlighted within parentheses.

If you need a unified solution, you might want to keep the css complemented by highlighting numbers and strings, highlighting each letter or word as a parameter.

Then, the question is whether the built_in or function class is used to highlight the word before the parenthesis?

[joshgoebel]

I feel like I already answered this. I saw lets track both functions and built-ins as different things and see how that works out.

[joshgoebel]

Any luck? :)

[joshgoebel]

FYI: Now that we have modules we also have the ability to pull common things out into a lib/css module and then share them at compile-time rather than run-time. Currently all the languages are still individually compiled but as soon as we have common modules that start to cross-language I'll update the build process to build one huge bundle for included languages which will cut down on duplication, etc.

I'm not 100% sure that's what we want here, but just mentioning it as a possibility. It's definitely preferable to copy-and-paste for simple things.

[joshgoebel]

Where is the source code example for your very first post? And how did you get the 4 side by side? Do you have a HTML template you're using for the previews? It'd be helpful if you attached those things so others could also use them.

I think we need to go back and split this into bite size pieces so that each one can turn into a small PR that is easy to review and get merged. If fear we've gone and made this a huge project and hence it's stalled out. You could do it by language but I think it'd be easier to do it by feature...

So you could start with say vendor prefixes, get those working the same everywhere, etc... then pseudo-selectors, etc... these could be separate PRs or separate commits inside a larger PR... If you made a complete list of CSS/CSS processor features how long would it be? 10-20 items?

And adding markup tests for each as you went... that way once you had things looking the same you could refactor the languages easily knowing we had solid tests to catch any issues.

[joshgoebel]

I created a checklist (above in the first message of this thread) and an example: #2425

First, add tests. Then make the grammars consistent. Optimization and sharing code can come last - so I didn't even focus on that. Obviously we should share vendor prefixes globally, etc.

I have a small script to make keeping the tests in sync easier:

#!/bin/bash
cp test/markup/css/css_consistency.txt test/markup/less
cp test/markup/css/css_consistency.expect.txt test/markup/less
cp test/markup/css/css_consistency.txt test/markup/scss
cp test/markup/css/css_consistency.expect.txt test/markup/scss
cp test/markup/css/css_consistency.txt test/markup/stylus
cp test/markup/css/css_consistency.expect.txt test/markup/stylus

If you want to work on this you can make PRs against the css_consistency branch rather than master so we keep all this work isolated for now.

[joshgoebel]

@taufik-nurrohman This is a big chunk of work if you wanted something large to cut your teeth on. :-)

[w3suli]

I will have time again by June. I will continue to work on the topic. Sorry I didn't have time for the new year :(.

There is a need on which I would like to ask @yyyc514 opinion, as well as the opinion of others.
In the case of css, would it be possible to highlight css correctly even without selectors?

When you leave the selector in an article, because only the property and the value are important:
border : 2px solid green;

[joshgoebel]

Maybe, maybe not.

I feel like we're wasting time answering questions like this without specific context. I made a long list (see initial message) of individual items to work thru... so lets focus on that list - knocking things off one at a time - and then when one of the items on it leads to us asking this kind of question, I say discuss it at that point - with the full context on hand, a PR to look at, etc.

I've also been trying to make the minimal invasive changes to do this so far... and work on building up a comprehensive test suite across all the CSS-like grammars... then once we have very high test coverage we can circle back at how we might make any of the individual grammars simpler.

[w3suli]

@yyyc514 Thank you for your support!

When I cut in, it seemed simpler at first. However, during the work, it turned out that the basic css highlighter also has shortcomings.

I don’t want to waste time, but a lot of little little things came up.

Maybe I lost a little bit of the details. Such as unicode selectors, which are also highlighted in the Visual studio code.

For example, that's why I created the following solution:

CSS_SPECIAL = '!|"|\'|`|#|\\$|%|&|\\(|\\)|\\*|\\+|,|-|\\.|\\/|:|;|<|=|>|\\?|@|\\[|\\\\|\\]|\\^|{|\\||}|~';
CSS_SPECIALS = CSS_SPECIAL.replace(/\|/gi, '');

...

className: 'selector-id', begin: '\\#(-?((\\\\('+CSS_SPECIAL+'|[0-9a-f]{1,6}\\s?))|(?![-\\d'+CSS_SPECIALS+'\\s]))|--)((\\\\('+CSS_SPECIAL+'|[0-9a-f]{1,6}\\s?))|[^'+CSS_SPECIALS+'\\s])*'

There are lots and lots of little things, yet. I started working on these, but they stopped. I will have time to continue soon.

._
#_
._7
#_7
._a
#_a
.--
#--
.-a
#-a
.--3
#--3
.class
#id
.Class
#Id
.clAss
#iD
.CLASS
#ID
.cláss
#íd
.cläss
#iđ
.člasŝ
#ίδ
.класс
#идентичность
.クラス
#身元
.מעמד
#זהות
.صنف
#هوية
.कक्षा
#पहचान
.c-lass
#i_d
.c-lass
#i_d
.-class
#-id
._class
#_id
.►♫♪™
#►♫♪™
.cla$s
#:d
.cl@ss
#i&
.\31
​#\31
.\31 0cl\31 ass
​#\31 0id\31abcd gass
.\31 fclass
​#\31 fid
​#\31fid
.\31gclass
​#\31gid
.\31@
​#\31@
..
#.
.#
##
.@
#@
.!
#!
.$
#$
.%
#%
.&
#&
.(
#(
.)
#)
.*
#*
.+
#+
.,
#,
.-
#-
./
#/
.:
#:
.;
#;
.<
#<
.=
#=
.>
#>
.?
#?
.[
#[
.\
#\
.]
#]
.^
#^
.{
#{
.|
#|
.}
#}
.~
#~
."
#"
.'
#'
.`
#`
.cs!#$%&()*+,-./:;<=>?@[\]^{|}~"'`
#id!#$%&()*+,-./:;<=>?@[\]^{|}~"'`

/* NOT Classes*/
.-
.-4
.5
..
.@
.!#$%&()*+,-./:;<=>?@[]^{|}~"''" #!#$%&()*+,-./:;<=>?@[\]^{|}~"''"

[toastal]

Title: CSS, SASS(SCSS), LESS, STYLUS highlighting differences CSS, Sass(SCSS), Less, Stylus highlighting differences

[joshgoebel]

When I cut in, it seemed simpler at first. However, during the work, it turned out that the basic css highlighter also has shortcomings.

They each have their own shortcomings. Bringing them all into alignment is going to be a lot of slow, laborious effort I think. I started it, but I think someone else may have to finish it. I'm not interested in patches that ONLY fix one while ignoring the others.

Such as unicode selectors, which are also highlighted in the Visual studio code.

Picking a single item like that (Unicode selectors) and making a PR is a great idea... add a test, sync it across the CSS languages (I believe I have a script and that most of them support "plain jane CSS" in addition to their more complex form) and then make changes to guarantee the same behavior.

This work (overall) should be done in lots of tiny PRs or else it will be impossible to review. That's why I have a detailed list of CSS features in checklist form at the top of this item... hopefully each item would be a small PR that could be easily reviewed.

[joshgoebel]

What issues did you notice with :lang(de)? Currently I see consistency across all 4 (could be I already fixed):

<span class="hljs-selector-pseudo">:lang</span>(en) {}

[joshgoebel]

  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2"),
       url("/fonts/OpenSans-Regular-webfont.woff") format("woff");

What are url and format here? They aren't technically functions are they?

[joshgoebel]

lack of at-rules highlighting ("@font-face" "@Keyframes", "from", "to")

Could you clarify if you remember? I'm sure keyframes needs work, but what was the issue with font-face (other than the function aren't highlighted, see question above). Right now I have this: (Stylus)

[joshgoebel]

One could question whether we highlight the explicit values like swap, but first I'm just trying to get basic consistency.