[Webkit-unassigned] [Bug 156684] rem in media queries should be calculated using font-size:initial, not root element font-size

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=156684

--- Comment #10 from Myles C. Maxfield <mmaxfield at apple.com> ---
(In reply to Myles C. Maxfield from comment #9)
> Hang on, computeNonCalcLengthDouble() is used for all style resolution, not
> just media queries. This is a situation where, if a media-query says "60rem"
> it refers to a different value than if an element says "60rem".
> 
> So we can't just modify computeNonCalcLengthDouble(). We have to set some
> state inside CSSToLengthConversionData which represents whether or not we
> are trying to calculate a media query or a regular style on an element.
> 
> Style::fontSizeForKeyword() is sensitive to the user's preferences, namely
> settings().defaultFixedFontSize() and settings().defaultFontSize(). Media
> queries probably should be sensitive to these preferences as well, which
> means we should use the logic inside Style::fontSizeForKeyword().
> 
> You're right about not having access to a document inside CSSPrimitiveValue,
> and this is desirable - individual CSS values shouldn't know what a whole
> Document is. Luckily, the CSSToLengthConversionData is created in
> MediaQueryEvaluator::evaluate() which has access to m_document. So we should
> interrogate m_document inside MediaQueryEvaluator::evaluate() and use our
> findings to set some new fields (which we will create) inside
> CSSToLengthConversionData. Then, computeNonCalcLengthDouble() can read those
> settings.
> 
> We should make sure that when we test this, we test all the relevant
> combinations of defaultFontSize(), defaultFixedFontSize(), media queries,
> and style on regular elements.
> 
> Does that help you understand this?

Oh, and we're going to have to refactor Style::fontSizeForKeyword() to make a version that doesn't accept a whole Document, but just accepts the things that it would have asked the document for.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180301/c5a9cf41/attachment-0001.html>