Changes to :visited in Firefox/Gecko

Might be of an interest:

Interesting but as they mention it won’t affect the CSS much at all. Most of the cases they gave are quite…rare and won’t happen much at all.

Most :visited styles you apply are just those listed that they are supporting anyway.

Useful article though :). Thanks for the information.

I do know a share of sites that do use backgrounds and padding on visited links, so it does happen in the real world.

I posted it because it’s one of those small things that you need to keep in mind, not because it’s likely to immediately affect most people. Who knows, maybe someone might want to add a background to a visited link someday. Better to know it’s not possible rather than try and get thoroughly confused.

Huh? I think you misunderstood (or me?) You CAN set backgrounds. So no…this doesn’t affect us so far (via your argument)

We’re limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or transparent on them

According to the article you’ll only be able to set background colours, not, e.g., background images. That could be a major drawback for some sites.

I first thought this was a bad April’s Fools joke, but it appears it isn’t. I do think it’s the wrong way to go about things. Paranoid people who are concerned about leaving traces on the 'Net could use a user style sheet with !important declarations to prevent tracking via the :visited pseudo-class. Imposing this sort of disadvantages on everyone seems far too drastic to me.

I agree with Tommy, but I like their concern about privacy also for unaware visitors.

I don’t fully understand the background transparent color-value omission as it is the default. (Hopefully it can be worked around by the shorthand.)

Mozilla has slowly been chipping away at whatever was “good” about their browser. I’m doing everything in my power to prevent getting an upgrade to 3.6.

They removed “properties” from the right-click context menu. Uh, hello? Yes, let’s break with every other browser in the universe and force people to download a plugin that doesn’t work quite the same way.

Their “png colour fix” that destroyed my personal web site (by making a “colour correction” on by default) is the top of retardation. Shame on them! Photographers who want colour correction on Flickr will do it themselves, that’s why they bought fancy cameras and editing software in the first place. Don’t ruin it for the rest of us.

Their interesting “fix” for the focus caret bug (a decade-old mozilla bug) basically broke the orca screen reader, preventing people from being able to move their focus to new pages. The solution? downgrade to 3.5 or turn off the built-in correction-for-firefox-caret-bug. Great.

The so-called “awesome bar” had quite a large amount of discussion regarding privacy in history. Everyone seemed pretty pissed that the pr0n they sought couldn’t be hidden when they were using their computers for things like presentations. I don’t know the details of that, but I do know that the auto-completion/suggestion in the address bar was so retarded (going by site name rather than url like it should) that I turned it off completely somehow (I forget).

Now they continue with “protecting people from themselves”. As Tommy said, people who actually give a rats’ about :visited link privacy are willing to make their own stylesheet overriding this stuff anyway. Just like those of us who hate retarded Javascript for singing and dancing fading and bzing-bling-bling dropdown menus turn it off.

What’s scary to me is that all these things Mozilla does, webkit seems to follow. Arg.

ARG!

AAAAAARG!

</rant>

The first thing I did was check the date :slight_smile: Then I waited for someone else to reply just in case :wink:

Setting !important declarations will break the utility of visited links. Their solution maintains the usability of visited link designations, but fixes the problem. I wasn’t really happy either, but their solution is the only practical solution. They presumably blocked other properties like padding because those can be used to detect a user’s history by analyzing how the rest of the page reflows (or you can just consider the size of the element itself). For background images, you can detect server-side if the image was loaded and who loaded the image.

Color correction is part of PNG. It is reasonable for them to support it. If you don’t want color correction, then you shouldn’t put that information in your images. Image formats support color correction because monitors differ. It is not possible to somehow apply color correction on your own as you had suggested, because it will not self correct on different environments.

On the awesomebar, I have to admit that I vehemently abhorred it at first, but it grew on me. The problem with the old address bar is that it only matched the beginning of URLs, so while it worked in many cases, if your history contained many URLs that started in a similar fashion, then the address bar was useless. With the awesomebar, you can match other portions of the URL, so you get the best of both worlds.

Color correction is part of PNG. It is reasonable for them to support it. If you don’t want color correction, then you shouldn’t put that information in your images. Image formats support color correction because monitors differ. It is not possible to somehow apply color correction on your own as you had suggested, because it will not self correct on different environments.

I don’t screw with my images. I simply change the filetype from whatever it was to png and WOW! Suddenly everything looks like complete garbage in one browser only: guess which one. They’re just gradients and even solid colours for Pete’s sake! They no longer match the CSS’d backgrounds! It’s a whole new, invented colour! I should take screenshots, you’d barf if you saw my pages like this (dark red turned into an interesting shade of vomit brown). I don’t dick with colour correction because I put in the hex number and expect to see that exact same colour on the web page. A reasonable request, I’d say.

http://hacks.mozilla.org/2009/06/color-correction/ my complaint is in there too, not that it matters for anything other than letting off steam and begging Mozilla to tell our clients why their carefully designed sites suddenly look like a toddler got ahold of the code.
*edit my comment seems to have vanished. It must not have been worthy.

So, should I change all my pngs to work in Firefox on Macs/Linux and make all other OSes and browsers look like crap, or should I do it the other way around?? Sure, I can turn it off in my browser, but since I can’t expect other people to do that, I leave it on to remind myself of how absolutely terrible everything looks to certain casual visitors. And my clients’ pages too. And my boss’ pages. IE, I’m used to it being silly. I expect it, but more importantly, I have easy hacks for it.

All I want is a * html #element {styles for firefox;}

and parent selecors

and a p0ny.

