281–290 of 333 posts
Hi Mario, I am an engineer on Google Search frontend. Thank you for posting this, and I'm really sorry and saddened to see this broken; this is certainly not intended behavior. I've reproduced the issue you described in the blog (Lynx does not allow clicking on the search results page). Even though Google serves valid HTML to Lynx, it's probably HTML that Lynx cannot parse, and since it used to work before, this is a…
Earlier quoted context omitted.
Heavy graphics with static HTML? That's going to be a crummy experience for mobile users.
CSS supports media queries.
Earlier quoted context omitted.
This sounds like the kind of argument that would have said that the algorithm for rounded rectangles in the Mac OS toolbox was superfluous fluff. The world is bigger and more interesting than screens and screens of uninterrupted plaintext.
Rounding rectangles is superfluous fluff, but it also is nice, and serves a purpose in the context of the whole design language they're using. I'm not against rounding rectangles and other such UI fluff in general. But I am against throwing away perfectly working controls, with all the ergonomy their offer, and replacing it with a half-broken, slower version of that control that only works if you use it in one partic…
Fortunately, good dynamic HTML also exists.
And I wouldn't write off rounded rectangles as superfluous fluff. They're fairly ubiquitous in user interface design because round cornered structures are fairly common in nature. They make a UI look more "real". And decreasing the artificiality of a user interface isn't superfluous; it lets more users interoperate with the interface without feeling like they've strapped an alien abstraction onto themselves. A lot of people in the computer engineering space have no trouble working with alien abstractions for hours at a time, but it's an extremely self-selecting group. We are often at risk of believing that what is normal for us should feel normal for everybody.
https://bgr.com/2016/05/17/iphone-design-rounded-squares-exp...
Earlier quoted context omitted.
Come on, you can't be serious about this. Creating sophisticated web pages is massively easier than 10 or 20 years ago. Yes, HTML of plain simple text-only pages is still pretty much the same, but most users actually prefer visually fancier content with pictures and colors. Yes, companies presenting themselvses online profit of more capabilities. And yes, presenting ads is probably easier too. But if you think those…
> most users actually prefer visually fancier content with pictures and colors. You're aware that pure HTML and CSS alone can produce visually fancy content with pictures and colors, right? It honestly seems like a lot of web developers are starting to forget this, but it's true, I swear. My personal web site ( https://coyotetracks.org/ ) is minimalist by design, but it has accent colors, custom fonts, Retina-ready i…
Earlier quoted context omitted.
Come on, you can't be serious about this. Creating sophisticated web pages is massively easier than 10 or 20 years ago. Yes, HTML of plain simple text-only pages is still pretty much the same, but most users actually prefer visually fancier content with pictures and colors. Yes, companies presenting themselvses online profit of more capabilities. And yes, presenting ads is probably easier too. But if you think those…
It's actually because we programmers like to recreate things, because there's this itch and wonder about how stuff works. Http hasn't changed that much. Html did. It was hyper text, and rendering was done for document flow. Then we could script a bit, and soon after we wanted "webapplications". Now, we lost probably 15 years trying to fit in an application-ui and lifecycle model in a document-flow model. Html, or rat…
Most application UIs are not complicated. Most applications are just interactive documents. There is nothing special about 90% of the apps I use on my native computer that means they couldn't be rendered as HTML. The document model is fine for applications. Preferable, even.
Heck, a reasonable portion of the native applications on my computer have optional pure-terminal interfaces. If your application can work in a terminal, it can work with HTML -- and embracing a document model for your application UI would be a better user experience than whatever the heck pixel-perfect framework that everyone is chasing nowadays. That's true on the web, and it's true on native.
The problem with the web is not that HTML is incapable of being used as an application platform; it's not that we're trying to fit a square peg into a round hole. It's that both web and native developers overestimate the interface requirements of their applications, and bring in unnecessary cruft to achieve pixel-perfect layouts that are worse for end-users.
We have a square peg, and a square hole, but we like to go to conferences and pretend that our peg is actually some convoluted, recursive star shape.
Earlier quoted context omitted.
It's funny because "javascript is bad" was common geek sentiment at the turn of the century. Now it is flamebait, or being caught up in the past [itself possibly a bit of a code for ageism]. Seeing this attitude change is one of the most interesting things I've seen in tech nerd circles in the last decade or so.
Can you elaborate on why it's funny? javascript (on it's own) has changed a lot in 20 years and it was originally designed in what, one week due to external time constraints? i think the criticisms are valid if $Your_favorite_language had ~4 days only for language design. From my recollection, there were no frameworks, no tooling, no linters, no jquery. it was a basically a primative language for browsers that had no…
I think you may be blind to the harshest criticisms, though. It was a common view that the web was built for static content (or server-side dynamic content) and code execution by the client is mostly a nuisance at best. And there is some validity to that. When JS was developed, roughly contemporaneous with worse ideas like java applets and ActiveX on the web, it was thought by proponents that untrusted code execution is OK to good. 20 years later, it was still assumed that if JS is sandboxed, memory safe, has a different page table from the rest of user mode, untrusted code execution is safe. Then spectre and meltdown happened.
I feel like many of the text-mode browsers have failed to keep up with changing web standards. We were all mad when IE was holding back the Internet, and I'm not sure we should give lynx and w3m a pass because they're geek tools. (Accessibility is an important concern, but web browsers running under a GUI system support screen readers.) https://www.brow.sh/ is a console-based browser that claims to support modern sta…
I'll be the first (EDIT: third) of six. > If all that stuff works for everyone, why did we invent new stuff? Just because? Or perhaps it wasn't really as amazing as well all remember. To better track people and push ads. It's really mostly just it. Modern web has very little to do with providing value to the end-user; any utility that's provided is mostly a side effect, and/or a vector to lure people into situations…
> Regarding 'L', Lynx sometimes "hides" links if the anchor is around a div. Maybe it is just that simple. IIRC, ... will trigger a similar behaviour.
I'm generally against unnecessary web complexity, but I don't understand how anyone can paint Lynx a hero for randomly ignoring anchor tags.
I embrace progressive enhancement where possible, all of my blogs/sites will load and function without Javascript. I'm not going to serve alternative HTML in a scenario like this. There has to be a give and take towards Lynx supporting objectively valid pure HTML content.
It wouldn't violate any of Lynx's pure-text principles to parse modern HTML correctly.
Earlier quoted context omitted.
The average user, by Google's own studies, wants a faster experience. By far. Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older "apps" were running on computers which were orders of magnitude slower than our cell phones today. I've worked with 2 companies now where their users (and both these companies have us…
Yes and no: Ajax allows interactive (snappier/faster) behavior in most cases, especially for complex interaction flows. Using the minimal html Gmail interface vs the modern one, the modern one is quicker for complex interactions because I end up loading fewer pages,even if the average load is more expensive.
Earlier quoted context omitted.
It doesn't feel faster to me. And that's the case with Ajax in general - in principle , it can allow for snappier, faster experience. In practice, it rarely does.
It depends on the application though. Mapping apps (e.g google maps) without ajax are awful . Even basic UIs like filtering can be bad if you want to change multiple filters, and you have to wait for a whole page load in between each change (page load times for pages with filters are often slow as they're performing complex queries). It's a case of different things being appropriate for different use cases I think. T…
Earlier quoted context omitted.
> If there weren't plenty of good, modern options I would be all for Links but there are, so I'm not. What are the good, modern alternatives to Lynx?
Firefox and Chrome both have mature accessibility API implementations at this point. Edge is also at least okay. Internet Explorer has worked forever. You then couple those with a screen reader--most commonly Jaws or NVDA--and you get something that very much resembles Emacs or what have you: there's around 50 or 60 keystrokes I use on a regular basis. It's like a local client-server model (indeed documentation on th…
I was interested in hearing about browsers that do what Lynx does, but are better. Unfortunately, the browsers you mention are graphical, and so are not Lynx replacements.