I forgot to mention that an absolutely positioned element behaves differently with respect to height rules. But absolute positioning should usually be avoided as much or more than setting height in the first place. Let the rendering engine do the work rather than treating the layout like a manually designed desktop publishing exercise.
Regards, Adrien > On Nov 19, 2019 w47d323, at 12:48 PM, Adrien Monteleone > <adrien.montele...@lusfiber.net> wrote: > > > >> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam >> <christopher....@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
