Difference between revisions of "Styles Wishlist"

From Dreamwidth Notes
Jump to: navigation, search
(Standardization: Please make sticky posts standard across all styles (or eliminate them).)
 
(11 intermediate revisions by 8 users not shown)
Line 1: Line 1:
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.  See also [[S2 Wishlist]] for wishes about the S2 system.
+
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 ==
 
== 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.
 
* 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/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/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/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/892064.html - return error when custom CSS is too long. Makes sense, ja?
 
* 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?
 
 
* http://community.livejournal.com/suggestions/846771.html - a standardization in all layouts of the links that occur in the comment bar.
 
 
 
* http://community.livejournal.com/suggestions/815626.html Allow ?format=light to work for things besides single entries (e.g. whole journals, reading lists)
 
* 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.
 +
* The option to create a list of favorite styles, to make choosing a style easier.  http://community.livejournal.com/suggestions/779032.html
  
== Standardization ==
+
== Features wanted on all layouts ==
  
 
Which features should possibly be included in all layouts?
 
Which features should possibly be included in all layouts?
  
 
* Nested tags, with user specified delimiter
 
* 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.
+
* Sorted tags: set first/second/etc. tag, then list by alphabetical order. To remove the need for naming tags like so: '!important entries', '.credit entry'.
 +
* 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
 
* 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.
 
* 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.
 
* Quick reply and comment editing.
 
* Entry dates link to archive dates?
 
* Entry dates link to archive dates?
* Guestbook entry
+
* Guestbook entry.  See http://community.livejournal.com/s2howto/40800.html
 
* All should be tag aware
 
* All should be tag aware
 
* All should allow external stylesheets
 
* All should allow external stylesheets
Line 35: Line 32:
 
* All should show the entry/comment you are replying to on the reply page!
 
* All should show the entry/comment you are replying to on the reply page!
 
* Lots of customizable text
 
* 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
 
* The ability to have user icons in posts, for both recent and reading pages
 
* Timezone support
 
* Timezone support
Line 40: Line 38:
 
* Adjustable font size (this might require altering css to prevent overflow in width-defined containers)
 
* Adjustable font size (this might require altering css to prevent overflow in width-defined containers)
 
* Sticky posts
 
* 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.
  
 
[[Category: Wishlists]]
 
[[Category: Wishlists]]
[[Category: Styles]]
+
[[Category: Obsolete]]

Latest revision as of 21:57, 10 September 2010

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.
  • The option to create a list of favorite styles, to make choosing a style easier. http://community.livejournal.com/suggestions/779032.html

Features wanted on all layouts

Which features should possibly be included in all layouts?

  • Nested tags, with user specified delimiter
  • Sorted tags: set first/second/etc. tag, then list by alphabetical order. To remove the need for naming tags like so: '!important entries', '.credit entry'.
  • 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.