Grid output style API about singularity HOT 29 CLOSED

Agreed. I was actually just thinking of vw/vh based grids.

from singularity.

pushed new branch. totally broken but on its way: https://github.com/scottkellum/Singularity/tree/Grid-output-API

Two mixins, grid-structure-shared and grid-structure. One holds shared components and one will write all components when called. New mixins down the cascade will override these mixins meaning plugins can take over these components.

Again, totally broke it but no time to fix right now.

related to issue #40

from singularity.

I've got all day today to work on this and by George, I'm going to!

from singularity.

Will take a look!

from singularity.

Forked to new branch for a fresh start: https://github.com/scottkellum/Singularity/tree/grid-output-api

edit: not finished yet!

from singularity.

I'm going to work on this and move it up to 1.0 as I really want this for 1.0

from singularity.

I've got this 99% working; only thing that isn't working is percentage gutters for float. Take a look.

from singularity.

Cool, I am working on it as well, will push to new branch and check the dif

Yes, this is a must for 1.0

from singularity.

Getting errors on your branch, did a lot to balance things in my branch, still a little messy https://github.com/scottkellum/Singularity/tree/grid-output-api-sk

EDIT: taking a break for a bit, feel free to dig in but let me know when you are digging in. I have been watching all the test examples as use cases very a ton with Singularity.

from singularity.

Can you post your errors? I wasn't seeing any (I didn't do a visual check to make sure everything was actually working, just a CSS check)

On Oct 28, 2012, at 6:31 PM, Scott Kellum [email protected] wrote:

Getting errors on your branch, did a lot to balance things in my branch, still a little messy https://github.com/scottkellum/Singularity/tree/grid-output-api-sk

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

from singularity.

Yeah, I have been working the same way. These are the erros I am getting:

>>> Change detected at 20:18:52 to: output-api.scss
identical example/css/container.css 
overwrite example/css/grid-span.css 
overwrite example/css/gridset.css 
overwrite example/css/micah.css 
    error example/sass/oocss-responsive.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oocss-responsive.css 
    error example/sass/oocss-variable-padding.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oocss-variable-padding.css 
    error example/sass/oosass-responsive.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oosass-responsive.css 
identical example/css/output-api.css 
overwrite example/css/rtl.css 
overwrite example/css/scale.css 
overwrite example/css/test-grid.css 
overwrite example/css/zen-iso.css 

from singularity.

I'll backtrace that in a bit, but I believe the error is coming from a renamed mixin.

On Oct 28, 2012, at 8:20 PM, Scott Kellum [email protected] wrote:

Yeah, I have been working the same way. These are the erros I am getting:

Change detected at 20:18:52 to: output-api.scss
identical example/css/container.css
overwrite example/css/grid-span.css
overwrite example/css/gridset.css
overwrite example/css/micah.css
error example/sass/oocss-responsive.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oocss-responsive.css
error example/sass/oocss-variable-padding.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oocss-variable-padding.css
error example/sass/oosass-responsive.scss (Line 9 of stylesheets/singularitygs/mixins/_grid-objects.scss: Undefined mixin 'structure-common'.)
overwrite example/css/oosass-responsive.css
identical example/css/output-api.css
overwrite example/css/rtl.css
overwrite example/css/scale.css
overwrite example/css/test-grid.css
overwrite example/css/zen-iso.css
—
Reply to this email directly or view it on GitHub.

from singularity.

Yeah, I was dealing with that error a bit as well. Fixed by using a universal default: scottkellum/singularity@2f81bbf

from singularity.

What is grouped-styles? I saw that in there, didn't quite understand it, so wound up taking it out.

from singularity.

There are two parts to the API, one mixin with shared styles called structure-common, another with unique styles called structure-section.

With the grid-span mixin, both structure-common and structure-section are written. With grid-objects structure-common styles are grouped and structure-section only writes the necessary styles.

It is important to know when common styles are grouped together, like in grid-objects, so that default margins and floats (margin-right: -100% and stuff) can be written and overridden as needed on a per-column basis.

We could ignore this and let gzip do it’s magic. I am most concerned about getting into CSS grid-layout stuff and re-writing the entire grid layout for each column.

from singularity.

So take a look at what I've done, I've built it out ever so slightly different.

I've got structure-shared that includes the box sizing, width, and padding. Then I've got structure-isolation which is the margins and floats, and structure-float which is the float and "standard" margin (aka not the -100%, x% stuff). In this way, we don't overload a single structure mixin with every possible output for each of our different outputs.

from singularity.

hmm, sorry not really as flexable as I was envisioning.

I totally removed use of structure-float mixin (or anything referencing floats) in favor of the two generic mixins. This frees up Singularity to support overriding of these mixins at any point. For example, when I was working on my branch I could work on the mixins from within the example files and then move them to core after they were finished. Using the API to make the API. This is why I abandoned the structure-float mixin and commented out the other structure includes. Now, if you want different output you can just include another structure that comes with Singularity or easily build your own and override an existing one. You can even override the mixin half way through your cascade if you want to use two output styles in the same project for some reason.

