Input element request about litehtml

[bigfatbrowncat]

I'm sorry for interfering (as I'm not the author), but I want to protect the concept of this library.

There are many browser engines out there - chromiumembedded, gecko and so on. All of them let the user to make forms themselves, actually download the pages from the web and so on... But they are HUGE. And SLOW. :)

LiteHTML is small, fast and easily embeddable. It's main target is to calculate (not render) the visual part and handle output and input events.
If you want tag to be handled, it should be a part of your visualiser (which isn't actually a part of liteHTML). it's up to you to handle a custom tag and create an input field (or a button) cause if liteHTML starts to create buttons for you it would be dependent of some visual component library (such as WinForms or GTK+) and supporting all of them for different platforms would make it huge and possibly slow.

That's only my opinion, but I hope @tordex wouldn't disagree with me...

[DaveM2011]

Im not saying that is should be added im pretty sure the issue belong with litebrowser but it would be hugely helpful to have in ethier

[tordex]

Yes, I agree with @bigfatbrowncat, the implementation of the input element must be completely outside litehtml. Generally the method document_container::create_element was created to implement the input tag in the future. Using the document_container::create_element you can overwrite any tag with your own implementation. On the other hands some code can be added into litehtml to help with input tag implementation (like something like notification about new position etc.).

I plan to add the input implementation into litebrowser to test this technology.

[DaveM2011]

Awsome thanks be sure to keep me posted even just the basics in litehtml and some sort of editor class in litebrowser i think i could handle the rest and then push it after ive added most of the basics [input,textarea,date,color,spinner] maybe some others there mainly the ones i need to create 😄

[tordex]

Just committed update for litebrowser and litehtml.

In the litehtml I've added the pointer to the document as the parameter of document_container::create_element - you need it to create the custom elements.

The litebrowser now supports the address bar. And this address bar is based on <input> tag. This is just a simple demonstration how to create custom elements and bind them with the real controls.

First we have to implement create_element:

litehtml::element* CToolbarWnd::create_element(const litehtml::tchar_t* tag_name, const litehtml::string_map& attributes, litehtml::document* doc)
{
    if (!t_strcasecmp(tag_name, _t("input")))
    {
        auto iter = attributes.find(_t("type"));
        if (iter != attributes.end())
        {
            if (!t_strcasecmp(iter->second.c_str(), _t("text")))
            {
                if (m_omnibox)
                {
                    m_omnibox->release();
                    m_omnibox = nullptr;
                }

                m_omnibox = new el_omnibox(doc, m_hWnd, this);
                m_omnibox->addRef();
                return m_omnibox;
            }
        }
    }
    return 0;
}

The el_omnibox have a member function update_position:

void el_omnibox::update_position()
{
    litehtml::position pos = litehtml::element::get_placement();
    RECT rcPos;
    rcPos.left = pos.left();
    rcPos.right = pos.right();
    rcPos.top = pos.top();
    rcPos.bottom = pos.bottom();
    m_edit.setRect(&rcPos);
}

You have to call el_omnibox::update_position every time after rendering:

void CToolbarWnd::render_toolbar(int width)
{
    if (m_doc)
    {
        m_doc->render(width);
        m_omnibox->update_position();
    }
}

The m_edit.setRect just updates the real control position. You can replace this with something like MoveWindow or any other function to re-position control.

PS. I've tried to create address bar with the standard Edit (richedit) windows control - this is working, but it is very hard to customize it for visual appearance :( So I've used the custom windowless control I've created later.

[DaveM2011]

omg awsome i will give it a go later on in the week thanks a bunch

[DaveM2011]

wow awsome work man might be a little buggy but i can work with that got it running and updated in my project in less that a few hours with setting up etc. Im going to spend a little time intergrating it into the main browser theres quite a bit of code to add i see so i will do that first then start adding input types i will let you know how i get on and again good work on this

[gesajt]

What happen with "input" field? I understand, that it is not part of litehtml, but it is not visible in litebrowser too!

[tordex]

@gesajt the input tag is not implemented in litebrowser.

[gesajt]

Do you plan to implement it? Since it will be good to have such basic functionality (and so litebrowser can be used for some real sites, not only for visualization).

[blockspacer]

see as example implementation https://github.com/blockspacer/qtimgui-wasm-port/blob/feature/litehtml/container_el_inputbox.cpp

[ec1oud]

Any plan to get this feature added?

Given that there is no JS, I'd like to be able to turn checkboxes into tabs, for example, as in https://alvarotrigo.com/blog/html-css-tabs/ (the simpler ones, without SVG and so on). So only the checkbox state-changing logic, calculating geometry based on the style, and input handling needs to be in litehtml, right? So far, some such examples (such as https://codepen.io/alvarotrigo/pen/QWqXYmG) even render almost correctly: but they are just not interactive.

Maybe it would be ok to add this piecewise: one input type at a time. I can understand that text-input elements are harder to get working, and more of the work needs to be left to the renderer. For me it's also less important ATM.