submitted 9 months ago* (last edited 9 months ago) by to c/webdev@programming.dev
 

You can now jump to a CSS custom property's definition from within the var() function in style rules.

On clicking the arrow here:

You get jumped to where it's defined, and it's briefly highlighted.

The events tooltip in the Inspector now shows a badge besides custom events, making it easier to differentiate them from built-in events.

I think it's the "User-defined" badges I circled:

Full release notes

[–] 58 points 10 months ago (26 children)

The post on Mastodon has a screenshot of the post edit history:

Screenshot of a forum post, showing the versions before and after an edit. The sentence "I am queer, I am technically a furry too" was edited into "I am technically a furry too"

And a copy-pasted response from a moderator (the most relevant bit):

So in my opinion, if your intention was to show political support for diversity, you should avoid using this flag. This will allow us to refuse the use of a flag for instance saying 'non-queer', If we allow your flag, then we have to admit also other similar political flags, both supporting and opposing diversity.

  • source
  • parent
  • context
  • [–] 1 point 11 months ago*

    The silent keys part were a disappointment, it is way louder than the previous one (had cherry MX silent keys). However, the rest is pretty nice.

    Did you try O-rings? They dampen the sound of the keycap hitting the base of the keyboard.

    https://www.gloriousgaming.com/en-eu/products/glorious-mx-o-ring-switch-dampeners

    Maybe it won't matter with those switches, but they also helped with the switch actuation of my MX Blues. I noticed some high-pitch sound from the springs, and that also got dampened.

  • source
  • parent
  • context
  •  

    I'm posting this in case it helps anyone, but also for a sanity check (anyone has a better solution?).

    My issue - using 3rd party packages and SCSS (and the solution in the docs)

    Using Bootstrap as an example:

    Running php bin/console importmap:require bootstrap doesn't import SCSS.

    The easy provided alternative is installing as Composer package with composer require twbs/bootstrap, and importing the SCSS from there. This happens to work for Bootstrap, but may not be an option for others (there may not be a composer package)

    My alternative

    CSS

    1. Install (at least these) third party packages using npm like usual.
    2. In the app's SCSS file, import using the relative path to the node_modules's bootstrap: @import '../../../node_modules/bootstrap/scss/bootstrap';

    JS

    1. In config/packages/asset_mapper.yaml add the path specifically for the third-party package to be included. My file is looking like this:
    framework:
        asset_mapper:
            # The paths to make available to the asset mapper.
            paths:
                - assets/
                - node_modules/bootstrap/dist/js
            excluded_patterns:
                - 'assets/styles/scss/**/*'
            missing_import_mode: strict
    
    when@prod:
        framework:
            asset_mapper:
                missing_import_mode: warn
    
    
    1. In importmap.php add the path ( and with entrypoint set to true). This only works because of the previous step.
    
    return [
        'app' => [
            'path' => './assets/app.js',
            'entrypoint' => true,
        ],
        // ...
        'bootstrap' => [
            'path' => './node_modules/bootstrap/dist/js/bootstrap.bundle.min.js',
            'entrypoint' => true,
        ],
    ];
    
    1. Import in the template as usual
    {% block importmap %}
        {{ importmap([
            'bootstrap',
            'app',
        ]) }}
    {% endblock %}
    
    [–] 7 points 1 year ago

    To note that there is one positive type of gentrification that has appeared in Portugal. In the interior there are many small villages that are mostly empty and which have been a target for some richer immigrants.

    Hotels and Airbnbs too, it's not an issue when most of the houses are empty anyway.

  • source
  • parent
  • context
  • [–] 4 points 1 year ago* (1 child)

    Funny you call it magic, what actually does the conversion is Imagick.

    In my project I have it integrated in the upload process. You upload a PNG/JPG and it does its thing. Since it's written in PHP (my project), and PHP has an extension to call Imagick, I didn't need to write any complicated code.

    You can see on this page if your programming language of choice has any integration with Imagick.

    But there's always the command line interface. Depending on your process it may be easier to create a script to "convert all images in a folder", for example.

  • source
  • parent
  • context
  • [–] 4 points 1 year ago* (3 children)

    but 2KB vs 200KB is paltry on even a terrible connection in the 2000s).

    You still need to resize the images and choose the right ones (even if only for the device's performance).

    So we might as well do that small extra step and add conversion to the process.

    What I really wish is that we could get more browsers, sites, and apps to universally support more modern formats to replace the overly bloated terribly performing and never correctly pronounced animated formats like GIF with something else like AVIF, webm, webp (this was a roughly ~60MB GIF, and becomes a 1MB WEBP with better performance), or even something like APNG…

    Isn't that the users' fault? And of the websites for allowing those huge GIFs.

    Apparently browsers have supported MP4 for a long time.

    https://caniuse.com/mpeg4

  • source
  • parent
  • context
  • [–] 7 points 1 year ago (2 children)

    Even using the highest compression levels, barely any difference. Not worth it

    If I understand correctly gzip, brotli and similar are best used to compress text.

    Font files also shouldn't be compressed. A TTF file compresses a bit, but a WOFF2 file will be even smaller than that (and WOFF2 also doesn't compress well). So might as well use WOFF/WOFF2

  • source
  • parent
  • context
  • [–] 74 points 1 year ago* (41 children)

    I'm working on a project which generates images in multiples sizes, and also converts to WEBP and AVIF.

    The difference in file size is significant. It might not matter to you, but it matters to a lot of people.

    Here's an example (the filename is the width):

    Also, using the <picture></picture> element, if the users' browsers don't support (or block) AVIF/WEBP, the original format is used. No harm in using them.

    (I know this is a meme post, but some people are taking it seriously)

  • source
  • submitted 2 years ago* (last edited 2 years ago) by to c/php@programming.dev
     

    My TLDR is:

    • Their team was using PHP

    • Before doing a complete re-write they evaluated other languages

    • Rust ruled out due to cost/benefit, being the fastest in the list, but also the most complex

    • PHP kept as the main language because:

      • The ecosystem is mature
      • The PHP/Symfony (and Roadrunner) stack meets their high-performance needs
    • Inertia: their team "already had extensive experience" in it

    • They already integrated Go in some microservices

    • They aren't locked to PHP, and will continue to evaluate these programming languages and others

    submitted 2 years ago* (last edited 2 years ago) by to c/linux@programming.dev
     

    The Debian Long Term Support (LTS) Team hereby announces that Debian 10 "buster" support will reach its end-of-life on June 30, 2024, nearly five years after its initial release on July 6th, 2019.

    Starting in July, Debian will not provide further security updates for Debian 10. A subset of "buster" packages will be supported by external parties. Detailed information can be found at Extended LTS.

    The Debian LTS Team will prepare afterwards the transition to Debian 11 "bullseye", the current oldstable release. Thanks to the combined effort of different teams including the Security Team, the Release Team, and the LTS Team, the Debian 11 life cycle will also encompass five years. To make the life cycle of Debian releases easier to follow, the related Debian teams have agreed on the following schedule: three years of regular support plus two years of Long Term Support. The LTS Team will take over support from the Security and the Release Teams on August 14, 2024, three years after the initial release on August 14, 2021. The final point update release for "bullseye" will be published soon after the final Debian 11 Security Advisory (DSA) will be issued.

    Debian 11 will receive Long Term Support until August 31, 2026. The supported architectures remain amd64, i386, arm64 and armhf.

    view more: next ›