Variable fonts support in spellcheck.

Actually this title is more apt.

I can't say that I agree with the wording.

Yes, these properties are used only by navigation so far. But even without navigation, it makes sense to add them since this progressive technology can be used by others.

I just would like to keep properties names in title.

Better?

Great! Thank you!

rohit.mns → made their first commit to this issue’s fork.

Not 100% sure in favor of this but think if it were to happen it should be in the drupal dictionary file.

I don't think so, the drupal dictionary contains drupal specific things. While I want to add global CSS properties.

In that case I think I'm a -1 for adding to the main dictionary file, just doesn't feel right.

Then perhaps it's worth considering why the dictionary throws exceptions for fairly popular properties that are fully supported by the core? I don't understand the purpose of the dictionary in this case

These properties are obviously not drupalisms.

Maybe someone else can pick it up

50/50 actually. If no one picks up on a month I’ll pivot back

No one has picked up in a month so lets see what core committers think. Know @quietone does a lot of work with the dictionary so she may be a good one.

In general, adding technical words to the dictionary makes sense. However, do we allow 'words' that are only used in a few files, or a sub system, or CSS or JS? An 'word' unique to a subsystem or language can be a spelling error in an English comment or in a variable, class or method name.

This change has such an example. If 'wdth' and 'wght' are added to the dictionary then those 'words' are available for use throughout core. But in the context of comments and naming variables, methods and classes, they are most likely misspellings of 'width' and 'weight'. So, I think this should not be done.

While reviewing this I learned that 'ital' is now the English dictionary. So, that could be removed and we will have to manually catch where 'ital' is a misspelling.

$ yarn cspell trace ital
...
ital * en_us*               node_modules/@cspell/dict-en_us/en_US.trie.gz

Shows that this is now in the English dictionary. So, this could be removed.

@quietone

I just ran through the existing words and I see an inconsistency in your comment

The dictionary has:

autop - possibly a misspelling of autopilot.
dflt - possibly a misspelling of default.
devel - possibly a misspelling of development.
delsp - possibly a misspelling of delete space.
denormalizable - technical term, but could be perceived as a misspelling.
dotenv - technical term, but could be a misspelling in other contexts.
dnumber - possibly a misspelling of number.
widthx - possibly a misspelling of width.
writeln - possibly a misspelling of write line.
xmlhttp - possibly a misspelling of XML HTTP.
yamls - possibly a misspelling of YAML (no plural).
zoomin - possibly a misspelling of zoom in.
zoomout - this may be a misspelling of zoom out.

But the most important question.
Why do pipelines crash when I write valid CSS?
Why the dictionary?
Shouldn't it just be optional in that case?

at least this needs to be added
https://www.npmjs.com/package/@cspell/dict-css

Do you want to open a ticket under cspell for this and postpone this one?

I don't know.

I don't have much time for contributing right now.

I thought that tickets like this are a normal way to treat these pipeline crashes.

Now I just want to understand why a normal css unit causes pipeline crashes.
Why should we add comments ignoring a normal css unit?
It's not a weird word but a documented property

Why do pipelines crash when I write valid CSS?
Is this core and/or contrib?

Yes, the dictionary is not consistent and is work in progress. Nearly every word in there is from the initial creation of the dictionary, so it has many, let's just say, technical words. We can't assume that because a technical word is in the dictionary that it was a deliberate choice or from the original created.

There are no guidelines for how to handle technical words. And I would like to make that happen. However, my attempts so far have not worked. If you want to chat about the overall approach, ping me sometime.

Is this core and/or contrib?

It doesn't really matter
For now, this is part of the experimental Navigation module. But further on, I have reason to believe that this will become global styles of the Drupal admin theme.
And I really don't like the presence of

/* cspell:ignore wght */

in CSS files, because

This is a direct alternative to font weight, that is, it will be used in almost any file.
This is a completely valid and documented CSS unit.

The CSS core developer does not know that the dictionary is unfinished and, frankly, should not know.
Checking the code against an unfinished dictionary and causing pipeline crashes in this case is another obstacle for novice developers, which simply should not exist.

Therefore, I propose either

1. Merge a new version of the merge request
Leaving at least
ital - we already know that this is OK
wght - for me, this is no different from dflt which are already in the dictionary

2. (Globally) Remove the requirement to check the dictionary. Leaving only notifications for the core committer that some words in the merge request do not match the dictionary. Thus, the decision that this is a spelling error or a dictionary flaw (as in my case) will be made on the spot before the commit

@finnsky, can you identify the words in dictionary.txt that are valid CSS words? That would help.

This now has out of scope formatting changes in CSS files.

Here's what we found with Github Copilot:
They are in CSS files

bgblue — refer to a blue background (background blue).
bgred — refer to a red background (background red).
clearfix — commonly used in CSS to fix float issues.
closethick — relate to the thickness of a border or element.
minusthick — relate to reducing thickness.
plusthick — relate to increasing thickness.
zoomin — relate to a zoom-in effect.
zoomout — relate to a zoom-out effect.
tabledrag — relate to tables and their styles.
tableselect — relate to selecting rows in tables.
tablesort — relate to sorting tables.
transferthick — relate to the thickness of a border or element.
twocol — relate to a two-column layout.
threecol — relate to a three-column layout.
strikethrough — relate to text with a strikethrough.
touchevents — relate to handling touch events.
titlebar — relate to headers of windows or blocks.
twistie — relate to collapsible/expandable UI elements.
extrasmall — relate to element sizes.
extraspace — relate to additional spacing between elements.