 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006goofy HTML addressing
I sometimes wish I could strangle the nameless bureaucrats who cook up standards on paper and never try them out before foisting then on the public. In particular I refer to html URL relative addressing. It is fine to address members in the same directory, but falls on its nose to address a page elsewhere in the tree. If a page is moved, all links in a page must be recalculated in a way that is highly error-prone. The same included HTML needs to be adjusted depending on where it is inserted to adjust all relative links. If a page moved, there is no simple way with search/replace to find and adjust all links in other pages to it. I make my adjustments with static macros, but the obvious solution is a third mode -- webroot relative addressing. I propose syntax like this href=":images/dog.png" means relative to the webroot which works for local or website browsing You can use that sane syntax to get at your linkages at any depth in the html document tree. The slight awkwardness is figuring out how to tell the browser the absolute position of the local webroot for any given document. I think you would just give it a list of webroots and it finds one encompassing any given document Webroots may not nest. .  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Tue, 14 Feb 2006 18:13:33 GMT, Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or indirectly quoted someone who said : >means relative to the webroot which works for local or website >browsing You can use that sane syntax to get at your linkages at any >depth in the html document tree You can do it without Sun/W3C permission IF you are willing to preprocess links to relative before upload or during serving SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > means relative to the webroot which works for local or website > browsing You can use that sane syntax to get at your linkages at any [quoted text clipped - 4 lines] > think you would just give it a list of webroots and it finds one > encompassing any given document Webroots may not nest. If you want all relative URLs relative to the "webroot", you can use base. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ On Tue, 14 Feb 2006 19:41:30 +0000, Thomas Hawtin <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone who said : >If you want all relative URLs relative to the "webroot", you can use base. I don.t know what you mean. Could you give a sample href? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Tue, 14 Feb 2006 19:41:30 +0000, Thomas Hawtin > <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone > who said : > >>If you want all relative URLs relative to the "webroot", you can use base. > I don.t know what you mean. Could you give a sample href? I think he refers to the <base> which you can give in the <head> of an HTML file. For example: <html> <head> <base href="http://www.faqs.org/rfcs/"> </head> <a href="rfc1866.html">lhgkkjkuj</a> </html> Signature"TFritsch$t-online:de".replace(':','.').replace('$','@') On Wed, 15 Feb 2006 03:53:01 +0100, "Thomas Fritsch" <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted someone who said : >I think he refers to the <base> which you can give in the <head> of an HTML >file. [quoted text clipped - 3 lines] ><head> > <base href="http://www.faqs.org/rfcs/"> The problem is you want the same document to work both locally and on the web. I can solve it by generating two different sets of documents, one for local viewing and another for web viewing, but .... I would rather URLS were fixed to give me webroot relative addressing, a scheme that works both locally and on the web. For now, the best I can do is a macro that takes a web-root relative link, and expands it to the corresponding minimal relative link. The relative link works both locally and on the web. In my HTML Static macros scheme I work with three kinds of addressing: absolute : e.g. fully qualified local filename or fully qualified web url. relative ../../ navigation. webroot relative. I find find myself interconverting all the time. It would be so much more convenient if I could work directly with webroot relative nearly all the time without conversions. It would be so much easier to maintain and conceptualise. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Wed, 15 Feb 2006 03:53:01 +0100, "Thomas Fritsch" > <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted [quoted text clipped - 32 lines] > webroot relative nearly all the time without conversions. It would be > so much easier to maintain and conceptualise. I believe HTML files are not "meant" to be viewed locally. Consider you have a folder "C:\MyWebPages", which contains a file "index.html" and a folder called "SubSiteA", which contains a "mySiteA.html". What is the "webroot" of mySiteA.html? Is it C:\MyWebPages, or is it C:\MyWebPages\SubSiteA? or is it C:\? Or something else? Would the web browser just scan all ancestor directories and consider the highest directory to contain an html file to be the webroot? Any such algorithm is pretty arbitrary. There's no way to know the webroot for a given html file. What would the browser do if I downloaded an HTML file off the internet, and saved it in some arbitrary folder of mine? What would the webroot be then? Etc. - Oliver > What would the browser do if I downloaded an HTML file off the internet, >and saved it in some arbitrary folder of mine? What would the webroot be >then? Etc. For this to work, you could not download part of a website and expect he webroot relative addresses to work unless you created the intermediate nodes to the webroot base and declared the webroot at the base local directory. You might handle it in a more dictatorial way by saying that webroots correspond to local directories of the form com.mindprod So you could even in theory deal with locally cached copies of websites that reference each other. the idea then is your browser is told a list of URLs and were they are locally cached/being prepared. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > In particular I refer to html URL relative addressing. It is fine to > address members in the same directory, but falls on its nose to [quoted text clipped - 17 lines] > browsing You can use that sane syntax to get at your linkages at any > depth in the html document tree. If you use href="/images/dog.png" you do have a link relative to the webroot. So what is the difference to what you want to achieve? Or did I completely misunderstand you? Signature"Thomas:Fritsch@ops.de".replace(':', '.').replace('@', '$') On Tue, 14 Feb 2006 19:34:11 GMT, Thomas Fritsch <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted someone who said : >If you use > href="/images/dog.png" >you do have a link relative to the webroot. So what is the difference to >what you want to achieve? Or did I completely misunderstand you? but there is no such thing as a webroot locally when you are preparing and viewing the files, or distributing them for offline use, right? It would be lovely to be wrong on this one. I would kick myself for so long spent wrestling with pure relative addresses. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Tue, 14 Feb 2006 19:34:11 GMT, Thomas Fritsch > <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted [quoted text clipped - 7 lines] > but there is no such thing as a webroot locally when you are preparing > and viewing the files, or distributing them for offline use, right? Suppose your HTML file is at URL "file://localhost/somedirectory/page.html" and you have href="/images/dog.png" in it. Then this ref would expand to href="file://localhost/images/dog.png" That means: in this case your webroot is at "file://localhost/" > It would be lovely to be wrong on this one. I would kick myself for so > long spent wrestling with pure relative addresses. Signature"TFritsch$t-online:de".replace(':','.').replace('$','@') On Wed, 15 Feb 2006 03:30:28 +0100, "Thomas Fritsch" <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted someone who said : >Suppose your HTML file is at URL "file://localhost/somedirectory/page.html" >and you have > href="/images/dog.png" >in it. Then this ref would expand to > href="file://localhost/images/dog.png" >That means: in this case your webroot is at "file://localhost/" but that won`t be where the local file is. Each website you are preparing lives in its own directory, not the root. In my case for example I need href=":images/dog.png" inside file E:\mindprod\jgloss\dalmatian.html to expand to file://localhost/E:/mindprod/images/dog.png when used locally and http://mindprod.com/images/dog.png when used on the web. You want true file urls rather than faked local websites with an HTTP servec so that when you do view source you can edit the orginal. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>Suppose your HTML file is at URL >>"file://localhost/somedirectory/page.html" and you have [quoted text clipped - 16 lines] > You want true file urls rather than faked local websites with an HTTP > servec so that when you do view source you can edit the orginal. Well, I must admit, the "file:"-URL technic is not very well-suited for offline-testing web-sites. One (probably very bad) way to get around this would be: Instead of keeping your whole web-content in "E:\mindprod", keep it in "E:\" or maybe in "C:\". Then the root "file:///" is, where it should be. Another idea is: Completely avoid offline-testing with "file:..." URLs. Instead set up a HTTP-server on your local machine, and configure it to have "E:\mindprod\" as its web-root, and to listen at "localhost". Test your offline-site with "http://localhost/...." URLs. When your browser sees href="/images/dog.png" in your HTML, it will request "http://localhost/images/dog.png", and your local server will respond with the contents of "E:\mindprod\images\dog.png". You know that you won't need a full-featured server like Apache. Any small toy web-server will do. (Google for example for "Tiny HTTPd in Java") Signature"Thomas:Fritsch$ops.de".replace(':', '.').replace('$', '@') Thomas Fritsch schrieb: > Well, I must admit, the "file:"-URL technic is not very well-suited for > offline-testing web-sites. It definitely isn't. Just think about content types. > Instead set up a HTTP-server on your local machine ACK. Timo On Wed, 15 Feb 2006 16:42:44 GMT, Thomas Fritsch <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted someone who said : >Completely avoid offline-testing with "file:..." URLs. Instead set up a >HTTP-server on your local machine, and configure it to have "E:\mindprod\" >as its web-root, and to listen at "localhost". The problem with that approach is view source does not work. You are using the links to find the stuff you need to update. With a local server you don't get the original do you? I thought perhaps a clever editor that would render, edit and navigate links could be taught to reinterpret absolute links locally. However, than leaves out in the cold my users who want to peruse the website offsite from a local mirror. The problem does not have an elegant solution. Perhaps that is why W3C backed away from it. Consider the this scenario. You are using google desktop to index your local files. You parachute into to a file E:\mindprod\jgloss\jar.html and it has a reference to :image\jar.png How is the browser to know that really means E:\mindprod\images\jgloss\jar.png rather than E:\images\jgloss\jar.png ? Ok, let's say W3C were to invent a header tag called local base set to E:/mindprod all is fine, right? until somebody downloads the site and puts it in F:/mymirrors/mp So I think the solution is: 1. You use a tag of the form ":images/jar.png" which is interpreted as webroot relative both on the website and locally. 2. To help with the translation from webroot to absolute locally, you must register a set of webroots in your browser, and the browser selects the best/only fit. I suppose I could try to introduce this idea into the world purely as a browser convenience feature. Then I don't need W3C approval. I have to sell it to browser makers a few at a time, and hope the natuar0l use of it forces the others to support it too. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. I don't think it is W3C fault. However you should setup a local HTTP server, such as Apache or IIS and then set the local webroot to your folder. yangc schrieb: > I don't think it is W3C fault. It certainly isn't because HTML is actually older than the W3C. The WWW was invented by Tim Berners Lee (he wrote the first web server and client in 1990). Uniform resource locators were standardized _much_ later, the first RFC is from 1995. Timo >Uniform resource locators were standardized _much_ later, the first RFC >is from 1995. I think by then people had some experience creating full websites and browsing the locally. I think the just did the academics shoulder shrug. Relative handle the problem in theory even if very inconvenient for large sites. Academics usually have only under 5 pages in their websites. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.