18 ms·

The web today rebuilds the scrollbar in javascript (overriding Browser UI), reimplements the DOM in js (I doubt this abstraction is more lightwight than renderi

by 1ris 8y ago

The web today rebuilds the scrollbar in javascript (overriding Browser UI), reimplements the DOM in js (I doubt this abstraction is more lightwight than rendering into a convas) and builds single page applications (making URL way less usefull, breaking back and forward, and open in new tab buttons). This doesn't look any different. This web application does not have to pretend to be a hypertext, but otherwise this looks very familiar. And there is something to gain: A proper language, less resource wasted at run time, the vision of "Compile once, run anywhere", but this time for real and sandboxed.

Vinnl 8y ago
> The web today rebuilds the scrollbar in javascript Who does that? > reimplements the DOM in js I am assuming you are referring to the Virtual DOM? In which case: no it doesn't. It's an abstraction for working _with_ the DOM, but it doesn't do away with all the advantages of the DOM - like canvas does. > (making URL way less usefull, breaking back and forward, and open in new tab buttons). This indeed used to be done, but with the History API having been usable for years, you hardly ever encounter that any more nowadays.
- pjmlp 8y ago
  > > The web today rebuilds the scrollbar in javascript > Who does that? Google in some of their developer docs for example.
- hajile 8y ago
  Webkit browsers have the (somewhat limited) ability to manipulate the scrollbars with pseudo-selectors. For everything else, it's JS or deal with whatever horribleness that browser gives you. History API is standard, but not usable for a lot of things. I'm on a project that has to play nicely with server-side routing, so we are forced to use hash routing like it's 2001. Likewise, the ability to save state in the builtin History API forces some workarounds and doesn't play too nicely with things like testing.
- 1ris 8y ago
  What pjmlp and hajile said. Besides: Yes, I meant virtual DOM. And yes it does. It's another (complex) layer of indirection encapsulating already extremely high level API, that is already looks like the most elaborate API to navigate a tree. And what advantage does using the dom bring me? Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas? Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it? Text reflow on mobile is better. But AFAIK Chrome removed this feature because it broke to many websites anyway. Opera is the only brower to do it. Market share ~5%. Even with the History API you completely break all assumptions about url. You can share a link with a single page app just like you can with this example; it doesn't make much sense, tho.
  - danShumway 8y ago
    > Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas? Yes, specifying shortcuts and fonts at the browser level is better than doing it application by application. Browser zoom is usually vastly preferable to just magnifying the screen in my experience. Handling gestures, intercepting all keyboard events (including right click menus), and reimplementing settings like smooth scrolling on canvas is much more difficult and will give you much worse performance than just letting the browser do it for you, because you'll have to reinvent the wheel for every input. A good example of this is multitouch. Many websites were written before touchscreens were common. Most of those websites work with touch scrolling on my tablet, even though they haven't been updated. If you bundle an application with Qt and 2 or 3 years from now a new input format becomes commonplace, your site won't work with it unless you recompile and re-ship because it's up to you to interpret every piece of raw input that you get. Add to that the fact that many browsers handle input differently because different devices call for different behaviors. On sites that aren't optimized for mobile, your phone browser uses extra logic to make sure that your clicks are intentional. If you're manually handling everything yourself via canvas, you can't do that without trying to guess what device a user is using - an increasingly difficult task. > Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it? It's way easier. You're talking about using some kind of Machine Learning system or algorithm to take the place of explicit accessibility controls. Programs like Jaws do so much more than just read text off a page. They allow you to jump and scroll to specific headings. They allow you to get a list of every link on a page. They allow you to fill out an item on a form and jump to the submit button with a key stroke that you define (not the webapp) - or select an input field and read off the associated label or help box attached to it. There's a huge list of Aria labels and tricks that are used to make the DOM accessible, and none of them work with OCR - hidden icon labels, alt tags for images, etc... Accessibility is not just about reading off random text on a page. It's about context. The reason why a blob of pixels isn't accessible is because anyone who's blind loses all of the context. You lose the ability to take a hunk of content in your application and say in a universal language that every screen reader will understand, "This is the navigation. Bring the user here if they want to go somewhere." That stuff doesn't stop being important just because you made an application - arguably, it's much more important for an application than it is for a blog post or document. For a blog post you could make the argument that as long as your screen reader reads the text in order, you're still getting the gist of everything. For an application, a blind user needs much more context and much better structure than would otherwise be required for just reading. I've built enterprise level web applications - for us to say that we were compliant with accessibility standards, we had to do a heck of a lot more than just allow people to read text. The DOM helps with that.

by 1ris 8y ago

Vinnl 8y ago

> The web today rebuilds the scrollbar in javascript Who does that? > reimplements the DOM in js I am assuming you are referring to the Virtual DOM? In which case: no it doesn't. It's an abstraction for working _with_ the DOM, but it doesn't do away with all the advantages of the DOM - like canvas does. > (making URL way less usefull, breaking back and forward, and open in new tab buttons). This indeed used to be done, but with the History API having been usable for years, you hardly ever encounter that any more nowadays.

pjmlp 8y ago
> > The web today rebuilds the scrollbar in javascript > Who does that? Google in some of their developer docs for example.
hajile 8y ago
Webkit browsers have the (somewhat limited) ability to manipulate the scrollbars with pseudo-selectors. For everything else, it's JS or deal with whatever horribleness that browser gives you. History API is standard, but not usable for a lot of things. I'm on a project that has to play nicely with server-side routing, so we are forced to use hash routing like it's 2001. Likewise, the ability to save state in the builtin History API forces some workarounds and doesn't play too nicely with things like testing.
1ris 8y ago
What pjmlp and hajile said. Besides: Yes, I meant virtual DOM. And yes it does. It's another (complex) layer of indirection encapsulating already extremely high level API, that is already looks like the most elaborate API to navigate a tree. And what advantage does using the dom bring me? Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas? Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it? Text reflow on mobile is better. But AFAIK Chrome removed this feature because it broke to many websites anyway. Opera is the only brower to do it. Market share ~5%. Even with the History API you completely break all assumptions about url. You can share a link with a single page app just like you can with this example; it doesn't make much sense, tho.
- danShumway 8y ago
  > Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas? Yes, specifying shortcuts and fonts at the browser level is better than doing it application by application. Browser zoom is usually vastly preferable to just magnifying the screen in my experience. Handling gestures, intercepting all keyboard events (including right click menus), and reimplementing settings like smooth scrolling on canvas is much more difficult and will give you much worse performance than just letting the browser do it for you, because you'll have to reinvent the wheel for every input. A good example of this is multitouch. Many websites were written before touchscreens were common. Most of those websites work with touch scrolling on my tablet, even though they haven't been updated. If you bundle an application with Qt and 2 or 3 years from now a new input format becomes commonplace, your site won't work with it unless you recompile and re-ship because it's up to you to interpret every piece of raw input that you get. Add to that the fact that many browsers handle input differently because different devices call for different behaviors. On sites that aren't optimized for mobile, your phone browser uses extra logic to make sure that your clicks are intentional. If you're manually handling everything yourself via canvas, you can't do that without trying to guess what device a user is using - an increasingly difficult task. > Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it? It's way easier. You're talking about using some kind of Machine Learning system or algorithm to take the place of explicit accessibility controls. Programs like Jaws do so much more than just read text off a page. They allow you to jump and scroll to specific headings. They allow you to get a list of every link on a page. They allow you to fill out an item on a form and jump to the submit button with a key stroke that you define (not the webapp) - or select an input field and read off the associated label or help box attached to it. There's a huge list of Aria labels and tricks that are used to make the DOM accessible, and none of them work with OCR - hidden icon labels, alt tags for images, etc... Accessibility is not just about reading off random text on a page. It's about context. The reason why a blob of pixels isn't accessible is because anyone who's blind loses all of the context. You lose the ability to take a hunk of content in your application and say in a universal language that every screen reader will understand, "This is the navigation. Bring the user here if they want to go somewhere." That stuff doesn't stop being important just because you made an application - arguably, it's much more important for an application than it is for a blog post or document. For a blog post you could make the argument that as long as your screen reader reads the text in order, you're still getting the gist of everything. For an application, a blind user needs much more context and much better structure than would otherwise be required for just reading. I've built enterprise level web applications - for us to say that we were compliant with accessibility standards, we had to do a heck of a lot more than just allow people to read text. The DOM helps with that.