Cascade Framework

[Matthew Browne]

Hi all,
I thought it was worth creating a new thread about John's Cascade Framework, since there's been a good bit of discussion about it...

The framework looks very nice, but I just wanted to let you know that when I tried to browse the site (http://jslegers.github.com/cascadeframework/) on my Android phone, the navigation button didn't work, so I was only able to look at the grids documentation. I'm now checking out the rest of the framework on my computer and will let you know if I have any other feedback.

Thanks!

[iDGS]

Yep. As the old saying goes, "'Different' is not 'the same.'" So, as a Mac-based web developer, I've learned the hard way to test even simple HTML & CSS stuff that ought to simply "just work" (LOL!) using the Android SDK virtual device emulators. (Yoda voice:) "Gotten many a suprise, have I."

Here's a "toe in the water" link for anyone interested: http://developer.android.com/tools/devices/emulator.html

[John Slegers]

Hi Matthew,

Thank you for your feedback and thread.

I'm aware of the issue with the menu on Android.

Unfortunately I've been quite busy and haven't had the time to fix the issue yet. 

Feel free to play around with it and try to fix it yourself in the meantime if you think you can. 

Cascade Framework is a one-man project so far, so any community support would be appreciated.

Kind regards,

John

Op maandag 1 april 2013 15:38:01 UTC+2 schreef Matthew Browne het volgende:

[Nicole Chung]

I use the emulator on Browserstack but for Android devices I find it's not always accurate (which is terrible!). Sometimes the layout looks totally different from what you see on a device.

The best way is to plug in your android device into your computer and enable remote debugging, see reference:

https://developers.google.com/chrome-developer-tools/docs/remote-debugging

To make it work you have to have the android SDK installed (note: this is a big download):

http://developer.android.com/sdk/index.html

Once you get that all installed, plug in your device (follow the instructions on settings because you have to enable USB debugging in your "settings" AND the Chrome browser), then type into your console:

adb forward tcp:9222 localabstract:chrome_devtools_remote

Then on your desktop/laptop, open Chrome and go to:

localhost:9222

This will allow you to use the web inspector to see your css and debug your javascript AS your device sees it.

Hopes this helps people.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matthew Browne]

Hi John,
I don't have time to troubleshoot it right now, but earlier you asked about emulators....here's a link with instructions on how to use the Android emulator:
http://developer.android.com/tools/devices/emulator.html

I do have one other bit of feedback, but first of all I want to say great job! It's especially nice that the documentation is so complete.

My feedback is that the grids seem to require more markup than the OOCSS grids....I'd prefer not to need so many div tags. Why is the "cell" class implemented with a margin rather than with padding? If it used padding then the "cell" class could go on the same div as "col". I'm guessing this probably has something to do with your philosophy on how cascading should work, but it's not clear to me.

Thanks,
Matt

--

[John Slegers]

Thanks for the tip.

I'll look into it as soon as I find the time.

To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented-css+unsub...@googlegroups.com.

[John Slegers]

Hi Matt,

Check out Chris Coyier's article Don’t Overthink It Grids for my inspiration for the "cell" class.

The main advantages of how the "cell" class is implemented, are these :

• It allows for a consistent gutter across your web page that can be overruled with one single CSS rule
• Because it uses a seperate div, you only have a gutter when you need one
• The "cell" class should have a "margin" rather than a "padding" because of where the border would appear if you give your "cell" a border. You want your border to appear inside of the gutter rather than outside of it. Check out eg. the demos for the "panel" component as an illustration.

[Matthew Browne]

Nice article, thanks for the link.

Ok, I think I understand the advantages of the "cell" class now. But the framework could still be used without it, right? It seems to me you could have some other class (e.g. "with-gutter") that could be added to "col" divs (perhaps even to the container for the row, which could be overridden on a per-column basis if needed).

I suppose I could get used to the extra divs but it might encourage adoption if people realize they have options. If you think my above suggestion is viable then I could write a paragraph about it that could be added to the documentation. The documentation could still encourage using the "cell" class as the recommended approach.

