Packages: [CSS] units in scientific notation

[ghost]

[michaelblyons]

Can you please:

1. Change the title of the issue to something like "[CSS] units in scientific notation"
2. Paste the contents of the relevant file into a code block:
   md ``` css textarea { ... } ```

Thank you.

[ghost]

textarea{
  height: 1e3px !important;
  min-height: 1e3px !important;
  max-height: 1e3px !important;
}

[ghost]

/cc @keith-hall, @Thom1729, @FichteFoll, @michaelblyons

Hey guys, is anyone preparing fix for this? This issue has been opened a week ago and nobody fixed it yet. Please fix it and implement normal coloring for 1e3 and 2.7e5 and similar formats for numbers, they are colored properly in other languages, why are not in CSS?

Also, please fix this issue, but also fix the following Haskell issue: a a = (*) a 1 is not colored like it should be (the multiplication function (operator) is not highlighted like other binary operators), so please fix it, I am sure it is not hard and you are clever guys, you'll know how to deal with it and resolve it. It is very annoying to type further haskell code, while previous code is not properly colored.

Any idea how to fix it? I mean both css and haskell issues are very annoying. I hope someone is working on the fix.

Thanks.

[keith-hall]

https://www.w3.org/TR/css-values/#numbers

When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits and optionally an exponent composed of "e" or "E" and an integer.

so 1e3 doesn't seem to be a valid number in CSS

[ghost]

@keith-hall

Programming languages are defined by implementations, rather by standards. All modern browsers support it. See live example: https://djmangoo.github.io/

So, if browsers support it and if people use it, why not cover these cases, keeping in mind that it is surely an easy fix? I think sublime should support it.

[ghost]

@keith-hall

Wait, the standard actually allows it, I didn't read closely enough. It says

When written literally, a number is {either {an integer}, or {zero or more decimal digits followed by a dot (.) followed by one or more decimal digits}} and optionally an exponent composed of "e" or "E" and an integer.

I added braces to separate the sentence parts properly. What it says is that a number is either an integer followed by optional exponent, or zero or more decimal digits followed by a dot followed by optional exponent. So, 1e3 is a valid number. Hope it is clear now.

[keith-hall]

haha nice try, but why would it fail in the official validator then?

[ghost]

Then consider my first statement "Programming languages are defined by implementations, rather by standards." as the main argument. Also, consider that

1. This fix is easy
2. People use 1e3 notation
3. Browsers support it

So, what's the problem then?

More arguments:

1. Sublime already highlights some non-standard extensions in some languages (for example in Java)
2. Users will not complain if something that works in browsers is highlighted properly

[keith-hall]

then feel free to create a PR :)

[ghost]

Ok, but I need guidance. What line needs to be changed? And how the change should look like. My yaml knowledge is 0 and I'm not very interested in learning it. Please post diffs that fix the issue and I may open PR. The fix is easy for people that know yaml (if that is how you call highlighting language), but for a haskell programmer, it is not easy, im not experienced with it. So, feel free to either open a pr yourself, or post here detailed diffs, so I can open pr myself. The first option if more favorable imo.

Thanks.

[michaelblyons]

The validator doesn't like any of these:

textarea {
  height: 1e3px;
  height: 1.0e3px;
  height: 1E3px;
  height: 1.0E3px;
  height: 1e-3px;
  height: 1e+3px;
  height: 1.0e-3px;
  height: 1.0e+3px;
  height: 1.0E-3px;
  height: 1.0E+3px;
}

At least some of them should be valid, so the validator is clearly missing something. Sublime Text is happy with the ones containing a ., which conforms to my understanding of the spec after reading it for a third time.

I don't quite understand why there's consternation about a week-old bug report. Particularly when the effect is just that the e is not highlighted. It's not interfering with the rest of the file, or even the rest of the line.