I am writing some CSS that should create some generated content.
.foo:visited::after {
display: inline;
content: " visited";
}
However, it has no effect.
If I change the selector to just .foo::after, it works.
Similarly, my styles for .foo:visited take effect.
The Safari web inspector is even showing my styles for :visited::after as if they are in effect!
Why can’t I see my generated content?
Browsers limit the styles you are allowed to modify on a visited link, and even lie to you if you query for the current color of the link with JavaScript.
Why?
Because otherwise, you, at scumbag-advertising.example.com, can run a bunch of JavaScript to see what websites (or at least URLs) are in the browser’s history!
For more, see :visited on MDN and this longer explanation of how this privacy hole was closed:
Historically, the CSS :visited selector has been a way for sites to query the user's history, by using getComputedStyle() or other techniques to walk through the user's history to figure out what sites the user has visited. This can be done quickly, and makes it possible not only to determine where the user has been on the web, but can also be used to guess a lot of information about a user's identity.
A number of years ago, browsers patched up this hole by limiting changes and lying about color.
Related
I'm building a front-end widget which can be embedded on any web page.
I don't want the host page's styles to affect the widget. So, I'd like to reset all styles for #widget, and its descendants, to the browser defaults.
This is what all: revert does – but it doesn't have widespread browser support yet. I'm essentially looking for a polyfill for all: revert.
(The phrase "to their browser defaults" is important. I know that I can use all: initial to reset styles to their initial value. But the initial value is not the same thing as the browser's default value.)
I'm familiar with Eric Meyer's CSS reset and similar resets/boilerplates. Those aren't what I'm looking for. They don't reset all styles – only those which are inconsistent between the major browsers' default stylesheets.
For example, say that the host page contains the style body { font-style: italic } (unlikely, but possible). Boilerplate-type CSS resets would not correct this: the text in my widget would also be italic.
(Please think carefully before marking this question as a duplicate. There are similar questions on Stack Overflow – but many of them were posted many years ago, when the situation was quite different, or they're asking subtly different questions.)
Thanks!
Since both of the following have the same effect:
.class {
cursor:pointer;
}
.class:hover {
cursor:pointer;
}
Regarding best practices, which one should you use and why?
The two selectors are for distinctly separate purposes, despite the fact that- at least in practice they appear to accomplish the same thing.
I would tend to say it would be best practice to define the hover state using :hover (at least on non-touchscreen devices, see below), because:
It makes finding and understanding your styling more apparent in larger blocks of CSS
It utilizes a specifically designated selector (which may be extended in the spec at a later date, what would then happen to your functionality?)
If you later add to the default styling for .class your states are clearly separated appropriately
What happens if you hand over responsibility of your CSS to another individual? Having :hover specific functionality defined under the correct selector makes understanding code a heck of a lot easier.
If you have more complex CSS its likely you'll be using :hover elsewhere, so should use it for the purposes of consistency
The two selectors represent the same element but in different states, semantically you should use :hover
But hang on a minute.. you may notice that if you set the cursor style for an a element to default then the usual hand icon wont appear on hover...this indicates that there is baked-in prior evidence for not specifically styling :hover states (see this in action here)
In summary, there is no game breaking reason not to use simply .class in some circumstances- it certainly uses less bytes and if you have a fairly simple setup then only under development by you...then why not, but be wary it is probably best avoided if you want to adhere to the strict rules and better support ongoing development.
In addition..lets not forget touchscreen devices MDN makes an important point here
on touch screens :hover is problematic or impossible. The :hover
pseudo-class never matches, or matches for a short moment after
touching an element. As touchscreen devices are very common, it is
important for web developer not to have content accessible only when
hovering over it, as this content would be hidden for users of such
devices.
As such depending on your requirement, it may not be best to use :hover as if you have it in your CSS for a touch screen device it may bake in reliance on unsupported or flakey functionality.
IE6 and lower only recognises the :hover pseudo class on a tags. :hover on a div or other tag will not be interpreted by those browsers.
If compatibility is a consideration, use the :hover else I believe there is no difference.
First, for your "same effect", it depends on what do you apply to.
Because some elements by default have "cursor: pointer" property such as
anchor tag
While the following elements by default have "cursor: default"(no pointer)
input type: submit
Take stackoverflow.com "Post your answer" as an example, it is a submit button with "cursor:default" by default, user's perception might think a clickable object is displaying "pointer", so it is styled with "cursor:pointer"
As a quick conclusion with my experience, there is no best practice, but rather, depends on the purpose. For clickable object but it is not display as "pointer" by default, you may style them with "pointer".
When you disabled something, eg when you activate something then enable an anchor link, you may use something like
/* the a is only for illustrative purpose */
a.disabled{
cursor: default;
}
a.enabled{
cursor: pointer;
}
Because cursor is a matter of visual presentation, related to user experience design(UX).
How can I style a anchor tag so that once the link is visited it will change to Red and append [Old] to the end of the link.
So how do I combine these two:
a:visited{
color:Red
}
a:after{
content:[Old]
}
This is a privacy issue. As browser can detect element styles, it can therefore know what sites did you visit. An right now JS can detect it for a very large number of links in very short time. So for security reasons modern browser's ability to detect :visited class is severely cutted down.
Read more about it on mozilla's blog: http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
Citation from Webkit changelog:
http://support.apple.com/kb/HT4196
Impact: A maliciously crafted website may be able to determine which
sites a user has visited
Description: A design issue exists in WebKit's handling of the CSS
:visited pseudo-class. A maliciously crafted website may be able to
determine which sites a user has visited. This update limits the
ability of web pages to style pages based on whether links are
visited.
Similiar questions (have more links):
Google chrome a:visited background image not working
How can I remove the underline of a link in chrome using CSS?
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Cross Site Scripting in CSS Stylesheets
I'm considering allowing users to create their own CSS through linked stylesheets (NOT embedded style tags). Can an XSS attack be performed from a stylesheet?
Thanks
In Internet Explorer, Firefox and other browsers you can embed JavaScript in CSS by specifying a javascript: URL in a url() CSS statement.
Even if you manage to filter these out, an attacker can still completely redesign the page (including all of its textual content) with advanced CSS. Therefore, it becomes extremely easy to trick users to execute stupid actions, which is what XSS is about. For example, you could make the Delete Account button fill the entire window and change its text to "Click here to win 1000$".
You can white-list a select few properties (text-*, font-*, color, background (only colors and gradients, no URLs or other fancy stuff)), but you'll have to reject anything that does not match these restrictions.
Interesting question. I can imagine the style sheet having the ability to remove or hide elements which can be a security problem. You can also insert text after a certain element using :after and :before so you might want to be careful about that.
Alternately I think you should include their style sheet first so that they don't suddenly change all your fonts or something global.
those are old hacks but might still work in older browser, for example you can put javascript protocol in href attr.
http://ha.ckers.org/xss.html
(search for style)
I am curious about the efficiency of this example piece of CSS:
ul, a, span, p, li { *zoom:1; }
Please keep in mind that this is purely theoretical so the merits or pitfalls of CSS hacks are not so much of interest.
My question is — What do browsers other than IE6&7 do:
look to match all the selectors in the page and then realise that it is empty and not act upon it? (horribly inefficient)
Realise it is empty and not act upon the selectors (fairly efficient)
No of the above.
Any ideas would be greatly received.
Cheers,
Ad.
I don't know. :) It might depend on the browser, although all of them are in a race to optimize for speed as much as possible. I'd assume they would have thought about this.
But since you can never be sure, I would recommend to put IE hacks inside a separate css file and use conditional comments in HTML to include these css files conditionally.
But when doing that, I think you should also provide these files with an 'Expires' header that allows them to be cached for a longer period of time (like a day?). When you don't provide these headers, IE will invalidate the cached file much sooner than most other browsers, which might cause more requests (for these separate css files) to your server when a visitor is browser multiple pages of your site.
Usually this will not be a big problem, but if you're talking optimization like this, it might be an issue.
Assuming a browser obeys the specification, it will simply ignore the *zoom property:
User agents must ignore a declaration
with an unknown property. For example,
if the style sheet is:
h1 { color: red; rotation: 70minutes }
the user agent will treat this as if
the style sheet had been
h1 { color: red }
As for what happens if such a browser finds an empty declaration block, I don't know. I haven't seen the scenario mentioned in the spec, so I would guess it's an implementation detail and it'd differ browser by browser.