boen_robot

With or without disable-output-escaping, the<ordernumber><xsl:text> </xsl:text></ordernumber>Should have worked. Oh well, try putting<ordernumber xml:space="preserve"> <ordernumber>in the XSLT.

Biztalk is your processor you mean? Huh... whatever...Try to see if document() is supported there to begin with. Like this: <xsl:choose><xsl:when test="function-available('document')"><xsl:variable name="var1" select="document('sample.xml')/RootNode/Node1"/>....<OutputNode><xsl:value-of select="$var1"/></OutputNode></xsl:when><xsl:otherwise><OutputNode>Document is not supported.</OutputNode></xsl:otherwise></xsl:choose> If that does't work (that is, if document() is supported, but the output is still the same), try giving absolute filepath fot the XML using the file:// protocol:file:///D|/folder/sample.xmlthat is if we suppose your XML is on D: drive of course.

The advantages of both are that the other doesn't need to change.If you use @import rules, this means that if you had common and page stylesheet, and at one point wanted to add per section stylesheets, you'll need to go into each page's CSS and add the @import for the section stylesheet. You may also put the section stylesheet in the place of the common. The common may then be called from the section stylesheet.The (X)HTML reamains intact in all of those procedures.The drawback of this approach is that you need to change each page CSS and also that if you @import stylesheet in imported stylesheet, this creates a bond that would have otherwise be breakable.If you use several <link/> elements, this means that if you had a common stylesheet and page stylesheet, and at one point wanted to add per section stylesheets, you'll need to go into each page's (X)HTML and add a new <link/> element in it's proper place for the new CSS.The CSS remains intact and there's never unbreakable bond.The drawback is that each page's XHTML has to be edited.I'm personally more comfortable with markup and thus prefer the <link/> approach.

