The stylesheet for my blog is fairly simple. It consists of white or grey text on a black background. I'm thinking about, eventually, giving the user the ability to "turn on the lights," so to speak, and invert the colors.
It got me thinking that I'm unaware of a way to simply swap two values (say, #fff and #000). I obviously know about find and replace functions in most text editors, but if I ever need to do something like this, I end up doing a multistep thing where I replace the first value with a slightly weird version of the second (e.g., swapping #fff for #00$ instead of #000), then the second value with the actual first, and finally the weird value with the actual second.
Know a quicker way? I use TextMate on the Mac, and I'm pretty sure it doesn't have this functionality, but I'm willing to use another app just for this.
Thanks!
Related
Let's say a component allows the choice of picking between 20 colors. Should these swatches have labels on them? It seems a little pointless to me since there's no standard for color names besides (probably) meaningless gibberish like #d1ed7e. However, I'm wondering if anybody has an argument for their inclusion.
For color choices on a product selection, say a blouse or shoes, then color names might be important.
And there is a standard for color names. It's in the CSS documentation.
https://www.w3.org/TR/css-color-3/#html4
https://www.w3.org/TR/css-color-3/#svg-color
Those CSS color names might not match a company's name for a color, like "Dusty Sunset", which could be a shirt color or a paint color.
RGB values can also be very useful. What you might think of gibberish, #d1ed7e, might mean a lot to me if I'm a designer or coder.
Visually displaying the color name along with the swatch can also be helpful for some users. You don't necessarily have to "hide" the color name for just screen reader users.
Here's an example from a shoe website.
The current color displays as "Navy" and if I hover with the mouse over the other color, it shows "Tan". Tooltips are not the best way to do this since they're generally not displayed on mobile devices and tooltips often only work with a mouse hover and not keyboard focus, but it gives you an idea of showing color names.
If I'm in a design system and I want to choose a color, I probably want the exact RGB or HSV values so displaying the color code would be helpful.
One of the rules of WCAG says that information shouldn't be conveyed only by their color.
The color of an object, whatever it is, is always an information. It can be more or less important depending on the object and user taste, but it's always a property that the user must know about.
As a consequence of this, definitely, yes, colors have to be labelled in some way, and not left alone without labels.
For sure I want to choose the color, and at worst I don't matter at all and pick one at random. So at worst it anyway never hurts.
It's not because I'm blind that I'm not interested or don't matter at all about colors. For clothing, it stays important. I don't want to wear pink and green together, right ?
I might make a gift to a sighted friend. And what about color blind people ? They will certainly find useful to see "red" and "green" explicitly written, instead of apparently seeing two identical options.
Even normal sighted people are sometimes surprised because the color of what they receive don't match exactly what they saw on the screen. Maybe the brightness wasn't optimal, or he/she ordered during the night, or under artificial light ? I'm pretty sure that a name may help in this case, too.
As explained in the previous answer, the kind of label you should show depends on the kind of users using your site.
However, I don't agree with using CSS names.
For daily life objects sold in a shop, use the same name as it is officially called in your article catalog, it's probably better than using CSS names. If you can stick to quite generic color names, it's probably even better than a possibily brand-specific vocabulary. Example: is "blue marine" or simply "marine" more widely understood than "navy" ? (I'm not native english speaker, so maybe it's a wrong example, but I think you get still the idea).
If I look at all CSS names, really, there are colors I don't know about at all. Jaws has also a quite big list of colors mapped to RGB values, but many don't make much sense either for a lambda user.
For development stuff, RGB code can be very useful, but remember that it doesn't make sense for most people or in other contexts
To wrap up, yes, label your colors, and if possible with names that are widely understood
I'm looking for a sanity check on an idea I'm considering implementing. I'm working on a client list page and I want some transition effects on the logos. For now, it's going to be a colour transition from white to gray but who knows what else down the line. I can't use something like CSS grayscale() filter because in my tests white isn't getting changed to gray. (And that makes sense, right???).
So I was thinking that I could use SVGs instead (either outputting them inline or more than likely as an SVG image). In terms of practical management it isn't going to be an issue to either create the SVGs or upload the logos to the site so I'm wondering about things like performance or just generally thoughts on whether having 20+ individual SVGs (which can be pretty weighty in terms of markup) is madness. I've not used SVGs a whole lot so excuse me if the answer is obvious.
On the other hand, I'm thinking that if I stick to pngs I'd have to create functionality to add 40 images (20 white and 20 gray versions) and this seems like a bad idea from a performance perspective and also like a massive pain in the you know what.
I'm developing a BlackBerry 10 mobile application using the Momentics IDE (native SDK).
I have a Label which has fixed width. If a Text does not fit in this Label, I want it to be ellipsis (elliding the text with the conventional "..." at the end) in place of a fade effect (just sort of "ghosts" into oblivion) like the Cascades designers have chosen to be in such case like presented in the image below.
Can any one help me on this ?
Since Peter doesn't seem to know how to do this in a straight forward way, the only option left would seem to be the complicated way. You may, of course, create your own control and manage the text rendering in the way you would like using an ellipsis instead of the fade. That would seem to be a great deal of work for what in the end will really only result in your program being unconventional on the platform.
Edit:
Since you think it is worth a bounty I will add the following thought.
Using the ellipsis method, instead of the fade method, may impose a performance penalty on your application. Elliding text requires the computation of how many characters may be displayed int the available area and still leave room for the ellipsis. This is not a trivial mater with variable width type faces or different character sets. The fade, on the other hand, is a simple transparency operation. Since UI graphics operations in Cascades are all done in hardware the fade is quite efficient and independent of the size of the string, text area, type face, etc.
Which version of QML? QML element Text has elide property and this is what you want.
Is it possible to animate text/object with 'end' in after effects just like you do with strokes? How can I achieve this? See the video and you'll understand what I wan't to achieve.
YouTube - Guy showing the 'end' on a stroke
Cheers,
Tommie
I think I see what you are asking. You want the shapes of a text layer (the actual lines of each character) to actually build on, right? Can't be done like that. Even if you use text and convert to shapes, you are looking at a world of pain because of the way letters are built by most fonts (for one thing, the shapes are actually filled, not stroked -- strokes are outlines).
The only way I would do this is by using the Element 3D plugin in After Effects and Cheetah3D (or whatever 3D tool you want to use). In Cheetah, I'd create the text shapes as extruded 3D text. Then I'd use the "Build" modifier ("Linear" setting) to progressively build the text. Then I'd export that out as an OBJ sequence (script for this is available on cheetah forum site -- I wrote it) and bring that sequence into Element3D and work with it that way. That will work. And as far as I know, that's the only way with a decent amount of control. Wedding video? Just curious. :-)
I noticed that every browser renders the border-style: inset; property differently, so I had two questions:
Why do the browsers render it differently? How can there be so many different algorithms for this? Most of all, some browsers look wrong with it!
Since I can't rely on the inset attribute working, I was wondering what the proper "algorithm" is? I typically go 16 lighter on top/left and 16 darker on bottom/right (ie. #666666 is the background, so #767676 is the top/left and #565656 is the bottom/right)
I need to know what to use (generally speaking) because I'm having trouble making my styles inset, and I clearly can't use the inset properly so I have to manually change the colors. Sometimes, however, it just doesn't look right (if it's too dark). There has to be a good algorithm out there for this?
I've looked for web resources on the issue (such as a "what colors your borders need to be to make this look inset!" tool) or anything that could help, and found nothing.
Think of it this way: If someone were making something in a paint program and didn't have an inset effects button, what colors would all four of their borders be, given the main color is _____?
There HAS to be a general algorithm for this that I can't find...
Edit: I want to point back to my example of using a paint program that needed an inset style. Can someone give me an example of what they'd use for this? (Is this part of the question better directs on the designers stack?)
Quote: "1. Why do the browsers render it differently?"
I'm sure each browser does it differently because they think theirs looks best. IE probably does it to look good in Windows. Safari is making theirs consistent with the look of Mac OS. Firefox in keeping with that browser's other elements, etc. (and like stated by thirtydot, it has not been standardized.)
Quote: "2. Since I can't rely on the inset attribute working, I was wondering what the proper 'algorithm' is?"
You could try to reverse engineer it if it's that important. Setup a test page and call it up in a browser. Use an eye-dropper/color-picker utility to pick off the various colors. With enough samples, you should be able to find a pattern for that one browser.
Quote: "There HAS to be a general algorithm for this that I can't find..."
Not if every browser does it differently. Each will have their own algorithm.
EDIT to address OP's follow-up:
Quote: "Edit: I want to point back to my example of using a paint program that needed an inset style. Can someone give me an example of what they'd use for this? (Is this part of the question better directs on the designers stack?)"
You seem to be looking for one specific answer where one does not exist. I cannot give you an example of what I'd use since modern graphics programs (Photoshop) will do this for me and then give me enough options that, when combined, literally provide millions of results; border color, highlight color, shadow color, depth, angle, thickness, profile, etc. Ask 20 people what they think is the "perfect" inset and you'll get 20 different answers (opinions really) and then we're back to the reason it looks different in each browser (see #1 above). So yes, in the context of "programming" questions, this last part of your OP is probably off-topic.
Additional Random Thoughts:
Why is border-style not Standardized? IMHO, I'm thinking this property is simply not used enough to warrant any major effort to Standardize or perhaps there is much disagreement on this in the Standards community. I imagine that all the CSS properties requiring Standardization are prioritized in some fashion (popularity, usefulness?) and this one just didn't yet make the cut or bring everyone together. Personally, I think a property like this is tied too closely to ever-changing trends. i.e. - 10 years ago, we used to see to see lots of tables with very thick "embossed" borders. These days, many designs use few borders or very thin borders, if any. Again, this is only a matter of taste and opinion.
I have an answer to this:
Why do the browsers render it differently? How can there be so many
different algorithms for this? Most of
all, some browsers look wrong with it!
See: http://www.w3.org/TR/CSS21/box.html#border-style-properties
The color of borders drawn for values
of 'groove', 'ridge', 'inset', and
'outset' depends on the element's
border color properties, but UAs may
choose their own algorithm to
calculate the actual colors used. For
instance, if the 'border-color' has
the value 'silver', then a UA could
use a gradient of colors from white to
dark gray to indicate a sloping
border.
That's the reason implementations differ - because it wasn't standardized.
I would say for lighter side add 20% to each of the rgb values, and for the dark side remove 20% from each RGB value..