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)
Related
If you forget to close a HTML-Tag, Chrome will validate your code and try to fix problems like this.
I had a major problem because I forgot a closing Form-Tag, and instead of closing it correctly, Chrome deleted a following form, not the inputs, simply the Form-Tags.
When I looked at the Source Code itself, the Form-Tag was there, but not in the Elements-Tab in the console.
So at first, I thought it must have something to do with some JS deleting this DOM-Node and set a DOM-Breakpoint to find the script.
To cut a long story short, it took me hours to find out, that no JS deleted my form, but Chrome itself thought: There is a missing so I delete some other to fix that...
Is there any possibilty to see if Chrome automatically changes your DOM?
Thank You!
The browser Engine does indeed. They use string replace methods, although it happens internally.
<div>
</div>> // mistake
<div> //missing end tag
<div></div>
---------------------------------------------------
Methods
file=file.stringreplace('>>', '>')
an uneven count will add the missing div just after the next beginning div and conditionally if the missing is not found by the end of the file:
file=file.stringreplace('
<div>', '</div>
<div>')
The Parsing Engine after the missing and broken tags are repaired then parses the file and can then with a positive count set the screens GUI widgets by opening and closing tags as GUI Frames. It does this by adding tokens delimiters to the actual div tags making them easily distinguished from each other.
<div1s>
</div1e>
<div1s>//section columns
<div2s></div2e>
<div2s></div2e>
<div2s></div2e>
</div1e>
<div1s>Footer</div1e>
-----------------------------------------------------
The GUI Frame Tokens
for each "<dive1>"{
FrameCreate(CSS--ATTRIBUTES FROM ASSOCIATIVE ARRAYS--)
//the GUI Frame Widgets VERTICAL SECTIONS
}
//Next it finds the nested divs2 and embeds these into the thir parents above but with embedded Text Widgets also.
FrameTextBoxCreate(--CSS MATED ATTRIBUTES RULES--)
div3 etc------and so on.
In fact it is in the WebView GUI Widget Sets in its customized Mosaic Canvas Widget Sets in Chrome would be where they are repaired.
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.
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 have an array of 2000 items, that I need to display in html - each of the items is placed into a div. Now each of the items can have 6 links to click on for further action. Here is how a single item currently looks:
<div class='b'>
<div class='r'>
<span id='l1' onclick='doSomething(itemId, linkId);'>1</span>
<span id='l2' onclick='doSomething(itemId, linkId);'>2</span>
<span id='l3' onclick='doSomething(itemId, linkId);'>3</span>
<span id='l4' onclick='doSomething(itemId, linkId);'>4</span>
<span id='l5' onclick='doSomething(itemId, linkId);'>5</span>
<span id='l6' onclick='doSomething(itemId, linkId);'>6</span>
</div>
<div class='c'>
some item text
</div>
</div>
Now the problem is with the performance. I am using innerHTML to set the items into a master div on the page. The more html my "single item" contains the longer the DOM takes to add it. I am now trying to reduce the HTML to make it small as possible. Is there a way to render the span's differently without me having to use a single span for each of them? Maybe using jQuery?
First thing you should be doing is attaching the onclick event to the DIV via jQuery or some other framework and let it bubble down so that you can use doSomething to cover all cases and depending on which element you clicked on, you could extract the item ID and link ID. Also do the spans really need IDs? I don't know based on your sample code. Also, maybe instead of loading the link and item IDs on page load, get them via AJAX on a as you need them basis.
My two cents while eating salad for lunch,
nickyt
Update off the top of my head for vikasde . Syntax of this might not be entirely correct. I'm on lunch break.
$(".b").bind( // the class of your div, use an ID , e.g. #someID if you have more than one element with class b
"click",
function(e) { // e is the event object
// do something with $(e.target), like check if it's one of your links and then do something with it.
}
);
If you set the InnerHtml property of a node, the DOM has to interpret your HTML text and convert it into nodes. Essentially, you're running a language interpreter here. More text, more processing time. I suspect (but am not sure) that it would be faster to create actual DOM element nodes, with all requisite nesting of contents, and hook those to the containing node. Your "InnerHTML" solution is doing the same thing under the covers but also the additional work of making sense of your text.
I also second the suggestion of someone else who said it might be more economical to build all this content on the server rather than in the client via JS.
Finally, I think you can eliminate much of the content of your spans. You don't need an ID, you don't need arguments in your onclick(). Call a JS function which will figure out which node it's called from, go up one node to find the containing div and perhaps loop down the contained nodes and/or look at the text to figure out which item within a div it should be responding to. You can make the onclick handler do a whole lot of work - this work only gets done once, at mouse click time, and will not be multiplied by 2000x something. It will not take a perceptible amount of user time.
John Resig wrote a blog on documentDragments http://ejohn.org/blog/dom-documentfragments/
My suggestion is to create a documentDragment for each row and append that to the DOM as you create it. A timeout wrapping each appendChild may help if there is any hanging from the browser
function addRow(row) {
var fragment = document.createDocumentFragment();
var div = document.createElement('div');
div.addAttribute('class', 'b');
fragment.appendChild(div);
div.innerHtml = "<div>what ever you want in each row</div>";
// setting a timeout of zero will allow the browser to intersperse the action of attaching to the dom with other things so that the delay isn't so noticable
window.setTimeout(function() {
document.body.appendChild(div);
}, 0);
};
hope that helps
One other problem is that there's too much stuff on the page for your browser to handle gracefully. I'm not sure if the page's design permits this, but how about putting those 2000 lines into a DIV with a fixed size and overflow: auto so the user gets a scrollable window in the page?
It's not what I'd prefer as a user, but if it fixes the cursor weirdness it might be an acceptable workaround.
Yet Another Solution
...to the "too much stuff on the page" problem:
(please let me know when you get sick and tired of these suggestions!)
If you have the option of using an embedded object, say a Java Applet (my personal preference but most people won't touch it) or JavaFX or Flash or Silverlight or...
then you could display all that funky data in that technology, embedded into your browser page. The contents of the page wouldn't be any of the browser's business and hence it wouldn't choke up on you.
Apart from the load time for Java or whatever, this could be transparent and invisible to the user, i.e. it's (almost) possible to do this so the text appears to be displayed on the page just as if it were directly in the HTML.
I'm having a ton of problems with every version of IE, one of which is that IE7 won't register input in this text input field.
http://www.flightm8.com/redesign
I'm a bit nervous about posting the link since the site looks a mess and doesn't function properly in any version of IE at the moment, and it is still quite a way off being ready for public consumption. But if anyone can shed any light on this particular problem I'd very much appreciate it.
So the question is: What is causing this problem in IE7?
Update: I've also added an additional textfield at the bottom of the page to try and rule out any CSS wierdness that might be causing the problem.
<form method="post" action="nowhere.php">
<input type='text' name='test' value='testing' />
</form>
And I still can't enter any text, or select the text that is in there. I'm wondering now if it's a problem caused by running a standalone version of IE7 and IE6.
thanks
-t
the function causing problem is this one :
function modalAlert
the call that need to be debugged is this one :
modalAlert("NO SELECTIONS");
in
function findRoutes
the line that bug is :
$("#dialog").css("top", dTop);
first, you should avoid iframes when you can, why don't you do :
var message = $('<div></div>').load('/modal/"+modalpage);
instead of crappy code like this :
var iframe = "<iframe id='modal_frame' width='533' height='292' src='/modal/"+modalpage+"' >You didn't give me any information</iframe>"
If you don't need iframes, don't use them !
$('body').append(message);
I have IE7 on win xp (native), I was able to enter text but after a freeze (when you add all those markers), then when entering text and clicking on "find routes", there's a bug that i just explained to you ...
I would imagine it is because the input box doesn't have a 'name' field, which is used when posting form data.