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 - Nao
3736
Features / Re: Template edits
« on February 1st, 2013, 10:48 PM »
Only one hook?
So plugins use that hook to modify the skeleton and inject their templating right?

I'll also need to determine how many functions we split posts into.
3737
Features / Re: Template edits
« on February 1st, 2013, 07:41 PM »
Quote from Arantor on February 1st, 2013, 05:27 PM
So, we want to add in 14 function calls per post we make?
That's the thing... I'm perfectly content with not allowing anything :P

Oh, well.
Macros: no function call, but we'll add one hook (and thus, at least one function call, perhaps two if at least one hook is indeed used), per tag (including closer tags, that's x2). Maybe only call a hook if the tag has a variable in it...? (as in, "this is not your momma's macro"?)
Mini-skeleton: at least one function call per skeleton item. That's potentially less than for macros, unless you want to turn every single area into a function.
Quote
Now imagine I want to totally trash that and replace it with something else? How do I do that from the macro, exactly? Normal template skeleton is easy: I just invoke wetem to replace that element.
Oh, it's doable... I'm just not sure how right now... But the macros are all visible inside $context... They're only handled in ob_sessrewrite after all.
Quote
This is what I mean about having the flexibility of a template skeleton in there, because I (and others like me) will want to rearrange it. I'm trying, essentially to save us work in the long run by making this flexible and easy to change later on because I know people will want to change it.
Well, I feel you really want a mini-skeleton, so I'll code it.
Do you want it to be available in skin.xml? Or only through PHP calls..?
Quote
Which brings me to my other problem. I don't entirely like setting rules on what people can and can't do with the platform. Having hooks necessarily puts limitations in and I want to minimise that where possible.
But do we add automagic hooks to the skeleton system?
3738
Features: Forward thinking / Re: jQuery support
« on February 1st, 2013, 07:32 PM »
Alrighty.

I'm just annoyed by the .prop() thing right now... Everything else should be converted (I think), but .prop... It needs some looking into. I guess.
3739
The Pub / Re: Remove flash dependency from AeMe?
« on February 1st, 2013, 05:25 PM »
Hmm... I thought they went out of beta years ago...

And still. I enabled it (re-enabled it?), and it still tells me Flash Player and all... Funny.

I guess it's only important on mobile, anyway.
3740
Features: Forward thinking / Re: jQuery support
« on February 1st, 2013, 05:23 PM »
I think jQuery 1.4 works with the latest 'legacy' jQuery UI, same as with v1.5...

http://w3techs.com/technologies/details/js-jquery/all/all

This page has interesting statistics for per-version usage.
As I thought, v1.4 is the most widely used 'legacy' version, i.e. that's when jQuery stabilized, having acquired all of its important features and fixed all of its major shortcomings. It went downhill after that, until the jQuery team made the (right) decision to focus on stripping code out of their codebase for v2.

But I was pretty sure v1.5 was more widely used than that. It isn't... However, even v1.4 is not that widely spread. It has a market share of about 20%, meaning that about 10% of all major websites use that version, and you have a relatively good chance of having it in your cache -- but it's not as good a chance as simply going for the most widely available version. As of now, it looks like it's v1.7, but I have good hopes that once we release Wedge to the public, v2.0 will be the most widely used one. (Or maybe v1.9...? That would not be as nice.)
3741
Features / Re: Template edits
« on February 1st, 2013, 05:18 PM »
Quote from Arantor on February 1st, 2013, 04:41 PM
1. Performance is going to be impacted, though not *massively* with extra hooks per template/macro/whatever.
It's always going to be impacted. It's either this... Or SMF mods. Hurray for choice...
Quote
2. It's still way too simplistic and doesn't achieve any of the things I really wanted out of a mini skeleton.
I'm not so sure.
Quote
It lets me change the markup for the things around the content, but it doesn't easily let me add new items with any control. Supposing I wanted to replace the likes feature with something else. How do I do that?
<we:postlike>our like code</we:postlike>...? It's just a matter of determining how many macros we want to put into the loop.
Quote
Suppose I wanted to add more icons to the poster information, in a separate area under everything else. How do I do that?
Call the hook for </we:poster>... (Oh yes that means having two hooks per macro, hmm...)
Imagine </we:poster> says '</div>'. Just call the hook, get the macro contents in it, add <mycode> at the beginning, and voilà.
Quote
Suppose I want to move the avatar above the group badges, how do I do that?
That one's more of a problem.
Quote
Bear in mind also that macros are one-off replacements per page, not per post which means more complexity to be attached.
Oh, I also have a solution for that... Just implementing variables inside hooks, like I'm doing for the skeleton (see the bottom linktree one.) These variables would be carried along with the hook. Of course, that does mean doing something strange in our HTML, such as echo '</we:poster:', $id_msg, '>...
PS: macros are already quite powerful as it is -- look at the <if:param> if anything. They *can* be extended. It's mostly a matter of determining what you want to do with them in the end, and what you don't want them to be able to do, ever.
3742
Features: Forward thinking / Re: jQuery support
« on February 1st, 2013, 04:43 PM »
Quote from Arantor on February 1st, 2013, 04:34 PM
Of course it wasn't worth it just for that. But I can see the logic of a single unified beast for it.
It's unified to a limit... Doing the big jump is the hardest one, after that it should be fairly easy to upgrade jQuery along with the main one, but then again we have two codebases to keep up with -- one for oldIE, one for HTML5 browsers.
Quote
The thing about it is that there's an awful lot of legacy stuff to keep in mind too.
Like..?
Quote
I don't know... I'm fairly happy with what we have... *shrug*
v1.4: the shortest one... Has all the features we need.
v1.5: a bit bigger, not even sure it fixes anything. Just adds an Ajax rewrite that doesn't really change a thing, except for the callbacks.
v1.6: big pile of crap, followed by a 'mehh..' 1.6.1
v1.7: meh.
v1.8: meh.
v1.9: meh!
v2.0: no IE support, yay!

