Exactly. Even on the rare occasion when someone uses a full url with
http://it is pretty simple to just ignore those.
On Sun, Oct 5, 2008 at 10:57 PM, Jörn Zaefferer <
[EMAIL PROTECTED]> wrote:
> 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
> >
> > >
> >
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
