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.

@quietone what are you thoughts?

@finnsky, thanks for the list.

#25.1 wght - for me, this is no different from dflt which are already in the dictionary. This would support your argument if there is an issue that has decided that dflt should be in the dictionary. Since, 'dflt' is used in one file, it might make sense to add an ignore line to that file.

#25.2 I don't see how removing the requirement to check spelling would help issue workflow.

-

There is also the option of adding the CSS dictionary. Thinking on that I went back to the issue that added cspell to core. In that issue longwave expressed the same concern → that I had in #20. And since then a dictionary has not been added. So, the approach here of adding the words to the dictionary makes sense.

However, adding these words to the dictionary is no guarantee that the word will not be removed in the normal process of updating cspell or the dictionaries. If one of these words is no longer used in core it will be automatically be removed from the dictionary. Is that going to be a problem?

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

@oily, before rebasing, please read the comments. There is a pending question to be answered before any changes to the MR are made.

correct status

@quietone So revert the commit.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Resolved merge conflict.

I thought it was possible to use cspell in a 'context-aware' fashion. So if word is only used in css only, can the cspell syntax handle that?