Cleaner code: best practices for HTML code with WeWeb?

[robm]

I’ve had a look around WeWeb and created a basic website. While WeWeb is great for quickly throwing something together, there seems to be an awful lot of unnecessary code output for basic things. I guess this has been mentioned before but I can’t easily find definitive answers.

Here’s a simple example:

The problems I have with this code:

1. Creating a link with rich text editor doesn’t add basic styles
2. You have to style separately which outputs <u> and <span> classes and inline styles.
3. The link also is not very easy to edit after it’s created.
4. The <p> wrapper has an awful lot of styling that I’d prefer to have in :root
5. It’s all wrapped in an unnecessary <div>
6. Even tabular data isn’t formatted properly (it’s all <div>s and <p>s)

I could go on, but the basic gist is there’s a whole lot of redundant or incorrect code that I’d like to be trimmed down and somewhat semantically correct. I do understand that to make it “no-code” extra html is required, especially for things like the “Kanban” widget.

The point of using WeWeb is that people who don’t want to mess around with javascript can use it in a no-code way, but I’d also like to keep it cleaner for the next project.

General

• Is the only option for simpler code Embeds->HTML?
• How do I enforce WeWeb to use a default css file, without too much overriding of your defaults? (ideally, zero overriding)
  • I’d rather use plain old css and classes in developer mode.
  • In my experience so far, the “Custom CSS” box at the bottom of the editor hasn’t really worked for me. It doesn’t seem to override the selected block.
• For an example: if I wanted a plain HTML form, with zero styling — then add in whatever variables, data, and workflows, css etc — is that something easily achievable?
• Can I achieve this kind of thing without having to mess around with Vue components?

Markdown

I can see two options for Markdown. The first is basic which has a very small field to enter in your Markdown, and isn’t very usable.

The second is input which I don’t really understand. In the documentation there’s two boxes, an input and an output. Do you have to link the two somehow?

Could an admin use Markdown in place of the drag and drop interface for simple HTML? How do you get read-only content?

Summing up …

I know a little javascript but I’d rather not have to get my hands dirty and learn a whole new framework (Vue) to achieve something that should be simple. I’m also still trying to wrap my head around building interactive things with WeWeb.

For the simple stuff though, I feel that unless you’re using custom components (e.g: form container), the above should be something that’s easily achievable?

I apologise for all the questions, but it’d be helpful to have answers in one place so that others might benefit too.

What suggestions do you have for best practices?

Thanks.

[dorilama]

you want to use the html element as less as possible, expecially if you need to interpolate untrusted data from the user. Also because with that you opt-out of all the nocode stuff. You can create a form in plain html, but then connecting it to the nocode part (logic variables etc) will be more difficult and probably require more code.

I think that the code generated by the ritch editor is handled by the library used in the component (tiptap).

The produced html is bigger than what you would do manually but it is not meant to be manually edited and the browser can render all that stuff easily. You can argue about benchmark of speed for styles etc but usually what will make you page slow will be js and data fetching, not the structure of the page.
The extra elements are there of course for a reason, and some of the styles are actually applied to the wrapper, not the element.

The “custom CSS” box will not override styles managed directly by weweb. You need to use another approach: add css variables to that box (--bg-color: red;) and bind the style property in the editor to a string accessing the variable (var(--bg-color)). You can always add your external css and add classes to the components. Remember that this way you will need to overrun the specificity of inline styles and will end up writing a bunch of css that goes against best practices. And also nome styles are applied to the wrapper, so you will need to get a bit more creative with selectors or add an extra wrapper.

Using Vue is necessary only in custom code components. Again, you want to use weweb’s components as much as you can because cooding components for a nocode platform is usually slower that doing the same thing in a yescode project, just because you need to integrate it with the editor.

There is big amount of interfaces that you can create with Weweb without using external code, and you can also add a lot of interactivity and logic. A lot of people here created drag and drop form builders, multistep dyanamic forms and event notion-style form builders.

[robm]

Hmm. @dorilama I hope these posts don’t come across as overly-complaining; I admire the work that’s going into WeWeb and I think for the most part, it works really well. I do have a bit of a critique about your position however:

I understand the problem with security for forms, but perhaps looking to other frameworks with some form of templating system that assures some security for simple forms would be nice, in addition to drag-and-drop.

On styling components

The “custom CSS” box will not override styles managed directly by weweb. You need to use another approach: add css variables to that box (--bg-color: red; ) and bind the style property in the editor to a string accessing the variable (var(--bg-color) ).

