I am building my first electron desktop app. It creates a formatted document/book from spreadsheet data to either be printed or made into a PDF. I am trying to figure out the best way to prevent performance loss from reflow/repaint when having a large document(lots of divs). I have found that if I have the book in an iframe then I do not suffer reflows/repaints from UI changes and can control when to have it loaded. If I try to create a PDF however I will only get the amount of the iframe that is visible.
Simply, I'm looking for the best solution to prevent reflow in a complex HTML element while still being able to print it to PDF.
I've found a solution to the problem.
As far as I understand, for an electron desktop app, that is not running a server, you cannot directly access myIframe.contentDocument on elements for actions such as append, innerHTML, or offsetHeight etc. The only thing you can do is contentDocument.write(), however once you have used this method, you have access to all of the other regular DOM methods. The best I can understand is that when you use contentDocument.write() it essentially creates a virtual HTML document. This is my workaround at the moment which is working like a charm in giving me control over what elements reflow and what ones do not.
Hope this helps anyone dealing with the same issue.
Related
How can I programmatically interact with an existing web page in a web browser launched in a standard way? For example I navigate to a specific page and want to be able to run a Python script that fills some edits or clicks some elements.
This should be possible at least through IAccessible2 for main browsers, but I did not find any pointers. To put it in another way, how do screen readers do it? And bonus question, is there Python library for it?
EDIT: I am looking for something more than user input simulation. I would like to programmatically read the DOM at least, write if possible. So far I have looked at code in NVDA which is very low-level and complex. Is there anything easier?
How can I programmatically interact with an existing web page in a web browser launched in a standard way? For example I navigate to a specific page and want to be able to run a Python script that fills some edits or clicks some elements.
The answer is keyboard/mouse macros if you have to visually see the browser as it happens. You can google macro programs for your OS.
But you most likely are looking for a headless browser such as PhantomJS, HtmlUnit, TrifleJS, Splash, and SimpleBrowser
Check out - https://saucelabs.com/blog/headless-browser-testing-101
When you mention 'interact with an existing webpage in a web browser launched in the standard way' you are talking about the DOM (Document Object Model).
Many QA environments are running testing scripts on code that has not been rendered by the browser into a DOM (you see the DOM when you inspect a page using your browser tools). When you use a headless browser it creates the DOM and then runs all the tests as if a human were clicking without having to visually look at it happen.
see - https://css-tricks.com/dom/
To put it in another way, how do screen readers do it? And bonus question, is there Python library for it?
Screen readers are interacting with the DOM at a low level. I do not know if there is a Python library. Most likely this would be overkill though unless you are building a desktop app that interacts with browsers like a screen reader does.
edit...
I did some more digging and found this article that is a much more verbose explanation of how screen readers interact with the browser/dom.
Also, there is a python API for manipulating the DOM and this library seemed popular.
I often have a problem where I'm working on a dynamic web app with tons of front-end or back-end code and there is a CSS problem that just eludes me despite an hour of scratching my head. I know that StackOverflow could solve it in a second, and I'd like to post it, but I either have to
Make the app public along with steps to reproduce the state, or
Tediously copy out the DOM and assets (CSS) along with the current state.
Neither is very straightforward. Note that the DOM is dynamically generated so "View Source" won't cut it. Similarly, the CSS could be spread out across multiple files and I'd like to just grab it all at once.
Is there an easy way to copy out the DOM and all CSS as a single file so that I can insert it into something like JSFiddle and be on my way?
The quickest way to get all HTML on the page as-is is to paste this in the address bar:
javascript:alert(document.body.outerHTML)
You can also use the console, of course, but the above works even in old IE versions and is easier to copy/paste.
I don't think there's a good way to get the CSS at all, but you could try using a jQuery selector or similar to get the URLs:
$('link[type="text/css"]')
.each(function(x, link){
console.log(link.attributes.href.value)});
And downloading and concatenating the CSS.
We're currently researching if it is possible to on the fly generate/change the UI of a metro app. So far I have seen only that the reflection options are somewhat limited. But perhaps if we're using HTML/JS we can modify the HTML on the fly? Anybody tried something like this?
Will fire up VS later and give it a go, just thought I'd ask here and see if we could have a disucssion on the topic.
Most Javascript-based apps modify their HTML on the fly as this is a pattern promoted by the Navigator template. So for example even just clicking a link and navigating to another page will replace the content of a 'page' container element instead of reloading the whole page and thus reloading all .js and .css files.
Also the WinJS.UI.ListView will dynamically create and reposition elements in your DOM as you scroll its contents.
Basically you can do anything you'd do in a webapp and re-use patterns like known from AJAX to make your UI adapt dynamically.
Depending on what you want to achieve, you should with increasing complexity keep in mind that your app should be able to suspend and restore its state from scratch at any point.
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)
Usually Flash and Flex applications are embedded on in HTML using either a combination of object and embed tags, or more commonly using JavaScript. However, if you link directly to a SWF file it will open in the browser window and without looking in the address bar you can't tell that it wasn't embedded in HTML with the size set to 100% width and height.
Considering the overhead of the HTML, CSS and JavaScript needed to embed a Flash or Flex application filling 100% of the browser window, what are the downsides of linking directly to the SWF file instead? What are the upsides?
I can think of one upside and three downsides: you don't need the 100+ lines of HTML, JavaScript and CSS that are otherwise required, but you have no plugin detection, no version checking and you lose your best SEO option (progressive enhancement).
Update don't get hung up on the 100+ lines, I simply mean that the the amount of code needed to embed a SWF is quite a lot (and I mean including libraries like SWFObject), and it's just for displaying the SWF, which can be done without a single line by linking to it directly.
Upsides for linking directly to SWF file:
Faster access
You know it's a flash movie even before you click on the link
Skipping the html & js files (You won't use CSS to display 100% flash movie anyway)
Downsides:
You have little control on movie defaults.
You can't use custom background colors, transparency etc.
You can't use flashVars to send data to the movie from the HTML
Can't use fscommand from the movie to the page
Movie proportions are never the same as the user's window's aspect ratio
You can't compensate for browser incompetability (The next new browser comes out and you're in trouble)
No SEO
No page title, bad if you want people to bookmark properly.
No plugin information, download links etc.
If your SWF connects to external data sources, you might have cross domain problems.
Renaming the SWF file will also rename the link. Bad for versioning.
In short, for a complicated application - always use the HTML. For a simple animation movie you can go either way.
You also lose external control of the SWF. When it's embedded in HTML you can use javascript to communicate with the SWF. If the SWF is loaded directly that may not be possible.
Your 100+ lines quote seems pretty high to me. The HTML that FlashDevelop generates for embedding a SWF is only around 35 lines, with an include of a single swfobject.js file. You shouldn't need to touch the js file, and at the most would only have to tweak the HTML in very minor ways to get it to do what you want.
In my experience not all browsers handle this properly. I'm not really sure why (or which browsers) but I've mistakenly sent links like this to clients on occasion and they've often come back confused. I suspect their browser prompts them to download the file instead of displaying it properly.
One upside I can think of is being able to specify GET parameters in the direct URL to the SWF, which will then be available in the Flash app (via Application.application.parameters in Flex, not sure how you'd access them in Flash CS3). This can of course be achieved by other means as well if you have an HTML wrapper but this way it's less work.
Why would you need 100+ lines of code? Using something like swfobject reduces this amout quite some (and generally you don't want to do plugin detection, etc. by hand anyway).
More advantages:
Light weight look cuz you can get rid of the header with all the tool bars that seem to accumulate there and even the scroll bar is not needed. This enhances the impact when you are trying to show a lot of action in a short flash.
The biggie: you get it in a window that you can drag larger or smaller and make the movie larger and smaller. The player will resize the movie to fill the window you have. This is great for things like group photos where everyone wants to enlarge to find themselves and their friends. I've done this for a one frame Flash production!
Downsides:
As with popups in general, if you are asking for multiple ones from the same site, and you want different size popups, the browsers tend to simply override the size you ask for in window.open and reuse whatever is up. You need to close any open popup so the window.open will do a fresh create. It gets complicated, and I have not been able to get it to work across pages in a website. Anyone who has done this successfully, pls post how!
Adobe should be ashamed of themselves with the standard embed, which defeats the puprose of convention over configuration. Check ^swfobject (as mentioned above) or swfin