> To view this site, you must use Chrome, Opera or other Chromium-based browser.
Well frankly F off
Well frankly F off
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.
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."
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.
I'm sorry for the missing documentation on Github, I will write a proper project description with some examples later next week.
Suffice, yes. And yet they are clearly inferior to actually using the widget as it would be used, so why sacrifice that? In the name of possible users that refuse to use Chrome?
I think the number of people that are actually interested in this that do not have a version of Chrome handy already install that they can use and are unwilling to install it to see the functionality of a tool that relies on the functionality of a core component of Chrome is very small. So small, in fact I would be interested to hear from someone that was actually put off from viewing this that was actually in the market to make an Electron app.
If I hadn't seen this comment thread, I would've went about my business to never give Xel a shot, because I'm on a low-end machine currently that takes forever to boot up Chrome, or any modern browser for that matter.
Though, I'm also a proponent of writing accessible sites/apps that don't break when javascript's disabled, so this sort of "you need x to view y" grinds my gears.
TL;DR: I'm definitely in the minority but it'd still be nice to have screenies
Sidenote: To those who use angular/react/vue: add a prerender to your buildscript to fallback to a static site for js-disabled folk. It can even wait for database calls, so dynamic content can still be shown. I personally use this one for Vue: https://www.npmjs.com/package/prerender-spa-plugin
> I'm definitely in the minority but it'd still be nice to have screenies
Which is fine, and I'm not arguing it's better to not have them, just that when it comes to the set of cases where it's okay to require a specific browser version, this pretty much fits the bill for me. Anything else is more work than using the actual widgets in examples, so that's what appears to have been done (and (one of?) the authors is on record here as saying they are planning to a add more later).
I just think "Well frankly F off" is a bit extreme given the actual specifics of the situation. People have a tendency to shift outrage from one item to another using false equivalencies (a website targeting general users doing this would be a different story), and I think that's worth calling out when I notice it.
In the longer run I'm planning to replace HTML Imports with ES.next modules, so it's temporary dependency.
Blocking other browsers is a bit extreme, but would reduce the pointless bug reports and bad publicity.