![]() Ok, HTML5 isn't actually an official standard yet, but the latest versions of the major browsers support significant sections of it. I am not suggesting changing the behavior for the keyword-sorted icons.) (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. 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. 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. Here is the code from the core2 which concerns itself with the icon keywords: The IconsPage styling was implemented last year ( ) but it hasn't been used much all of the system styles are still using the old icons page. 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. The same could apply to (fan)artists and the various arts they post on Dreamwidth. (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. Readers could then decide to continue reading that post, search for all posts containing those warnings, or skip the post entirely. 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.įor 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. But probably it would be awesome and everybody would be happy again, and that's my story and I'm sticking to it. Also it might be hard to code or something. 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). 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. I propose that Dreamwidth undo this illogical decision and restore title/subtitle to its rightful place under Edit Profile. Sadness, and also it just took me like two minutes to find because seriously, why is it there?! ![]() 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. Even greater was the fact that DW was hard at work at correcting some of LJ's more questionable coding decisions. Years later, Dreamwidth came to exist and forked off of LJ's existing code, and that was great. ![]() 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. (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. Once upon a time on LJ, journal titles and subtitles were edited via the Edit Profile page, and everybody was happy. ![]()
0 Comments
Leave a Reply. |