timeasmymeasure: kerry washington with a rose held right below her lips (Default)
[personal profile] timeasmymeasure

Title:
Be Able To Customize "Member Posts" Text In Communities

Area:
communities, customization

Summary:
We should be able to customize the navigation text for the reading in page in communities.

Description:
Currently, the reading text for communities defaults to "Member's Posts", which makes sense. However, it also makes sense that we should be able to customize the text in the 'Customize Journal Style - Text' page like we can with the other navigation links.

Poll #9397 Be Able To Customize "Member Posts" Text In Communities
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

Should be implemented as-is.
40 (66.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
19 (31.7%)

(Other: please comment)
0 (0.0%)

roximonoxide: (Default)
[personal profile] roximonoxide

Title:
Editable Module Headers

Area:
styles / customization

Summary:
User input fields to control the text headers of all modules, not just the custom text module.

Description:
Currently, the the Custom Text module allows for the user to change the module heading from the Text customization options for your journal. (The same page where you might edit other default page text such as metadata labels and navigation links). Though you can hide module headers entirely with css, other modules have no such customization options other than order and page placement. It would be exceedingly helpful to both users and communities who use their journals, and the modules available to them, differently if all other modules allowed for the user to alter the default module headings to text of their own choosing.

This might logically be implemented either from the Text page, as it already exists for the with the Custom Text module, or from the Modules page where order and organization of your modules takes place.

Poll #9210 Editable Module Headers
Open to: Registered Users, detailed results viewable to: All, participants: 68


This suggestion:

View Answers

Should be implemented as-is.
39 (57.4%)

Should be implemented with changes. (please comment)
1 (1.5%)

Shouldn't be implemented.
2 (2.9%)

(I have no opinion)
26 (38.2%)

(Other: please comment)
0 (0.0%)

allchildren: kay eiffel's face meets the typewriter (Default)
[personal profile] allchildren

Title:
move journal title controls back to Edit Profile

Area:
Styles/Profiles

Summary:
Move the editing controls for journal title and subtitle from Edit Journal Style to Edit Profile.

Description:
Once upon a time on LJ, journal titles and subtitles were edited via the Edit Profile page, and everybody was happy. (There was a dark time previously when journal titles and subtitles didn't even exist, but we don't like to talk about those days.) However, one day For Some Reason those controls were moved to the Customize Journal Style page. Much consternation and confusion raged across the land, for the journal title and subtitle and in fact THE FIRST THING one sees on one's profile, so it seems pretty natural to want to edit it there; in fact, some journal styles hide the subtitle completely. WHY IS IT EDITED THERE. WHERE IS THE LOGIC. BUFFY QUOTE.

...cried the people.

Years later, Dreamwidth came to exist and forked off of LJ's existing code, and that was great. Even greater was the fact that DW was hard at work at correcting some of LJ's more questionable coding decisions. Great, great stuff. However, this fork included the illogical switch of title/subtitle control, and thus it still sits in Customize Journal Style, making way less sense than it would to be in Edit Profile.

Sadness, and also it just took me like two minutes to find because seriously, why is it there?!

I propose that Dreamwidth undo this illogical decision and restore title/subtitle to its rightful place under Edit Profile. The only drawback I see is that it may confuse people who have gotten used to it being under Customize; but since Edit Profile is really the natural place to look for it I think that will be the lesser confusion. Plus, there could be a link where that control used to be pointing people in the right direction (or at least that link to Customize could exist under Edit Profile so I never waste two minutes again). Also it might be hard to code or something. But probably it would be awesome and everybody would be happy again, and that's my story and I'm sticking to it.

Poll #9086 move journal title controls back to Edit Profile
Open to: Registered Users, detailed results viewable to: All, participants: 79


This suggestion:

View Answers

Should be implemented as-is.
29 (36.7%)

Should be implemented with changes. (please comment)
17 (21.5%)

Shouldn't be implemented.
14 (17.7%)

(I have no opinion)
18 (22.8%)

(Other: please comment)
1 (1.3%)

aidadesigns: Ginger tabby painted in watercolor, head closeup (Default)
[personal profile] aidadesigns

Title:
Adding option to move tags before entry text

Area:
tags

Summary:
Adding an option under Customization > Additional options that enables a user to place tags before entries instead of having them appear after entries, as is currently the case.

Description:
There's already an option under Customization > Additional options that enables a user to move metadata before entry text, and I believe having the same option for tags would be useful in many cases.

For example, people could tag their posts discussing sensitive issues with general or trigger specific warning tags, making those warnings easy to spot at the top of the post. Readers could then decide to continue reading that post, search for all posts containing those warnings, or skip the post entirely. (Fan)writers could tag their fiction as original or fan fiction, then tagging it further according to fandom, pairing, genre, etc., making it easy to see and search according to the reader's preferences. The same could apply to (fan)artists and the various arts they post on Dreamwidth.

I don't foresee any problems and drawbacks to this suggestion, and I don't have any knowledge of S2 or other languages to be able to suggest any other ways to accomplish this move.

Thank you in advance.

Poll #8898 Adding option to move tags before entry text
Open to: Registered Users, detailed results viewable to: All, participants: 75


This suggestion:

View Answers

Should be implemented as-is.
45 (60.0%)

Should be implemented with changes. (please comment)
6 (8.0%)

Shouldn't be implemented.
3 (4.0%)

(I have no opinion)
20 (26.7%)

(Other: please comment)
1 (1.3%)

sharpiefan: Line of Age of Sail Marines on parade (Default)
[personal profile] sharpiefan

Title:
Links List on switching layouts

Area:
links lists

Summary:
If a user has more than 10 links (including blank spaces for headers) in their links list, on switching layouts, a user loses links 11 onwards. Could there be some way to change things so that a user doesn't lose links?

Description:
If a user has more than 10 links (including blank spaces for headers) in their links list, on switching layouts, a user loses links 11 onwards. Could there be some way to change things so that a user doesn't lose links? I recently changed layouts, not realising that I'd lose a good portion of my links list in doing so, and I don't suppose I'm the only one - and I don't know if there's any way to go back and get them again.

Poll #8392 Links List on switching layouts
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
40 (75.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (22.6%)

(Other: please comment)
1 (1.9%)

cmshaw: DC Comics: Kory cries "X'Hal!" (Default)
[personal profile] cmshaw

Title:
Keywords are not listed separately for styling the icons page in S2

Area:
styles

Summary:
In the S2 code for the IconsPage, there is an array of icons which contains the user's icons (as Icon objects) listed in the order specified. Each Icon object has an array containing the icon's keywords. When the IconsPage's sort order is the order in which the icons were uploaded, each Icon object has exactly one element in that array no matter how many keywords the icon has, and that one element contains all of the icon's keywords concatenated together.

Instead of this, the array should have one element per keyword, with each element containing one keyword.

Description:
The IconsPage styling was implemented last year (http://dw-styles.dreamwidth.org/18631.html) but it hasn't been used much; all of the system styles are still using the old icons page.

Here is the code from the core2 which concerns itself with the icon keywords:

    if ($.keywords) {
        """<div class="keywords">""";
        var int keyword_count = 0;
        print safe "<span class='label'>$*text_icons_keywords</span> ";
        """<ul>""";
        foreach var string kw ($.keywords) {
            $keyword_count++;
            """<li>""";
            print safe $kw;
            if ($keyword_count < size $.keywords) { print $*text_icons_keyword_sep; }
            """</li>""";
        }
        """</ul></div>""";
    }


This, to me, pretty strongly implies that the keywords array was intended at some point to hold multiple elements which should be looped through in order to display each keyword separately. There's a string to hold the separator between the elements and everything! I would like it to hold each keyword in a separate element here, when the icons have multiple keywords to be displayed; I think it makes a lot more sense than forcing a comma concatenation in a one-element array.

(Side note: when the sort order is by keyword, the icons appear multiple times in the $.icons array, each time with just the applicable keyword in their $.keywords array, which seems fine to me. I am not suggesting changing the behavior for the keyword-sorted icons.)

Poll #8384 Keywords are not listed separately for styling the icons page in S2
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

Should be implemented as-is.
9 (22.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
31 (77.5%)

(Other: please comment)
0 (0.0%)


Edited to fix formatting
allen: (Default)
[personal profile] allen

Title:
Add an HTML5/CSS3 (core) style

Area:
styles

Summary:
We should put in a style, be it a customized style or a core style (core5?), that generates HTML5 code and uses CSS3 features. Since this wouldn't be universally supported, we should also available only on a beta/opt-in basis at first.

Description:
Ok, HTML5 isn't actually an official standard yet, but the latest versions of the major browsers support significant sections of it. Same with the various parts of CSS3 and WAI-ARIA. And while we wouldn't want to force everyone to upgrade their browsers, it would be nice for users and developers to have the option of trying out the new features.

In particular, I'd suggest that we build a single S2 layer that generates valid, semantically correct HTML5. We'd probably also need to update the Javascript on the pages to work with the new structure. We could even do a single page at a time, falling back on the default style if the HTML5 version of the page isn't available. This would give us time to standardize the page structures, accessibility requirements, etc., without having to worry about getting a working version of everything done.

Beta opt-in could be through the <a href = "http://www.dreamwidth.org/betafeatures">beta features</a> page. Only users who had opted in would see the new HTML5 pages. To make it simple, we'd probably want to have that value sticky everywhere, so that if you chose to see HTML5, you'd see it on all pages where it was available by default. (Though style=light or style=mine would probably still be available as an override.)

Poll #6688 Add an HTML5/CSS3 (core) style
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

Should be implemented as-is.
20 (42.6%)

Should be implemented with changes. (please comment)
3 (6.4%)

Shouldn't be implemented.
2 (4.3%)

(I have no opinion)
22 (46.8%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Add an Optimized-for-small-screens category to the Select Journal Style page

Area:
styles, accessibility

Summary:
Test each theme as presented in the Select Journal Style area for how well it behaves on small screens. Put the ones that work well into a category, so people who need this can find them easily. Meta-task: identify accessibility situations with distinct needs, and create theme groups specifically for them.

Description:
This is apropos of a support request where someone had decided against using Dreamwidth because it did not work well for them on a small screen out of the box. Foxfirefey put a good amount of research into finding themes and styles that worked well with small screens. This seems like a situation that will probably come up again, and not every person showing frustration will think to come to Support.

The meta-task, of identifying accessibility situations and creating theme groups for each of those (for example: small screens, light sensitivity/migraines, large font...) sounds as though it would work well paired with FAQs targeted at those same needs from a whole-site-usability standpoint: how to set site skin, where to find and change themes, etc.

Poll #6571 Add an Optimized-for-small-screens category to the Select Journal Style page
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
54 (94.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (5.3%)

(Other: please comment)
0 (0.0%)

turlough: deckchairs on Brighton Beach, June 2013 (Default)
[personal profile] turlough

Title:
Option to make archive and calendar week start on a Monday

Area:
Archive and sidebar calendar

Summary:
There should be an option that lets you set Monday as the first day of the week in the archive year view and in the calendar module.

Description:
As a European I'm always thrown to see the week start on a Sunday in the archive year view and in the calendar module. I think that, just as we have the option to set time to display as 24 hours instead of AM and PM, we should have the option to set Monday as the first day of the week. It's a small thing but I think it would be a nice way of showing that DW isn't only for people from the US.

Poll #5992 Option to make archive and calendar week start on a Monday
Open to: Registered Users, detailed results viewable to: All, participants: 80


This suggestion:

View Answers

Should be implemented as-is.
51 (63.8%)

Should be implemented with changes. (please comment)
18 (22.5%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (13.8%)

(Other: please comment)
0 (0.0%)

foxfirefey: Fox stealing an egg. (Default)
[personal profile] foxfirefey

Title:
Add a "Manage Links" link to the links module

Area:
styles

Summary:
The links module should have a "manage links" link at the bottom, like the tags module does, if you are able to edit the links.

Description:
Currently, figuring out where your links list is and how to edit it is not as easy to access as, say, tags. Putting a link at the bottom of the Links module to let you manage them if you have the permissions would be a way to make that page easier to find and edit.

Poll #5606 Add a "Manage Links" link to the links module
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

Should be implemented as-is.
26 (54.2%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
2 (4.2%)

(I have no opinion)
18 (37.5%)

(Other: please comment)
2 (4.2%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Advanced Customization: option to duplicate layers and styles

Area:
styles

Summary:
Add a function to create a copy of an existing layer or an existing style (public or custom).

Description:
I make styles based on other styles (Tabula Rasa or my own) and themes based on other themes I've made for the same style. Having a duplicate function would make it easier and faster as I'd have less copying and pasting to do.

Poll #5577 Advanced Customization: option to duplicate layers and styles
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

Should be implemented as-is.
38 (70.4%)

Should be implemented with changes. (please comment)
1 (1.9%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (27.8%)

(Other: please comment)
0 (0.0%)

aedifica: Me looking down at laptop (off screen).  Short hair. (Default)
[personal profile] aedifica

Title:
Give a list of journal styles a user has used

Area:
account management, styles

Summary:
Say you want to change your journal style to a really cool style you used a while ago... and now you have no idea what the style was called. Wouldn't it be great to be able to see a list of styles you've used in the past?

Description:
This hasn't been an issue for me on Dreamwidth yet, but I bet it's only a matter of time (I just ran into it on LiveJournal). Say you want to change your journal style to a really cool style you used a while ago... and now you have no idea what the style was called. Wouldn't it be great to be able to see a list of styles you've used in the past, so you don't have to page through all the styles and try to remember exactly what it looked like?

This could be a link called "[user name]'s Theme History" from the "[user name]'s Current Theme" box on the Select Journal Style page. The link would go to a page with a list of styles that have been used on that journal before. (It would be extra cool if each style named on that page included a link to the style, but even just the name would be helpful.)

Possible drawbacks: one more thing for Dreamwidth to keep track of. Also, when Dreamwidth starts getting more custom styles created by users for other users (modifications on site styles), I'm guessing this list I'm proposing would only be able to display the name of the site style that was the base for the custom style.

(P.S. I am confused about the difference between styles and journal themes, so if I've misused either term that's probably why.)

Poll #4641 Give a list of journal styles a user has used
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

Should be implemented as-is.
23 (44.2%)

Should be implemented with changes. (please comment)
10 (19.2%)

Shouldn't be implemented.
3 (5.8%)

(I have no opinion)
16 (30.8%)

(Other: please comment)
0 (0.0%)

stormy: βͺ ππŽπ“πˆπ‚π„ ❫ 𝑫𝑢 𝑡𝑢𝑻 𝑻𝑨𝑲𝑬 𝑴𝒀 𝑰π‘ͺ𝑢𝑡𝑺 ⊘ (Default)
[personal profile] stormy

Title:
Make Stylesheet Text Box Larger

Area:
styles

Summary:
http://www.dreamwidth.org/customize/options?group=customcss

The custom style sheet box would be much easier to write complex css in if it was wider. It's aligned to match up to the checkbox and textarea above, but it just looks like it is wasting space. There are many times when I feel like having to wrap my CSS around on several lines makes it harder for me to work in that box when I want to adjust things.

Description:
(See Summary)

It'd be exponentially helpful if it was as wide as the area the textbox sits in.

Bonus Suggestion:
"Use embedded CSS
If you'd like to add custom CSS to this style, enter it here."

That phrase should probably be aligned to the top of that box so that it's not placed below the large text box.

Poll #4640 Make Stylesheet Text Box Larger
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

Should be implemented as-is.
28 (56.0%)

Should be implemented with changes. (please comment)
10 (20.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (24.0%)

(Other: please comment)
0 (0.0%)

foxfirefey: Fox stealing an egg. (Default)
[personal profile] foxfirefey

Title:
Standardize color selection throughout site

Area:
Customization, circle management

Summary:
I want an improved color picker, and all places on the site that pick colors to be the same.

Description:
Right now, I can think of two places on Dreamwidth that have color selection:

http://www.dreamwidth.org/customize/options?group=style
http://www.dreamwidth.org/manage/circle/edit

I want us to pick out a jQuerified plugin, such as ColorPicker, and use it on both of those pages instead of the current disparate systems.

This suggestion has a caveat, however, in that it changes the way the circle colors work--right now, those colors seem to be artificially limited to a given set in the front end. However, I don't think giving people more options with a (possibly better) UI would be amiss here.

Any implementation would have to consider users who do not use Javascript, however, and make sure they have a usable interface still.

Poll #3752 Standardize color selection throughout site
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

Should be implemented as-is.
17 (53.1%)

Should be implemented with changes. (please comment)
1 (3.1%)

Shouldn't be implemented.
1 (3.1%)

(I have no opinion)
13 (40.6%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Styles: Add links to Your Layers

Area:
styles

Summary:
Add links to Public Layers and S2 Doc to Your Layers so that you don't always have to go back to Advanced to get to these.

Description:
BTW, it would be nice if S2 Doc could now encompass the Wiki pages dealing with S2 (I know it's a big WIP but it already has very useful info) or even be replaced by http://wiki.dwscoalition.org/notes/S2_Guide:_Table_of_Contents.

Poll #3536 Styles: Add links to Your Layers
Open to: Registered Users, detailed results viewable to: All, participants: 27


This suggestion:

View Answers

Should be implemented as-is.
13 (48.1%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (51.9%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Improve the S2 Compiler

Area:
styles

Summary:
Add line numbers, highlight the line where an error was found, add a second Save & Compile at the bottom, add a link to public layers, option to colorize some elements (such as the words 'function' and 'propgroup' or commented lines).

Edit: for coloring, maybe something like the syntax highlighted view of source layers.

Description:
Is there any other 'small' change you can think of? Maybe a search field. You can do that with Ctrl+F but maybe a field would be nice anyway.

Poll #3535 Improve the S2 Compiler
Open to: Registered Users, detailed results viewable to: All, participants: 24


This suggestion:

View Answers

Should be implemented as-is.
15 (62.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (37.5%)

(Other: please comment)
0 (0.0%)

zvi: self-portrait: short, fat, black dyke in bunny slippers (Default)
[personal profile] zvi

Title:
Timestamp collapsed comments on journal styled pages

Area:
styles, entry pages, comments

Summary:
When a comment is collapsed (the text of the comment is not shown, merely a link to expand or open the comment on a second page) in a system style, the metadata available about the comment includes the date and time it was made.

This information should also be displayed when an entry page is in a journal style.

Description:
If the timestamp of a collapsed comment is visible, it is easier to guess whether or not one has read it before. You can keep track of the time before which you have or have not read a comment, and only open the ones that are new to you.

Poll #3481 Timestamp collapsed comments on journal styled pages
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

Should be implemented as-is.
38 (86.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (13.6%)

(Other: please comment)
0 (0.0%)

matgb: Artwork of 19th century upper class anarchist, text: MatGB (Default)
[personal profile] matgb

Title:
Allow/encourage title attributes to links list entries

Area:
styles

Summary:
Create text area within the Links list for link TITLE text, that would then display as per browser standards.

Description:
Currently, the only option we have for a Links List entry is URL and link text. It's good practise to give links Title text as well, that normally, depending on browser settings, then displays as a tool tip.

Other platforms, such as Wordpress, allow and encourage links to be given Title attributes, following usability guides and allowing users to give expanded explanations of what a link is, and why it's there in the sidebar.

Example: in my links list, I link to Miss_s_b using her name. For sidebar space reasons, that's all I can give. I'd like to allow users to know if they hober over a link that she's my fiancΓ©e and give a brief description of her content. That's good practise, recommended by usability experts. It can also aid search engines and is recommended white hat SEO behaviour.

Poll #3478 Allow/encourage title attributes to links list entries
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
17 (50.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
7 (20.6%)

(I have no opinion)
10 (29.4%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Customize: make 'Choose a Page Setup' available in Customize Style

Area:
styles

Summary:
Move 'Choose a Page Setup' to Customize Style OR duplicate it there OR add a link to it (with appropriate anchor) when the layout allows for different page setups.

Description:
When you were on Customize style (http://www.dreamwidth.org/customize/options), you used to be able to select a different setup (one column, two columns, etc.) in Display options. Now, you have to click on 'Select on a different theme' to go back to Customize. Except you're not trying to change themes so the link is confusing. I think the least that can be done about this is to add a 'Change your page setup' link to Customize Style as well.

Poll #2962 Customize: make 'Choose a Page Setup' available in Customize Style
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

Should be implemented as-is.
32 (72.7%)

Should be implemented with changes. (please comment)
1 (2.3%)

Shouldn't be implemented.
1 (2.3%)

(I have no opinion)
10 (22.7%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Customize Journal Style: turn sidebar subsections into links

Area:
styles

Summary:
When you want to customize your style, two menus - display and style - have subsections: mood themes, presentation, fonts, colors, etc. Turn these into links as well.

Description:
It's always annoyed me that I can't directly go to images or fonts if I want to and I don't understand the reasoning behind it.

Poll #2637 Customize Journal Style: turn sidebar subsections into links
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

Should be implemented as-is.
29 (74.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (25.6%)

(Other: please comment)
0 (0.0%)

Profile

Dreamwidth Suggestions

April 2017

S M T W T F S
      1
23456 7 8
9 101112131415
16171819202122
23242526272829
30      

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom