I am working with an ASPX page using CSS to locate DIV properties, these DIV properties can be changed on the page but when I go to print the properties, they are not pushed to the printer. Is there a way to locally change CSS properties, save them and push them to a server-side ASP page?
I know I could use a DB solution, but that is really not feasible. Is it possible to save the CSS properties to a local cookie, and reload the page with the cookie properties? I seem to remember that we use to be able to load variables from cookies directly into a page, but it's been a while...
document.cookie = "myCustomCss=blah";
and for reading
var x = document.cookie;
a good explanation is available on w3schools
be careful using cookies for a lot of data or sensitive data, for that you'd probably want to move to using a database.
Presently I am using a pop-up window to edit the CSS properties like this;
<div id="adjDate">
H
<br />
V
</div>
The CSS is like this;
div#adjDate {
left: 110px;
top: 1px;
color: red;
}
I am thinking using CSS variables might be a viable solution, but the JS might be something worth looking into.
Related
i have an webapp and i need to onclick change css style, but i need to save this change in the webapp instaled into the phone of my user, and only in his phone. The javascript for onclick change css style it's working but i don't have no idea to how to save this css changes.
Can somebody help me with this?
Since now thanks
In general CSS styles can't be directly saved on an HTML client.
What you can do is make an Ajax call back to your server and save the information there. The next time the user asks for the page send HTML with the appropriate style class already on the element you wish to style based on the saved information.
There are several hackish client side possibilities involving JavaScript & cookies or local storage but I would avoid that sort of solution if at all possible since it's very likely to lead to an annoying flicker as the page loads and renders styled one way and then the JavaScript finally runs and corrects the style.
To elaborate on my comment:
el1.addEventListener('click', function() {
el2.style.color = 'red';
localStorage['color'] = el2.style.color;
})
And then on startup:
window.addEventListener('load', function() {
if (localStorage['color']) {
el2.style.color = localStorage['color'];
}
}
Of course, you may want to add error checking and fallbacks as appropriate.
I have a reference site for a series of books, and I'd like to make it so that readers can avoid spoilers. The idea I had was to make a setup webpage where they click on a checkbox for each book from which they want to see info. I could then store that (somehow) as a cookie for each time that they visit the site, plus have it work for each page in the site. So, one page might have this:
<li class="teotw">Rand killed a Trolloc</li>
and another page might have
<li class="teotw">Nynaeve tugged her braid</li>
and that information would not show up on the page unless they had checked the box for the "teotw" book. My initial thoughts are to do something like toggling the CSS class value like this:
document.styleSheets[0]['cssRules'][0].class['teotw'] = 'display:none';
document.styleSheets[0]['cssRules'][0].class['teotw'] = 'display:inherit';
but I'm not sure if this is the best method. Firstly, it would only apply to the current document only so I'd need a way to re-apply it to each page they visit. I'm using YUI as well, if it matters.
Any ideas on the best way of doing this?
There are many ways to implement it. You can use the YUI Stylesheet module (read its User Guide for how to use it) which will do what you're considering with cross-browser support and it's much easier to use than using the DOM directly.
Another way would be to add classes to the body of the page. You can define styles like this:
.teotw {
display: none;
}
.teotw-visible .teotw {
display: block;
}
With the following JS code:
if (someCondition) {
// show the hidden content
Y.one('body').addClass('teotw-visible');
}
For the persistance of the visible state you can use cookies with the YUI Cookie utilty or local storage with CacheOffline. Code using cookies would look something like this:
var body = Y.one('body');
if (Y.Cookie.get('teotwVisible')) {
body.addClass('teotw-visible');
}
// change the cookie
Y.one('#teotw-toggle').on('click', function (e) {
var checked = this.get('checked');
Y.Cookie.set('teotwVisible', checked);
body.toggleClass('teotw-visible', checked);
});
You should probably store the different sections in a JS object and avoid hard-coding class names in every JS line. Or maybe use a convention between checkboxes IDs and section class names.
I am refactoring some CSS on a website. I have been working on, and noticed the absence of traditional HTML IDs in the code.
There is heavy use of CssClass='…', or sometimes just class='…', but I can't seem to find a way to say id='…' and not have it swapped out by the server.
Here is an example:
<span id='position_title' runat='server'>Manager</span>
When the response comes back from the server, I get:
<span id='$aspnet$crap$here$position_title'>Manager</span>
Any help here?
Use jQuery to select the element:
$("span[id$='position_title']")....
jQuery's flexible selectors, especially its 'begins with'/'ends with selectors' (the 'end with' selector is shown above, provide a great way around ASP.NET's dom id munge.
rp
The 'crap' placed in front of the id is related to the container(s) of the control and there is no way (as far as I know) to prevent this behavior, other than not putting it in any container.
If you need to refer to the id in script, you can use the ClientID of the control, like so:
<script type="text/javascript">
var theSpan = document.getElementById('<%= position_title.ClientID %>');
</script>
Most of the fixes suggested her are overkill for a very simple problem. Just have separate divs and spans that you target with CSS. Don't target the ASP.NET controls directly if you want to use IDs.
<span id="FooContainer">
<span runat="server" id="Foo" >
......
<span>
</span>
You can embed your CSS within the page, sprinkled with some server tags to overcome the problem. At runtime the code blocks will be replaced with the ASP.NET generated IDs.
For example:
[style type="text/css"]
#<%= AspNetId.ClientID %> {
... styles go here...
}
[/style]
[script type="text/javascript"]
document.getElementById("<%= AspNetId.ClientID %>");
[/script]
You could go a bit further and have some code files that generate CSS too, if you wanted to have your CSS contained within a separate file.
Also, I may be jumping the gun a bit here, but you could use the ASP.NET MVC stuff (not yet officially released as of this writing) which gets away from the Web Forms and gives you total control over the markup generated.
Ok, I guess the jury is out on this one.
#leddt, I already knew that the 'crap' was the containers surrounding it, but I thought maybe Microsoft would have left a backdoor to leave the ID alone. Regenerating CSS files on every use by including ClientIDs would be a horrible idea.
I'm either left with using classes everywhere, or some garbled looking IDs hardcoded in the css.
#Matt Dawdy: There are some great uses for IDs in CSS, primarily when you want to style an element that you know only appears once in either the website or a page, such as a logout button or masthead.
The best thing to do here is give it a unique class name.
You're likely going to have to remove the runat="server" from the span and then place a within the span so you can stylize the span and still have the dynamic internal content.
Not an elegant or easy solution (and it requires a recompile), but it works.
.Net will always replace your id values with some mangled (every so slightly predictable, but still don't count on it) value. Do you really NEED to have that id runat=server? If you don't put in runat=server, then it won't mangle it...
ADDED:
Like leddt said, you can reference the span (or any runat=server with an id) by using ClientID, but I don't think that works in CSS.
But I think that you have a larger problem if your CSS is using ID based selectors. You can't re-use an ID. You can't have multiple items on the same page with the same ID. .Net will complain about that.
So, with that in mind, is your job of refactoring the CSS getting to be a bit larger in scope?
I don't know of a way to stop .NET from mangling the ID, but I can think of a couple ways to work around it:
1 - Nest spans, one with runat="server", one without:
<style type="text/css">
#position_title { // Whatever
}
<span id="position_titleserver" runat="server"><span id="position_title">Manager</span></span>
2 - As Joel Coehoorn suggested, use a unique class name instead. Already using the class for something? Doesn't matter, you can use more than 1! This...
<style type="text/css">
.position_title { font-weight: bold; }
.foo { color: red; }
.bar { font-style: italic; }
</style>
<span id="thiswillbemangled" class="foo bar position_title" runat="server">Manager</span>
...will display this:
Manager
3 - Write a Javascript function to fix the IDs after the page loads
function fixIds()
{
var tagList = document.getElementsByTagName("*");
for(var i=0;i<tagList.length;i++)
{
if(tagList[i].id)
{
if(tagList[i].id.indexOf('$') > -1)
{
var tempArray = tagList[i].id.split("$");
tagList[i].id = tempArray[tempArray.length - 1];
}
}
}
}
If you're fearing classitus, try using an id on a parent or child selector that contains the element that you wish to style. This parent element should NOT have the runat server applied. Simply put, it's a good idea to plan your structural containers to not run code behind (ie. no runat), that way you can access major portions of your application/site using non-altered IDs. If it's too late to do so, add a wrapper div/span or use the class solution as mentioned.
Is there a particular reason that you want the controls to be runat="server"?
If so, I second the use of < asp : Literal > . . .
It should do the job for you as you will still be able to edit the data in code behind.
I usually make my own control that extends WebControl or HtmlGenericControl, and I override ClientID - returning the ID property instead of the generated ClientID. This will cause any transformation that .NET does to the ClientID because of naming containers to be reverted back to the original id that you specified in tag markup. This is great if you are using client side libraries like jQuery and need predictable unique ids, but tough if you rely on viewstate for anything server-side.
If you are accessing the span or whatever tag is giving you problems from the C# or VB code behind, then the runat="server" has to remain and you should use instead <span class="some_class" id="someID">. If you are not accessing the tag in the code behind, then remove the runat="server".
I have built a basic data entry application allowing users to browse external content in iframe and enter data quickly from the same page. One of the data variables is the URL.
Ideally I would like to be able to load the iframes current url into a textbox with javascript. I realize now that this is not going to happen due to security issues.
Has anyone done anything on the server side? or know of any .Net browser in browser controls. The ultimate goal is to just give the user an easy method of extracting the url of the page they are viewing in the iframe It doesn't necessarily HAVE to be an iframe, a browser in the browser would be ideal.
Thanks,
Adam
I did some tests in Firefox 3 comparing the value of .src and .documentWindow.location.href in an iframe. (Note: The documentWindow is called contentDocument in Chrome, so instead of .documentWindow.location.href in Chrome it will be .contentDocument.location.href.)
src is always the last URL that was loaded in the iframe without user interaction. I.e., it contains the first value for the URL, or the last value you set up with Javascript from the containing window doing:
document.getElementById("myiframe").src = 'http://www.google.com/';
If the user navigates inside the iframe, you can't anymore access the value of the URL using src. In the previous example, if the user goes away from www.google.com and you do:
alert(document.getElementById("myiframe").src);
You will still get "http://www.google.com".
documentWindow.location.href is only available if the iframe contains a page in the same domain as the containing window, but if it's available it always contains the right value for the URL, even if the user navigates in the iframe.
If you try to access documentWindow.location.href (or anything under documentWindow) and the iframe is in a page that doesn't belong to the domain of the containing window, it will raise an exception:
document.getElementById("myiframe").src = 'http://www.google.com/';
alert(document.getElementById("myiframe").documentWindow.location.href);
Error: Permission denied to get property Location.href
I have not tested any other browser.
Hope it helps!
document.getElementById('iframeID').contentWindow.location.href
You can't access cross-domain iframe location at all.
I use this.
var iframe = parent.document.getElementById("theiframe");
var innerDoc = iframe.contentDocument || iframe.contentWindow.document;
var currentFrame = innerDoc.location.href;
HTA works like a normal windows application.
You write HTML code, and save it as an .hta file.
However, there are, at least, one drawback: The browser can't open an .hta file; it's handled as a normal .exe program. So, if you place a link to an .hta onto your web page, it will open a download dialog, asking of you want to open or save the HTA file. If its not a problem for you, you can click "Open" and it will open a new window (that have no toolbars, so no Back button, neither address bar, neither menubar).
I needed to do something very similar to what you want, but instead of iframes, I used a real frameset.
The main page need to be a .hta file; the other should be a normal .htm page (or .php or whatever).
Here's an example of a HTA page with 2 frames, where the top one have a button and a text field, that contains the second frame URL; the button updates the field:
frameset.hta
<html>
<head>
<title>HTA Example</title>
<HTA:APPLICATION id="frames" border="thin" caption="yes" icon="http://www.google.com/favicon.ico" showintaskbar="yes" singleinstance="no" sysmenu="yes" navigable="yes" contextmenu="no" innerborder="no" scroll="auto" scrollflat="yes" selection="yes" windowstate="normal"></HTA:APPLICATION>
</head>
<frameset rows="60px, *">
<frame src="topo.htm" name="topo" id="topo" application="yes" />
<frame src="http://www.google.com" name="conteudo" id="conteudo" application="yes" />
</frameset>
</html>
There's an HTA:APPLICATION tag that sets some properties to the file; it's good to have, but it isn't a must.
You NEED to place an application="yes" at the frames' tags. It says they belongs to the program too and should have access to all data (if you don't, the frames will still show the error you had before).
topo.htm
<html>
<head>
<title>Topo</title>
<script type="text/javascript">
function copia_url() {
campo.value = parent.conteudo.location;
}
</script>
</head>
<body style="background: lightBlue;" onload="copia_url()">
<input type="button" value="Copiar URL" onclick="copia_url()" />
<input type="text" size="120" id="campo" />
</body>
</html>
You should notice that I didn't used any getElement function to fetch the field; on HTA file, all elements that have an ID becomes instantly an object
I hope this help you, and others that get to this question. It solved my problem, that looks like to be the same as you have.
You can found more information here: http://www.irt.org/articles/js191/index.htm
Enjoy =]
I like your server side idea, even if my proposed implementation of it sounds a little bit ghetto.
You could set the .innerHTML of the iframe to the HTML contents you grab server side. Depending on how you grab this, you will have to pay attention to relative versus absolute paths.
Plus, depending on how the page you are grabbing interacts with other pages, this could totally not work (cookies being set for the page you are grabbing won't work across domains, maybe state is being tracked in Javascript... Lots of reasons this might not work.)
I don't believe that tracking the current state of the page you are trying to mirror is theoretically possible, but I'm not sure. The site could track all sorts of things server side, you won't have access to this state. Imagine the case where on a page load a variable is set to a random value server-side, how would you capture this state?
Do these ideas help with anything?
-Brian J. Stinar-
Does this help?
http://www.quirksmode.org/js/iframe.html
I only tested this in firefox, but if you have something like this:
<iframe name='myframe' id='myframe' src='http://www.google.com'></iframe>
You can get its address by using:
document.getElementById('myframe').src
Not sure if I understood your question correctly but anyways :)
You can use Ra-Ajax and have an iframe wrapped inside e.g. a Window control. Though in general terms I don't encourage people to use iframes (for anything)
Another alternative is to load the HTML on the server and send it directly into the Window as the content of a Label or something. Check out how this Ajax RSS parser is loading the RSS items in the source which can be downloaded here (Open Source - LGPL)
(Disclaimer; I work with Ra-Ajax...)
Ok, so in this application, there is an iframe in which the user is supplied with links or some capacity that allows that iframe to browse to some external site. You are then looking to capture the URL to which the user has browsed.
Something to keep in mind. Since the URL is to an external source, you will be limited in how much you can interact with this iframe via javascript (or an client side access for that matter), this is known as browser cross-domain security, as apparently you have discovered. There are clever work arounds, as presented here Cross-domain, cross-frame Javascript, although I do not think this work around applies in this case.
About all you can access is the location, as you need.
I would suggest making the code presented more resilitant and less error prone. Try browsing the web sometime with IE or FF configured to show javascript errors. You will be surprised just how many javascript errors are thrown, largely because there is a lot of error prone javascript out there, which just continues to proliferate.
This solution assumes that the iframe in question is the same "window" context where you are running the javascript. (Meaning, it is not embedded within another frame or iframe, in which case, the javascript code gets more involved, and you likely need to recursively search through the window hierarchy.)
<iframe name='frmExternal' id='frmExternal' src='http://www.stackoverflow.com'></frame>
<input type='text' id='txtUrl' />
<input type='button' id='btnGetUrl' value='Get URL' onclick='GetIFrameUrl();' />
<script language='javascript' type='text/javascript'>
function GetIFrameUrl()
{
if (!document.getElementById)
{
return;
}
var frm = document.getElementById("frmExternal");
var txt = document.getElementById("txtUrl");
if (frm == null || txt == null)
{
// not great user feedback but slightly better than obnoxious script errors
alert("There was a problem with this page, please refresh.");
return;
}
txt.value = frm.src;
}
</script>
Hope this helps.
You can access the src property of the iframe but that will only give you the initially loaded URL. If the user is navigating around in the iframe via you'll need to use an HTA to solve the security problem.
http://msdn.microsoft.com/en-us/library/ms536474(VS.85).aspx
Check out the link, using an HTA and setting the "application" property of an iframe will allow you to access the document.href property and parse out all of the information you want, including DOM elements and their values if you so choose.
Is it possible to prevent an asp.net Hyperlink control from linking, i.e. so that it appears as a label, without actually having to replace the control with a label? Maybe using CSS or setting an attribute?
I know that marking it as disabled works but then it gets displayed differently (greyed out).
To clarify my point, I have a list of user names at the top of my page which are built dynamically using a user control. Most of the time these names are linkable to an email page. However if the user has been disabled the name is displayed in grey but currently still links to the email page. I want these disabled users to not link.
I know that really I should be replacing them with a label but this does not seem quite as elegant as just removing the linking ability usings CSS say (if thats possible). They are already displayed in a different colour so its obvious that they are disabled users. I just need to switch off the link.
This sounds like a job for JQuery. Just give a specific class name to all of the HyperLink controls that you want the URLs removed and then apply the following JQuery snippet to the bottom of your page:
$(document).ready(function() {
$('a.NoLink').removeAttr('href')
});
All of the HyperLink controls with the class name "NoLink" will automatically have all of their URLs removed and the link will appear to be nothing more than text.
A single line of JQuery can solve your problem.
I'm curious on what it is you which to accomplish with that. Why use a link at all?
Is it just for the formatting? In that case, just use a <span> in HTML and use stylesheets to make the format match the links.
Or you use the link and attach an onClick-Event where you "return false;" which will make the browser not do the navigation - if JS is enabled.
But: Isn't that terribly confusing for your users? Why create something that looks like a link but does nothing?
Can you provide more details? I have this feeling that you are trying to solve a bigger problem which has a way better solution than to cripple a link :-)
A Hyperlink control will render as a "a" "/a" tag no matter what settings you do. You can customize a CSS class to make the link look like a normal label.
Alternatively you can build a custom control that inherits from System.Web.UI.WebControls.HyperLink, and override the Render method
protected override void Render(HtmlTextWriter writer)
{
if (Enabled)
base.Render(writer);
else
{
writer.RenderBeginTag(HtmlTextWriterTag.Span);
writer.Write(Text);
writer.RenderEndTag(HtmlTextWriterTag.Span);
}
}
}
Could be a bit overkill, but it will work for your requirements.
Plus I find is usefull to have a base asp:CustomHyperlink asp:CustomButton classes in my project files. Makes it easier to define custom behaviour throughout the project.
If you merely want to modify the appearance of the link so as not to look like a link, you can set the CSS for your "a" tags to not have underlines:
a: link, visited, hover, active {
text-decoration: none;
}
Though I would advise against including "hover" here because there will be no other way to know that it's a link.
Anyway I agree with #pilif here, this looks like a usability disaster waiting to happen.
If you mean to stop the link from activating, the usual way is to link to "javascript:void(0);", i.e.:
foo
This should work:
onclick="return false;"
if not, you could change href to "#" also. Making it appear as a rest of text is css, e.g. displaying arrow instead of hand is:
a.dummy {
cursor:default;
}
Thanks for all the input, it looks like the short answer is 'No you can't (well not nicely anyway)', so I'll have to do it the hard way and add the conditional code.
If you are using databind in asp.net handle the databinding event and just don't set the NavigateUrl if that users is disabled.
Have you tried just not setting the NavigateUrl property? If this isn't set, it may just render as a span.
.fusion-link-wrapper { pointer-events: none; }
Another solution is apply this class on your hyperlink.
.avoid-clicks {
pointer-events: none;
}
CSS solution to make tags with no href (which is what asp:HyperLink will produce if NavigateURL is bound to null/empty string) visually indistinguishable from the surrounding text:
a:not([href]), a:not([href]):hover, a:not([href]):active, a:not([href]):visited {
text-decoration: inherit !important;
color: inherit !important;
cursor: inherit !important;
}
Unfortunately, this won't tell screen readers not to read it out as a link - though without an href, it's not clickable, so I'm hoping it already won't be identified as such. I haven't had the chance to test it though.
(If you also want to do the same to links with href="", as well as those missing an href, you would need to add pointer-events:none as well, since otherwise an empty href will reload the page. This definitely leaves screen readers still treating it as a link, though.)
In the OP's use case, if you still have the href being populated from the database but have a boolean value that indicates whether the link should be a 'real' link or not, you should use that to disable the link, and add a:disabled to the selector list above. Then disabled links will also look like plain text rather than a greyed-out link. (Disabling the link will also provide that information to screen readers, so that's better than just using pointer-events: none and a class.)
A note of caution - if you add these sorts of rules globally rather than for a specific page, remember to watch out for cases where an tag has no (valid) href, but you are providing a click handler - you still need those to look/act like links.