Also, one other thought (I would suggest this for OOCSS too except it would break backward-compatibility): how about naming the classes "width1of2", "width1of3", ... instead of "size1of2", "size1of3", ...? That way if you added a "stack" object (for stacking items vertically), you could have "height1of2", "height1of3", ... I guess the "size" classes could work just as well though since you could make them specific to whether it's a grid or a stack...it's just an idea.

On 4/10/13 10:29 AM, John Slegers wrote:

Hi Matt,

Check out Chris Coyier's article�Don�t Overthink It Grids for my inspiration for the "cell" class.

--

You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

[John Slegers]

I sent my response to you by accident as a private message / email rather than a public response.

I can't find the message anywhere. Would you be so kind to send it back to me, so I can post it publicly?!

Op woensdag 10 april 2013 18:59:08 UTC+2 schreef Matthew Browne het volgende:

To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented-css+unsub...@googlegroups.com.

[John Slegers]

Matt,

Thank you for sending back the message I sent to you.

I'll repost it publicly below.

Cascade Framework supports two popular grid techniques :

• One is the so-called "semantic grid" technique, which was popularised by The Semantic Grid System. This technique consists of using semantic "section", "aside", "header", "nav" and "footer" elements in your markup and adding a minimal amount of semantic class or ID based styles to define your layout. While it requires custom CSS styles, it allows you to keep your HTML markup minimal. The way to do with with Cascade Framework is explained here. Note that using "section", "aside", "header", "nav" and "footer" elements requires the use of a JS based polyfill for old IE.

• The other is the so-called "presentational grid" technique, which is used by Nicole's OOCSS project, Twitter Bootstrap and most other CSS frameworks. This technique consists of using "div" elements with one or more additional generic presentational classes to add grid specific behavior and define the width. While it reduces the amount of custom CSS styles to an absolute minimum, it does add extra bloat to your HTML markup. The way to do with with Cascade Framework is explained here.

Both techniques can be combined.

While I do recommend the extra div with the generic "cell" wherever you need a gutter regardless of which technique you prefer, it is optional and could be replaced by semantic class or ID based styles. I do not recommend it, because you will need add a gutter in your custom CSS to every part of your layout where you desire it.

Leaving out the extra "div" entirely and using a "with-gutter" class on its container element will get you into trouble because of the different way different browsers handle margins and padding. Using "box-sizing:border-box" could fix this issue, but I will need to test how exactly this impacts the grid in different browsers as it is not supported by IE<8 and I'm not yet willing to drop support for those browsers just yet.

The framework does not include "heightXofY" classes because I'm not sure how to implement those. Setting the height of a container element to a percentage based height is tricky. Also, for responsive websites you usually want your height to adjust to the content rather than set a fixed height. 

Still, I'm willing to consider adding percentage based heights to the framework if I can find a decent example of how to implement them. If you know any implementations you like, feel free to point them out to me.

Kind regards,

John

[Matthew Browne]

Hi John,
Thanks for the clarification. I'm going to set aside the semantic grid option for now, which is a good option for many situations of course (especially the overall layout/template), and focus on presentational grids.

Let me back up a bit...when I first did a "View Source" on the Cascade Framework page for presentational grids, my first thought was, "Wow, that's a lot of divs!" Then I realized that some of those divs were for the panel surrounding the examples...silly me! So one simple improvement could be a button or tab to view the code for a specific example in the documentation, which I assume you just haven't had time to implement yet - very understandable.

As to the "cell" divs, I knew that the OOCSS framework seemed to have some default padding on grids but had forgotten how this was implemented. Looking at the code, I see that it wasn't padding on the grids at all, but rather the default margin on headers, paragraphs, etc.:

h1, h2, h3, h4, h5, h6, ul, ol, dl, p, blockquote, .media {

    margin: 10px;

}

I see that " stefsullrew" contributed a version of grids with gutters (grids_gutter.css), but as you pointed out, this is only possible by using the box-sizing property, which breaks compatibility with IE<8.

So I can see better now why you recommend the "cell" divs, but I still think it would be good to clarify that they're optional. Using the OOCSS approach (default margin on headers, paragraphs, etc.) allows you to have a default gutter, and then you can add the "cell" divs anytime you need additional spacing.

