23 Matching Annotations
  1. Sep 2021
    1. I’ve written a few thousand words on why traditional “semantic class names” are the reason CSS is hard to maintain, but the truth is you’re never going to believe me until you actually try it.
  2. Aug 2021
  3. Mar 2021
  4. Feb 2021
  5. Jan 2021
  6. Nov 2020
    1. While there have always been server listings on joinmastodon.org, this is a break from our previous practice of listing servers. Before the Server Covenant we pulled a list of servers from a 3rd party provider called instances.social. However, instances.social was a 3rd party and automated service. The one thing that it could not do was any kind of quality control as it simply listed every instance submitted–regardless of stability or their code of conduct. As Mastodon has grown it has become increasingly clear that simply listing every possible server was not in our interest as a project, nor was it in the interest in the majority of the communities running Mastodon.

      To some level as an IndieWeb participant I'm doing this more manually by reading and individually adding people and their sites to my personal network one at a time. No one has yet moderated this process and to some extent it's sort of nice to have a more natural discovery process for protecting my own personal network.

    1. I think it is indeed important that we get this right but I'd prefer to hold off on implementing such a system until we have grown contributors and until the project is successful. I expect that after the initial open source release and before the end of the year we'll want to move pretty quickly on this project and I recommend revisiting the RFC based model early next year. Does that sound like a good plan?
  7. Oct 2020
  8. Sep 2020
    1. But when you’re using Svelte within a larger Rails app, you probably already have a CSS system in place and there’s no reason to change that. You can just use the same CSS classes as you do elsewhere in your app, and everything will be fine.
  9. May 2020
    1. Implementing prior blocking and asynchronous re-activation Our prior blocking option prevents the installation of non-exempt cookies before user consent is obtained (as required by EU law) and asynchronously activates (without reloading the page) the scripts after the user consents.To use, you must first enable this feature: simply select the “Prior blocking and asynchronous re-activation” checkbox above before copy and pasting the code snippet into the HEAD as mentioned in the preceding paragraph.
  10. Apr 2020
    1. Allows you to autodetect and limit prior-blocking and cookie consent requests only to users from the EU – where this is a legal requirement – while running cookies scripts normally in regions where you are still legally allowed to do so.
    2. Enables the blocking of scripts and their reactivation only after having collected user consent. If false, the blocked scripts are always reactivated regardless of whether or not consent has been provided (useful for testing purposes, or when you’re working on your project locally and don’t want pageviews to be counted). We strongly advise against setting "priorConsent":false if you need to comply with EU legislation. Please note that if the prior blocking setting has been disabled server side (via the checkbox on the flow page), this parameter will be ineffective whether it’s set to true or false.
  11. Mar 2020
    1. If other third-party tools guarantee not to use cookies, perhaps by providing specific configuration options, they too can be considered to be exempt from prior blocking. This is the case namely with YouTube, which provides a specific feature to prevent the user from being tracked through cookies.
    2. This depends on the legal jurisdiction applicable to your site. In Europe, you’re legally required to block cookie scripts until user consent is obtained. All cookies must be blocked except for those that are exempt.
  12. Sep 2018