Most references as below mention that Safari partially supports web components.
In detail, what web component features are not supported by Safari desktop and Safari iOS?
Is there a technical docs or specs about the issue?
https://developer.mozilla.org/en-US/docs/Web/Web_Components
https://caniuse.com/shadowdomv1
Burn all old blogs!
Apple Safari supports Web Components, apart from Customized Built-In Elements.
After an ongoing debate since 2013, nearly everyone agrees Apple engineers are right on this one.
Not yet supported by Apple (Google proposals, implemented in Chromium):
Constructable StyleSheets : https://web.dev/constructable-stylesheets/
declarative shadowDOM : https://web.dev/declarative-shadow-dom/
Will never be implemented by Apple:
Customized Built-In Elements
extend from any existing HTML Element: <p>, <input>, etc..
If you want to understand the Apple Why,
read back in time to 2013 - Yes! Web Components are not a new fad!
Autonomous Elements (extend from HTMLElement)
work 100% in all Modern Browsers
At this time of writing, see: https://custom-elements-everywhere.com/
Angular is 100% compatible
Svelte is 100% compatible
Solid.js is 100% compatible
Vue is 91% compatible (Vue doesn't listen to Capitalized Eventnames)
React is 29% incompatible
StackOverflow Deep dive into Web Components, React & Lit like BaseClasses:
Main differences between lit-element & React
Javascript regexp variable length lookbehind is not supported by Safari but works in Chrome, Edge and Firefox. Maybe international agreements/standards say Safari doesn't need to support it (yet) but it's a pain nonetheless.
The forum post (see below) on the Apple Developer website has both requests to support customized built-in elements and formAssociated custom elements.
https://developer.apple.com/forums/thread/682165
It could be used to follow up onto when Apple will release support for those features on Safari.
Related
We are told to use progressive enhancement when building websites that will use modern features if available but still work if not.
However, I find it hard to test the fallback cases. Of course there should be some tests with some older browsers, but it is hard to target non-support of specific features. It is also nicer to use recent developer tools that are not available in legacy browsers.
Example: I use a flexbox layout with a float-based fallback. I would like to debug the fallback in chrome, but flexbox is already available there. I could also use IE 8 which does not support flexbox, but it also does not support many other features and the developer tools are not as nice to work with.
Is there something like "reverse polyfills" that remove support instead of adding it? What other solutions are available?
I'm writing a Safari NPAPI plugin using CoreAnimationDrawingModel. This lets me create high performance CAOpenGLLayer and return it to the browser (I'm using this: https://wiki.mozilla.org/NPAPI:CoreAnimationDrawingModel).
Unfortunately, I'm having trouble supporting Retina displays in this setup because I cannot find a way of working out whether or not the plugin is hosted on a Retina display. Without this information I cannot set the CALayer's contentScale property properly.
In native applications I'd host the CALayer in an NSView and watch viewDidChangeBackingProperties to obtain the required resolution information. I'm not sure whether there is a way of obtaining the layer host in the NPAPI world? Even if that was possible, I'd be annoying to have to poll it for the resolution, ideally I'd want to register some kind of a notification listener.
I'm writing my plugin using FireBreath (http://www.firebreath.org/) and talked with the devs there (Richard Bateman) on IRC, but they suggested asking here (Stuart Morgan was mentioned as a good person to ask).
There's a spec for passing this information to NPAPI plugins. I'm not completely sure of the implementation status; Chrome doesn't implement it, casual inspection of Firefox source suggests it does, and since it was authored by an Apple engineer it's likely that Safari does.
As I am converting my flash based virtual lab to HTML5 using EaseLJS, I thought its a good idea to ask if some one knows any browser support issues or restrictions? lots of new and old browsers out there ..
I wonder how easeljs handle such diversity, is there a known-compatibility-issues of easeljs APIs ?
A matrix would be perfect! well ?
Canvas is a pretty well-supported and consistent HTML5 feature - and there are very few inconsistencies between the major browsers. There are some touch issues on some of the mobile platforms that we are working to address - mainly Android.
Cheers.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
I've been thinking to give GUI development a try lately and am torn with the choice of between wxPython and Mono.
Judging from what I've seen out there, wxPython people seem to use the WebKit trick to produce nice (doesn't have to be beautiful) UI.
How hard is it to do the following in each of the platform:
1) Custom Control
2) Use HTML rendering
I don't quite understand how far the HTML rendering works via WebKit in wxPython (i.e.: does it support separate CSS/JS files? how's the JS support? do we need to write extra wxPython code to run the JS? how hard it is to integrate between JS events and wxPython widgets? what are the usual strategy of integrating WebKit with wxPython?)
Mind to share your thought on this subject? I specifically pick either wxPython or Mono, not Java Swing for no reason.
PS: I'm aware of certain limitation of cross-platform UI (as in: it won't be 100% native) and I could care less of such things.
wxPython has wxWebkit available via the new WebView widget, but WebKit is only available on Mac and Linux right now. WebView uses a different rendering engine on Windows called Trident from IE (see http://wxpython.org/CHANGES.html). So you'll want to keep that in mind.
Either way, we're talking about browser engines that display HTML, CSS, etc. They should, theoretically, display whatever those engines support. You'll have to look up their specifications to be sure and also make sure to check if the port supports everything. As I understand it, they should definitely support the usual HTML and CSS and I would assume normal javascript. If I were you, I'd just create a simple window in wxPython and then load the web page you've created and see how it works.
I don't know how the javascript communicates with wxPython or if it even does. You'll want to ask on their mailing list for that kind of information.