Skip to:
Content
Pages
Categories
Search
Top
Bottom

Members directory code

  • Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    I’ve done a version one of the code for the new members directory:
    https://gist.github.com/3743761

    Image here:

    This is very much a concept not a set version. The CSS is at the bottom of the file – I’ve also commented out or removed (if needed) CSS that I’ve done changes to (for instance submit buttons).

    Few points to kick off the debate:
    1. Do we want to have as a li or a dl?
    2. Do we want things like ‘generic’ classes and specific ones ie; member-title item-title?
    3. I removed the role=main as most themes assign roles – seems potential duplicates if we also add
    4. Do we want a prefix ie; buddypress- or are we going to use a #buddypress
    5. Where possible I am using things like % and this includes for fonts. I think best to avoid any exacts like px – if we have to a rem could of course work.
    6. I added in a style for the submit / button but we need to consider if we do that or leave that up to defaults be they browser or theme.

    Thoughts welcome and feel free to poke the code around and suggest changes via gist.

Viewing 25 replies - 1 through 25 (of 35 total)
  • Argh, blimey. We need to see the CSS just for these changes. How did you get this working with trunk, btw? Child theme of bp-default?

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    I did this in Twenty Twelve in the end as had a child theme issue (reported on trac). It was using trunk.

    Just CSS in gist:

    https://gist.github.com/3744885

    Avatar of meg@info
    meg@info
    Participant

    @megainfo

    Nice!
    thanks

    Avatar of @mercime
    @mercime
    Keymaster

    @mercime

    @karmatosed thanks for the hard work.

    1. Re: Do we want to have as a li or a dl?
    => IMHO UL. Why do you want to change it to DL?
    2. Re: Do we want things like ‘generic’ classes and specific ones …
    => I would prefer that we retain the classes or ID’s already there. If devs want to add some more classes, that’s fine with me.
    3. Re: I removed the role=main as most themes assign roles – seems potential duplicates
    => I agree.
    4. Re: Do we want a prefix ie; buddypress- or are we going to use a #buddypress
    => my choice #buddypress plus classes representative of component and component sections
    5. Where possible I am using things like % and this includes for fonts. I think best to avoid any exacts like px – if we have to a rem could of course work.
    => I would leave font-sizes to theme defaults, except to make the font relatively smaller where wanted or needed, [edit] simple just like CSS transferred via BP Template Pack plugin
    6. I added in a style for the submit / button but we need to consider if we do that or leave that up to defaults be they browser or theme.
    => Other than placement of button (right, left or center) I suggest leave that up to defaults in theme

    Thoughts welcome and feel free to poke the code around and suggest changes via gist.
    => Haven’t had the time to compare the before and after, I need patch/diff to see what’s changed. Thank you for all your contributions :-)

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    List structures: To li or dl ?

    The li structure is time honoured but partly as many aren’t that familiar with how a dl can be used so it’s not out of the question to use a dl, previously we had lists such as activity stream chucking out a huge amount of non semantic aggregating elements using a dl construct may help lend some better meaning to inner elements in loops. It needs looking at and seeing if the generated elements do make sense in a dl, if dt’s and dd’s do convey a better meaning and useful structure for styling with.

    Should not necessarily retain classes as they were, bear in mind we are moving forward free of the constraints of backpat there will be the default theme still selectable if wanted. classes do however need, still, the principle of generic class and specific class to allow for maxim flexibility so you might have ‘bp-lists’ as well as ‘bp-members-list’ style some generic properties for all lists and add some specific rules targeted to members list.

    Font sizing needs to carefully considered, by and large we mustn’t fall into trap of setting any sizes this is where inheritance is still massively relevant and we must be using – as expressed in OP – relative sizing (not sure that we can even risk rems in this situation) . By way of an example of why this aspect is important: recently had to counter a plugin that was adding elements to the post content, the authors had thought it ok to set that element with an explicit px font size – however if they had thought things through they should have realised that they could have no idea what font sizing approaches or sizes set in any given theme thus their fixed size essentially resulted in a broken post layout and had to be countered or overridden – pointlessly.

    In this process it’s perhaps important to view two aspects as invidual tasks, that is you have markup / structure and then visual styling. The structure needs to be worked up first and be able to demonstrate suitable semantics, and a element flow and be then shown to fit to a given parent structure albeit unstyled then visual styling applied to make that structure have a sense of layout.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Not sure where or how the ‘#buddypress’ fits in that prefixes all the selectors?

    I do think first order of the day ought to be to re-factor the stylesheet ‘sections’ into something that makes better sense for this new iteration esp given we won’t be needing to worry about providing styles for things like WP elements.

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    @Hugo: Why do you think a rem is a risk? A em is a risk yes but a rem? I ask this more opening up the debate than against anything you’re saying.

    I do think from the feedback though that removing font-sizes full stop is a far better approach.

    https://gist.github.com/3748782 is the latest revision then taking this in mind and your comments @mercime

    We do need to consider do we do borders / colours or do we even leave those to one side? We have errors / messages and other things we probably need though.

    @Hugo: If you look at legacy theme which is what is in trunk – it is wrapping in a #buddypress so using that. I don’t think refactoring is the first order as we’re redoing everything. What has been suggested by Paul and I think rightly, is that I take this back into legacy and build up from there clearing everything down. That’s what we’re doing here not refactoring the old. If you’ve not I’d suggest looking at the legacy theme though that doesn’t style WordPress defaults (if you look into the CSS it’s only calling ones it uses). I think we’d be very much doing it wrong if we did.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    A rem references the root element, using it might just as easily conflict with a theme as a fixed size, using a true relative measure such as em/% as you mentioned would be the only safe way of adding font sizes as it would respect what ever the parent might be setting or at least be relative to whatever the parent might be setting, however I would agree with you, ultimately not setting font sizes at all is safest path to take although we probably know that certain elements such as meta are nearly always down sized.

    Clearly there is a little confusion here – likely on my part but also with the nomenclature in use – Yes there is an id=”buddypress” in the members index template in the legacy folder but I do not see that running 2012 and looking at members dir so now not sure what I’m looking at or really what the term ‘legecy’ is actually referring to.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Ignore paragraph about my confusion found that ID :) couldn’t see wood for the trees

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    - That’s what we’re doing here not refactoring the old

    never said anything about re-factoring the old but you have placed that gist example up so I’m commenting on that – I utterly disagree with re-factoring the old as that was never the plan! this has always been about the opportunity to move forward but we’ve all understood that those who have been at all involved?

    re-factoring is a sensible order of the day as it denotes and sets out what is in the stylesheet and where and needs to be done afresh for theme compat.

    I am running legacy templates and yes agreed that clear down legacy and build anew is order of day but that’s why I was a little confused by the gist stuff.

    As for styling anything other than BP stuff one can’t, yes there won’t be any need for WP styles but that is sort of point in theme compat we now are only concerned with styling BP to best fit to a generic theme.

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    @Hugo – that’s why in my last 2 gists I’ve just put pure CSS separate.

    Avatar of @mercime
    @mercime
    Keymaster

    @mercime

    @karmatosed, re CSS and members-loop.php
    1. first thing I’d add is `#buddypress ul { list-style: none; }`
    2. Based on more than 80 WP themes we’ve “template-packed” so far, you don’t need to append #buddypress to all (or almost all) of selectors present in http://plugins.svn.wordpress.org/bp-template-pack/tags/1.2.1/bp.css some of which are also used in your gist

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    @mercime: we are using the legacy theme though that uses #buddypress as the id. I’m not basing it on template pack. What is in gist is from the legacy theme that has a id wrapper #buddypress.

    Avatar of @mercime
    @mercime
    Keymaster

    @mercime

    @karmatosed I know very well that you are using the legacy theme which has added div#buddypress and are not basing it on the template pack.

    The BP template files transferred to WP theme folder via BP Template Pack plugin have generally the same HTML structure with its ID’s and classes (except new #buddypress) as that of the legacy theme. Therefore it was logical to deduce and to recommend, after helping with the implementation or around 80 template-packed WP themes, that there was also no need to append #buddypress to all the elements within the legacy theme to the stylesheet.

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    @mercime: hmm I think #buddypress .element is fine. We may have crossed wires as prefix doesn’t mean just that it could be #buddypress-elementname. If we’re talking selectors I think we should have that.

    Avatar of @mercime
    @mercime
    Keymaster

    @mercime

    @karmatosed Here’s an example of what I mean
    `/* members directory */
    #buddypress ul.item-list{
    display: block;
    margin: 0;
    padding: 0;
    }
    #buddypress #members-list li.item-grid{
    border: 1px solid #f1f1f1;
    display: inline-block;
    float: left;
    list-style:none;
    margin: 0 2% 1% 0;
    vertical-align: top;
    width: 48.65%;
    }
    #buddypress .member-avatar{
    float: left;
    margin: 0 3% 0 0;
    }
    #buddypress #members-list .member-single{
    padding: 1rem;
    overflow: hidden; /* temp fix */
    }
    #buddypress #members-list li.item-grid:nth-child(2n+2){
    margin: 0 0 1% 0;
    }`
    to
    `/* members directory */
    ul.item-list {
    display: block;
    margin: 0;
    padding: 0;
    }
    #members-list li.item-grid {
    border: 1px solid #f1f1f1;
    display: inline-block;
    float: left;
    list-style:none;
    margin: 0 2% 1% 0;
    vertical-align: top;
    width: 48.65%;
    }
    .member-avatar {
    float: left;
    margin: 0 3% 0 0;
    }
    #members-list .member-single {
    padding: 1rem;
    overflow: hidden; /* temp fix */
    }
    #members-list li.item-grid:nth-child(2n+2) {
    margin: 0 0 1% 0;
    }`

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    @mercime: What if in the CSS of the theme there was #members-list as a class. We need to have #buddypress to ensure even if there is it won’t be the one we’re referring to. We have to encounter for any theme.

    I’d suggest using the least specific selectors, and only make them more specific if and when it’s needed. The classes themselves will probably be prefixed to minimise any name conflict.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    All classes could/should be prefixed with ‘bp-*’ with #buddypress in reserve for where there may be further need of adding ‘weight’

    Avatar of Tammie
    Tammie
    Moderator

    @karmatosed

    I think prefixing with bp- does sound a better option then. Just having raw really won’t work I think we all agree now. I’ll add that to the next update.

    Avatar of Roger Coathup
    Roger Coathup
    Participant

    @rogercoathup

    suggest rather than writing raw CSS, you work in LESS, or better still SASS — will make it much easier to work with BP styling — supporting factoring out into different files / template, easier separation of colours / layouts / typographic, etc, colour (and font) schemes (i.e. using variables for the colours, which might be a real boon for basic BP themers) .., but most importantly given the nature of BP (and this discussion)… it deals much better with nested selectors.

    You still have CSS files churned out that ‘non-savvy’ devs can work with, but also provide a much more useful set of files for those who can.

    Note: of the major frameworks out there — Twitter Bootstrap provides LESS files, whilst Zurb Foundation provides SASS / SCSS. They really are the future for high powered CSS work and definitely the way BP should be going to support development on future versions of the platform.

    Roger, not as easy as it seems. We have a bot that minimises our CSS + JS files on commit (shared with WordPress core, and bbPress core, and other Automattic projects). AFAIK, it doesn’t support LESS etc. That’s one technical reason why we couldn’t do that immediately. Another reason is the core team has never discussed if we want to use LESS etc in BP; it might be worth something asking us after a dev chat sometime.

    I also suspect you’re overestimating the amount of markup that we’ll end up with. I might be underestimating, but we’ll find out soon :)

    Avatar of Roger Coathup
    Roger Coathup
    Participant

    @rogercoathup

    @djpaul – the LESS or pref SCSS compiler (e.g codekit) produces CSS files for you — you then include the CSS files in the theme (along with the original SCSS / LESS).

    Given you have the CSS files for committing, would there be any issue with the Automattic bot for minimising?

    I don’t like the idea of that workflow. It wouldn’t stop someone changing the CSS directly and forgetting to update the LESS file. I’d prefer to write LESS, and have the CSS generated and minified in a post commit hook.

    Avatar of Roger Coathup
    Roger Coathup
    Participant

    @rogercoathup

    It’s the way Twitter bootstrap, Zurb Foundation, 320 and up, Compass, etc. provide the files.

    It’s up to the user / developer how they work on their own site — if they want to use SCSS they can, if they want to stick with CSS they can. You’ve provided them with both in the default set of files – and they can work how they see fit.

    [Edit: of course, they should be working in their own themes anyway, and not overwriting the default set of files, so not sure there's any issue]

Viewing 25 replies - 1 through 25 (of 35 total)

The forum ‘BP-Default’ is closed to new topics and replies.