Closed Bug 1357410 Opened 3 years ago Closed 3 years ago

Firefox successfully parses -webkit-calc (100vh + var (--some-variable)) but then doesn't honor it (because of how CSS Variables work)

Categories

(Core :: CSS Parsing and Computation, enhancement)

All
Other
enhancement
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: xla07764, Unassigned)

Details

(Whiteboard: [specification][type:bug])

Attachments

(3 files)

What did you do?
================
Write follow code:

:root {
 --cv-height: 56px;
}

.memo-comp1 {
height: calc(100vh - 5em);
height: -webkit-calc(100vh - 5em - 56px);
}

.memo-comp2 {
height: calc(100vh - 5em);
height: -webkit-calc(100vh - 5em - var(--cv-height));
}

What happened?
==============
In firefox it became below:

memo-comp1 --> height: calc(100vh - 5em);
memo-comp2 --> height: -webkit-calc(100vh - 5em - var(--cv-height)); --> Height is wrong


What should have happened?
==========================
memo-comp1 --> height: calc(100vh - 5em);
memo-comp2 --> height: calc(100vh - 5em);


Is there anything else we should know?
======================================
Not an MDN bug, moving over to Firefox

I've seen people recommend the generic rule is last in the list, like:

.memo-comp1 {
  height: -webkit-calc(100vh - 5em - 56px);
  height: calc(100vh - 5em);
}

.memo-comp2 {
  height: -webkit-calc(100vh - 5em - var(--cv-height));
  height: calc(100vh - 5em);
}

Do you have different results with a different order?
Component: API → Untriaged
Product: Mozilla Developer Network → Firefox
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Attached image sample for memo-comp1
Attached image sample for memo-comp2
Thanks for the message.

I can only read and write Osaka dialect.
Please forgive me for my poor English.

I understand the order.
I thought that firefox ignored -webkit-calc().

On andoroid I thought that I could run below with chrome and firefox with the same css.
(I only want chrome to reduce urlbar size 56px)

In chrome, it is displayed by the late-order -webkit-calc() value.
In firefox,
memo-comp1 is displayed as the calculated value of calc()
Memo-comp2 seems to fail, trying to compute with -webkit-calc().

Since the only difference between memo-comp1 and memo-comp2 is use of var().
I thought there was a problem there.

Now I have the following code.

:root {
 --cv-height: 56px;
}

.memo-comp2 {
height: -webkit-calc(100vh - 5em - var(--cv-height));
height:    -moz-calc(100vh - 5em);
}


Thank you.
https://hg.mozilla.org/integration/mozilla-inbound/rev/18f4ab471d1699f03d90a23bda5c94ae443b9908
Bug 1357410 follow-up sign remaining unsigned permission test xpis r=andym
https://hg.mozilla.org/mozilla-central/rev/18f4ab471d16
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
I don't believe this was the correct bug number.
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(aswan)
Resolution: FIXED → ---
Target Milestone: mozilla55 → ---
(In reply to xla07764@gmail.com from comment #4)
> I thought that firefox ignored -webkit-calc().

It does ignore it.  (However, I see how the devtools in attachment 8859568 [details] make it look like we recognize it.)

If you modify your original testcase to use "foo-bar" instead of "-webkit-calc", you'll see the same results (in Firefox as well as Chrome) -- the declaration with the var() expression is accepted and overrides the earlier declaration, even though it includes something unrecognized.

This is just a quirk with how CSS Variables work.  See this specific part of the CSS Variables spec:

  # If a property contains one or more var() functions,
  # and those functions are syntactically valid, the
  # entire property’s grammar must be assumed to be
  # valid at parse time.

This is why the bogus property value is being accepted here.  So, this is not a Firefox bug.
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → INVALID
Flags: needinfo?(aswan)
(In reply to Daniel Holbert [:dholbert] from comment #8)
> If you modify your original testcase to use "foo-bar" instead of
> "-webkit-calc", you'll see the same results (in Firefox as well as Chrome)
> -- the declaration with the var() expression is accepted and overrides the
> earlier declaration, even though it includes something unrecognized.

I've just attached a testcase to demonstrate this. In both Firefox and Chrome (and any browser with CSS Variables support), the text does not get a lime background, even though that seems like it's the last seemingly-valid declaration that would apply to that element.

This is counterintuitive, but it's just how CSS Variables work.
Summary: Do not invalidate -webkit-calc (100vh + var (--hoge)) → Firefox successfully parses -webkit-calc (100vh + var (--some-variable)) but then doesn't honor it (because of how CSS Variables work)
(In reply to Daniel Holbert [:dholbert] from comment #8)
> This is just a quirk with how CSS Variables work.  See this specific part of
> the CSS Variables spec:
> 
>   # If a property contains one or more var() functions,
>   # and those functions are syntactically valid, the
>   # entire property’s grammar must be assumed to be
>   # valid at parse time.
> 
> This is why the bogus property value is being accepted here.  So, this is
> not a Firefox bug.

I understand.

regards
You need to log in before you can comment on or make changes to this bug.