If you continue reading that paragraph you'll come to a link for the "supporting the suggested default rendering". ie: being standards compliant.
Upon clicking that link you'll find this:
User agents that are designated as supporting the suggested default rendering must, while so designated, implement the rules in 10 Rendering. That section defines the behavior that user agents are expected to implement.
ie: if you're in standards mode you MUST render below the fold as described (see "Off-Screen" note and various expectations on rendering non-hidden elements)
In quirks mode they're free to do whatever they want. Which mode it's to be rendered in is also something the developer specifies.
There are valid, non-tracking, reasons for lazyloading, however, I agree with you completely. The control scheme should always be User>Developer>User-agent
You're assuming you've got a quality connection that's able to keep up and your WiFi is not dropping packets (common problem in old apartment buildings due to reflection issues/signal conflicts)
I located the specification and this is not exactly being implemented as an HTML attribute. It's being implemented by default and for iframes it has an attribute to turn it off. That attribute does not exist for images.
If they made it the opposite so that you need to specify you want an image/iframe lazyloaded - I'd have no problem with that. The developer is given a new tool to optimize but isn't forced into anything.
Depends on how the developer wants it rendered. There are many techniques which will trigger a repaint cycle on the displayed content to add layers to create an effect. Using jQuery's animate() is a simple example of where the developer would know the load-index that would work best for the animate() cycle but the browser would not know until after it repaints. Currently loading these images off screen allows the animation to execute in a predictable manner once it verifies the images have been rendered.
I should have also quoted this, which specifically addresses the issue of off screen elements:
NOTE: Just being off-screen does not mean the element is not being rendered. The presence of the hidden attribute normally means the element is not being rendered, though this might be overridden by the style sheets.
Actually, if they are designated as "supporting the suggested default rendering" they are required to:
In the absence of style-layer rules to the contrary (e.g., author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification. An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages.
Which would make a load-index attribute worthwhile, so that images load in the order of importance instead of as chosen by the browser. Otherwise you're just deferring the load time until scrolling which means they could scroll right past something that hasn't loaded yet.
If they're doing it as an HTML attribute they should scrap "deferred" and do "load-index". Developer can choose when to load images then and anything below the line can be "deferred" by placing the load-index after the above the line content. It could also be easy to set this via JavaScript for dynamic loading to different screen sizes.
A simple slideshow? A row based thumbnail gallery? There are all sorts of systems that need this kind of functionality for smooth operation. There are alternate ways to do it but they're clumsy and screw up SEO.
The guy was a prolific cheater who use a friend (who's now in jail for fraud) to verify his scores or submitted them himself (he worked for Twin Galaxies). If you watch the video in the article there's a lengthy and thorough pile of evidence.
The after upgrading from 56 to 57 did a bunch of background cleanup/optimization/restructuring of databases. The larger your SQLite data the longer it would take/slower it would be. It was temporary though - had nothing to do with the "process spawning" which is actually just multi-process at work (unless there's a bug I'm not aware of that might cause multi-process to misbehave)
It's really not. The data is always collected even if it's not transmitted so they can backdoor into it via "experiments" which send all sorts of data back regardless of your privacy setting. This includes personally identifiable information as it's exempted from their normal privacy rules.
We value the efficiency gained by correcting for Firefox's deficiencies or optimizing processes that Firefox does a generic version of but can be tweaked for individual use cases or simply by adding new functionality. Something like TableTools which allowed for sorting/filtering/copying of tabled data into various formats, now must be must be manually edited or scripted via Greasemonkey. I've lost *hours* to every few seconds FF57 might have saved me on this alone. SnapLinks - probably my most used extension for using right click to count/copy/open multiple links at once offered great efficiency.
As a web developer it's far more efficient for me to have SSH/FTP/etc all in the browser interface. FireSSH, FireFTP were blown up by FF57 over functionality that could have easily been added to WebExtensions before release of 57. It was a far lower memory footprint than having multiple instances of multiple programs open in addition to the browser to compensate for their loss. To that end I've not seen an improvement in memory footprint, in fact it's been quite the opposite. FF56 and prior I'd run with about 1.2-1.5GB Firefox footprint. I'm routinely over 2.7GB with FF57; to the point of having to kill the process to free up memory, not including the 0.5-1GB in replacement programs.
Then there's things like the Google Advertising Opt-out addon which no longer works. It was literally the only way for a multi-user browser to be consistently opted out. The moment a profile logs in that isn't opted out or browsing while not logged into Google services they'll ignore your opt out and start tracking you again.
It's a bloody usability nightmare because they wanted to rush FF57's features out without properly supporting the addon community. It was a giant "fuck you" to every addon user and addon developer. Had they taken the time to get the bulk of the addons compatible I would have been completely fine with the transition. Their response to one developer about getting sockets added to WebExtensions was literally "it'd be a lot of work" - WONTFIX.
And now they're talking about dropping support for HTTP instead of letting developers decide whether to enable HSTS? They've lost it and think they know better than everyone.
The difference between the low end of the chart and the high end, price wise for "high end CPUs" is $3,748. A 10% drop in performance is up to $2,157 drop in price among the top 10.
The simulation games do not require constant gambling of money - they're just purchase and play therefore never come under section 198 (3) because there's no wagering of money going on. Microsoft Jackpot requires you to continually pay to keep gambling your money away.
You mean the discredited report that was pulled by the company who issued it (Swrve.com)? Regardless, even taking those numbers lets see what happens when you run them:
100k users 99,850 generate $499,250 (average of $5/user) 150 generate $499,250 (average of $3,328.33/user)
A cap of say $1,000/game would mean that you'd be generating $649,250 - a very respectable amount that is easy to make a business case for. You don't run the risk of bad PR, you're on a solid financial foundation that allows you to shed some of those whales over time without destroying your business model - even if you lose your entire 'whale' population it's still financially viable. Yes, the lost revenue potential of $349,250 exists but do you really want to ruin lives/exploit those 150 people to get that money? Statistically, 1-2 of the 150 are able to afford it and the rest are exhibiting the same kinds of addiction you see in gambling.
Slashdot Mirror
If you continue reading that paragraph you'll come to a link for the "supporting the suggested default rendering". ie: being standards compliant.
Upon clicking that link you'll find this:
User agents that are designated as supporting the suggested default rendering must, while so designated, implement the rules in 10 Rendering. That section defines the behavior that user agents are expected to implement.
ie: if you're in standards mode you MUST render below the fold as described (see "Off-Screen" note and various expectations on rendering non-hidden elements)
In quirks mode they're free to do whatever they want. Which mode it's to be rendered in is also something the developer specifies.
There are valid, non-tracking, reasons for lazyloading, however, I agree with you completely. The control scheme should always be User>Developer>User-agent
You're assuming you've got a quality connection that's able to keep up and your WiFi is not dropping packets (common problem in old apartment buildings due to reflection issues/signal conflicts)
I located the specification and this is not exactly being implemented as an HTML attribute. It's being implemented by default and for iframes it has an attribute to turn it off. That attribute does not exist for images.
If they made it the opposite so that you need to specify you want an image/iframe lazyloaded - I'd have no problem with that. The developer is given a new tool to optimize but isn't forced into anything.
Also, it breaks the 5.2 rendering standards
That's not how it works.
Here's the specification: https://docs.google.com/docume...
You should really know what the fuck you're talking about before ranting and calling people "fucktards"
https://www.w3.org/TR/2017/REC...
Depends on how the developer wants it rendered. There are many techniques which will trigger a repaint cycle on the displayed content to add layers to create an effect. Using jQuery's animate() is a simple example of where the developer would know the load-index that would work best for the animate() cycle but the browser would not know until after it repaints. Currently loading these images off screen allows the animation to execute in a predictable manner once it verifies the images have been rendered.
I should have also quoted this, which specifically addresses the issue of off screen elements:
NOTE: Just being off-screen does not mean the element is not being rendered. The presence of the hidden attribute normally means the element is not being rendered, though this might be overridden by the style sheets.
Actually, if they are designated as "supporting the suggested default rendering" they are required to:
In the absence of style-layer rules to the contrary (e.g., author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification.
An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages.
- https://www.w3.org/TR/2017/REC...
- https://www.w3.org/TR/2017/REC...
Which would make a load-index attribute worthwhile, so that images load in the order of importance instead of as chosen by the browser. Otherwise you're just deferring the load time until scrolling which means they could scroll right past something that hasn't loaded yet.
Note the "page" in your comment. Browsers are supposed to render the *entire* page, not just the visible part of it.
If they're doing it as an HTML attribute they should scrap "deferred" and do "load-index". Developer can choose when to load images then and anything below the line can be "deferred" by placing the load-index after the above the line content. It could also be easy to set this via JavaScript for dynamic loading to different screen sizes.
A simple slideshow? A row based thumbnail gallery? There are all sorts of systems that need this kind of functionality for smooth operation. There are alternate ways to do it but they're clumsy and screw up SEO.
Taking control and functionality away from the web developer because browser developers think they know what's best for everyone.
The guy was a prolific cheater who use a friend (who's now in jail for fraud) to verify his scores or submitted them himself (he worked for Twin Galaxies). If you watch the video in the article there's a lengthy and thorough pile of evidence.
From the horse's mouth: https://bugzilla.mozilla.org/s...
The question is, why is Firefox continuing to collect telemetry data when explicitly told not to?
The frontend calls Services.telemetry APIs unconditionally, but they won't send data if you've opted out.
The after upgrading from 56 to 57 did a bunch of background cleanup/optimization/restructuring of databases. The larger your SQLite data the longer it would take/slower it would be. It was temporary though - had nothing to do with the "process spawning" which is actually just multi-process at work (unless there's a bug I'm not aware of that might cause multi-process to misbehave)
It's really not. The data is always collected even if it's not transmitted so they can backdoor into it via "experiments" which send all sorts of data back regardless of your privacy setting. This includes personally identifiable information as it's exempted from their normal privacy rules.
>People like you just like to whine
We value the efficiency gained by correcting for Firefox's deficiencies or optimizing processes that Firefox does a generic version of but can be tweaked for individual use cases or simply by adding new functionality. Something like TableTools which allowed for sorting/filtering/copying of tabled data into various formats, now must be must be manually edited or scripted via Greasemonkey. I've lost *hours* to every few seconds FF57 might have saved me on this alone. SnapLinks - probably my most used extension for using right click to count/copy/open multiple links at once offered great efficiency.
As a web developer it's far more efficient for me to have SSH/FTP/etc all in the browser interface. FireSSH, FireFTP were blown up by FF57 over functionality that could have easily been added to WebExtensions before release of 57. It was a far lower memory footprint than having multiple instances of multiple programs open in addition to the browser to compensate for their loss. To that end I've not seen an improvement in memory footprint, in fact it's been quite the opposite. FF56 and prior I'd run with about 1.2-1.5GB Firefox footprint. I'm routinely over 2.7GB with FF57; to the point of having to kill the process to free up memory, not including the 0.5-1GB in replacement programs.
Then there's things like the Google Advertising Opt-out addon which no longer works. It was literally the only way for a multi-user browser to be consistently opted out. The moment a profile logs in that isn't opted out or browsing while not logged into Google services they'll ignore your opt out and start tracking you again.
SQLite Manager? Gone.
HTML5 Storage viewer? Gone.
CacheViewer? Gone.
It's a bloody usability nightmare because they wanted to rush FF57's features out without properly supporting the addon community. It was a giant "fuck you" to every addon user and addon developer. Had they taken the time to get the bulk of the addons compatible I would have been completely fine with the transition. Their response to one developer about getting sockets added to WebExtensions was literally "it'd be a lot of work" - WONTFIX.
And now they're talking about dropping support for HTTP instead of letting developers decide whether to enable HSTS? They've lost it and think they know better than everyone.
So the SERVER should be using HSTS. The browser should not ignore an instruction to connect via HTTP if that's what is desired.
The difference between the low end of the chart and the high end, price wise for "high end CPUs" is $3,748. A 10% drop in performance is up to $2,157 drop in price among the top 10.
CPU cost $999 so $99.90 refund coming my way - sweet
I'm done arguing with you mate, I'm just sad for those around you who have to deal with such an unethical individual.
The simulation games do not require constant gambling of money - they're just purchase and play therefore never come under section 198 (3) because there's no wagering of money going on. Microsoft Jackpot requires you to continually pay to keep gambling your money away.
You mean the discredited report that was pulled by the company who issued it (Swrve.com)? Regardless, even taking those numbers lets see what happens when you run them:
100k users
99,850 generate $499,250 (average of $5/user)
150 generate $499,250 (average of $3,328.33/user)
A cap of say $1,000/game would mean that you'd be generating $649,250 - a very respectable amount that is easy to make a business case for. You don't run the risk of bad PR, you're on a solid financial foundation that allows you to shed some of those whales over time without destroying your business model - even if you lose your entire 'whale' population it's still financially viable. Yes, the lost revenue potential of $349,250 exists but do you really want to ruin lives/exploit those 150 people to get that money? Statistically, 1-2 of the 150 are able to afford it and the rest are exhibiting the same kinds of addiction you see in gambling.