But I suppose even with OOCSS you could run into issues with width accuracy (assuming box-sizing isn't an option) if you tried to add borders directly to the grid "unit"s. Come to think of it, if you want the width of a cell to be 100%, does even an inner "cell" div help with borders? I'd be interested to hear how others have dealt with these issues in the past with OOCSS.

As to my recommendation for "widthXofY" instead of "sizeXofY", it's really about being precise, and avoiding ambiguity in case you ever want to add "heightXofY" for something -- either to the framework, or perhaps a user creating "heightXofY" classes for something in their own site.

For example, a while ago I worked on a "stack" class. The design ended up changing and I didn't use it in production, so I it probably still has some kinks in it (especially for IE7 and below), but here's a link to the code:

https://gist.github.com/mbrowne/5373439

Here, I myself used inner divs to create a default gutter :) (the "box" divs in my example). It seems to me that it should be possible to achieve the same result without the "box" divs (if all elements inside it had the same default margin, as described above), but I think the box-sizing property is a necessity for fully accurate heights if you want borders.

[John Slegers]

Hi Matt,

I've been a bit too busy lately to look into all of your suggestions.

I'll look into them as soon as I find the time for it.

Meanwhile, you can take a look at http://coshg.org/ . It's the first client website I built using Cascade Framework.

It's but a very simple website, but it still might be useful as an example of how to use the framework.

[Matthew Browne]

Thanks, that's a useful example.

[John Slegers]

If Cascade Framework still isn't lightweight enough for you, there's now also a light version with 2kb in total.

If you just need the grid code, it's only 323 bytes!

You can check it out at http://jslegers.github.io/cascadeframeworklight/ .

[Matthew Browne]

Hi John,
Nice work.

I recently used the full version to create a documentation site and am in the process of using it to build a real site.

Personally I don't like having to put the .cell divs all over the place, so I added a default gutter to some common elements like the OOCSS framework does. I added a few things beyond what OOCSS does (code below) to make it easy to apply or disable the standard gutter easily - for example, if you want a standard gutter around elements that don't have it by default, you can wrap them with a .std-gutter div.

The only thing that doesn't quite line up correctly is lists - <ul> and <ol> end up not being quite aligned by default; the best I've been able to do for now is to give them different left margin values.

Any ideas from OOCSS framework users on a better method to make <ul> and <ol> have the same left margin by default?

Of course, IE7 only has something like 2% market share these days, and it won't be long before box-sizing:border-box (or -moz-box-sizing, etc.) will work for virtually all users, eliminating the need to use inner margins instead of padding on the container.

There is of course no problem with the .cell divs, it's just personal preference as to whether you prefer more divs in the HTML or the need to understand/explain how the standard gutter works.


/* Put a standard gutter on these common elements, as well as any element with the std-gutter class.
   This makes it possible to have a standard gutter compatible with IE<=7 without needing to wrap every
   grid cell with <div class="cell">  (as is done in the Cascade Framework examples)
*/
.std-gutter, .panel, .media, h1, h2, h3, h4, h5, h6, dl, p, blockquote, table, address, pre, figure {margin:15px;}
/* since we're applying a standard margin, list-style-position:inside is needed to keep lists
   in alignment with everything else */
ul, ol {list-style-position:inside;}
ul {margin:0 0 9px 2.4em}
ol {margin:0 0 9px 2em}
/* immediate children of .std-gutter elements shouldn't have margins by default
   because if the .std-gutter element has children, the intent is probably not to have the margin
   applied again for child elements like h3, p, etc. listed above.
   To override this, those child elements can simply be assigned the .std-gutter class as well  */
.std-gutter > * {margin:0;}
.std-gutter > .std-gutter {margin:15px;}
/* special case for table since tables in the Cascade framework are 100% width by default and
   would otherwise not have a gutter on the right */
table {padding-right:15px;}
.no-gutter {margin:0 !important;}

[John Slegers]

Do let me know when you finish your documentation site, so I can add it to the showcase I'm planning to put on the Cascade Framework home page in the near future.

And do you have some demo code to illustrate the issue with list items? I'm not entirely sure what you mean with that.

Maybe I should have explained it better in the docs or used different semantics, but you don't need to wrap every grid cell with a div that contains the "cell". If you don't need a gutter, the "cell" class is optional. Thus, it seems to me the purpose of your "std-gutter" class is identical to that of the "cell" class.

