The "postMessage" is an HTML5 API, it is available in all major browsers including IE8/9. What I am trying to do is to create a popup window from a page, and be able to talk to the popup window using "postMessage". This works in every browser except IE8/9. Disappointed!
It looks like IE8/9 only allows the communication between iframes, but not between two windows, even the windows are within the same hierarchy.
I found that .postMessage() in IE9 was unreliable unless I used Strings.
My workaround was to simply call .postMessage(JSON.stringify({object: 'data'})) and use JSON.parse() in the onMessage() function on the other end.
The .postMessage method works, you just need to understand how it works from IE8 and up. Unfortunately, for IE8 and IE9 it will not do what you're seeking (though it does in IE10). While you can send messages between frames in IE8/9, you cannot send messages to a separate window.
There is a work-around that works in some instances. Martin Beeby discusses it in the last paragraph of his blog post on the issue: PostMessage Popups and IE.
For more on this, and a few other caveats, see Eric Lawrence's post on MSDN.
Related
TL;DR
How/why are some browsers able to search and highlight text in the HTML body which is followed by #:~:text= in the URL?
Explanation
One day I was searching for something on Google, which lead me to Quora's result. I observed that 2 sentences were highlighted in yellow, which were part of URL after the aforementioned parameter. I thought this would be Quora's feature for SEO or something, however, also found this on Linkedin, and Medium, and so on.
I'd like to know:
What is this highlighting called? Why/how does it work?
This seems to be browser-specific. What kind of browsers support this?
It seems to work on Chrome and Edge; but not on Firefox, Safari, and IE.
Does a frontend programmer need to incorporate something in the code to have search engines highlight content on their web-pages? (Based on the assumption that search engines actually appends the relevant string predicted by user's query)
The highlighting is called Text Fragments. Its a new feature that was recently added to Chrome 80. It works by specifying a text snippet in the URL hash.
Yes it is browser specific.
No, the experience that you get when clicking on a link from Google's search results is part of Featured Snippets which are algorithmically determined. There is nothing you can incorporate into your code to prompt search engines to highlight text on your page.
There is no markup needed by webmasters. This happens automatically,
using Scroll To Text for HTML pages
https://chromestatus.com/feature/4733392803332096. See also more
background here: https://support.google.com/webmasters/answer/6229325
Sources:
https://web.dev/text-fragments/
https://www.theverge.com/2020/6/4/21280115/google-search-engine-yellow-highlight-featured-snippet-anchor-text
https://www.theverge.com/2020/6/18/21295300/google-link-to-text-fragment-chrome-extension-chromium-highlight-scroll-down
https://searchengineland.com/google-launches-featured-snippet-to-web-page-content-highlight-feature-335511
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html
While text fragments is natively implemented only in latest Google Chrome (and the latest versions of Chromium-based browsers, such as the new Microsoft Edge), there is a browser extension/add-on that seems to enable it on Firefox and Safari: https://github.com/GoogleChromeLabs/link-to-text-fragment
It appears to use #ref-for-fragment-directive:~:text= and additional arguments (instead of just simple #:~:text=).
Firefox: https://addons.mozilla.org/firefox/addon/link-to-text-fragment/
Safari: https://apps.apple.com/app/link-to-text-fragment/id1532224396
Curiously enough, the extension has also been made available for Chrome and Edge too (!).
.
UPDATE: I'm testing it on Firefox Developer Edition, and it doesn't work for me.
I was having issues because of Chrome automatically referencing DIV... It works that way in Safari (desktop and mobile), but not in Firefox.
See image:
See Fiddle (open in Chrome, then in Firefox):
http://jsfiddle.net/stefek99/Sqcff/
The question is - how to disable this feature? I would really like to develop in "strict" mode without any Google quirks, just to make sure my code is cross-browser compliant.
This is a known 'problem', however I have not been able to find a reliable method of disabling this. One might think that "use strict"; should probably disable it but that doesn't seem to be the case.
In any case, some more explanation on it; Do DOM tree elements with ids become global variables? As explained there it will probably be standardized in HTML5. It all started out as a non-standard IE feature, which ofcourse got mimicked in other browsers. Theres even a msdn blog post noting it as a 'problem' so it seems a bit silly the HTML5 working group is trying to standardize it now.
I would like to note to anybody to please not rely on this problem feature as it is very ambiguous and hard to debug for programmers who don't know of it.
I am developing the follow website:
http://di20studios.com/2012/royalpack/
All works fine in Mozilla Firefox and IE 8, but Safari, Opera and Google Chrome don't like my display:table-*CSS...
The display:table-* is at header and bottom.
What I want? Continuous background:
Can you enter the website and see this issue in action? How I can solve this?
Check this out, I believe you will find your problem is similar.
This is an unconfirmed webkit bug. My only suggestion would be to make sure you are using an HTML5 doctype:
<!DOCTYPE html>
From John Resig:
What’s nice about this new DOCTYPE, especially, is that all current browsers (IE, FF, Opera, Safari) will look at it and switch the content into standards mode – even though they don’t implement HTML5. This means that you could start writing your web pages using HTML5 today and have them last for a very, very, long time.
Also, I might suggest you NOT use this method (display:table-*) unless it is the ONLY solution (which is never :P). There are many known issues with this method, one being that it is not supported in IE7.
A plausible solution would be to use floating to achieve this. You will need to change the transparency over the images for the repeat-x to overlay properly. I edited the images so you can see a working example. As long as you MAKE sure to clear after the header-container, you shouldn't run into any issues using float. PS, this works in IE7+ :]
Can you enter the website and see this issue in action?
If the question is as above, then my answer is: Yes, yes I can. I am using Google Chrome 18.0.1025.162 on Linux.
What would be the process for ensuring that the code works as expected across multiple browsers. What would be the best answer?
Be XHTML compliant (w3.org validator)
Be CSS compliant (w3.org validator)
Use a JavaScript library that is cross-browser compatible (less direct call to JavaScript as possible)
Test, test, test during development. Not at the end!
Avoid bleeding edge code.
Yeah, I know, many of you will hate that answer. And if you've never worked in a large enterprise environment, you'll think I'm a Luddite. However, I can't tell you how many times the requirements I've been given have specifically listed "No HTML5" or "No CSS3" elements simply because the client was paranoid about IE6 working exactly as the others did.
The obvious overall answer is testing, but I'd go one step further. If you're worried about 100% operation in all browsers, you have to define your standards. For example, if you have to code back to IE6, do you have to worry about mimicking rounded corners, which is always a hack on IE6 and below? Or, will the client accept progressive enhancement such as square corners for those on browers from the dark ages and rounded for the rest of us? Does the client specify fonts that can't be told apart when pulling the page up side-by-side, or do they understand that browsers use different font rendering engines? Is it ok to work just in IE6, or do you have to also support quirks mode? What about rendering with a screen reader (accessibility) or without CSS or Javascript. How about mobile devices? All these were valid and measurable issues with my last major corporate client.
I like Adobe's Browser Labs as my first line of defense for testing. However, it's just one of many steps I take including multiple physical computers on multiple OS's connecting via multiple connections through different network proxies. You just can't test enough....and even then expect to find an error as the site is launched and matures.
Take each browser and test :D
You can use websites like browsershots.org to see how it looks on different browsers and platforms.
The most comprehensive way of doing that is to actually test in different browsers. A simple solution would be to create a virtual machine hosting server, set up multiple VMs, and then install a different browser version to different VMs to fully test your application.
Absent that, there are tools that can emulate (but not fully) browsers and you can test through those.
The best measures to adopt are:
Use a CSS Reset (read about it at the link, implement it however you like)
Use a Javascript Framework like jQuery (This will abstract a lot of cross browser quirks)
Validate your HTML and CSS. Make sure you are specifying a Doctype
You can test most browsers via Chrome, Firefox and IE8. IE8 has an IE7 mode that can be used to test for IE7. Press F12 in IE8 to get the developer window to debug and solve issues. Make sure you are prompting for all JS errors. IE6 is a tough one, but there are a number of resources available that you can probably find to help you with this.
Hope this helps. Good luck.
http://browsershots.org/
thats the site you looking for. You need to put in the url of your website, select the browsers that you want to check and click submit. It will return screenshots of the your website based on the browsers that you have selected.
There is no one way to test the app's compatibility for web browsers. First thing to keep in mind is understand the standards set for the app, define the number of browsers and versions to support. Once we know what we need to support we can keep the following points to ensure compatibility:
Test during development. Not at the end.
Avoid bleeding edge code. New functions that come with ES5 or ES6 standards would only be supported by modern browsers, hence would need polyfills in older browsers. Therefore use the most native form of Javascript wherever possible.
Use jQuery functions if it's included in the project. It helps take care of most javascript cross browser issues. If not included, use just bring its particular function in your project that you might need.
For CSS, try to use the traditional methods of layout and styling instead of the latest CSS3 one's which might not be supported by old browsers(like transform property).
Tools like Browserstack can be used to see the screenshots of how the CSS turned out on different machines.
Actually test on different machines and browsers. Although chrome provides a superb emulator but when code actually runs on that particular OS and ecosystem, then it may misbehave. So the best way to ensure is actually test them in every ecosystem.
Use Tools like VirtualBox to be able to test old browsers and different OS.
There is no way to ensure it aside from testing testing testing :-)
What, if any, considerations (HTML, CSS, JavaScript) should you take when designing for Google Chrome?
Chrome uses Webkit, the same engine as is used by Safari, OmniWeb, iCab and more. Just code everything based on the standards and verify in each browser.
I think first and foremost you should focus on using HTML and scripting that follows the standards.
After you have that running, file a bug report then make the browser-specific tweaks. If Chrome is worth a flip you shouldn't have to tweak things for it.
The same ones you'd take for Safari, as they share the same rendering engine (with a slight version mismatch).
I'm sure filing a bug report really helps with all those IE rendering issues!
Realistically, you need to test your application in each browser, no browser 100% follows the W3C standards so ultimately you can't rely on following that at all. You need to test everything you do in any browser you wish to support.
As has been mentioned, Google Chrome has the same rendering engine as Safari/iPhone/etc., WebKit which passes Acid3, so there should be minimal issues if you follow the standards. But don't rely on it. Google Chrome currently uses a slightly older version of WebKit than Safari. I'm sure they'll eventually be on the same version at some point, but unfortunately any new browser becomes just another browser to test in.
Are you designing specifically for Chrome, or do you want to make sure your pages work well with Chrome?
Assuming it's the latter, then just use the same design considerations you'd do for any browser. If applicable, keep in mind that many phones and video game consoles have web browsers now.
Chrome uses a new JavaScript engine, so you'll have to test your JavaScript using Chrome as well as Safari. The HTML and CSS may render pretty much the same, but they use different JavaScript engines.