From: Eoghan Ó C. <eog...@gm...> - 2009-12-08 15:12:46
|
Hi, I'm not sure if this is entirely relevant to your discussion, but I remember that in his talk on using Yahoo CSS Framework ( http://video.google.com/videoplay?docid=-5133887282042525979#) Chris Barr mentioned that Yahoo recommend a !DOCTYPE of HTML 4.01. Eoghan 2009/12/8 Demian Katz <dem...@vi...> > The XHTML spec includes some notes on HTML4 compatibility: > > http://www.w3.org/TR/xhtml1/#guidelines > > If we work with these guidelines, I think we can make the themes both XHTML > and HTML4 compatible. Perhaps there's some show-stopper that I'm not aware > of, but at a glance, I didn't spot any major problems. I've already taken > care of most (if not all) of the entity encoding issues (i.e. use of bare > ampersands in place of &). Other changes like <br> ==> <br /> and > checked ==> checked="checked" can probably be done with reasonably simple > search and replace operations. I see no harm in starting some of these > tasks as incremental improvements. If we're left with any big problems > after that, we can discuss on a case by case basis. > > Feel free to open a JIRA ticket for this if you want while you're in the > area. > > - Demian > > > -----Original Message----- > > From: Tuan Nguyen [mailto:tu...@yo...] > > Sent: Tuesday, December 08, 2009 9:32 AM > > To: Demian Katz > > Cc: Barnett, Jeffrey; vuf...@li... > > Subject: Re: [VuFind-Tech] please test/comment > > > > We can definitely cleanup the existing themes. The only reason I > > wanted to add a new one was to allow people who are not using xhtml in > > their general templates to still stick with html4. Perhaps that is a > > non-issue. > > > > On Dec 8, 2009, at 9:23 AM, Demian Katz wrote: > > > > > Thanks. > > > > > > Do you see any reason why we can't update the existing themes to be > > > XHTML compliant? I'd rather not add a third theme -- it's enough > > > work to maintain two as it is -- but I certainly see the advantages > > > to having more standardized HTML in the templates we've already got. > > > > > > - Demian > > > > > >> -----Original Message----- > > >> From: Tuan Nguyen [mailto:tu...@yo...] > > >> Sent: Tuesday, December 08, 2009 9:20 AM > > >> To: Demian Katz > > >> Cc: Barnett, Jeffrey; vuf...@li... > > >> Subject: Re: [VuFind-Tech] please test/comment > > >> > > >> I'll post it to JIRA later today. > > >> > > >> For 1.0, I would like to propose that we work on a new theme that > > >> will > > >> be using xhtml (transitional ???) so people won't have to do too > > much > > >> clean up to have VuFind fits in to their existing xhtml general > > >> templates. > > >> > > >> > > >> > > >> On Dec 8, 2009, at 9:08 AM, Demian Katz wrote: > > >> > > >>> That definitely sounds pretty safe to me, especially since the > > >>> relative paths in the patch all stay within the /web folder anyway, > > >>> so none of them should even cross potential symbolic link > > boundaries > > >>> in your setup. > > >>> > > >>> To allow more time for testing and discussion, and in case there's > > >>> some factor I'm not thinking of, I'm not going to put this in the > > >>> trunk before RC2 is released... but it's probably a good candidate > > >>> for inclusion in 1.0 if nobody finds a problem in the meantime. > > >>> > > >>> Tuan, would you be willing to post your patch to JIRA so we don't > > >>> lose track of it? I can do it for you if you prefer. > > >>> > > >>> thanks, > > >>> Demian > > >>> > > >>>> -----Original Message----- > > >>>> From: Barnett, Jeffrey [mailto:jef...@ya...] > > >>>> Sent: Friday, December 04, 2009 12:16 PM > > >>>> To: Demian Katz; Tuan Nguyen; vuf...@li... > > >>>> Subject: RE: [VuFind-Tech] please test/comment > > >>>> > > >>>> You are right I expect about the client side perspective (since it > > >> is > > >>>> css rather than php or java). Our layout is each site's document > > >>>> root > > >>>> is in /usr/local/xxfind (mounted at "/"), but with ./import and > > >> ./web > > >>>> (and in one case ./solr) linking to different file systems. Two > > of > > >>>> the > > >>>> sites share a common ./import location. > > >>>> > > >>>> -----Original Message----- > > >>>> From: Demian Katz [mailto:dem...@vi...] > > >>>> Sent: Friday, December 04, 2009 11:57 AM > > >>>> To: Barnett, Jeffrey; Tuan Nguyen; vufind- > > >>>> te...@li... > > >>>> Subject: RE: [VuFind-Tech] please test/comment > > >>>> > > >>>> In this case, I would expect the relative path processing to > > happen > > >>>> client-side (where the exposed URL should be independent of the > > >>>> file > > >>>> system layout) rather than server-side (where links can cause > > >>>> inconsistencies like you describe). Of course, it is not > > >>>> unprecedented > > >>>> for my expectations to be wrong. In any case, if you get a chance > > >> to > > >>>> test at some point, please let us know what happens... though I > > >>>> understand it may be a while. If you don't think you're going to > > >> get > > >>>> to it at all, you could also give me a general idea of your file > > >>>> layout, and I can try to reproduce it on my test system. > > >>>> > > >>>> thanks, > > >>>> Demian > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Barnett, Jeffrey [mailto:jef...@ya...] > > >>>>> Sent: Friday, December 04, 2009 11:34 AM > > >>>>> To: Demian Katz; Tuan Nguyen; vuf...@li... > > >>>>> Subject: RE: [VuFind-Tech] please test/comment > > >>>>> > > >>>>> I have seen relative links break other web pages, I have not > > tried > > >>>> this > > >>>>> exact patch. Right now we are trying hard to stabilize our > > setup, > > >>>>> so > > >>>> I > > >>>>> may not get a chance to try it before our deadline of 12/18, but > > >>>> maybe > > >>>>> after that. To be clear, it isn't that they don't resolve, but > > >> that > > >>>>> they resolve incorrectly... ignoring the higher level symlink in > > >>>> favor > > >>>>> of the "native" directory structure of the file system. > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Demian Katz [mailto:dem...@vi...] > > >>>>> Sent: Friday, December 04, 2009 11:22 AM > > >>>>> To: Barnett, Jeffrey; Tuan Nguyen; vufind- > > >> te...@li... > > >>>>> Subject: RE: [VuFind-Tech] please test/comment > > >>>>> > > >>>>> It's my understanding that relative image links in CSS files are > > >>>>> supposed to be resolved by the web browser as being relative to > > >>>>> the > > >>>> URL > > >>>>> of the directory containing the CSS file. I wouldn't expect > > >> server- > > >>>>> side file system architecture to have any impact on how the > > >>>>> browser > > >>>>> resolves paths. I could be mistaken about this, but if you > > >>>>> haven't > > >>>>> actually tested the patch yet, it might be worth a try to be sure > > >> it > > >>>>> will really break your setup. If you've already tested it and > > >>>>> proven > > >>>>> that it won't work, then I apologize for doubting you -- I just > > >>>> wanted > > >>>>> to be sure. > > >>>>> > > >>>>> A couple of other comments: > > >>>>> > > >>>>> 1.) If it turns out that the relative path thing won't break > > >>>> anybody's > > >>>>> setups, I think some of the relative paths in the patch could be > > >>>>> made > > >>>>> even shorter... for example: > > >>>>> > > >>>>> background- > > >>>>> image:url(../../../../interface/themes/default/images/rc2.jpg); > > >>>>> > > >>>>> could be simplified to: > > >>>>> > > >>>>> background-image:url(../images/rc2.jpg); > > >>>>> > > >>>>> 2.) If we can't safely get away from the PHP processing, I don't > > >>>> think > > >>>>> we gain much by replacing $configArray['Site']['path'] with a > > >>>>> local > > >>>>> variable. It might be worthwhile for readability purposes, but I > > >>>>> wouldn't expect to see any significant performance change. I'm > > >> sure > > >>>>> accessing a variable directly is faster than indexing into a two- > > >>>>> dimensional array, but it's still a fast memory operation either > > >>>>> way. > > >>>>> > > >>>>> - Demian > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Barnett, Jeffrey [mailto:jef...@ya...] > > >>>>>> Sent: Thursday, December 03, 2009 4:45 PM > > >>>>>> To: Tuan Nguyen; vuf...@li... > > >>>>>> Subject: Re: [VuFind-Tech] please test/comment > > >>>>>> > > >>>>>> I can see the desirability of reducing calls to > > >>>> $configArray['Site'], > > >>>>>> but reliance on relative urls will break some sites (like mine) > > >>>> where > > >>>>>> different portions of the vufind directory tree reside on > > >> different > > >>>>>> file systems joined via symlinks. What about an approach that > > >>>>> fetched > > >>>>>> $configArray['Site'] once to a local variable and then reused > > >>>>>> that > > >>>>>> result for the rest of the processing? > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Tuan Nguyen [mailto:tu...@yo...] > > >>>>>> Sent: Thursday, December 03, 2009 10:39 AM > > >>>>>> To: vuf...@li... > > >>>>>> Subject: [VuFind-Tech] please test/comment > > >>>>>> > > >>>>>> It seems there are some unnecessary execution of css files and > > >>>> extra > > >>>>>> parsing of config.ini in themes/default/css. I cleaned up the > > css > > >>>>> files > > >>>>>> as much as I can so that we don't need to execute those css > > >>>>>> files > > >>>>> any > > >>>>>> more. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> ---------------------------------------------------------------- > > -- > > >> - > > >>>> -- > > >>>>> -- > > >>>>>> ------- > > >>>>>> Join us December 9, 2009 for the Red Hat Virtual Experience, > > >>>>>> a free event focused on virtualization and cloud computing. > > >>>>>> Attend in-depth sessions from your desk. Your couch. Anywhere. > > >>>>>> http://p.sf.net/sfu/redhat-sfdev2dev > > >>>>>> _______________________________________________ > > >>>>>> Vufind-tech mailing list > > >>>>>> Vuf...@li... > > >>>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech > > >>> > > > > > > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > |