Related
I would like to know if it is possible to have line-breaking text that sometimes consists of one line and sometimes of two. I can best describe what i mean it with an image:
You would have to insert the text into separate elements which have the shape and size you want to achieve the effect you are going for. It is not possible with just one html tag.
As Watson said, you'll have to contain the elements in containers of a specific shape and size. You can't make them truly "fluid" as I think you're meaning to comment, however, you can use percentages for those containers to determine how much text is visible in space and possibly viewport sized text to try and properly fill those spaces. Definitely no manner in my mind that will allow you to easily create this in a universal method for all browsers. You're going to have a lot of ragged edges I'd suspect.
Are there any existing plugins/extensions/methods to maintain vertical rhythm for Twitter's Bootstrap project?
It is quite a laborious task to create good vertical rhythm templates, I would rather use a pre-baked solution. I am open to creative suggestions, I just want my pages nicely aligned in the end.
Edit: To clarify what I am after...
Vertical rhythm is a technique used to ensure that every element on a page lines up according to a horizontal grid. This is achieved by setting the height, padding and margin of every item to conform to a standard unit line size. If a line of text in a paragraph is 20px high (including margin and padding) then maybe a heading 4 will also be 20px high, and a heading 1 might be 40px high. This maintains the rhythm of the text across columns.
I want to use this technique in combination with bootstrap (from twitter), but it would be quite a lot of work to get everything looking nice. For example, all the buttons would need to conform to the same vertical height definition as paragraph text etc... There are other standard controls used in bootstrap which would also all need rules to define their height appropriately.
I could start with a generic solution for vertical rhythm, which would go a long way to achieving what I want, but I wanted to know if anyone else has started this, or has any idea of another way to achieve this.
Edit: Assuming there is nothing like what I want...
Maybe just a good vertical-rhythm based css template would be a good starting point. Preferably something that is continuing to be developed, is already usable, well thought out, and adaptable.
Since no one has linked to an actual vertical rhythm boilerplate as you suggested, I took the one I use, commented it, and created a github repo for it here https://github.com/jonschlinkert/vertical-rhythm
As it says in the readme, this is a starting point for your own project.
I think what you're going after is understood. Problem is: you're looking for a grid schema in one dimension (a "vertical rhythm" set in accordance with, for example, proportional line heights...which, in a manner of speaking, measures and aligns things along a given page's Y axis)...but doing things in that manner might potentially be at odds with Bootstrap's pre-existing 12-column grid system (which, in contrast, measures and aligns things along the page's X axis). You want to "proportionalize" the height of each "row" in the framework. BUT: keep in mind, Bootstrap's design is intended to promote not just proportionality via columns solely for the sake of looking nice, but to also make pages responsive--i.e., to allow page elements to "flow" around one another vertically, and to nest fluidly. And, in that sense, issues pertaining to the height of elements measured along the Y axis may already be accounted for... I recall that most of the typographic elements in the base CSS file have proportional em sizes, and/or likewise proportional top and bottom padding, etc. Generally speaking, things are not so arbitrary that the framework screams a need for additional styling in the manner you're considering.
Even so: Bootstrap's base CSS file isn't so intolerably extensive that it'd be impossible for you to tweak the height of various element classes and IDs yourself without too much trouble. In any case, it's highly unlikely you're really going to need to do that with every styled element, right? In fact, as a framework, Bootstrap includes styling for many elements which may not even be in the app for which you're designing the front end. (EXAMPLE: Does your app have drop down menus? Great. You can style the "vertical rhythm" of drop down menus. BUT: are you also using pills or tabs in your nav bar? No pills, you say? Well, you can just delete a couple hundred lines of code in the stylesheet and save yourself the effort of having to apply your "vertical rhythm" to those unneeded elements.) Elsewise, for the elements that remain and that you do in fact need, just use a text editor to find-replace the values for line height, top and bottom padding, margins, font-size, etc...and test it out. As a CSS framework, it's pretty clear how Bootstrap is laid out; relevant elements are well sorted, and grouped together within the stylesheet's code for the most part. Once you do complete tweaking of the base CSS file, just minify your revised stylesheet...to replace the pre-existing minified version...or, perhaps, just serve it up from CloudFront if you want to optimize.
The Compass CSS Authoring Framework has explicit support for vertical rhythm based typography. For starters you can check out this short video tutorial.
Have you looked at the Square Grid CSS framework?
http://thesquaregrid.com/
A simple CSS framework for designers and developers, based on 35
equal-width columns. It aims to cut down on development time and help
you create beautiful-structured websites.
Square Grid provides a standard horizontal grid, but it also maintains a vertical grid, using a standard "square" of 28px. It is really just a grid, not a full CSS library like Bootstrap (i.e. no buttons, menus, etc).
I used to for one project and found it to be pretty intuitive, though I ultimately decided that it was too hard for me to keep track of both the vertical and horizontal grid, especially when thinking about responsive design.
You may be able to combine the two, or at least take a look at the square grid source code which is pretty simple CSS to get some ideas on how to adapt Bootstrap to meet your needs.
What are the differences between how CSS and Latex organize boxes? (Either paragraph or graphical elements.)
The general scheme, of having a hierarchical boxed representation of page layout produced from processing of input language, and that is then turned into the rendered page, is basically similar between the two models. The four differences that are most impressed on me are:
The CSS boxes model is a robust abstraction, whilst the layout of boxes in the Tex model is operationally determined: as boxes are being laid out in the Tex model, the code can break apart and re-layout earlier boxes.
While Tex's layout model is text-oriented, like the CSS boxes model —and as opposed, to, say Adobe's InDesign page-oriented layout model that's very much about fitting together blocks to cover each page— it still has quite a few page-oriented abstractions, like determining "badness" of vertical space in order to place footnotes - there's nothing like that in the CSS boxes model that I can see. Context has a more sophisticated page layout model, that allows both text-oriented and grid-oriented layout together.
Both the CSS model and the Tex model have notions of block-level boxes (vboxes) and inline boxes (hboxes). However, while you can specify using CSS that a block-level box occurs inside an inline box, section 9.2.1 of the CSS2 standard says that the semantics of this is to turn the outer inline box into a block-level box, so the CSS box model basically forbid block-level boxes from occurring within inline boxes. Tex, by contrast, is happy to have vboxes inside hboxes, which offers power to do things like place pieces of text above text inside a paragraph's text.
Most importantly, the CSS box model has no notion of flexible glue, making scaleable page layout much trickier, and is, I guess, the reason why fixed-width webpage design is dominant.
The specs for CSS are not hard to find and of course they contain a chapter on the box model.
The information is somewhat harder to find for LaTeX, but you can look here, where you can read:
LaTeX builds up its pages by pushing around boxes. At first, each letter is a little box, which is then glued to other letters to form words. These are again glued to other words, but with special glue, which is elastic so that a series of words can be squeezed or stretched as to exactly fill a line on the page.
I admit, this is a very simplistic version of what really happens, but the point is that TeX operates on glue and boxes. Letters are not the only things that can be boxes. You can put virtually everything into a box, including other boxes. Each box will then be handled by LaTeX as if it were a single letter.
I think this is very different from CSS, but for details I'm afraid you have to read books, e.g. The TeX book by Knuth, or the LaTeX companion by Mittelbach et. al.
Miel.
There is a dearth of discussion on this important matter.
There is one key reason I wish that HTML/CSS layout was based on TeX: the lack of glue or springs.
TeX didn't really need to use this feature as the use of TeX was always to lay out content on fixed pages. But the most natural thing on a web browser (ever since screen sizes have gone beyond 640 x 480 pixels) is to resize it, especially the width.
It is impressively difficult in CSS to lay out something like a slide-show, with a frame in the center occupying most of the space and 2 thin stripes of forward and backward buttons, right and left respectively, that then resizes gracefully, especially as we get to the narrow end of the spectrum. But also, on the wide end without wasting all the space in margin as many modern CSS layouts do.
In TeX that is easy. You have an hbox, with a grow- and shrink-able center frame, and the forward and backward button are fixed size.
As you increase the page width, only the center frame expands, and as you reduce the width, only the center frame becomes narrower, until all its shrink value is used up (minimal width) then it stops (and supposedly a horizontal scrollbar would appear.
This is the one key aspect I feel is badly missing from CSS. It is so much more natural, and amazing that Knuth had invented it at a time when dynamic screen layout was decades away from becoming reality. And it is sad that this genius was forgotten.
I assume that the box and glue model was argued to be
too hard on real-time computation capacity of earlier web clients
too "difficult" to implement for Microsoft programmers
too "confusing" for beginners to use.
All of this are very weak arguments IMO.
The same issue appears in Java/Swing Layout schemes. I remember I implemented a real Box and Glue Layout in Java to use with SWT on a project some 15 years ago. Once you have it is's so awesome.
I am awaiting a real box and glue layout option to appear in some next generation of CSS before the end of my programmer career, and I hope soon, so I can still use it for a few years.
Sometimes while typing in a textarea in Flex many characters will be rendered at one height then at some point on that same text line the rest of the characters are rendered a couple pixels lower than the rest. Here is an example, look at the last 'I' character, its low:alt text http://img.skitch.com/20091031-ej5n28akygnm3gmxcjx731ic85.jpg
Sometimes changing the font size will fix this but its not consistent and its not something I can detect (and fix even if I could). Anybody got an idea why this happens? It happens for embedded and non-embedded fonts.
Thanks,
Sam
Flash acts strange sometimes when movie clips, textboxes etc are not on whole pixels. Make sure the textbox has integers for it's coordinates. If it is in any movie clips, make sure those movie clips have integers for coordinates too.
The other option would be to fudge around with the anti-aliasing features in Flash, but that's always a hit-or-miss situation.
Is there any reason to avoid using text-align: justify;?
Does it reduce readability or cause problems?
Firstly, this is purely a design-related problem and solution. The design of your grid specifies if justifying text is needed. I think justify align alone has no major effect on usability. Bad typography that makes text illegible is what decreases usability. That said, make sure you have solid contrasts and a good balance of spacing in your type. Font-size matters too.
This site is a successful attempt at justifying text online. Since you can't control the spaces between letters and words nearly as much with CSS as you can with InDesign, it's a lot harder to justify text and not have 'rivers' of whitespace run down your rows, which happens when the spaces between words exceeds the spaces between lines. Things that make justifying text difficult: long words, row widths that don't hold enough words, and too much contrast between the text and the background colors; they make the rivers appear wider and more apparent.
The typographic ideal is to have an even text-block, where if you squint the text block becomes a uniform solid shade. So if you keep text at about 10px and 60% gray on white background, and have rows that fit about 20 words, justify align shouldn't look ugly. But keep in mind this does nothing to improve usability. Small, relatively light text annoys a lot of people, especially the older readers.
I should note that with (soft hyphenation) correctly separating long troublesome words like superawesome you can mimic proper typesetting (e.g. InDesign). There's a lot of stuff out there to help you do this. I would recommend the logic for hiding, manipulating, and displaying the text to be done on the client side, perhaps with this.
Edit: As others mention below, css hyphens are possible now, except not feasible (not in Chrome). Plus, css4 offers even more control.
text-align: justify shouldn't be used in browsers at the moment. They aren't good at handling the minute details within and the output ends up containing lots of rivers and there's no support for hyphenation (other than soft hyphens).
Note above was written 4.5 years ago. Things are slowly changing... http://caniuse.com/#feat=css-hyphens
Edit:
Hyphenator was brought to my attention in this answer's comments. It looks like it makes text-align justify worth using, check out the sites that use it. You may want to use javascript to apply text-align justify before using this script so that those without javascript don't get caught out.
Edit 2:
CSS now allows for hyphenation with the hyphens property [browser support]. PPK is now saying to add it to your stylesheets, whilst Eric Meyer says just add it for mobile.
Edit 3:
A good little overview of things available to us now, with some SASS.
The problems brought up by others about justify alignment are more prevalent with narrow columns. If your columns are wide enough in relation to the size of your fonts and other parameters then it's ok to justify the text. Let's say you'd want a minimum of 12 to 15 words per line in average. More is better.
There's no technical reason not to - it's purely a design decision. Many people find that justified text is harder to read, but I guess it depends on your situation. Though it works fine for print, generally web browsers do not give enough control over the eventual output of text to guarantee that what you're serving won't look like crap on some people's screens.
Your best option is to avoid justification.
I cant think of a compelling reason why not to justify text - at a certain point the volume and width of content almost demand that it be justified. Of course, you'll get issues with content consisting of certain word combinations, but to my mind if you're seeing rivers and unusually large spaces between words you have a different problem altogether - one of readability and clarity.
What I would avoid, at all costs, is centered body text. I don't think there's a greater red flag of ammateurish web design than that.
I prefer left justification (text-align: left) because it's generally more readable. It's also quicker to read evenly-spaced words, so I hear. Unless you have a stylistic reason for using justify, keep it left, right, or center. Especially for body text, use left. (Actually, you'd want something like "forward" for text in the other direction (e.g. Hebrew)...)
Justification should not be used without hyphenation. Here is a PHP based hyphenation library, and a port of this library to a WordPress plugin: wp-Typography.
Like any web design question... it depends. As has been suggested, justified text does not usually end up looking good in narrow columns. I'd recommend against it as a general rule in sidebars as sidebars are usually narrow.
With body copy at the often recommended 10 words per line (or with any amount above that) you will probably be able to get away with justified text and have it look reasonably good most of the time unless you're using a lot of really long words and/or strings.
I think I've pimped this site on StackOverflow before, but Jon Tan uses justified text in his body copy (within articles) and it looks great 99.99% of the time.
Erhh... No...!
[seriously] WordPress uses justify, and I think that's a pretty strong statement in regards to whether or not it decreases readability...
You can also use text-justify:newspaper. The text-justify css tag helps you control how you wrap the text when you justify
Text justification can be done in several ways.
Couple of definitions: Adjusting the spacing between words is "tracking" Adjusting the spacing between characters is "kerning" Good layout programs do some kerning automatically, and it varies by letter pair. The va of variable can be kerned closer than the xa in exact. Good fonts have built in tables of kerning hints to aid in this process.
In early days of monospace fonts it was done by inserting extra spaces between words. This made for very clunky looking output. If you had 4 spaces at the end of the line, and 6 spaces in the line, 4 of them would become double spaces.
Monospace fonts shouldn't be justified.
With variable width fonts, we have em spaces, en spaces, etc, and so the space could be better distributed.
I think this is where most browsers are now. It works reasonably well most of the time. For it to work well the following conditions need to hold:
You need a reasonable number of words on a line.
A large word at the end of the line can make problems.
The average word in English is 5 characters. So on the average you will have 5 characters (the 5 character word plus space wouldn't fit so gets bumped to the next line)
If you have 10 words on the line, then you need to add about half a standard space to each interword gap.
If the last word is a long one, like "headaches" and there isn't room for it, now you have 10 spaces to distribute. This starts to look bad.
This is where a hyphenation dictionary comes into play. Hyphenation can be done by algorithm, but there are enough exceptions that having a dictionary helps a lot. (There is a special character for soft hyphens for words not in your dictionary.)
Hyphenation can split a word so that the the line fills more evenly.
Empirically I decided that a 65 em line length made a good compromise. This gives 11-13 words per line a lot of the time.
Another approach to justification is to split the space up between characters. This avoids some of the problems above, but still looks odd if you are distributing a lot of space in not enough line. You see this in newspapers now and then where a word seems to have a full space between each character. This is a good argument for a longer line.
Good typesetting programs (InDesign, *TeX, Framemaker) do a combination of extra space in interword gaps, and tiny extra spaces between characters.
There is a new kid on the block, text-justify that can be used in CSS to modify the use of text-align: justify. Nominally it accepts the options
auto (default)
interword
inter-character (+ distribute for legacy reasons)
none
CanIuse https://caniuse.com/#search=text-justify
CSS working group https://drafts.csswg.org/css-text-3/#text-justify-property
CanIuse reports compliance only for Firefox right now, Chrome supports it but requires that you enable experimental features. CanIuse claims that support is buggy. Going to the Chromium bug tracking site, claims that it's fixed. Go figure. Haven't tested.
Other pragmatic points:
I made four changes to my site's style sheet:
Maximum line length of 65 rem
body font increase to 110%
leading increase to 125%
Justified text.
The result was that time on site and pages per session doubled.
Anecdotal, but may be worth your own test.
I think it is perfectly OK on print, but it is clunky on most Web browsers, by lack of fine control of spacing and hyphenation. Typographers can even play slightly on letter spacing or font contraction in some cases, as pages/columns (at least in magazines) can be finely tuned.
It should be mentioned that Internet Explorer (at least) up to version 8 does not render text-align: justify correctly. Instead it is interpreted as text-align: center.
Here is more info: text-align: justify
Caused me some headaches to find out why IE kept centering stuff. Maybe it saves somebody else some time.