Kindle Experimental Web Browser support
mikespub opened this issue · 8 comments
Originally posted by dunxd August 9, 2023
Being able to navigate COPS and access your library using the Kindle Experimental Web Browser should be an aim of new templates.
Here is a reference that compares which HTML5 features are supported or not: https://html5test.com/compare/browser/kindle/chrome-68.html
https://tests.caniuse.com/ tests different CSS and JavaScript features against the browser used to view the page (and compare that to a list of other browsers). Unfortunately it doesn't have a pre-made Kindle Experimental Web Browser reference, but can be used from a Kindle to see what does and doesn't work.
- Should all templates be compatible with Kindle (and other e-Reader browsers)?
- Should there be some naming convention to signify which templates will work with more limited browsers? e.g. "basic-*" prefix
- Should there be a function in COPS to only allow selection of templates that support a particular class of browser? e.g. only templates starting with a specific prefix
- Should basic browsers be forced to use a specific template? This would allow the use of new features such as semantic HTML5, newer versions of Bootstrap framework etc. without breaking things for people using e-readers.
Given the mess with old Kindle devices, my vote would be no on client-side support for the old Kindle Experimental Web Browser.
Although apparently the browser finally moved out of Experimental phase for newer versions, so there might be hope yet...
https://news.ycombinator.com/item?id=28379718 - its html5 results are not very convincing...
As reported in #62 Kobo browsers may be impacted by the same thing.
I had a look at the different ways of evaluating support for the client side javascript we use, and all the server side ones I found did some kind of parsing of the user agent string, as we currently do. We might want to update this to include more browsers that we know don't support modern javascript (e.g. ES6 and newer).
Note that the scripts in util.js are required by all browsers for the customize page, so this needs to work in ES5 browsers. See #58 for some discussion on working around this sort of issue.
User Agent Switcher extension for Chrome is useful for testing User Agent tests.
User agent strings:
Kindle browser (before 2021 update) - up till at least 5.12.4 firmware.
Mozilla/5.0 (X11; U; Linux armv71 like Android; en-us) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/533.2+ Kindle/3.0+
Kindle Fire tablets - note that Silk browser is used, and doesn't include Kindle in user agent string below is the format, not an actual browser user agent string
Mozilla/5.0 (Linux; Android android-version; product-model Build/product-build) AppleWebKit/webkit-version (KHTML, like Gecko) Silk/browser-version like Chrome/chrome-version Safari/webkit-version
Kobo Touch (see #62)
Mozilla/5.0(Linux; U; Android 2.0; en-us;) AppleWebKit/538.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/538.1 (Kobo Touch 0384/4.38.21908)
The first version of WebKit that supported ES6 was 603.1.1 - this debuted in Safari version 10.
Here is some chatGPT code that can check for WebKit versions earlier than 603.1.1.
$userAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Safari/602.1.50"; // Replace with the actual user agent string
$pattern = "/WebKit\/(\d{3}\.\d+\.\d+)/";
if (preg_match($pattern, $userAgent, $matches)) {
$webkitVersion = $matches[1];
// Compare the WebKit version with 603.1.1
$compareResult = version_compare($webkitVersion, "603.1.1");
if ($compareResult === -1) {
echo "The WebKit version is earlier than 603.1.1.";
} elseif ($compareResult === 0) {
echo "The WebKit version is 603.1.1.";
} else {
echo "The WebKit version is later than 603.1.1.";
}
} else {
echo "No WebKit version found in the user agent string.";
}
COPS doesn't have a lot of client-side specific functionality at the moment. Do you want to go to this level of checks before we decide on server-side vs. client-side?
If you have some specific use cases then I'm OK with that, but otherwise I'm fine with the (revised) user agent check too :-)
No. I wanted to find out how easy it was, and the answer was "not very". Besides, a lower powered device that supports ES6 may come out of the woodwork that will still perform better with server side rendering, in which case we'd probably revert to checking by the model name.
Now I made a Kindle theme for bootstrap2 I'm less inclined to put the time in to make a Kindle/eReader specific template.
Maybe a way to default bootstrap2-Kindle on eReaders is the next thing to look at?
Closing issue as we have no further plans with this