The following is a very minor problem, I would just like to understand why this happens.
Create a html document that looks like this:
<html>
<head>
<title></title>
<style>
body {font-family: Arial;}
</style>
</head>
<body>
<input type="radio" name="radio" />
</body>
</html>
Now open it in Firefox (I am using build 14.0.1) and right click the radio button to open a context menu. From that menu select "Inspect Element with Firebug...", which will open Firebug with the HTML tab open and the radio button HTML code highlighted.
Now try and select the radio button. It will be selected for a second but then it quickly deselects itself. Why?
I know if I remove that body style definition the above behavior will not happen or if I am in a different tab while Firebug is open (such as the "Console" tab) it won't happen or if Firebug isn't open it won't happen.
I know this is super minor and very situational I just like to at least have some idea of why this is.
I have heard of this before, my onlu suggestion is to report it to FireBug and for now keep trying until you find a work around. Maybe try wrap a form round it or add content round it?
It's a known issue with firebug that is sadly still open
http://code.google.com/p/fbug/issues/detail?id=5744
Annoyingly it creates a heisenbug situation if you don't know about it, where you can't work out why radio buttons won't check for you.
Related
I'm facing a little issue over here.
If I set the rel attribute to noreferrer, my target attribute is not working anymore.
It still opens a new tab if you click on it twice, instead of using the tab created on the first time.
Here some Code:
<p>Click me</p>
jsfiddle not working so look at this one:
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_a_target (change the _blank to what ever name you like)
Note: If you first try it without the rel and didnt close the opened tab , target works well with the rel
I've tried it with Chrome and IE.
Is there any reason why this is not working?
The site I am editing has a search form. For the record, there are several other forms on the site, contact and the like. This is the only one with an issue.
Upon submission of the form, SOME of the styling is lost in IE9 (possibly other versions of IE, haven't tested that yet). Primarily, the margins and colors set in html and body appear to have been lost. Menus, banner, text, etc all appear to retain styles. All styles are on one sheet, that are used here...
Any helpful advice?
Here is the contents of the search page and the php used to check for the form, if that helps, and the css that I think is lost.
EDIT: The page is a search page, with almost nothing on it. A search reloads the same page, while displaying results from the search function. Thus, the same embedded sheets should be embedded, the same html is displayed as far as I can see... if this helps the discussion any. Still sifting to find some type of error. IE dev tools also seem to indicate that this error occurs in previous versions of IE as well, when viewed in IE7-8...
THE HTML:
<div id="search">
<br />
<div style="float:right;font-size:.8em;">
<form name="form_sidesearch" action="search.html" method="post">
<input type="hidden" name="action" value="search" />
<input type="text" name="search_value" value="<?php echo $systems_primary->search_value ?>" />
<input type="submit" name="submit_search" value="Search Website" />
</form> <br />
</div>
</div>
<?php echo stripslashes($search_results);
THE PHP:
<?php
// -- Begin Search --------------------------------------------------------------------------------------
if($_REQUEST["action"] === "search")
{
if(strlen($_REQUEST["pg"]) <= 0)
{
$_REQUEST["pg"] = 1;
}
$search_results = $systems_primary->search_website("index",urldecode($_REQUEST["search_value"]),"<div class=\"listing ui-corner-all\">{ENTRY_TITLE}{ENTRY_CONTENT} ...read more</div><br /><br />",345,"all",10,$_REQUEST["pg"]);
}
// -- End Search ----------------------------------------------------------------------------------------
?>
THE LOST CSS (could be more):
html {
background-color:#F6E6C8;
font-size:16px;
font-family:Helvetica;
}
body {
width:1027px;
margin:0 auto;
background-color:#ffffff;
font-family: arial, 'times new roman', sans-serif;
}
Elaboration: The actual thing that happens is that the page content as a whole is shifted left and remains left aligned instead of using the auto margins to stay centered. Additionally, the html background color is lost. The styles for the search fields are also lost or ignored. Not sure what else might be altered.
Typically when styling is lost after submitting a form, especially when it's an Ajax operation and not a full page reload, it's because there was some styling applied using JavaScript or jQuery that did not get reapplied when the updated portion of the page was reloaded. This could involve additional elements being created, or it could involve CSS classes being added to 1 or more elements.
This is especially likely to happen with the styling of HTML form elements, because in some cases heavy styling of certain form elements can only be done with the help of JavaScript or jQuery.
In such cases, identify the JavaScript or jQuery that styled the relevant content when the page first loaded, and then reapply it after the page has been updated (after an Ajax call has completed successfully, or after the browser has reloaded the page or loaded a new page).
Failing that, compare the HTML for the page before and after and see what changed. There may be a CSS class on the body tag or a container class that's not getting consistently set. If a new page is loaded, a different set of CSS files may be getting downloaded, or there may be an embedded style sheet that one page has but another does not.
Failing that, verify that the HTML and CSS are valid. Some browsers are more forgiving than others when rendering invalid code. What may seem like a browser bug could be caused by bad code.
If all of that turns up nothing and it seems increasingly likely that the problem is caused by an obscure browser bug, then reduce the code to the simplest possible state in which the problem can be consistently reproduced, and try to identify more clearly exactly what the nature of the bug is. This will make it easier to search for possible fixes and to ask for help. And in the course of reducing the code, if the problem suddenly disappears, the last code removed may turn out to be at least partly responsible for the problem.
Conversely, when it seems like there's no rhyme or reason to a problem, it's sometimes helpful to reimplement the code from scratch, to see if the problem still occurs. If the problem starts to occur at some point while writing the code, then likewise the last code that was added may be at least partly responsible for the problem.
You can do something like this...
$('#yourForm").on('submit',function(e){
$(this).css({
// reasign all the atributes you lost
});
e.preventDefault();
});
I'd like to create a link that when it is clicked it will open up a some sort of dialog with some text a user can copy.
I was going to use jquery ui dialog for this but I'm wondering if there is something else I should consider?
Ideally I'd like to have that text highlighted so it is ready to copy. Don't think I can do this with jquery dialog?
Any guidance would be appreciated.
Try this :
HTML :
<div id="dialog">
<textarea id="textbox">some text to copy and paste</textarea>
</div>
JavaScript:
$('#dialog').dialog();
$('#textbox').focus().select();
This opens a dialog and then selects all of the text within the textarea. Because the focus function is used you can Ctrl+C straight off as the text is already in focus and selected.
Working demo : http://jsfiddle.net/eZbXD/
Instead of opening a dialog, you can show a textbox in which the link is selected and ready to copy. I have done something like that before. Look at this fiddle. You can remove unnecessary codes and give some style according to your need.
I've found what I believe to be a bug with Firefox and I'm wondering if this actually is a bug, as well as any workarounds for this.
If you create a basic webpage with the following source:
<html>
<head>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
</head>
<body>
<div>
<input id="txtTest" type="text" />
<input type="button" onclick="$('#txtTest').attr('disabled','disabled');" value="Set Disabled (jQuery)" />
<input type="button" onclick="document.getElementById('txtTest').disabled = true;" value="Set Disabled (js)" />
<input type="button" onclick="$('#txtTest').removeAttr('disabled');" value="Remove Disabled" />
</div>
</body>
</html>
If you disable the textbox dynamically and then refresh the page, the textbox will remain disabled instead of resetting back to its original state of not disabled. I've tried this in IE8 and Chrome and those behave as I would expect, resetting the textbox back to not disabled when I refresh.
Another interesting bit of information is that it still does the same thing if the input is a checkbox instead of a textbox.
This is a "feature" of Firefox which remembers form input values across page refreshes. To fix this behavior, you simply set autocomplete="off" on the form containing the inputs, or just directly to the input.
This stops autocomplete from working and prevents the browser from remembering the state of input fields.
Alternatively, you can just "hard-refresh" by clicking CTRL+F5. This will completely reset the current page.
To deal with the back button, do this (from here)
window.addEventListener('pageshow', PageShowHandler, false);
window.addEventListener('unload', UnloadHandler, false);
function PageShowHandler() {
window.addEventListener('unload', UnloadHandler, false);
}
function UnloadHandler() {
//enable button here
window.removeEventListener('unload', UnloadHandler, false);
}
As mentioned before you need to add autocomplete="off" to your buttons.
Here is a sh+perl snippet to automate this in the case of <button>s in your HTML files/templates (under some assumptions):
find /path/to/html/templates -type f -name '*.html' -exec perl -pi -e \
's/(?<=<button )(.*?)(?=>)/#{[(index($1,"autocomplete=")!=-1?"$1":"$1 autocomplete=\"off\"")]}/g' \
{} +
The assumptions are:
Opening <button> tags begin and end on the same line. If this is not the case (i.e. they might be split over several lines) then replacing /g with /gs should help (the s modifier causes . to match newlines as well)
Valid HTML (e.g. there are no funny characters between < and >) and no unescaped greater than (>) inside the opening tag.
This is indeed an open bug in Firefox. There is also a note in MDN: autocomplete (scroll down to the second yellow box):
Note: The autocomplete attribute also controls whether Firefox will — unlike other browsers — persist the dynamic disabled state and (if applicable) dynamic checkedness of an <input> element, <textarea> element, or entire <form> across page loads. The persistence feature is enabled by default. Setting the value of the autocomplete attribute to off disables this feature. This works even when the autocomplete attribute would normally not apply by virtue of its type. See bug 654072.
If you are using Bootstrap, you might be interested in the
comment on the bug report by a Bootstrap team member
bug report in the Bootstrap repository
note in the Bootstrap documentation
I'm using <input type="file" /> in my webpage. I've different CSS classes for button and other controls. But I'm not able to add any class, style to browse button that appears due to above tag.
Is there any way to change its default appearance?
Thanks is advance.
You can't do that. You could only apply style to the entire <input />.
You could use opacity: 0 CSS hacks to replace it with you favorite image and image:hover.
Keep in mind that height: property will not work on Firefox 3.6; You could use font-size: to enlarge the height instead.
I have an example made: http://timc.idv.tw/html5-file-upload/ ; inspect the CSS of the 2nd demo.
You can't style the file input directly, but you can indeed give it some faux styling and/or make it invisible but still clickable. There's an article on how to do so at Quirksmode.
The <input type="file" /> control is notoriously difficult to style.
Here are some articles that can help.
There are also some nice libraries for styling hard-to-skin form elements. Uniform is nice for selects and upload fields.
You can't style a file input button with CSS. This is not the only element that you can not style. Some other inputs are not accepting styles. Look at this fiddle to see many types of inputs. Based on your browser some inputs renders different. Inputs like range input or date inputs are using OS level UI that is not editable by CSS.
What you can do is hiding the file input and showing another element like a div or another input that is accepting styling like button type input as your file input and trigger trigger click and submit (hitting enter) events on your hided actual file input.
Code example:
HTML
<input type="file" />
<label>Select file to upload: <input type="button" /></label>
CSS
input[type="file"]{visibility:hidden; width:0;}
JavaScript:
var fileInput = document.querySelectorAll('input[type="file"]')[0],
fakeFileInput = document.querySelectorAll('label')[0],
clickEvent = document.createEvent('MouseEvent');
clickEvent.initMouseEvent('click',true,true,document.defaultView,1,0,0,0,0,false,false,false,false,0,null);
fakeFileInput.addEventListener('click', function(event){
fileInput.dispatchEvent(clickEvent);
}, false);
Look at fiddle in action
So answer of you question is: No, unfortionantly you can not style file input BUTTON!