dpaste.org/Ag6tM that should be closer

have to get into windows so i can balance Deja Vu and Verdana

njsg:

if you still need to run ttree, it sounds like you need Template::Plugin::XML, which is not packaged

if you don't want to mess with a debian chroot, i just tried 'cpan -T Template::Plugin::XML' in an almalinux 9 chroot and 'sh bin/build' works

i also have a windows 10 vm and am running linux with mscorefonts2.sourceforge.net installed

there might be slight differences with freetype

oh ffs

figures

(verdana is available as an exe)

well a webfont is the solution but I think my dejavu webfont isn't right or is an older version.. need to check.. the issue is except for one place the fonts are defined as Verdana and sans

but adding a webfont for the bug i opened is beyond its scope..

IrisZzz:

i see

idealy with the font set to verdana or dejavu even without a webfont it should look like this when done.. the middle.. as the left is the template I am designing for the new add-ons site and right is currently what is out there

esblishing the height at 24px which can be used for menu items, the breadcrumb, or even a toolbar depending on what may be called for in the fture.. at 22 or strictly font/content height it was jarring going from front page to subpages and back it is why I opened the issue.. also I needed about 2 extra pixels lol

a 24px bar can accomidate 16px "toolbar buttons with icons"

guess I need to go to windows

ok with my revised css it looks dandy with 4px on verdana and 6px with dejavu sans

I don't want to add js to every page just to detect linux and alter 2px

ok.. so I can complete this bug I am gonna expand it slightly to do for body fonts Verdana, "DejaVu Sans", and sans and style to Verdana .. perhaos suggest in a later bug to change the fonts to Deja Vu Sans webfont

I have to consider this was designed in 2005/2006

so it isn't like one of my 2010s layouts

let alone my 2020s

The best birthday present, to contribute to the project I always wanted to in the ways I am able.

ah, happy birthday

thank you IrisZzz

I updated bug 1904084 but will redo the patch tomorrow.

mornings

I'm still not sure just going with a pixel size here is good, em and similar units are much preferred

min-height alleviates the problem, but will still cause a visible difference if the font size is larger

(and the height is in non-font-size-relative units)

s@height@min-&@

njsg: you can't do padding by em its not reasonable.. the height is padding plus font and the rest is filled with min height

and I have to have a minimum height because the site was designed 20 years ago and no content means no height

except the padding

dpaste.org/WmPqO/raw is essentually the revision

i need to make a patch

Hi ContributorTobin

it's early lol

how are you?

didn't sleep well

working on the wip branch till IanN_Away creates the beta branches for 2.53.19b1

frg_Away: are git formatted patches acceptable?

No problem. I reformat them for hg if needed

my hg skills are basically non-existant and its difficult to learn one thing while trying to accomplish another.. so for the minute at least i can use git cinnabar to clone and make patches that way.. tho if you give me the command to format em for hg I'll do that

make me a little script to do that in one shot :P

best way for me to learn hg is to create and manage an hg repo .. that's how I learned git

oh i may be able to format them for hg from git

nsITobin: the problem is that without text there is no height from font

hence min-height should more or less match that of the font so that the bar looks the same both with and without content

and for that you want something that can match the text dimensions more closely, those are the text-related units like em

now I'm probably overlooking some better way to do this, so far the best I've found was "guess what line-height might be and set (min-)height to that" for which one might just explicitly set line-height too to ensure it matches?

