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();
});
Related
I have 4 links. Previously implemented as A tags.
My goal is to switch the request method (GET) with POST. Everything else have to remain the same!
The problem - it must be implemented using pure HTML - to be exact - no ajax and no window.open().
My solution is half way there. Hopefully to get a creative second half from you (impossible is also an answer)
Here is the (simplified) HTML:
<form
id = "resultsForm"
target="_blank"
action="http://example.com"
method="post"
>
<input type="hidden" name="data" value="someData">
<button type="submit" value="submit">
<p class="contextual"> title </p>
<span></span>
</button>
</form>
Now, it looks and feels like the old implementation and also sends POST requests
But - contrary to a link - a button can't be middle clicked or opened in new window when right clicking on it (by default...)
Can I somehow wrap it in an A tag to achieve the explained behavior without using js events or be conflicted with form subbmission?
Your help is really appreciated
No, this is impossible.
Anchor elements cannot contain interactive elements such as button elements.
Forms should be posted to the target window, so a normal click on the submit button, by virtue of the _blank value, should open an unnamed browsing context (a new window or tab).
Users should be accustomed to not middle-clicking on buttons, although there is a habit of developers to style links to look like buttons, throwing off users' expectations (end rant:)).
I'm trying to get HTML patterns to work. The behaviour I expect is that as soon as text that doesn't match a given pattern is entered into an input, the edges of the input will turn red (error state), and go back to normal as soon as the text matches the pattern again. This is the pattern I'm using - for non-regex people, it allows characters from the alphabet, both upper and lower case, and requires exactly three characters.
<input type="text" pattern="[A-Za-z]{3}">
I couldn't get this behaviour working reliably in my project, so I took this example from W3Schools: https://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml5_input_pattern to test it.
When I load it in Firefox (latest version):
After entering invalid data for the first time after the page renders, I need to click somewhere else (the input needs to lose focus) for the input to go into error state.
After this, if I enter valid data and click somewhere else, the state of the input goes back to normal. (expected behaviour)
However, if I then enter invalid data without the input losing focus, the error state is still not triggered.
When I test it in Chrome (latest version, again), the input simply never turns red, no matter what I enter or where the focus is.
Not only does the pattern not behave how I expected, but it does not behave consistently from browser to browser.
Can anyone explain this? Is this an official feature? I know it doesn't behave consistently on mobile browsers, but it should on major desktop browsers (platform in Win7 FWIW)
HTML5 validation styled differently across browsers. While supporting browsers will all prevent a form submission if it's invalid, everything outside of that is a browser design decision.
You can attempt to enforce certain behaviors using JavaScript. For example, if you want some kind of immediate feedback for invalid input, you can attach a handler to the input event.
document.querySelector('input').addEventListener('input', function(e) {
if (!e.currentTarget.checkValidity()) {
e.currentTarget.classList.add('invalid');
} else {
e.currentTarget.classList.remove('invalid');
}
});
.invalid {
background-color: red;
}
<form>
<input type="text" pattern="[A-Za-z]{3}">
<input type="submit">
</form>
Obviously you'll want better custom styling, and something that doesn't clash with the native "invalid state" styling of major browsers, but this at least gets you started in the right direction.
You could also force the browser to report validity on the input event. But you may find most browsers' behavior for reportValidity is a bit too loud to show on each invalid input.
document.querySelector('input').addEventListener('input', function(e) {
e.currentTarget.reportValidity();
});
<form>
<input type="text" pattern="[A-Za-z]{3}">
<input type="submit">
</form>
I create <div contenteditable="true"></div>
The behaviour I want is:
Enter key press = <p></p> around the text line
Shift-Enter keys press = <br/> after the text line
To get the behaviour I want in Firefox, I have tried creating the following "keypress" event:
function(ev) {
if (ev.keyCode == '13') {
document.execCommand('formatBlock', false, 'p');
document.execCommand('insertBrOnReturn',false,false);
}
return false;
}
but Firefox (as at 33.1.1) insists on inserting <br></br> on first enter (which then gets wrapped in my paragraph). I understand it to a degree when a line is empty however I do not understand why it is not removed as soon as a character is inserted into the new line.
For example, assume I type:
hello<enter>goodbye
into the editable field, I will end up with the following markup (using the above event handler)
<p>hello</p>
<p>goodbye<br></br></p>
The <br></br> does indeed disappear if I hit enter again but then I am left with the following markup
<p>hello</p>
<p>goodbye</p>
<p><br></br></p>
There are 2 problems with this:
Users will not necessarily hit the second enter, leaving "invisible" <br></br> after the goodbye
Alternatively users will hit the second enter and end up with an essentially redundant line containing <p><br></br></p>.
In fact the only way I can see to get
<p>hello</p>
<p>goodbye</p>
ie. what I want, is to to use the following sequence hello<enter>goodbye<enter><backspace> which seems patently ridiculous.
At this point I should say that I personally love Firefox as a browser and my strong preference is to keep using it, however for our business clean editing markup is critical, and in Chrome, using the above method (excluding insertBrOnReturn) produces the desired markup (the above keypress event function switches Chrome cleanly to use p rather than its standard div)
So I am in a difficult position, and I would welcome any input from other Firefox enthusiasts as to how the above can be achieved elegantly if indeed it is possible (please don't invest time providing complex hacks though as we are unlikely to use them - in my limited experience complexity is diametrically opposed to reliability)
thanks in advance for any help!
(PS - after working with this, I'm really not sure that the Chrome div implementation is any better - see comments below)
In our MVC5 project there is a page where user can check multiple assets.
Each asset is represeneted by checkbox and name.
When there are a lot of assets (about 800-1000) Chrome getting extremely slow. It's even sometimes show message that "page is unresponsible".
It looks like this:
- page is partially rendered and stucked on DIV with checkboxes
- then there is delay 30-40-50 sec. Sometimes error message
- DIV with checkboxes rendered and rest of the page rendered too
In FF and IE it's ok.
Thanks in advance
I agree that it's not a good user experience, but at the current stage I need to solve this problem.
Here is markup (this div is 4 level nested):
<div class="list">
#for (int i = 0; i < Model.Items.Count; i++)
{
<text>
#{var cid = Guid.NewGuid().ToString();}
#Html.HiddenFor(m => Model.Items[i].Id)
#Html.CheckBoxFor(m => Model.Items[i].Selected, new { id = cid })
<label for="#cid">#Trakopolis.WebSite.AppHelper.GetLocalizedString(Model.Items[i].Name)</label><br />
</text>
}
</div>
You could try to use javascript for this where everything is in plain text with data attributes and on click, input element is temporarily added, the input element takes the input, sends it to the server (or saves it in indexeddb for async using a service worker) and removes itself or waits for next input.
<td id=“unique-id1” data-url=“/action” data-name=“InputName”>data</td>
Same problem with Safari, I suspect a webkit bug. Any page with hundreds or thousands of input fields will be very very slow to navigate or edit.
See Why does Safari Mobile have trouble handling many input fields on iOS 8
We have a page with some tables with 300 rows, each row has several cells and each cell is editable (input).
Workaround given in link above works nicely.
Looks like Chrome not uses closing tags for checkboxes dropdown markup for and <br> that is somehow forces additional browser internal checks and as result slow page rendering in comparison to IE and FF browsers(that are using closing tags). To avoid Chrome slow loading because of <br /> tags you may use opening and closing <div> instead and speed up page a bit, but I'm not sure whether <input> elements may be replaced somehow.
Thanks for spending time to read this
I have a form where is call a JS function to copy the html content of a DIV to a hidden form field so that I can submit this with the form. It works fine on desktop webkit broswers and also on mobile safari on iPad. However when I run the application in fullscreen mode (by saving a shortcut on home screen), this does not work.
Here's my code
JS function:
function update_script_in()//copies scripts and submits the form
{
$("#script_in").html($("#scriptContent").html());
$('#ResiForm').submit();
}
form submission:
<input type=submit value="Submit" onclick="update_script_in()">
Thanks for your help
This is quite old, but after googling around to solve the same issue for me, I have not found a solution. Looks like some weird behaviour from iPad (easily reproducible, no way to fix, at least that I found): the target input field gets changed indeed, but the posted value is the original one (???)
So just in case a workaround is useful to somebody, instead of applying the changes from the contenteditable div on form submit, I apply the changes whenever the div is changed (no on change event for contenteditable divs, so really it is done on blur event):
<div id="editor_inline_core_body" class="inputbox editor-inline" contenteditable>[initial value here]</div>
<input type="hidden" id="jform_core_body" name="jform[core_body]" value="[ initial value here]" />
<script>
jQuery('#editor_inline_core_body').blur(function() {
var value = jQuery('#editor_inline_core_body').html();
jQuery('#jform_core_body').val(value);
return true;
});
</script>
Less efficient, but at least it works. If you want a bit more of efficiency, you can check old and new values using also focus event, but at least I do not think it is a big deal or worth the added complexity.