Is there a simple way to detect if the user's browser supports neither Web Components nor the webcomponentsjs polyfill?
Thanks!
No for different reasons:
Web Components is a set a severral distinct features (Custom Elements, Shadow DOM, HTML template, HTML Imports), so some could be supported by one browser version while other not.
Polyfills themselves are using JavaScript "advanced" features that are not necessarily implemented in the broser. For example, ShadyCSS is using Array.from() that is not implemented in Internet Explorer 11 and therefore needs another polyfill to work.
Therefore, depending on what you really need, use an ad-hoc feature detection test, or try / catch test.
Related
This is probably a silly question, however: from a Web Design/Development point of view (I mean support for web standards and web technologies), could Google Chrome and Chromium be considered equivalent?
I know that they are essentially the same browser, the former being the branded version of the latter, but they also have some functional differences, and Google Chrome features some additions not present in the base Chromium browser (detailed on the Chromium page on Wikipedia).
They use the Blink engine, which is in turn also used by other Chromium-based browsers like MS Edge and Opera; and all these browsers have an uneven support for many different web technologies, as detailed on https://caniuse.com.
I'm working on a Linux machine, and my distro ships Chromium by default, providing it from its standard repo; for the sake of simplicity and keeping things clean, I would prefer to avoid adding another external repo and install Chrome just for this task, if I can rely Chromium to behave exactly the same and not have any compatibility issue.
Like I said, this question is probably silly, but given the differences between other Chromium-based browsers, maybe this doubt of mine could be justified.
EDIT: Please note that I'm not interested in the differences between Google Chrome and Chromium from an user point of view or in details of their history and so on; I only wish to know if from a website development point of view, they are fully compatible or if they support the same set of features. In other words, if I test a site from Chromium, can I be sure that it will work also in Google Chrome? Do they support the same exact set of CSS, JS (and other web-related technologies) features?
Chromium is an open-source browser project that forms the basis for the Chrome web browser. It's maintained by the Chromium Project, while Chrome is maintained by Google. Aside from code-opennes, the main difference (for your concerning question) between the two browsers is that Google adds a number of proprietary features to Chrome like automatic updates and support for additional video formats. Also added is AAC, H.264, and MP3 support. Giving you acess to a wider variety of media content, like sites using HTML5 to stream H.264 videos. Both browsers include Opus, Theora, Vorbis, VP8, VP9, and WAV codecs. Chrome also includes a sandboxed Adobe Pepper API (PPAPI) Flash plug-in that updates along with.
From a programmatic side, both support Google DevTools protocol with all of the flexibility and possibilities this brings, like browser automation using the popular puppeteer Node.js runtime, allowing you to run automated tests either in head or headless environments. Both browsers use the Blink rendering engine and the V8 JavaScript engine, so both will give you same support for CSS, HTML and DOM parsing/rendering, and same JavaScript compatibility, functionality and performance. So the real difference is if you're developing media-content centric web apps, in that case you will benefit more from Chrome since it includes all of the above mentioned extra plugins and supported formats, all of this makes the web more accessible to it and provides a wider range of things you could do.
might be very basic question but just wanted to clear out my doubt, since I'm seeing PWA is like alternative for native application.
What if browser fail to read/understand manifest file?
what if user is having other/older browser? (most of the time I see e.g of chrome)
after installation what are the browser dependencies for PWA?
Please guide me with the above.
Thanks
One of the more important concepts in a PWA is that it is built following the principle of progressive enhancement, this means that the website would function ordinarily on older browsers (including Safari) and then gain PWA abilities if the user's browser supports them.
Therefore in answer to your three questions:
Website would function as normal without the option to "Add to HomeScreen"
Same.
The PWA runs using the browser, therefore any functionality supported by the browser will be included in your PWA.
We have a universal React application sitting behind a CDN.
We want to serve up HTML with srcset images from the server, but need to handle the fact that IE will not support this HTML feature, ideally using feature detection.
As the site is served from a CDN, IE will get the same initial HTML as other browsers. When the page loads in the browser, we want to swap out these srcset image tags for some different HTML, but this means React will complain about a mismatch between the client side HTML and the already rendered server side HTML.
What's the best way to handle this?
e.g.
ignore the warning, or specify it's ok somewhere?
use a client side polyfill that happens after the page has loaded e.g. using componentDidMount? In this case, how do we handle subsequent renders of an unchanged component not rewrite this HTML on the client?
use a cache key on the CDN for the user agent - but this would mean sniffing browser rather than using feature detection
The best and most compliant way is to leave both attributes. My guess is that browser will use "src" as a fallback but use "srcset" if available.
No polyfills or strange manipulations needed here :)
For all other browsers that I've tried in both Windows and MacOSX (including Chrome under Windows) using an "iframe shim" works fine. However, I have not been able to get iframe shims to work over our plugin in Chrome on the Mac.
Having Googled the problem, and done some testing, it appears to depend upon the object. I've found an example using StreetView (a flash object) which works, and another example using a Java Applet which does not work.
Some links:
Here's a description of the method: http://www.oratransplant.nl/2007/10/26/using-iframe-shim-to-partly-cover-a-java-applet/
This example using a Java Applet is from the above article: http://www.oratransplant.nl/files/iframe_shim.html
And here's the working version using Streetview: http://gmaps-samples.googlecode.com/svn/trunk/streetview/iframeshim.html
By inspecting (and editing) elements in Chrome and copying the objects between the two example pages, it appears to be that the flash object just allows iframe shims (in Chrome on the Mac), but that the Java Applet does not.
In our case we are using a custom plugin, built with Firebreath.
It may be that I need to implement extra functionality into our plugin, mimicking whatever flash is doing, but this could well be caused by a bug in the Mac build of Chrome.
Can anyone help? We really do want to be able to show HTML elements over our plugin, and the iframe shim works on almost all browser/OS combinations!
The lack of compositing is a known bug in Mac Chrome with any plugin using Core Animation or Invalidating Core Animation. It will be resolved in some future version--in theory, you should never need an iframe hack on the Mac, and plugins should always composite correctly. If you are interested, you can detect whether compositing of Core Animation is supported dynamically in your plugin using NPN_GetValue with the value 74656 (see WKNVSupportsCompositingCoreAnimationPluginsBool in the WebKit source; this should be added to the formal NPAPI spec soon, but the value won't change, so you can hard-code it now and when Chrome supports it that will start returning true).
In general the iframe hack should work in recent versions of Chrome (what version are you testing?), but there are some bugs where it doesn't get noticed until the page gets a re-layout, so you might want to play with forcing that.
Note that your Streetview example isn't a valid test on Mac Chrome, because it's using wmode=opaque, which means it's using the CG mode, not CA mode, and thus compositing works completely regardless of the iframe hack.
What drawing method are you using? You shouldn't need to use an iframe over a plugin on Mac because all drawing is windowless, unless you're doing strange things that I wouldn't expect to be possible with Chrome (i.e. creating an opengl context over a coregraphics or quickdraw context). If you were doing something like that there would probably not be anything you could do.
One easy setting would be to just resize the plugin to 1x1 to effectively "hide" it.
Web browser plug-ins such as Flash already provide VoIP functionality in a web browser, but is it possible to have browser VoIP without any plug-ins?
Ericsson Labs has posted information using the device element to allow for microphone input. This, in addition with WebSockets could be used to implement VoIP. However, the device element is not implemented in any web browser yet.
No there isn't but the device element will likely be the way in the future, as you mentioned. I don't think it will take too long for browsers to look into it however. There are also the WAC APIs, but they are only on mobile, and not shipping quite yet.
Update: There is now a standard in development called WebRTC. Drafts of this spec are supported by Chrome and Firefox. Microsoft have made an alternative proposal called CU-RTC-Web