For developers #wise_applink has float-right, #wise-appload has float-right. If we change the naming convention the first element in wise apps menu will have .float-end class and the last one (second) will have .float-begin. Also confusing ;) > Why the new table format? It needs 2 KB more space. To make it easier to understand the content of langs array. That's 5% grow in size. For end user on search.wikia.com we're sending merged JS file (search.js) with size of 309 kB. Even smaller increase :) We can also try to use GZIP content encoding to make it even smaller... -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia From rainer.blome at gmx.de Wed Jan 21 09:48:32 2009 From: rainer.blome at gmx.de (Rainer Blome) Date: Wed, 21 Jan 2009 10:48:32 +0100 Subject: [search-ui] Floatsome Message-ID: <4976EF70.4090505@gmx.de> Can anyone *point me to a resource* that explains a browser's layout algorithm? I seek answers to: How does the browser determine the width of an element - without explicit width spec - with percentage width spec - for spans - for divs Mozilla and Safari appear to use the same (weird) interpretation of percentages. With width:25%, the width of a 1px border can be significantly more than one fourth of the available width. They apparently use a width that excludes padding. To get the expected sizing makes it necessary to use an additional, padding- margin- and borderless container. IE's algorithm is more to my expectation. With width:25%, the width of the border is about one fourth of the available width. How does the browser determine the position - of the leading content (text) edge of an element - of the border of an element For example, in the attached test, I want: The content-container should float to the right of the bar-container. IE does this, the others don't. The middle-container should have the minimum height of bar-container and content-containe, the middle background (outside of the content-container) should be orange. Brown should be visible only between header and middle-container. No browser does this. The resource should help me achieve a "nested floating boxes" layout. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wikia.com/pipermail/search-ui/attachments/20090121/9a52e7e6/attachment.html From macbre at wikia-inc.com Wed Jan 21 09:47:48 2009 From: macbre at wikia-inc.com (Maciej Brencz) Date: Wed, 21 Jan 2009 10:47:48 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: <49766503.3040307@gmx.de> References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49766503.3040307@gmx.de> Message-ID: > IE 6.0 on XP SP2 does not let me switch to Hebrew, it gives an error > when I try to save the new language setting. Problem solved, should work in IE6 now... -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia From macbre at wikia-inc.com Wed Jan 21 09:56:13 2009 From: macbre at wikia-inc.com (Maciej Brencz) Date: Wed, 21 Jan 2009 10:56:13 +0100 Subject: [search-ui] Floatsome In-Reply-To: <4976EF70.4090505@gmx.de> References: <4976EF70.4090505@gmx.de> Message-ID: > Can anyone *point me to a resource* that explains a browser's layout > algorithm? W3C spec of box model is a good answer: http://www.w3.org/TR/CSS2/box.html#mpb-examples > Mozilla and Safari appear to use the same (weird) interpretation of > percentages. With width:25%, the width of a 1px border can be > significantly more than one fourth of the available width. They > apparently use a width that excludes padding. To get the expected > sizing makes it necessary to use an additional, padding- margin- and > borderless container. IE's algorithm is more to my expectation. With > width:25%, the width of the border is about one fourth of the available > width. IE approach is probably more logical (width property sets the width of the content, excluding paddings, margins and borders), but is not standard compliant... -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia From rainer.blome at gmx.de Wed Jan 21 23:17:52 2009 From: rainer.blome at gmx.de (Rainer Blome) Date: Thu, 22 Jan 2009 00:17:52 +0100 Subject: [search-ui] Floatsome In-Reply-To: References: <4976EF70.4090505@gmx.de> Message-ID: <4977AD20.5080004@gmx.de> Maciej Brencz wrote: >> Can anyone *point me to a resource* that explains a browser's layout >> algorithm? > > W3C spec of box model is a good answer: > http://www.w3.org/TR/CSS2/box.html#mpb-examples Thanks, that's the pointer that I needed. To be precise, the Visual Formatting Model (http://www.w3.org/TR/CSS2/visuren.html) is what I was looking for, which is the next chapter after the box model chapter. "width ... property specifies the *content width*", whereas I expected it to specify the width of the area that is colored with the background-color (content including padding). > Rainer Blome wrote: >> Mozilla and Safari appear to use the same (weird) interpretation of >> percentages. With width:25%, the width of a 1px border can be >> significantly more than one fourth of the available width. They >> apparently use a width that excludes padding. Unexpected, and so far mostly not what I need, but indeed standard-conforming. The "content with padding" area also serves as the containing box for descendants, making it desirable to control its width directly. >> To get the expected >> sizing makes it necessary to use an additional, padding- margin- and >> borderless container. ...just to be able to directly control the desired width. The abundance of these additional "container" divs suggests that the standard's width definition may be unfortunate. > IE approach is probably more logical (width property sets the width of the > content, excluding paddings, margins and borders), It's the other way around, for IE 6 the "width" property specifies the width of "content with padding". From rainer.blome at gmx.de Wed Jan 21 23:56:02 2009 From: rainer.blome at gmx.de (Rainer Blome) Date: Thu, 22 Jan 2009 00:56:02 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> Message-ID: <4977B612.10804@gmx.de> Maciej Brencz wrote: >> That's what I mean. The name ".float-left" is potentially confusing >> because it suggests that it means something absolute. I'd prefer to use >> names that express the intended relativity of the style property, for >> example ".float-begin" and ".float-end". > > True, but take a look at this example: > >

> Dodaj Aplikacj? >

For > developers > > #wise_applink has float-right, Yes. > #wise-appload has float-right. Where? I see only one occurrence of "right". > If we change > the naming convention the first element in wise apps menu will have > .float-end class and the last one (second) will have .float-begin. Also > confusing ;) I don't understand. A class name should truthfully reflect the effect of the class, regardless of the current layout direction. In the example of the WISE apps menu, the app links would all have class "float-begin", only the "add app" link would have "float-end". This would not change when the direction is changed, only the classes' properties would be changed. LTR: .float-begin { float:left; } .float-end { float:right; } Line beginning Line end App1 App2 App3 "Add an app" RTL: .float-begin { float:right; } .float-end { float:left; } Line end Line beginning "Add an app" App3 App2 App1 >> Why the new table format? It needs 2 KB more space. > To make it easier to understand the content of langs array. I suggest these changes: "name" -> "native" - This is the native name, as written in the language itself. Both the native and english language names are names. "desc" -> "en" - Directly expresses that these are the english language names. "rtl" -> "dir", true -> "rtl", false -> "ltr" - Allows using the value directly, without having to map it to a "dir" property value. Also allows generalization to TTB languages. > That's 5% grow in size. For end user on search.wikia.com we're sending merged JS file > (search.js) with size of 309 kB. Even smaller increase :) We can also try > to use GZIP content encoding to make it even smaller... Why don't the Wikia servers use compression? Or do they already? Do know whether this would be visible to the user, for example in page info? From phil.nelson at gmail.com Wed Jan 21 23:59:03 2009 From: phil.nelson at gmail.com (Christian Nelson) Date: Wed, 21 Jan 2009 18:59:03 -0500 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: <4977B612.10804@gmx.de> References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> Message-ID: > > >> That's 5% grow in size. For end user on search.wikia.com we're >> sending merged JS file >> (search.js) with size of 309 kB. Even smaller increase :) We can >> also try >> to use GZIP content encoding to make it even smaller... > > Why don't the Wikia servers use compression? Or do they already? > Do know whether this would be visible to the user, for example in > page info? Do we really need to worry bout compression when we're still editing the JS itself so heavily? I suppose we could use something to minify it on the fly, like http://code.google.com/p/minify/ but otherwise it seems like we'd be working across purposes. > > > _______________________________________________ > Search-UI mailing list > Search-UI at wikia.com > http://lists.wikia.com/mailman/listinfo/search-ui From jan.eschweiler at gmx.net Thu Jan 22 10:23:49 2009 From: jan.eschweiler at gmx.net (Jan Eschweiler) Date: Thu, 22 Jan 2009 11:23:49 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> Message-ID: <49784935.1070609@gmx.net> Hi, we can also use gzip compression for every files(not only JS). My php code: class abZlib { public function Init() { global $_SERVER; $OBGzHandler=(isset($_SERVER["HTTP_ACCEPT_ENCODING"]) && eregi("gzip, deflate", $_SERVER["HTTP_ACCEPT_ENCODING"])); if ($OBGzHandler) { ob_start("ob_gzhandler"); } else { ob_start(); } return true; } public function Flush() { ob_end_flush(); return true; } } Regards Cy Christian Nelson schrieb: >> >>> That's 5% grow in size. For end user on search.wikia.com we're >>> sending merged JS file >>> (search.js) with size of 309 kB. Even smaller increase :) We can >>> also try >>> to use GZIP content encoding to make it even smaller... >>> >> Why don't the Wikia servers use compression? Or do they already? >> Do know whether this would be visible to the user, for example in >> page info? >> > > Do we really need to worry bout compression when we're still editing > the JS itself so heavily? I suppose we could use something to minify > it on the fly, like http://code.google.com/p/minify/ but otherwise it > seems like we'd be working across purposes. > > >> _______________________________________________ >> Search-UI mailing list >> Search-UI at wikia.com >> http://lists.wikia.com/mailman/listinfo/search-ui >> > > _______________________________________________ > Search-UI mailing list > Search-UI at wikia.com > http://lists.wikia.com/mailman/listinfo/search-ui > > From macbre at wikia-inc.com Thu Jan 22 10:38:22 2009 From: macbre at wikia-inc.com (Maciej Brencz) Date: Thu, 22 Jan 2009 11:38:22 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: <49784935.1070609@gmx.net> References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> <49784935.1070609@gmx.net> Message-ID: > we can also use gzip compression for every files(not only JS). Yes and we can even tell Apache to do so... Responses from AjaxDispatcher are already gziped. -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia From macbre at wikia-inc.com Thu Jan 22 13:01:31 2009 From: macbre at wikia-inc.com (Maciej Brencz) Date: Thu, 22 Jan 2009 14:01:31 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> Message-ID: Hi, I've just commited my changes related to RTL version of WIkia Search UI (r723). Right now I'm making changes in private branch located at . Basically I removed position: absolute rules and changed them to float: left / right (classes "float-left" and "float-right" - names might be confusing for RTL users, but in some cases same applies to "float-begin" / "float-end"). Hardcoded border-right values were replaced with "border" CSS class. I've also simplified HTML of header and search results. JS script which sets "lang" variable also checks whether current language is LTR / RTL (based on 'rtl' entry in langs JS array) and sets class name of to "ltr" or "rtl". Still some work needs to be done with header inside index.htm -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia From rainer.blome at gmx.de Fri Jan 23 07:55:19 2009 From: rainer.blome at gmx.de (Rainer Blome) Date: Fri, 23 Jan 2009 08:55:19 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> Message-ID: <497977E7.7030307@gmx.de> Maciej Brencz wrote: > I've just commited my changes related to RTL version of WIkia Search UI > (r723). Right now I'm making changes in private branch located at > . Impressive, it already looks better than my private table-based version. The RTL flag for Arabic wasn't set, checked in a fix in cool_rtl. From macbre at wikia-inc.com Fri Jan 23 08:41:07 2009 From: macbre at wikia-inc.com (Maciej Brencz) Date: Fri, 23 Jan 2009 09:41:07 +0100 Subject: [search-ui] [Fwd: Re: RTL version of Wikia Search UI] In-Reply-To: <497977E7.7030307@gmx.de> References: <49727274.7060505@gmx.de> <298babfb0901190159r6baf18acte5c97db85398e333@mail.gmail.com> <4975148D.9050307@gmx.de> <49765FDF.10609@gmx.de> <4977B612.10804@gmx.de> <497977E7.7030307@gmx.de> Message-ID: Hi, > Impressive, it already looks better than my private table-based version. Great :) > The RTL flag for Arabic wasn't set, checked in a fix in cool_rtl. Thanks for the fix -- Maciej [macbre] Brencz macbre[at]wikia.com skype: macbre_wikia