So, in order to be able to benefit from v2.0 (shorter + likely to have less bugs...???), we have to go through a larger version for oldIE, as well as potentially more bytes in our code because of the .prop() changes. (Oh, you know me -- I'll optimize the code here and there to at least compensate for the loss...)

To me, it makes sense to go back to 1.4, as much as it makes sense to stay at 1.5 or go for 1.9/2.0.
The main consideration should be plugin authors. What do you want? The latest & meanest? Or the old ones that may be more compatible with whatever plugin you want to use?

(It's interesting to note that the jQuery plugin server 'broke' for so long... It's as if they wanted people NOT to download old outdated plugins. It's a conspiracy :P)
3743
Features / Re: Template edits
« on February 1st, 2013, 04:35 PM »
Quote from Arantor on January 18th, 2013, 07:46 PM
I'd prefer it to be a bit *more* complicated, not less. Not for performance as such (though that's important) but because I'd love plugins to be able to be flexible. For example being able to juggle the order of items around in the poster area and inject new items in between things as desired.
Hmm...
I had an alternative solution in mind, which doesn't really fit your description.
Heck, I'll still mention it...

It's two-fold.
1/ Turning posts into macros. In the template we could have this:
<we:postwrapper>
  <we:poster>our poster data...</we:poster>
  <we:post><we:abovepost>our post header</we:abovepost><we:postbody>our body</we:postbody><we:belowpost>our buttons</we:belowpost><we:signature>our signature</we:signature></we:post>
</we:postwrapper>

Fill the macros with the usual -- and offer, for instance, an alternative that would use table tags to force buttons and signature at the bottom of a post if the body is just a couple of lines and the avatar is huge. One of the things that has bothered me ever since SMF 2.0 Beta 1 came out... ;)

2/ Implement a hook into macro replacement -- i.e. when I'm showing we:postwrapper, I'll automatically call_hook('macro_postwrapper'), where a plugin is then free to add their own code.

Point (2) is something I dabbled with when I was looking at skeleton code -- I mentioned it in my earlier posts (which I have difficulty remembering correctly, I guess I'll have to re-read this topic), I'd really like to add automatic hooks into template functions, so that plugins can add stuff without having to actually add a template override function (which might be already taken anyway...)

Anyway... That was what I was considering, because it's relatively easy to implement, and would allow plugins to add stuff to every post that would use macros.

Then again, this technique doesn't allow plugins to reorder elements within a mini-skeleton. But it also doesn't require us to provide miniature functions for each and every area of every post. I dunno...
Quote
Override blocks replace the entire block, often that is not necessarily useful, though it can be for some cases.
Say a template function only consists of function template_something() { echo '<div>'; }... You can replace that with a <table> or a <span>, whatever you want. Of course, more functions = more freedom and also more CPU used. You can't eat your cake and have it[1]
Quote
The thing about having such blocks is that they're more for the theme to perform overrides rather than plugins doing it - plugins are going to do it via the skeleton anyway, but it is nice to have the choice.
Yep, but that's precisely why it'd be a good thing to associate a hook with every single template function and their derivatives... (et le cul de la fermière[2].)
Quote
I'd argue that's overkill to be honest. Anyone that really wants to do that will inject into the buffer changes at the end.
That's a better alternative, indeed...
 1. I prefer the bawdy French version, "On ne peut pas avoir le beurre, l'argent du beurre et le cul de la fermière". It's worth digging out that old French dictionary eheh.
 2. :ph34r:
3744
Features: Forward thinking / Re: jQuery support
« on February 1st, 2013, 04:14 PM »
Quote from Arantor on February 1st, 2013, 04:11 PM
The only thing I liked about .prop() for replacing .attr() was slightly saner handling of the checked attribute, as in you had to .attr('checked', 'checked') and .removeAttr('checked') to change it, but with .prop() it's simpler and could be done inline with a ternary expression.
Sure. But just for that one..? Not worth it.
Quote
Other than that it seemed like a change almost for the sake of change.
Which we don't want, either.

I'm starting to wonder whether it isn't too early to switch to jQuery 1.9+2.0... I mean, I'm only thinking of the 'release date', it'll be okay in that fashion, but what was the reason for the switch, already...? Saving 300-400 bytes in v2.0 for non-IE browsers..? Only that? Or something else? lol...

I would have better used my time today had I instead worked on thinking of the mini-skeleton implementation... :^^;:
3745
The Pub / Re: Remove flash dependency from AeMe?
« on February 1st, 2013, 04:04 PM »
I'm in Chrome, and all I can see when I right-click a video is a long menu and, at the end, "Flash Player Settings". <sigh>
3746
Archived fixes / Re: sb refresh does not update scrollbar
« on February 1st, 2013, 03:52 PM »
Quote from Arantor on February 1st, 2013, 03:08 PM
It's nothing to do with where it comes from, it's a bonus feature of the parser. If you don't want that, don't enable it ;)
Ah, yes... Forgot about that one :)
Should be disabled.
<br>
Yay.

