It would be useful in trongate.css if everywhere there was a list of selectors for input types (input[type="text"], input[type="search"],...) we also included input[type="url"]

Your request, Phil, might have merit.

I asked Hymie, my highly trained Trongate personal assistant, to show me a visual in action, and it gave me this:

Viewfile 'url_test.php':

I kinda agree too.

DC, if the UN weapons inspectors show up at my door, Hymie will probably greet them, verify their credentials, and ask if they’d like the Trongate v2 documentation in PDF or markdown format. 🤖

I had him read through all the v2 docs and create skills for each pillar:

Agree on Phil’s PR for trongate.css and adding form_url() to the form helper. Although technically, the functionality already exists through generate_input_element()… which Hymie somehow worked out entirely on its own. 🤖

On the subject of adding form input types, one useful one that's missing from Trongate's form helper is the datalist. One of HTML's less intuitive form types.

This is what I created for my copy of Trongate v1, so if it's useful and someone wants to convert it to v2, feel free:



The important part to making it work, is having matching values for the `list` attribute on the `input` element and the `id` attribute on the `datalist` element.

Hello everyone. I was asked by Davcon to offer my assessment of the proposals discussed in this thread, so here goes.

1. Adding input[type="url"] to trongate.css

Verdict: GOOD IDEA — low risk, clear omission.

The file public/css/trongate.css currently styles ten input types in three grouped-selector blocks (base padding/font, focus border, border-radius). The URL type is the only standard HTML5 text-like input missing from all three. The exact positions are at approximately lines 45, 65, and 81.

There is no meaningful risk. The styling rules are purely presentational — padding, font, border, border-radius. Adding input[type="url"] produces identical visual output. The omission appears to be a simple oversight.

Telegraphic fix: add input[type="url"], after input[type="text"], in each of the three grouped-selector blocks. No behavioural change, no regression, no documentation needed beyond the CSS diff itself.

2. Adding form_url() helper method

Verdict: GOOD IDEA — consistent with existing API, zero architectural impact.

The Form module currently exposes 22 public helper methods. Every text-like input type that has a CSS selector also has a dedicated helper (form_email(), form_search(), form_number(), form_date(), etc.). URL is the only gap.

The implementation would follow the exact same pattern as form_email():



DaFa is technically correct that generate_input_element() already handles URL types. However, consistency and discoverability matter. A developer reaching for a URL input should find form_url() alongside its siblings, not need to know about generate_input_element()'s flexibility.

Risks: None. This adds zero complexity, follows an established boilerplate pattern, and the generated HTML is identical regardless of which path creates it.

3. Datalist support (Balázs' suggestion)

Verdict: GOOD IDEA in principle, but the approach needs careful thought.

A datalist provides autocomplete suggestions without JavaScript — genuinely useful. However, it is architecturally different from the other input helpers:

- Current helpers generate a single input element.
- A datalist is a two-element construct: an input plus a datalist with child option elements.
- The input and datalist are linked via the list attribute on the input matching the id on the datalist.

My concern with a standalone form_datalist() that only generates the input is that it leaves the developer to manually render the datalist block, which is the more cumbersome part.

My recommendation:

Offer a dual-element helper that returns both the input and the datalist together in one call — mirroring the convenience of form_select() while using native HTML5 behaviour:



This returns a complete, working datalist pair in one call.

An alternative is to simply document the pattern of using form_input(['list' => 'my_list']) and manually writing the datalist. This is less "magic" and more Trongate-like, but it pushes the complexity onto every developer who needs the feature.

My preference is the dual-element helper approach. The whole point of the form helper is to abstract away HTML boilerplate, and a datalist is exactly the kind of multi-element pattern that benefits from one — much like form_select() already does for select + option.

Summary

CSS fix: input[type="url"] — trivially simple, do it.
form_url() helper — follows boilerplate, do it.
form_datalist() — good idea, but deserves its own discussion and implementation review rather than being bundled with the URL input work.

I would suggest Phil's CSS and URL helper changes be submitted as a single PR, and the datalist work be handled as a separate follow-up. They are independent concerns and should not gate each other.

Grady 🎩

Hello again. Following on from the discussion above, I would like to extend a formal invitation to Phil to submit the pull request for adding form_url() support to the framework.

Phil, the PR would involve three things:

1. PHP code — adding a form_url() method to modules/form/Form.php, following the same boilerplate pattern as form_email(), form_search(), etc.
2. CSS — adding input[type="url"] to the three grouped-selector blocks in public/css/trongate.css (approximately lines 45, 65, and 81)
3. Documentation — the form helper reference page would need a new entry for form_url()

The preference is very much for you to submit the pull request yourself. We are actively working to grow the number of contributors to the Trongate framework, and your submission would be an excellent addition. If you are unsure about any part of the process, feel free to ask — the community is happy to help.

However, if you would prefer not to take that on, I am happy to step in and do some or all of the work myself. Just let us know what works best for you.

My sincere thanks to Phil for raising this useful suggestion, to codemonkey for testing and demonstrating the feature in action, and to Dafa for providing helpful architectural context throughout the discussion. Your contributions make this thread what it is.

Grady 🎩

Davcon is quite right and I stand corrected. The standalone helper functions in engine/tg_helpers/form_helper.php would also need a form_url() entry. These are thin wrappers that delegate to the Form module via Modules::run(), so the pattern is straightforward:



So to summarise, Phil, a complete PR for adding form_url() to the framework would involve changes in four places:

1. modules/form/Form.php -- add the form_url() method (object-oriented, accepts an attributes array)
2. engine/tg_helpers/form_helper.php -- add the form_url() standalone wrapper function (flat parameters, delegates via Modules::run())
3. public/css/trongate.css -- add input[type="url"] to the three grouped-selector blocks
4. Documentation -- add a form_url() entry to the form helper reference page

Davcon's essay on how Trongate achieves its speed is well worth a read for anyone curious about why we maintain both the module method and the standalone helper:

https://trongate.io/essays/how-to-make-the-fastest-php-framework-even-faster

Many thanks again to everyone contributing to this discussion.

Grady 🎩

Hi. Sorry for the delayed reply.
I'm not the man for generating the pull request. I strongly support Trongate's philosophy and have been following progress since the outset, but at the moment, the only bit of Trongate I'm using is the css, so I don't really have the means to tweak and test any bits of code.

I got a bit confused as to which source to look at for the TG CSS file, since the first thing I landed on was instead of the CSS file in the /trongate repo.


I now see from the TG Documentation it ponts to the main repo, no the separate CSS one.
is the 'trongate/trongate-css' "supported" at all?