I must say Danny Goodman (doesn't really ring any bells, but hey, the guy has a book) is right. It is really best to set up the server to deliver proper last-modified headers. Browsers never ignore those, but they do sometimes ignore the meta elements. However, scince you don't have control over your server, that's not an option and so, the next best remains the meta element.Anyway, that's probably (almost) useless, scince you solved your JS problem and have alternative for the above.For the CSS table replacement, I told you: use a float on each list item, but specify dimensions in pixels to avoid inconsistencies. Try it.

So? A server side scripting language is still the thing to work with the database (please oh please, just don't ask what's a database).

There's both ways.You can insert two link elements in the head section of your page. More explicit (page) stylesheets must be put below more common ones (overall, section, etc.).Or you can call one different CSS per page and have one or more @import rules to import the more common stylesheets. Again, more common styles must be put above more explicit ones.

My point exactly. You do clean up spam fast enough. Not asap, but still fast enough. No single person can be expected to be online 24/7 and members ocasionally noticing spam before the mods is just a trivial situation, that can't be otherwise even with 99 mods, especially on a worldwide forum.

Offtopic(kind of)://That's about the age I saw a porn movie for the first time and it wasn't on the internet, but on TV .Well, if you as a mod say you do need more help, then I guess you should get some no matter opinions like mine .

Actually, having more mods may hurt at some point I think. There's a saying "Lots of chieftain, little redskin" (the plurals are intentionally made to singulars). The saying implies there should be a balance of power and that this power must be given only to the worthy.I think our current mods are worthy enough and are doing a fine job as it is. True, spam does show up now and then, but does it always get deleted, even without people reporting it? Sure it does.And why are you so child protective like anyway? As if you haven't seen such nudity stuff. As if I as a minor haven't seen nude stuff either. As if we're not going to see it sooner or later anyway . I'm not saying that's a good thing to see, especially in a web development forum. What I'm saying is that it's not that critical if mods aren't there asap to delete it. I mean, they will eventually, right guys?

If Apache is running properly when you type in your IP, then registering your domain with that IP should not result in any sort of parking pages.Also, are you sure you bought that domain or just reserved it? The later only means they will be keeping the name for you so others don't take it, but you aren't actually getting to link your IP to that name.Or... wait... I saw their offers, and saw the fee inludes "Free Domain Parking Page (comming soon page)". If you have any control over the DNS or your account, you should be able to turn that page off from there, thus resulting in your actual pages. So sign-in to your account and check out the settings there.

Correct, but a <div> can contain all other sots of stuff as well. It may contain other divisions, one or more lists, one or more tables, etc.It's like a piece of the page you've decided to "cut" into it's own territory.

It works fine for me. The only thing is the image is loading a bit slowly, but it did eventually (in about 3 or 4 seconds). Try reducing the size of your image a bit. Try something not larger then 10KBs.

The differences between a div, span and p are more semantical then visual. By semantic I mean their meaning... their purpose if you want. They are about "what" is the data in them, not "how it looks".A block to put it more simply means "bunch of stuff".A paragraph is a block of text. You've written essays in literature classes, haven't you? The introduction and thesis are written in one paragraph each.Visually, most browsers put a small margin around a paragraphs and put each on a new line.A "div" is used to define a "division". A devision may contain all sorts of things, but it's supposed to be a division of things, not simply a division of block of text, as with the paragraph. For example a div may contain several blocks of text (several paragraphs). If I go to the essay association again- you write each argument in it's own paragraph. The arguments together form a statement.Visually, browsers put each div on a new line.And "span" is used to mark text that may be found inside a line of a block of text (in a line=inline). This can be a word or prase or anything else.Visually, browsers don't do anything with a span, because span alone doesn't define the text in it to be anything special.

Depends what you mean by "displayed". The alt text should only be used when the image is not available. If you want a tooltip (the thing IE shows when your mouse is over an image with alt text), then use the "title" attribute instead. Example: <img src="image.gif" alt="Text that appears in both IE and FF as well as other user-agents if the image is not there or is simply not downloadable for some reason. Screen readers I think also read this text." title="This text will appear as a tooltip in all major browsers, including IE and FF." />

First things first. You do know that this function should be used for parsing XML documents other then the currently transformed one, right? Not needed otherwise.Try placing the XML, the XSLT and the sample.xml file in one folder and see if it works then. If it does, try moving each of the files in a different folder to see how does your processor resolve URIs. That is, relative to the XML, to the XSLT or to the processor itself.

Actually, I didn't had that in mind, so that's really cool. But I don't see the principal. How they did it? There's a lot of JS involved, that's for sure.

If you really want custom scrollbars at least for IE, you can enclose those styles in another IE only stylesheet with IE's conditional comments.

Um... XSLT can only acces XML files. By using entities in those files (or the unparsed-text() XSLT 2.0 function) you can read text files and put certain values from them in the output.As for registry entries... as far as I'm aware, they are not text files, nor they can be opened like such, so no: you can't do that with XSLT. What you can do is to create a script to fetch that data by other means and pass the results as parameter(s) to the stylesheet, where they can be handled.

I realize we're starting to go a bit offtopic again, but what the heck...To me, that statement doesn't sounds nuts at all, mostly because I'm in the same boat. I don't have an actual job, nor I've currently taken a project. I should be having a lot of time on my hands. But there's school and there is also my father.... what about him you ask? I go to his PC shop to install OSes, fix computers and $hit. I don't really want to, because I would prefer spending time building XML editing forms (and their respective processors), building my own website following the best practices I've learned for the last year (complete flexibility and scalability, server configuration, various formats and versions in both English and Bulgarian). So why do I go there? Well, because my father is otherwise alone in that shop and can't manage the large flow of computers for himself. Not to mention the ~60 people to which we sell internet to. On the bright side, I get payed for this.

Is it possible that you dial the complete number? For example, if that number happened to be a short number in Bulgaria, it would have looked like "+359195" where +359 is the country code.

Actually, text inside a text area can't be visually changed, unless controlled by a plug-in. That's why stuff like "BBCode" exists. Users write normal text, but when submitted, certain things in the textarea are transformed for the sake of a better reader experience.

If you mean you want to select between different stylesheets on certain criterias, then you need to create some sort of script to select the proper one and start the respective XSLT processor. If this is done on the server side, you might as well run the transformation there and provide the client only with the result.

Some references to sites that would contain such tips would serve better. While a few tips may work for a lot of people, there will still be other simple fixes that will work for a lot others. Giving people with problems sites to look for solutions might serve better in the long term.Besides, there's already a topic like that for CSS and it seems to contain some usefull initial stuff.

I've always tought that JavaScript has a security measure that forbids access to remote files. Try downloading the file and inserting it into the same folder the script is in.

IE7 has no problems with the box model and the XML prolog. It uses the W3C box model (used before and now by Firefox), but if you want compatability with IE6, you should still not add the XML prolog.For the image, are you sure it's in it's proper place? If your XHTML file is located at:example.com/index.htmlthen the image must be atexample.com/images/bas11go256_dark_autumn.jpgThe quotes might be a fix, but when there's no link, I just have to ask.