Text elements

[ed2050]

Continuing from discussion #1778, nicegui could use more text elements. ui.label is confusing because html has a <label> tag, which ui.label is not. I suggest either

1. adding methods for ui.para () and ui.heading (level = 1-6) or
2. if you really want to keep it abstract, make a new method ui.text () that covers all text elements. It can have flags such as heading = 1-6 for header text, para = true/false for body text, etc. Or perhaps an all-encompassing flag type = para,label,heading1,heading2,... that allows for later expansion. If users want simplicity, they can just call ui.text () with no flags to get the default text element, whatever that may be. Maintain ui.label as deprecated for compatability with existing code.

[falkoschindler]

Thanks for the feature request, @ed2050!

We strongly tend towards option 1 instead of creating a mighty text element with lots of parameters. Since we try to avoid abbreviations, ui.paragraph and ui.heading would be good candidates.

Driven by another discussion (#1592 (comment)) I recently started to think about a ui.table_of_contents element, which would require a dedicated ui.heading element. It would be great to rethink our text element(s) before possibly tackling the table of contents.

If we introduce more specialized text elements, we could imagine to deprecate ui.label, keep it as an alias to ui.text and eventually remove ui.label altogether. The label tag from HTML is not our main concern, because NiceGUI doesn't try to mimic HTML. But I can imagine that ui.label is not the most obvious name for such a "text" element.

Regarding the headings we're thinking about more LaTeX-like names heading, subheading, subsubheading. But we're not 100% how to map it to h1, h2, ..., h6. LaTeX also has part, chapter, paragraph and subparagraphs. But this is probably to specific for writing documents. A level parameter like ui.heading('Introduction', level=2) needs more typing and hides the hierarchy at the end of the line.

What about something like this:

• ui.title --> h1 (because there shouldn't be more than one h1 on a page)
• ui.heading --> h2
• ui.subheading --> h3
• ui.subsubheading --> h4
• ui.paragraph --> p
• ui.text --> div

Either way, our new text elements could have tag parameters for special cases:

• ui.subsubheading('Side note', tag='h5')
• ui.text('print(1 + 1)', tag='code')

What do you think?

[ed2050]

Hi falko, thanks for the info. I agree, TOC would be useful.

Before addressing your other questions, can I ask who your intended audience for nicegui is? I thought it was a toolkit to simplify user interfaces for app developers (whether web app or local app or both). These people would be programmers who are comfortable using python, not beginning students or people whose main job is another field and just dabble in python as a support tool (eg scientists running python scripts to parse / validate data from their experiments).

When you suggest latex and heading / subheading / subsubheading it sounds like you are targeting a very different audience. Like you are aiming nicegui at academics, particularly in cs or math, physics, and other hard sciences. Those are the people who know latex. Heading / subheading / subsubheading is more suitable for authoring scholarly publications than for writing web apps.

Anyone making web apps needs to understand basic html. HTML knowledge is far, far more common than latex knowledge among a general programming audience (I know both, though I haven't used latex since grad school). If your target is "python developers" then I would stick with paragraph, heading levels 1-6, and other html tags. They will be more familiar to a wider audience.

As far as deeper structures - TOCs, chapter, part, etc - html does have those. <section> and <article> are commonly used to break content into larger semantic chunks like chapter and part. Docbook (which is almost a superset of html) uses these tags and others for technical documentation. And html5 allows arbitrary tag creation, so anyone can use tags like <book> or <chapter> in their own html documents if they want (they just have to provide complete styling since browsers don't know how to style custom tags).

So I'm not sure where the resistance to html comes from. It's the lingua franca of markup languages (maybe markdown has slightly higher recognition among non-technical audiences). There are millions and millions of web developers, vs how many latex users? I love latex, it handles publishing jobs very well. But it doesn't seem like the right model for interactive web-based apps.

What do you think? What's your intent? Maybe we have different audiences in mind.

[falkoschindler]

Sorry for the confusion. LaTeX was just an example for a different, more English naming scheme than HTML's more cryptic h1-h6. But I didn't want to imply that we necessarily want to copy LaTeX's element names.

You're right, NiceGUI tries to "simplify user interfaces for app developers (whether web app or local app or both)". Sure, there are lots of web developers that are familiar with HTML. And we don't have a problem with HTML in general. But we want to think NiceGUI's API independently from existing conventions, more focussed on how a NiceGUI app would look like. Instead of writing

ui.h1('Introduction')
ui.p('Lorem ipsum...')
ui.img('dog.png')

we prefer

ui.heading('Introduction')
ui.paragraph('Lorem ipsum...')
ui.image('dog.png')

The latter is something everyone can read, even without prior web-dev knowledge. With an API like this we bring web-apps to developers that haven't even thought about creating web apps themselves, but just look for a way to quickly create some GUI for their application.

[ed2050]

Ok no problem. I'm not advocating for html abbreviations. Spelling out names is fine.

I forgot to add - MS Word also uses Heading 1 to Heading 6. So that's many more people familiar with it.