I have this template
<ons-row>
<ons-col width="22%" class="card" ons-lazy-repeat="SimilarDelegate"><!--ng-repeat="item in similarResults"-->
<img ng-src="{{item .thumb}}" class="thumbnail" ng-click="showQuickInfo(item .id)" err-src="img/noimage.jpg" />
<ons-row>
<ons-col width="75%">{{item .name}}<br><ons-icon icon="md-star" size="22px"></ons-icon> {{item .rating}}</ons-col>
</ons-row>
</ons-col>
</ons-row>
Using ng-repeat my items are rendered in a two column row (each row has two items). But my list can go up to 16000 items and ng-repeat' performance is not that good even with 300 items. I changed the code to use ons-lazy-repeat and the loading performance is now more than fine! but each row now has only one item instead of two. I've been trying to make it two items each row but nothing yet. Is there a way for ons-lazy-repeat to accomplish that?
Thanks
ons-lazy-repeat works only for vertical repetitions.
While ng-repeat just puts more items, so basically it loads everything, lazy repeat has a maximum number of items which it displays. So if you scroll down 1000 items you will still have only 100 items in the DOM at the same time. So remembering more complex stuff about how the DOM elements would be positioned if it they had existed becomes something complex. Therefore ons-lazy-repeat supports only vertical repetition. That's why you have probably noticed that it requires to know the height of the repeated element. So basically you cannot repeat items the way which you are describing. However there are still relatively easy ways to get your desired result.
Here are the 2 solutions which come to my mind:
Easiest solution is just to have the ons-lazy-repeat directive for the element which will contain these 2 items. Then everything will be fine. This is how ons-lazy-repeat should be used.
The second one is kind of hacky and I wouldn't really recommend it, but some people like these things. Basically you should be able to cheat the ons-lazy-repeat by giving it false values and doing some css hacks.
For example lets say that you're
.item { height: 100px; width: 50%; }
.item:nth-child(even) { margin-top: -100px; margin-left: 50%; }
And your height function can return 50 instead of 100. There is also a possibility that some of these styles may require !important, since the lazy-repeat may be adding some inline styles.
CSS Hacks prevail once again.
But still I would recommend the first solution.
Related
I have a situation where my end points and mid points can vary.
I always have:
<p style="margin-top: 0px;" >
and
<p class="contactAdvisor">
in between, I will have varying items including <b>, <i>, <strong>, <br> headings 1,2 or 3. I might also have one or more <p> in between the two fixed items.
What I'm trying to get is all of the text in between these two elements no matter whether wrapped in headings, various stylings or inside sub paragraph elements.
I've messed around with contains and preceding/following-sibling but my best attempt has been to create based on pre/follow for each use case. And even that leaves me with some issues because if there are multiple <p> inside and I'm trying to select all of them, I only get one.
Depending on the hierarchy, you can use either preceding:: or preceding-sibling::.
Try selectong something along the lines of:
//*[preceding::p[#style="margin-top: 0px;"] and not (preceding::p[#class="contactAdvisor"])]
This should exclude everything before the first p with the first condition and everything after the second with the second. Untested so you may have to tweak the check a little.
//p[#style="margin-top: 0px;"]/following::*[following::p[#class="contactAdvisor"]]
//*[preceding::p[#style="margin-top: 0px;"] and following::p[#class="contactAdvisor"]]
I'm building a data grid with thousands of list items and no pagination. As a result, the performance with live-binding is, understandably, very poor. With ~20 list items, there is no lag whatsoever.
<thead>
{{#each columns}}
<tr><td can-click="sort">{{name}}</td></tr>
{{/each}}
</thead>
<tbody>
{{#each thousandsOfItems}}
<tr><td>{{name}}</td></tr>
{{/each}}
</tbody>
Is there a way for part of my template to be live bound, such as the <thead>, but use simple string concatenation/injection for the <tbody>?
Edit
My approach may be the problem. Thousands of static <tr>s are likely quite laggy too. It's been suggested to me that I try adding/removing rows as the page is scrolled.
I made a JSPerf rendering 4000 rows in a single column table, which you can check out here:
http://jsperf.com/can-stache-table-render
Some takeaways from these experiments:
without live-binding you can get a 10x performance boost. If you need more than that, though, you'll probably have to do perceived performance boosts.
When not live binding any data, there's no performance boost in using {{#each}} versus just {{#thousandsOfRows}}
Using divs instead of table rows was something I was interested in trying since you could conceivably see incremental drawing faster (but really, with all of this running synchronously, the UI will lock until it's all drawn this way), but it's 35% slower to draw the whole table, and probably is best avoided.
So based on this, what can we do?
Page the table, or rather, draw many tables of a fixed size until you run out of data. The first screen will render quickly and the rest will fill in as you go. Make use of setTimeout() to draw the next table, so as to not lock the UI.
Use live-binding, but page it in using a pattern like this:
var i=0;
function loop() {
while(i < source_list.length) {
list_in_live_binding_context.push.apply(
list_in_live_binding_context,
source_list.splice(i, 20)
);
i += 20;
setTimeout(loop, 4);
}
}
Do one of the two previous things, but hide the results behind a screen with a spinner until the rendering is finished
Use jquery-ui-scrollable (https://github.com/bseth99/jquery-ui-scrollable) to detect when elements have been scrolled into view -- use a Stache helper to only render items once they're scrolled in to view, but you'll need to reserve the space first. This can be helpful if each individual row has complex rendering associated with it. You can delay the details until they're necessary.
Sorry it's not a simple answer, but it's not a simple problem. :) HTH, anyway.
CSS Selectors are parsed right to left, and then displayed.
With this in mind, based on this code:
<a href="#" class="myImage">
<img>
</a>
Which is more performant?:
.myImage img
or
.myImage img:only-child
Does :only-child help specificity in selector selection? So instead of initially matching all <img> in the document then looking for the parent class, does it only match <img>'s that are the only child (thereby reducing the pool of selections)?
reference read: http://csswizardry.com/2011/09/writing-efficient-css-selectors/
EDIT
Found further reading:
The sad truth about CSS3 selectors is that they really shouldn’t be
used at all if you care about page performance. Decorating your markup
with classes and ids and matching purely on those while avoiding all
uses of sibling, descendant and child selectors will actually make a
page perform significantly better in all browsers.
-David Hyatt (architect for Safari and WebKit, also worked on Mozilla, Camino, and Firefox)
Source: http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
Alright, so this depends completely on the use case. What I'm going to do is handle cases.
Point 1 - Concerning given example
Case A
Say your code is simply:
<a href="#" class="myImage">
<img>
</a>
In this case .myImage img and .myImage img:only-child will have essentially identical performance hits. Reason being is as follows:
CSS performance hits are derived from having to style or re-style boxes. What CSS does is affect your graphics processor, not the CPU, so we only care about visual updates. And styling things again with duplicate properties DOES cause a redraw (By this I mean duplicate properties that are applied at a later time, which selectors generally cause).
Usually, .myImage img would style ALL <img>s in .myImage. While using the only-child selector may not style all (obviously).
But in this example, both .myImage img and .myImage img:only-child would do identical things, since they would both cause 1 draw/redraw on the same box.
Case B
But suppose we have:
<a href="#" class="myImage">
<img>
<img>
</a>
Here though, we have a different story.
In this example, only-child wouldn't work at all, since <img> is not the only child.
Case C
Finally, suppose you have this, but you only want to style the under the :
<a href="#" class="myImage">
<img>
</a>
<div class="myImage>
<img>
<img>
</div>
In this case, using the only-child selector would be significantly better performance-wise, since you only will style one element, instead of three.
Conclusion and Takeaway
Basically, remember a few things.
CSS selectors help you with writing code because you get to add less IDs and Classes, however, they are almost always less efficient than using all IDs and Classes, because using selectors will causes extra redraws. (Since you'll inevitably style multiple elements with some selector, and then re-style other things with IDs or classes, causing unnecessary redraws)
only-child is NOT faster than .class child if that .class only has one child.
Technically what you are comparing are two completely different things, used for different purposes.
Conclusion
In final answer to your question. In your shown example, neither is more efficient than the other since they cause identical redraws.
However, as
"Does :only-child help specificity in selector selection?"
goes: Yes, that's the point of the selector. See: http://www.w3schools.com/cssref/sel_only-child.asp
Sources:
I am a significant volunteer developer for Mozilla Thunderbird and the Mozilla project and work in the CSS area.
FYI
There are of course weird exceptions to this, but I won't go over them here since I think your exact question doesn't give a brilliant example.
Point 2 - Concerning speed of find selectors
I am purposely trying to drive home the point that it is the drawing the causes the CSS perf hit, not finding the selectors. However, the reason I say this is not because finding selectors takes no time, but instead because it's time is miniscule to the time caused by drawing. That said, if you did have 5,000 <div>s or something, and attempted to style a few using pseudo selectors, it would definitely a little longer than using CSS classes and IDs.
Again though, in your example it would make no difference, since it would look through each element anyway. Why only-child is helpful perf-wise is because it would stop searching for some element after it finds more than one child, whereas simply doing class child would not.
The problem with pseudo selectors is that they usually require a lot of extra searching AND it happens after IDs, classes, and such.
The links you provided are actually very helpful and I'm surprised they didn't answer your question.
One thing I should point out is that many selectors believed to be slow may be vastly improved now. See: http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/
Remember selector performance is only important on very large websites.
If I open the following HTML e-mail in Gmail or Outlook it renders as it should:
<img src="img.png" />
However, if I open it in Outlook and then forward it to Gmail, it adds extra garbage HTML that makes the area taller than it should be (the 'p' tag is responsible for the added height - 3px specifically):
<p class="MsoNormal">
<span style="font-size:10.0pt">
<img src="img.png">
<u></u>
<u></u>
</span>
</p>
There are lots of solutions for fixing spacing issues in Gmail, like adding display:block to the image, setting the font-size and line-height to 0, etc. I've tried over a dozen methods and none have worked because of behind the scenes HTML modification that I have no control over - styles and attributes getting stripped, tags with their own properties getting added, etc.
Is there is a work around to allow the original formatting to always be preserved? I will gladly provide any additional details needed, just let me know.
There is no fix for this, but there are ways to limit and hide the size of the separation. I'll refer to it as separation, but it is really the top cell expanding due to Outlook applying the mso-normal p tag. Here is a related article.
Between tables creates a bigger gap (about 15px) than between table rows (2px). It is more complex, but try and put everything that you can't afford separating into one big table. Colspans and rowspans can be complex, but they work if set up correctly.
To hide the separation, wrap all the tables in a master-content table with the bgcolor set. For example, make one big content pane set to white. When sending from Outlook, all your child tables will then move, but the gaps will remain white, stopping unwanted lines appearing in your email body.
A trick for footers - As the last child table of your main white panel, when this separates, it will create a white line underneath it. Either remove the footer table from the main panel or set the cell bgcolor to the same as your email background to hide this separation.
I managed to change this situation by changing the MsoNormal class
<style>
td p.MsoNormal {margin: -4px !important}
/* ou */
.MsoNormal {
margin: -4px !important;
}
</style>
I'm trying to use CKEditor for a project and I found the need for bookmarks. The documentation says that the intrusive way to create bookmarks add span elements in the source. This is just fine with me and that is exactly what I would want it to do.
However, I can see in the source that the span elements are wrapped in p elements.
<p><span id="cke_bm_147S" style="display: none;"> </span> </p>
This creates problems for me with the way the text is displayed and mainly when trying to navigate the document.
I didn't find anything that even mentions the creation of these p elements. Could I have set something wrong? Is there a way to prevent these to be created?
Thank you
The span bookmark is an inline element so it cannot be the root element of the content. It is wrapped in a block element (which is by default a paragraph).
This behaviour depends on editor enterMode. If it is a default one - ENTER_P - you will have a p element as a wrapper. For ENTER_DIV you will have a div element. And for ENTER_BR there will be no wrapper which means it is the effect you would like to achieve.
Check this codepen for demo.
Please keep in mind that enterMode other that ENTER_P is not recommended due to some caveats. So maybe in your case it will be better to reconsider some different solutions instead of changing enterMode.