Wedge

It makes me wonder how much of the attitude is just jealousy. I don't know, I don't really care, don't know why I'm wasting any energy on worrying about what they think.

Should it merely be off by default in those cases, or hidden completely?

It'd be workable but I suspect not that practical because future commits may or may not end up having that.

Git promotes a style of forking and merging complete features, not gradual iteration.

Yes. Not quite as complicatedly as that, but yes. I wasn't planning on doing anything particularly glamorous or elegant, but functional. (i.e. just calling the relevant template function with the current board's row as its details)

I think the downsides to 1) make it enough reason I don't like it, I can fully see that being a problem otherwise.

For 3), call it virtual, it's not abstract by definition. As far as large mixins go, as long as we don't ourselves use anything too massive I don't really see a problem. I don't see us including base64 stuff in the main file - and we're not responsible for keeping themers super-efficient. (As it is, WeCSS deals with things a lot better than SMF anyway)

I agree that both methodologies[1] have their pros and cons but since WeCSS is - sensibly - on the class extension side, you're right in that it should use it to the end.

windowbg is a special case because it has no right home, it's not quite either mixin/extends nor OOCSS because it's both stylistic and semantic. It's like we need to split it up into its roles and have windowbg simply extend that.

1.	I kept wanting to write mythologies

Well, assuming you mean the choice of themes per board, that's primarily so that you can theme different areas of the site relatively easily, and pretty much unrelated to what I'm talking about.Still not really what I'm talking about, though sort of.


What I'm getting at is that right now, the board index can only display one of two things, a regular board or a redirect board. If you want anything different, tough. What I want to do is be able to give plugin authors and theme authors the ability to restyle it without having to fight too much to make it happen.

I like the idea of being able to allow extensions etc. to be able to extend the base classes, something I'm sure I had trouble with at some point.

I don't really think 2 is an option, but what's the downsides of 1 and 3 vs their specific benefits?

As well you should, GMT != UTC anyway. The two are different notably that UTC is UTC is UTC and never varies, even for DST while GMT is only the placeholder assigned to Britain etc. during the winter months. There are some minor vagaries involved at the system level too but nothing to worry about.Odd, 12.04LTS (last I installed it) didn't use any geo-location, it asked me my language first and foremost and since I'd said English UK, it just went from that.

What did you put in as your language?Not going to happen.

1. Geolocation is a rat's nest, and that's going to get worse, not better, as IPv4 exhaustion will lead to buying and selling blocks.
2. We don't have the resources to generate the relevant lists, and I don't see us paying for the maintained lists - and that's a good way to push upgrading.
3. I'm fairly certain there are privacy implications.
4. The alternative is to use the Location API but not all browsers support is and of those that do, they all ask first for permission to use the API. Fairly certain most users would say no.
5. Other than IP address, the only other measure is the language code, which may or may not be accurate and it won't tell you the location of the user in all cases.