« Quick moderation
Trying something a bit new
¿BBCode tabs? »

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #15, on February 24th, 2012, 05:30 PM »
Okay, I hope you won't mind too much but I've fixed some things that needed fixing in the skeletons, so it's possible that you'll need to fix them too in Wintage... At worst, you'll just need to copy some of the stuff from the Wine/skin.xml file.
Quote from Arantor on February 24th, 2012, 04:12 PM
For the info centre, InfoCenter.template.php. Under the <we:title> is a div with an explicit 8px height.
Ah, yes... I think I added that one as a quick hack to make it 'work' because the padding wasn't very good for this particular occurrence.
Even if Wedge is miles ahead of SMF when it comes to theming, templating and CSS, it still inherits a few of its oversized CSS so sometimes I'm just too lazy to look into what's breaking padding etc... :-/
Quote
Now put a single border around those items, with a 1px padding between the border and the content, and leave the content such that you can still put borders on the content that butt up against the 1px padding+border (e.g. the someotherstuff div has a gradient but a 1px darker border on it)
I see. Feel free to add a wrapper or remove anything... But technically speaking, it might also break other design possibilities. (For instance, breaking up a large div into several horizontal divs certainly makes it impossible to put a gradient on the first div and expect it to continue flawlessly in the following ones. Unless you set the parent div's position to relative and the children to absolute, and set a large height for the first child... Uh.)
Quote
i.e. replicating the Core layout.
I was more of a Babylon guy, myself, BTW :)
The first Noisen theme (back when it was running SMF 1.1) was based on Babylon. I still like it a lot.
Quote
Certainly late, but interesting idea. Personally, though, I'd rather strip the indentation instead of outputting it - simply because it should save a bit of bandwidth, no?
Well, it certainly would be feasable... Could even have an admin setting to determine whether you want 'correct' indenting (i.e. based on skeleton tabs), or bandwidth/CPU-saving indenting (i.e. nothing done), or bandwidth-saving indenting (i.e. removing all indents at run time, including the hard-coded ones.)
Although yeah, it's really indenazi territory at this stage... ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #16, on February 24th, 2012, 05:40 PM »
Quote
Okay, I hope you won't mind too much but I've fixed some things that needed fixing in the skeletons, so it's possible that you'll need to fix them too in Wintage... At worst, you'll just need to copy some of the stuff from the Wine/skin.xml file.
*nods* Well... I did spend some time last night poking at it and trying to break stuff, and more than once I wondered idly if I was doing it wrong or not - no matter what I did, it seemed like I could only have the sidebar on the right, or on the left above the content (because it wasn't floating correctly) but that in hindsight could just as easily have been me doing it wrong heh - yesterday was a very strange day for me in a lot of ways, nothing really made perfect sense...

Though looking at the latest rev, seems that it might have been more than just me that was intrigued by it.
Quote
Ah, yes... I think I added that one as a quick hack to make it 'work' because the padding wasn't very good for this particular occurrence.
Well, I might switch it out for a class, that way the theme can control it how they see fit.
Quote
But technically speaking, it might also break other design possibilities. (For instance, breaking up a large div into several horizontal divs certainly makes it impossible to put a gradient on the first div and expect it to continue flawlessly in the following ones. Unless you set the parent div's position to relative and the children to absolute, and set a large height for the first child... Uh.)
This is the problem, ultimately, with skins vs themes; sometimes the theme code just doesn't allow for a given combination of styling - so you end up having to have alternative markup available.
Quote
The first Noisen theme (back when it was running SMF 1.1) was based on Babylon. I still like it a lot.
Babylon is still well designed. It's just not quite what I want from a theme, and I find the smoother gradients in Core make it more palatable for me personally.
Quote
Well, it certainly would be feasable... Could even have an admin setting to determine whether you want 'correct' indenting (i.e. based on skeleton tabs), or bandwidth/CPU-saving indenting (i.e. nothing done), or bandwidth-saving indenting (i.e. removing all indents at run time, including the hard-coded ones.)
I'm sensing a touch of overkill here - most admins don't actually care whether it's correct or not. Plugins almost certainly won't be correct anyway.

The other thing is, does it make a difference in gzip size? I know that sometimes you can end up saving far less than you thought by not removing things like spaces.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #17, on February 24th, 2012, 06:23 PM »
Okay...

- A concept for you to play with: dynamic replacement of HTML code. In skin.xml:

<replace for="ie6,ie7">
  <from><aside id="sidebar"></from>
  <to><table id="sidebar" class="top"><td></to>
</replace>

It's just an example, because it'd be impossible to find the closing div, and thus to do a full replacement -- I think. Unless we do some recursive regex matching... I dunno. Without it, that would allow adding extra divs, but only if you could also match the next div opener to add a closer before it.

- removing tabs on a typical page will save about 100 bytes after gzipping. It's not something to be ignored, but it's not that much compared to a typical (small) page size of 5KB gzipped. About 2% worth...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #18, on February 24th, 2012, 06:40 PM »
I LIKE IT! That said, I see your point about finding the end div, and I don't think there's a good way to solve that at all, sadly.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #19, on February 24th, 2012, 08:31 PM »
<from><div I'd="sidebar">{match}</div></from>

If match is met in the request, and is followed by a closer, turn it into a regex with recursively. Can be done. Just doesn't feel very natural.

<to><i >{match}</i></to>

I hate the iPod when it comes to typing HTML in...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #21, on February 25th, 2012, 12:39 AM »
So... I've been thinking about it a bit more... Couldn't find a perfect solution. Right now the best realistic code I have is this:

Code: [Select]
<replace>
<from-start><aside id="sidebar"></from-start>
<from-end></aside></from-end>
<to-start><div id="sidebar"></to-start>
<to-end></div></to-end>
</replace>

If <from> is used, a simple replace is done. Otherwise, Wedge would build a recursive regex out of <from-end>, or it would simply step through the code until it meets an unmatched closer, which has my preference these days (it's probably not faster, but at least it's not subject to any security problems.)
Maybe use from-opener and to-closer etc instead of start and end, although it'd imply we only support one tag in these, when there could be more. Or perhaps it could be made simpler for skinners...

Code: [Select]
<replacenode>
<from><aside id="sidebar"></from>
<to><div id="sidebar"></to>
</replacenode>

Replacing a "node" would look into the HTML in 'from', extract the tag name, and look for the closer. Then it would replace the opener normally, and would replace the closer with the tag extracted from the 'to' entry.
That one, obviously, would require having only one tag.

Finally, there's also the possibility of giving freedom to skinners, but they'd also need to learn regex...

Code: [Select]
<replace>
<from-regex><aside id="sidebar">(.*?)</aside></from-regex>
<to><div id="sidebar">$1</div></to>
</replace>

Would obviously require that skinners know how to encode the request for preg_replace. *And* know how to do a recursive regex... (I suppose I could provide one for inspiration. But it would still require work on their side...)
Posted: February 25th, 2012, 12:38 AM

BTW, I also have in my to-do-list a @replace command for WeCSS... Although it's a bit on the backburner for now, because I'm not sure where best to implement -- in the same way as my @remove code, possibly, although it might be smarter to do it either before the parsing, or after the processing.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #22, on February 25th, 2012, 12:58 AM »
I like the idea of the regex but I suspect it's going to be a bit much for themers. Heck, regex is beyond most mod authors too.

Regarding @replace, what are the benefits and problems with doing it before parsing and what are the benefits/problems to doing it after?
Re: Trying something a bit new
« Reply #23, on February 25th, 2012, 03:12 PM »
Dragging this back on topic a bit, I did some more work on fixing the styling up. Notably, I've altered the menu to be reminiscent of Core's menu - but not that similar.

The board index still needs work as does post display, but the message index looks good :)

📎 wedge_wintage_2.png - 39.54 kB, 640x512, viewed 201 times.

📎 wedge_wintage_3.png - 41.55 kB, 640x512, viewed 199 times.

Dr. Deejay

  • Happy new year all!
  • Posts: 118

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #25, on February 25th, 2012, 04:03 PM »
And remember, this is *purely* done using the theme system - there are no new templates involved.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #26, on February 25th, 2012, 06:15 PM »
Quote from Arantor on February 25th, 2012, 12:58 AM
I like the idea of the regex but I suspect it's going to be a bit much for themers. Heck, regex is beyond most mod authors too.
That's what examples are for...
If I provide an example for a simple div replacement, then it should be alright. Maybe I could even document it in comments, or something. Coming up with a recursive regex is hard. Adapting it to other tag types is easy.
Quote
Regarding @replace, what are the benefits and problems with doing it before parsing and what are the benefits/problems to doing it after?
Post-parsing is a no-no if done after the base64 replacements. Other than that, it should be good enough.
Pre-parsing, I don't know. The main issue with doing it at the same time as @remove is that it does add a bit more processing time compared to pre or post parsing. That's really the only thing... I'd like to move @remove to pre-processing, but technically it's not doable, because if you remove an entry and its selector only had that entry, you end up with an empty selector entry which usually means parsing problems in WeCSS...
Posted: February 25th, 2012, 05:52 PM

In the end I went for the pre-parsing way. Works perfectly, and its only costs a preg_match_all. (I could make it a bit faster though, by preventing @remove from having tabs or spaces before it.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #27, on March 18th, 2012, 08:26 PM »
Hmm, I probably should pick up on this again now that one of the things which bugged me has been fixed in the base theme ;)

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Trying something a bit new
« Reply #28, on March 18th, 2012, 10:49 PM »
What was it?

Btw I should add support for @remove specificity, ie being able to add a selector filter right after the keyword... That'd be good. And maybe even a wildcard like "background: *" so that any changes to the parent won't affect this...

Oh, and about the iPod preventing me from typing: seems to fix itself once it first saves that empty draft. But I don't know if drafts are the cause. The same issue happens when I get asked for my admin password...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Trying something a bit new
« Reply #29, on March 18th, 2012, 10:55 PM »
I actually mentioned it in a thread somewhere: I wanted to be able to put a border around just the categories themselves, not around the entire table, but that wasn't possible with Curve style markup. But in the last few weeks I rewrote the board list markup[1] so that it generated separate tables for each category, with their own thead and tbody rather than having category headers, board contents and the divider all being separate tbody elements.
Quote
Btw I should add support for @remove specificity, ie being able to add a selector filter right after the keyword... That'd be good. And maybe even a wildcard like "background: *" so that any changes to the parent won't affect this...
That'd be pretty awesome.
Quote
Oh, and about the iPod preventing me from typing: seems to fix itself once it first saves that empty draft. But I don't know if drafts are the cause. The same issue happens when I get asked for my admin password...
If it's occurring in the admin password, it's not related to drafts. That's the thing, I could understand it if there was a problem with the textboxes since even QR now uses a full reply box (with hidden content), hence the draggable bottom border. But I don't know about any issues with the admin password box.

I probably should use my own iPod a lot more for testing but right now it's waiting to be packed up with the rest of my stuff.
 1. Though I don't remember doing it to the child board listing in message index.
« Quick moderation
¿BBCode tabs? »