Styles overhaul: stage one

[aveleh]

For the last few months, one of the quiet projects that has been going on is an overhaul of the styles system on Dreamwidth. The styles system for LiveJournal code is mostly very powerful, but there are a number of problems associated with it. Most of these problems can only be fixed by breaking things first, which is what we've been doing.

----------------------------------------------------------
Somewhat technical ramblings:
----------------------------------------------------------

(1) The S1 style system hasn't been officially supported for years, which means that either new features aren't implemented in that system or that they have to be implemented a second time into the system. These days, with the added wizards and CSS boxes available within S2, it's much more accessible to people at a variety of levels of experience and interest in customization. For these (and other) reasons, S1 will not exist on Dreamwidth.

(2) S2 styles were written by various authors, at various times, and for various reasons. Although many of them have since been standardized, many users still have to choose their style based on what it can *do*, as opposed to how it *looks*. We have been standardizing functionality by moving as much of the logic as possible to the core2 layout. We have also been continuing to standardize the wizards in the same way, so that users can more easily make changes. And we've been standardizing CSS classes and IDs across styles, so that users can duplicate CSS in the wizards or make use of them in GreaseMonkey and Styleish scripts. This is taking a long time, but will be worth it in the long run.

For those of you who are anxious to get working on new styles, we're still not done getting these standardizations done in a way that will help you work on them. I promise that it's one of the priorities, and one of the reasons that we're working on this overhaul in the first place: to make it easier for people to author styles. Please continue to be patient.

----------------------------------------------------------
What all this means:
----------------------------------------------------------

If you aren't using a customized style, you may have noticed that the ugly and plain style you've been forced to use has now been replaced with a... still ugly and plain style, but one that has more functionality. This is our first draft of core2, the underlying code that is used to power all the other styles that are coming your way. We aim to have a stable building block with which to build other styles; styles won't have to create a lot of functionality from scratch each time.

The draft you're using doesn't have any wizard functionality, so you can't add headers or change background colours or make any of a million tweaks that will be standard. There will be features that you don't use that are showing up, that later you'll be able to remove them. And things that are ugly. But you guys all know this is beta :) So, please, poke at it, poke at journals, poke at communities, poke at syndicated feeds. If you're on the beta team, please follow your usual bug reporting procedures as per domtheknight. If you're not, please contact me (I like IRC) or denise for further instruction regarding any problems you find.

Current known issues (more edited in as reported):

• ugly


• No wizard


• CSS incomplete


• HTML not validated on all views


• Two "tags" listings in sidebar - this is because one is to display multi-level tags. Multi-level tags are a change in display, only. Use : as a separator between words in your tags to make use of this feature.


• openID user URLs in the sidebar overlap with the rest of the page text. Have to decide whether to make really wide sidebars, or do something else with the usernames.


• On the Reading page sidebar, usernames are printed for users posting in communities, but not for users printing in their own journal.


• On the Reading page sidebar, usernames are printed for users posting in communities, but not the community name.


• On communities that you can manage tags, the "Manage Tags" link under the "Tags" modules will not appear, as S2 has no way of knowing who can manage tags.


• On the month view, entries that have links will not work as expected. Instead, the HTML in the subject should be stripped and printed plain, and then linked to the entry.


• The Month module shouldn't be displayed when viewing an openid's reading page


• Unclosed h3 tag on the Day Page

Some example things to be expected:

• You should be able to perform the same "user interactions menu" options on any journal page as you can on the profile page. This means adding and/or modifying your circle relationships, posting to a journal, and tracking entries. If you see something different, report it. If the text describing the action is incorrect, report it.


• There are two linkbars for working on your entries, one for "edit entry, edit tags, add to memories, track this" and one for "x comments, leave a comment". Each link should only display to a user who can do that specific action. If you see something different, report it. If the action is describing the action is incorrect, report it.


• etc, etc

Comments

[rho]

I can't believe that nobody has commented on this yet. I don't understand S2 at all and yet this is still massively exciting to me. Having an S2 that's actually finished! You guys rock.

[aveleh]

<3

[dani_the_girl]

OK, I have been poking around and all looks good. I have compiled a list of smaller or larger niggles here, most of which are not bugs so much as suggestions for the new core functions. The only actual bug I found so far is that there's an unclosed h3 tag on the DayPage so I think that qualifies you lot to open a case of champagne or something!

[aveleh]