Could you expand on this please? Perhaps I haven’t understand you properly, but this seems a bit bizarre. I understand --css-variables and assigning them as color: var(--color-variable); in CSS — is that all you need to do? I mean, surely having a CSS box that won’t override styles managed directly by Weweb is an oversight — why have the box there if it’s more-or-less inactive?

Ideally it would be nice to have some of those components available as unstyled (is it easy to remove styling?) so that anyone with a little CSS knowledge can override things easily. Or use the new CSS Layers option so we don’t have to !important all the things.

Or better still use something like Tailwind so components can be properly styled or override all in one place.

I’m still trying to wrap my head around components and style-systems within WeWeb, so I apologise if this has been considered (or implemented) before and I’m just not understanding things properly. But I think my feature suggestion of unstyled, or easy-to-unstyle components would come in handy.

So in short, I understand if HTML/Vue components are better served as a library (without editing the raw HTML), but styling options should be easily made.

And also some styles are applied to the wrapper, so you will need to get a bit more creative with selectors or add an extra wrapper.

Again, this seems like really bad practice. An element should style on the element and not it’s wrapper (unless you’re doing stuff with flexbox etc).

The rich text editor

I think that the code generated by the rich [text] editor is handled by the library used in the component (tiptap).

I think more documentation for this would very helpful. I still don’t understand how you’d link the editor to the live preview/read-only mode. To be clear:

1. I’d like to use the rich text editor (which would allow for Markdown) for both end-users and for my own purposes for general content editing.
2. I can see the options for “Read only”, “Editable”, and “Rich Text/Markdown” but in the documentation it has one box on top of the other:
   1. An editor box (Rich text mode)
   2. A read-only box (No editor, text is rendered here from the editor box)
   3. Has one box been bound to the other somehow? Or is the documentation outdated?
3. According to this documentation of tiptap (if that’s what is being used) they don’t widely support Markdown?
4. Some things written in Markdown convert nicely into Rich HTML (automatically), but [^1]: footnotes and [link](http://links.com) don’t?
5. Adding images via Markdown is a bit hard to make edits, you’ve just got to delete and start again. It also adds a bunch of <p><br /> when it renders the image by closing the ![title](http://image.com/ last paren )
6. And a more serious bug that’s just happened as I’ve published changes to my workspace, is that all of the rich text from my editor tests have disappeared. I don’t know how on earth that happened.
   • Is this expected behaviour?
   • Do you have to bind it to a database for it to save properly?

I’d look to apps that do Markdown well, like Bear app — or failing that, just give an option to write Markdown as normal and parse it into HTML.

I feel like in current editor’s state, it’d be just as easy to write my own Markdown and parse it as HTML for now — even the Rich Text mode adds a bunch of unnecessary <p><br />s from what I can see:

I understand that the HTML element is frowned upon for no-code, if everything is supposed to be more of a drag-and-drap scenario. That’s fine, but the Rich Text Editor still seems to need some work.

Summing up

There is big amount of interfaces that you can create with Weweb without using external code, and you can also add a lot of interactivity and logic. A lot of people here created drag and drop form builders, multistep dyanamic forms and event notion-style form builders.

I’m sure there are, and I’ll keep trying. My initial effort was pretty simple so I’m sure there’s lots more cool stuff WeWeb can do with data that I don’t know about yet.

This also comes from a place of wanting WeWeb to do well, for both no-coders and those of us who’d like something a bit more flexible. I’m also learning how to build things with Elm Lang, so I imagine I’ll have some sort of hybrid system going on.

Finally …

Again, you want to use weweb’s components as much as you can because coding components for a nocode platform is usually slower that doing the same thing in a yescode project …

Could you expand on this please? By “yes code”, do you just mean coding things up from scratch?

[Broberto]

Jesus christ, I’m not reading all of this, sorry guys, have fun lmao.
ChatGPT summary, by the way, I agree with whoever blames the overly verbose markup of WeWeb, because I hate it too when I have to tweak something outside the WeWeb powers with CSS or JS for example.

[robm]

@Broberto Fair comment. I tried to be thorough!

I have a ton of little potential tweaks that I’d noticed building a small thing before which I haven’t (yet) mentioned, but understand if all the above goes unnoticed. I think it’s worth noting though.

@Broberto

ChatGPT summary, by the way

Thanks for the summary

[dorilama]

I get your suggestions, you should formalize them in feature requests at http://feedback.weweb.io/ I’m sure weweb team will benefit from the feedback.

[robm]

@dorilama Ok then, I’ve added a feature request.