Mixins

[jcoufal]

• Rework current SCSS files so that they use Compass mixins (especially for CSS3 features).
• For future files, keep using Compass
• Create new mixin only if it is not covered by Compass library,
• Document all mixins which are available for us to use

(Compass documentation http://compass-style.org/reference/compass/)

[jcoufal]

I have a question regarding css reset. Currently we use compass/reset, but it is doing real mess in the code - lot of overwritten rules by the same ones (e.g. inspect input field at http://convergeui-ehelms.rhcloud.com/form). I suggest not using reset and style elements by us.

[ehelms]

I have had similar concerns over the use of reset.css and recently learned about normalize.css [1]. We should probably take the time to enumerate the pros and cons of reset vs. normalize vs. custom in the context of the work that is on going towards certain components. And make our decision based off that.

[1] http://necolas.github.com/normalize.css/

[andyfitzsuse]

The only reset that is truly worthwhile is *{-prefix-box-sizing: border-box;}

Well no doubt set height width padding margin text indent float line-height and list style for all objects as we com across them.

This is why resets exist first The idea is that you clean up the generic conflicts after everything is specified. Basically we will end up crafting our own defaults and coding style so copy pasting someone else's reset isn't worthwhile. It's just another layer of confusion until we really understand our code,

On 26/08/2012, at 2:18 PM, Eric D Helms notifications@github.com wrote:

I have had similar concerns over the use of reset.css and recently learned about normalize.css [1]. We should probably take the time to enumerate the pros and cons of reset vs. normalize vs. custom in the context of the work that is on going towards certain components. And make our decision based off that.

[1] http://necolas.github.com/normalize.css/

— Reply to this email directly or view it on GitHub.

[tzumainn]

Moved to https://github.com/Katello/converge-ui/issues/57

Hi,

I was wondering if it would be practical to have requirements-level documentation published somewhere for the great amount of converge-ui work coming up. It would ensure that everyone was on the same page, and also give a good starting point for outsiders like myself to find answers to questions, and possibly raise concerns.

For example, on Friday, Andy showed some really nice tab navigation, and true to my contrary nature, I spent five minutes figuring out how to ask where the subnavigation would go (I had thought that the tabs would be dropdowns). He was kind enough to explain the answer to me, but I'm guessing it would have been easier for everyone involved if I had been told to RTFM.

I don't think it would have to be anything too detailed; something along the lines of the text here, without the HAML on top:

http://convergeui.readthedocs.org/en/latest/resources/layouts.html

I dunno, what do people think?

Thanks, Tzu-Mainn Chen

[jcoufal]

+1 for normalizr, from my point of view it's much better (less code, still doing its job)

[jtomasek]

I had a nice experience using Normalize.css. It manages to clean the browser differences very well. Anyway I still had to use some small reset rules as *{margin: 0; padding: 0} etc. So I'd prefer this combination...