|
|
|
|
|
by joshribakoff
3172 days ago
|
|
I built an editor based on canvas and DOM, eventually you run into problems with canvas that the dom already solves. At that point your options are reinvent the wheel (for example write logic to draw tables with lines and the drawing API), or float DOM elements over the canvas. The latter gets hairy with z index as canvases block mouse and touch events from "passing through" to elements behind them. There are of course hacks like invisible dom elements that toggle pointer-events on the canvas, but you have to ask yourself if the problem you're trying to solve is really worth these hacks/reinventing the wheel. If you're not letting users draw with a paintbrush, you probably don't need canvas but that's just my opinion. Canvas is also a bit of a leaky abstraction in some cases. For example it essentially uses the same text layout algorithms as HTML, deciding on its own where to line wrap. Line wraps can jump around when resizing the browser. It is not vectorized text so it doesn't work for all types of designs |
|
To keep the line wrapping consistent with how the designer sees it in the application, wrapping is handled by the app itself, it doesn't rely on the text layout algorithm HTML uses. Consistency is the priority.