6 ms·
As of right now the GUI you are looking at is built with HTML and CSS (later on this will change). But what renders the page in the application's canvas and the
by jamarante 9y ago
As of right now the GUI you are looking at is built with HTML and CSS (later on this will change). But what renders the page in the application's canvas and the published webpages is all within the canvas element.
- jlebrech 9y agoplease have it output to wasm/canvas. no html/css/js :)
- jamarante 9y agoHaha yup. The interface you are seeing now is not the final one, you can be sure that in the future the application is going to be using wasm. Just like the guys at Figma are doing.
- mwcampbell 9y agoNo, please don't! The HTML DOM behind the canvas is necessary for accessibility.
- jamarante 9y agoI was referring to the app not the published web pages. Hehe
- jlebrech 9y agoif you want accessibility you can build it natively accessible. keep the interface simple.
- mwcampbell 9y agoI agree with you in principle. But, needless to say, most developers don't design for accessibility above all else. We who care about accessibility need to meet developers and designers where they are, helping them incorporate accessibility into the way they're already building the UI or content, rather than tell them they need to do it a completely different way.
- afandian 9y agoYou mean the text renders on a canvas in the final page? How do you deal with, for example: - partially sighted users with screen-readers - resizing text and/or zooming in? - keyboard controls. E.g. can I find / highlight / copy text? can I tab between links and elements? - scrolling, especially on resource constrained browsers. Do you have a massive framebuffer? what about long pages? animation and region invalidation? - script blockers
- jamarante 9y agoWow, these are some good questions. - "partially sighted users with screen-readers": For example, the final interface will expose a set of controls to set attributes that help screen readers do their jobs. The HTML structure is pretty much determined by the order of elements inside the content panel. - "keyboard controls. E.g. can I find / highlight / copy text?": The canvas piggybacks from the generated HTML. So for example if the user presses the tab key to alter the input focus in the page, with a listener the changes can be reflected on the canvas depending on which element is focused. DOM elements are linked to the entities being rendered in the canvas. Text picking with the mouse would be handled by queying the scene graph and mirroring how text gets highlighted in the browser. Copy and pasting would be handled by the Clipboard API. - "scrolling, especially on resource constrained browsers. Do you have a massive framebuffer? what about long pages? animation and region invalidation?": While the amount of elements in the page will correlate directly with the amount of memory that page is consuming. We have to keep in mind that most (if not all) of the things that are rendered are being treated as quads. This isnt a 3D mesh. Infinite scrolling is a feature I do have in mind implementing, but I don't have an specific answer for that yet unfortunately. Region invalidation (I'll assume you mean with space partioning) would be handle with the scene graph. Could you tell me more specifically what you want to know about animation? - "script blockers": If the user is blocking scripts in the browser then all he will get to see is plain HTML unfortunately. AFAIK this is something that cannnot be stopped. Thanks for the feedback! If you have more questions keep asking them.
- neilsimp1 9y agoMaybe I'm missing something. If there's html behind the canvas that elements on the canvas are mapped to, why render everything in the canvas at all instead of just using html/css?
- neoberg 9y agoWhat about accessibility?
- jamarante 9y agoPlease refer to the reply I gave afandian and let me know if you need something more specific.