Due to Chrome (and other Blink browsers) having a bug where only the first 500 columns are painted i need either a fix/hack, or an alternative solution.
See bug here (there is 509 pages - not 500): https://codepen.io/anon/pen/pLxozK
/* codepen link must be accompanied by code */
column-width: 400px;
I parse EPUB html to a single file. The EPUB's styling must be preserved, so i can't change the html structure.
CSS columns does a good job of rendering such a flat document horizontally. But the 500 limit in Blink means blank pages in Android Webviews.
Is there any workaround for this bug?
Users can adjust font size etc meaning amount of columns can change. So an alternative solution must be able to adjust.
What a cool little bug, I've never seen that before!
By the looks of things you'll need to add display:none to some of your divs. You'll need to use Javascript to see what's in view and see what's not. You'll get the added bonus of not using any system resources unnecessarily as you won't be painting any of the pages that aren't in view.
Related
I am dealing with a task to prepare HTML document for printing in Chrome (requirement), that will contain unspecified number of text elements of unspecified length. The document needs to be printed two-sided, while the elements shall not mix with eachother. So whenever the text spans over odd number of pages, one extra blank page needs to be included.
So far I have read a lot about page-break-before and page-break-after CSS elements, that should do exactly the job I need. However they doesn't seem to work according to the specifications in Chrome. I have noticed it probably quite well-known problem, but haven't found suitable workaround yet.
I created following CSS:
#media print {
.block {
font-family: Arial, Helvetica, sans-serif;
page-break-after: right;
display: block;
float: none;
position: relative;
}
}
When I try it in Edge (44.18362.449.0), it seems to be inserting blank pages just as I need - the test output has 17 pages with page 6 and 12 completely blank. But my Chrome (85.0.4183.121) is not doing the same - here the page-breaks are made, but only one at the time, so the next div starts on even page, which is wrong for my case.
Simple demo code with some lorem-ipsum test data: https://codesandbox.io/s/inspiring-wing-rtwbn?file=/test.css
You definitely should keep in mind, that page-break properties are not supported correctly in most browsers. Check the caniuse report.
Also, here is the question that might help you, it already has some good answers.
Duplicating the main suggestions here with my own commentaries. It may be, that you can use the mix of every of them.
Number 1. (#Nils)
You could maybe try wrapping each of your reports in a div and then using something like jQuery to work out the height of the div to figure out whether it ends on an odd page.
If it ends on an odd page, then inject an empty div with your page-break-after class after that so that it feeds to the next page.
Obviously this will only really work if you know the dpi at which your page prints on your target printer. There's no magic answer that will just work for all scenarios.
72 dpi (web) = 595 X 842 pixels
300 dpi (print) = 2480 X 3508 pixels
("210mm X 297mm # 300 dpi")
600 dpi (print) = 4960 X 7016 pixels
You'd need to experiment a bit here with your standard printer settings to see what works for you/your client(s). If there are multiple scenarios, you could let them select from a drop-down.
So you'd use jquery to check the pixel height of the div, check it against the pixel height of the page to see if the div ends on an odd or even page - then inject the page break if the report ends on an odd page.
You'd also need to know upfront if the user will be using duplex printing - because you'd only need to do this for duplex printing.
Number 2. (#spekary)
Use inline styles for manual page-breaking where it is needed.
<div style="page-break-after: right">
<!-- your content -->
</div>
However, you should keep in mind that this doesn't exactly solve your problem, because, as you said, the document
will contain unspecified number of text elements of unspecified length.
But still, maybe you can play around with this solution.
I've been using latest Kendo grid for ASP.NET MVC.
Data table specs are like this,
columns --> 25 to 35.
rows --> anywhere between 1500 to 5000.
client side paging --> 20 rows
Issue is, when I'm doing the scrolling, IE 11 takes upto 1s to display data depending on screen resolution and grid content height. Which causes the UI glitch.
When I ran IE UI Responsiveness from Dev Tools, I got the below results.
I get that whenever user does scrolling, browsers have to render the rows and it takes a bit time. But IE 11 takes it to a whole new level. The moment it has to process 3-4 more rows, it starts acting jumpy and glitchy.
I did the testing in Chrome (& opera), Firefox. In which performace was very decent.
I tried to refractor CSS to reduce styling, but there's very little bit change I could afford.
Please let me know what is the next step? Should I keep calm and blame IE?
The grid works fine on its own in IE11, my team uses it.
It could be you've added some code that's being executed excessively.
The UI responsiveness tool isn't very useful. Try using the profiler in IE's Dev tools. Open the page with the problematic grid in it, hit the green arrow of the profiler to start recording, scroll the grid a bit and then hit stop in the profiler.
Sort the results by Count, Inclusive time and Exclusive time and see what stands out. After each sort look at the top ~50 entries for code you wrote.
When sorting by Count, you might find a piece of code that while is pretty short, it runs hundreds of thousands of times in a loop for no reason because of a simple mistake.
Sorting by time can show you pieces of code that are very demanding and perhaps could be moved to other places.
For instance, it could be you're running some logic on the view like formatting a date. If you see such a function in the profiler, it would be better to move this logic to the data fetching phase before the view is rendered.
There's an issue with a file named angular-material.css which causes a slow scroll like you describe. I've seen several places, like this one, that state removing the file or several lines in it solved the problem.
Are you using angular in your project? If you do, see if you have this file and try to remove it.
Because this question crossed 1000 views, I'm obliged to answer on how I fixed my issue.
Turns out, rendering of IE is slow when it comes to bigger screen of HD/FHD resolutions. So, the solution I followed was to promote the grid to new layer by adding the following to grid's CSS class.
.promote-new-layer{
transform: rotate(0deg);
will-change: transform;
}
will-change might not work in all the browsers. Hence the fallback would be to use transform:rotate(0deg).
Please ensure while doing so, you are not promoting unnecessary nodes.
Is there a way, without javascript, to load a small image for a background before the real image is downloaded? Without javascript because I know how to do it with it.
I can't test if the following CSS3 would work because it works too quick:
body {
background-image:url('hugefile.jpg'), url('tinypreload.jpg');
}
If the tinypreload.jpg is only, say 20k, and the hugefile.jpg is 300k -- would this accomplish the task? I assume that both downloads would start at the same time instead of being consecutive.
Update
Timing the results using Firefox's profiling revealed that it's not practical / not worth it to load a smaller background first. Main reason is the connection time. For tiny pictures it's the same time to connect as it is to download the content. For images where this becomes worth it -- the file size is not recommended for mobile.
If you still want to achieve this effect - combine all your "necessary" images into 1 file and display them as cropped background with correct offset. Load your high-res images through javascript, and update the content afterward.
You could exploit css load order and overrides to achieve this result.
Try loading the small image from your main css file and then put a <style></style> tag at the bottom of the html page. The inline style will override the main style but will load last because of it's position in the code.
The difference would be milliseconds though, so it may be too quick. It's also hacky and would result in invalid, but working code. Worth a shot though.
If you're trying to fix a mobile problem then have a look at this article on context specific images as that might be a more effective way to go.
This article on CSS3 multiple backgrounds may also help, as you may be able to exploit the stacking order to achieve the result you're after
It would be useful to know what problem you are trying to solve beyond load order, as it's hard to give advice on this one.
As I said in my comment you can use the 'net' tab in firebug for firefox (called timeline in chrome) to see the actual load order on your page - you can even filter it (on firefox) for CSS only or images only - this will enable you to test.
At the moment I've got a div which is 1024px wide.
In that box are two CSS3 columns with text flowing automatically from one to the next.
However, I want to restrict the height of these two columns to 700px - once they are full I want 2 more columns with the same height to appear underneath them.
Is this possible?
OK. It is totally possible to achieve what I think you are about to build. However, if you want to do it by yourself, you will need a bit more then just CSS3 styles in place. You will need a fair amount of JavaScript as well.
Take a look at this Columnizer jQuery plugin (it can do the job)
Here's a sample site showing results of it's work: http://welcome.totheinter.net/autocolumn/sample10.html
Update on this:
The Adobe CSS Regions proposal mentioned by gimme5 looks excellent. Unfortunately, according to caniuse.com, there now seems to have very little browser support - it's been removed from current versions of Webkit.
There is a simpler proposal which may do the required job: CSS Multi-column layout (http://www.w3.org/TR/css3-multicol/) which appears to have broader browser support. I haven't tried it yet, but it might work for you without having to pile in a ton of Javascript.
I'm trying to present my notecards in a web app style.
I'm not worried about caching, or making it work offline.
I just want it render well in the iOS browser.
Here's the link: http://kaninepete.com/flashcard/review.php?Sec=3
I want it to look the same as if you re-size your browser window to 320x480.
The problem is, it always renders a huge amount of blank space off to the side.
I want to lock the scrolling to only the vertical axis (like flipping through notecards),
but also have the text at a readable size.
You can use CSS media queries to set your template on a certain width/height model. This works well and can adjust specifically for iPhone screens.
As for the font size issue you'll probably need to just spend time testing. With that it's going to require some type of virtual simulator or a real iPhone where you can test the site. I just loaded it up onto my iPhone 4 and I see what you mean about additional space - this is just because of your page size. Try messing with CSS media queries I think you'll find the answer in there.
Here is a very handy Google search to hopefully get you started on the right track. CSS3 has a lot of new features. Many of them geared towards mobile :)
Reading your question again, here's some suggestions based on what I think you're looking for.
Make sure your document is valid HTML before you continue. Safari on iOS supports HTML 5, so I'd suggest targeting that, unless your platform targets something different already.
If you just want it to run well in iOS Safari, then code for that. If you want it to look similarly in other browsers, however, then it may be necessary to look at styles targeting the iOS device (via width/height). See http://davidbcalhoun.com/2010/using-mobile-specific-html-css-javascript (It seems hacky, but based on some research a week ago, this still seems to be the suggested route.)
You've got CSS that shouldn't be in there if you want to target multiple browsers. overflow:hidden and set pixel widths.
Generally, I'd say you'll want to tweak your markup as well. List items or headers would be much better than just simple breaks.
Maybe I'm just oversimplifying the question, but it looks to me like all you really need to do is wrap each notecard in a div, perhaps giving each div a <div class="notecard_wrapper">. then just attach a stylesheet that specifies the width and height you want for each card.
This page explains Safari's viewport and how to change it. It will probably fix the font size problem and maybe help with the page size.
Basically, Safari by default simulates a screen that's about 900px wide, when it's actually about 300px (so the page appears zoomed out). This makes pages designed for real computers render properly, but for a web app you usually don't want it to zoom the page at all. The viewport tag should let you control that.