Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Quirks

github.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: WebKit Quirks

#81

Post by tabtab »

eyelidlessness wrote: post #76
tabtab wrote: post #66

Web UI "standards" are a friggen mess. We really need to rethink it all. For one, if we had a standard state-ful GUI markup language, we wouldn't need to reinvent so many common GUI widgets and idioms using bloated libraries based on JS + DOM. Second, if web standards allowed true absolute positioning of vectors (as an option), then the layout engines could reside on servers, allowing us to choose a layout engine tha…

My goodness a coordinates based layout system would be an enormous step backwards. We’d be back to `m.` subdomains and horizontal scrolling as the norm. The CSS layout standards are certainly not all ideal for my preferences. But the adaptability they afford in fluid layout is far better for real end users than any kind of absolute layout predetermined on a server. We’ve reached a point I can use most of the web on m…

I don't think you understand. The layout engine could be on the server, not "non existent". (Although one could program directly with coordinates if they wanted.) Coordinate based vectors allows the layout engine to be on the server, so that we are not stuck with a one-size-fits all layout engine.

And what's wrong with the "m." standard as an option? For some jobs it's the right tool.

And what's good for public site phone use may not be the right tool for internal CRUD applications. I don't recommend Google make an email client with the additions I suggest, for example. The existing standards are fine for light-input consumer sites, but lousy for productivity-oriented CRUD. I'm not saying get rid of existing standards.

Re: WebKit Quirks

#82

Post by eyelidlessness »

tabtab wrote: post #81
eyelidlessness wrote: post #76

Earlier quoted context omitted.

My goodness a coordinates based layout system would be an enormous step backwards. We’d be back to `m.` subdomains and horizontal scrolling as the norm. The CSS layout standards are certainly not all ideal for my preferences. But the adaptability they afford in fluid layout is far better for real end users than any kind of absolute layout predetermined on a server. We’ve reached a point I can use most of the web on m…

I don't think you understand. The layout engine could be on the server, not "non existent". (Although one could program directly with coordinates if they wanted.) Coordinate based vectors allows the layout engine to be on the server, so that we are not stuck with a one-size-fits all layout engine. And what's wrong with the "m." standard as an option? For some jobs it's the right tool. And what's good for public site…

> I don't think you understand. The layout engine could be on the server, not "non existent".

Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes.

> And what's wrong with the "m." standard as an option? For some jobs it's the right tool.

Instead of getting overly principled about it... one of the reasons it went away was because the heuristics that determined what even is mobile were becoming increasingly wrong. And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users.

Re: WebKit Quirks

#83

Post by tinus_hn »

astrange wrote: post #80
tinus_hn wrote: post #79

Earlier quoted context omitted.

It has been a while since I wrote iOS app code but I’m pretty sure iOS does not, although the libraries provide a mechanism you have to save and restore state yourself. And iOS doesn’t swap, it just kills apps when it needs memory. Anyway, how would you handle connections to remote servers?

iOS does sometimes swap, but only suspended processes, so you won't notice from inside the app.

So how do you know? Is it documented somewhere? All I could find was one unclear mention that could also be about the automatic mechanisms built in to storyboards.

Re: WebKit Quirks

#84

Post by tabtab »

eyelidlessness wrote: post #82
tabtab wrote: post #81

Earlier quoted context omitted.

I don't think you understand. The layout engine could be on the server, not "non existent". (Although one could program directly with coordinates if they wanted.) Coordinate based vectors allows the layout engine to be on the server, so that we are not stuck with a one-size-fits all layout engine. And what's wrong with the "m." standard as an option? For some jobs it's the right tool. And what's good for public site…

> I don't think you understand. The layout engine could be on the server, not "non existent". Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes. > And what's wrong wit…

Re: "Layout on the server means you're laying out without the context of my device or viewport"

Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.)

Re: "And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users."

Without seeing a specific scenario, I cannot comment on possible solutions or standard adjustment proposals. Sometimes people throw the baby out with the bathwater even the baby was fine.

Re: WebKit Quirks

#85

Post by eyelidlessness »

tabtab wrote: post #84
eyelidlessness wrote: post #82

Earlier quoted context omitted.

> I don't think you understand. The layout engine could be on the server, not "non existent". Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes. > And what's wrong wit…

Re: "Layout on the server means you're laying out without the context of my device or viewport" Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.) Re: "And like I said this resulted in a bunch of ridiculous…

> Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details

And what happens when I rotate my device? Or resize my window? Or switch to dark mode? Another request to the server to redraw? What happens when an unknown class of device is encountered? What happens when your assumptions about a known class of device aren’t future proof?

Look I agree that the CSS layout APIs aren’t as good as they could be. But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough (for example many kinds of layout are still very difficult to achieve with dynamic content, even with grid). But what would improve the APIs in my opinion is to design them with common idioms as primitives. Grid has somewhat embraced that by allowing template areas to be named arbitrarily. But the underlying APIs are sprawling and hard to understand even with close attention to the docs/spec.

Re: WebKit Quirks

#86

Post by richdougherty »

duckerude wrote: post #20

> domain.endsWith("hulu.com") Huh, does that mean it would also apply on "thisisnothulu.com"? Most other endsWith calls seem to do e.g. `domain.endsWith(".hulu.com")` to only match subdomains.

I've created a WebKit bug report for this so they can fix it.

https://bugs.webkit.org/show_bug.cgi?id=222130

Re: WebKit Quirks

#87

Post by astrange »

tinus_hn wrote: post #83
astrange wrote: post #80

Earlier quoted context omitted.

iOS does sometimes swap, but only suspended processes, so you won't notice from inside the app.

So how do you know? Is it documented somewhere? All I could find was one unclear mention that could also be about the automatic mechanisms built in to storyboards.

Probably not. It's patented though. https://patents.google.com/patent/US9720617B2/en

Re: WebKit Quirks

#88

Post by dbbk »

tabtab wrote: post #84
eyelidlessness wrote: post #82

Earlier quoted context omitted.

> I don't think you understand. The layout engine could be on the server, not "non existent". Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes. > And what's wrong wit…

Re: "Layout on the server means you're laying out without the context of my device or viewport" Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.) Re: "And like I said this resulted in a bunch of ridiculous…

I really don't think you have thought this through.

Re: WebKit Quirks

#89

Post by spectramax »

We need something new here. This is not scalable. If a group of engineers can't write a new browser in sabbatical, then we need to change what a browser (and the spec) should be.

Access to internet should be simple, not complicated so many can participate and leave control out of big corp.

Re: WebKit Quirks

#90

Post by tabtab »

eyelidlessness wrote: post #85
tabtab wrote: post #84

Earlier quoted context omitted.

Re: "Layout on the server means you're laying out without the context of my device or viewport" Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.) Re: "And like I said this resulted in a bunch of ridiculous…

> Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details And what happens when I rotate my device? Or resize my window? Or switch to dark mode? Another request to the server to redraw? What happens when an unknown class of device is encountered? What happens when your assumptions about a known class of device aren’t future…

> And what happens when I rotate my device? Or resize my window? ... or switch to night mode.

It tells the server and the server re-renders the page. It's a bit slower than client-side adjustments, but worth it for the extra power and control. I don't do those actions very often, do you? The existing tools screw those up anyhow.

> But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough

That makes the client even more bloated, meaning more client version variation and bugs. That exacerbates the problem. By shifting the burden to the server, the client can be simpler and thus less buggy, and the server can pick the best layout engine for the domain instead of being stuck with the client's one-size-fits-all mistake.

Post reply on HN