Apple going to kneecap the web: PWAs

posted by Kravimir at 2:55 AM on Feb. 29th, 2024

Categories: Browsers, Chromium & Webkit, Miscellaneous, Usability & UX 0 comments

Remember the days that Apple used to pitch itself as David in the David and Goliath stories? Well, the tables have turned. Apple, in a short number of days, are going to intentionally kill off PWA support.

This affects developers, businesses and users.

When any documentation eventually emerged, Apple not only intentionally confused readers as to the reasoning, but also lied, and not just a little lie, just outright lie.

Alex Russell has an excellent long form piece that explains the reality of what's going on. Take 20 minutes of your day and read it.

Do two things

There's two things you can do to help to attempt to fight back against Goliath Apple:

  1. Sign the open letter to Tim Cook
  2. Blog (feel free to copy this post if you want), toot, bookface, linkitin, tweet (or ecks…?) - it doesn't have to be long, but it has to be now.

Safari has long held users back. If Apple succeed here, they'll have delivered a heavy blow to the open web (and frankly, some decent choices for your phones).

Don't just read this: fight back

Reposted with permission from remysharp.com

Using SVG images with Maximum Cross-Browser Compatibility

posted by Kravimir at 10:36 PM on Oct. 29th, 2013

Categories: HTML, Intermediate, Web Images 0 comments

This technique is complex, using an object element and IE's "conditional comments" in addition to at least one img element, but it avoids using JavaScript for something that's not behavioral. The conditional comments are used because IE, or at least older versions of Internet Explorer, don't correctly handle the fallback procedure for object elements, so since we know which versions don't support SVG, we simply hide the object element from them. Fortunately IE9 supports SVG, so we're well clear of the issue that conditional comments are not available in IE10 and newer.

Here's the version I've been using:

Code:
<!--[if (!IE)|(gt IE 8)]><!--><object data="images/logo.svg" type="image/svg+xml">
	<img src="images/logo.png" alt="">
</object><!--<![endif]-->
<!--[if lt IE 9]><img src="images/logo.png" alt=""><![endif]-->

Here's the shorter version which may be more confusing to those who aren't familiar with the more advanced uses of conditional comments:

Code:
<!--[if (!IE)|(gt IE 8)]><!--><object data="images/logo.svg" type="image/svg+xml"><!--<![endif]-->
	<img src="images/logo.png" alt="">
<!--[if (!IE)|(gt IE 8)]><!--></object><!--<![endif]-->

Now you might expect that to be it. However, in many browsers clicking on an object element that is nested within a link does not activate the link. The solution is to absolutely position another element (or pseudo-element) within the link over the top of the object element. Since object elements don't have alternate text the same way img elements do, I've been using an img element as the absolutely positioned element.

Code:
<a href="#" id="logo">
	<img src="images/clear.gif" class="link" alt="alternative text for the SVG/PNG here">
	<!--[if (!IE)|(gt IE 8)]><!-->
	<object data="images/logo.svg" type="image/svg+xml"><img src="images/logo.png" alt=""></object>
	<!--<![endif]-->
	<!--[if lt IE 9]><img src="images/logo.png" alt=""><![endif]-->
</a> <!-- /#logo -->

For using SVG as a background image in CSS with a PNG fallback, check these articles out:

Pro tip: Calculating CSS Backround-Position

posted by Kravimir at 11:00 PM on Sep. 16th, 2013

Categories: CSS, Web Images 0 comments

Calculating percentage values for background-position is very tricky. However, once you know that it's a simple calculation, it is no longer completely beyond comprehension. You subtract the width (or height) of the element's background area from the respective dimension from the background-image and then dividing that by the position of the image within the sprite. If you're using background-size, then you need to make sure all 3 numbers are in the same scale. So for example, I have a sprite that is 72x726 and elements that are 72x67 and 49x45. To get the position of the image what is at 329px from the sprite's top edge, you calculate 329/(726-67), which results in "49.92%". Due to rounding you may want to adjust the percentage slightly.

New Usability Issue in Firefox 4 When overflow:auto is Used

posted by Kravimir at 7:48 PM on Apr. 29th, 2011

Categories: CSS, Browsers, Mozilla, Usability & UX 1 comments

A member of my family recently was buying something online and was making the payment via PayPal's form for non-PayPal members to pay through a credit card. When she tried to tab from one field to the next a border (outline) appeared around the next label and field instead of the field receiving focus. This is definitely an unwanted change from normal tabbing behavior. So when I got back to my own machine, which has the necessary developer tools, I first went to the page in Firefox 3.6 where I did not see the problem. Next I navigated to the page in Firefox 4 where lo and behold the issue occurs.

It turns out that the issue is triggered by the wrapper paragraph element having "overflow:auto" set, even though no scrollbar was generated. So I recommend that you use "overflow:hidden" instead or, better, use an alternative (that doesn't require adding any extra elements to the markup), or even better: use inline-blocks instead of floated elements. Keep in mind that this could also be an issue in navigational menus for people who choose to navigate through pages with the keyboard alone.

Before this change in Firefox, we needed to give a normal element, e.g. a <div> (not a link or form control), (that didn't have a scrollbar) tabindex="0" in order to make it able to receive focus via tabbing (and still do for other browsers).

I'm not sure whether this is a good change for usability or not. However, we do have an issue that needs to be addressed by being more thoughtful about using "overflow:auto" in our stylesheets. I'd love to hear your thoughts and if anyone knows why the Mozilla developers made this change, I'd appreciate hearing it.

Good Scrollbars Are More Complex Than They First Appear

posted by Kravimir at 1:44 PM on Mar. 21st, 2011

Categories: JavaScript and DOM, Usability & UX 1 comments

It seems pretty much everyone is aware of the up and down (or left and right) arrows of scrollbar. However, there are several more features to a good scrollbar. Most people also notice the drag-bar, but did you realize that the length of the drag-bar relative to the "track" (or "gutter") is used to indicate how much of the page is currently in view? Also have you ever clicked in the track itself to make the page scroll one screen's-worth?

Before making your own scrolling mechanism, I'd like to remind you that the keyboard and mouse (and other pointing devices) can also be used to scroll. The arrow keys and, for full-size keyboards, the "page up" and "page down" keys are nearly universal scrolling controls, but have you realized that the spacebar, "home", and "end" keys can also be used to scroll in many web browsers as well? Mice and trackballs often include a scroll-wheel these days and, likewise, touchpads often include a special region to drag your fingertip on to scroll.

The reason I'm writing this is that most of the custom scrollbars I've seen are missing many of those features. To be clear, I'm not saying all custom scrollbars are bad. For those who would like to create your own scrollbar design here are two scripts that I would recommend: jScrollPane and FleXcroll. At least in some configurations, those scripts support all of the features mentioned above. They might be difficult for people, especially novice users, to identify on the page though.

This has been a public service announcement aimed at graphic designers in the hopes that they'll rethink creating custom scrollbars and other scrolling controls that cause frustrating user experiences.

Related: