I have a general non-code related question about my website. When I used developer tools to look at html code on website, I saw all of the code. I have used developers tools on other websites and it only shows all of the class names for each section of the website and the CSS. How can I limit how much a user can see of my code when using something like developer tools? It's not that I don't want developers to look at how my website works, but there should be a limit to how much they can see, since it is not copyrighted.
You can use any one of a variety of code minifiers/obfuscators to reduce the visibility of the code. But you can't prevent people from seeing the content, which is why you'll want to keep certain values, such as authentication keys, on your server.
I know there are several tools available to find unused CSS on a static web page. But in most real world scenarios I encounter, a lot of the CSS is used after some or the other interaction on the page, maybe a new modal opening up or an options popup etc.
In such scenarios, what would you suggest? How do I keep a tab on my ever-growing render blocking CSS?
The only way I guess one could do that is by running regular unused-css-detector type tools in conjunction with Selenium - test known interactions and see whats left unused. But a big assumption here is that I'd need to know all interactions on my page which could use new CSS. Is there a way to achieve my goal without making this assumption?
In an ideal world, I'd be able to post-back all CSS used by a visitor's browser on my page to my server. Then I'd collect data over a month, aggregate, and get a pretty accurate idea about actual unused CSS.
Any good ideas?
I am the author of a tool that is aiming at doing what you are describing. Everywhere I worked, the CSS is this "append-only" thing that is too risky, too time-consuming to clean up. And even when you try, the ROI is so low that it not worth it.
So I am working on a tool that is very similar to what you are describing. The goal is to bring confidence on what can be removed, and to actually do it automatically by submitting pull requests.
A snippet of JavaScript is running in the browser and sends reports of what is being used to a server. Once enough data is accumulated to build some "confidence score", it can create Pull Request automatically to remove selectors that are actually not used.
It is still very early stage, but you are welcome to try it and give some feedback about it.
https://www.bleachcss.com/
I have large CSS rules which are mainly based on CSS3 transitions.
When I check the rendering time for a typical page with online tools like webpagetest.org or developer tools like firebug; the rendering time is extremely different in various browsers. For example, MSIE: 1.5s, Chrome:2.5, FireFox:47.0.
How can I debug which part of my CSS has caused unusual problem in FireFox?
Common tools like firebug only shows the total rendering time, and does not show which process (DOM and its CSS rule) is slow and blocking.
How to find the slow process in CSS rendering of FireFox?
No, unfortunately, we don't have anything much better than trial-and-error right now (see here). Chrome's native dev tools currently give us the most complete information about rendering and, from what I've heard, that's one of the most common requests they get.
As far as third party tools, ones that measure this at all are relatively rare. I knew of 2 in the past that I no longer use (http://ejohn.org/blog/browser-paint-events/ and http://www.browserscope.org/reflow/about). Mostly these help you know when repaints or reflows happen and estimate how long they take total.
However, CSS Paint Times and
Profiling CSS for fun and profit mention ways to do profiling by property, but, if you look, neither is probably what you're hoping to see.
Is there a definitive way to measure "time to paint" for performance? and
How to measure browser layout performance
provide related information.
Also see http://jankfree.org/, which has up-to-date information and no links to a tool that automates the current trial-and-error approach.
Here's the catch,I need to take a full screenshot of a webpage via actionscript, I know this is possible on other programming languages (like PHP & CutyCapt), but via actionscript, is there a way to accomplish it?
The full screenshot should be able to take the entire webpage which might include swfs / videos.
Please note, im only interested for available solutions (if any!) for Actionscript, not references to libraries / other programming languages.
No way. You can take screenshot of current swf only.
Nope. This would be a huge security vulnerability. Imagine if some 3rd party Flash ad could randomly just screen capture anything that you are doing on the webpage (login details, personal information, activity etc.).
Anything within the SWF itself is fair game however.
I'd advise you to think about why you need the screenshot and from there try to find another approach that can give you the same effect as a screenshot, since it is impossible to take a screenshot of the whole webpage just from ActionScript.
It seems possible today.
There is a "neat" (sarcasm) Flash advertisement running on Yahoo.com, which captures the current visual state of HTML elements on that page. See the attached screenshot. Items that are pure HTML, and have been interacted with by me just prior to the advertisement capturing an image, are part of that image, which it then applies an effect to. You can tell when the swf captures focus. It isn't performing a server-side operation or even simulating the capture. Looks real to me; however, I'll concede that I haven't looked at the latest player's capabilities or security vulnerabilities in a few months. If someone can explain how that is NOT a capture I'd be intere
I do agree that this is a huge security vulnerability. Can you imagine the possibilities? Many bank sites allow Flash advertisements to run on them. It wouldn't take much more effort to capture account balances and transaction details.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.
One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.
However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.
Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.
With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.