You’re not getting the point. Without color profile support, it is impossible to correctly reproduce colors in a picture across different environments. Any decent graphics editor and photo viewer understands color profiles, so it is reasonable that browsers should as well. Mozilla is not at fault. Rather, whatever program you are using is at fault, for not making it obvious enough that you are saving a PNG image with a color profile. You were never supposed to save images with a color profile (other than sRGB) if you are trying to seamlessly integrate it with CSS, which does not yet have support for color profiles.

Safari has support for ICC profiles as well.

If you want your images to look the same across the board, then remove the bogus data that you have in your images.

I don’t see how. Please elucidate. What’s the difference between my setting a specific background/foreground colour combination in a user style sheet and Gecko forcing the author to do it?

I don’t call severe violations of the CSS specification a ‘practical solution’. I call it a panic reaction. I call it cutting off your nose to spite your face.

The author can still detect a difference in style between visited and unvisited links. You would have to make both visited and unvisited links have the exact same style in your own user style sheet, which would break the visited link functionality.

I wouldn’t call it a panic reaction. The fact that they considered reflow and background images indicates that they put some real thought into this. This is unfortunately their only solution if they want to solve the problem. For example, there is nothing about margin and padding that you can do to allow their usage without still leaving holes. Even if they made getComputedStyle() outright lie, it is still possible to look at how the rest of page reflows.

It’s not a question of whether they considered the best solution or not. It’s a question of whether you saw it as a problem or not. Personally, I don’t find the disadvantages over-weighing the advantages, because the need for styling :visited links in a radical manner doesn’t come up often.

[QUOTE=sk89q;]It’s not a question of whether they considered the best solution or not. It’s a question of whether you saw it as a problem or not. Personally, I don’t find the disadvantages over-weighing the advantages, because the need for styling :visited links in a radical manner doesn’t come up often.[/QUOTE]I see the problem, but…

…I still don’t see why transparency can’t be allowed on visited links. (I suspect the “won’t” could be a typo in the linked article.)

Some info I found speaks about transparency…
Like here: W3.org: SVG Content Interactivity

For raster images, hit detection is either performed on a whole-image basis (i.e., the rectangular area for the image is one of the determinants for whether the image receives the event) or on a per-pixel basic (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event):

…and how it can be used: Mozilla Developer Center/CSS/pointer-events

The CSS property pointer-events allows authors to control whether or when an element may be the target of a mouse event. This property is used to specify under which circumstance (if any) a mouse event should go “through” an element and target whatever is “underneath” that element instead.

From David Baron’s Proposed Solution:


… If the relevant link is not visited, this function returns the color from the first (normal) style context. If the relevant link is visited, it returns a color whose R (red), G (green), and B (blue) components come from the second style context (the style-if-visited) but whose A (alpha) component comes from the first.

Also note what he suggests about mouse events:

If, in the future, we add (highly requested) values to this property that allow mouse events to reach elements depending on whether or not parts of an image or parts of the element are transparent, we need to be careful in two cases. First, SVG filters allow swapping of alpha and color components. Second, if we allow background images (above), those images might have transparency in different places.

These problems could be avoided in one of two ways. We could ensure that pointer-events always looks at transparency based on unvisited styles. Or, alternatively, if we don’t allow background images, we could ensure that pointer-events looks at transparency prior to processing of SVG filters (which might be easier anyway).
Conclusion: For accessibility I still think also the transparency could be allowed on :visited for the visual appearance of an already loaded background to show (could also be allowed to change position).

That is no different from limiting the properties that apply to :visited links. And if they make getComputedStyle() lie, then it doesn’t matter either.

If they see this as a real problem (I don’t, and it can be solved already for those who do) they should convey it to W3C and have the CSS specification changed. Not singlehandedly decide to violate the spec.

They removed “properties” from the right-click context menu.
Glad you mentioned it… thought I had a problem with my machine. Very frustrating I use this feature often to recap on image dimensions for CSS editing, I now need an extra couple of clicks :nono:

Here you go, Barry. It’s not 100% the same, but if I accidently find myself unable to prevent an upgrade to 3.6, this is one of the first plugins I’ll download… if I’m still using FF as my main dev browser by then.

Cheers Stomme poes just what I’m after :slight_smile:

Uh, hello? Yes, let’s break with every other browser in the universe and force people to download a plugin that doesn’t work quite the same way
I second that :smiley:

No, it’s not the same. Say you only have access to two properties: color and padding.

For your scheme to work, only this will work:
[highlight=‘css’]a:link {
color: blue !important;
padding: 0 !important;
}
a:visited {
color: blue !important;
padding: 0 !important;
}


Besides breaking visited links, that has a high potential to [i]really[/i] break many pages.

None of these combinations can work:
[highlight='css']a:link {
    color: blue !important;
    padding: 0 !important;
}
a:visited {
    color: red !important;
    padding: 0 !important;
}

[highlight=‘css’]a:link {
}
a:visited {
color: red !important;
padding: 0 !important;
}


They all reveal holes.

You cannot just change getComputedStyle() to lie either. That still leaves holes.

This really is the [b]only[/b] solution.


[quote="AutisticCuckoo,post:15,topic:54070"]
If they see this as a real problem (I don't, and it can be solved already for those who do) they should convey it to W3C and have the CSS specification changed. Not singlehandedly decide to violate the spec.
[/quote]


Perhaps if that was a quick process. I see no problem with violating the spec if there is a major problem with the spec. Also, besides the fact that no fix exists that doesn't severely degrade your experience (JavaScript has to be disabled and you have to override some CSS), it is not practical to expect most people to be aware of the problem or know how to fix it. If we applied that mentality in a broader scale, botnets, spammers, and DDoS attacks would be far more prevalent.

That’s where you and I are on opposite sides of a very large field, so let’s just agree to disagree, eh? :slight_smile: