How to simplify styling?

[rodja]

While it's great to have Tailwind and Quasar classes at hand to do all kinds of styling. It's quite hard to discover. If one is not working regularly with these libs, constant documentation lookup can not be avoided.

Maybe we find a nice API to make styling more discoverable. Here some ideas to get started:

💡 Idea 1: "Format Property"

My first Idea was a format property wich would return a Format object. This can then be used in a builder pattern like this:

ui.label('my headline').format.font-medium.text_4xl.margin_top(0).margin_bottom(2).text_blue_600

One disadvantage would be the huge number of properties and functions of the Format object. Maybe it's to much to be helpful.
To reduce the amount of suggestions, we could provide a tailwind, and a quasar property instead of format. Another trick may be to introduce sub objects like text_color which then provide blue_600 and the like.

Another problem with this approach may be that styling can not easily be shared between elements.

💡 Idea 2: "Operator Overloading"

It feels strange at first, but utilising operators could be nice. The inspiration comes from the / operator in pathlib. Applied to styling it could look like this:

from nicegui import ui, tailwind, quasar

headline = tailwind.font-medium.text_4xl.margin_top(0).margin_bottom(2).text_blue_600
ui.label('my headline') + headline
ui.button('press me') + quasar.button.rounded.flat + tailwind.margin_top(4)

[rodja]

