Basically my question is as exactly as the title suggest.
I want to override the css styling of Shopify's embedded buy button iframe, but I am not sure how.
I as assuming this will be extremely tricky, if not impossible? As I have tried many things and it seems that all of my css affecting the Shopify's embedded button is ignored.
I have tried adding !important to styling and this doesn't seem to do anything either.
Is there a way to add styling after the iframe has loaded in browser? I am guessing that this is the last thing that loads, hence why my css is being ignored/overwritten.
Any help would be great.
PS. I do not have a website link to provide as it is for a client and a signed NDA has legally prevented me from uploading the site, even in a test environment.
Thanks,
Currently, the only supported customizations are the ones listed here. There's no way to override styles within an iframe on another domain. However, we've built the JS Buy SDK to support greater customization, though it would require more intensive development. That said, there are some examples you could use to get started.
I am styling a project built on Meteor and using LESS. I use Brackets for styling because its Live Preview feature makes working with CSS a lot quicker and more pleasurable, but by Meteor's nature it doesn't seem possible to use this feature.
Every little change I make on the code has to be detected by Meteor, who will in turn refresh the project on the browser for me, and this process is now taking anything between 5 and 10 seconds, which is entirely too much.
Does anyone know if it's possible to work on "live" CSS/LESS, using Brackets, in a Meteor project, without having to wait for Meteor to notice my changes and take its sweet time to refresh the whole thing for me?
Or at the very least least if there's anything I can do to shorten the time Meteor takes to update?
I don't think it is possible unless the developers of Brackets go an extra mile and implement a specific support tailored for Meteor.
Brackets works on top of raw CSS and HTML files and uses Chrome Dev Tools API to manipulate the page.
Meteor doesn't send raw files to the client. HTML templates in Meteor get compiled to JS DSL and CSS is concatenated and sent in a manipulated form, too.
Bracket's live preview feature would work only with quick page layout prototyping and will not play well with any modern front-end tool chain that involves compiling pages and stylesheets or preprocessing.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For me iframes are pure evil (well, maybe not so pure). They seems to make a lot of troubles. Yes, your whole site will load once and then you can just load single pages. But people invented AJAX for this purpose.
One of the biggest issues I found with iframe was that I couldn't paste a link to one of the subpages, because the URL never changed (yes, I know there is a workaround for this). Second thing, web search engines may have problems indexing such pages.
Sometimes the accessibility of this sites are worse and some browser can even display them improperly.
There are better ways to design layouts without iframes. Everyday I can see some one asking at SO questions, like "How to access iframe with jQuery?".
So what are the benefits of iframes? What reason can it be to still use them? I just would like to know why.
I can think of 2 reasons (at the moment) why people would still use iframes instead of AJAX:
1) Iframes circumvent the cross domain origin policy (images, scripts, and styles do not). This can be useful for pulling in sites / content from other domain names relatively safely. Basically, this allows the advantage of being able to visually show data from other domains without letting them stomp all over your page with unlimited access (like something like JSONP would be able to do).
2) You can load multiple types of resources from within an iframe, not just certain mime-types (you're relatively limited to application/javascript, application/x-javascript, text/css, text/xml, image/png, image/jpeg, image/gif with scripts, XHR, images, and sources). For instance, if I want to show you a PDF, I can open an iframe and let the Adobe Reader plugin show you that file. Additionally, in the same domain, if I want to pipeline a script, style, and image all together (inline on the page, image would have to be data URI), I can accomplish this with an iframe (and if it's in the same domain, port, and protocol I can access it with JavaScript as well).
Did you know that Gmail is a set of iframes? The visible part is just clever positioning. Additionally, many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in).
IFRAMEs are used to embed and isolate third-party content into a website.
Most of web advertising solutions are based on iframes - because they give security (cross-domain policy) and isolated rectangle on screen which can be fully managed by third party content and scripting (a common use case is advertisments).
Another modern use of IFRAMES is a management of history (common back button workaround) of AJAX applications.
FRAMEs are poor version of IFRAMES. Their use is declining.
If a user has javascript disabled, iframes will work when ajax doesn't. This is not out of the question, considering that people use things like NoScript.
I use them on ajax websites, when I need to upload files without reloading the page.
I still see iframes being used in large corporations where they provide a single sign on which injects header information about the authenticated user which is then passed, via an iframe, towards the actual application(s). Since the "portal" surrounding the iframe handles all the specific authentication details those applications behind it don't need to have each an implementation for it, making things easier to make for the development team and having a single place to monitor and adjust authentication details of users.
There are plenty of technical reasons to use them (especially the security issue mentioned by Dan Beam).
What you shouldn't do is use iframes “like frames”, doing navigation to new pages by updating the iframe only. As you say, this prevents the navigation from being bookmarkable/linkable, responding to the normal navigation buttons, and providing useful link affordances like open-in-new-tab.
But that's not peculiar to iframes. You can see more and more pages where the navigation is done by fetching new content with XMLHttpRequest and writing it to the main content div's innerHTML. Often this is done with jQuery load() and clever-clever slidey animations. This breaks navigation just as badly as iframe-used-as-frame, or indeed old-school framesets. It's a shame so many web authors are using this tactic believing it to be a super-modern web design methodology, when really it's just a new skin on yesterday's despised framesets.
You can work around it in both cases, but it means you have to store a viewstate in the # fragment identifier part and support proper hash-navigation, which isn't trivial. Even then you've still got problems with non-JS agents like search engines; you end up having to have a parallel ?-based and #-based navigation to support both. It's a pain and most don't bother.
Framesets are outdated as of HTML 5, and sometimes you need to have a frame with another site within a site.
Also AJAX can only do so much. Try uploading a file to a site on another domain through https without an iframe. AJAX won't help you there.
In addition to others reasons, I have one specific usage of iframe in my application. Unfortunately, the target browser in my case is Internet Explorer 6. I need to have a footer and a header that are fixed in my web pages. The main part of this page is scrollable.
However, there is a bug in IE6 where I cannot display a div element on top of select elements using the z-index CSS property. Thus, I need to create an iframe that will be used as a hack to avoid this problem.
Of course, this is a really specific usage of iframe and only concern IE6...
Javascript WYSIWYG Editors use iframes, because that is easiest and best way to make it. For example TinyMCE uses it:
http://tinymce.moxiecode.com/
I was building a social network and i see iframes being useful for widgets to put on other peoples website to show like a mini profile or integrate with the content on a remote server. Seems like the most simple way to build this. I know some widgets use JavaScript. Also with the iframe method the session is the same as visiting the site like normal, so great for like buttons.
Many Formatted Text Editors (e.g. TinyMCE, HTMLArea) are implemented as iframe.
iFrames are okay for some cases, as X-domain-requests, or posting data to a source via parameters. But when I want to access data across domains, I prefer using CSS-files - they can accept params, set cookies, add content to the page (:before & :after) and give a visual feedback.
just wondering is there any free tool which can aid in making the GUI/interface layout of asp.net/html forms ? My forms mostly end up in being less user friendly and not good looking at all.
I have been using Bootstrap framework to get my design up to speed in no time. You can use this tool to get forms created in minutes. http://bootsnipp.com/forms?version=3
Why don't you try downloading the Firefox Web Developer Toolbar and use it to reverse-engineer some simple, good looking sites that you come across?
https://addons.mozilla.org/en-US/firefox/addon/61772/
You can use it to grab the entire CSS of any site, or hover over areas of a page and see the various divs and their associated CSS rules highlighted.
We have customers that create small intranet applications on servers we provide them. The servers also house various (windows/.net based) systems we have created.
We need to provide our customers a "one-liner" piece of code that will allow them to embed functionality into their web pages. Similar to how Google Ads works when they are embedded into a site. A slight difference is that ours will need to refresh every 5 seconds or so. We will create several of these "widgets" for them to place in their pages.
All our developement is in .Net so I would prefer options in regard, but I'm open to anything.
Early research points to IFrame, possibly with Ajax, or JavaScript, JQuery, and a webservice, or using IHttpHandler that returns HTML via "Document.Write" (like this).
Recommendations?
Simply put, Iframes are easy because they eliminate any possible conflict with the client's web site. That's vitally important, unless you also manage the client's web site so you control the environment into which you are inserting your widget.
Otherwise, situations where you're embedding your widget code directly into the client's web site (not using an Iframe) is likely to cause a conflict with the client's HTML, CSS or Javascript. You can write your widget code so it doesn't conflict, but you generally can't depend on their web page code. All it takes is something poorly written on your client's site to cause problems with your embedded widget. CSS is the easy example.. Say your client had something silly in their stylesheet like:
div { background-color: red; }
...unless you've specified the background property using a more specific selector for all div's used in your widget, now they're red.
I think the best way to do widgets is give your clients a single external script reference that passes a client ID in the script URL. Your script starts by document.write()-ing the Iframe - that way you have future control over every aspect of your widget (including the iframe) with no changes ever necessarily on the part of your clients.