I'd love to know how long a string is when it appears on the screen. We're not using a fixed width font, so:
"Our mother's tummy makes dummy noises."
is much wider than:
"Lilly Leadbetter lives life leisurely."
Is there a way to tell how long something is by the characters? I don't need pixel perfect accuracy, just long enough to ellipse at roughly the right spot. CSS overflow won't help, because I can't attach the ellipse after CSS has determined how long it is.
Here's a related question with at least a partial solution. Basically the technique is to render the text in a hidden <span> and then (using JavaScript) measure the pixel width of the span, then chop off characters until it fits in your target width.
And here's a jQuery plugin that encapsulates this sort of functionality, linked from this related question.
Ordinarily I'd agree with fsb that you have to understand that on the web you don't have pixel-perfect control over everything. It's not print. Choose a reasonable length and chop it off server-side, you can avoid chopping in the middle of a word to make it look a little better.
If you insist on a perfect length though, check out ThreeDots, a jQuery plugin.
Unless you're using a fixed width font, I don't think there's any simple way to tell. Perhaps the easiest way is to render the candidate text and see how long it is.
Server-side, this is a bit hit-and-miss because you don't know for sure what the browser is going to do with the text. You could use GD (or something like that) and your best guess what font and size the browser will use but is it worth the trouble when you can't trust your guesses?
Client side in javascript (or whatever) you can have the browser render the text and look to see how long the rendered DOM object is (as Jordan said).
One solution, though perhaps very hard psychologically, is to understand that web page rendering is not typography. You do not have control. You do your best, accept the limitations and move on to the next problem. Technically simple but maybe hard to accept.
You can use the truncate helper function. Even if you know about the visual length, you cannot probably optimize it for all browsers/browser window resizes.
Related
I've been learning to code for some time and I've sure learned quite a lot, but styling has always been a pain in the ass for me (it's very embarrassing, I know). I absolutely have no idea how many pixels a nav bar should have or how wide any component should be. If it's just too small/big for me, I'll resize it. Size units? No idea. Don't get me wrong. Percentages, ems and metrics - I'm aware of its existence and what they do, but I do everything in pixels. I'm not saying that things I code look horrendous and not responsive. It's all try and error until things look aesthetically pleasing and it takes me so much time to make things look pretty.
Let's say I need to make something simple like a popup modal in CSS. I might wrap the hidden content in a div, with a class of modal, its content in a div with a class of modal__content, make a button to close it and some text in it. Semantically correct HTML is not a problem. Animations and colours? Fine, you got it. I just have no clue how to style it. That's when I realise I know CSS just in theory. I can code it, but I just have no idea if the modal should be 300x200 px box for a desktop screen or maybe use percentages?
If you have some saved articles or a book you could recommend, I'd be very very grateful.
I've used Bootstrap and Semantic UI. These are very cool and convenient tools, but I wish to know some in-depth guidelines when it comes sizing since I don't really know what something should actually look like. Most of the time I'm just eyeballing all font sizes, paddings and margins etc.
I'm not a good at graphic design either. Few people excel in both graphic design and in programming/scripting.
SitePoint has some books worth reading on the subject, the first especially (each available in paperback and as an ebook):
The Principles of Beautiful Web Design, 3rd Edition
Sexy Web Design
The Universal Principles of Design is likely to cover topics such as those you're asking about, although I haven't read it.
Graphic design relies a lot on convention (which is usually a good thing), fads (less so), and the preferences of the designer and client. However, there are various guidelines that are important to know. I'll mention a few here.
Large or bolder type, motion (videos and other animations), and contrasting borders and backgrounds draw the eye. Be careful not to give such visual emphasis to too many elements at the same time. (This is a common problem for home pages of organizations that many factions competing to highlight the thing most important to them.)
Adjacency implies relationships. For example, it's typically better to give headings, e.g. <h2>, a larger top margin than bottom margin.
Elements tend to need a comfortable amount of space between them without using too much screen space. When large spaces between content sections are desired, it's usually best to scale them down for mobile devices.
Animations serve multiple purposes. There are the various pulse/"throbber" animations to indicate that content is being loaded or some other kind of processing is taking place. There are transitions that show a non-instantaneous change between states, e.g. a menu opening/closing or change is views of a content/image slider. While others are mostly for aesthetic reasons, to add visual interest.
I'm glad you mentioned semantics. Do you use <label> elements where appropriate?
P.S. Too many people who call themselves "web designers" don't know, or refuse to acknowledge, the differences between graphic design for the Web and for print.
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
Hey guys I have a question, I plan on making a website for a friend that wants a nice description about them, for in terms of design they want something like this:
dsdsdsds
sdsdsdsdsdsdsd
sdsdsdsdsdsdsdsdsds
sdsdsdsdsdsdsdsdsdsdsdsd
sdsdsdsdsdsdsdsdsdsdsdsdsd
sdsdsdsdsdsdsdsdsdsdsdd
sdsdsdsdsdsdsdsdsdsd
sdsdsdsdsdsdsds
sdsdsdsdsdsd
sdsdsdsd
So basically small line of text at the start, and increase for the middle, then decrease in size near the end, so basically a circle type. Any ideas?
One bad way is to have a fixed number of lines (and maybe no word-wrap). Just do spans and have the id's of each span have a pre-defined width.
A better (somewhat) way is to do something along these lines css circle via stack-overflow. You may have to tweak it though (and I haven't tried it), but you could play around to see of you like it.
I'm pretty certain the latter is the way you would go, but the ease of constructing it may not be overly fast.
Good luck!
After looking around in Google, I have found this:
CSS Text Wrapper
It involves javascript, but you dont really need to know javascript in order to use it.
if you want to achieve that use
<pre></pre>
then apply the css to the text.
Its the easiest way to do that.
I'm working on a project which will deliver small pieces of text to a display engine that will show them to the user. One of the requirements is rich styling: position, color, font, the works. Each transmission should stand alone, with its own embedded style information. I have already built a web service to deliver the text.
How should I represent this style metadata so that it's compact, flexible, easy to parse and easy to render? I haven't decided on a client to display the text, so it should be as presentation-agnostic as possible and easy to transform if I need to. I was thinking of using CSS, but I'm not on top of all the different ways to style text these days. What would you recommend?
Some more specifics about what you're trying to do might be useful. As far as I can tell though, I don't see any real reason not to use CSS or something similar.
It's easy to type, easy to learn, widely known, and there are pre-existing engines for rendering it. It can do all the basics of text styling and positioning. (And CSS3 transforms can give a lot more flexibility in terms of text positioning.) And if you end up implementing your own rendering engine for some reason, it's easy to parse and there aren't too many rules if you only need to worry about text and absolute positioning.
There are a couple of reasons I can see for not using CSS. One is if you need more advanced transformations--say, you want to skew or distort the text (in cases like this, you're going to need to end up rendering an image instead of text). In that case, I don't know of anything pre-existing that will fit your needs. (I think the closest match in that case would be SVG, but then you lose any prospect of it remaining at all simple or easy to use.)
I would say this is a perfect place for using XML. You can go way beyond the permissible values of CSS in defining your meta-information.
If you wanted something more compact you could send back objects via json with the same information.
CSS is really meant for rigid web-browser-compatible display. If that's not what you're doing here I wouldn't recommend it myself.
EDIT:
Example:
<data>
<font>Garamond</font>
<text>This is the message I'm sending back</text>
<font-weight>bold</font-weight>
<color-of-the-third-letter>green</color-of-the-third-letter>
</data>
CSS ultimately cannot be as specific as custom XML. It all depends what you want from it, though.
This issue is obviously bigger than I thought! Using the VS2008 form designer for web pages, it'd a doddle to lay everything out using pixels. In fact, as far as I can tell, it's very hard to use absolution positioning and anything but pixels.
So my webapp has developed nicely until somebody mentioned the 120DPI issue and I've wandered off into another field which I've managed to kind of ignore.
I'm the person who thinks if you get a bigger monitor, it's because you want to display more windows on there with the same size text, not make everything bigger because you're 40 and your eyes are playing up ;-)
Given that there isn't a way for the designer to lay things out in anything apart from pixels, is there is half way house? I'm not about to go through every inline style changing from pixels to em values. Sorry, but that's just too much work for a volunteer written webapp.
Is it okay to keep pixels for the layout of text boxes etc. but switch to using some percentage based system for fonts? Will that size correctly?
This is only a problem in IE7. IE8 looks at the DPI setting and scales the x,y,w,h values as required. I appreciate this is both right and wrong at the same time. IE8 now works correctly with 120DPI where fixed pixel sizes have been used.
Cheers, Rob.
Have you considered not using such strict control over your sizes? In general, you will probably find it much easier to specify as few sizes and positions as possible. HTML is designed to handle size and position dynamically. The less you specify explicitly, the more able the browser is to arrange the page as needed to fit the user's browser size and viewing preferences.
Anyway, if you really must make heavy use of fixed positioning and such, I highly recommend you not use the visual designers in visual studio. They are very much NOT up to the task. I'd recommend looking around for other designer tools that handle the WYSIWYG stuff better. While I'm not a fan, dreamweaver does a respectable job with absolute positioning and has at least some support for aspx too.
Might I suggest using the YUI 'reset-fonts-grids.css' CSS from Yahoo, then you can use EMs as your units for fonts meaning the user's browser can decide how large or small to show the text.