Further, I don't think selectors like .myClass > * {} and .myClass > .myClass {} are a good idea for various reasons :

• It's not OOCSS
• It's not supported by IE6
• It makes the behavior of the children of elements with the .std-gutter class both less flexible and predictable. If you want a custom margin for child elements of an element containing the .std-gutter class and you don't want to use the .std-gutter class for that element, specificity and/or the order your CSS rules are loaded can unexpectedly impact whether or not a margin is are applied)
• Selectors containing * should generally be avoided because

• They're pretty slow
• Not giving you ANY structural or semantic information, * is too generic
• It easily makes your selector logic more complicated than needed
• It makes debugging your code in the browser more complicated than needed

For a use case like that, I would suggest one of the following strategies instead :

• Define a default for elements that might inherit a rule from a parent if you want to avoid that.
• Allow inheritance by default. Subsequently, reset the rule or set a different rule when an descendant is not supposed to inherit the rule. This is especially useful for em or % based typography, as it allows you to increase or decrease eg. the font size of an entire section of your page with a single class and easily customise further when needed.

In this case, however, you could just drop the .std-gutter > * and .std-gutter > .std-gutter selectors entirely as margins are not inherited unless explicitly defined (in which case you don't want to reset).

And yeah, it's but a matter of time before you don't need any additional elements anymore for a consistent gutter across all browsers. I'm definitely looking forward to it.

[Matthew Browne]

Hi John,
Sorry for the delayed reply.

On 7/8/13 7:21 AM, John Slegers wrote:

Maybe I should have explained it better in the docs or used different semantics, but you don't need to wrap every grid cell with a div that contains the "cell". If you don't need a gutter, the "cell" class is optional. Thus, it seems to me the purpose of your "std-gutter" class is identical to that of the "cell" class.

I realize that the "cell" class is optional; sorry, I should have been clearer. I find that most of the time a gutter is necessary rather than having columns jut up right against each other, which is why the CSS I posted previously gives common elements a gutter by default.

I got the idea from the OOCSS framework. I haven't gotten a chance to check out the new SASS version of OOCSS yet, but if you look at the grids example from the older CSS version, you'll see that there's a gutter between the columns in spite of the fact that there's no inner div (i.e. no equivalent to your "cell" class). That's because OOCSS's space.css includes this line:

/* ====== Default spacing ====== */
h1, h2, h3, h4, h5, h6, ul, ol,dl, p,blockquote, .media {margin:10px;}

My CSS for a standard gutter is similar; it just adds a few things that I thought made it easier to work with.

I added the .std-gutter class in addition to putting a standard margin on common elements like OOCSS does because I wanted to be able to add the standard gutter to any element I wanted, just as your "cell" class does. The main reason I didn't just use your "cell" class for this was my realization that if you created a div with a standard margin, chances are you don't want an additional margin to be applied again to its immediate child elements like <h1>, <p>, etc.

Further, I don't think selectors like .myClass > * {} and .myClass > .myClass {} are a good idea for various reasons

This probably won't make the idea sound much better to you, but first of all I don't care about IE6 in my case, and secondly I have a slightly better version of the standard gutter written in SASS for which I did a bit too much of a shortcut in the CSS version in my last email; here's the original (with an improvement to only set the horizontal margins to 0, not the vertical ones):

.std-gutter {
    > h1, h2, h3, h4, h5, h6, dl, p, blockquote, table, address, pre, figure {margin-left:0; margin-right:0;}
}

Admittedly this was a little complex to write and to set up, but so far I've been pretty happy with the result: I have a standard gutter by default everywhere without needing so many .cell divs.

Again, I was just trying to take inspiration from the default margins in the OOCSS framework - perhaps standard gutters for grids were just a side effect, and not the real purpose of those default margins. I'm not sure what others' mileage has been with the OOCSS default margins; perhaps it's better to just create additional inner divs as you have done with your .cell class. I'm not necessarily recommending that you make any change to your framework; I was simply sharing my personal experience with a way to avoid lots of .cell divs all over the place (assuming a gutter is usually needed).

As to the issue I mentioned with lists, it's a quirk having to do with the standard gutter, not with the Cascade framework. Since paragraphs, etc. have a standard gutter it makes sense for lists to have one too, which I accomplished with list-style-position:inside. But that means that <ul> and <ol> no longer line up with each other...but it's a minor point and I already have a workaround.

Do let me know when you finish your documentation site, so I can add it to the showcase I'm planning to put on the Cascade Framework home page in the near future

It's not very aesthetically interesting, but it does demonstrate several Cascade framework classes as well as my standard gutter (link to one of the complete pages below)...Also, I may need to password-protect this URL at some point, but I'm discussing the system on another forum so if I do that I'll re-post most of the documentation publicly. Just let me know if you list it and then if the public URL changes I'll send you the new one.

http://summersatlrei.org/docs/#/after-school-use-cases/enter-student-information

I had a little trouble getting the spacing on the left menu right for nested items, so the CSS for that is a little hackish at the moment. I'm just posting the link since you asked; I'm not sure it makes the best example for showcasing the Cascade framework. If I have better examples in the future I'll let you know.

Thanks again for a great framework. I may even abandon my standard gutter approach if I run into any other issues with it; I just wanted to share. One reason I currently favor more concise HTML in spite of the slight complexity of the standard gutter approach is for future-compatibility, since as I mentioned before, it won't be too long before IE7 is no longer a concern.

--Matt

[John Slegers]

Don't worry about the delayed time. I appreciate your input a lot ;-)

First of all, thanks for mentioning the new Sass version of OOCSS. I wasn't aware of that, then though I was moving in a similar direction. I am looking forward to compare notes ;-)

As I said, margins and paddings aren't inherited unless you explicitly define them as such. So if you define a margin or padding for the "with-gutter" class, your <p></p>, <h1></h1> or <div></div> that is a child of <div class="with-gutter"></div> don't inherit its margins and padding unless you explicitly said they should.

In the upcoming Sass version of Cascade Framework, I'll probably use configuration parameters to let developers and designers define which padding and margin to use for their ".col", their ".cell" and other classes by default. Once there, this discussion becomes kinda moot :-)

With regards to your website, it does look very simple indeed... yet it could be a perfect illustration of the framework's potential as a replacement of Bootstrap for this type of simple documentation pages once you get the bugs out of it. Is there any reason you're generating your content with JS instead of a backend language like PHP, Python or Ruby beyond your familiarity with these languages?

It seems to me that backend languages are better suited for generating a documentation page, as you want your documentation to be accessed by as many devices and browsers as possible... and JS dependance restricts access to your page to only browsers that have JS enabled. Don't you agree?

[Matthew Browne]

On 7/18/13 5:15 AM, John Slegers wrote:

As I said, margins and paddings aren't inherited unless you explicitly define them as such. So if you define a margin or padding for the "with-gutter" class, your <p></p>, <h1></h1> or <div></div> that is a child of <div class="with-gutter"></div> don't inherit its margins and padding unless you explicitly said they should.

The issue is that I don't always want to have to use my .std-gutter class in the first place -- I only created that class for the case where I wanted to add the gutter to an element (e.g. a <div>) that didn't already have the standard gutter by default. Recall that the real meat of my standard gutter is the following:

.panel, .media, h1, h2, h3, h4, h5, h6, dl, p, blockquote, table, address, pre, figure {margin:15px;}

The whole point is more concise HTML - I want to avoid (wherever possible) the need for an inner div that exists only for the purpose of adding a gutter.

In the upcoming Sass version of Cascade Framework, I'll probably use configuration parameters to let developers and designers define which padding and margin to use for their ".col", their ".cell" and other classes by default. Once there, this discussion becomes kinda moot :-)

Wouldn't any padding other than zero for the .col class break the sizing (size1of2, size1of3, etc.) in IE7? I fail to see how a configurable default padding and margin makes this discussion moot, at least not without dropping support for IE7.

It seems to me that backend languages are better suited for generating a documentation page, as you want your documentation to be accessed by as many devices and browsers as possible... and JS dependance restricts access to your page to only browsers that have JS enabled. Don't you agree?

My main reason for creating the documentation page using JS was that I have been discussing the design of the system on a programming forum and I'm planning to post the documentation site publicly later for discussion. I don't want to reveal the URL of the real system, so I'm planning to host it on github, which doesn't support any server-side scripting. I don't think the JS dependence is much of a concern. Even most phones can handle Javascript now and anyone who disables Javascript should expect that much of the internet will be broken, given the rise of AJAX. If it became important to support non-JS environments in the future, I could do what some other frameworks do and have a server-side fallback in node.js if Javascript is disabled in the browser.

[Matthew Browne]

John,
Speaking of my documentation site, I have a question: do you have a suggestion for how to better handle tree navigation that goes more than one level deep? (Currently it only goes one level deep, but there's a potential for there to be more levels added in the future.) I'm using the .nav and .tree classes. I'd like to be able to use HTML like the following and have everything line up correctly:

        <ul class="nav tree">
            <li class="collapsible">
                <a class="collapse-trigger" href="#"><span class="icon icon-collapse"></span>
                    1
                </a>
                <ul class="collapse-section">
                    <li class="collapsible">
                        <a class="collapse-trigger"><span class="icon icon-collapse"></span>
                            1.1
                        </a>
                        <ul class="collapse-section">
                            <li class="collapsible">
                                <a href="#">1.1.1</a>
                            </li>
                        </ul>
                    </li>
                </ul>
            </li>
            <li>
                <a href="#">2</a>
            </li>
        </ul>

Adding a margin here seems to help:

.menu .tree ul {margin-left:15px;}

but the childless elements don't line up with the ones with children (I'm thinking a no-children class could help).

Also, consider this scenario:

<a class="collapse-trigger" href="#"><span class="icon icon-collapse"></span>
  1
</a>
<a href="#">another link here</a>
<ul class="collapse-section">
...

"another link here" isn't in alignment with the number "1" (or even the triangle), but it's not part of the collapse-trigger so putting it inside that isn't a solution (plus HTML doesn't allow nested links).

