(As somebody working in webdev): Ah, Safari/Webkit slander, the most correct and justified slander. Though supposedly (?) Safari has become a lot better since last year's nightlies or so I've been told.
To elaborate on my hostility against WebKit: WebKit does nothing but get in my way whenever I work on literally any website.
When I rewrote nouveau's website in late 2023, it worked perfectly fine on Firefox (Gecko) and Chromium (Blink), but was broken on Epiphany/Safari (WebKit). The logo, which is an SVG, would not adapt to dark style, because, to this day, WebKit still does not support prefers-color-scheme in SVGs. So, as a workaround, instead of having one SVG file for both color schemes, we have one SVG file for light style, and one for dark style. Edit: This feature is currently considered nonstandard and is only written as a draft. WebKit behaves appropriately, see: estradiol.city/@ity/1150068605…
Another example: On my website, some elements are intentionally made to be unselectable using user-select: none;, such as the command-line decoration and the “Table of Contents” text, but on WebKit, these elements continue to be selectable because it does not properly support the user-select property. And no, using the vendor prefix is completely unacceptable, especially considering that it behaves differently.
Lastly, WebKit does not yet fully support the ::marker pseudo-element. This means, in my articles, numbered list items in the table of contents are completely wrong and don't represent the same numbers as headings.
Apple has consistently proved that they don't care about WebKit, because otherwise browsers like Safari and Epiphany would have worked as well as they do on Firefox and Chromium. There's absolutely no reason to force WebKit onto iOS and iPadOS if they're not even willing to invest in WebKit. Likewise, Apple employees working on WebKit should really stop calling themselves “WebKit evangelists” if their inferior engine regularly gets in developers’ way. So yes, WebKit sucks, and this is 100% on Apple. I don't care about being harsh. Apple is a multi-trillion dollar company, most of which came from exploiting people. The least they can do is invest in their projects.
For clarity, my hostility towards WebKit is purely targeted at Apple's lack of involvement with WebKit, not the browsers using it.
The ::marker CSS pseudo-element selects the marker box of a list item, which typically contains a bullet or number. It works on any element or pseudo-element set to display: list-item, such as the and elements.
To elaborate on my hostility against WebKit: WebKit does nothing but get in my way whenever I work on literally any website.
When I rewrote nouveau's website in late 2023, it worked perfectly fine on Firefox (Gecko) and Chromium (Blink), but was broken on Epiphany/Safari (WebKit). The logo, which is an SVG, would not adapt to dark style, because, to this day, WebKit still does not support prefers-color-scheme in SVGs. So, as a workaround, instead of having one SVG file for both color schemes, we have one SVG file for light style, and one for dark style. Edit: This feature is currently considered nonstandard and is only written as a draft. WebKit behaves appropriately, see: estradiol.city/@ity/1150068605…
Another example: On my website, some elements are intentionally made to be unselectable using user-select: none;, such as the command-line decoration and the “Table of Contents” text, but on WebKit, these elements continue to be selectable because it does not properly support the user-select property. And no, using the vendor prefix is completely unacceptable, especially considering that it behaves differently.
Lastly, WebKit does not yet fully support the ::marker pseudo-element. This means, in my articles, numbered list items in the table of contents are completely wrong and don't represent the same numbers as headings.
Apple has consistently proved that they don't care about WebKit, because otherwise browsers like Safari and Epiphany would have worked as well as they do on Firefox and Chromium. There's absolutely no reason to force WebKit onto iOS and iPadOS if they're not even willing to invest in WebKit. Likewise, Apple employees working on WebKit should really stop calling themselves “WebKit evangelists” if their inferior engine regularly gets in developers’ way. So yes, WebKit sucks, and this is 100% on Apple. I don't care about being harsh. Apple is a multi-trillion dollar company, most of which came from exploiting people. The least they can do is invest in their projects.
For clarity, my hostility towards WebKit is purely targeted at Apple's lack of involvement with WebKit, not the browsers using it.
The ::marker CSS pseudo-element selects the marker box of a list item, which typically contains a bullet or number. It works on any element or pseudo-element set to display: list-item, such as the and elements.
That's not normative, that's descriptive of Firefox & Chromium behavior (the purpose of mdn is to be descriptive rather than normative, unlike the specifications themselves)
MDN even warns that "Respects color-scheme inherited from parent" is "non-standard" and to "Expect poor cross-browser support"
The feature itself is listed as "Full support" for Safari/WebKit on that site.
The feature is also considered "unfinished" by W3C, and W3C in the specification warns that
Information about a user can be used as an active fingerprinting vector. Analysis of impact pending, more information to be provided before spec is published. User agents and developers implementing this specification need to be aware of this vector and take it into consideration when deciding whether to use the feature. Specifically prefers-reduced-motion, prefers-color-scheme and prefers-reduced-data are currently of concern for exploitation.
W3C further comments on the specific feature that
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)
I have no idea what policy WebKit has for standards, but the only standard it seems to violate is one that begins with this statement:
This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
So while it is certainly dumb that it has not been fixed yet, it feels a bit of a stretch to call it a violation of web standards, imo.
I wonder how difficult it is to fix, I've been meaning to try to get into WebKit stuff
When you state "failed to align with established web standards", are you referring to standards with a specification document, or conventions (aka behavior of Firefox & Chromium) ?
I was unable to find any references stating that WebKit's behavior at bugs.webkit.org/show_bug.cgi?i… violates any such spec
I'll still have to look into the remaining ones, but I am curious if you have any references that state that it's a spec violation (I skimmed the W3C IRC logs, the MQ5 spec, the W3C GitHub issue, etc)
Wdym it doesn't support it? I just tested in epiphany - the prefers-color-scheme selector is available, and is set to dark when Epiphany is dark, and light when it's light
visit nouveau.freedesktop.org, open the developer tools, go to the "Sources" tab, open "style.css", remove the line containing "--logo-path: url('logo-light.svg');" (line 55), and replace the line from "--logo-path: url('logo-dark.svg');" with "--logo-path: url('logo.svg');" (line 17)
Then, switch between light and dark styles, and you'll notice that the SVG's text doesn't adapt
("logo.svg" is the SVG file that embeds prefers-color-scheme to adapt to light and dark styles)
I am extremely confused. You state that WebKit fails to align to web standards. Are you saying that the first issue you listed is *not* what you are talking about when you say that WebKit fails to align to web standards?
@ity to me, not supporting a standard is the equivalent of not aligning with it. So to answer your question, it's an example of WebKit failing to align with web standards
That said, since "align" seems to be ambiguous, it could as well be "failed to align with or support established web standards"
I can only find a link to the WebKit bug tracker, then two SVG links, plus ofc a link to your blog post, which I read and I cannot find any links to any standards there either
The WebKit bug tracker links to a W3C discussion page with inconclusive results (as far as I can tell, they arrived at the conclusion that SVGs MAY inherit the value, depending on per-browser decisions). I cannot find anywhere in the Media Query Level 5 specification, which defines the semantics of the prefers-color-scheme media query, a statement that it MUST inherit its value. Just what its value means without further specification of its behavior, plus one big red box stating to be careful with implementing it due to fingerprinting considerations.
(Highlighted keywords MAY and MUST in this fedi post to be interpreted as-defined in RFC2119 - the spec & discussions do not seem to use RFC2119 in parts relevant to the prefers-color-scheme media query)
So, I am truly at a loss here. The prefers-color-scheme Media Query is
Implemented
Behaves how the W3C specification defining it prescribes it should
Does not behave in a predictable manner
Does not behave in the same way as Chromium & Firefox do
I might be missing some different specification or a part of the MQ5 specification that states that it SHOULD or MUST behave the way you and many others are expecting, which is why I am asking if you know of any, since you are stating it does not support a specification properly
the only thing I can do is link to developer.mozilla.org/en-US/do…. Other than that, I don't know what else there is to say...
> plus ofc a link to your blog post, which I read and I cannot find any links to any standards there either
Ah, sorry for that. The blog post isn't used as a source/reference to prove a point. It's just a link in case people wanted to read about the rewrite. I removed that link
The prefers-color-scheme CSS media feature is used to detect if a user has requested light or dark color themes.
A user indicates their preference through an operating system setting (e.g., light or dark mode) or a user agent setting.
That's not normative, that's descriptive of Firefox & Chromium behavior (the purpose of mdn is to be descriptive rather than normative, unlike the specifications themselves)
MDN even warns that "Respects color-scheme inherited from parent" is "non-standard" and to "Expect poor cross-browser support"
The feature itself is listed as "Full support" for Safari/WebKit on that site.
The feature is also considered "unfinished" by W3C, and W3C in the specification warns that
Information about a user can be used as an active fingerprinting vector. Analysis of impact pending, more information to be provided before spec is published. User agents and developers implementing this specification need to be aware of this vector and take it into consideration when deciding whether to use the feature. Specifically prefers-reduced-motion, prefers-color-scheme and prefers-reduced-data are currently of concern for exploitation.
W3C further comments on the specific feature that
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)
I have no idea what policy WebKit has for standards, but the only standard it seems to violate is one that begins with this statement:
This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
So while it is certainly dumb that it has not been fixed yet, it feels a bit of a stretch to call it a violation of web standards, imo.
I wonder how difficult it is to fix, I've been meaning to try to get into WebKit stuff
@ity I see, I stand corrected. Thanks for being patient with me and for putting your time researching and reading everything thoroughly. I edited my post, which hopefully addresses the misinformation
yeah I wish webkit was better. I really like using epiphany as my web browser for sites that need JavaScript (otherwise I use emacs). I have Icecat and ungoogled chromium as well installed because you know there are always situations where you need to use those because other browsers won't work. The modern web just sucks tbh.
❌ Making your website compatible with, to this day, still one of the most performant browser engines out there ✅ Crying about it
With the amount of frameworks'n'shit out there, it's not that hard to make your stuff webkit compatible. If you can't be bothered to do it, that's a problem with the web dev, not the people visiting your website.
To elaborate on my hostility against WebKit: WebKit does nothing but get in my way whenever I work on literally any website.
When I rewrote nouveau's website in late 2023, it worked perfectly fine on Firefox (Gecko) and Chromium (Blink), but was broken on Epiphany/Safari (WebKit). The logo, which is an SVG, would not adapt to dark style, because, to this day, WebKit still does not support prefers-color-scheme in SVGs. So, as a workaround, instead of having one SVG file for both color schemes, we have one SVG file for light style, and one for dark style. Edit: This feature is currently considered nonstandard and is only written as a draft. WebKit behaves appropriately, see: estradiol.city/@ity/1150068605…
Another example: On my website, some elements are intentionally made to be unselectable using user-select: none;, such as the command-line decoration and the “Table of Contents” text, but on WebKit, these elements continue to be selectable because it does not properly support the user-select property. And no, using the vendor prefix is completely unacceptable, especially considering that it behaves differently.
Lastly, WebKit does not yet fully support the ::marker pseudo-element. This means, in my articles, numbered list items in the table of contents are completely wrong and don't represent the same numbers as headings.
Apple has consistently proved that they don't care about WebKit, because otherwise browsers like Safari and Epiphany would have worked as well as they do on Firefox and Chromium. There's absolutely no reason to force WebKit onto iOS and iPadOS if they're not even willing to invest in WebKit. Likewise, Apple employees working on WebKit should really stop calling themselves “WebKit evangelists” if their inferior engine regularly gets in developers’ way. So yes, WebKit sucks, and this is 100% on Apple. I don't care about being harsh. Apple is a multi-trillion dollar company, most of which came from exploiting people. The least they can do is invest in their projects.
For clarity, my hostility towards WebKit is purely targeted at Apple's lack of involvement with WebKit, not the browsers using it.
The ::marker CSS pseudo-element selects the marker box of a list item, which typically contains a bullet or number. It works on any element or pseudo-element set to display: list-item, such as the and elements.
to be clear; I’m not trying to defend WebKit here. It has its flaws, and I am well aware of it. Hell, almost every time I quit epiphany, it’s through it crashing, and not me pressing the cross button or alt+f4.
However, a good web dev should be able to circumvent those flaws, instead of flat out saying that the visitors shouldn’t use x or y browser. A website should properly work regardless of the user's preferences, even if some design features aren’t there. In your case, I don’t see how disabling user actions is any different from using a span and a div… edit: misread original post. How is using the vendor prefix unacceptable though? It is definitely not the first occurrence of that in the world of frontend dev.
I have made no effort to make derg.ch WebKit-compatible, I’ve simply used tailwind. And yet, all of it works on WebKit.
Identically, at work, I’ve been working on websites of all different natures since a year now (always using tailwind though). I have only encountered once an issue with WebKit, namely the date picker (which seems to be wildly unstandardised among any browser).
> How is using the vendor prefix unacceptable though? It is definitely not the first occurrence of that in the world of frontend dev.
Just because it's not the first occurrence, it doesn't excuse that such a basic feature is not available in an engine maintained by a multi-trillion dollar company. It's been available for around a decade, which only makes it more inexcusable.
> However, a good web dev should be able to circumvent those flaws, instead of flat out saying that the visitors shouldn’t use x or y browser. A website should properly work regardless of the user's preferences, even if some design features aren’t there.
Nope, no matter how good or bad you are as a web developer, you shouldn't be in a position where you need to consider an outdated engine that is regularly forced onto users due to market share abuse.
Everything my website uses is documented in MDN, without any comment stating "nonstandard". Basically, my website is as 'standard-respecting' as it can be. The only requirement for my website is to have a browser that uses an actual web engine underneath.
If you look through my website's CSS, you'll notice that it does a lot of calculations underneath, either to maintain fluidity and alignment when resizing, maintain color contrast no matter the color you throw at it (see social.treehouse.systems/@TheE…), or whatever the reason. The last thing I want is to worry about some engine maintained by a large company that does not even put the effort to comply with or support standards.
Attached: 1 image
Okay, this keeps getting better and better. First, my website adapted to the user's accent color, assuming the browser supports the feature.
what triggers me about WebKit is how far behind it is as a technology and Apple's lack of involvement, despite being a multi-trillion dollar company. I have nothing against the browsers you mentioned
FineFindus
in reply to TheEvilSkeleton • • •Reminds me of the story how YouTube engineers tried to kill Internet Explorer: blog.chriszacharias.com/a-cons…
Noé Lopez
in reply to TheEvilSkeleton • • •Phil
in reply to TheEvilSkeleton • • •🌸 lily 🏳️⚧️ θΔ ⋐ & ∞
in reply to TheEvilSkeleton • • •mfw
TheEvilSkeleton
in reply to 🌸 lily 🏳️⚧️ θΔ ⋐ & ∞ • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •@ity @tauon social.treehouse.systems/@TheE…
TheEvilSkeleton
2025-08-09 21:26:36
TheEvilSkeleton
in reply to TheEvilSkeleton • • •To elaborate on my hostility against WebKit: WebKit does nothing but get in my way whenever I work on literally any website.
When I rewrote nouveau's website in late 2023, it worked perfectly fine on Firefox (Gecko) and Chromium (Blink), but was broken on Epiphany/Safari (WebKit). The logo, which is an SVG, would not adapt to dark style, because, to this day, WebKit still does not supportEdit: This feature is currently considered nonstandard and is only written as a draft. WebKit behaves appropriately, see: estradiol.city/@ity/1150068605…prefers-color-schemein SVGs. So, as a workaround, instead of having one SVG file for both color schemes, we have one SVG file for light style, and one for dark style.Another example: On my website, some elements are intentionally made to be unselectable using
user-select: none;, such as the command-line decoration and the “Table of Contents” text, but on WebKit, these elements continue to be selectable because it does not properly support theuser-selectproperty. And no, using the vendor prefix is completely unacceptable, especially considering that it behaves differently.Lastly, WebKit does not yet fully support the
::markerpseudo-element. This means, in my articles, numbered list items in the table of contents are completely wrong and don't represent the same numbers as headings.Apple has consistently proved that they don't care about WebKit, because otherwise browsers like Safari and Epiphany would have worked as well as they do on Firefox and Chromium. There's absolutely no reason to force WebKit onto iOS and iPadOS if they're not even willing to invest in WebKit. Likewise, Apple employees working on WebKit should really stop calling themselves “WebKit evangelists” if their inferior engine regularly gets in developers’ way. So yes, WebKit sucks, and this is 100% on Apple. I don't care about being harsh. Apple is a multi-trillion dollar company, most of which came from exploiting people. The least they can do is invest in their projects.
For clarity, my hostility towards WebKit is purely targeted at Apple's lack of involvement with WebKit, not the browsers using it.
#WebKit #Apple #iOS #iPadOS #WebDev #Web #Safari
::marker - CSS | MDN
MDN Web Docsity [unit X-69] - VIOLENT FUCK
2025-08-10 22:37:06
TheEvilSkeleton reshared this.
ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •I was unable to find any references stating that WebKit's behavior at bugs.webkit.org/show_bug.cgi?i… violates any such spec
I'll still have to look into the remaining ones, but I am curious if you have any references that state that it's a spec violation (I skimmed the W3C IRC logs, the MQ5 spec, the W3C GitHub issue, etc)
199134 – SVG images don't support prefers-color-scheme adjustments when embedded in a page
WebKit BugzillaTheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •prefers-color-schemeselector is available, and is set to dark when Epiphany is dark, and light when it's lightTheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •visit nouveau.freedesktop.org, open the developer tools, go to the "Sources" tab, open "style.css", remove the line containing "
--logo-path: url('logo-light.svg');" (line 55), and replace the line from "--logo-path: url('logo-dark.svg');" with "--logo-path: url('logo.svg');" (line 17)Then, switch between light and dark styles, and you'll notice that the SVG's text doesn't adapt
("logo.svg" is the SVG file that embeds
prefers-color-schemeto adapt to light and dark styles)nouveau · freedesktop.org
freedesktop.orgity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •ity [unit X-69] - VIOLENT FUCK
in reply to ity [unit X-69] - VIOLENT FUCK • • •TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •@ity to me, not supporting a standard is the equivalent of not aligning with it. So to answer your question, it's an example of WebKit failing to align with web standards
That said, since "align" seems to be ambiguous, it could as well be "failed to align with or support established web standards"
ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •I cannot find it
I can only find a link to the WebKit bug tracker, then two SVG links, plus ofc a link to your blog post, which I read and I cannot find any links to any standards there either
The WebKit bug tracker links to a W3C discussion page with inconclusive results (as far as I can tell, they arrived at the conclusion that SVGs MAY inherit the value, depending on per-browser decisions). I cannot find anywhere in the Media Query Level 5 specification, which defines the semantics of the
prefers-color-schememedia query, a statement that it MUST inherit its value. Just what its value means without further specification of its behavior, plus one big red box stating to be careful with implementing it due to fingerprinting considerations.(Highlighted keywords MAY and MUST in this fedi post to be interpreted as-defined in RFC2119 - the spec & discussions do not seem to use RFC2119 in parts relevant to the
prefers-color-schememedia query)So, I am truly at a loss here. The
prefers-color-schemeMedia Query isI might be missing some different specification or a part of the MQ5 specification that states that it SHOULD or MUST behave the way you and many others are expecting, which is why I am asking if you know of any, since you are stating it does not support a specification properly
TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •the only thing I can do is link to developer.mozilla.org/en-US/do…. Other than that, I don't know what else there is to say...
> plus ofc a link to your blog post, which I read and I cannot find any links to any standards there either
Ah, sorry for that. The blog post isn't used as a source/reference to prove a point. It's just a link in case people wanted to read about the rewrite. I removed that link
prefers-color-scheme - CSS | MDN
MDN Web Docsity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •That's not normative, that's descriptive of Firefox & Chromium behavior (the purpose of mdn is to be descriptive rather than normative, unlike the specifications themselves)
MDN even warns that "Respects color-scheme inherited from parent" is "non-standard" and to "Expect poor cross-browser support"
The feature itself is listed as "Full support" for Safari/WebKit on that site.
The feature is also considered "unfinished" by W3C, and W3C in the specification warns that
W3C further comments on the specific feature that
There seems to be a draft asking for it in "Secure Animated mode" -> github.com/w3c/csswg-drafts/co…
Which has not made it to the current latest Working Draft of MQ5 (w3.org/TR/mediaqueries-5/), and is only available in the Editor's Draft (drafts.csswg.org/mediaqueries-…)
MQ5 itself is not finalized and is very much experimental.
This has been okayed into being merged into WebKit at 2022 by one of the WebKit maintainers github.com/w3c/csswg-drafts/is…
I have no idea what policy WebKit has for standards, but the only standard it seems to violate is one that begins with this statement:
So while it is certainly dumb that it has not been fixed yet, it feels a bit of a stretch to call it a violation of web standards, imo.
I wonder how difficult it is to fix, I've been meaning to try to get into WebKit stuff
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?
emilio (GitHub)TheEvilSkeleton
in reply to ity [unit X-69] - VIOLENT FUCK • • •ity [unit X-69] - VIOLENT FUCK
in reply to TheEvilSkeleton • • •🥺 always, mew ! I got nerd sniped haha
I even cloned WebKit (it's compiling now) and I'll see if I can patch it. Unsure. Hope it isn't more complex than Firefox.
Dr. Dek 👨🚀🐧🚀 )
in reply to TheEvilSkeleton • • •Konakona
in reply to TheEvilSkeleton • • •Dråfølin the Derg
in reply to TheEvilSkeleton • • •❌ Making your website compatible with, to this day, still one of the most performant browser engines out there
✅ Crying about it
With the amount of frameworks'n'shit out there, it's not that hard to make your stuff webkit compatible. If you can't be bothered to do it, that's a problem with the web dev, not the people visiting your website.
TheEvilSkeleton
in reply to Dråfølin the Derg • • •@drafolin social.treehouse.systems/@TheE…
You're defending an indefensible position, sorry
TheEvilSkeleton
2025-08-09 21:26:36
Dråfølin the Derg
in reply to TheEvilSkeleton • • •to be clear; I’m not trying to defend WebKit here. It has its flaws, and I am well aware of it. Hell, almost every time I quit epiphany, it’s through it crashing, and not me pressing the cross button or alt+f4.
However, a good web dev should be able to circumvent those flaws, instead of flat out saying that the visitors shouldn’t use x or y browser. A website should properly work regardless of the user's preferences, even if some design features aren’t there. In your case,
I don’t see how disabling user actions is any different from using a span and a div…edit: misread original post. How is using the vendor prefix unacceptable though? It is definitely not the first occurrence of that in the world of frontend dev.I have made no effort to make derg.ch WebKit-compatible, I’ve simply used tailwind. And yet, all of it works on WebKit.
Identically, at work, I’ve been working on websites of all different natures since a year now (always using tailwind though). I have only encountered once an issue with WebKit, namely the date picker (which seems to be wildly unstandardised among any browser).
Dråfølin - Tech derg!
derg.chTheEvilSkeleton
in reply to Dråfølin the Derg • • •> How is using the vendor prefix unacceptable though? It is definitely not the first occurrence of that in the world of frontend dev.
Just because it's not the first occurrence, it doesn't excuse that such a basic feature is not available in an engine maintained by a multi-trillion dollar company. It's been available for around a decade, which only makes it more inexcusable.
> However, a good web dev should be able to circumvent those flaws, instead of flat out saying that the visitors shouldn’t use x or y browser. A website should properly work regardless of the user's preferences, even if some design features aren’t there.
Nope, no matter how good or bad you are as a web developer, you shouldn't be in a position where you need to consider an outdated engine that is regularly forced onto users due to market share abuse.
Everything my website uses is documented in MDN, without any comment stating "nonstandard". Basically, my website is as 'standard-respecting' as it can be. The only requirement for my website is to have a browser that uses an actual web engine underneath.
If you look through my website's CSS, you'll notice that it does a lot of calculations underneath, either to maintain fluidity and alignment when resizing, maintain color contrast no matter the color you throw at it (see social.treehouse.systems/@TheE…), or whatever the reason. The last thing I want is to worry about some engine maintained by a large company that does not even put the effort to comply with or support standards.
TheEvilSkeleton (@TheEvilSkeleton@treehouse.systems)
Treehouse Mastodonsarah tonin
in reply to TheEvilSkeleton • • •TheEvilSkeleton
in reply to sarah tonin • • •