Have you dug into my latest branch? Any issues with my approach or reasons we shouldn’t go with my branch?

from singularity.

Honestly, I think that there is much too much going on in structure-section and it doesn't address the concerns properly; specifically the $grouped-styles doesn't fully make sense to me and the shared margin-right isn't actually right (for simple floats, you don't want location+gutter, you only want gutter). I also think that width is something you'd want to put into common.

I also firmly believe (as it's something I currently want to do) that you'd want to use a mix of the two options on a given project. Because of this, I really like the solution I came up with as each structure can be contained in its own mixin instead of spaghetti-ing it into structure-section and being able to use it is adding a simple if statement to grid-build.

In short, easier to write a separate mixin and override grid-build than to try and add your own stuff to what's already in structure-section and making sure nothing breaks in what we've already got.

from singularity.

Good points and I think we are debating the points of semantics rather than structure.

Curious how width is shared as it varies in every instance while margin-right is the same for almost every instance.

Still, my concerns are regarding having “float” stuff called in core. If the language can be cleared up so generic mixins can be passed through core it would be awesome. Weather it is 3 specific mixins or 2 context aware mixins we should be good.

from singularity.

They're actually very different.
In Zen Grids mode, what I'm calling isolation, it's total columns before + gutter. In Susy mode, what I'm calling float, it's just gutter. I say float as that's the most defining feature of the Susy style grids. display: table based grids could be called table, viewport unit based grids could be called "viewport", etc…

As for width, width is, IMO, a common component as the width is always going to be percentage based and always going to be border-boxed. Unless we decide that we're going to allow for fixed width grids (which you can do with containers)

from singularity.

haha, whoa, yeah we are talking about totally different things and ways of seeing this, I think.

Lets focus on Zen Grids for now.
common styles meaning they have the same value across all/most columns (1):
float, zoom, margin-right, clear

Styles that change at different points (2):
width, margin-left

THEN we have styles that are generally the same, but change depending on where you are (3):
margin-right, clear, float...

You can either write three mixins or two mixins where (3) is written depending on if the styles are grouped or not.

This is for Zen style ONLY, not Susy, not table, not grid layout.

IF you decided to do somthing totally different, like Grid Layout then no, you would not define width for (2). You would define the grid for (1) and where on that grid for (2). For CSS Grid layout there would be no conditions for (3)

Shared styles are NOT attributes common across multiple grid systems but values shared across the grid for a single grid system.

Hope that clears it up.

from singularity.

Maybe we can have a quick skype call.

from singularity.

Would love to, but no power. When I do we shall.

On Oct 29, 2012, at 4:39 PM, Scott Kellum [email protected] wrote:

Maybe we can have a quick skype call.

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

from singularity.

Okay, so I'm going to take look at your code today and see if I can't combine the two ideas. I disagree that we shouldn't include a Susy style for launch, mostly because I'm in a position where I very specifically need it right now. I think I'm going to fork off of your branch to do it.

from singularity.

Also, I still don't fully grok $grouped-styles. Can you explain what it's for a little bit better.

from singularity.

So here's my updates, haven't fully tested yet, just to give you an idea of what I'm thinking of with your stuff and my stuff both in there:
https://github.com/scottkellum/singularity/tree/gird-output-api-sr

from singularity.

Never said we shouldn’t include Susy style, just trying to clearly illustrate how the API works. Susy has no place in the current structure-float partial. If we plan on including both then maybe we should break float into float and zen partials.

Each partial in grid-structure is a different output model. There shouldn’t be any overlap in the current architecture.

I think your approach is an attempt to somehow combine things like Susy and Zen styles but this is only going to lead to big problems with new grid structures that don’t involve floats. The API needs to be totally agnostic.

Still want to skype on this?

from singularity.

Yes I do, and I don't think we're going to have the problems that you think we are going to, especially with the way I've just rewritten the float/isolation stuff. We should Skype about this, I'll be free in like 1.5 hours. and then most of the day thereafter.

On Friday, November 2, 2012 at 10:15 AM, Scott Kellum wrote:

Never said we shouldn’t include Susy style, just trying to clearly illustrate how the API works. Susy has no place in the current structure-float partial. If we plan on including both then maybe we should break float into float and zen partials.
Each partial in grid-structure is a different output model. There shouldn’t be any overlap in the current architecture.
I think your approach is an attempt to somehow combine things like Susy and Zen styles but this is only going to lead to big problems with new grid structures that don’t involve floats. The API needs to be totally agnostic.
Still want to skype on this?

—
Reply to this email directly or view it on GitHub (https://github.com/scottkellum/Singularity/issues/36#issuecomment-10021731).

from singularity.

Reviewed, looks really good.

from singularity.