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.
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.
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.
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.
I'm currently struggling with implementing text floating in TLF. It does not support it natively, and the only solution I've found so far is to use linked containers and then combine controllers using flowComposer for single textFlow.
However, I need to implement Dropped Initial letter feature in my column layout. Initial is just a first big letter in paragraph, floated by the rest of the text. It looks like this -
The issue here is that for that big letter, the resulting TLF textFlow sprite is bigger than the actual letter. It's because of the baselines (small q vs big A for example). But I don't want these extra gaps. After textFlow is rendered, I would like to learn how big the resulting letter exactly is (in pixels) so that I can crop/shift baseline, etc.
ContainerController.getContentBounds().height or
ContainerController.compositionHeight
gives me height of whole sprite with gaps added, not the letter.
Is there some kind of measure method for this?
Can this be solved differently?
check out the Tiny TLF framework by Paul Taylor. I think he addressed this issue along with many other cool things.
Check it out: https://github.com/trxcllnt/tinytlf
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.