4 ms·

Hi chrismorgan. Many thanks for taking the time to check over the site, and giving me feedback! Can I ask which device/screen you used to view the site? I'm cu

Hi chrismorgan. Many thanks for taking the time to check over the site, and giving me feedback! Can I ask which device/screen you used to view the site? I'm currently limited to a Macbook Pro, so can't get the insight of seeing the page on other devices. >> This fails my very first test of anything canvasy: it’s not scaling by devicePixelRatio, so it looks bad on a high-DPI display, especially if text is involved. I usually find this to be a bad sign. [...] Anyway, this one should be very quick to fix Noted. Fixing will take a bit of thought as it won't be a simple case of scaling (as suggested here[1]). The canvas Cell where most of the work happens can already have different dimensions to the display canvas, which goes partway to addressing the problem. The library should also play nicely with <img srcset="..." sizes="..."> - I'm only supplying a single src value for the images used on the site. >> (even if it rather encourages CPU-guzzling) Yes. Minimising the impact on the CPU will remain a key priority for the library going forward. >> Accessibility: yeah, you can tab between the links, which is good, but when you’re just hovering you’re not hovering over a real link, so you can’t see the link target, That's an issue with the page code, not the library, I think. Hovering over a link with the mouse cursor should bring up a tooltip (working on my machine for Chrome, Firefox, Edge; fails on Safari) - I didn't think to include the link url when designing the page, but that can be easily added. Tabbing (which doesn't work on Firefox because[2], and is buggy on Safari) shows the link at the bottom-left of the browser window on Chrome, Edge. >> the cursor is wrong (though one that could be fixed), Agreed, fixable. >> and modifiers don’t work. On my Macbook Pro hovering over a link (and tabbing to it) changes the size of the pin and displays a graphic text label. Is that not what you see? The library has functionality to handle focus and blur states, but I've not thought to include anything to handle visited and active states. >> Right-click triggers the “links” too, which it shouldn’t. I can replicate this on Firefox, when I previously agree to "allow popups". Without that user agreement, the right click shows the small menu with links to "save image" etc. Does not seem to be occurring on Chrome, Edge, Safari. ... I'm beginning to fall out-of-love with Firefox on Mac >> Things like this must be handled by drawing real DOM elements persistently on top of the canvas, and letting the user genuinely interact with them. No other approach is capable of achieving the expected and desired result. Not `location.href = …`, not `open(…)`, not `link.click()`. Nothing. One straightforward (but inferior) approach to make this work could be to put an <a tabindex=-1> above the entire canvas (or even wrapping the canvas!) and set its href when hovering a “link”, and remove it again when not. This can be achieved by wrapping the canvas element in a Scrawl-canvas stack, which then allows DOM elements to be positioned over (or beneath) the canvas in the same way as canvas entitys. By making the DOM element "mimic" its entity, DOM element positions and dimensions can be handled automatically. >> I haven’t delved into any more of the accessibility stuff, but it looks much better than most, and just needs to work on any real DOM counterparts to canvas pieces actually being in the right place, so that interactions, text selection, &c. can work properly. Again, thank you! [1] - https://www.html5rocks.com/en/tutorials/canvas/hidpi/ https://www.html5rocks.com/en/tutorials/canvas/hidpi/ [2] - https://stackoverflow.com/questions/11704828/how-to-allow-keyboard-focus-of-links-in-firefox/11713537#11713537 https://stackoverflow.com/questions/11704828/how-to-allow-ke...

chrismorgan 7y ago
The main thing I’m talking about is links, that links need to be real, or the interactions are all wrong, irredeemably. It must be a real <a href> element that the user hovers over and clicks on, or else the link destination isn’t shown in status text (and you can’t just set window.status like you used to be able to!), and modifiers don’t work. Modifiers: Ctrl+click, Shift+click, Ctrl+Shift+click, that sort of thing, which change where the link will open—current window, new window, new background tab, new foreground tab, it’s up to the user agent to decide what it all means, and target=_blank is the only slight control authors can have. If you use open(…) or similar, it will do the wrong thing. open() is a very flimsy tool that has (or should have) very limited use. Browsers are likely to block it, though they may allow it to operate as part of an event handler. Concerning DOM elements matching the canvas contents, yes, that’s the approach that needs to be taken; and it needs to be taken. This leads me to suspect that for many applications minimising the part that happens in the canvas, or making an SVG/canvas hybrid, may be more sensible. The few examples I looked at seemed to start in the direction of doing this, but not take it as far as it needs to be taken to satisfy accessibility.
- rikroots 7y ago
  >> It must be a real <a href> element that the user hovers over and clicks on For each <canvas> element that Scrawl-canvas wraps, it adds a hidden <nav> element to the DOM, immediately after that <canvas> element. Creating a graphical entity with an anchor attribute will trigger the library to add an <a> element to the hidden <nav> element. When the user clicks on the graphical entity in the canvas, the library creates a new MouseEvent 'click' event and then dispatches it from the <a> element. The anchors are not directly placed over the graphical entitys in the canvas, but they are there in the DOM. >> Modifiers: Ctrl+click, Shift+click, Ctrl+Shift+click, that sort of thing, which change where the link will open—current window, new window, new background tab, new foreground tab, it’s up to the user agent to decide what it all means, and target=_blank is the only slight control authors can have. For Chrome running on a Macbook Pro: Shift+click opens the link in a new window; Command+click opens the link in a new tab but remains on the original page. I've not tested this functionality yet for other browsers, or for any browser running in a different OS/device. >> If you use open(…) or similar, it will do the wrong thing. open() is a very flimsy tool that has (or should have) very limited use. Browsers are likely to block it, though they may allow it to operate as part of an event handler. The library makes no use of window.open(), or similar. Links are driven by MouseEvents: let e = new MouseEvent('click', { view: window, bubbles: true, cancelable: true }); >> Concerning DOM elements matching the canvas contents, yes, that’s the approach that needs to be taken; and it needs to be taken. This leads me to suspect that for many applications minimising the part that happens in the canvas, or making an SVG/canvas hybrid, may be more sensible. The few examples I looked at seemed to start in the direction of doing this, but not take it as far as it needs to be taken to satisfy accessibility. I am grateful for the feedback! If the responses I've given above indicate that my thinking is flawed, then it is much better for this flawed thinking to be exposed and examined - and, if possible, fixed in the near future - rather than letting them lie hidden and festering in the library, making it unusable for serious production sites.

chrismorgan 7y ago

The main thing I’m talking about is links, that links need to be real, or the interactions are all wrong, irredeemably. It must be a real <a href> element that the user hovers over and clicks on, or else the link destination isn’t shown in status text (and you can’t just set window.status like you used to be able to!), and modifiers don’t work. Modifiers: Ctrl+click, Shift+click, Ctrl+Shift+click, that sort of thing, which change where the link will open—current window, new window, new background tab, new foreground tab, it’s up to the user agent to decide what it all means, and target=_blank is the only slight control authors can have. If you use open(…) or similar, it will do the wrong thing. open() is a very flimsy tool that has (or should have) very limited use. Browsers are likely to block it, though they may allow it to operate as part of an event handler. Concerning DOM elements matching the canvas contents, yes, that’s the approach that needs to be taken; and it needs to be taken. This leads me to suspect that for many applications minimising the part that happens in the canvas, or making an SVG/canvas hybrid, may be more sensible. The few examples I looked at seemed to start in the direction of doing this, but not take it as far as it needs to be taken to satisfy accessibility.

rikroots 7y ago
>> It must be a real <a href> element that the user hovers over and clicks on For each <canvas> element that Scrawl-canvas wraps, it adds a hidden <nav> element to the DOM, immediately after that <canvas> element. Creating a graphical entity with an anchor attribute will trigger the library to add an <a> element to the hidden <nav> element. When the user clicks on the graphical entity in the canvas, the library creates a new MouseEvent 'click' event and then dispatches it from the <a> element. The anchors are not directly placed over the graphical entitys in the canvas, but they are there in the DOM. >> Modifiers: Ctrl+click, Shift+click, Ctrl+Shift+click, that sort of thing, which change where the link will open—current window, new window, new background tab, new foreground tab, it’s up to the user agent to decide what it all means, and target=_blank is the only slight control authors can have. For Chrome running on a Macbook Pro: Shift+click opens the link in a new window; Command+click opens the link in a new tab but remains on the original page. I've not tested this functionality yet for other browsers, or for any browser running in a different OS/device. >> If you use open(…) or similar, it will do the wrong thing. open() is a very flimsy tool that has (or should have) very limited use. Browsers are likely to block it, though they may allow it to operate as part of an event handler. The library makes no use of window.open(), or similar. Links are driven by MouseEvents: let e = new MouseEvent('click', { view: window, bubbles: true, cancelable: true }); >> Concerning DOM elements matching the canvas contents, yes, that’s the approach that needs to be taken; and it needs to be taken. This leads me to suspect that for many applications minimising the part that happens in the canvas, or making an SVG/canvas hybrid, may be more sensible. The few examples I looked at seemed to start in the direction of doing this, but not take it as far as it needs to be taken to satisfy accessibility. I am grateful for the feedback! If the responses I've given above indicate that my thinking is flawed, then it is much better for this flawed thinking to be exposed and examined - and, if possible, fixed in the near future - rather than letting them lie hidden and festering in the library, making it unusable for serious production sites.