PLEASE LOG IN OR REGISTER TO BE ABLE TO SEE THE PICTURES AND ATTACHED FILES!
|
Author |
Message |
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
Problem with layout of lists |
Quote |
the layout of index (lists) type A, B and C below is not correctly lined out on my screen, see the attachment showing the results of lists A, B and C defined below. Lists A and B look the same (second block shifted to the left wrt first one), C shows clearly that a blank line is added unexpectedly by the software.
| | Index A
[list]
[*]Title chapter 1
[list=1]
[*]text 1.1
[*]text 1.2
[/list]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list]
| ==>Result:
Index A
- Title chapter 1
- Title chapter 2
| | Index B (no spaces)
[list]
[*]Title chapter 1
[list=1]
[*]text 1.1
[*]text 1.2
[/list]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list] | ==> Result:
Index B (no spaces)
- Title chapter 1
- Title chapter 2
| | Index C (no spaces & no CR)
[list][*]Title chapter 1[list=1][*]text 1.1[*]text 1.2[/list][*]Title chapter 2[list=1][*]text 2.1[*]text 2.2[/list][/list] | ==> Result:
Index C (no spaces & no CR)
- Title chapter 1
- Title chapter 2
How can I get it correct?
The problem showed up now while preparing a new index for Arrancar, see http://lah.li/p/254926
Edit: It might well be that this problem already existed before the V-update, I didn't exactly use type A, B or C above before. It's strange though that a complicated list as in http://lah.li/p/274287 still looks as good as ever ...
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Sun Feb 16, 2014 10:53 pm |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
Your syntax looks correct.
As a matter of fact, the lists' code hasn't been modified for many years (if it ever was). With a quick glance, there seems to be two or three issues at play here:
Firstly, the parser currently does not actually support different nested lists of different types. It is generating invalid markup, which explains the different left margin in some items.
The "extra line" is related to two other "issues":
- Each line break (carriage return) you insert in the text will be replaced by a Line Break Element when rendering the post. Though it would be really nice to allow formatting lists with line breaks, I fear that changing this behavior would bring some undesirable side-effects. Maybe removing any whitespace and line breaks which follow an opening [list] or [list=1] tag could work.
- Another point is that there is currently no list styling applied on our part - what you see is your browser's default lists styling. Chrome and Firefox put some margins above and below the top-level list, and no vertical margins around nested lists.
The huge gap between "Title chapter 2" and "text 2.1" is both due to the line break and the invalid markup mentioned earlier, which makes the browser interpret that list as a top-level list and thus adds vertical margins.
I would suggest some workarounds, but I guess it is better to have a definitive solution. I'll add this to the small bugs list, it should land in the next minor patch.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Tue Feb 18, 2014 1:24 am |
Profile PM MSN Skype
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
So let's see, fix the nesting problem, normalize the margins to have the same behavior as chrome/firefox in every browser, okay nothing really hard here.
Now onto how we should handle line breaks to make the list code more readable (without an extra line break in the output), I'm not quite sure. Let me think a bit, have to take in consideration line breaks before and after both opening and closing list tags.
- Lists are block elements, hence a line break before the opening tag does not affect the rendered output since blocks will implicitly create those breaks either way.
- Line breaks before the closing tag should never happen the way the parser is designed, (as long as the input is valid) the line breaks will be inside of the list item and a single line break in the end of the list item won't be rendered due to their block-like display nature.
- Finally there are line breaks after the opening tag and after the closing tag, these would always be rendered.
I could make the parser eat away a single line break (if present) after the starting and after the ending tag, this allows for adding line breaks for formatting code without affecting the output, as well as still allowing to add more than one line break when extra spacing is desirable. The lists' implicit line breaks and their vertical margins will be rendered just as before, independently of having eaten away line breaks or the whole code being inline without line breaks. This will just affect the spacing after a list start and after a list end which are now being cut short by one line break, which makes sense since there were already vertical margins of equivalent space.
Indentation is also possible, the browser will just collapse the extra whitespace, the same behavior as before.
I've attached a screenshot which hopefully illustrates better what I'm trying to convey.
This should not break any existing list, though note that it may affect the rendering of some existing lists, more specifically those which have one or more line break after a [list], [list=1], [list=a] or [/list], which will have a single line break's space stripped from them. Also, as the invalid markup will be fixed, the nested lists which are currently wrongly identified as top-level will no longer have vertical margins.
In other words, this seems to be a good move, but you will have to review your existing lists to ensure that they look as you want, after the update has landed.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Tue Feb 18, 2014 3:52 am |
Profile PM MSN Skype
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
The proposal in your last attachment is perfect, as WYSIWYG as we can get. I wouldn't mind to refresh - if necessary - previous lists, of which the code now looks clumsy.
Good idea to solve this in a definitive way, hopefully more artists and fans are gradually going to use it to make indexes of their work, making this site still more enjoyable. Maybe to make creating lists even more user friendly, the edit list buttons could be adjusted in a further future too (adding the extra line feeds automatically, and adding a new [*] button, which I believe is standard in phpBB).
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Tue Feb 18, 2014 7:51 am |
Profile PM
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
To see how it works in practice, I brought the code of the index of the first two chapters in http://lah.li/24672/3d-custom-girl-one-chapter-works-various/?page=1#281496 in line with your attachment above.
The code now looks nice:
Result is as expected:
Index One-Chapter Works
(click on any arrow ==> jump to corresponding post)
- And I Ran Away November 2011: Shota
- A True Friend May 2012: Futanari
Result in one spoiler doesn't show correct in my preview screen, there should be only one spoiler below containing both chapters and I see only one chapter in the spoiler below, chapter two has escaped and show up further below
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Thu Feb 27, 2014 8:39 am |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
The preview I posted in my previous post is not live yet, it will be deployed in the next maintenance update together with some other fixes and changes to reduce server load.
The issue you reported is most likely due to the invalid markup still, let's see it again after the update goes live. You may have noticed that there are still some blank lines after opening [list] which will no longer appear after the update goes live.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Thu Feb 27, 2014 3:12 pm |
Profile PM MSN Skype
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
I was delaying this update in order to bundle some improvements to a few mod/admin tools, but server performance and layout rendering take precedence. Therefore, I've split this maintenance update and deployed the first part.
You should notice the lists nesting now works as expected. There are also improvements that the vast majority of users won't notice, our JS and CSS are now gzipped and all our assets have aggressive caching, but still allowing us to update them whenever we want thanks to our sturdy automated cache busting strategy. A couple layout fixes and cleaning went live as well. That is, most of it is invisible to non-developers, but you should notice that the site loads and renders faster. Also, some 3rd party modules have been updated, but I've put enough effort to make the transition nearly unnoticeable, I'll leave that up to you to guess what has been changed.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Fri Feb 28, 2014 4:45 am |
Profile PM MSN Skype
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
Great to see that you tackled the server overload problems so vigorously, the screen in the attachment below was very annoying indeed, hope to see it never again after "waiting for lah.li" a couple of minutes...
Index in OP looks great now, in later post it seems that spoiler spoils it a little bit. Test -->
| | Index AA
[list]
[*]Title chapter 1
[list=1]
[*]text 1.1
[*]text 1.2
[*]text 1.3
[/list]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list]
| ==>Result:
Index AA
- Title chapter 1
- text 1.1
- text 1.2
- text 1.2
- Title chapter 2
| | Index AB
[list]
[*]Title chapter 1
[spoiler][list=1]
[*]text 1.1
[*]text 1.2
[*]text 1.2
[/list][/spoiler]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list]
| ==>Result:
Index AB
- Title chapter 1
- Title chapter 2
| | Index AC
[list]
[*]Title chapter 1
[list=1]
[*]text 1.1
[spoiler][*]text 1.2
[*]text 1.3[/spoiler]
[/list]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list]
| ==>Result:
Index AC
- Title chapter 1
- Title chapter 2
| | Index AD
[list]
[*]Title chapter 1
[list=1]
[*]text 1.1
[spoiler][*]text 1.2
[*]text 1.3
[/list][/spoiler]
[*]Title chapter 2
[list=1]
[*]text 2.1
[*]text 2.2
[/list]
[/list]
| ==>Result:
Index AD
- Title chapter 1
AA is perfect, AB has extra line, AC is empty and AD=AB+AC
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Fri Feb 28, 2014 1:29 pm |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
I've only implemented the line break removal for lists as an experiment, I was considering whether to apply it to other block elements such as spoilers, code blocks, etc. but it would affect the rendering of a large amount of existing posts, and IMO the spoilers would look a bit too crowded without a line below them in most of the common use cases.
I'll type the explanation for the other cases inside of a code block so I can properly type BBCode tags without rendering them:
| | AC is invalid, the [*] must be directly children of a [list] (nested directly under, without any tag wrapping the [*] besides a [list]). Guess I've said it before, but BBCode is a translate-to-HTML markup language, hence the HTML rules should be respected if you want your posts to render correctly in all browsers. [list] translates to <ul> (unordered list - http://dev.w3.org/html5/markup/ul.html#ul-content-model ), whose only permitted content are <li> (list item) elements. As you may have figured out, [*] translates to <li>. List items are implicitly closed right before the beginning of the next list item, and before the [/list].
So, in short, [*] is invalid as a direct child of a spoiler, [*] must always be a direct child of a [list], if [*] is nested directly inside of any other tag it is invalid. Also, the only valid direct child for [list]s is [*], so you should open a [*] before putting any other content inside of a [list].
Ordered lists follow the same rules as unordered lists.
To illustrate better:
OK:
[list]
[*]
[/list]
OK:
[list]
[*]
[list]
[*]
[/list]
[/list]
OK:
[spoiler]
[list]
[*]
[/list]
[/spoiler]
OK:
[list]
[*]
[spoiler]
[list]
[*]
[/list]
[/spoiler]
[/list]
INVALID:
[list]
[spoiler] -- ERROR: [list] only permits [*] as direct child
[*] -- ERROR: [*] is not valid as a direct child of anything but [list]
[/spoiler]
[/list]
| I personally tend to avoid using lists due to all these restrictions.
| | AD is invalid because you opened a [spoiler] tag inside of a [*] and closed the spoiler outside of the [list]. Overlapping tags are always invalid, tags should always be closed before their parent tag is closed. |
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Fri Feb 28, 2014 5:57 pm |
Profile PM MSN Skype
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
I like the idea of automatic removal of "code improving line breaks" so much that I'm trying to implement it here right away ==> for better readability I too put the following in a code block:
| | [code]
[quote="ult_combo"]
I've only implemented the line break removal for lists as an experiment, I was considering whether to apply it to other block elements such as spoilers, code blocks, etc. but it would affect the rendering of a large amount of existing posts
[/quote]
A frequently used block is the quote block. I think it would be great if the line break removal was implemented for all block elements; in rare cases we could edit an old (index) post but the advantage of being stimulated to give our posts a clear structure seems more important.
[quote="ult_combo"]
IMO the spoilers would look a bit too crowded without a line below them in most of the common use cases.
[/quote]
Consider the layout difference of case AB (extra line) and AC (no extra line) in the attachment below. I think most people would prefer AC. And those who prefer AB could easily add an extra line themselves - in contrast to the situation now: it is impossible to remove that extra line! So please stop adding those extra lines around blocks.
If possible, I would even prefer to have e.g. the spoiler starting where we insert it. The code between quotation marks:
"E.g. [spoiler]s[spoiler]p[spoiler]o[spoiler]i[spoiler]l[spoiler]e[spoiler]r[/spoiler][/spoiler][/spoiler][/spoiler][/spoiler][/spoiler][/spoiler]"
should result in a one-liner altogether, not 7 lines as in the current rendering!?
[quote="ult_combo"]
So, in short, [*] is invalid as a direct child of a spoiler, [*] must always be a direct child of a [list], if [*] is nested directly inside of any other tag it is invalid. Also, the only valid direct child for [list]s is [*], so you should open a [*] before putting any other content inside of a [list].
[/quote]
Very useful info Ult, thanks :D
[/code] |
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Fri Feb 28, 2014 11:09 pm |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
Yeah, I agree that being "unable" to remove the line break is a drawback (it is actually possible to remove it by writing the following text in the same line, but it doesn't look good on the editor, of course).
The real problem is that the spoiler toggle is pure text and gets mixed in the text too easily without line breaks. Guess I'll experiment changing the spoiler toggle layout a bit to give it a bit more visibility.
jacxxx:
| | If possible, I would even prefer to have e.g. the spoiler starting where we insert it. The code between quotation marks:
"E.g. [spoiler]s[spoiler]p[spoiler]o[spoiler]i[spoiler]l[spoiler]e[spoiler]r[/spoiler][/spoiler][/spoiler][/spoiler][/spoiler][/spoiler][/spoiler]"
should imo be a one liner altogether, not 7 lines as in the current rendering!? |
Not sure there. Spoilers are block elements, that is, when you click "Show spoiler" it opens a block showing the spoilers' contents. Blocks by default take all width of the containing block, inserting a line-break before and after them implicitly - you can see the spoiler block delimited by a thin border.
Spoilers consists of two parts: the toggle (or trigger) which shows/hides the contents, and the spoiler contents. Showing the trigger inline with the text sounds reasonable, but then opening the spoilers contents would automatically push any text after the button to below the spoiler contents, as long as we keep the spoiler contents as a block.
Edit: here is the demonstration of the above with a draft toggle button: hxxp://jsfiddle.net/uKnZL/
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Fri Feb 28, 2014 11:32 pm |
Profile PM MSN Skype
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
ult_combo: Yeah, I agree that being "unable" to remove the line break is a drawback I'm glad I made at least one point clear
The real problem is that the spoiler toggle is pure text and gets mixed in the text too easily without line breaks. Guess I'll experiment changing the spoiler toggle layout a bit to give it a bit more visibility.
Personally I think our current spoiler toggle would be visible enough, also when it appeared in the middle of a text line. Perhaps it could be shorter (click to open/hide) and sexier (emoticon of loli getting unplugged/ plugged)?
ult_combo (the yellow color was added by me): Spoilers are block elements, that is, when you click "Show spoiler" it opens a block showing the spoilers' contents. Blocks by default take all width of the containing block, inserting a line-break before and after them implicitly - you can see the spoiler block delimited by a thin border.
Spoilers consists of two parts: the toggle (or trigger) which shows/hides the contents, and the spoiler contents. Showing the trigger inline with the text sounds reasonable, but then opening the spoilers contents would automatically push any text after the button to below the spoiler contents, as long as we keep the spoiler contents as a block.
Edit: here is the demonstration of the above with a draft toggle button: hxxp://jsfiddle.net/uKnZL/ I see that your reference also automatically shows a thin bordered block around the text, which is quite unnecessary in my use of the spoiler function. As I use it in the indexes (btw: the idea to do so originally was Arrancar's) a more appropriate name would be "detail". When detail is "on" a lot of detail is shown, when it is "off" it is hidden. Intuitively I would think a "detail button" - especially think of it's use in nested lists - should work as follows:
I offer a piece of code to be parsed containing a couple of (nested) details, say "indexbefore [detail]T1[detail]T2[/detail][/detail] indexafter". When a user chooses detail 1 on and detail 2 off I expect you to read this as: "indexbefore D-on T1 D-off indexafter", without any blocks or lines or anything automatically added. (D-on/off are the detail-on/off toggles, T1/2 are the texts - which may contain codes to be processed as any other code appearing outside the details! - within detail 1/2).
Using this function Detail instead of Spoiler all test examples AA - AE above would work fine, despite the html rules you mentioned, wouldn't they? (just because of the prefiltering)
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Sun Mar 02, 2014 1:36 pm |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
jacxxx: Perhaps it could be shorter (click to open/hide) and sexier (emoticon of loli getting unplugged/ plugged)? Not a bad idea, though I'll go with something more neutral for now.
jacxxx: I see that your reference also automatically shows a thin bordered block around the text, which is quite unnecessary in my use of the spoiler function. The border indicates which contents are part of the spoiler, also indicating what will be hidden when clicking the "hide spoiler" button.
jacxxx: I offer a piece of code to be parsed containing a couple of (nested) details, say "indexbefore [detail]T1[detail]T2[/detail][/detail] indexafter". When a user chooses detail 1 on and detail 2 off I expect you to read this as: "indexbefore D-on T1 D-off indexafter", without any blocks or lines or anything automatically added. (D-on/off are the detail-on/off toggles, T1/2 are the texts - which may contain codes to be processed as any other code appearing outside the details! - within detail 1/2).
As you're using lists/list items, which also behave like blocks, making spoilers/details inline would still have the same problem as the demo in my previous post -- text which comes after the spoiler's would be pushed to under the spoiler contents upon opening the spoiler.
About [detail]: We usually tend to avoid duplicating functionality. If a spoiler is good enough for your and most other use cases, there isn't much point into adding more tags to generate almost the same behavior. Though, now that you've mentioned the term "details", HTML5 introduced a <details> element (see demo). It may be useful to implement that syntax in BBCode (replace <> with []), though its functionality is very close to that of a spoiler and <details> is currently only supported in Chrome/Safari -- it is possible to polyfill it, but I'm still hesitant in adding more JS and more BBCode parsing overhead just to have a functionality which will barely get used and which there's an alternative solution already. Maybe in the future?
jacxxx: Using this function Detail instead of Spoiler all test examples AA - AE above would work fine, despite the html rules you mentioned, wouldn't they? (just because of the prefiltering) Independent of using spoiler or another tag, AD will always be invalid due to the overlapping tags and AC violates the permitted content rules (list > list item). Not sure what you mean by prefiltering.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Sun Mar 02, 2014 7:36 pm |
Profile PM MSN Skype
|
|
jacxxx
Beginner Angel
Warnings:
Posts: 14
|
|
Quote |
ult_combo:
jacxxx: I offer a piece of code to be parsed containing a couple of (nested) details, say "indexbefore [detail]T1[detail]T2[/detail][/detail] indexafter". When a user chooses detail 1 on and detail 2 off I expect you to read this as: "indexbefore D-on T1 D-off indexafter", without any blocks or lines or anything automatically added. ... Not sure what you mean by prefiltering. I mean that as a first step you convert "indexbefore [detail]T1[detail]T2[/detail][/detail] indexafter" into "indexbefore D-on T1 D-off indexafter" and only after this start applying the remaining BB-->html process.
ult_combo: About [detail]: We usually tend to avoid duplicating functionality. If a spoiler is good enough for your and most other use cases, there isn't much point into adding more tags to generate almost the same behavior. Though, now that you've mentioned the term "details", HTML5 introduced a <details> element (see demo). It may be useful to implement that syntax in BBCode (replace <> with []), though its functionality is very close to that of a spoiler and <details> is currently only supported in Chrome/Safari -- it is possible to polyfill it, but I'm still hesitant in adding more JS and more BBCode parsing overhead just to have a functionality which will barely get used and which there's an alternative solution already. Maybe in the future?
I like [detail] better (because of the "summary" which for spoiler is always "spoiler"), perhaps only that one will be necessary and sufficient - spoiler being included?
_________________ My avatar shows the first encounter of Yuki in the Land of Eternal Snow. Yuki would become my favorite character in the on-going Mystics Saga by arrancar85 |
|
|
Sun Mar 02, 2014 8:05 pm |
Profile PM
|
|
ult_combo
Matrix Angel
Warnings:
Posts: 86
|
|
Quote |
jacxxx: I mean that as a first step you convert "indexbefore [detail]T1[detail]T2[/detail][/detail] indexafter" into "indexbefore D-on T1 D-off indexafter" and only after this start applying the remaining BB-->html process. Well, independently of the conversion order, the result is the same. Independent of whether we "convert" spoiler or list tags first, their start and end tags will still be in the same order in the same place, I guess a better term would be "inline replacing". The output received by the browser would be the same, still invalid.
jacxxx: I like [detail] better (because of the "summary" which for spoiler is always "spoiler"), perhaps only that one will be necessary and sufficient - spoiler being included? I had a similar idea, since details is pretty much a spoiler with a custom title, instead of adding a new tag it'd be possibly easier to implement [spoiler=title] or [spoiler="title"]. It would be necessary to keep it clear what interacting with the button will do though, so the "Show/Hide spoiler" text should remain in the button. The spoiler title could go right at its side, as in the attachment below.
_________________ My main MF acc was suspended, use other mirrors until I re-up it all to a new host.
There is no knowledge that is not power.
Our only limitations are those we set up in our own minds.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.
Programming is an art form, whose real value can only be appreciated by another versed in the same arcane art. |
|
|
Sun Mar 02, 2014 11:59 pm |
Profile PM MSN Skype
|
|
|
|
|
You can post new threads in this forum You can reply to threads in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
Do not upload or mention any illegal content. Violators will be reported to the authorities. You are responsible for your uploads and actions.
If it is illegal for you to view adult lolikon material in your current location, leave this site immediately.
LAH is in compliance with DMCA.
|