4 ms·
> To view this site, you must use Chrome, Opera or other Chromium-based browser. Well frankly F off
by scandox 10y ago
> To view this site, you must use Chrome, Opera or other Chromium-based browser.
Well frankly F off
- detaro 10y agoAnd to add insult to injury, it hijacks the back button on that page...
- jarek-foksa 10y agoWhat web browser are you using? I'm unable to reproduce this bug on Safari.
- hdhzy 10y agoFirefox for Android. Main site redirects to /fallback. Thrn you press back then it goes to the home page and... Redirects to /fallback. :(
- detaro 10y agoDesktop Firefox, Linux and Windows
- jarek-foksa 10y agoThanks for feedback. This issue should be resolved now (I had to use window.location.replace() instead of window.location.pathname).
- detaro 10y agoworks now, thank you!
- pbowyer 10y agoGiven this is the engine inside Electron, it's understandable if they only work in this rendering engine. Blocking other browsers is a bit extreme, but would reduce the pointless bug reports and bad publicity.
- kbenson 10y agoActually, given the subject, that's an entirely acceptable requirement. If all the components are only meant to function inside a blink based engine, then making versions that might function without chrome specific extensions just for the demo site is silly and a waste of resources. It's simple enough to install chrome just to view this if you didn't have it installed already, and if you are interested in deploying an electron app, you probably already do. Requiring a chrome based browser to view is the equivalent of requiring your browser support java applets when viewing a site showing off a toolkit for java applets (assuming it's a decade in the past). The simplest way to show the actual usage it to actually use them, and the best way to make that function correctly is to deploy examples that actually use the engine.
- detaro 10y agoI'd argue presenting the documentation for your java toolkit as a java applet would be bad form. Not getting the full demo without a matching browser (although I'd ask the question if there isn't a polyfill for the webcomponent APIs), but there is no reason why a basic info page with at least a screenshot doesn't work everywhere, and would already be a lot friendlier. There is the "fork on github" banner, but the readme just sends you back: "Visit xel-toolkit.org for demos, documentation and code samples."
- kbenson 10y ago> I'd argue presenting the documentation for your java toolkit as a java applet would be bad form. The equivalent would be if Java had a documentation viewer application which was built in Java and was the standard way to view the documentation. At that point, saying and enforcing "You need to read our documentation using the standard documentation program but utilizing this special Java version which is what you would be deploying the toolkit in, because that's the only way the examples will work right." matches the current situation.
- jarek-foksa 10y agoUnfortunately it is not technically possible to polyfill all Web Components APIs. Shadow DOM is especially hard to polyfill in any sensible way (Google did try it, but failed to deliver a solution that would cover all use cases). I'm sorry for the missing documentation on Github, I will write a proper project description with some examples later next week.
- jarek-foksa 10y agoI'm planning to implement a proper fallback site for other browsers with documentation and screenshots later. It's not my top priority right now because the project is still in alpha stage.