Is it enabled by default? I don't remember... It's neither something for a 'forum for dummies' ("HTMwhat?"), neither for techies ("why can't I post my HTML code to the forum?")...
Quote from Arantor on February 1st, 2013, 03:08 PM
Easy enough to reproduce, have a <select> with at least 15 items, call .sb() on it the first time and it sets it up. Then call .sb() again.
So... Doing it on the timezone one, for instance..?
Quote from Arantor on February 1st, 2013, 03:08 PM
The calendar is the easiest way to see it but it's not the only way. It's normally not an issue because most of the selectboxes aren't that long, or where they are, they're not re-initialised.
I'm starting to be ashamed of my select box code... (Apart from the fact that it holds the dubious world record for shortest select box with scrollbar and all :P)
3747
The Pub / Re: The Cookie Law (in the UK at least)
« on February 1st, 2013, 03:45 PM »
Quote from Arantor on February 1st, 2013, 03:15 PM
Of course it is. (Yes, Prime Minister is also a good show but only the original incarnation. The remake is shite.)
I saw there's a 2013 version when I went to get my subtitles for the original, lol. How is it so bad in comparison? And is the original Yes Prime Minister any good, too? (i.e. seasons 4-6 or something.)

I never watched YM in the first place because I don't have such excellent memories of The New Statesman, which was one of the first British sitcoms to be shown in English with subtitles in France, back in the early 90's. Heck, for a long time I thought they were the same shows... I'm only at 1x04 but I really like it. The characters are well played, they're all likeable and the gimmick is interesting (i.e. starting the episode with the Minister trying to do something better for the UK, and ending up having to compromise because of reality checks.)
Quote
I'd be fine with a core notice disabled by default - I just think we should include it for those who need it. I could even make it a plugin really... As long as it's available, easily, for those who feel they need it.
Well, as of now, it's much easier to implement into Wedge than it would have been if you'd had to disable cookies by default..! :^^;:

Might be a good opportunity to get rid of PHPSESSID though :P
3748
Features: Forward thinking / Re: jQuery support
« on February 1st, 2013, 03:41 PM »
Correction, they didn't remove .delegate! Then only removed .live and .die, possibly to force users to update their code. Granted, .live is not as efficient as .delegate, but why not delete ALL at least from v2.0 so they could save more bytes...? I don't see the point.

Anyway.

My biggest problem right now is with .attr() vs .prop()... I was under the impression that jQuery had, from v1.6.1, turned back and decided to let people do as they wish. Apparently, their Migrate plugin indicates that they're back to the "use .prop if it's a property" thing...
Heck, if they could only provide a complete guide with what exactly needs to be converted. I don't see any. I have to GUESS. jQuery is there for SAVING time, not WASTING it... -_-
I even waste a dozen minutes earlier today when I saw they'd removed support for $().error(), and I thought $.post().error() (which we use in topic.js or post.js, something) was in the lot. It wasn't. I posted on their blog to complain that they should update their documentation about that.

My...
Give me another week like that, and I'll definitely write my own 10KB jQuery equivalent.
3749
Archived fixes / Re: sb refresh does not update scrollbar
« on February 1st, 2013, 01:07 PM »
Is there a way to reproduce this without installing the calendar...?

The scrollbar system is far from perfect. Just yesterday I had to play with < br> tags to prevent a reflow in the JS packer select box.

:edit: Hmm, I thought HTML tags were only taken 'as such' in quick reply, but even quick edit seems to do it on the br tag...?!
3750
Archived fixes / Re: parse_bbc_inline does not process colors
« on February 1st, 2013, 01:05 PM »
If you'll look at the code, parse_bbc_inline DOES process colors, but only if you tell it to use the full set of inline tags.

I think the reason was mostly that I dislike this tag personally, so I couldn't see myself moving it to the shortlist :lol:
And although it can't break designs, it can break good sense. So I'd tend to say, "if you want color tags, make sure to ask for the full set when dealing with parse_bbc_inline."