That would simply assume that any URL within the CSS file is a
relative URL, which seems to be a safe bet. Having absolute URLs in
there doesn't make too much sense anyway, at least not in this
context.
Jörn
On Sun, Oct 5, 2008 at 7:11 AM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote:
> Good stuff! One post from Jörn is better than a thousand from me, hehe :)
> I'd say however that even the /* [relative-url] */ marker is not necessary
> and just another chance for error. What you could do simply is find all
> url(....) references and extract the necessary URL details within. It's
> probably not as simple as that but you get the gist. :)
>
> On Sun, Oct 5, 2008 at 2:52 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>>
>> That sounds great. I would still want a cssDir and imagesDir in the json,
>> so that I could simply use the last part of the relative URL marked with /*
>> [relative-url] */ and know where the images actually were in the package.
>> -- Yehuda
>>
>> On Sat, Oct 4, 2008 at 2:39 AM, Jörn Zaefferer
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> A token that a plugin user must replace isn't acceptable, as it defies
>>> the drop-in nature of most plugins. But there are alternatives that
>>> would allow Yehuda to automate replacing the relative directory URL
>>> without anyone else having to modify the file.
>>>
>>> Something like this:
>>> background-image: url(../img/bla.png) /* [relative-url] */
>>>
>>> Writing a script that looks for these inline comments and modifies the
>>> content accordingly wouldn't be any harder then the %imagePath% token.
>>>
>>> In any case, we should define a convention for packaging resources, so
>>> that a plugin author can stick with the convention, without having to
>>> specify the metadata. Based on that convention and inline comments a
>>> plugin user could automate moving resources to project-specific
>>> folders.
>>>
>>> About the other metadata.json elements:
>>>
>>> How about keeping plugin names in sync with file names? jquery.tabs.js
>>> -> jquery.tabs; ui.core.js -> ui.core
>>>
>>> What about versioned depenendencies? Dependency to a certain jQuery
>>> version?
>>>
>>> So far plugins are always packaged into a single file, something like
>>> utility.tabs.jquery isn't in wide use. I don't see why that should be
>>> changed.
>>>
>>> So, to summarize:
>>>
>>> {
>>> name: "jquery.tabs",
>>> author: "Yehuda Katz",
>>> version: "1.0"
>>> dependencies: {
>>> "ui.core": "1.6",
>>> "ui.mouse": "1.6"
>>> }
>>> }
>>>
>>> Jörn
>>>
>>> On Sat, Oct 4, 2008 at 9:49 AM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote:
>>> > I understand what you are saying - and believe me I have much
>>> > experience
>>> > with "real-projects" that have their separate image/css/javascript
>>> > folders
>>> > set in a certain way. What I'm trying to impart is the idea of
>>> > de-coupling
>>> > so that plugin assets are independent of whatever system it is placed
>>> > into.
>>> > By adding a %imgDir% token to CSS we're already assuming developers
>>> > wants to
>>> > change CSS files whereas some might quite happily use the plugin as-is,
>>> > placing it inside a dedicated plugins sub-folder and link to the plugin
>>> > css
>>> > files directly.
>>> > The point is you don't have to map the structure implanted inside a
>>> > plugin
>>> > to the structure on your system. They could live quite happily
>>> > together.
>>> > What we're dealing with here is a matter of aesthetics which is not
>>> > something you could get right for everyone.
>>> > If it is absolutely essential that all images/css are placed inside
>>> > that
>>> > specified by the system then I think the automated tool could quite
>>> > easily
>>> > handle this. It should be quite simple to write a CSS parser in Ruby or
>>> > even
>>> > a simple regex to replace the combination found inside url(...) so it
>>> > replaces anything before the image filename with whatever folder
>>> > structure
>>> > the system chooses.
>>> > On Sat, Oct 4, 2008 at 3:10 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> People who download plugins today have to go modify CSS files to make
>>> >> them
>>> >> match their existing directory structure. I've had to contend with
>>> >> this more
>>> >> than once with the tabs plugin, including having to figure out the
>>> >> issue in
>>> >> the first place. Typical downloaders could use the find/replace
>>> >> feature of
>>> >> their editors to quickly set up the CSS the way it belongs in their
>>> >> project,
>>> >> and we could document this, instead of developers, every time, having
>>> >> to go
>>> >> into the bundled CSS to figure out the expectations of the plugin.
>>> >> We could potentially also set up packages.jquery.com to automatically
>>> >> replace the token for a non-tokenized version (although, again, I
>>> >> think
>>> >> making assumptions about people's directory structures doesn't map
>>> >> well onto
>>> >> real-world projects).
>>> >> -- Yehuda
>>> >>
>>> >> On Fri, Oct 3, 2008 at 9:33 PM, Ca-Phun Ung <[EMAIL PROTECTED]>
>>> >> wrote:
>>> >>>
>>> >>> A few more potential issues with the %imgDir% token are:
>>> >>> 1. Plugin developers need to remember to add the token back in every
>>> >>> time
>>> >>> they package the plugin for release.
>>> >>> 2. Those who simply download plugins without an automated tool will
>>> >>> have
>>> >>> a problem with this token.
>>> >>> 3. If we're saying that this is a separate repository under
>>> >>> packages.jquery.com, we may come into sync'ing issues as plugin
>>> >>> developers
>>> >>> have to upload their plugins twice. One version with the token and
>>> >>> another
>>> >>> without.
>>> >>> On Sat, Oct 4, 2008 at 12:05 PM, Ca-Phun Ung <[EMAIL PROTECTED]>
>>> >>> wrote:
>>> >>>>
>>> >>>> But if we don't touch CSS and image locations we're not assuming
>>> >>>> anything - the plugin developer should make this decision and not
>>> >>>> the
>>> >>>> automation tool. The automation tool should simply copy over the
>>> >>>> plugin as
>>> >>>> is and use the metadata.json to determine what is needed for
>>> >>>> installation.
>>> >>>> If we start dealing with image and CSS re-location it will make
>>> >>>> plugin
>>> >>>> maintenance more difficult, i.e. what happens if you decide to
>>> >>>> delete the
>>> >>>> plugin?
>>> >>>>
>>> >>>>
>>> >>>> On Sat, Oct 4, 2008 at 4:34 AM, Yehuda Katz <[EMAIL PROTECTED]>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> The problem is that you *can't* assume that the img folder remains
>>> >>>>> relative to the css folder. People are putting jQuery inside of
>>> >>>>> other
>>> >>>>> directory structure (like Rails or Merb) which have their own
>>> >>>>> conventions,
>>> >>>>> and then it's up to the individual developer to figure out how to
>>> >>>>> modify the
>>> >>>>> relative paths.
>>> >>>>> I'd like to be able to automate the installation of jQuery plugins,
>>> >>>>> which means not having to figure this out manually.
>>> >>>>> -- Yehuda
>>> >>>>>
>>> >>>>> On Fri, Oct 3, 2008 at 8:54 AM, Ca-Phun Ung <[EMAIL PROTECTED]>
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>> Hi Yehuda,
>>> >>>>>> Interesting proposal.
>>> >>>>>> A note on CSS images. I'm not sure the %imageDir% token will be of
>>> >>>>>> any
>>> >>>>>> use in CSS because CSS is capable of locating images relative to
>>> >>>>>> itself.
>>> >>>>>> i.e. if we have a structure like
>>> >>>>>> /assets
>>> >>>>>> -- /css/style.css
>>> >>>>>> -- /img/logo.png
>>> >>>>>> Then as long as the img folder remains relative to the css folder,
>>> >>>>>> whereever it is copied the following will always hold true:
>>> >>>>>> _style.css_
>>> >>>>>> div#logo {
>>> >>>>>> background: url( ../img/logo.png ) no-repeat;
>>> >>>>>> }
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Fri, Oct 3, 2008 at 2:31 PM, Yehuda Katz <[EMAIL PROTECTED]>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> For a while, I've been trying to make it possible to build a
>>> >>>>>>> system
>>> >>>>>>> to automatically install jQuery plugins into an application. In
>>> >>>>>>> particular,
>>> >>>>>>> I've wanted to be able to let Merb (a Ruby web framework I
>>> >>>>>>> maintain
>>> >>>>>>> -- http://merbivore.com/) install jQuery plugins simply and
>>> >>>>>>> easily.
>>> >>>>>>> There are a few problems I needed to see solved:
>>> >>>>>>>
>>> >>>>>>> A way for package authors to describe the locations of the
>>> >>>>>>> javascript
>>> >>>>>>> files, the CSS files, and any images
>>> >>>>>>> A way for package authors to declare required dependencies
>>> >>>>>>> A way to write CSS files that don't need to provide explicit
>>> >>>>>>> image
>>> >>>>>>> paths
>>> >>>>>>>
>>> >>>>>>> I want to propose a packaging format that plugin authors can use.
>>> >>>>>>> To
>>> >>>>>>> get the ball rolling, I'm proposing a JSON file called
>>> >>>>>>> metadata.json:
>>> >>>>>>> {
>>> >>>>>>> "name": "tabs.jquery",
>>> >>>>>>> "author": "Yehuda Katz",
>>> >>>>>>> "dependencies": [
>>> >>>>>>> "core.ui.jquery",
>>> >>>>>>> "mouse.ui.jquery"
>>> >>>>>>> ],
>>> >>>>>>> "javascript": [
>>> >>>>>>> "lib/utility.tabs.jquery",
>>> >>>>>>> "lib/tabs.jquery",
>>> >>>>>>> ],
>>> >>>>>>> "cssDir": "css",
>>> >>>>>>> "imageDir": "images"
>>> >>>>>>> }
>>> >>>>>>> Additionally, I'd like to propose that CSS files containing image
>>> >>>>>>> paths use the token %imageDir% to refer to the directory where
>>> >>>>>>> the images
>>> >>>>>>> will be placed. This will allow automated tools (or even users
>>> >>>>>>> themselves)
>>> >>>>>>> to quickly modify CSS files with the correct relative (or
>>> >>>>>>> absolute) path.
>>> >>>>>>> Does this stuff make sense? People seemed to be, in general, in
>>> >>>>>>> favor
>>> >>>>>>> of a more consistent package format, so I thought I'd get the
>>> >>>>>>> ball rolling
>>> >>>>>>> here.
>>> >>>>>>> --
>>> >>>>>>> Yehuda Katz
>>> >>>>>>> Developer | Engine Yard
>>> >>>>>>> (ph) 718.877.1325
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> Ca-Phun Ung
>>> >>>>>> + Yelotofu <http://yelotofu.com>
>>> >>>>>> + css, django, hongkong, html, javascript, php
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Yehuda Katz
>>> >>>>> Developer | Engine Yard
>>> >>>>> (ph) 718.877.1325
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Ca-Phun Ung
>>> >>>> + Yelotofu <http://yelotofu.com>
>>> >>>> + css, django, hongkong, html, javascript, php
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Ca-Phun Ung
>>> >>> + Yelotofu <http://yelotofu.com>
>>> >>> + css, django, hongkong, html, javascript, php
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Yehuda Katz
>>> >> Developer | Engine Yard
>>> >> (ph) 718.877.1325
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Ca-Phun Ung
>>> > + http://yelotofu.com
>>> > + css, django, hongkong, html, javascript, php
>>> >
>>> > >
>>> >
>>>
>>>
>>
>>
>>
>> --
>> Yehuda Katz
>> Developer | Engine Yard
>> (ph) 718.877.1325
>>
>>
>
>
>
> --
> Ca-Phun Ung
> + http://yelotofu.com
> + css, django, hongkong, html, javascript, php
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
