home.social

#webcompat — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #webcompat, aggregated by home.social.

  1. Again, unfortunately, I go to use a feature that is apparently now supported in Safari/WebKit (and considered baseline on #MDN), only to discover that one of the features isn’t implemented.

    Today’s example? The <dialog> element.

    After messing around with it and wondering why clicking the backdrop wasn’t closing it even though closedby="any" was set, I find the closedby attribute isn’t implemented at all 😶

    Now I have to add some JS that shouldn’t be needed.

    #WebKit #CSS #WebCompat #Interop

  2. Similarly… foiled again.

    Me, earlier:

    Oh cool, the @ page size descriptor is supported by Chrome, Firefox and Safari! I’ll use it for this print and PDF layout that needs to be A4 landscape.

    Me, now, actually trying it:

    Wait, why isn’t it working? Oh. Oh no. It does not work at all in Safari. And MDN/caniuse.com say it does, but they are wrong (and there is an open issue about it).

    The WebKit bug 63575 is from… 14.5 years ago.

    *dies* 💀

    #WebKit #CSS #WebCompat #Interop #MDN #CanIUse

  3. The year is 2026 and again, today, I still need to use a prefixed version of user-select because WebKit still requires it (-webkit-user-select)…

    bugs.webkit.org/show_bug.cgi?i

    There’s a proposal for it in Interop 2026 and I really hope it was selected (the proposal selection process has already been completed, but the results aren’t expected to be published until next month).

    #WebKit #CSS #WebCompat #Interop

  4. Another great new CSS feature that is starting to be available in more browsers is field-sizing, which allows you to size an input to fit its value with:

    field-sizing: content;

    Great for UI like tags, where you want to be able to type directly into them and have them automatically resize to fit the text.

    (#CanIUse shows the feature as not being available in Safari Technology Preview, even though all the individual child features show that it is available)

    #Interop #WebCompat #CSS

  5. Does anyone actually use the HTML5 `<time>` tag? Well, I do, and I’ve noticed that Safari’s Reader mode strips this semantic tag entirely.

    For example, if you code `<p>iOS 18 was released in <time datetime=“2024-09-16”>2024</time>.</p>`, Reader Mode will render it as, “iOS 18 was released on .”

    User agents don’t need to do anything with this tag. The expected behavior is to ignore it and render it as plain text, as if it were never there. Safari handles it correctly, but turn on Reader and you’ll have some missing dates and confused readers.

    I filed a bug report. If anyone out there can get Apple’s attention on this super-easy fix, that’d be great. feedbackassistant.apple.com/fe

    #Apple #iOS #iOS17 #iOS18 #Safari #HTML5 #SemanticWeb #browsers #bugs #WebCompat

  6. @CenturyAvocado The UI / #XUL application frontendof #PaleMoon is based on #Firefox 28 (before #Australis)

    The #UXP platform/backend Pale Moon is built to work on is hard forked from the ESR 52 branch of the #Mozilla platform (which is erroneously referred to as the "Firefox platform" no thanks to Mozilla focusing so much on the browser to the detriment of building a sustainable XUL platform for other desktop app developers to use), and has since come a long way when it comes to #webcompat

    So "really ancient" can be pretty misleading on the surface.

    @Tourma

  7. A reminder that #CSSnesting is still a working draft in the #W3C under the #CSSWG. Please mind #webcompat when using this relatively new feature. IOW, don't make your #CSS break because you assumed everyone right now is using the latest version of #Chrome / #Chromium, #Firefox, #Safari, or #Edge. They might not even be using a mainstream #browser to visit your website (I am using #PaleMoon for example)... ​:seija_coffee:​

    RE:
    https://c.im/users/youronlyone/statuses/111884225846166170

  8. then implements modern features in Safari/Webkit really slowly

    That's good actually, because you #webdevs keep chasing the shiny new features #Chrome / #Chromium / #Blink is pushing to the #web like fucking fireflies, to the detriment of #webcompat with small #browsers like #PaleMoon, #Basilisk, and others based on #UXP / #Goanna / #XUL (like #SeaMonkey).

    As someone who used to work actively in Pale Moon's development, I am witness to a website that almost broke its #compatibility with my #browser but was stopped because the new feature it wanted to require was not yet available in an old #Safari / #WebKit version they're still supporting.

    So yes, from my point of view, #Apple does more to support the #openweb than #Mozilla and #Firefox (which always follows Chrome whenever it's not controversial) does, even if it didn't intend to. And to be clear, I am not even an Apple fanboy. The only Apple device I own is this ancient 1st generation of the iPad mini. I don't like their ecosystem.

    So it's not a bad take. It's the reality we independent desktop browser developers see in #webdev. ☕

    #MissedQuoteBoost of tenforward.social/@packetcat/1

  9. All major browsers rely on a dark secret: the quirks where native code or the UA stylesheet is varied based on which site you're on.

    They're a hell to debug if you're ever caught in one, but they make for interesting stories!

    Example:
    neugierig.org/software/chromiu

    Fix for SVN deadlink:
    static-codereview.wikimedia.or

    Source code of doom:
    github.com/WebKit/WebKit/blob/

    History:
    github.com/WebKit/WebKit/commi