Is it possible to draw elements stacked on top of each other?

[Black-Maille]

Hi,

not sure if this is possible with a finite amount of effort, but is there a way to stack different elements on top of each other so they are both rendered?
I have added a crude drawing to illustrate what I would like to achieve:

• Have a linear progress bar just working as standalone
• Draw an overlaid icon or image on the left end of the progress bar
• Have the ability to change the icon (change from triangle to circle, swap fill colors)

Step 3 should not be too difficult, but step 2 seems to be impossible in NiceGUI or Quasar. Since I don't have experience with HTML/JS, I'm not sure if there is a way using Vue as a low-level solution.

Of course I could just put both elements side by side and be done with it, but layering would be nice.

In any case, thank you for your effort.

[evnchn]

Yes, this works today — it's just CSS layering, and there are two routes.

1. Nest the icon inside the progress bar. Quasar's QLinearProgress has a default slot for exactly this, so any element you nest under ui.linear_progress is drawn on top of it:

with ui.linear_progress(value=0.4, size='28px', show_value=False):
    ui.icon('change_history', color='white').classes('absolute-full flex items-center justify-start pl-1')

justify-start pins it to the left end (justify-center for the middle). Two gotchas: give size enough height for the icon, and pass show_value=False so the built-in percentage label doesn't sit in the same space.

2. Generic stacking, for any two elements — a relative parent with absolute children:

with ui.element().classes('relative w-64'):
    ui.linear_progress(value=0.4, size='28px', show_value=False)
    ui.icon('circle', color='red').classes('absolute left-1 top-1/2 -translate-y-1/2')

Step 3 is then just mutating the icon:

marker.name = 'circle'
marker.props('color=yellow')

All three, rendered:

[Black-Maille]

Thank you for the prompt answer, I will try route 2 on monday as I would like to keep the numerical display (seconds elapsed/remaining).

[Black-Maille]

Hi,
I managed to build a progress bar that I like, and for the most part I understand the parameters.
A bit thank you for that!
However, I cannot find documentation on 'absolute-full'.
To me it looks like a combination of absolute positioning and full width, but is that not redundant with flex?
Or do I misunderstand the functions of these two parameters?

Also, the command 'px' does not seem to do what I intended, namely limiting the width of the label to be narrower than the underlying progress bar.

Here is my full test code and the corresponding render:

with ui.element().classes('relative w-64'):
    with ui.linear_progress(value=0.6, size='28px', show_value=False):
        ui.label('fwjepfjepdjfsädfjpäwsfjg#sgejspogjoe').classes('absolute-full flex items-center justify-center text-black text-base')
    ui.icon('circle', color='green').classes('absolute left-1 top-1/2 -translate-y-1/2')
    ui.icon('o_circle', color='black').classes('absolute left-1 top-1/2 -translate-y-1/2')

Thank you!

[evnchn]

absolute-full is a Quasar class, not a NiceGUI one — which is why you won't find it in our docs. That's the generally useful thing here: the classes in your snippet come from three different systems, and NiceGUI documents only the third.

in your code	system	documented at
absolute-full	Quasar helper	quasar.dev/style/positioning
flex items-center justify-center, w-64	Tailwind utility	tailwindcss.com/docs
size='28px', show_value=False	NiceGUI / Quasar props	NiceGUI docs

1. absolute-full vs flex

Four lines of CSS — no display, no width:

.absolute-full { position: absolute; top: 0; right: 0; bottom: 0; left: 0; }

So read it as "absolute, pinned to all four edges", not "absolute + full width". The pure-Tailwind spelling is absolute inset-0 — identical down to the pixel, if you'd rather not mix the two systems.

Not redundant with flex, because they decide different things: absolute-full decides where the box goes (out of flow, overlaying the bar, filling it), flex items-center justify-center decides where the text sits inside that box. Drop the first and the label falls back into flow, behind the bar's own two absolute-full layers; drop the second and the text sits in the box's top-left corner.

2. The width

It did apply — your box really was 150px. But left: 0 + right: 0 + width is over-constrained, so CSS ignores right and the box snaps to the bar's left edge. mx-auto fixes it: auto margins absorb the slack instead of dropping an edge, so the box centres.

