DevKick Forums - Beta Feedback

Re: Beta Feedback

2008-06-12T12:03:56Z

Just noticed that having [code]html {background:#FFF;...[/code] in the RESET sort of "pulls down the pants" in Safari and Firefox on Mac on pages that are shorter than the viewport. What happens is, the background of ".content body" only shows down to where the page content ends, after that the "body" seems to end as well, and the white background defined for "html" begins. Don't know why this is, but taking out this one parameter (background:#FFF;) fixes the problem.

Re: Beta Feedback

2008-05-16T05:39:41Z

OK, I can see a possible "problem". Try this one on the Tripoli Sample Page: Inside the fieldset, add a heading (any level) after the fieldset (a real-world example: a survey, where the question is very large and cannot be used as legend, because large legends doesn't wrap, they are always single lines and break/expand fieldset bounds). So: [code]

Tripoli Survey

What do you think about Tripoli, a CSS standard for HTML rendering?

base

[/code] (of course, first, we will have to agree if having a heading there is a common/good/semantic practice or not) Check it on FF & IE6/7: it renders the same across the three. Cool. Now, try this (the same, but legend is hidden): [code]

What do you think about Tripoli, a CSS standard for HTML rendering?

//options...

[/code] (of course, again, first, we will have to agree if having a heading there and also hiding the legend is a common/good/semantic practice or not) It renders differently: on FF, the

still has the margin-top (because it isn't the fieldset's first-child). But on IE6/7 it renders without the

margin top. Probably better than having a heading inside the fieldset (and after the legend), it is to have it outside the fieldset, or having a paragraph in place of the heading (also, inside the fieldset). Like this (heading outside): [code]

What do you think about Tripoli the CSS standard for HTML rendering?

// options...

[/code] Or this (paragraph inside): [code]

What do you think about Tripoli, a CSS standard for HTML rendering?

// options...

[/code] Again, because using a large text for legend will expand the fieldset bounds, putting the question on the legend isn't an option. So, between having it inside/outside as a heading, or inside as a paragraph, I would choose the last option: the paragraph seems to be a very semantic way to put the survey question. The problem is then, to choose a good text for legend.

Re: Beta Feedback

2008-05-16T04:46:57Z

Now, I'm seeing another possible issue: [code].content fieldset>*:first-child { margin-top:0; }[/code] If --as you said (and I still believe you ;))-- every fieldset requires(*) a legend (so I suppose the legend shall be the first chield of the fieldset), then that rule wouldn't make sense. Because it's saying: "for all fieldset children that are the first-child", and that only can match one child, because just one child is the first-child. And if legend is required (and if legend is first element inside fieldset), so legend always becomes the first-child. Right? Of course, the rule is totally valid if you want to remove margin-top for legend (although there is no margin set for legend on tripoli.base, so no reason to remove it) *: yes, it does require it, as you said, in HTML, but not in XHTML

Re: Beta Feedback

2008-05-15T14:15:45Z

Hi David, I didn't know every fieldset *requires* a legend. I've been looking some info about that on the web, but couldn't find it yet (yeah, a lazy search I did) Of course, I believe you. And the fact that Tripoli advocates to best practices and valid code is very important. I can confirm that if a legend is present, the rendering is consistent across browsers (tested on FF, IE6/7). As said on my original post, if legend isn't present, IE7 renders differently (no padding top). Can't find why IE6 also doesn't remove the top padding, considering the ".content fieldset {padding-top: 0}" on tripoli.base.ie.css should apply to both IE6/7. Any ideas? So, let's go back one second to Tripoli Alpha generic.css. There we had: [code].content fieldset { padding: 0 1em 1em 1em; margin: 1.6em 0; }[/code] That rule was applied to every browser. That rule rendered more consistently *even if legend wasn't present* (although, as you said, this is not valid HTML). But now, consider this scenario: a legend *is* present (so the code is valid), but for design reasons, it is hidden/removed from rendering (usually using a display:none, because position:absolute;left:-9999px -better for accessibility- doesn't work pretty well on legends across browsers). So, again, in this scenario, our legend is present in the code, but hidden from rendering via CSS. If we apply the rule on Tripoli Alpha generic.css, the render is consistent across browsers. But if we apply the rule on Tripoli Beta tripoli.base.ie.css, the render is inconsistent across browsers. David, do you think this reasoning makes sense? Does it convince you to get the padding-top back for IE? :) Thanks in advance and excuse my english.

Re: Beta Feedback

2008-05-12T21:46:43Z

Here are some answers to your questions: —–----------- 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 the next version.

Beta Feedback

2008-05-12T21:45:15Z

Another blog comment from maniqui: ------------------------------------------------------- on May 10th, 2008 e, 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: [code] /* \*/ html { font-family:sans-serif; } /* */[/code] And this [code] /* \*/ .content legend { padding-left:.8em;padding-right:.8em;} /* */[/code] 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/Abbreviation So, 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: [code] * html .content blockquote * { margin:.8em 0; }[/code] 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: [code] * html .content blockquote * { margin:.8em 0; } * html .content blockquote * * { margin-top: 0; margin-bottom:0; }[/code] (A fake child-selector (>) IE6-compatible) http://bitesizestandards.com/bites/using-the-universal-selector * This rule (removed properties for clarity): [code] * html input { … }[/code] 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.