[GNC-dev] (no subject)

Tue Nov 19 13:48:32 EST 2019

> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam <christopher.lck at gmail.com> wrote:
> 
> Dear All
> 
> Maint branch includes recent changes to report whereby <!DOCTYPE html> is
> inserted at the top. This is to improve standards compliance.
> 
> The minor side effect right now is that it enforces standards-mode instead
> of quirks-mode in webkit (both unices and Windows) charts are squashed to
> 300px because of
> https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
> and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
> {height:95%} does the trick by expanding parent elements to 95% of
> viewport. Setting height to 100% would be fine except it causes scrollbars
> to appear unnecessarily. This fix works both in Unix (libwebkit2) and
> Windows (libwebkit1).
> 
> If anyone has better ideas how to fix this please let me know. If this
> change is unwanted we can revert to previous quirks-mode reports.

The solution and explanation is given both in that link as well as the further explanatory link contained therein: https://stackoverflow.com/a/31728799/3597276

The problem is the use of percentage which is relative to its parent element. But if the parent (all the way up the document tree to the root element, `html`) does not have a set height, then the value defaults to `auto` because there is nothing to calculate the percentage on.

The solution is to not use percentage.

If you need a relative rule, (as opposed to explicit units like `px` or `pt`) use Viewport Height, `vh`, thus set {height: 100vh}

That may not be what you want, however. You might just need a smaller percentage of the viewport, but any such value has a reference for calculation. (the viewport height is known by the browser and doesn’t rely on the document tree cascade. It can be changed by the user, however)

The reason that percentage ‘works’ in quirks-mode is because quirks-mode converts the percentage rule to a viewport height rule.

So I’d advocate for sticking with standards-mode and using the proper style declaration.

Note too, it is rare to need to set height. While there are some exceptions, needing to set height means something else was maybe done wrong somewhere. It is probably better to find and fix that error instead and let the rendering engine determine the height based on content.

> Additionally there's a recent change to re-enable negative numbers=red in
> reports; a side effect of this was border colour also becomes red. This is
> fixed by applying CSS rule "th,td {border-color:grey}" which could cause
> cause issues with users with different colour themes. Any further
> suggestions welcome.

Borders should not be affected by a rule for coloring negative numbers at all. That tells me the proper specificity is not being used in the CSS rule.

Fix the specificity targeting negative numbers instead and you won’t need to mess with border color at all.

Regards,
Adrien