It has panning, zooming, and dragging elements around. The settings closely follow html/css. We think an open canvas is a big improvement over other website builders. Everything is easier: styling, consistency, responsiveness…
But making it work was hard! We thought HN would appreciate the tech behind it: - A custom WebGL rendering engine (w/text, shadows, blurs, gradients, & opacity groups) - A partial implementation of the css spec - A custom text editor & text shaper - A transformer to turn designs into publishable html/css
Repaint is a design tool for html/css. But internally, it doesn’t actually use html/css itself. All your designs live in a single <canvas> element.
We wanted users to be able to see all their content on one screen. We target +60fps, so frames only have 16ms to render. The browser’s layout engine couldn’t handle simple actions, like zooming, with many thousands of nodes on the screen. To fix that, we wrote a rendering engine in WebGL.
Since we use custom rendering, we had to create a lot of built-in browser behavior ourselves.
Users modify a large dom-like data-structure in our editor. Each node in the document has a set of css-like styles. We created a layout engine that turns this document into a list of positions and sizes. We feed these values into the rendering engine. Our layout engine lets us display proper html layouts without using the browser's layout engine. We support both flex and block layouts. We already support multiple layout units and properties (px, %, mins, maxes, etc.).
We also can’t use the browser’s built-in text editor, so we made one ourselves. We implemented all the common text editor features regarding selection and content editing (clicking, selection, hotkeys, inline styling, etc.). The state consists of content and selection. The inputs are keystrokes, clicks, and style changes. The updated state is used to render text, selection boxes, and the cursor.
When you publish a website, we turn our internal document into an html document. We've intentionally structured our document to feel similar to a dom tree. Each node has a 1:1 mapping with an html element. Nodes have a list of breakpoints which represent media-queries. We apply the styles by turning them into selectors. All of the html pages are saved and stored on our fileserver for hosting.
We made a playground for HN, so you can try it yourself. Now that the tech works, we’d love feedback and ideas for improving the product experience.
And we’d love to meet more builders interested in the space. If that’s you, feel free to say hello in the comments! Or you can reach Ben from his website.
Playground: https://app.repaint.com/playground
Demo Vid: https://www.loom.com/share/03ee81317c224189bfa202d3eacfa3c3?...
Main Website: https://repaint.com/
Contact: https://benshumaker.xyz/
I just tried to insert an emoji on the demo. The page didn't recognize the IME was up and when pressed enter in the IME it inserted a carriage return in the text area. I tried pasting in some Japanese and an emoji. Neither displayed. I tried right-clicking so I could use cut/copy/paste/define/lookup/spellcorrect. All of them were missing
You actually just found a bug in our text editing. Cut/copy/paste is supposed to work. We've always tested with hotkeys instead of right clicking. So thanks for the bug report :)
This seems to be built out of pure love for technology but I am wondering how much time and effort has gone into that.
For me, it was the best part of 4 months of mornings, evenings and weekends - and roughly 40% of my sanity (quaternions took the other 60% a few years ago). And the work is nowhere near finished. Knowing that I still need to find a proper fix for CJK punctuation brings me out in hives. I've also developed a special hatred of Thai fonts.
As for styling a single Arabic glyph within a word ... has anyone in the world managed to do that? It's when I failed to achieve that idea I decided to throw in the towel and release the work as Good Enough because I've Had Enough!
Still - it was an adventure[1].
[1] - https://scrawl-v8.rikweb.org.uk/demo/canvas-206.html
Tbh all the complex part is handled by: https://github.com/harfbuzz/harfbuzzjs which handles the entire text shaping part (which glyphs to draw and the offset from previous glyph), then all that remains is text layout (linebreaking, kerning, line height, font size etc.) and the actual rendering ofc. Still took about 4 months of full-time work.
I've never heard about this. Where can I read more about it?
Complexity comes from the fact that in Arabic, a single character can have at max 4 contextual shapes generally speaking. In Nastaleeq variation, a single character can have up 100s of contextual shapes depending upon where it appears in the word.
[0]. https://pango.gnome.org/ScriptGallery
And maybe it sounds silly, but we don't personally feel pure love for technology. We're obsessed with a vision. And we've decided to conquer any technical challenge to make it real.
- import existing html/css. This would allow me to use it for non-greenfield projects, and allow for back-and-forth workflows.
- mark nodes with my own semantic ids that are included in the html export. I would use these to post process exported html to create dynamic templates/components/views. I don't want to be tied to a specific framework.
- No way to set defaults for new frames etc ( that I know of )
- Some things rely on mouse input (setting width modes etc) which breaks flow
- Generally not for power users
- No decent code export
- No stylesheets for retheming components /showing variation (I know there's a Variant workflow for it but it's not simple to restyle an entire hierarchy)
Would love to see you tackle those if you're not already. Great to see you following CSS more closely, makes so much sense.
But if you aren't allowing us to extract the code / self host then I'll be passing on it. Digital feudalism
Also congratulations on building a canvas engine library! Nothing is easy when it comes to canvas. Creating one for the WebGL canvas is magnitudes of more difficulty compared to 2D (which is what my library maps to).
I'd love to hear your horror stories when it came to coding up the text layout functionality and text editor - that is, in my view, the hardest part of the job: I may have invented a few new swear words while tackling that work.
I'd also be interested in your plans for accessibility. Not just making the tool accessible, but how such a tool may push designers to consider accessibility as a first class requirement for the end user in the projects they build with the tool.
Best wishes and great fortune!
Haven't planned accessibility help yet. But I think simple warnings could go far. When I break guidelines, it's usually by accident.
Every time I have to interact with font metrics data directly, I pour one out for IBM’s greatest and most tragic PC desktop OS.
https://faultlore.com/blah/text-hates-you
Otherwise, this is another hosting service with a really nice proprietary wizard.
HTML/CSS support should just be another MIME type among many. Java Applets, Flash/Shockwave, PDF, Markdown, VRML-97, Quake .map, or whatever. Most sites would use one of the many stock renderer & runtimes. Some would implement their own, like your CSS reimplementation, as needed.
In other words, just skip the need for HTML shims.
Lastly, your efforts bring us that much closer to bringing us full circle. Next step: implement Wayland (and/or X11 if you're nostalgic).
https://ishoudinireadyyet.com/
https://github.com/w3c/css-houdini-drafts/blob/master/css-la...
When you explained how you had just reimplemented the CSS spec I was mindblown.
You guys rock. Repaint is amazing.