Make the cuttag arrows scalable.

[facetofcathy]

Title:
Make the cuttag arrows scalable.

Area:
Entries

Summary:
This is a very small suggestion about some very small things--the cuttag arrow images. They are small in size on the screen--11-15 pixels a side. Small in file size--around 100 bytes. And small in target--the image link has no padding on it.

They should be bigger and scalable.

Description:
Make the images scalable.

It's easy to make the arrow images scale up with a user's font size. You just need to set a width on the image in ems--something like .7em, which at a 16px font would show the arrow the same size it is now, but would let the image get bigger as the font size went up.

The problem is that the images are so low resolution, even very minor enlargement makes them very blurry. Making the images much higher resolution to begin with means that they start out shrunk down and they have room to grow.

Users of touch screens that zoom on the arrows to make them big enough for a finger to hit will also benefit from a less blurry image.

This increases the file size of the image. I made an 88 pixel square .gif of the right-facing arrow and it went from 91bytes to 573bytes. Something more in the 44px range is likely adequate if file size is a concern--that would give a clean image at up to a 62px font size.

Make the target bigger for everyone.

"Target" refers to the area you have to hit with your cursor or your finger to click a link. Right now it is the size of the image, nothing more.

I use a padding of 0.2em on the image and it gives me an 18px square to hit at default font size, instead of an 11px square. It makes a huge difference. (By the way, the span class .cuttag is inconsistently applied in the code and doesn't appear on the closing collapse arrow.)

Making the image scalable and putting some padding on it would make it a feature more users can enjoy.

Poll #9802 Make the cuttag arrows scalable.

Open to: Registered Users, detailed results viewable to: All, participants: 73

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
56 (76.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
2 (2.7%)

(I have no opinion)
15 (20.5%)

(Other: please comment)
0 (0.0%)

Comments

[pseudomonas]

Does this mean that the userheads can be made scalable as well?

[facetofcathy]

All images can be scaled. The question is always, how do you do it and does it cause a problem with file size.

I hadn't thought of the userhead when I made this suggestion, and I focused on the cut tag arrows since they are always images--other images like the entry management links can be changed to text. But the userhead only provides a text link alternative if you have the hover pop up enabled, so having it scalable would be lovely.

If I could have everything, I'd want all the clickable images to be scalable in some way.

[noracharles]

It would be good for users to be able to have larger cut tag arrows, but I wouldn't want them to be smaller for me. My font size is set to 12px.

I think many people who are comfortable reading smaller fonts would still prefer a larger target when they have to click things.

[facetofcathy]

Oh, good point. It's a simple thing to set a minimum the image wouldn't go below, which could be exactly what it is now.

[zaluzianskya]

Why not just use text for the cut tag arrows? A ► or something. That wouldn't have any issues scaling.

[pseudomonas]

So long as you use a glyph that most platforms will have a font for.

Sorry, you get the info dump of my research.

[facetofcathy]

That's a really good question. This is a complex issue where the best thing to use really depends on your site and what you're using the icon for. I spent a while researching this, and decided to stick with the basic technique that DW uses now for this suggestion.

Using ascii characters can be done, but has never been very popular in web design, I believe, because the failures are truly silent. If a user's browser can't display the character, it's often because of their local encoding settings, and the site never knows they failed to deliver meaningful icons. Mostly you will see only very popular and well supported characters used on sites. People often think they look very 1995 too.

The other drawback is that the semantic meaning of these characters is fixed and limited. A screen reader reads your example as something like forward arrow, which doesn't mean anything in context. The images used have context-specific alt text.

Another newer option might be font face icons like Pictos or Twitter Bootstrap's Font Awesome. They're very flexible and can be styled by CSS in the layout. They both claim a level of accessibility that I'm a little dubious of, and they both rely on using generated content via the :before pseudo element, which is not supported by the usual suspects. This might be made workable, but I'm not yet convinced.

Scalable Vector Graphics supplied via the img tag is even better than my suggestion, but would require server side or JavaScript fallbacks for the usual suspects who don't support it. SVG has all the pluses of images and is inherently scalable.

Another plus to using images or SVG is that the door is open to allow them to be changed in styles or in user options to theme-relevant colours or designs and the sky's the limit on what could be used.

[zaluzianskya]

That all makes a lot of sense! And don't apologize, I love info dumps to be honest. Thanks a lot for taking the time to write that all out.

Re: Sorry, you get the info dump of my research.

[ninetydegrees]

and they both rely on using generated content via the :before pseudo element, which is not supported by the usual suspects.

If only it was! Scalable arrows can even be created using pure CSS and no image or font (I have this is in my style). *sighs*

Re: Sorry, you get the info dump of my research.

[facetofcathy]

I know, right, and this is the thing that makes me dubious of Font Awesome.

Their site is all yay! compatible, yay! accessible, and they even go so far as to talk up how @font face is supported in IE4, but meanwhile, you can't use the accessible CSS in all browsers.

I don't like that they never define, "won't trip up screen readers" either. Pictos seems just as slippery on this issue.

[msilverstar]

I would like a bigger target for that function, so yes!

[marahmarie]

I'm curious about you mentioning the expander images having no padding because they have padding on my blog. If you check my CSS, you'll see I have the padding zeroed out. If I don't zero it out, it's about 2 pixels on all sides. Granted, I'm not sure if my own CSS (the stuff I added myself, in other words, not the default style) is at fault for it, but I haven't knowingly added any padding to that element (in fact, I have all DW-originating images zeroed out on padding, because they all have it) but something is.

On second thought (wow, I'm thinking out loud as I type) I have padding set on entry images - wonder if that could be it? I always assumed the padding was on DW's end, but now that I think about it, maybe not.

Anyway, yes, the cut-tag images do scale badly regardless, and ASCII character replacements do fall short for all the reasons you said.

[facetofcathy]

If you mean you set a padding on .entry img, then, yeah that would definitely add padding to the cuttag images in posts, but not the ones in the module.


I double checked my style, and the only padding on anything, a, img, span, div etc. is coming from what I added via custom CSS.

[facetofcathy]

And just adding a note here to mention that Opera users also get to experience really blurry cuttag images and other icon images, like the entry interaction links and the userhead, since Opera zooms the whole page, not just the text.