Awesome. I'm going to comment here, for my ease :D

1) Recompiling my style under core2 requires editing a couple of properties and that's it. Yay for not having the double negative variable naming for turning off custom comments pages :)

\o/

2) My current style, using core1, is using the new views array and so has extra items in the menu bar. Cute.

\o/ (We tried to make it so that if you use the core2 functions, you can get to important pages from your style.)

3) No overall div for the sidebar created by the sidebar primary function. Looking at core, I see it's in the page print, function. I would suggest that anything which is printing out a lognical grouping of content like that ought to print out the containing tags for that grouping itself, but that's personal preference - I doubt it'll make people override.

Sidebars are totally a half-finished job. But yes, the whole point of all the printing functions is to print out containing classes and ids so that people will be able to use those standards without having to pay attention to them. Expect to see more changes to sidebars themselves, too.

4) No CSS class to indicate the current view on the views list.

Yup, part of CSS incomplete. There are lots and lots of classes and ids still missing.

5) The tell a friend button on the userlinks toolbar isn't transparent like the rest.

*nods* I wasn't worrying about the look of any of our icons because of Bug 394 (< a href="http://bugs.dwscoalition.org/show_bug.cgi?id=394">match LJ icons to Silk icons ).

6) While we're building in tags functionality, how about a tags_cloud function for the sidebar?

*nods* High on the existing list of things that still needed to be implemented.

7) The basic comments layout is displaying with the userpic on its own line, which is annoying. Might be a width issue, but it never used to do that.

I answered elsewhere, but this is because I haven't changed much in the comments section, other than replacing the userpic with the new printing userpic function. Lots of mess in the comment area.

8) There is an unclosed h3 tag on the day page.

Fixed for next draft. Thanks. ouch.

9) Page summary on Friends Page doesn't list the journal the entry's held in. (You can pinch the code for this from my style if you like - I just modded the existing Core2 stuff).

Thanks. Got that one in known issues.

10) No tag counts as tool tips on tag links

Added for next draft.

11) For consistancy's sake, can the Reply link have brackets around it like the (Parent) and (Thread) links for comments?

Nope. But when we get to that stage, I'm removing brackets from (Parent) and (Thread), so same deal :D

[dani_the_girl]

Interesting. The thing with comment info appearing under the userpic, not next to it is a core thing, not a my style thing. Might want to consider changing that?

[dani_the_girl]

OK, figured it out. Looking at the source, there is (with extra attributes cut for legibility):

<table><tr><a href="blah"><img src="your userpic"><td>[sub table containing all the From, date, etc]</td></tr><table>

So the problem is basically that we're missing a set of <td> elements wrapping the userpic.

[domtheknight]

Not sure what your plan is on this but - logged out, there's no button for subscribing to things, but the memory and sending a personal message buttons are still there. They redirect to login. I feel like maybe for the buttons, it should be all or nothing - have every option and they all redirect to login, or have none (except the next and back arrows, since they don't require login).

[aveleh]

*nods* I will find out which way we should go, and pass that on to be standardized. Thanks!

[domtheknight]

When you look at an entry in ?mode=reply, the tag list and the navigation buttons all disappear. I can sort of understand the navigation buttons, since probably the user is only there to leave a comment, but the tags missing seems odd. (This happens in openID, seed accounts, and logged out users - haven't tested free yet.)

eta: Huh, on the site-schemed pages, the tags disappear but the buttons don't. I'd never noticed that before.

Also, it happens on LJ too, which I hadn't noticed before either. So maybe it's intentional.

[aveleh]

Did we talk about this on IRC, or did I just dream it? I just wanted to make sure I noted that I've got it on the list; thanks!

[baggyeyes]

I just wanted to pop in and say a couple of things. Actually it was supposed to be one thing, but something popped up.

I've opened 7 journal pages from DW with images on, some had themes set up, (a couple look like Smoothies, one like grrliz's design from the Fulcrum) but synecdochic had a full background, and images. Everything loaded fast on my dialup connection. On LJ, I usually have to surf with images off. Maybe that's because you haven't got the full steam ahead thing going on the themes yet, or what, but I like how fast the pages loaded.

The second thing is, when I clicked to comment, for me below OpenID was LiveJournal User, rather than Dreamwidth user. I've seen the same thing on InsaneJournal as well. Just an FYI.

I REALLY look forward to when I can join DW. Great job, and hopefully, I can help out soon.