iirc with hg the most of it is to configure it to the defaults that match the usual patch style (more context, for example. then with mq you can just grab the patch file

njsg: just min-height is speciried now

you were right height didn't need to be there

i do swear it was required at some point

njsg: so what is the value of 4px in em and also 20px

also i literally cannot set min-height to anything but a whole em

in seamonkey

i need it to be min-height: 1.25 but seamonkey only responds to 1 or 2

or 0

padding with 0.25em works great tho

ContributorTobin: can't be computed agnostically, that's the reason to use em

padding's ok, it's the height, because it needs to take text into account

and seamonkey doesn't support decimal em values for height

so what should I do

I tested with 1.25em in min-height and it worked

I'm also wondering if, instead of trying to get this right without content, if :before can be applied only to the empty breadcrumbs div

njsg: did it work or is it just ignoring the decimal and it is set to 1

change it go from 1 1.25 1.50 2 it only changes on 1 and 2

no, it was different, 1 and 1.2 had different results from 1.25

what version?

2.53.17.1 I think'

also: #breadcrumbs:-moz-only-whitespace:before{content:"\00A0";}

then i guess it busted in 18.2

njsg: it doesn't work in other browsers

no idea how widespread that is

empty won't work cause of whitespace

and the new one the standardized version of moz-only-whitespace is unsupported by everyone

including mozilla

which is funny cause all they'd have to do is alias it

ashrooming stylo has that.. nsLayout does

layout/style

njsg: because of this bug either on linux or in x.18.2 min-height does NOT respond to anything but whole number em's on seamonkey

2em is 26px

of effective height

my target was 24

ok

ok this is weird.. i closed out reloaded the page reloaded devtools and it works now

njsg: could be a devtools bug

I have DOMi up to confirm.

okay I think I have it

padding-top: 0.37em; min-height: 1.8em and margin-bottom: 2.2em;

njsg: eh?

njsg: thank you for pushing me to use em.. HA!

I think I'd leave paddings and margins set to pixels, unless the space needs to scale with text

I can't say I haven't seen situations where something had to be refreshed or didn't work right away, but at least half of the time might have been PEBKAC. I think I also remember DOMi needing to refresh the interface somehow for changes to stick, but that was probably when I was styling DOMi with DOMi.

devtools wasn't apply for some reason.. the domi needing to be clicked off and clicked back on again I do instinctively

lol

njsg: the mozilla devtools code while more featureful for actual webdev than chrome's which is more setup for webAPP dev it isn't the greatest code around either.. it is why I favor DOMi more

i'll chalk it up to a devtools glitch that may not even be reproducable

which is NOT unpresicdented lol

i am glad it works and I can .. in a round about way do things in em now

and I have you to thank njsg

frg_Away: When you get a moment could push v2 patch to staging so can see it in the wild?

also njsg other margins are using em units

ContributorTobin done and active

height seems to be constant now

the ocean

that's why it is blue

lol

i mean the waves sure but I never connected the blue bar to the ocean..

until like last week

you know.. it just occured to me..

also

this page background preview.binaryoutcast.com/special on there.. that is a css recreation of the older Pale Moon banner background is damn well sampled from Mozilla colors.

like that menu

sidebar menu*

frg_Away: I messed with layout.css.devPixelsPerPx and it looks good at various values.. full page zoom works perfectly.. text only zooming works well as well .. except lol the logo starts sliding down the page into the bar

it did that before tho

I would call it as good a patch for this as the current design will allow

besides lol its been a while since I did anything reletively important, I am out of practice

be back

MattATobin: margins or padding in em don't look too big or small with font size changes?

one of the things to test in measurements is indeed resolution (i.e. dpi) but there's another scenario here which is changes in the font size only, say if somebody sets a bigger minimum font size for that type of font in that encoding

but note that I'm not saying there *is* an issue, just pointing out a different scenario to test

a quick test here on staging doesn't show anything that looks off

at least that I can see

njsg: its much easier to recreate a classic design with semi-modern html and css than it is to retrofit a 20 year old layout. Won't stop me, but it IS easier lol.

well the time to deal with that best would be if frg agrees to dejavu as a webfont so its just the same everywhere and if not LIKELY verdana is on the system.

or ian whomever makes these decisions.. I am just a contributor!

see

hi tonymec|away

also tomman

ContributorTobin I wonder if the logo header couldn't use some more pixles for height. Looks a bit cramped. What do you think?

frg literally adding margin-top: 1px; to #header makes it so there is the same gap between the top of the logo and the bottom.. anything more would require some .. work lol

and thus better

lol

a proper mod to allow flexability to header height and metrics for the wordmark would be to use a transparent wordmark and have the background of the wordmark just be a white gradient with opacity on each side and setting the wave bg background properties to stick to the bottom.. then you'd be able to change the header height all you want

but that is.. work

another enhancement imo is to lock the width of the sidebar menu cause 25% or whatever of 2k is a lot more than 1280 lol

as for flowing right forever i think that is part of the SeaMonkey charm so while I'd ordinarily be against it.. in this case not so much

plus it is more conducive to heavier text content

of course why they need to view webpages at 2650px wide i dunno but that is their choice I guess

frg_Away:

CaptainTobin I thought maybe some top px padding.

padding will cause the logo to shift down if the tiled background isn't stuck to the bottom it will misalign.. margin-top pushes the entire thing down a pixel

at 1280 wide the sidebar div registeres at 284px I would suggest locking it to 280px or the eq em value and setting the right div to fill the rest of the width

BinOC Sidebar with is traditionally 240px

not that that matters

other suggestion same width as the nordvpn ad

but this layout may require more work to do that and I don't wanna spend another day on css bits when I need to be writing php bits .. this just kinda grew out of getting a template ready for the add-ons site

but yeah the breadcrumb enhancement and 1 pixel margin-top just somehow instantly polishes the seamonkey site more than it actually should

I am a bit surprised actually

anyway sleep. Nighty night

rest well frg_Away