I have some questions about the :visited pseudo-class:
Based on what do browsers decide when the :visited pseudo-class should be applied to a hyperlink?
Do they take this information from the browser's page history or is it stored per-session or somewhere else?
Is it possible (for the developer of a web page) to control for how long the :visited pseudo-class should be applied to hyperlinks?
(Note: I'm not trying to solve an actual problem, I'm just wondering how it works)
It's applied when a link has been visited based on the browser history. Clearing your history will clear the visited state. There's no "timeout", as far as I know.
It's usually stored in the browser's page history (not per session, except in the case of some sort of privacy mode perhaps).
It simply checks if that link exists in the history, if so it's :visited. As far as I'm aware, you can't control how long it's applied in any way.
You can kind of control it to your advantage by changing the link itself when its target changes. For example, I've seen some message board software that would append the message count to its topic links on the front page, so that the links you have visited would become unvisited when a new message appears in them.
The :visited argument is stored in a users history file, and can only be removed locally.
There is no way to controll that from a server
why do you want to set a timeout for it? maybe there is another way to get what you need.
what you can do is create a random parameter in your link like:
http://www.yourdomain.com/?<random argument>
this way the link always difers, is directed to the same link and then you just throw away the parameter.
#edit yes, it is possible, if you set a cookie and the per user check the last time the cookie was set per link(include the parameter), and if time > the time you want, refresh the parameter
well almost everything has been covered except one thing.
when does it get applied?
when the target page has its onload event. so not immediately.
if you open the link in a new tab in the backgorund you will see some delay before it switches its style. tahts exactly the time the external page takes to load and for the browser to store history/trigger the change.
It only applies to hyperlinks (<a href>), and when an entry is found in the browser history (not session).
Related
There's probably a historical reason for this, but I don't know where to start looking for where this might be documented.
Specifically, instead of the cryptic "anchor tag" with a "hypertext reference" (well, I suppose terminology was different back then):
StackOverflow
why didn't something like this happen?
<link to="https://stackoverflow.com">StackOverflow</link>
What exactly did "anchor" mean anyway?
According to the W3 docs:
A link has two ends -- called anchors -- and a direction. The link starts at the "source" anchor and points to the "destination" anchor, which may be any Web resource (e.g., an image, a video clip, a sound bite, a program, an HTML document, an element within an HTML document, etc.).
I'm not an expert in the field, but I believe that it is merely because of the terminology at the time. Reading that article can provide more details about the definitions, but you may need to message the original authors or historians to provide a creditable answer.
A was short for anchor, which could be a url or a named anchor (created with <a name="myanchor">text</a>). The text in my example would not be visually different, and another A tag could set its href to #myanchor. When clicked, the browser would scroll the named A tag to the top of the page, or at least ensure it was visible.
Link wasn't added until later, and it means something else semantically.
See http://www.w3schools.com/tags/tag_a.asp
As to why, I think only the Html group at the time could answer, but i'd guess that since you could link to another page or within the document, hyper linking wasn't all it could do. Or perhaps since bandwidth was more expensive, brevity had a higher value.
The link tag references a link the current document has with an external source, so it is used to specify a link with associated CSS files. Your thinking is "hyperlink", which is different to the tag's intended usage.
As for your new question about "anchor", I would assume it got its name as an anchor is stuck to its place, and the anchor tag points to a specific location (sometimes on the same page, using #id).
I have used a:visited CSS for my web application, but the browser remember its history for unlimited time.
How can I set this time till the browser is closed?
That is a browser setting, nothing you can influence with CSS.
Alternatives:
Make the links “different” for each browsing session, f.e. by appending a random GET parameter/query string value, or
do not use :visited in the first place, but keep track of clicked links via JavaScript and sessionStorage or a cookie, and then set a class on those elements every time a page is loaded, to achieve the formatting you want for that state.
You can't. How long a browser keeps a URL in its history is entirely up to the browser and there are no APIs that allow a website to influence it.
I want to be certain that the omniture calls for document.write()'s are nullified/cleared from the DOM for each new call.
Criteria:
I want to see what gets written to the DOM with a Adobe Omniture call(s.t() call) for example
I want to make sure that the DOM writes are cleared/nullified out before adding each new call
How to prove the DOM value is nullified/cleared.
I assume you are talking about this part of the on-page code:
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
Adobe Analytics (Omniture) tracking makes its request to the collection server by creating an image object. Modern browsers make the request when you set the imageObject.src attribute with the URL. The reason document.write() is used is to accommodate if the request is not made from simply setting a value to imageObject.src.
Basically, the AA code checks if the imageObject.src successfully loaded the returned image. If so, s.t() returns an empty string. If not, s.t() returns a full img tag, which gets added to DOM from the document.write().
This document.write() fallback is meant to accommodate older browsers. And by "older" I mean IE4 old. If you do not care about tracking browsers that old (hint: nobody does), you can just cut all of the "trigger" code down to the single s.t() call (no need to even assign to s_code).
So to answer your question, nothing is actually document written to the DOM unless you are on an ancient browser. But in the case that you are on an ancient browser.. no, there is no code that removes previous stuff appended. Which brings me to...
..What are you really asking? IOW, why are you trying to find out / make certain that it is removed? I suspect what you may really be asking is something along the lines of wanting to make sure previously set AA variables do not get popped on subsequent requests. Which is a fair thing to ask, but that doesn't really have anything to do with the request itself. But you will need to clarify that point.
My web-app records users via webcam and microphone. I want to use HTML/JS for the controls and content, so I created two separate Flex modules:
* A "Webcam Setup" module that lets you choose your camera and mic input devices
* A "record" module that lets the user record and submit the recording
When I embed either of these on the page, since they access the user's Camera/Mic object, Flash shows the Privacy dialog that says "[mysite] is requesting access to your camera and microphone. If you click Allow, you may be recorded."
The problem is, if I answer Yes in the Setup module, and later add the Record module to the page using Javascript, it again shows the Privacy dialog.
Is there a way to avoid the second privacy popup?
I would think that saying "Yes" for [mysite] would store that permission for at least that session, but apparently not.
What I've tried
I tried combining them into one SWF, adding it to the page once and moving the DOM element with jQuery's append() function when needed. When I move it, however, it reloads and asks me again.
Imagine if [mysite] was, say, blogger.com or livejournal.com (or, if it were still around, geocities.com). Would you want a "yes" response on that site to be good for every page under that domain?
Rememeber, just because you promise (cross your heart & hope to die) not to abuse the security hole you request, doesn't mean they can allow you to have that security hole.
Eventually, I found a usable workaround, similar to what I originally tried (above).
I combined the setup and record modules into one SWF. I first show the setup screen. When the user hits the Continue button on my page, Javascript calls a function in the SWF to swap to the Record screen.
I then move the <div> containing the Flash object to another location on page using absolute positioning, and resize the object.
Previously, I was trying to use jQuery's append() function to move the div within the DOM, and that was causing the SWF to reload. Just changing position and size does actually work.
You could build the "record" component to simply send and receive signals using an API you've created for your "setup" component (which has already been authorized, meaning one auth & two swfs) by using the LocalConnection class:
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
This seems far closer to best practice than the other implementations mentioned, which smell a bit hacky and would probably confuse anyone who may inherit the codebase in the future.
For a specialized purpose with Aweber regarding a newsletter subscription, I have a page loading a nested IFRAME inside, and both reside on the same domain. (Many other stackoverflow posts talk about different domains, but this question deals only with the same domain.) I need a cross-platform way (including browsers as old as the dawn of IE6) for the two to communicate.
For example, someone fills out name and email and clicks a checkbox, and the hidden IFRAME next to the checkbox sits in a setInterval() loop watching for that. When it receives notification, it grabs the name and email and does a form post.
I thought at first that I could just drop a cookie in the parent page, and then the IFRAME child could then sit in an interval watching for that cookie. But my tests show that this won't work. The cookie gets created -- but the IFRAME can't see it. So, I tried the meta-refresh technique in the IFRAME, and again it couldn't see that cookie for some reason.
The only solution I can come up with is that the parent page will take the checkbox click (we use jQuery) and do an AJAX data push to the server into a database. The IFRAME can then check on an interval back to the server via AJAX to see if the database value has changed, and react to it if so. But this seems like an over-engineered solution and I'm looking for an easier alternative that works cross-platform, even in earlier browsers from the timeframe of IE6 and forward.
It's much more simple: In the iframe, you can access the parent variable, which contains the parent window. So you can use parent.document to find the form, read the values, etc.