Posted on Thursday, May 8th 2008 at 19:08
Tripoli Beta
17 comments so far | Digg | del.icio.us
Tripoli, the generic CSS standard for HTML rendering, have reached the Beta stage. By resetting and rebuilding browser standards, Tripoli forms a stable, cross-browser rendering foundation for your web projects.
So, what’s new in the beta?
There are many new things in Tripoli. I have listened to the public voices from people using it in real world projects during the last 6 months and the result is even more stable, generic and dynamic. Here’s a quick run-down:
- no more print styles
- a brand new layout plugin
- more ways of implementing Tripoli to simplify installation
- hundreds of tiny corrections since the alpha
- even less specific styles in the base component, expand tripoli as far as you need
- the heavy IE expressions in the late alpha has been removed for better performance
Tripoli is the same as before, only much better and more dynamic. If you are using tripoli today and would like to upgrade, you should be able to do so without any major issues.
Read more and try it out in the Tripoli project page. If you are new to Tripoli, you might want to check out two earlier blog posts as the project was initiated: Introducing Tripoli and Tripoli Beta in Development
Leave a Reply
17 Responses so far.
-
At 2:42 pm on May 9th, 2008 , neondragon wrote:
i have used it before and i have only good comments
-
At 7:19 am on May 10th, 2008 , Maniquí wrote:
Hi. Congratulations for this new release! There seem to be many changes between the alpha release and this beta.
So, I go straight to the feedback, the things I like and the things I don’t.* Why did the the print stylesheet have been removed? Or have it been merged somewhere? (”making the HTML look great in several medias, including screens, mobile browsers and prints”quoted from Tripoli project page)
I think it was a great idea to also have a Tripoli stylesheet for printing.* I can understand the benefits of having less files (less files requests, and probably, less total size). But also, I liked the approach of having reset/generic/ie.css. It was pretty clear and straightforward of implement and understand.
I must admit I haven’t started to play with this new beta, nor i’ve upgrade the project were I was “training” myself on Tripoli. I’m just thinking loud about this things.* About hacks on tripoli.base.css
This:
/* \*/
html { font-family:sans-serif; }
/* */
And this
/* \*/
.content legend { padding-left:.8em;padding-right:.8em;}
/* */Why there are some hacks on the base CSS?
If they are ¿IE? (¿IE Mac?) hacks (can’t remember), why aren’t they on the IE-specific CSS?* I was about to suggest you to remove the “.content” from all “a” elements so you can have some styled links even if they aren’t inside a block class “.content”.
I believe this is what you did at the end of visual.css.
Why not move that set of rules to the base stylesheet?* This comes from the alpha release: why is abbr being transformed to uppercase? Is this a common practice on typography? I know there are some abbreviations that go on uppercase, like BPM, BCC, PDF and many others. But there are also some abbreviations that go on lowercase (at least, on Spanish but I think in English too: like Mr. (mister) Dr. (doctor), St (street), etc).
Also, it’s very probably that if someone use an abbreviation like BPM, PDF, etc, the user will write it directly in uppercase, and I think it’s correct to write it in uppercase, and not like css, bpm, pdf, and if “it’s not correct”, at least, it’s what most writers does: to write BPM, PDF, CSS, HTML, whatever. The same goes also for mister, street, philosophiae doctor: when abbreviated, they are writing capitalized, but not uppercased, nor lowercased.
http://en.wikipedia.org/wiki/AbbreviationSo, in other words, I’m just suggesting to remove any text-transform applied to abbr.
* I know you are working hard on this, but a little more documentation added to hacks and IE rules probably would have helped me to avoid asking this questions, and you to avoid answering them. ;D
* On tripoli.base.ie.css:
This rule:
* html .content blockquote * { margin:.8em 0; }
will apply a top/bottom margin to all the children (and children of children). Although top/bottom margin usually doesn’t affect inline elements (left/right margin does affect), that rule will apply to all block elements inside other block elements (inside blockquote, of course).
So, I would like to suggest to do it this way:* html .content blockquote * { margin:.8em 0; }
* html .content blockquote * * { margin-top: 0; margin-bottom:0; }(A fake child-selector (>) IE6-compatible)
http://bitesizestandards.com/bites/using-the-universal-selector* This rule (removed properties for clarity):
* html input { … }
Doesn’t it have too much specificity if I want to override it for IE6 directly from a stylesheet loaded before the ie-specific one?
I may be missing something here (I’m fallen asleep, can’t think clearly about this point)* the *.simple.css versions are a good extra gift. Thanks! But for small sites I may probably keep the full versions even on deployment.
They are pretty clear and readable.* Since I started using Tripoli, I’ve imposed myself a rule: don’t make your changes directly on Tripoli files. Override them with your own stylesheets. You will be thankful on next Tripoli update, I think. Of course, this adds overhead, but think in yourself and your time too.
Well, I think this is all by now. I’ve to start playing with these release and even upgrade it on the project I was using it.
Thanks again, David!
-
At 9:18 am on May 10th, 2008 , Maniquí wrote:
Appendix:
I liked the styles applied to blockquotes on Tripoli Alpha:
blockquote { border-top: 1px solid #ccc; border-bottom: 1px solid #ccc; color: #666; }
blockquote > *:before { content: “\201C”; }
blockquote > *:after { content: “\201D”; }(Maybe the border was a bit “out of scope”, but I like it too)
Regarding the new styles, in the project I’m working, the big quote before the first child was being put too far (to my taste) to the left, and even being cut.
Also, I’ve done some slight re-styling, that you may like (and added closing quote)
blockquote > *:first-child:before, blockquote > *:last-child:after /* Tripoli bonus: pure CSS blockquote */
{
content:”\201C”;
font-size:3.5em;
margin-left:-.5em;
font-family:georgia,serif;
padding-right:.1em;
color:#e0e0e0;
line-height:0;
vertical-align:text-bottom;}
blockquote > *:last-child:after {margin-left:0;vertical-align:text-bottom; }So, I still have to think what to do with blockquotes, hehe…
-
At 9:24 am on May 10th, 2008 , Maniquí wrote:
Sorry, last rule should have been:
blockquote > *:last-child:after {margin-left:0; content: “\201D”; }
-
At 6:00 pm on May 10th, 2008 , Maniquí wrote:
I’m biting my fingers just to avoid touching the Tripoli style sheets directly.
I’ve more findings on this beta, which I would consider bugs or inconsistencies, that worked better (or different, but at least, consistently across browsers) on the alpha version.
1. On tripoli.base (line 246):
blockquote { padding-left:2.2em; }
Why this rule is there and not below (on Content section), with a “.content” before it?
Without the “.content” bit, the specificity of that rule is low.In other words, if there is a rule like this:
.content ul,.content ol { margin-left:2.2em; }
Why not also this?
.content blockquote { padding-left:2.2em; }
Totally make sense, and also, for those (like me ;)) who use suicidal rules like:
.wrapper * { padding-left:2em; padding-right: 2em }
.wrapper * * { padding-left: 0; padding-right: 0 }(http://bitesizestandards.com/bites/using-the-universal-selector)
…the tiny bit of specificity added by “.content” (to blockquote, in this case) is wished gift.
2. On tripoli.base.ie (line 25)
.content fieldset { padding-top: 0; }
That rule is creating cross-browser inconsistencies. It’s only applied to IE7 and makes it look different from IE6 and other browsers (FF 2.0, Opera 9.5), which are displaying correctly.
It could be acceptable that there are some few things that look different on IE6 (and it’s expected, because Tripoli is ¿ab?using of :first-child and child selectors), but IE7 and FF should render mostly the same regarding paddings, margins and layout in general.
I know CSS and Tripoli aren’t about perfect pixel design (and even less, if working in ems), nor every page have to look the same on every browser.
Again, using child selector and :first-child for applying/removing margins and paddings will lead to this “inconsistencies” with IE6.
I’ve no doubt Tripoli could have another approach here, but not sure how could it be. I will start to think about it.So, there were some general things that looked better on alpha release. I’m making a “mental diff” to find out what has been improved and what not (in my opinion).
David, please, excuse this cascade of comments and my english.
-
At 12:19 am on May 12th, 2008 , admin (author) wrote:
Maniquí: you have some good questions. I’m opening up a tripoli forum soon, but until then I’ll try to answer some of your thoughts here:
—–
Why did the the print stylesheet have been removed?
Because it contained only two CSS lines. I’ve been working on print styles for some projects, and getting browser consistency is very difficult. And each project requires different print style priorities, so I simply removed them for this release since it didn’t really contain much CSS anyway.
—–
Why not move MSIE5/OSX hacks to base.ie
- because it would require one extra CSS rule to do so. Still, it’s not a bad idea for clarity so I’ll consider it.
—–
Why not move the anchor rules to the base stylesheet?
- the anchor styles are moved to a presentational plugin called visual. The base does not contain colors at all.
—–
Why is abbr being transformed to uppercase?
Thats a good question. Abbrevations does not have a general style guide, and magazines print them differently. I’m not really sure why they should be uppercase in the CSS unless it’s because we want some typographic consistency. The uppercase declarations should be set in the type plugin anyway, so thanks for the pointer.
—–
Why not use:
* html .content blockquote * { margin:.8em 0; }
* html .content blockquote * * { margin-top: 0; margin-bottom:0; }instead of:
* html .content blockquote * { margin:.8em 0; }
That would ruin the vertical flow inside the blockquote. You cannot just remove margins on descentant children of the blockquote, especially not using such specific rule. The “fake child-selector” is very bad practice, since it also removes properties from elements defined earlier in the cascade if they happen to be a second descendant. IF you could write something like “inherit from grandparent” it would work, but CSS can’t do that.
Basically all block-level elements in tripoli have a bottom-margin of 1.6em. But since IE6 has some limited selectors to choose from, we can set the margin to .8em 0 inside blockquotes instead. The elements will still line up in the same way, but we get the same margins from the blockquote borders.
—–
Why not use :
.content blockquote { padding-left:2.2em; }instead of:
blockquote { padding-left:2.2em; }Another good question, I’ll consider that.
—–
.content fieldset { padding-top: 0; }
in the IE styles is creating cross-browser inconsistencies.Actually it’s the opposite, that rule makes the browsers much more consistent, unless I missed something completely. It’s kind of hard to explain, but these three rules inside the IE styles work together to solve the difficult fieldset/legend rendering issues in different browsers:
.content legend{margin-bottom:1.6em;}
.content fieldset{padding-top:0;}
.content legend:first-child{margin-top:0;}But you are raising an important point. Tripoli recommends HTML and in valid HTML, every fieldset requires a legend. But the definition of fieldset in XHTML is quite loose. If you use a fieldset and no legend, tripoli will render IE and FF differently. This is the cost of effective cross-browser consistency when writing valid HTML. But I strongly recommend to have a legend for every fieldset, so I’ll leave it like this for now but it might change in thenext version.
-
At 7:30 am on May 12th, 2008 , Maniquí wrote:
Hi David, thanks for your extensive and clarifying reply to my questions. I will look to them in detail while playing with Tripoli.
A forum would be great. Go for it!
In its simplicity and goals, Tripoli is an ambitious project that deserves to keep being developed and spread as an option for website rendering, particularly (but not exclusive) for online documentation :)
May I suggest a forum flavor? FluxBB, the recently forked version of PunBB.
In fact, it could be a nice experiment to apply Tripoli to FluxBB and see how it looks :D-
At 9:35 pm on May 12th, 2008 , neondragon wrote:
hm, i have been working on my print css stylesheet framework, and i would like to see as a part of something like this. interested?
-
At 10:16 pm on May 12th, 2008 , admin (author) wrote:
@neondragon: sure, please visit the forum and post your ideas.
-
At 9:00 am on May 13th, 2008 , Demian wrote:
This is great! I’ll start using this right now. Curiously, I had a similar idea some time ago, but never worked on it. Regards.
-
At 4:36 pm on May 14th, 2008 , Ben Hayes wrote:
Really useful and interesting stuff.
I have a comment about line height. I often like to get line height consistent across different types of elements to keep a regular vertical rhythm. So if line-height is 18px then it is nice to have it 18px for both h2 and p, for example. I notice in your base CSS file you end up with a line height of 19.2px for paragraphs but 18px for h2 (for example).
I’ve found it quite good to set line-height separately for all elements like this:
.content { line-height: 1.8em; }
But then set font sizes separately on individual element types. Of course you have to be careful setting margins to make them proportional.
-
At 11:40 pm on May 22nd, 2008 , trice33 wrote:
Hello,
just wanted to let you know, that I’ve been using Tripoli already very successful in two projects and it has been speeding up my work a lot/making my life hell a lot easier.
Thanks man—I owe you one!
5 Trackbacks & Pings:
-
Trackback at 7:14 pm on May 8th, 2008 by Tripoli Beta | David’s kitchen: […] Beta was released today. More about the beta in the blog post at […]
-
Trackback at 12:28 pm on May 12th, 2008 by Tripoli - Einheitlicher, erweiterbarer CSS-Standard für alle Browser - Peter Kröner - Die Kunst des Machbaren: […] könnte Tripoli Abhilfe schaffen, das kürzlich Betastatus erreicht hat. Es handelt sich dabei um einen Stylesheet, der die Darstellung auf allen Browsern von IE5 bis FF3 […]
-
Trackback at 8:43 am on May 13th, 2008 by Electriblog » Blog Archive » Estandarizando las hojas de estilo por defecto de los navegadores II: Tripoli: […] de hojas CSS creadas para lograr exactamente lo que comentaba en mi apunte. Recientemente Tripoli ha llegado a la fase beta, por lo que sugiero vehementemente que le echen un vistazo, las utilicen si, como yo, piensan que […]
-
Trackback at 8:45 am on May 13th, 2008 by Electriblog » Blog Archive » Standardizing default browsers stylesheets II: Tripoli: […] project, a set of CSSs created to do exactly what I have stated on my post. Recently Tripoli reached beta stage, so I strongly encourage you to take a look at it; use it if you, like me, think this is a […]
-
Trackback at 4:42 am on September 9th, 2008 by No HTML Experience Needed* (So Says SiteGrinder) « PhilSpace: […] Style Sheets.” I suggested telling his coder to start with a style reset from either Tripoli or Yahoo, and then clean up the invalid […]
