New theme(?) with green headers..

New theme(?) with green headers.. Started by Bloc · June 17, 2013, 11:32:15 am · Read 31931 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Re: New theme(?) with green headers..

Reply #45 – June 22, 2013, 08:41:06 am

Quote from: Antechinus – June 22, 2013, 08:16:24 amWell how can you customise it then? There's already custom code for Elk tied in with the editor, and there's no point making a request to Sam Clark for stuff that is specific to another project. Also, the options that are edited are minor and are highly unlikely to inhbit upgrades.

Also, is anyone going to downlaod the pile of code I did? It's been sitting there for over 48 hours without being touched, but the tiny zip for the editor has already been downloaded.

I see that its minor, but its still a difference, so unless someone wants to create a elk fork of the editor and maintain it and make PR's back to Elk when it changes, etc and bla bla bla personally I'd like the editor, in total, to be maintained by the Sam so upgrading is a simple file replace. (that resize code actually changed a lot from various versions due to complications with various browsers supported)

I just downloaded the code, don't get yer knickers in a knot

ETA: https://github.com/elkarte/Elkarte/pull/574 But I probably missed some of the image updates

Re: New theme(?) with green headers..

Reply #46 – June 22, 2013, 05:16:42 pm

Quote from: emanuele – June 22, 2013, 08:26:54 amoptions.resizeMaxHeight and the others are already ways to customize the max height and width of the editor (AFAIR).

Ok, where are the settings for them? In the file I edited, or hiding somewhere else? If there's a better way of setting them I'm happy to use it, but I think the default behaviour doesn't really make sense.

I often want a textarea larger, often a lot larger, but I've never wanted one to collapse below its default size. It's sort of messy at the moment, and IMO would be better if the textarea was constrained so it couldn't go below its default height or width, or above its default width. It would feel more stable when dragging it to expand it.

I have sometimes wanted a textarea to expand past default width, but that only applies to tiny ones. Our editor is already sufficiently wide.

The default max-height limit makes no sense at all. That's just a PITA.

Quote from: Spuds – June 22, 2013, 08:41:06 amI just downloaded the code, don't get yer knickers in a knot

Yeah but I had to kick you first.

Re: New theme(?) with green headers..

Reply #47 – June 22, 2013, 10:06:18 pm

Ok cool. I found out how to do it properly.

Code: [Select]

		 * Max resize to height, set to null for double textarea height or -1 for unlimited
		 * @type {int}
		 */
		resizeMaxHeight: null,
		/**
		 * Max resize to width, set to null for double textarea width or -1 for unlimited
		 * @type {int}
		 */
		resizeMaxWidth: null,
		/**
		 * If resizing by height is enabled
		 * @type {Boolean}
		 */
		resizeHeight: true,
		/**
		 * If resizing by width is enabled
		 * @type {Boolean}
		 */
		resizeWidth: true,

Change to:

Code: [Select]

		 * Max resize to height, set to null for double textarea height or -1 for unlimited
		 * @type {int}
		 */
		resizeMaxHeight: -1,
		/**
		 * Max resize to width, set to null for double textarea width or -1 for unlimited
		 * @type {int}
		 */
		resizeMaxWidth: null,
		/**
		 * If resizing by height is enabled
		 * @type {Boolean}
		 */
		resizeHeight: true,
		/**
		 * If resizing by width is enabled
		 * @type {Boolean}
		 */
		resizeWidth: false,

That doesn't set a fixed min-height equal to default height, but does stabilise the width and allow unlimited max-height.

Re: New theme(?) with green headers..

Reply #48 – June 23, 2013, 06:40:20 pm

Hey would that be acceptable, since it's in the options section of the file, or do you want it set somewhere else? If the options can be set where the editor is intiialised or somewhere else, I don't mind doing that before resubmitting the code. Just need to be pointed at the right bit of the right file.

Re: New theme(?) with green headers..

Reply #49 – June 25, 2013, 07:25:17 pm

Ok you Webkit and Presto peeps, your silly browsers wont handle numerical font-weight. They only know normal or bold. Firefox, and even IE, will do a font-weight of 600, which in many places is much better than either bold or normal.

Since I don't have to look at what Webkit and Presto do, I don't much mind which they get. If the consensus is that the bold is too heavy, I can serve them normal weight. We haz body id by browser (someone clever though of that).

Re: New theme(?) with green headers..

Reply #50 – June 25, 2013, 08:11:24 pm

I've found a mix of color and bold/normal goes a long way in separating items and/or lowering their visibility. Different bold values seems a bit too unreliable, both on the account of the failing support in browsers(webkit as it seems) and the slight differences there will be in different systems regarding the chosen font-type. Plus the different resolutions yield different results in the anti-aliasing and rendering of said fonts. There is a noticeable difference in quality between 1080p and something like 1024px screens.

In short, it can never be 100% the same all over - thus very small differences in appearance, like bold/slightly less bold, will be less effective than other things IMHO. I've opted to NOT do browser-specific styles/adjustments even, only adding vendor-specific on certain css3 styles just to trigger the styles. That means less amount of styles to work with(less alternatives to figure out) but also a requirement that the ones I do use, must work acceptable all over, if not exactly 100% copies of each other.

But, of course, a broader palette is always nicer to work with.

Re: New theme(?) with green headers..

Reply #51 – June 25, 2013, 08:21:41 pm

600 is pretty safe, because it just defaults to bold anyway. It doesn't seem to do anything weirder than that, and it does look much better in Firefox and IE, which are a significant chunk of the target market.

Then again, I suppose I should fire up Browsershots again and check everything they've got. There might be an odd surprise lurking in some dark corner.

PS: Firefox and IE will also do a pretty good 100 weight, although it's of limited practical use (large text only, really).

Re: New theme(?) with green headers..

Reply #52 – June 25, 2013, 08:34:07 pm

Seems to be pretty good in just about any combo. http://browsershots.org/requests/9060392

Re: New theme(?) with green headers..

Reply #53 – June 26, 2013, 02:58:33 am

Quote from: Antechinus – June 25, 2013, 07:25:17 pmOk you Webkit and Presto peeps, your silly browsers wont handle numerical font-weight.

Don't know if you know, but Presto is going to die with the next release of Opera that will use Webkit.

Re: New theme(?) with green headers..

Reply #54 – June 26, 2013, 03:13:12 am

Well that will leave Webkit being the problem, but just on more browsers.

Re: New theme(?) with green headers..

Reply #55 – June 26, 2013, 05:41:31 pm

If you have a moment in one of the next updates, consider changing the color of the numbers in the menu (for example the number of PMs), the current black is really difficult to read with the dark-green background.

Re: New theme(?) with green headers..

Reply #56 – June 26, 2013, 06:45:12 pm

Yeah saw that yesterday. I was thinking a small pop-up link might be good. With the click menus you can see you've got a message, but you have to open a droppy before you can go to inbox.

So if I hack teh sauces a bit and make a little anchor that pop-ups and goes straight to inbox on click, that might be handy.