It would also be great to use more self explaining names. For example "modal" instead of "persistent" (see #132).

[rodja]

If the + operator is not favoured, we could also use a function like apply:

💡 Idea 3: "Apply"

ui.label().apply(tailwind.margin_top(4).text_blue_600)

[morningstarsabrina]

I think the apply function is a great idea

[smojef]

Interesting discussion! Here are a few thoughts and observed pain points:

• Yes, discovery of classes is painful at first because we need to understand the frameworks.
• We need the those web references to be always open and we are often seeking for recipe to common styling problems.
• It is not only for the class names, but to understand the various layout concepts and strategies.
• We often dig in Chrome inspector to understand why our component is not displayed like we want (how to align right).
• I like the concept of chaining properties with dots to provide autocompletion and minimize typing.
• I like that the current classes string is very compact in the code.
• I often use transparency, such as bg-slate-400/10. How to handle double digit?
• I kind of prefer a shorter ui.card().cls('shadow-lg p-4 bg-slate-400/10') over a longer ui.card().apply(tailwind.shadow_lg.padding_4.bg_slate_400(10))
• But it could end up shorter, like ui.card().apply(tw.shadow_lg.p_4.bg_slate_400, qs.square.flat.bordered).
• But the goal should be to minimize the need for repeated styling, so then the length will be less a concern.
• Autocomplete could be helpful to complete a w- class when we don't remember the options (what's below 96?).
• Tooltip (docstring) on styling properties could be helpful to understand what it does (for those that don't understand CSS and HTML).
• What I would really want is an easy way of having common layouts and visual patterns without having to dig in Quasar and Tailwind.
• For instance, if I use a ui.expandable with an icon, it was painful to get the same look (and spacing) of icon and text (without the expandable) elsewhere. It was also painful to style the expandable header separately from the content.
• It was painful to create a nice header on a card with an emphasis background that works well on dark and light modes.
• Once I found a recipe, I am usually looking for a way of reusing it without typing long class strings.
• It could be nice to do big_card = [tw.shadow_lg.p_4.w_96, qs.square.bordered] and then ui.card().apply(big_card) for quick custom stlying.
• I would like a gallery of visual styles and examples, easy to search and browse, to find which recipe to apply.
• I would like various nice and trending themes available out of the box so that I don't have to mess with styling when I don't want a boring white page.
• I would like a method like BeautifulSoup CSS selector to quickly target multiple elements (from layout or parent element), then I could .apply() to them at once.

That's what I had in mind so far. Hope this helps ;-)

[smojef]

Other thoughts:

• How to handle hover: and such?
• For complex classes we could have a text method: .apply(tw.p_4.text_lg.t('hover:bg-slate-400/25 pr-[16px]'))
• To simplify styling of components that have multiple parts, we could do:

with ui.card().apply(tw.text_normal, qs.flat) as e:  # general styling
    e.header.apply(tw.text_h6)  # styling of header
    # Content goes here

• An operator like + would be a very compact alternative, without the need for a closing parenthesis. However the lack of assignment may be confusing. Would that modify the header?

with ui.card()+tw.text_normal+qs.flat as e:  # general styling
    e.header+tw.text_h6  # styling of header?
    # Content goes here

• What about <<? It suggests something applied to the left operand:

with ui.card()<<tw.text_normal<<qs.flat as e:  # general styling
    e.header<<tw.text_h6  # styling of header!
    # Content goes here

[smojef]

• It could be really convenient to have autocomplete for icon names as well: icons.settings.

[rodja]

Thanks for your thoughtful, in depth analysis. I'll try to summarize all high level requirements we have got so far. Ordered by priority. This is open to discussion, of course. Please point out if I missed something or you want to rearrange the priority:

1. As a developer not familiar with the web technologies, I want an easy way to discover and understand style, layout and props.
2. As a software architect, I want to reuse once defined styles and layout specifications.
3. As a Python developer, I want the API to be unsurprising (eg. no magic involved, just pure Python)
4. As a developer focused on efficiency, I want the methods to be short, but readable.

In my opinion requirements like pre-configured themes, galleries and maybe something like nicegui-fiddle (analog to js-fiddle) is out of scope for this discussion.

After we agree on the main requirements I may get easier to find the right API...

[smojef]

Yes, exactly!

For 1., I would emphasis that understanding layout is way more complex than props and style.

• It is really easy to figure out how to put text in bold, change color, add a shadow or change the padding.
  • It only gets tricky when we want to pick colors that are good for both light and dark themes.
  • Built-in color codes that would automatically invert in dark mode could help here.
• But it is really painful to figure out all layout and positioning issues, such as:
  • How does sizing behaves?
  • Will elements stretch-up to the parent or will elements make the parent bigger?
  • What will happen when the browser window is resized?
  • How to organize elements visually for both large screens and small screens?
  • How to get consistent positioning of elements (icons, headers, labels, input fields, and buttons) within cards or other containers to achieve a nice GUI?
  • How to have containers of equal sizes?
  • This requires to learn Tailwind and underlying HTML layout engines

If developers can find discoverable answers to some of these questions, it might ease the learning curve!

[rodja]

💡 Idea 4: "Builder Pattern for Looks"

I created the branch https://github.com/zauberzeug/nicegui/tree/looks where I made some first experiments with a possible API:

nicegui/looks_demo.py

Lines 1 to 23 in a3b3f48

	#!/usr/bin/env python3
	from nicegui import ButtonLooks, Looks, ui
	shared = Looks().width.full().background.secondary()
	with ui.row().looks.add(shared).padding.y_axis.small().align.main_axis.center().element:
	for i in range(5):
	with ui.card():
	ui.label(str(i))
	button_looks = ButtonLooks().rounded().background.teal(0.9)
	hover = Looks().text.gray(0.6)
	with ui.row().looks.add(shared).height.fixed.twenty().background.grey(0.4).align.main_axis.evenly().align.cross_axis.center().element:
	ui.button('12').looks.square().width.fixed.twelve().add(button_looks)
	ui.button('64').looks.width.fixed.sixty_four().add(button_looks).height.fractional.two_thirds()
	ui.button('1/6').looks.width.fractional.one_sixth().add(button_looks).on_hover(hover)
	with ui.row().looks.add(shared).gap.none().element:
	ui.image('https://picsum.photos/id/29/640/360').looks.width.fractional.one_half()
	ui.image('https://picsum.photos/id/565/640/360').looks.width.fractional.one_half()
	ui.run()

Everything in this approach is discussable. Please feel free to provide feedback and suggestions. I've already some remarks of my one:

• I'm not 100% sure "Looks" is the best word. "Appearance" would be better, but is too long. Maybe "Layout"?
• I started with very short names like p for padding, w for width and bg for background, but found it not "nice" enough in the end. Too cryptic; explorability before efficiency.
• I think we do not need to expose any .style values
• Many thinks like width/height are not available in Quasar, therefore I decided to mainly use Tailwind classes; but these are sometimes not intuitive; therefore the API translates gap.small() into gap-2 and gap.medium() into gap-4 to give a more rigid framework than Tailwind itself.
• By using a property .looks instead of .apply(Looks()...) I could not only shorten the amount of typing but also return derived versions like ButtonLooks which have additional commands to style buttons (via Quasar props).
• The builder-pattern implementation of Looks enforces that derived commands must come before generic ones. ButtonLooks().rounded().background.teal(0.9) has auto-completion, but ButtonLooks().background.teal(0.9) only returns Looks and the suggestion for rounded() is lost. Not a big problem in my opinion. Maybe even enhances readability when a certain amount of order is enforced...
• I could not get the hover to work; I think the concept is quite nice: providing an on_*(Look()) for special states like breaks, hover, dark etc. But we need it to work with Quasar/Tailwind....

[rodja]

Where does one aspect begin and where does it end?

@falkoschindler I used properties to step deeper into one aspect (eg return a Topic class) and methods to complete the aspecg (eg. return the Look again): padding.y_axis.small().align.main_axis.center(). Behind the brackets would also be the logical breaking point to start a new line.

[morningstarsabrina]

Although its very functional and easy to use because of autocomplete feature. however I found it too hard to read

[falkoschindler]

In order to keep an overview I updated previous comments and added markers for easier reference of proposed ideas. And I've got another one, a bit contrary to the builder patterns so far:

💡 Idea 5: "Literal Keyword Arguments"

Although I'm a fan of the builder pattern for creating user interfaces, it can get quite lengthy. And I personally find @rodja's idea 4 a bit difficult to read: Where does one aspect begin and where does it end?

Therefore I thought about making good old strings more accessible and discoverable:

Color = Literal['red', 'green', 'blue']
Gap = Literal['small', 'medium', 'large']

def look(*,
         color: Color = ...,
         background_color: Color = ...,
         gap: Gap = ...,
         width_px: float = ...,
         width_rem: float = ...,
         width_percent: float = ...):
    ...

look(color='blue', background_color='blue', gap='large', width_percent=50)

Advantages:

• I like the clean structure: key-value, that's it.
• You get auto-suggestion for both key and value:

[rodja]

Nice! The main drawback would be that nesting is not so easy. With the builder pattern you can write height.fixed.twenty() instead of height = '20'. Nesting allows for smaller option space eg. you can decide if you want fixed sizes or fractionals to the parent container and not get a huge list. Also I wonder how to add documentation for example "gap" to the autocompletion.

[falkoschindler]

Well, I thought we might not need nesting. But I'm not sure.
And I don't know how to add modifiers like dark: or hover:.
And although the API is easily extendible to arbitrary strings with Union[Color, str], this kills the auto-suggestion because the resulting type is just a str. Here is a related discussion (TypeScript, but I think the problem is the same in Python).

[falkoschindler]

@rodja After adding a docstring we get some kind of documentation from the IDE. Not great, but better than nothing.

[morningstarsabrina]

I really like this simple and functional

[falkoschindler]

With the @overload decorator from the typing module we could even combine it with the existing style method (similar for props, I guess):

@overload
def style(*, color: Color = ..., background_color: Color = ..., gap: Gap = ..., width_px: float = ..., width_rem: float = ..., width_percent: float = ...) -> None:
    ...

@overload
def style(add: Optional[str] = None, *, remove: Optional[str] = None, replace: Optional[str] = None) -> None:
    ...

def style(*args, **kwargs) -> None:
    ... # actual implementation

[smojef]

Here is how I see the main approches to the problem:

1. nicegui creates its own API and hides the underlying ones. Then it must provide extensive documentation, examples and knowledge base. Ex..width.fixed.twelve() is harder to relate to Tailwind and is really long compared to .w_12.
2. nicegui exposes the underlying frameworks, and leverage their documentation. It may requires a deeper learning curve at first but there are plenty of examples in the web. It relates to what we see in the inspecror. Ex. 'w-12' or .w_12 for discovery.
3. Like option 2, but by adding some additional shortcut helpers for common layouts or styles, building on top of the underlying frameworks (instead of hiding them). Maybe looking at the source of those helpers could reveal how the underlying frameworks are used and help the learning process. Maybe it could be methods to apply default styling to elements, or containers with default layouts (expand width and align children right). Many options are possible. The idea is to provide shortcuts to start quickly, but still expose the frameworks for precise customization as we grow.

[falkoschindler]

Good summary.
I guess the current brainstorming for possible APIs falls under (1) or (2). Making already existing styling options discoverable seems worthwhile to me. But we'll see where it goes. We're still undecided whether to change anything at all.
(3) is a bit harder to approach. Do you have a concrete example in mind? What could such a helper provide? And how would it be used?

[rodja]

Indeed, very to the point @smojef. By combining the builder pattern with literals, 1. and 2. are virtually the same from a technical point of view. As you said the main difference between them is the decision on how to present the options. @falkoschindler proposed a way to implement 2 in Idea 6. Taking this into account I sumarized an approach to 1. in Idea 7 concluding with an explanation why we may need both.

[falkoschindler]

💡 Idea 6: "Builder Pattern with Literal Keyword Arguments to Access Styles, Classes and Props"

What about a combination of idea 4 and 5:

Color = Literal['red', 'green', 'blue']
Gap = Literal['small', 'medium', 'large']

class Style:
    def color(self, color: Color) -> 'Style':
        return self

    def background_color(self, color: Color) -> 'Style':
        return self

    def gap(self, name: Gap = ..., *, px: float = ..., percent: float = ...) -> 'Style':
        return self

style = Style()
style.color('red').background_color('blue').gap(px=2)

This divides the option space into separate methods like (4), but might be shorter and easier to read. "Literal keyword arguments" (5) provide auto-completion for pre-defined strings. And we still have multiple options for, e.g., gap dimensions: literal name, px or percent. But it's all in one method, thus visually easier to grasp.

And having single methods per aspect allows overloading them, e.g. to support a pre-defined color name or any other arbitrary string. In contrast to using Union[Color, str] this preserves auto-completion for pre-defined strings:

    @overload
    def color(self, color: Color) -> 'Style':
        ...
    def color(self, color: str) -> 'Style':
        return self

[rodja]

That's very interesting. But I could not directly find a way to incorporate it into my branch (which is now called "layout_builder").

[rodja]

Well... I take back my last comment. Ist fairly easy. Unfortunately does not reap great benefits for aspects like gap: .gap('none') is even a bit longer than .gap.none(). And contains more "special characters". And the implementation needs quite a few if-statements:

Gap = Literal['small', 'medium', 'large', 'none']

class Layout:
    ...
 
    def gap(self, name: Gap = ..., *, px: float = ...) -> Layout:
        '''Gap between children'''
        if name is 'small':
            self._classes.append('gap-2')
        elif name is 'medium':
            self._classes.append('gap-4')
        elif name is 'large':
            self._classes.append('gap-8')
        elif name is 'none':
            self._classes.append('gap-0')
        elif px is not ...:
            self._classes.append(f'gap-{px}')
        return self

But in cases where multiple things need to be set for one aspect it's way shorter: .size(width='64', height='2/3') vs width.fixed.sixty_four().height.fractional.two_thirds(). The main downside would be the huge amount of options cramped into the width/height parameters. We could provide separate parameters for fractionals and fixed values: .size(fixed_width='64', fractional_height='2/3'). But this is a bit unintuitive because you should not use fractional_width and fixed_width in the same method call.

[falkoschindler]

@rodja I haven't studied your implementation, yet. Instead I spent some time with a standalone demo and fiddling around with what the API could look like. One result is here:
nicegui-style-demo-1.py
An improved approach gets rid of all the repeated methods by introducing another layer of "style properties":
nicegui-style-demo-2.py
Both integrate well with the existing .style() method and provide auto-completion at every step (finding a style property, finding an overload, finding a predefined literal string value).

[rodja]

Wow. That is incredible. Do you think the same can be done for .classes() and .props()?

[morningstarsabrina]

I tried nicegui-style-demo-2.py its great and very easy thanks to auto-completion

[rodja]

💡 Idea 7: "Layout Builder"

When taking Idea 6: "Builder Pattern with Literal Keyword Arguments to Access Styles, Classes and Props" to improve Idea 4: "Builder Pattern for Looks" we get a shorter, more readable API. While Idea 6 exposes the underlying styles API (and probably could also expose props and classes in a similar way), the here proposed "Layout Builder" deviates from Quasar/Tailwind/CSS to provide a simpler, more accessible API for those who do not know or want to use all the subtle details of web development. Thanks to @smojef who made these different approaches clear. I experimented with an implementation of such a system on the branch layout_builder. But it's far from complete. There are some inconsistencies and lots of decisions to be made. If we go forward with it. Here are some example on how specific aspects could look like in such an API:

ui.icon('star').layout.color('yellow', '8').size('medium').align.center()

Here, color and size are props on an Icon and hence are only available for IconLayouts, while align.center() adds the class m-xa-auto and works on any element.

with ui.row().layout.align.children(main_axis='evenly', cross_axis='center'):
    ...

For groups the align property also provides the option to arrange its children. Internally quasar-classes justify-* and items-* are used.

with ui.layout().row().size(width='2/3`):
    ...

The element ui.row() adds the classes row items-start gap-4 to a div tag. By allowing the Layout class to be used in contexts, it is not only shorter than with ui.row().layout.size(width='2/3).elementbut also makes it possible to not at the gap by default. This would be helpful when providing an API for the [column classescol-*` from Quasar](https://quasar.dev/layout/grid/introduction-to-flexbox#distribution-of-size). These currently do not work correctly because the Tailwind-gap class adds to the overall with and hence braking the Quasar computation.

The above snippets are just examples on what could be done. Overall this will be a huge undertaking. Not only in writing the code, but also documentation. Maybe it can be build out in stages (postponing grids, tables, cards). In my opinion it's not either "Idea 6" or "Idea 7". If Idea 6 really works for props and classes too, we should definitely implement it. The benefits are obvious and the existing implementation of NiceGUI is not altered. But I feel it does not come true on the requirement "As a developer not familiar with the web technologies, I want an easy way to discover and understand style, layout and props." For this, we would need something like the here proposed Layout Builder. What do you think?

[smojef]

@rodja I like the general idea of having simple methods to deal with alignment of children (or self relative to parent), assuming the auto-complete would give meaningful suggestions.

Short story: during a meeting today, instead of creating a wireframe in Figma, I was able to create a quick layout with nicegui in a few lines. I did so without opening any reference, until the point where I wanted a label aligned to the right within a card (what is the quickest way to do that already?). If VS Code had been able to autocomplete suggestions for ui.label().align, it would have been great! But the momentum got broken. I had to open Tailwind docs, searching for 'right' didn't help, clicking and scrolling through all nodes in the tree until I find a visual example that might apply. I ended up using justify-between on the parent ui.row() because I had only 2 elements. This single search took almost the same time as creating the remaining of the entire layout (the later being the good thing about nicegui!).

I also like the concept of positive and negative colors (assuming it would deal properly with dark mode). Is there a current equivalent?

[rodja]

having simple methods to deal with alignment of children (or self relative to parent), assuming the auto-complete would give meaningful suggestions

Thats exactly the goal.

I wanted a label aligned to the right within a card

I think "margin-left set to auto" is quite short:

with ui.card().classes('w-96'):
    ui.label('right aligned').classes('q-ml-auto')

Thats not "nice". With the Layout Builder it would be autocomplete every step to:

ui.label('right aligned').layout.align.right()

I also like the concept of positive and negative colors

Setting and using Quasars brand colors is already implemented in NiceGUI: https://nicegui.io/reference#color_theming. But the documentation is a bit shallow. We currently just link to Quasar. That must be improved. For me the documentation was not clear on how to define these for darkmode. But because our ui.color can change the colors on the fly, you can set different colors when switching to dark mode.

[smojef]

q-ml-auto
Funny! I just learned that we can also use Quasar classes. I was only searching Tailwind. I also learned that the concept of auto margins existed. I now see that Tailwind also has ml-auto, but the power of the auto value is not illustrated visually in their docs. I am actually surprised by this choice for .align.right() in the case where I would have 2 elements to align right. Because of this choice, I now understand that only the first element should be aligned right and the second one would follow. But if the attribute was set on both, the first one would probably become centered instead. Not an easy task!

Oh and forget about the colors, I was thinking in shades of gray ;-)

[rodja]

But if the attribute was set on both, the first one would probably become centered instead. Not an easy task!

Indeed. This kind of unintuitive side-effects can not entirely be avoided. I like to refer to Joel's law of leaky abstractions. The documentation of the Layout Builder should contain infos on how a particular statement like .align.right() is achieved under the hood. So when things break, the user can figure out where the abstraction is going down the drain and figure out what to do about it.

[falkoschindler]

I personally try to stick to Tailwind classes. So I would use ml-auto rather than q-ml-auto in order to avoid mixing both libraries. When using colors, mixing Quasar and Tailwind can bite you, e.g. dark:text-red-400 won't affect a Quasar color text-red.

By the way: Margin "auto" is originally a CSS thing. Tailwind is just providing a class for it, but don't seem to care documenting it prominently.

[Diegiwg]

I created a class that implements all the properties of Tailwind's Typography system, experimenting with what a Styling constructor would look like.

GIST with code: https://gist.github.com/Diegiwg/f76d0cebb576185ad3a6caabd9f0e0df

To use:

btn = (
    Typography(ui.button("Test"))
    .text_align("center")
    .font_weight("bold")
    .text_transform("uppercase")
    .element
)

label = (
    Typography(ui.label("Test"))
    .font_family("mono")
    .font_size("4xl")
    .font_weight("bold")
    .text_color("neutral-700")
    .font_smoothing("antialiased")
    .element
)

(
Typography(ui.label("No Save Reference"))
	.font_weight("bold")
	.text_color("teal-600")
)

def my_label(text: str):
    return (
        Typography(ui.label(text))
        .text_align("center")
        .font_weight("bold")
        .text_transform("uppercase")
        .text_color("yellow-500")
        .text_decoration("underline")
        .text_decoration_color("zinc-700")
        .element
    )

• If you don't need to save the reference, you don't need .element at the end.
• All values ​​were mapped to Literal[ ], then to autocompletion in the IDE (vscode).

[falkoschindler]

The "style" branch shows a first example on how to integrate a separate Style class with the existing Element:
https://github.com/zauberzeug/nicegui/compare/style

[Diegiwg]

First, I am very happy with your reaction. It gets me excited, to try to do more stuff to the community.

I would love to continue the work, however, understanding the size of the project (NiceGUI), I would not want to be responsible for incorporating this implement into the framework.

I would be very happy if you took what I did, improved it, and put it into production in this beautiful project, which is NiceGUI.

As far as I'm concerned, you can start implementing it now, I don't intend to open a PR. I prefer it to be completely in your control.

[falkoschindler]

Ok, sounds great!
However, we would really like to have you listed as an official contributor on the NiceGUI GitHub page. This requires at least one commit from you in our repository. Therefore I'd like to suggest that you create a PR with your generator added to the main directory. (There's no rush, it's Friday night here anyway.)

[Diegiwg]

Cool, I'll do it the PR today when I get home from work (here in Brazil, I don't know if it will still be today for you).

And thanks for the attention of insisting on the PR.

[Diegiwg]

Ok, sounds great! However, we would really like to have you listed as an official contributor on the NiceGUI GitHub page. This requires at least one commit from you in our repository. Therefore I'd like to suggest that you create a PR with your generator added to the main directory. (There's no rush, it's Friday night here anyway.)

As requested, I opened a PR, and left it free to be modified by the project owners: #362

[rodja]

I converted the Layout Builder branch (Idea 7) into the draft pull request #364. I think we should further discuss the specifics of a possible Layout Builder implementation there.

[ItsCubeTime]

Personally Im a big fan of writing css like element.style(add="") on everything. I hope this request wont hurt that ability in any way.

[rodja]

We will definitely keep the .style(...) and .classes(...) builder functions. Simplifying layout will not cover 100% of the cases. NiceGUI wants to be as simple as possible for standard cases while still providing all the configuration ability for special cases and requirements.

[falkoschindler]

After implementing the new .tailwind API and starting the Layout Builder PR #364, I'd like to close this discussion and start a new one related to specific subtopics that might come up.

[rodja]

Ok for me.

[wgong]

Thank you for this super NICE web framework!
has @Diegiwg PR merged into main branch or when will it be released?
Currently on NiceGui 1.3.13, did not see Typography, Sizing, Backgrounds mentioned anywhere while going thru https://nicegui.io/documentation#styling,

[rodja]

Yes, every element has the .tailwind property. See PR #362 and https://nicegui.io/documentation#tailwind_css.

[wgong]

@rodja Thank you for quick reply, I tried it in VSCode which autocompletes both key and value. Awesome feature!

As a newbie, I am also impressed by how NiceGui team brainstormed on various options and converged to an optimal solution quickly. This PR feature definitely lowered my barrier to styling.

[rodja]

I am also impressed by how NiceGui team brainstormed on various options and converged to an optimal solution quickly

Thanks! @falkoschindler will have a talk about this at PyCon Ireland this November 😀

[wgong]

Please share the talk recording after the conference, would love to watch it

…

On Mon, Sep 18, 2023, 1:13 AM Rodja Trappe ***@***.***> wrote: I am also impressed by how NiceGui team brainstormed on various options and converged to an optimal solution quickly Thanks! @falkoschindler <https://github.com/falkoschindler> will have a talk about this at PyCon Ireland this November 😀 — Reply to this email directly, view it on GitHub <#117 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQRSC366BVFENB62CDXD3X27KBLANCNFSM6AAAAAARAVM6VE> . You are receiving this because you commented.Message ID: ***@***.***>

[WolfgangFahl]

There are some defaults that might need to be changed. E.g. a ui.html element currently doesn't show links as blue / underlined without styling it:

{
    color: blue;
    text-decoration: underline;
}

[falkoschindler]

Uncolored links without underlines are the default when using Tailwind. And we don't want to add custom default styling for generic HTML elements, because this would make styling even more unpredictable, after Quasar and Tailwind already defined theirs.

But you can call ui.run(..., tailwind=False) to get the "normal" HTML styling.
Or you define how links or other HTML elements should look like in your app:

ui.add_head_html('''
  <style>
    a:link, a:visited {
        color: rgb(0, 0, 238);
        text-decoration: none;
    }
    a:hover, a:active {
        color: rgba(0, 0, 238, 0.5);
        text-decoration: underline;
    }
  </style>
''')

[WolfgangFahl]

I think i'll make this part of my Link class by adding:

    red_link="color: red;text-decoration: underline;"
    blue_link="color: blue;text-decoration: underline;"

and an option for adding red and blue links in the create function. That way i get mediawiki compatible link display which makes sense for most of my applications.