"cannot find formatter: rect"

[dangreen]

WARNING in Stylable: VisuallyHidden.st.css:10:8: cannot find formatter: rect

   8 |  height: 1px;
   9 |  overflow: hidden;
> 10 |  clip: rect(0 0 0 0);
     |        ^
  11 | }
  12 |

[idoros]

Native functions and formatters (custom functions) share the same context. And we test for formatters first, then fallback to a closed list of native functions, and this is just a bad message in case the name is not found in the list.

The reason rect() causes a warning, is probably because it's deprecated and not in our list (I think you should use clip-path: inset() instead).

Notice that this is just a warning, and Stylable still outputs the clip: rect() correctly.

That being said, I think we should modify the behavior of native/custom functions to to be like JSX with capital first letter for custom and remove the native white-list altogether...

[brucelawson]

I agree it's a bad error message; should be clear that it's looking in custom formatters then native, not found anything, but output it anyway. (Not sure it should output it anyway - doesn't that break our promise of catching errors before production?)

[tomrav]

I agree the error message could benefit from being more verbose.

The idea to use capital letters to signify custom vs native feels slightly too magical to me.
Would this still be a concern when we introduce a registration mechanism for formatters/mixins?

[brucelawson]

Perhaps in developer mode. we should run the end CSS through the official validator )https://github.com/w3c/css-validator) to alert developers of deprecated/ non-standard CSS?

[idoros]

Not sure it should output it anyway - doesn't that break our promise of catching errors before production?

I think being tolerant here is the expected behavior. Stylable doesn't know what to do with the syntax, so it leaves it to CSS, which is tolerant as well and outputs a report with potential warnings (that might need an optional configuration).

capital letters to signify custom vs native

This should be taken out to a separate discussion

[brucelawson]

I think being tolerant here is the expected behavior.

• Good Point, Well Made. Agree. But nicer error message PLZ