Forums

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home › Forums › JavaScript › Requesting some test feedback for Android 4.4 CSS calc() support

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • December 10, 2016 at 10:30 pm #248857
    Shikkediel
    Participant

    According to caniuse.com that version does not support division or multiplication inside CSS calc():

    http://caniuse.com/#feat=calc

    So I’m trying to see if this feature test works correctly:

    var assay = (function() {
  var it = document.createElement('div');
  it.style.width = 'calc(2 * 10px)';
  return !!it.style.length;
})();

    If anyone has a phone with that OS, I’d be much obliged to hear what this pen states about availability:

    codepen.io/anon/pen/ZBjZOx

    Thanks in advance.

    December 11, 2016 at 3:36 am #248858
    Beverleyh
    Participant

    Morning Shikk,

    It says ‘true’ :)

    December 11, 2016 at 11:42 am #248869
    Shikkediel
    Participant

    Thanks, Bev. I suppose it’s not a good test for when calc() is available but limited then, so back to the drawing board…

    December 11, 2016 at 2:43 pm #248877
    Shikkediel
    Participant

    Next phase of this question doesn’t require going to a test page… it’s now become more about semantics. So any opinion on it is welcome.

    I somehow have the idea that feature testing should be as “passive” as possible. So just looking for the presence of a method would have preference over retrieving it as an object. Least favourable would be to have to create an element or actually access the method.

    Unfortunately with unit calculation such as calc() and vh a passive approach is not possible as far as I can tell. One will have to at least manipulate an existing element or create a new one to do a feature test. Like is done with the example in the first post.

    The element there has not been inserted into the DOM yet though so it’s not terribly intrusive. But the trouble is the calculated value will need to be retrieved, not the string value of the style attribute. This works for a non-inserted element with Firefox and IE but not with the browsers that have a Webkit heritage.

    :-(

    So a further step is needed – inserting it… or in that case we might as well target an already existing element. Which (finally) leads to my next question. Is it odd or perfectly valid to use the head for this? It’s not part of the page’s visible content and styling it seems weird. But it looks like it works and the element usually has display: none as a default value which makes it a better candidate than html for example.

    Here with jQuery (just because that’s convenient):

    var assay = (function() {
  $('head').css('width', 'calc(2 * 10px)');
  var mass = $('head').width();
  $('head').removeAttr('style');
  return mass == 20;
})();

    Side note, I wasn’t aware HTML5 doesn’t even require a head section…

    http://www.w3schools.com/tags/tag_head.asp

    In HTML5, the <head> element can be omitted.

    Interested to hear your thoughts about this.

    December 11, 2016 at 9:22 pm #248885
    Shikkediel
    Participant

    I’m wondering what purpose it serves at all that the head tag is stylable…

    codepen.io/anon/pen/xRaEEQ

    But it does look like adding a style attribute is valid:

    W3 specification
    Global content attribute style is supported

    This one won’t make it to the “best snippet list” though, it’s too much of a compromise.

    December 12, 2016 at 7:19 am #248914
    Shikkediel
    Participant

    Still looking forward to any input on that. :-)

    Although I’ve sort of decided I’ll be using the head for feature test on unit calculation (throw some viewport units in the mix for old Android as well). Seems odd but valid.

    Now let me switch back gears to requesting Android feedback. Because I’m very curious about how far forward the issue goes that I’m having with 2.3 and the stock Android browser. Which is that using jQuery plugins and referring to $.fn.myplugin will utterly break the script, not even to be stopped by using a try block.

    I can fix it with some PHP browser sniffing (that’s a must unfortunately because it requires a different script and link) but I’d like to minimise that as much as possible. Not having implemented that fix yet, any feedback based on Android versions going from 3.0 to 4.4 stock browsers (where stock becomes Chrome) on this page would be very welcome:

    http://tamiyaweb.com

    What I’m currently seeing in 2.3 is nothing but the dark background image…

    The only clue I’ve found is that jQuery itself claims support from 4.0 on but without using such a plugin as mentioned (easing.js is one that uses $.extend), everything works fine.

    Thanks again in advance.

    December 12, 2016 at 11:37 pm #248942
    Shikkediel
    Participant

    So it seems that the stock browser and Chrome on Android 4.2 don’t break the page as miserably as 2.3 does but they still cannot seem to cope with using $.extend correctly. They won’t go past the point of any reference to it in the script so instead of only showing a background like on my 2.3 phone, it gets stuck with the loading spinner. The Ghostery browser did manage to load the page normally on the newer phone, they must be using a better API.

    This likely means jQuery’s not really compatible with Android up to 4.4. I can’t believe there’s not more to find on this on the net. There must be a ton of plugins not working correctly with some browsers choices.

    December 13, 2016 at 12:39 am #248943
    Shikkediel
    Participant

    Anyone who could explain to me why that browser is lacking the ability to execute a $.extend.myplugin action, I would personally declare a coding legend. For whatever that is worth.

    December 13, 2016 at 2:52 am #248947
    Shikkediel
    Participant

    No need to go and check on the aforementioned site anymore by the way, I’ve put a fix in place. Some PHP browser sniffing, which I would normally not prefer at all. On the basis of that, the extra bit of script is loaded that would otherwise break things.

    :-/

    <?php
if (isset($_SERVER['HTTP_USER_AGENT'])) {
$blend = [];
preg_match('/Android.*AppleWebKit\/([\d.]+)/', $_SERVER['HTTP_USER_AGENT'], $blend);

if (isset($blend[1]) && intval($blend[1]) < 537) {
echo '<script>window.inept = true</script>'."\n";
}
else {
echo '<script src="myplugin,js"></script>'."\n";
}
}
else {
echo '<script src="myplugin.js"></script>'."\n";
}
?>

    Then I look for 'inept' in window. If it’s there, only delete it. Otherwise use $.getScript to load the few lines that initiate the plugin. This will happen inside the main script that follows the PHP above in the document.

    A lot easier to maintain than having two completely separate scripts…

    The number 537 is a version check for when stock browser became Chrome, with the better JS engine.

  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • The forum ‘JavaScript’ is closed to new topics and replies.