dbushell

> This API collates information about people from multiple web origins, which could be a significant risk to their privacy. To manage this risk, the information that is gathered is aggregated using an aggregation service that is trusted by the user-agent to perform aggregation within strict limits. Noise is added to the aggregates produced by this service to provide differential privacy. Websites may select an aggregation service from the list of approved aggregation services provided by the user-agent.

Now that Google have back-tracked on removing 3rd-party cookies[1] I can't help but think any attempts to standardise tracking APIs is only going to add more data to the mix. This seems like yet another source to abuse.

[1] https://privacysandbox.com/news/privacy-sandbox-next-steps/

I'm curious if anyone here is hosting any user-facing websites or services on Deno Deploy? Where response times matter. I still have a handful of "if this, then that" type functions I POST to and forget. I tried to host small websites on Deploy but the cold start times and "time to first byte" performance were kinda brutal early on, even for my closest region.

thanks!

Indeed. It's the user's browser and experience, it's not up to the website owner. But it's frustrating to get bug reports when a 3rd party extension is the problem, not the website. Many visitors will just bounce blaming the website too.

yep, it's in Grammarly's interest to namespace or scope their CSS in a way that doesn't conflict. Not doing it adequately goes both ways, website CSS could break their extension, or their extension could break the website.

If only I could opt-out, disable, or uninstall those used by visitors to my website when the extension breaks it :(

How do you deal with hostile browser extensions?

It sits underneath the first paragraph on smaller screens (I've since added an extra sentence at the beginning.) It was unintentionally confusing in this case.

yes

The "Take Action" link opens a modal giving three options:

1. appeal 2. change name

I forget the third... The appeal asks for links to prove your name like other social profiles, plus an option to upload 1 document (e.g. photo ID / passport). After submitting you're told to wait and find out the outcome of the appeal. They also link to the rabbit hole that is Google "help" pages.

Thanks, great explanation. I'm finding Ember Data really nice to use from my experience so far. I look forward to seeing an official release and documentation. For the time being the source code is heavily commented if you want to see what can be extended.

Correct.

jQuery animate (and any JS animation) iterates over CSS properties by updating an elements style attribute. Updating the DOM at this rate forces repaint/reflows and is rarely going to perform well.

CSS transitions/transforms let the browser render once on separate layers. The animation frames can then be composited faster (and accelerated on the GPU).

Paul Irish has a great demo: http://paulirish.com/2012/why-moving-elements-with-translate...

jQuery animate is terrible for performance. The demo lags at a few frames per second (and I'm testing on a Nexus 4).

CSS transitions are the method for this. Not without their own caveats, but usable. I've written extensively on the subject with this exact implementation of an off-canvas menu: http://coding.smashingmagazine.com/2013/01/15/off-canvas-nav...

Fully minified and gzip compressed I've found SVG to be neither smaller nor larger than an alternate PNG version. It really details on the complexity with the image itself. Obviously you get the scalability factor for free. I suspect mutliple SVG files inline of the same document will benefit for a small compression boost.

Sending them inline of HTML simply reduces HTTP requests. Latency there is a big bottleneck. You have to balance that with the fact that the browser can't cache the SVG for use across multiple pages, like it can with a background-image or <img> element.

You might enjoy my attempt. No jQuery dependency and binding to an input field is optional.

https://github.com/dbushell/Pikaday

That doesn't make their advice wrong.

Quite a bit hand-wavy! Only because SVG support is easily detected with the likes of Modernizr http://modernizr.com/. Background images with CSS are very simple to provide both SVG and a raster fallback graphic for. Image elements aren't as simple, but I'd suggest defaulting to SVG in both cases and replacing the source if support doesn't exist. That way the issue with eventually disappear alongside legacy browser usage.

As you said the benefits of high pixel densities are visually huge. A small and temporary JS hack is a price worth paying in my opinion.