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
3436
Features / Re: New revs
« on March 12th, 2013, 06:19 PM »
rev 1991 - Drive, driven... Gave, given... I gave myself away. / Ima, hatenai tabi ga hajimaru... Haruka na toki wo mitsumete.[1]
(23 files, 9kb)
* Renamed $context['current_action'] to just $context['action'] (it's not taken!) and replaced all awkward $_REQUEST['action'] tests with that. Also, the action is now exclusively retrieved from $_GET, rather than $_REQUEST. I don't think there's a reason to look into post data... Sub-actions are also stored in $context['subaction'], but there are more occurrences to replace, and I can't bother for now. Anyone..? (index.php, SSI.php, and two dozen files I won't bother listing.)
+ Added another (tentative) new hidden setting, $settings['default_action']. It's the equivalent of $settings['default_index'], and has priority over it. 'default_index' holds a filename (it has to contain a function with the same name), while 'default_action' holds an action name. This allows you to override the index page's default action, which is usually home or boards, and still set the $context['action'] variable correctly, something I'm afraid default_index doesn't provide for. It will be needed in some situations, such as Aeva Media being set at the default homepage: because it tests for empty actions, it could give unexpected results in the homepage. Would love to discuss the repercussions of this all! (index.php)
- Removed an empty($action) test that would never return true, because the test was already done earlier and resulted in a return. Pete..? (index.php)
* Reverted a <URL> which I'm not sure would be working. Well, it's just one, won't bother testing thoroughly. (Subs-Template.php)
* Moved respond.js inclusion for oldIE to avoid generating it for Ajax templates. (Load.php)
! Fixed animation of the search pop-up. Unfortunately, this adds about 20 bytes to our JS, but I couldn't find a tighter way to do it, otherwise I'd have done that. I even had to fight with what I suspect is a jQuery bug... (script.js)
(23 files, 9kb)
* Renamed $context['current_action'] to just $context['action'] (it's not taken!) and replaced all awkward $_REQUEST['action'] tests with that. Also, the action is now exclusively retrieved from $_GET, rather than $_REQUEST. I don't think there's a reason to look into post data... Sub-actions are also stored in $context['subaction'], but there are more occurrences to replace, and I can't bother for now. Anyone..? (index.php, SSI.php, and two dozen files I won't bother listing.)
+ Added another (tentative) new hidden setting, $settings['default_action']. It's the equivalent of $settings['default_index'], and has priority over it. 'default_index' holds a filename (it has to contain a function with the same name), while 'default_action' holds an action name. This allows you to override the index page's default action, which is usually home or boards, and still set the $context['action'] variable correctly, something I'm afraid default_index doesn't provide for. It will be needed in some situations, such as Aeva Media being set at the default homepage: because it tests for empty actions, it could give unexpected results in the homepage. Would love to discuss the repercussions of this all! (index.php)
- Removed an empty($action) test that would never return true, because the test was already done earlier and resulted in a return. Pete..? (index.php)
* Reverted a <URL> which I'm not sure would be working. Well, it's just one, won't bother testing thoroughly. (Subs-Template.php)
* Moved respond.js inclusion for oldIE to avoid generating it for Ajax templates. (Load.php)
! Fixed animation of the search pop-up. Unfortunately, this adds about 20 bytes to our JS, but I couldn't find a tighter way to do it, otherwise I'd have done that. I even had to fight with what I suspect is a jQuery bug... (script.js)
| 1. | I'm running out of ideas... These are cool songs, but nowhere as good as my 70's favorites :P |
3437
Features / Re: New revs
« on March 12th, 2013, 05:12 PM »
rev 1990 - Don't forget to try in mind, ai wa Jewel yori, subete wo kagayakasu...[1]
(5 files, 11kb)
* Changed SKIN_SIDEBAR string constant to two boolean constants: SKIN_SIDEBAR_LEFT, and... SKIN_SIDEBAR_RIGHT. This will be useful for the feature below. (Subs-Cache.php, Msg.template.php, Warm/skin.xml)
+ Added ability to test against skin constants from anywhere that uses the generic we::is test function. For instance, in a CSS file, doing @if (mobile) determines whether the user is using a mobile device, while @if (SKIN_MOBILE) will determine whether the current skin is targeted to mobiles (i.e., currently, the Wireless skin.) (Subs-Cache.php)
+ Added support for <else> fallbacks in skin.xml/skeleton.xml conditional tests. For instance, <if SKIN_MOBILE><do_something><else><something_else></if>. Self-described. (Subs-Cache.php)
* Updated msg mini-skeleton to make use of the new <if> system. I don't know about you, but I think it looks more complicated than it used to... ;) Well, at least it's shorter. (Display.template.php, Msg.template.php, skeleton.xml)
* Cleaned up many unused globals in the Msg template. Not sure if they're all cleaned up by now... But they probably are. (Msg.template.php)
@ Still unsure whether we should remove all SKIN_MOBILE tests from the Msg template -- or not care too much, considering the number of occurrences is now low enough to make it a very minor performance hit.
(5 files, 11kb)
* Changed SKIN_SIDEBAR string constant to two boolean constants: SKIN_SIDEBAR_LEFT, and... SKIN_SIDEBAR_RIGHT. This will be useful for the feature below. (Subs-Cache.php, Msg.template.php, Warm/skin.xml)
+ Added ability to test against skin constants from anywhere that uses the generic we::is test function. For instance, in a CSS file, doing @if (mobile) determines whether the user is using a mobile device, while @if (SKIN_MOBILE) will determine whether the current skin is targeted to mobiles (i.e., currently, the Wireless skin.) (Subs-Cache.php)
+ Added support for <else> fallbacks in skin.xml/skeleton.xml conditional tests. For instance, <if SKIN_MOBILE><do_something><else><something_else></if>. Self-described. (Subs-Cache.php)
* Updated msg mini-skeleton to make use of the new <if> system. I don't know about you, but I think it looks more complicated than it used to... ;) Well, at least it's shorter. (Display.template.php, Msg.template.php, skeleton.xml)
* Cleaned up many unused globals in the Msg template. Not sure if they're all cleaned up by now... But they probably are. (Msg.template.php)
@ Still unsure whether we should remove all SKIN_MOBILE tests from the Msg template -- or not care too much, considering the number of occurrences is now low enough to make it a very minor performance hit.
| 1. | I think it's the only TV show where I had my name in the ending credits, for some reason. 8-) |
3438
Features / Re: Icon alignment
« on March 12th, 2013, 03:58 PM »Ah, you're forgetting one thing about inlining something versus the HTTP request for it: the saving of that round trip. Sure, the DNS will be reused as will the HTTP connection (at least in theory), but the actual bandwidth of the request saved easily is more than 5 bytes. In fact it's probably into the hundreds of bytes I saved, while making it faster. If you look at a single page in isolation, sure, you'll see an increase - especially if it's a page without the sort image, but the incremental cost is lower on any pages that do use it.Quote That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes...
These sort images are linked thematically so it's okay to sprite them (you can't change one without changing the other!), but theoretically there's no need to sprite them. Just embed them both. The only extra cost is the 5 bytes I mentioned. No round trips.
I don't really care much either way. The key thing is that I get to push things into the CSS that weren't in the CSS before and the easiest way I know of doing that is a sprite.
I'm not fussed if you'd prefer me to keep individual images and use url-no-base64 instead to call them.
Hmm. I'd be inclined to leave it as-is and change it on requirement.Quote 3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.
Leave what as is? All icons?
Then, I suppose, strip the vertical-align out of .inline-block and then fix stuff as I find them..?
Hmm...
3439
Off-topic / Re: Women in the Workplace/Life
« on March 12th, 2013, 02:51 PM »
Hmm, whatever Opera bugs are, it's hard to go and look into them when you know that they'll eventually drop Presto for WebKit, and thus will get a host of new bugs but not the original ones they used to have until now... :(
And thanks for what? :^^;:
And thanks for what? :^^;:
3440
Features / Icon alignment
« on March 12th, 2013, 01:13 PM »
I was looking into more layout-related code, and couldn't remember why .inline-block forces a vertical-align: middle.
Which got me into looking at inline blocks again... Been a very long time, really.
One of the things I never liked in my code, is that inline blocks are never properly aligned with any text content beside them.
It particularly shows in cat/title blocks, where I have to assign some kind of vertical-align hardcoded pixel value to align the icon next to the title, only the number differs on every browser... Originally I did all of my calculations on Opera, but now that I'm using Chrome on a daily basis, I keep seeing icons that are off by a pixel or two. Most people won't mind, but I do.
The thing with inline blocks, is that their height is the same as the text next to them. By default. So, I did a few tests and... It's really easy to align icons. Just remove any vertical-align crap, any hardcoded height, and then include the icon with background: url(...) no-repeat center. The 'center' is really what does it.
While there's a definite advantage to simplifying our icon code (and believe me, it will), there are also three drawbacks to this method, and this is why I'm not going to implement it without feedback.
1/ There are tons of icons, and it requires changing their HTML one by one, manually. It's okay... I can handle it. But it's not pretty.
2/ Sprited images.
- Obviously, can't set a 'center' on them, because they'll show something else on the side. So... Do we get rid of sprites for any icons that inherits .inline-block?
- Pete likes them (true enough, the sort.gif image is 90 bytes, as opposed to 146 bytes for sort_down+sort_up). However, the magic of gzip ensures that small images may sometimes compress very well through Wess. In this case, I tried doing the same code with the two separate images, and went from 29085 bytes to 29096... That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes... The 143 bytes in sort_down+sort_up are compressed to exactly 84 bytes, while the 90 bytes in sort.gif are compressed to 79. (And they said base64+gzip wasn't helpful to compress images... :P Well, that's probably due to the fact that there are other GIF files in our CSS, and they share similar, if not identical, headers and palettes.)
3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.
So... What do you think..?
Which got me into looking at inline blocks again... Been a very long time, really.
One of the things I never liked in my code, is that inline blocks are never properly aligned with any text content beside them.
It particularly shows in cat/title blocks, where I have to assign some kind of vertical-align hardcoded pixel value to align the icon next to the title, only the number differs on every browser... Originally I did all of my calculations on Opera, but now that I'm using Chrome on a daily basis, I keep seeing icons that are off by a pixel or two. Most people won't mind, but I do.
The thing with inline blocks, is that their height is the same as the text next to them. By default. So, I did a few tests and... It's really easy to align icons. Just remove any vertical-align crap, any hardcoded height, and then include the icon with background: url(...) no-repeat center. The 'center' is really what does it.
While there's a definite advantage to simplifying our icon code (and believe me, it will), there are also three drawbacks to this method, and this is why I'm not going to implement it without feedback.
1/ There are tons of icons, and it requires changing their HTML one by one, manually. It's okay... I can handle it. But it's not pretty.
2/ Sprited images.
- Obviously, can't set a 'center' on them, because they'll show something else on the side. So... Do we get rid of sprites for any icons that inherits .inline-block?
- Pete likes them (true enough, the sort.gif image is 90 bytes, as opposed to 146 bytes for sort_down+sort_up). However, the magic of gzip ensures that small images may sometimes compress very well through Wess. In this case, I tried doing the same code with the two separate images, and went from 29085 bytes to 29096... That's an extra 11 bytes. With a bit of CSS simplification, I went down to 29090. Only 5 more bytes... The 143 bytes in sort_down+sort_up are compressed to exactly 84 bytes, while the 90 bytes in sort.gif are compressed to 79. (And they said base64+gzip wasn't helpful to compress images... :P Well, that's probably due to the fact that there are other GIF files in our CSS, and they share similar, if not identical, headers and palettes.)
3/ If the icon is taller than the current text, it won't resize to fit. So, the icon will be partially hidden. I can't think of many situations where this is desirable.
So... What do you think..?
3441
Off-topic / Re: Women in the Workplace/Life
« on March 12th, 2013, 10:48 AM »Yeah, but then we're accused of being pig-headed, arrogant and/or misogynistic.* Arantor has been down this road.
Posted: March 12th, 2013, 10:36 AM
My point is that anyone can rant about injustice and gender, a woman can also rant about injustice just as easily as men and their rants are just as valid to them as mens rants are valid to men.
There will never be anything like gender equality.
Posted: March 12th, 2013, 10:45 AM
Sidenot, on Opera 12.14 the page does this weird bouncing thing.
Posted: March 12th, 2013, 10:46 AM
Consider, for example, spousal abuse. If a man hits a woman, that's thoroughly wrong - as it should be. But what if a woman hits a man? Don't tell me it doesn't happen. It's just as wrong, but it's perceived differently because of the gender bias.
Well, if they're well-educated enough, they also know that violence isn't the solution to violence... Not that they COULDN'T handle themselves, they'd just decide NOT TO.
That's where it gets funny... No?
3442
Features / Re: Mini-skeletons
« on March 12th, 2013, 10:20 AM »
Nope, it would be displayed to: members if it's NOT a mobile skin, OR guests (in all situations), OR people running IE7 if the skin has set the sidebar to be on the right.
Maybe it's time to get rid of "," as an OR separator, and instead force the use of || everywhere, like in PHP or JavaScript... Since Wess is programmer-oriented and there's already support for brackets, bangs and ampersands, it would make more sense.
The main problem with the <if> implementation, if anything, is that it's never going to be enough...
I've been working on rewriting the skin since last night, and found that:
- there are situations where part of a block is skipped in SKIN_MOBILE (msg_author_group) and forces me to have two identical functions, a mobile one and a desktop one, with the only difference being an extra code block for desktop,
- some blocks are unskippable... Namely, the _before and _after tricks. In msg_author_after, SKIN_MOBILE is also tested, and I can't "skip" this test from within the skeleton. It would force me to write a different wrapper from msg_author just for skins...
But that would result in: <if !skin_mobile><msg_author><blocks for desktop></msg_author></if><if skin_mobile><msg_author_mobile><blocks for mobile></msg_author_mobile></if>... So much for flexibility if we have to maintain two very similar versions of <msg_author>'s before and after pseudo-blocks. :-/
Meh...
I'm still converting the stuff. You'll all decide after that, I guess...
Support for <else> added (and tested). It's so much easier when you don't have to care for indenting (as it's all pseudo-XML), I feel like a cheat! :lol:
Maybe it's time to get rid of "," as an OR separator, and instead force the use of || everywhere, like in PHP or JavaScript... Since Wess is programmer-oriented and there's already support for brackets, bangs and ampersands, it would make more sense.
Posted: March 12th, 2013, 09:46 AM
The main problem with the <if> implementation, if anything, is that it's never going to be enough...
I've been working on rewriting the skin since last night, and found that:
- there are situations where part of a block is skipped in SKIN_MOBILE (msg_author_group) and forces me to have two identical functions, a mobile one and a desktop one, with the only difference being an extra code block for desktop,
- some blocks are unskippable... Namely, the _before and _after tricks. In msg_author_after, SKIN_MOBILE is also tested, and I can't "skip" this test from within the skeleton. It would force me to write a different wrapper from msg_author just for skins...
But that would result in: <if !skin_mobile><msg_author><blocks for desktop></msg_author></if><if skin_mobile><msg_author_mobile><blocks for mobile></msg_author_mobile></if>... So much for flexibility if we have to maintain two very similar versions of <msg_author>'s before and after pseudo-blocks. :-/
Meh...
I'm still converting the stuff. You'll all decide after that, I guess...
Posted: March 12th, 2013, 10:12 AM
Support for <else> added (and tested). It's so much easier when you don't have to care for indenting (as it's all pseudo-XML), I feel like a cheat! :lol:
3443
Plugins / [Plugin] Re: Improved attachments upload
« on March 12th, 2013, 09:48 AM »
I installed your copy yesterday, but didn't look into it I have to admit.
3444
Features / Re: Mini-skeletons
« on March 12th, 2013, 08:26 AM »
Implemented, and working. :)
Oh, and you can do silly things like this:
<if !SKIN_MOBILE && member, guest, ie7 && SKIN_SIDEBAR_RIGHT>
<my_monster_block />
</if>
I know... Very useful :lol:
I'm considering whether to allow for lowercase skin_* tests in skeletons and other we::is() places, though. It does feel more natural to me... I don't know..? Opinions please?
Oh, and you can do silly things like this:
<if !SKIN_MOBILE && member, guest, ie7 && SKIN_SIDEBAR_RIGHT>
<my_monster_block />
</if>
I know... Very useful :lol:
I'm considering whether to allow for lowercase skin_* tests in skeletons and other we::is() places, though. It does feel more natural to me... I don't know..? Opinions please?
3445
Features / Re: Mini-skeletons
« on March 11th, 2013, 08:15 PM »
I agree, booties are cool.
What do you mean, though? That you agree I should use booleans for the sidebar constant..?
What do you mean, though? That you agree I should use booleans for the sidebar constant..?
3446
Plugins / [Plugin] Re: Improved attachments upload
« on March 11th, 2013, 05:20 PM »
And I didn't get a warning for that post either...
Although I just got one for your latest, but it's because you posted it before I hit the Reply button, so I had the warning at post time, not post2 time, basically.
This needs fixing, because it will make people miss on posts, as they're expecting to be told when someone posted in the meantime...Quote from Arantor on March 11th, 2013, 04:51 PM Probably some discussion I missed. Did that happen after I restored your admin access, maybe..? Otherwise it must be a very old discussion, and I remember having the plugin enabled here...Quote It got disabled when I changed its name, but I'm pretty sure I re-enabled it...
Quote from Arantor on March 11th, 2013, 04:59 PM That 'last' param in the URL... Is it only checked against correctly...?Quote Oh, don't talk down to your elders! I'm young enough to remember things! Well, at least part of the things! What was I talking about, already..?Quote I'm of the opinion that this should be done at post time... i.e. if you post an attachment from within a certain topic, get the topic, then the board, get its group list, attach these groups to the item's permissions.
Hmm, does that imply creating a new album on the fly, matching these..? I don't know. I don't remember if AeMe has a setting to fine-tune permissions per-item. I'M NOT OLD!!! I'm just rusty.Quote Well, in some situations I suppose you wouldn't mind...Quote Or we could just store the id_board in the item table, yeah, and do a {query_see_board} on that.Quote I don't rem....I'm not old!!
Although I just got one for your latest, but it's because you posted it before I hit the Reply button, so I had the warning at post time, not post2 time, basically.
This needs fixing, because it will make people miss on posts, as they're expecting to be told when someone posted in the meantime...
There was certainly a bug with it affecting events and at least once it was disabled for that reason.
It is currently disabled but there's other reasons why that might be (as other plugins are also disabled without any reason I'm aware of for that)
Posted: March 11th, 2013, 05:14 PM
Hmm, it should still have warned. Something is very much amiss.
The problem that I mention isn't that at all, I wouldn't mind but I have mentioned it multiple times now.
If you have an attachments system like that, you need to be able to reference the topic it came from, not so much for 'which topics use this' but 'can the person see this attachment'.
Hmm, does that imply creating a new album on the fly, matching these..? I don't know. I don't remember if AeMe has a setting to fine-tune permissions per-item. I'M NOT OLD!!! I'm just rusty.
Would really suck if attachments could be leeched without having proper board access.
Right now, access to a given file is based on its album. But that doesn't work for attachments whose access rights are implicitly different. Thus you need to be able to indicate where a given media item is supposed to get its authentication from, be that an album or thread access.
I did suggest one method of doing this but you weren't very keen on it.
3447
Features / Re: Plugin revs
« on March 11th, 2013, 05:04 PM »
rev 76
(1 file, 1kb)
! Commenazi (wrong ID). (mass_attach/attachui.js)
! Integrated Dragooon's fix for non-file drops. (mass_attach/attachui.js)
(1 file, 1kb)
! Commenazi (wrong ID). (mass_attach/attachui.js)
! Integrated Dragooon's fix for non-file drops. (mass_attach/attachui.js)
3448
Plugins / [Plugin] Re: Improved attachments upload
« on March 11th, 2013, 04:53 PM »
Hmm, didn't get a "new post" warning when sending the last one, even though I'd posted another... Maybe because it was one of mine..?Quote from Arantor on March 9th, 2013, 11:53 PM (Eh..?!)Quote The reason that topics don't use AeMe for attachments is, errr... It's not an *architectural* issue (what's to be afraid of? Creating a generic "Attachments" album where all attachments will go..? Adding a feature to keep track of all topics that make mention of an item? I also wanted to code that one anyway...), it's more that I'm a perfectly reasonable man, and the days I spent on AeMe were crazy, and I did a lot on it, and I know that even after I did all that, there were still tons of bugs, and I was weary of moving the bugs to the attachment system.
But really, the real reason, in reality, is really that, really, I'm super-fucking lazy and I try to focus on features that require less than a week to implement... And this one... It even requires writing a converter!! Eh!! And I'm not going to ask TE to do it... :^^;:
Sure I remember that. I'm still convinced it's ultimately not a blocker for it being a core feature, but simply that the selector is not as selective as it should be about grabbing events.
Mostly I think Nao and I have been quietly hoping the other will have a sudden idea on how to solve the architectural issues that come out of it but I think that in the end I'll just have to go in and do it. There is one aspect to it that is rather awkward to solve but not unsolvable, it's just figuring out how to do it without breaking the crap out of everything.
But really, the real reason, in reality, is really that, really, I'm super-fucking lazy and I try to focus on features that require less than a week to implement... And this one... It even requires writing a converter!! Eh!! And I'm not going to ask TE to do it... :^^;:
3449
Plugins / [Plugin] Re: Improved attachments upload
« on March 11th, 2013, 04:49 PM »Nobody told me about this?Quote from Plugin revs Dragooon, I'm still waiting for your approval to change the author ID to Wedgeward
Well, the plugin isn't "public" yet, so I didn't bother to ask you too much.
I didn't even know there was an alternative copy of this plugin in Wedge's plugin repository :P.
I don't mind the author ID change, but there has to be a better way to maintain the repository. Can't it be some sort of svn:external with the master in my GitHub account?
Posted: March 11th, 2013, 04:49 PM
Remember the bug where a selected word in the posting box being dragged would trigger this plugin's event? That's why it was removed from this site...
I don't even know what bug you're talking about.
BTW, whatever became of the ambitious dream to replace attachments with media items?
3450
Features / Re: Mini-skeletons
« on March 10th, 2013, 10:40 PM »
So...
- First implementation of your request is in revision 1988.
- I only dealt with we::is tests, which don't encompass skin options.
- It should be trivial to add support for basic skin options in wedge_skin_condition() (also, feel free to rename the function.)
- But I didn't do it (yet!) because my focus was on harmonizing user/browser tests to also include other specifics that are in skin filenames, i.e. member (instead of just 'guest'), mXXX (member #XXX), bXXX and cXXX (specific boards and categories). And I'm trying to determine if skin options belong here..??! I'd tend to say 'yes, they do', but while it's easy to test against '!SKIN_MOBILE', it's more time-consuming to do more elaborate things like 'SKIN_SIDEBAR == left' in a we::is test... I'd be tempted to say, maybe SKIN_SIDEBAR should be renamed to SKIN_SIDEBAR_LEFT/SKIN_SIDEBAR_RIGHT/SKIN_SIDEBAR_NONE, at least it'd become a simple boolean test... What do you think?
- I've tested exclusively with a single test in skin.xml, where I'm loading a font for myself. It worked. It may break in other situations, and in skeletons.
It's 22:36 and although a bit early to go to bed, I've had a very, VERY long week, I'm tired, and I decided to commit this and let you play with it (and have a chance to comment on my design decisions, or even fix anything), instead of postponing my commit to tomorrow.
So... Have fun ;)
- First implementation of your request is in revision 1988.
- I only dealt with we::is tests, which don't encompass skin options.
- It should be trivial to add support for basic skin options in wedge_skin_condition() (also, feel free to rename the function.)
- But I didn't do it (yet!) because my focus was on harmonizing user/browser tests to also include other specifics that are in skin filenames, i.e. member (instead of just 'guest'), mXXX (member #XXX), bXXX and cXXX (specific boards and categories). And I'm trying to determine if skin options belong here..??! I'd tend to say 'yes, they do', but while it's easy to test against '!SKIN_MOBILE', it's more time-consuming to do more elaborate things like 'SKIN_SIDEBAR == left' in a we::is test... I'd be tempted to say, maybe SKIN_SIDEBAR should be renamed to SKIN_SIDEBAR_LEFT/SKIN_SIDEBAR_RIGHT/SKIN_SIDEBAR_NONE, at least it'd become a simple boolean test... What do you think?
- I've tested exclusively with a single test in skin.xml, where I'm loading a font for myself. It worked. It may break in other situations, and in skeletons.
It's 22:36 and although a bit early to go to bed, I've had a very, VERY long week, I'm tired, and I decided to commit this and let you play with it (and have a chance to comment on my design decisions, or even fix anything), instead of postponing my commit to tomorrow.
So... Have fun ;)