Second trap: text-overflow only applies to block containers, so truncate draws no ellipsis while flex is on the same element. Drop the flex classes and use leading-[28px] for the vertical centring:

ui.label('elapsed 12.3 s / remaining 30.0 s') \
    .classes('absolute-full w-[150px] mx-auto truncate text-center leading-[28px] text-black text-base')

Keep the text-base, by the way — QLinearProgress is sized via font-size (height: 1em), so a nested label without a text-size class inherits 28px text rather than 16px.

Measurements, and a height-independent variant

All measured in headless Chromium against NiceGUI main.

If you expect to change the bar's height, leading-[28px] has to be kept in sync with size. A wrapper avoids that by letting flex do the centring, with the width and truncate on a block child:

with ui.linear_progress(value=0.6, size='28px', show_value=False):
    with ui.element().classes('absolute-full flex items-center justify-center'):
        ui.label('elapsed 12.3 s / remaining 30.0 s').classes('w-[150px] truncate text-center text-black text-base')

Either way the principle is the same: absolute-full stays the full-size layer, and the width + truncate go on something that is a block. justify-start (plus e.g. pl-2) pins it to the left end instead — though note your two icons are at left-1 and drawn after the label, so a left-aligned label runs underneath them.

The CSS, from the bundle NiceGUI serves (nicegui/static/quasar.unimportant.css; Quasar 2.18.5 per package.json) — two rules, and that's the entire definition:

.absolute, .absolute-full, .absolute-center, /* …other absolute-* helpers… */ { position: absolute; }
.absolute-full, .fullscreen, .fixed-full { top: 0; right: 0; bottom: 0; left: 0; }

The bar's own layers, which a non-positioned label ends up beneath. All three are z-index: auto, so this is plain CSS painting order — positioned elements paint above non-positioned ones — not a stacking trick. The fill is opaque and hides the text; the track is 40% opaque, which is why the tail still glimmers through:

child of .q-linear-progress	position	opacity	background
q-linear-progress__track absolute-full	absolute	0.4	rgba(0, 0, 0, 0.26)
q-linear-progress__model absolute-full	absolute	1	rgb(88, 152, 212)
a label with no absolute-full	static	1	transparent

Geometry, getBoundingClientRect() on a 256px bar (w-64) with width set to 150px:

variant	width	offset from bar's left	centred?	ellipsis?
absolute-full w-[150px] truncate flex …	150px	0px	✗	✗ (display: flex)
absolute-full w-[150px] mx-auto truncate	150px	53px = (256−150)/2	✓	✓ (display: block)
absolute inset-0 w-[150px] mx-auto truncate	150px	53px	✓	✓ (Tailwind spelling)
absolute-full flex … › inner w-[150px] truncate	150px	53px	✓	✓

Text placement for question 1, measured with a Range over the label's contents — the text box, not the element box, which is bar-height and so centres trivially — on a size='60px' bar:

variant	text offset from bar's top-left	text centre vs bar centre
absolute-full only	2px, 0px	−18px, −76px
absolute-full flex items-center justify-center	20px, 76px	0px, 0px

Also checked, since it's the obvious worry with your original string: with a long unbreakable word, text-center and left-aligned truncation render identically (start visible, … at the end). text-align only matters once the text fits, so centring can't clip the beginning.

[Black-Maille]

Wow, talk about an in-depth reply! 👍

It took me several reads to dive through all the information, and the last section comparing widths and positions is still a bit above my head. But it could come in quite handy in the future, and I certainly appreciate it. :-)
I adopted your approach, nesting the label inside a neutral element, but set 'w-3/4' instead of a fixed 150 px.
I am still not quite sure where the 150 pixel value comes from, since it does not seem to correspond to any of the sizes I have defined. But that maybe goes too deep into the weeds ...
Btw, I did look up the Tailwind and Quasar documentation. However, from the combined documents, I got the impression that Quasar definitions are gathered in .props(), while Tailwind definitions go into .classes(). Apparently, I was mistaken.
So I only did a cursory search for 'absolute-full' in the Quasar docs.

In any case, thank you for the comprehensive answer, and I think this should help me build something nice and reasonably future-proof. If not, I know where to ask folks ... ;-)