Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
5236
Off-topic / I couldn't sleep
« on December 10th, 2011, 05:22 AM »
I couldn't sleep tonight and I've been in something of a rut in terms of coding, wanting to do really little time wasting things rather than epic code production.
Now, I have a licence for http://impactjs.com/ and I finally got around to trying it, this is my first game in Impact, and I've spent maybe a little over 2 hours on it total, but I'm pretty happy with the results.[1] Uses Canvas, so needs IE 9, recent Chrome, FF 3.6+ should work alright etc.
http://arantor.org/meteor-storm/
Here's the deal: You're a spaceship caught in a meteor storm, one of your engines is burned out so you drift to the left, but you can use the other to push you to the right.
The deal ultimately is to survive as long as you can. Holding down Space will engage your engines and push you to the right but at the cost of fuel. Fuel is replenished with hitting the little petrol pump icon, though it does slowly regenerate while drifting.
How long can you last?
(Mobile... doubtful to work. I haven't done anything with respect to binding the 'buttons' on the display to anything, so I doubt it'll work on mobile, but that's a tweak for tomorrow.)
Now, I have a licence for http://impactjs.com/ and I finally got around to trying it, this is my first game in Impact, and I've spent maybe a little over 2 hours on it total, but I'm pretty happy with the results.[1] Uses Canvas, so needs IE 9, recent Chrome, FF 3.6+ should work alright etc.
http://arantor.org/meteor-storm/
Here's the deal: You're a spaceship caught in a meteor storm, one of your engines is burned out so you drift to the left, but you can use the other to push you to the right.
The deal ultimately is to survive as long as you can. Holding down Space will engage your engines and push you to the right but at the cost of fuel. Fuel is replenished with hitting the little petrol pump icon, though it does slowly regenerate while drifting.
How long can you last?
(Mobile... doubtful to work. I haven't done anything with respect to binding the 'buttons' on the display to anything, so I doubt it'll work on mobile, but that's a tweak for tomorrow.)
| 1. | The background graphics are ones that come with a demo game, the main ship/asteroids etc are mine. |
5237
Features / Re: Fixing mismatched BBCode
« on December 9th, 2011, 11:00 PM »Okay, it's like there's an endless list of bugs to fix with this...
First, my code was foolishly taking care of mismatched tags INSIDE code tags. Woops...
Obviously, this had to go. Done. I'm also not fixing anything inside nobbc tags. Anything else?
Now to an interesting bug... My s tag (strike) was not closing correctly. What the hell?
Turns out -- and I only found out after a painful debugging session -- that 's' is actually considered as a block-level tag by Wedge... This isn't the case in SMF, so I'd say it's a typo by the unknown author who moved bbcodes to the database...
Also, and this one IS in SMF, the br tag is not a block-level, while the hr tag is. It doesn't sound very logical to me... I'd tend to say they both are, though. Not that it will matter in my code anyway because it skips self-closing tags.
I'd also consider img tags to be block level... Shouldn't they?
Putting aside the semantic changes in HTML5 surrounding the a tag, consider it this way: would you consider putting an img inside an a to be valid? Answer: yes. Can't be a block tag then, because you're implicitly allowing it to be running inline.
Same question for br... answer: yes. Same reason. Although it has a layout effect, it's not something that would logically or semantically split a block element. Splitting text nodes, sure, but not splitting an element semantically. A link with a br in it would just be a vertically set link.
Both br and img are special tags in their own right because they're the class of tag that isn't markup by definition (much as hr is part of the same group) but that they have content-replacement as their focus: each tag replaces itself with content in render-time, they're not affecting presentation or structure of any other content (as a div or a span or a strong tag might). But hr doesn't logically fit being part of a link, and you'd (theoretically) never use it in an inline context, and I don't think it's valid for it to be either.
li tags and things like that are block level, and THAT bothers me a bit... Because my code treats block level tags in a special way, and I suspect this wouldn't properly add the closer tags, and instead accumulate tags. i.e. [li]Hello[li]world[/li] would add a closer after the last closer, instead of before the last opener.
We have two choices. We can manipulate it to the 'most likely' case of affairs, or we can avoid rendering it. If the regexps in preparsecode were not run, I can actually tell you what the parser would do: it would render that as a single list item with the bare li bbcode unmatched in the middle.[1]
Trouble is, with cases like this, it's sufficiently ambiguous (block or not) that we can't really make a call on how it should be changed.
FWIW, list items are considered block items because they can contain lists which are also implicitly block items.
Also. I added the code to turn a closer quote into an opener if it turned out it's at the start of a line and is followed by anything but a newline. Then I figured, okay MAYBE people could actually start a new line, type in [ /quote] and then immediately after, another [/ quote] to close a nested quote. Or even [ /code] or whatever... So I added a test for '[/' after the tag. Now, I suppose there are suddenly dozens of new ways to break this... Obviously I suppose I could test 'simply' for a-z... I don't know. It's hell.
Sometimes I wonder if we shouldn't just, ahem, call parse_bbc inside preparsecode, and have parse_bbc return a pseudo-BBC version instead of a html version... Would probably make things... easier. For me. Ah ah.
Well, I'm saying that but I've nearly reached the end... (And then in a weeks time I'll still be on it........... It's just a fucking pre-parser, arghhh!!)
I don't see where it would be impossible to implement.
We just need to always have the same code for quotes for instance... I mean, the current code generator is very simple. It can easily be emulated through jQuery to actually add that code to the post.... Heck, we could even take the quote's HTML code from within the database, and put it into a JS string...! That's the logical way to do it, even...
That, and contentEditable.
That's... interesting.
But then again, as important Unknown is the the SMF community (it's a no-brainer), I'm prepared to have his name removed entirely from posts if people shorten it to 'u'...
In our case, with my code, the missing u closer will be added.
| 1. | Well, that's what my understanding of the requires_parent code intimates it should do, put it that way, since requires_parent for li says it requires a list bbcode as a parent and it won't have one, so it should be left alone... |
5238
Features / Re: Fixing mismatched BBCode
« on December 9th, 2011, 06:38 PM »Not changing the output is opening the door to many problems... No?
There are many cases where it can be 'fixed' by using CSS and only applying the changes to them, but when you start using JS in a bbc tag...
Hmm... I dunno.
Well, if we could get the wysiwyg editor to actually show quotes as HTML, it would certainly solve a lot of issues. (And that's where my automatic quote splitter would come in very handy, because that'd really be the only way to split quotes at all...)
The only practical alternative is to have it be able to identify the quote tag (and all the header-y bits) and be able to convert it, but if people will want to customise the look of quote tags that can't be done in CSS... it's going to be ugly.
<we:code> and <we:quote>, that being said...
That's why SMF's code is so buggy, the different browsers generate different HTML fragments in the iframe.
At the risk of disappointing you -- I didn't plan for an overhaul or anything... I simply wanted to change SMF's behavior of fixing mismatched tags when it could simply return an error. Then it evolved into pointing out the exact location of the error... Then it evolved again into fixing the errors automatically when Wedge didn't, or couldn't, expect a $post_errors return message.
Hmm... I don't know, maybe we could silently remove any non-block tags, because they're mostly for details, while we could leave in the block tags where the 'bug' might actually break the post layout...?
For example, more than once I've seen people shorten [Unknown]'s name to [U], and be surprised at the result. The reason for their surprise is that other systems just silently fail to render the tag at all if there isn't a safe matching closer (IIRC vBulletin does/did this)
There's no one right answer for this.
5239
Features / Re: Fixing mismatched BBCode
« on December 9th, 2011, 10:52 AM »- wysiwyg is still hell... Saving as raw data is worse. Especially when you start changing the output for a bbcode...
- the main issue with bbc vs html, I think, is that most forum users are used to bbcode
The biggest stumbling block to WYSIWYG will always be complex bbcode that has no direct equivalent in HTML, e.g. the code or quote tags, not the simple stuff.
- wiki markup isn't very popular, I reckon. If popularity wasn't an issue, I'd have switched to SPIP code long ago
Wiki link syntax isn't clever in a forum that supports bbcode due to overloading on the [] operators not to mention the fact that you're not generally linking to conveniently titled pages (though the external link syntax is usable enough outside of operator overloading), the : indentation operator is a bit of a joke (because you don't do that in a forum generally), pipe syntax for tables is beyond a headache, but the place where wiki markup really shines is in lists.
It's almost impossible to screw up a wiki syntax list or if you do, it's usually not difficult to get it to what you want. The caveat is that it's a single line only per entry as opposed to a fully delineated entity (e.g. with li tags that can contain paragraphs, though I'm not sure that's a huge problem)
I agree about the consistency factor of bbcode, overall, it does make things consistent both for the user and the code, but it might be nice to provide wiki-style conventions as well. Probably as a plugin, though, just because it's an extra level of complexity otherwise.
It's a brave thing you've taken on there - overhauling the preparser/parser for tag mismatches was always on my todo list but I haven't been brave enough to tackle it just yet.
3- leave them be, whatever, except maybe for code tags?
We can't reach inside their mind and to a point we shouldn't be trying to do so. The most reliable of cases we can do something about but where there's any room for error, leave it be.
5241
Features / Re: Fixing mismatched BBCode
« on December 9th, 2011, 01:13 AM »
Well, going to a bigger level, consider WYSIWYG. WYSIWYG in most systems removes the need for parsing entirely because you validate it on save and you're done, you just output raw content later. Notice also that in most cases with WYSIWYG, you also don't have to contend with tag mismatches much, though the sanitisation layer should still fix any issues just in case.
This is why I'm wondering whether bbcode is entirely the right tool for this job. For simple formatting, sure, but we can use basic HTML for that too. For more complex formatting, it's a trade off between the two (tables in particular aren't a lot different between basic HTML and bbcode) while things like lists can be done much more nicely in wiki markup than in bbcode.
It does imply that we might look beyond using bbcode anyway and would trim the fat by having it done in other places and other ways. But I do like the consistency of everything being bbcode, to a point.
Hmm. It's complicated.
This is why I'm wondering whether bbcode is entirely the right tool for this job. For simple formatting, sure, but we can use basic HTML for that too. For more complex formatting, it's a trade off between the two (tables in particular aren't a lot different between basic HTML and bbcode) while things like lists can be done much more nicely in wiki markup than in bbcode.
It does imply that we might look beyond using bbcode anyway and would trim the fat by having it done in other places and other ways. But I do like the consistency of everything being bbcode, to a point.
Hmm. It's complicated.
5243
Features / Re: Fixing mismatched BBCode
« on December 9th, 2011, 12:20 AM »Yes, that's pretty much what fixNesting does...
(Well... Unless we add an errorbox for quick edit, of course. Which would not be such a bad idea...)
The end of the line?
We could always draw our inspiration from the best elements in wiki code...
There's also a PEAR library written in PHP, it seems to be nicely written albeit a bit large (30KB for main source + more for specific tags like url...), and doesn't provide a fixer by default -- but it does seem to fix tags on its side.
5245
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 11:31 PM »With most of the browsers now using a unified parsing model (the HTML5 parser), it's no longer an issue.
What do you mean unwind and reprocess?
The way it does it, ultimately, is not much different to constructing a DOM and traversing the node tree, albeit it does it in a linear rather than strict hierarchical fashion.
At each point, not only is the list of open tags maintained, plus block level evaluation, but the potential tags that can be contained inside each other, plus dependencies, are all reviewed too.
There's no way to evaluate a post and find all the instances of url bbc and immediately say beyond doubt that they will always be converted to links, because they won't even if they are otherwise legal. As I said before, there are some rules that even parsed tags cannot contain other tags (url can't contain email or url amongst other things), as well as being able to go up and down the tree in a *very* limited fashion to resolve the table-tr-td chain, which is actually defined in the bbc as well as the rules in preparsecode...
In fact, there is a very old bug on SMF's bug tracker where a table tag is malformed but because it fits the preparser's naive rules and even though there are rules defined for it, the rules aren't actually complete. IIRC, the preparser would actually break the nesting anyway under those circumstances, and that if the preparser were excluded, the main parser's handling would work properly and it would just safely fail to render the table.[1]
This is where it gets interesting. The parser will fix really obvious cases, where tags should be able to be safely closed (non block tags not being terminated when ending a block tag) but it chokes on bigger cases where nesting is broken. But if the nesting rules can be properly enforced at parser level without being broken by the preparser, tags will be safely unrendered until they can be fixed.
Now, if we were to move the full logic from the parser to the preparser, we'd be able to trap improperly nested tags too, and report on them properly.
Yeah... It'd be a candidate for deletion, I suppose.
SPIP actually supports turning opening dashes automatically into bullet points. At least it did back in 2003... Ah, good old times.
This is one place where I'm actually slightly envious of wiki markup because it actually does it sanely. It has no assumptions about hierarchy, one line is one list item, and the first blank line after the fact is the end of the list. If only it were that simple with the one character shortcuts.
Mind you, if they worked more consistently, it might encourage more use of them.
| 1. | The alternative is extra closers being injected, causing layout malfunction, seeing how this started out in SMF 1.1.x with its tabular layout. |
5246
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 11:04 PM »
It's a complicated task at the very best of times :( And it shows in browsers too, when they have malformed tags to deal with, some ignore them totally, some make assumptions with interestingly unpredictable results. I remember having a conversation with a fellow geek back in 2000 which illustrates this perfectly: he was building a site with a big complex data-heavy table in it, and it worked perfectly in IE but broke horribly in Netscape. As I discovered... he wasn't putting any of the closing tags because 'it doesn't need them'. Well, it obviously does!
It's also a rabbit hole of a problem, in that no matter how clever you get, you can pretty much always find another example that will break it. The issue is where the line gets drawn.
This is also why I think we will need to adopt the logic used in the parser to unwind and reprocess the tag nesting, simply because it's a lot more than just having balanced tags. It's a pain to get right but the result will be worth it in the end.
FWIW, I've been trying to play with this today, not getting very far with it, just because I'm still trying to get my head around how the post parser really works.
What do you reckon about the special list of tags like x or *? Do we really need them? I actually think they cause more trouble than they're worth - and they're a perfect poster child of why this whole issue is a problem, since no-one seems to know how to actually safely end such a list.
It's also a rabbit hole of a problem, in that no matter how clever you get, you can pretty much always find another example that will break it. The issue is where the line gets drawn.
This is also why I think we will need to adopt the logic used in the parser to unwind and reprocess the tag nesting, simply because it's a lot more than just having balanced tags. It's a pain to get right but the result will be worth it in the end.
FWIW, I've been trying to play with this today, not getting very far with it, just because I'm still trying to get my head around how the post parser really works.
What do you reckon about the special list of tags like x or *? Do we really need them? I actually think they cause more trouble than they're worth - and they're a perfect poster child of why this whole issue is a problem, since no-one seems to know how to actually safely end such a list.
5247
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 09:00 PM »
What I mean is, the code that fixes the above example triggers not because of the mismatch of b/s/quote but because b and s are described as non block tags and quote is a block tag. When the quote tag ends, it looks for any non block tags that are currently open, in nesting order, and closes them. The exact rules are much more complex than I've indicated but it's what forces cases like lists to not be able to contain quotes and for it to safely end the list before the quote.
I also seem to recall that the x bbcode list item is also handled in a similar way, seeing how it is not handled by preparsecode but solely within the BBC parser, and in a way that's fragile. (Frankly I don't have a problem removing the one character list builder shortcuts because I don't know anyone that uses them and whenever I've seen them used, they always break unexpectedly)
The light fixers aren't major pieces of effort in parse_bbc but anything that goes does save effort on page loads generally too.
I also seem to recall that the x bbcode list item is also handled in a similar way, seeing how it is not handled by preparsecode but solely within the BBC parser, and in a way that's fragile. (Frankly I don't have a problem removing the one character list builder shortcuts because I don't know anyone that uses them and whenever I've seen them used, they always break unexpectedly)
The light fixers aren't major pieces of effort in parse_bbc but anything that goes does save effort on page loads generally too.
5248
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 10:18 AM »But *once* it is redone through ::fixNesting, with my super-solid code etc, won't all of the remaining code become unnecessary all of a sudden...?
The only fixing I've seen preparsecode do is add code tags at the beginning or end of a post which sucks a bit...
::parse_bbc does some fixing on its own, IIRC, but if it does, it's in the wrong place. It should be done at save time, obviously. (AND, we should remove any fixer code from ::parse_bbc to force modders to go through ::preparsecode. Believe me, I didn't even know this function existed before Shitiz used it in SMG, and I didn't have the *reflex* to use it systematically until, err.... Now?)
Part of the reason parse_bbc has it and not preparsecode is that posts added to the DB through other sources that won't have come through preparsecode originally, and that's not just for modders (for example, this will include the importer unless we push every post through some kind of fixer during the import)
Still, considering that the html bbcode will do bad things if inserted manually and not through preparsecode, that nobbc may or may not work properly and other stuff, I'm inclined to think that it's OK to remove some of this stuff from parse-bbc, and move it to the preparser, provided that the preparser is able to do *everything* that parse_bbc does, which as I've alluded to, is more than just ensuring tag nesting is sane, it also has rules on what tags can contain other tags (url can't contain another url for example), on what tags must be where (list requires 1+ li, li must be inside a list, and the entire table->tr->td, both parent/children get evaluated)
I always wanted to move that to the preparser anyway to remove this dependency on strange, naive regexps that didn't allow for customising the table tag or adding th tags, without rewriting all that stuff as well.
5249
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 09:41 AM »Using the pseudo-code from above, this would be really messy -- an opening quote would be added just before the closer, and then the s and b tags would remain opened until the end of the post, where they would then be closed forcibly.
post1
The problem as you've discovered with writing such a solution is that unless you can get inside the user's brain and figure out what they meant, rather than what they typed, you have no hope of getting it consistently right. This is, incidentally, probably the one good example of where WYSIWYG actually works, because it allows people to see directly what they're using which typically means fewer mashed up tags.
5250
Off-topic / Re: Making a note for the future
« on December 8th, 2011, 12:41 AM »
If I'm brutally honest, none of the mods I've *ever* written were 'for my fans'. It's great that people find use but ultimately every mod I've written had at least one of two purposes: 1) because I needed it and 2) because it was going to teach me something about SMF. Even the mods I gave to the Customisation Team like 'Version Emulate' (putting a dropdown in the admin panel) was something I needed indirectly, to reduce support hassles.
But really, if you're doing something for you, you tend not to notice the cost (which is really where we stand with Wedge) so much.
But really, if you're doing something for you, you tend not to notice the cost (which is really where we stand with Wedge) so much.