Closed ocumo closed 4 years ago
chrisdavidmills
commented
4 years ago This seems to work perfectly fine to me. I get the background during and after the click. This is what should happen, and I don't think you are misunderstanding anything. But I do wonder why your browser is not behaving properly.
Do you get the same behavior in othe browsers, like Chrome or Safari?
ocumo
commented
4 years ago Thank you so much for your reply.
As a matter of fact, I had not tried it in another browser, which confirms the thesis that I was missing something basic such as launching Chromium (I am on Linux) and try.. (oops! yes, its embarassing). So I just did it, and it does work as it should. Thus, it must be something on my configuration of Firefox and nothing to do with the MDN article.
After this ultra obvious troubleshooting step (that I should have done in first place), I now will look into all what I have customized in firefox that might provoke this strange behavior. I have for example added some CSS in userChrome.css and userContent.css to improve the dark theme, specifically to have a dark background on new tabs and to avoid the "white flash" when one opens a new tab while in dark mode. There are so many "tips" for that in places like reddit, ghacks or others, that I had to test which ones worked. Still regarding CSS, I also use the Stylus extension to style half a dozen websites to my preferred darker colors, including MDN, but I have already tried disabling the extension and CSS changes to MDN with no success. In none of my rules I (intentionally at least) targetted links or pseudo classes: just background colors and some sizes or display rules.
At first, I wouldn't imagine that any of those rules would prevent or somehow conflict with e.g. the visited: pseudo class, but now I must try and systematically revert all changes and check if any change in particular seems to put things back to normal. This is going to be basic "trial and error" or "brute force" approach at least at the beginning, because as of now I have no other ideas. If I find anything which I can say "this was the cause" I will definitely post it here. I just need a little time to do that.
So, thanks again for pointing my attention in the right direction! PS: I wouldn't close it because I would like to discover the cause and share it if I find it, but if that is not acceptable, please let me know.
chrisdavidmills
commented
4 years ago @ocumo are you familiar with using the browser developer tools in Firefox?
Using those you can inspect that element and find out exactly where CSS is being applied to it from. If you don't have much experience, https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools provides a good intro.
ocumo
commented
4 years ago Excellent advise. Thank you, I will definitely use the dev tools as you suggest. I have used them when playing with CSS changes, though I am still learning my way through them. This is a good chance to gain yet more experience. When there are huge amount of css files in place (e.g. those that apply to the chrome), it becomes a bit more confusing, but then again, I believe it's a matter of trying and getting more familiar. Plus, the MDN documentation is absolutely amazing; I have this website open and use it almost every single day, that's why I try to customize it as pleasant for my eyes as I can. By the way, an additional note: I have also tried the same Stylus rules for MDN in Chromium and still all works perfectly as intended. Just to confirm that I can exclude that from the troubleshooting.
Once again, thank you for your help and good tips.
ocumo
commented
4 years ago A quick look at the dev tools for the example iframe shows me this: The iframe's document <head> node tries to source this css file:
<link href="/static/build/styles/samples.37902ba3b7fe.css" rel="stylesheet" type="text/css">
However, the console logs the following error, twice:
The resource from “https://mdn.mozillademos.org/static/build/styles/samples.37902ba3b7fe.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
and also on the top of the dev tools pane this is also displayed: "Stylesheet could not be loaded:"
Interestingly, in Chromium dev tools I see the same error also logged twice and yet the a:visited rule does work.
However, here is the thing:
Chromium dev tools do show the a:visited rule when we inspect any of the example links:
...which is shown as coming from the source of the very iframe of the example, i.e.,
<iframe class="live-sample-frame sample-code-frame" id="frame_Example" src="https://mdn.mozillademos.org/en-US/docs/Web/CSS/:visited$samples/Example?revision=1527075" frameborder="0"></iframe>
... which is obvious, since the css rule is in the <head> node of it, so, all normal,...
...whereas Firefox dev tools, when inspecting the same example link, does not show any a:visited rule whatsoever, not even as inherited or in the pseudo-elements group:
Now, all these do confuse me: if --aparently-- no css rules apply to a:visited in Firefox (though present in a <style> block in the <head>), then when I click a link, of course it won't change its appearance. But except for the above mentioned error, there are no other error messages or warning or info in the console (all messages allowed) that seem related in any way to this. Furthermore, the same error is shown in Chromium and it doesn't seem to affect this.
Could this somehow be related to any other thing than some bad CSS configuration that I might have introduced somewhere else? I don't know... perhaps something that mess the click event or an event handler? But... how it could "neutralize" a css rule from a <style> element in the <head> node? Of course I am aware that there are many variables to eliminate, such as installed extensions, which I will have to eliminate... I do have the usual uBlock Origin, Ghostery, TreeStyle Tabs, TamperMonkey and Stylus, plus a few others. I have disabled e.g. TamperMonkey to no avail (and I have no userscripts that apply to MDN, plus I only have userscripts written by me; nobody else to blame here). Work in progress.
Any tips are always welcome, although this is not an urgent case, it may affect others. For me, it means that for some software that I am developing to use in Firefox I have to circunvent the a:visited issue by using some extra javascript, which looks a bit stupid, but at least I can move on.
I will keep investigating, though I am not sure if I can spend much time on it today. It does look very interesting (and puzzling) to me.
Request type
Details
The code in the Example section, as shown in the Result (https://developer.mozilla.org/en-US/docs/Web/CSS/:visited#Result) box, doesn't demonstrate what the text is explaining it should do. I should see some yellow background and orangy text after "visiting" those links, but that is not the case.
When I click on any of the two example links, two of the three visited: rules ("color: hotpink" and "border-color: hotpink") apply only while the left button of the mouse is down. On release, the links come back to their original blue on white colors. The "background: yellow" never happens during or after the click. I have tried the same code in both the "Open in JSFiddle" and "Open in CodePen", and the behavior is exactly the same: it does not behave as described in the text.
Note that I have Firefox Quantum 69.0.1 (64-bit).
Please forgive my lack of experience on CSS. But while I realize that this might be a very silly and embarrasing misunderstanding on my side because I am precisely trying to understand how this CSS rule work, I would still complain that it doesn't seem appropriate to put an example that doesn't work out of the box and without any obvious reasons.
If the example requires some prerequisite configurations, or deeper knowledge that is not mentioned, or even yet some imagination to figure out how it works, then I would humbly consider frustrating and useless.
Could you please shed some light on what I am doing (or reading) wrong?
Thanks a lot in advance!