From: Robert Obkircher <r.obkircher@proxmox.com>
To: Shannon Sterz <s.sterz@proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>,
yew-devel@lists.proxmox.com, Dietmar Maurer <dietmar@proxmox.com>
Subject: Re: [PATCH yew-widget-toolkit v3] widget: add 'div', 'span' and 'italic' helper functions
Date: Wed, 8 Apr 2026 10:58:49 +0200 [thread overview]
Message-ID: <f29e2b0a-8f55-4890-925a-d8da5b1bc3d9@proxmox.com> (raw)
In-Reply-To: <DHNM2GSFWXR9.3NQTFXCJM47P2@proxmox.com>
On 08.04.26 09:55, Shannon Sterz wrote:
> On Wed Apr 8, 2026 at 9:12 AM CEST, Dominik Csapak wrote:
>>
>> On 4/7/26 7:25 PM, Dietmar Maurer wrote:
>>> italic() is IMHO very missleading ...
>> On 4/7/26 5:04 PM, Shannon Sterz wrote:
>>> On Tue Apr 7, 2026 at 3:13 PM CEST, Dominik Csapak wrote:
>>>> ah, missed inserting the changelog, so here it is:
>>>>
>>>> changes from v2:
>>>> * use standalone functions instead of macro
>>>> * add span/italic too for convenience
>>>> * make container mod public
>>> one small thing that occured to me is that the `<i>` element no longer
>>> is inteded for "italic text", but rather is a semantic element that
>>> should be used for "text that is set off from the normal prose for
>>> readability reasons" [1].
>>>
>>> so it might be more appropriate to use a `span` with italic styling here
>>> or we could add helpers for other semantic text elements such as `<em>`
>>> etc. too. no hard feelings on my side, though, i don't think this
>>> matters all too much.
>>>
>>> [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/i#usage_notes
>>>
>>> but overall, looks good to me, so consider this:
>>>
>>
>> i actually didn't want to express the italic styling here, but wanted
>> to have the 'i' tag (since we use that often for icons and so on),
>> but didn't come up with a better name than 'italic'. I also didn't want
>> to add a single-letter function.
>>
>> does any of you have a better idea ?
>>
>> mdn calls it the "Idiomatic Text element" but 'idiomatic()' also does
>> not really convey what it does.
>>
>> I can of course leave it out for now and we can decide later.
> just to put a couple of ideas out there: keeping with the rest of the
> functions here would be `i()`, but that might be a bit too short.
>
> we could maybe have a naming convention for wrapper helpers like this
> like `i_element()`, `span_element()`, and `div_element()` (alternatively
> replace `element` with `container` or `wrapper`). that feels a bit
> unnecessarily verbose, though.
Or a module like `tag::i` to let the caller decide whether the
function should be imported directly.
> if the intention is for this to mostly be used with icons, maybe that is
> best handled separately? for example, with an `Icon` component that
> takes the appropriate icon classes. somewhat analogous to `ActionIcon`
> except without the interactive component.
>
> --> snip <--
>
>
>
>
next prev parent reply other threads:[~2026-04-08 8:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 13:09 Dominik Csapak
2026-04-07 13:13 ` Dominik Csapak
2026-04-07 15:05 ` Shannon Sterz
2026-04-08 7:12 ` Dominik Csapak
2026-04-08 7:56 ` Shannon Sterz
2026-04-08 8:58 ` Robert Obkircher [this message]
2026-04-08 9:44 ` Dominik Csapak
2026-04-07 17:26 ` Dietmar Maurer
2026-04-08 10:56 ` superseded: " Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f29e2b0a-8f55-4890-925a-d8da5b1bc3d9@proxmox.com \
--to=r.obkircher@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=dietmar@proxmox.com \
--cc=s.sterz@proxmox.com \
--cc=yew-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox