Re: svn: /web/php/trunk/ include/header.inc js/common.js js/jquery.autocomplete.js js/jquery.autocomplete.pack.js styles/structure.css
styles/theme.css

On Wed, Dec 29, 2010 at 02:14, Stewart Lord <stewey@ambitious.ca> wrote: > On Tue, 28 Dec 2010 19:13:21 +0100, Hannes Magnusson > <hannes.magnusson@gmail.com> wrote: >> We should probably create it during manual build time then from PhD. >> Then I suppose we could also create a description file.. If that won't >> be huge :] > > Sounds good! Hmh.. How did you generate the original file? It seems to only contain functions, not methods or chapters or anything.. Thats not intentional, is it? When I dump the entire PhD index (including chapters and methods) I get: 120K output/php-web/search-description.json.gz 100K output/php-web/search-index.json.gz I do wonder though.. Should we try to categorize/chunk the files so we can improve the search priority and do as we originally wanted, split the search results into "categories". - functions - methods - chapters - references - appendixes - ... That would help, especially for description matches (i.e. searching for "audio" would give you http://php.net/manual/en/wrappers.php.php for example) >>> It occurs to me that we could shrink the index file substantially by >>> dropping the 'name' and 'page' keys and just adopting the >>> convention > that >>> name and page are elements 0 and 1 respectively. >> >> Thats not gonna matter once the data is .gzipped.. jQuery won't care, > will >> it? > > You are right. Uncompressed it saves 78K, gzipped it only saves 2K. > > Are you asking if jQuery will care about gzip? I don't think it will know > the difference. If we gzip it we will need to make sure we emit the correct > content encoding headers for the browser to decode it. Some browsers don't > support gzipped JS - not sure if we care to support those or not. That was what I meant yeah, but then I thought about it a little and remembered both YSlow and Chromium Audit and everyone else recommend compressing js :) -Hannes