CSS hardcoded column width in UI file view
(1) By Joel Dueck (joeld) on 2020-01-29 01:41:22 [link] [source]
I’m woking on a skin in my repo. Currently when I browse to /dir?ci=tip
, the files are arranged in columns that are too narrow for my font, and I’d like to adjust them.
However, the column width info is inlined into the HTML, and the markup structure makes it difficult to overrride. I’m talking about the line <div class="columns" style="columns: 19ex 19;">
below:
<div class="content"><span id="debugMsg"></span>
<h2>Files of check-in [<a href="vinfo?name=8bd52721dd066a31">8bd52721</a>]
in the top-level directory
</h2>
<div class="columns" style="columns: 19ex 19;">
<ul class="browser">
<li class="dir"><a href="/code/draft1/dir?ci=8bd52721dd066a31&name=.fossil-settings">.fossil-settings</a></li>
... etc.
The best way I could devise to override this in my skin would be to use .content > .columns
with an !important
flag, but this would affect everywhere that .content
is a direct descendant of .columns
, not just the file browsing view. That doesn’t seem like a good idea for me.
Would it not be better to give the surrounding div an additional class (or an ID), and put the styling in the CSS file?
Fossil (2.111 / cc86de732a)
(2) By TomaszDrozdz on 2020-01-29 08:30:18 in reply to 1 [link] [source]
Maybe You could use JS to add Your extra class, div, etc to accomplish that ?
(3) By Stephan Beal (stephan) on 2020-01-29 09:39:56 in reply to 2 [link] [source]
He could, but having in CSS would be the better approach.
Requiring it in the skin's CSS for proper layout would, however, require that all clients using a non-default/modified skin update their skins, though. :/
The values seen in the HTML are calculated based on the number of files and the longest name in the list, so they're not something we can simply inject into CSS :/.
i locally changed the style to columns: auto auto
, but ended up with only a single column. Likewise, with columns: auto N
, where N is the calculated number of columns, the layout got mangled (many columns overlapping).
(4) By Joel Dueck (joeld) on 2020-01-29 13:37:05 in reply to 3 [source]
If the div had an additional class — maybe files
, as in <div class="files columns" style="columns: 19ex 19;">
— then I’d be able to select it directly and use !important
to override the columns attribute.
Side note, I’m curious why Fossil is using ex
units here to specify a width? ex
is the x-height of a font; surely em
would correlate more closely with the width of the filename?
(5.1) By Stephan Beal (stephan) on 2020-01-29 14:14:00 edited from 5.0 in reply to 4 [link] [source]
If the div had an additional class — maybe files,
That sounds reasonable. Done: https://fossil-scm.org/home/info/374ca0c007974d03
Side note, I’m curious why Fossil is using ex units here to specify a width?
i wondered the same and experimented with changing that, but it causes fewer columns to be generated and each one is wider. i also tried using percent values, but (somewhat surprisingly) that had no useful effect, as if columns style can't work with those (my searches say they can, but Firefox's dev tools say no).
Edit: i just changed that style to use auto
as its second value. Previously it was setting that to the number of entries in the list, which is a semantic mismatch for that CSS property, which wants a number of columns.
(6) By Joel Dueck (joeld) on 2020-01-29 15:54:34 in reply to 5.1 [link] [source]
That sounds reasonable. Done
Thank you!
I wondered the same and experimented with changing that, but it causes fewer columns to be generated and each one is wider.
Yes, 1em is always going to be larger than 1ex, though the ratio varies depending on the font.
The biggest reason the old behavior didn't work for me is that I’m using a fixed-width font, so the filenames are going to be much wider than they would in the default proportional font. Fossil is not reasonably going to be able to adjust for this of course.