[denise]

The "LiveJournal user" thing is something that our site copy team is fixing! There are a bunch of stray "LiveJournal"s all over, because LJ was vaguely sloppy in how they set things up. We're stepping on all of them. :)

[afuna]

Commenting here so we don't lose track:

journal subtitles to use <span>/<p>, instead of h2?

As per http://branchandroot.dreamwidth.org/1207.html

[aveleh]

I'm always willing to be convinced, but I need a compelling reason why change from having it marked as a header to having it marked as a paragraph. It's a title! You can still CSS it, but for those of us who read with styles turned off, it's clear it's a header (which for random subtitles some people love becomes really important).

<3

[domtheknight]

A couple things.

On the day view, text for entries, dates, titles, etc is all a lot larger and bold than on any other view.

I checked on seeing locked posts in communities and on personal journals against membership and access, and everything there looks like it's showing up correctly except on openid, in views other than recent entries, locked entries weren't listed. If that's not Styles related, I'll stick it in bugzilla.

[afuna]

Zilla the openid thing. Looks like there's a problem with the stuff that's feeding entries to styles.

[branchandroot]

The Core2 comment structure is still hinky. The userpic appears in .contents while the actual text appears in .footer. This is not, as yet, breaking anything in ways that can't be gotten around, but with more complex styles it's going to start being an issue.

ETA: Except that the text falls in between the "select" and the "interaction" links, which is rather troublesome to read when it's one's own journal.

[domtheknight]

Thanks for reporting this! aveleh is at work right now and asked me to stop by and let you know what was up. The Styles team has a patch coming to fix this but they weren't expecting the code push that went out today so it wasn't finalized and committed yet.

[ratcreature]

I'm not sure whether this is the right place to ask, but in the regular comment page (i.e. no particular layout but just the red/purple site scheme) there is no white space on the sides, but the text is very close to the browser window edge. I find that this really decreases readability for me. LJ has space there, and IJ too. I noticed the same thing on the profile pages too, that there is no white space, and all the red/purple pages really, that everything is so close to the sides, but it is especially bad an effect on the non-styled comment pages. Is this an intentional design choice?

[afuna]

For reports on bugs that aren't specific to the journal styles system, see http://domtheknight.dreamwidth.org/7342.html#comments.

(Thanks!)

[snakeling]

I'm not positive on this, but I'll comment anyway so you can have a look :)

I think there's an error in function Page::print_entry(Entry e) on line 6:

    $e->print_time();
    """<div>\n""";
    """<div class="contents">\n""";

I think the middle line should be a closing div (to close .header).

The opening and closing divs do match, though, so there's probably a closing div to also take out in Entry::print_wrapper_end().

As I said, I'm not 100% sure of myself, but otherwise the header wraps around the whole entry, which makes no sense :)

[afuna]

Makes sense! (the bug report, not the behavior). We've filed, and have a patch coming out soon.

[grrliz]

snakeling got the header issue I was having, so my only remaining issues a couple of ones that are more a preference than they are an error. These are based on using the Core 2 Testing layer at thefulcrum.

1) One bit of functionality I liked on LJ was that userpics/usernames were contained within their own div so that you could separate them out from the rest of the content quite easily. As it stands right now, the userpic has its own div and the usernames have a span (I think), but the only thing that contains both of them is the container that holds the entire entry.

2) The date and time each have their own individual spans but, again, there's not one to contain the date/time as a whole entity.

Again, these are probably preference things, but since I tend to approach LJ layouts solely from the CSS point of view, they were things that made me immediately thing OMGWHY at the (minor) loss in flexibility. I imagine we're trying to avoid divitis. :)


(My favourite part of this post is this: "Current known issues: ugly".)

[afuna]

No, these are good things to bring up! And perfect timing too; in addition to bug fixes, we're currently focused on adding a few more CSS classes / containing elements where logical to make things easier for CSS designers. These fit right in with the other tweaks we're making.

#2 (date and time), we're definitely doing. I'll bring up (or Abby will) #1 (userpic/poster) when we go through the classes.

If you have anything else you want/need, we'd love to hear more suggestions. (See above re: making things as easy as possible)

[gossymer]

Was just wondering if paid users at LJ will be able to use Core2 over there with a theme layer+user layer. For my future journal design reboot I'd love to be able to base it on Core2 for both LJ and DW instead of mixit and port it over to DW...