Any suggestions?

[John Slegers]

Have you considered using the "files tree" navigation type instead of the  "menu tree" navigation type (or at least looking at the styles of the "files tree" navigation type for inspiration)? The "files tree" navigation type does support indentation with infinite depth.

I'll consider adding indentation support for the "menu tree" navigation type with a later version of Cascade Framework, although that'll have to wait until after I port the framework to Sass.

Op zaterdag 20 juli 2013 06:17:33 UTC+2 schreef Matthew Browne het volgende:

[John Slegers]

I released version 1.1 today.

The website now also contains a showcase of projects based on Cascade Framework.

If you built a website based on Cascade Framework, let me know, so I can add it to the showcase.

[John Slegers]

What's up with your documentation site? Did you move it? I noticed the original URL is down...

Op vrijdag 5 juli 2013 23:55:22 UTC+2 schreef Matthew Browne:

[Matthew Browne]

Yes, the URL changed. I will eventually move it to github where I eventually want it to accompany an example application, but for now I moved it here:

http://summerbuilder.lrei.org/docs/

I'll try to remember to let you know once it's up on github, since that should be a more permanent URL (also I might add password protection to the above URL at some point).

--

You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.

Visit this group at http://groups.google.com/group/object-oriented-css.

[Matthew Browne]

Actually, try this URL 10 minutes from now or later:
http://mbrowne.github.io/ClassRegistration-DCI/

I think I may have just succeeded in setting it up on github.

On 11/20/13 8:16 AM, John Slegers wrote:

--

[John Slegers]

Thanks :-)

I'm updating the link to your Github page as we speak.

By the way, I just created a new Gibhub project today. The code is still a bit messy, but I figured it's worth uploading anyway.

Feel free to check it out at http://jslegers.github.io/atomic-navigation/ and give any feedback you may have... 

Op woensdag 20 november 2013 14:55:36 UTC+1 schreef Matthew Browne:

Actually, try this URL 10 minutes from now or later:
http://mbrowne.github.io/ClassRegistration-DCI/

I think I may have just succeeded in setting it up on github.

On 11/20/13 8:16 AM, John Slegers wrote:

What's up with your documentation site? Did you move it? I noticed the original URL is down...

Op vrijdag 5 juli 2013 23:55:22 UTC+2 schreef Matthew Browne:

Hi John,
Nice work.

I recently used the full version to create a documentation site and am in the process of using it to build a real site.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented-css+unsub...@googlegroups.com.