Core variables for userpic and navlinks position?

[branchandroot]

Changing the userpic and navlinks locations seems to be something a fair number of users want. I have gotten repeated requests via pm for css to either change the side of the entry the userpic appears on or move the navlinks from the sidebar to the header. I imagine some of the other designers get these also, especially for the layouts where it's more complicated than float:left instead of right. It seems as though this is something we should work on addressing in the wizard. If there were a wizard-settable core variable, let us say position_userpic, that could be set to "left" or "right", then it would be relatively simple to include css for both as a local variable in any layout. The same is true for the navlinks, though those can be a little more of a chore to switch gracefully.

Should this be added as an enhancement/bug?

ETA: I am talking about CSS positioning for the navlinks, not altering the html.

Comments

[feathertail]

Post to suggestions, maybe? It does sound very useful, at least for the userpics.

The navlinks might be more difficult to position ... I'd personally like to be able to customize them some, but I'm not sure if this would cut it.

[branchandroot]

The navlinks are somewhat more difficult, and some layouts would really not lend themselves at all to putting those anywhere up top. Most can, though, and I've gotten even more requests for that than for the icon-swapping css.

What kind of customization are you thinking of, that goes beyond changing the position that way, though?

[feathertail]

Changing what order they're displayed in, for one ... I had a layout earlier where "Recent Entries" was at the bottom.

I was also thinking of changing the names on some of them, to be more like a WordPress blog ... like having "Home" instead of "Recent Entries." That might confuse long-time Dreamwidth / LiveJournal users, but then, the way Dreamwidth has it is different from most of the rest of the world.

[branchandroot]

Yes, changing the order would be an entirely different function than this, though I do agree it would be a nice addition also.

The text of them is already alterable in the wizard; are you thinking of proposing a change in the default text?

[feathertail]

The text of them is already alterable in the wizard

It is? Huh, I guess I didn't know that. >.> Sorry. Thanks for pointing that out!

I knew things like comment sections could have different names, because I see people styling those all the time.

[ninetydegrees]

There's already a bug for userpics (http://bugs.dwscoalition.org/show_bug.cgi?id=1813). As for moving stuff to the header, that's possible with some layouts but not Tabula-Rasa-based ones. If designers want this to be available then they can edit functions in their codes or ask for a patch when submitting their layouts.

[branchandroot]

It most certainly is possible with Tabula Rasa based layouts, as long as you do it with css. All of my layouts so far are TR based, and I could do this for all of them via css. Several, such as Basic Boxes and Crossroads already implement the navlinks-at-top. It's also the most common complex-css requested of me for layouts that don't have it already.

[ninetydegrees]

Sorry. I thought you meant moving any sidebar module to the header area, which is possible in Transmogrified for example. And when I said possible, I meant possible in the Wizard via a setting, not custom CSS. If you only mean navlinks, I think it's even simpler.

[branchandroot]

*nodnod* Exactly. And what I propose is to add a variable on which alternate css can be hung so that layouts like the TR children could also move the navlinks between top and side via the wizard. Like the userpic option, most layouts would have to have local css worked out to make the switch, but it would only have to be done once.

[ninetydegrees]

This variable already exists but is used for all modules. Designers are supposed to customize its values. This is what Core has:

set module_layout_sections = "none|(none)|one|Group One|two|Group Two";

This is how it's been customized in Negatives to give you an example:

set module_layout_sections = "none|(none)|one|Sidebar|two|Header|three|Footer";

I'm trying to see if you can only edit the subsequent property for navlinks (property string module_navlinks_section).

Designers are also free to create any variable they think is missing to their code.

[branchandroot]

I don't think we're talking about the same thing. I'm talking about the possibility of a purely css-based positioning that does not affect the html or the module groupings in any way.

And, yes, if I wanted to make a new base layout for the sake of just this one thing I could but I like designing on top of TR quite well and think a variable to hang the alternating css on would be a useful addition to the core itself. Part of the point of TR was to make it flexible enough to sustain a wide variety of designs.

[ninetydegrees]

That's the same thing. Properties don't tell how this is implemented. They just allow people to set stuff via the wizard.

TR is Core. It's just Core with a little CSS, and, as I said the property's already there.

[branchandroot]

*frowns* Wait a minute, you're thinking to hang the navlinks position css on the module grouping property?

...that seems like bad metadata usage.

And, since the TR layout children inherit the TR module grouping, how is that supposed to allow the positioning of a module in the notional "header"?

[ninetydegrees]

No, as I explained, I'm trying to see if you can edit the values for the navlinks prop only or if you need to create a new prop or what.

Because you can edit properties/create your own in your layer. I did it for Funky Circles. Zvi's doing it for Refried Tablet. Both are TR-based.