Also, some of the things I've always wanted to do:
#1 have username and community name on a single layer above/before the subject title.

Been able to sort of do it on Bloggish but could never do it on expressive/mixit without a theme layer. I'm hoping that a theme layer hack won't be needed for Core2

#2 Have the date at the bottom right of an entry just before the linkbar.

The closest I've been able to get for both is on my comm noveltybox

Also, I'd love to be able to have something that's sort of been exclusive to one or two layouts styles on lj - having username, then the linkbar then the entry content like over here - and then have just two links again for "X comments" and "add comments" at the bottom of each entry. Basically, being able to choose whether to have the linkbar at the top or bottom or both (and if both, then the bottom linkbar would be minimalist with just commenting links)

Though most likely this won't happen >_> I guess since layers are available to all accounts, I can always just include a theme layer when sharing layouts with this design...

[laitaine]

I was playing around with core2 last night, I have a couple of small comments:

* It would be nice to have an entry-actions wrapper of some kind around entry-management-links and entry-interaction-links to bring them together.
(Ditto for the date and time spans, but I see that's been mentioned already.)

* I want to replace $*text_tags with an image, at the moment I'm having trouble doing this. (This could just be me failing at css.) It would be great if $*text_tags was put into the tags list and highlighted as being a label, eg. <li class="tag-label">$*text_tags</li>, or in some other way wrapped and highlighted as being a label. The other metadata seems to work like this already. Another option would be to have $*text_tags accept html, though I'm pretty sure you have Good Reasons for not allowing that in the first place.

An issue with Core2

[gossymer]

It's not possible to disable the website listed in the .about-module in #secondary via CSS because it doesn't have an individual class - same with the name. They've both been put under the same class so to disable one, you have to disable both via css or try to hide either by making the name text or the website link really tiny and the same color as the background.

Basically, if Name and Website can be enabled/disabled individually via Customize Style, it should be possible via css two by giving them unique classes :)

[roximonoxide]

So... I haven't tinkered with making a core2 layout since I can't remember when, and don't remember a bloody thing about creating layers and what have you being little more than a CSS monkey, but um, if I could ask that you talk to me like a five year old for a minute here:

"We aim to have a stable building block with which to build other styles; styles won't have to create a lot of functionality from scratch each time."

Means; there will be styles to come the likes of LJ's smooth sailing that can be completely redesigned beyond recognition solely with some standard CSS, yes?

[afuna]

Means; there will be styles to come the likes of LJ's smooth sailing that can be completely redesigned beyond recognition solely with some standard CSS, yes?

Yup! In fact, the core2 layer, upon which all official layout layers are built, is specifically designed to be able to be customized using CSS. (Which means that all layouts should be heavily customizable with just CSS)

I just stumbled upon some gorgeous designs on mintyapple and dreamwidthlayouts

[rainfall]

This isn't a complaint, just a question.

I'm trying to make a version of my entry-swapping code that will work on DreamWidth, but I think you guys changed a property name. At the bottom here, I originally had "print_commentlinks"; it resulted in an error of "Unknown function print_commentlinks(Entry)". I changed it to print_interaction_links($e) and then print_management_links($e), but the error keeps coming up -- unknown function [name here](Entry).

Any ideas?

function entry_order(string order, Entry e, Color bgcolor, Color fgcolor) {
if ($order=="subject") {
print_entry_subject($e);
}
if ($order == "datetime") {
print_entry_datetime($e);
}
if ($order == "userpic") {
print_entry_userpic($e,$bgcolor,$fgcolor);
}
if ($order == "entrytext") {
print_entry_entrytext($e);
}
if ($order == "metadata") {
print_entry_metadata($e);
}
if ($order == "commentlinks") {
print_management_links($e);
}
}

[afuna]

Hm, I can't see print_commentlinks in core1. Perhaps it was a layout-specific function?

To print the other links, try this instead:

$e->print_management_links();
$e->print_interaction_links();

[rainfall]

Also, you may have already dealt with this, but CSS3 has a "word-wrap:wordbreak" option you could apply to the sidebar that would force those really long OpenID names to break appropriately midname? Just a simple forward-thinking solution for a small visual bug~. :3

[afuna]

I think we tried it and couldn't get it to work, or weren't sure which browsers supported it, so we wanted to check first or try to implement a way to insert <wbr> or something!

Any idea which do, at this point? If it's a reasonable number of the modern ones, we can get away with just using the CSS.