Difference between revisions of "Styles Wishlist"

Revision as of 21:40, 21 February 2009

Eventually, we'll probably run across theme-specific wishes; we can put them here, or remove the redirect from Themes Wishlist and put them in there and re-add that link to From LJ Suggestions. For now, though, better to centralize.

General

• http://community.livejournal.com/suggestions/885119.html - Style=mine should never step on another journal's actual content (when this suggestion is combined with related suggestions from other months and its comments). The problem specific to this suggestion is that Sticky Posts are only available in certain styles, and even the contents of such posts are treated as a style element rather than content, so that when viewing a journal under style=mine, one's own Sticky Post (or lack thereof) displays, rather than the Sticky Post of the journal being viewed.
  • This applies to link lists and free text in the sidebar as well.
• http://community.livejournal.com/suggestions/911865.html - The compiler currently thinks the word function means there is a function, even when this word is in comments. So, in the left-side panel, it lists lines which are not the start of a function. Just have the compiler ignore the word function if it's within comments. [Note: I don't do this sort of coding, so how important/impossible this is I cannot evaluate]
• http://community.livejournal.com/suggestions/874725.html - Option to view an entry without its comments. I'm not sure if this is going to be a styles thing, a sitescheme thing; I think it's going to affect a number of things, and it might be time to create an Entry/Comment viewing wishlist.
• http://community.livejournal.com/suggestions/356270.html -- Error pages (bad dates, etc) for journals are served in the journal style, not site scheme. Related to some general points made in http://community.livejournal.com/suggestions/889338.html - "when there are error pages, make them useful ones" so people can move forward logically, instead of going back in confusion. Error pages being served in "journal style" often means basic black text on white with no links whatsoever.
• http://community.livejournal.com/suggestions/892064.html - return error when custom CSS is too long. Makes sense, ja?
• http://community.livejournal.com/suggestions/815626.html Allow ?format=light to work for things besides single entries (e.g. whole journals, reading lists)
• Dream Garden layout for planning a flexible, ultra customizable CSS based layout
• A style that replaces a journal style when the journal is viewed on a mobile phone.
• The option to display entries from oldest to newest - not just by page, but for real, so that the first entry on the main page of your journal could be the first entry you posted.

Features wanted on all layouts

Which features should possibly be included in all layouts?

• Nested tags, with user specified delimiter
• The ability to edit the action link list for posts; remove or include links such as tag, edit, link, comment, etc. Possibly the ability to reorder these links. See also: http://community.livejournal.com/suggestions/846771.html - a standardization in all layouts of the links that occur in the comment bar.
• As few table-based layouts as possible
• Tag page options: cloud, list (with nesting), table. Ordering: alphabetical, by usage. Should also be able to access these by URL.
• Quick reply and comment editing.
• Entry dates link to archive dates?
• Guestbook entry. See http://community.livejournal.com/s2howto/40800.html
• All should be tag aware
• All should allow external stylesheets
• All should allow link lists
• All should show the entry/comment you are replying to on the reply page!
• Lots of customizable text
• All text should be in variables, so that language layers can be used to translate the layouts.
• The ability to have user icons in posts, for both recent and reading pages
• Timezone support
• Adjustable sidebar (modules at the least, likely positioning too)
• Adjustable font size (this might require altering css to prevent overflow in width-defined containers)
• Sticky posts
• http://community.livejournal.com/suggestions/893189.html - add free text areas to all styles. In general, I think the aim is for styles to have as many of these features occur across all styles?
• Ability to add meta tags to header.

Backend Wishes

Wishes specific for the S2 backend.

• Add a ticky variable to the properties/customization wizard, for easy boolean values.
• The ability to group a bunch of customization variables together and have them easily reordered in the customization wizard, such as by drag and drop, to be accessible by an array in the S2 layout code.
• S1-esque frontend to S2. Give people a box and some HTML they can play with.