1586556 - var() syntax is restrictive, DevTools doesn't help

Status: NEW

(DevTools :: Inspector: Rules, enhancement, P3)

Description

[Glenn Linderman]

Attachment: testcondtext.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Revised from this stackoverflow question: https://stackoverflow.com/questions/58253673/conditional-document-how-to-show-optional-parts-based-on-several-classes, revised file attached here.

Actual results:

The opacity didn't seem to react to the calc. DevTools didn't report that the syntax was bad. The syntax is bad.

Expected results:

I guess since Chrome acts the same, the syntax must be restrictive. The var and the following ( must not be separated by white space.

However, unlike other bad rules, DevTools doesn't indicate that this a bad statement in any way. I'm not sure how DevTools makes the decision about it being a bad statement: does it reparse the syntax, with a different parser? Or does it peek inside FF, and determine that the rule is being ignored? If the former, shame on it. If the latter, maybe it is peeking in the wrong place?

Comment 1

[Florencia Di Ciocco, NI to vbalducci]

Hi Glenn,

Thanks for taking the time of opening this bug. However this issue has already been pointed out on bug 1581911. Please do take a look at it. They are on their way to solving this issue.

Best regards, Flor.

Comment 2

[Axel Hecht [:Pike]]

Florencia, I think you picked the wrong bug number.

Comment 3

[Glenn Linderman]

I hope you are right, Flor, but I certainly couldn't see any connection with my bug and the one you referenced as duplicate. Thanks Axel for also noticing that.

Comment 4

[Florencia Di Ciocco, NI to vbalducci]

Hi Glenn,

Sorry, I read it again in more detail and I see my mistake. I was able to reproduce the bug on Windows 10 on the following versions:

Release 69.0.3 (64-bit), Nightly 71.0a1 (2019-10-08) (64-bit) and Beta 70.0b13 (64-bit).

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Comment 5

[Patrick Brosset <:pbro>]

Thanks for filing this. I made an even more reduced test case here:

data:text/html,<style>body {--color: var (--color2);--color2: red;color: var(--color);}</style>Hello

• Open this URL in Firefox
• Notice that text is not red as you expected
• Open the inspector
• Select the text in the page in the inspector
• The color property is not marked as invalid, it points to a variable
• The variable definition itself (--color) is not marked as invalid either

The problem is there is a space between var and ( which actually makes the --color custom property invalid. But DevTools does not show this like it normally does.

The reason for this is that DevTools does not attempt to do any sort of validation for custom properties, because by nature, those can contain any text and be used anywhere.
DevTools does not know where this custom property might be used, so has no way of knowing its final type, and therefore check its correctness.
In theory, it could run a search on the entire page to find places where this property is used, and validate based on that. In reality this would be very costly in terms of performance.

So, just like --color: rad; isn't invalid because we don't know if --color will be used as a color type value in the end, then --color: var (--color2) isn't invalid either because we don't know if this value will be used as a variable elsewhere either.

Comment 6

[Glenn Linderman]

Thanks for your investigation and analysis.

I realize that custom property values cannot be checked at the time of definition. I realize that the custom property value is perfectly valid for use, say, in a content: rule, even though it is invalid for other uses.

However, at the time the inspector is displaying rules that apply to a particular element, the browser itself is attempting to use rule, and fails to do so, because of the error.

I was hoping that at that time, it would be possible to determine, either by asking the browser, or analyzing the expansion of the custom property value in the context of the selected/inspected element, that the rule is valid or not. By focusing only on the currently selected element, the cost of searching all the places it might be used would be significantly reduced compared to an analysis of all the places it might be used (or even determining where those places are). The inspector is already determining what rules apply to the currently selected element, the added cost is determining which ones are actually valid for that element.