Posts by MattEvans

Ha! I think it is just there to show who you can afford to start an argument with.

Hm. I understood that for a moment, but now I see another, different, number.. your 'reputation altering power' on your profile = 9, but your 'rep power' as shown under your name on posts = 31.. aren't they the same thing? That's what I understood from your post.

Mine are different to; on my posts it's 4, on my profile it's 6..

What's the significance of the numbers? I have 2 green dots, a power of 4, and 120 point(s) [which is secret].. is there some simple mathematic relationship between points, green squares and power? 1 power integer = 30 points = 0.5 green squares? Green squares relationship there can't be right, because I see people with one more green dot than me might have 10+ more rep power than me.. is that because green dots aren't linearly mapped to rep points? Or is each measure related to other things than rep given, or is rep-power relative over all members? I must admit, it is quite confusing without clear explanation.

The first and second and third documents are equivalent; only in terms of the hierachal relationship between nodes. They are not by any means equal, and depending on the actual XML language they belong to, might not be considered equivalent semantically; nor are they necessarily equivalent in terms of hierachy if nodes are considered instances of something as opposed to types of something. That is, you might be saying, in the first case, that the X's in A are constituent parts of some single 'definition' of A, whereas in the second case, you might be saying that each X within an A or B is a unique X 'instance' within some unique A or B 'instance'. It depends on the XML language or representation, but in most XML languages I've used, the treatment of nodes is as instances, and the order of nodes that are in a 'sibling level' sequence is considered to some degree; so, the first, second and third examples would certainly not be considered equivelant on any meaningful level in a language like say, XHTML or XSLT.

In short, if you're authoring the XML dialect, it's up to you; it's merely a design decision. If you're working within the bounds of an existing dialect, you have to consult the specification of the dialect, because there's no way you can assume any level of equivalence.

Quite alot if you want the windows forms to actually open from a page or link on a user's web browser. You'd have to either; convert the VB standalone application to an ActiveX application, and use that on the webpage, but be warned, clientside ActiveX only works on Microsoft's web browsers and VB only really works under Windows. Still, you could convert the application in that way very simply; since you could reuse pretty much all the code with a few changes at the entry point of the application; and then add it to webpages with a tiny bit of ( MS only ) HTML code.

http://www.geocities.com/SiliconValley/Horizon/3950/ActiveX.htm
[this is for the old VB; but I imagine the same principles apply today.. although doing the necessary things might require different actions to be taken]

Alternatively, you could rewrite the application as a Java applet, Java is more widely supported than VB, and can do much the same form-based things as VB; it'd be a bit of work, but, IMHO it's the best option here. Alternatively, write it again in Javascript; although, it'd be more difficult to rewrite most VB apps in JS than it would to rewrite them in Java, and JS has no 'forms' framework, at least not for the kind of forms you're talking about. Alternatively, allow the user to download your application; and run it on their desktop. There's nothing to stop you making HTTP connections from your app, which would give you …

>>I guess this is one of those choices the OP would have to make based on his requirements.

Pretty much.

>> But in return of all this you get flexibility, the ability to change the logic without sifting through 6000 lines of your markup. Plus the load times would be less than or at the most equal to the time taken to set onclick on 6000 links by hardcoding them.

I would debate that using JS to generate onclick handlers could save much on download time and configurabilty unless the functions and their parameters can be derived automatically with a minimum of link-specific information hardcoded anywhere in either the JS or HTML. i.e, for extreme example cases:

( hardcoded )

<a href="#" onclick="return sf('data01')"/>

= association between a's and click handlers is hardest, function name can't be changed easily, most flexible; because different functions can be called.

( changing 'c' classed 'a' elements to call an onclick function with a parameter equal to the a's id )

<a href="#" class="c" id="data01"/>

=association between a's and click handlers is medium, function name can be changed in JS, but id's have to be changed in HTML and function name can't be changed ( unless more than one class is used ), there is a noteable decrease in HTML size, but at a runtime cost compared to hardcoding. Small JS file also. Might be optimum, might not. Especially when considering that you can't legally put all …

If all the functions are equal with equal parameters, or equal ( or derivable ) functions where the parameters can be easily derived programatically per link, i.e. via setting some dummy property on the link and using it to generate or lookup the function parameters. Otherwise I can invisage an equally huge JS file... Plus, it would take some noticable, although not restrictive, post-load time to dynamically set the onload property for 6000 links..

Ah yep, I get it. Hm.. thinking about it though.. Fungus1487; you could save a bit of transmission bandwidth with 6000 links involved, if you onclick="return some_function()" and make sure some_function always returns false.
In uncompressed 8bit ASCII; the dif between:

return some_function() 
some_function();return false

is 6 characters per link, meaning you'll potentially save {about} 36KB on 6000 links of the same type.. =P

Smells understandable in this circumstance.

Placing it directly in the anchor element feels better.

If you mean directly in the href attribute of an anchor element; href isn't an event handler.. so that smells worse to me.

I guess the event chain for a user click on an <a> element is something like: ( ignoring mousedown, mouseup, mouseover, and mouseout events )

if( onclick( ) ){ if (href ){ [navigate to href] } }

i have been using this practice for years but have come across a problem. using '#' will refresh the view of the page (thus if having scrolled miles down a page, resulting in a lovely jerk back to the top)

Try: <a href="#" onclick="some_function( );[B]return false;[/B]" /> I haven't tested it, but, it's advocated here: http://blog.reindel.com/2006/08/11/a-hrefjavascriptvoid0-avoid-the-void/, and it makes sense in theory.

How about ditching anchor tag all-together?
...

Use css behaviours instead.

This is ideal in theory, but older browsers ( i.e. IE6 ) don't support the :hover psuedoclass for any element except <a>, and the :visited psuedoclass _certainly_ won't work in this context in any browser. However, new browsers seem to be supporting :hover on any element, which is a good thing.

lol.. didn't think of that.

did you try the first one I posted? that shouldn't hit the same problem.. because grep is opened with one line of arguement at a time.

otherwise; try this one:

find some_dir -name "*.some_ext" | xargs -l10 grep "some_expr"

looks similar to the find . -name "*.php" -exec grep -H "some_string" {} \; one; but it lets find collect the entire set of files and pipe them to the xargs command, which splits the set into blocks of 10 lines ( controlled using the -l flag ), and calls grep with those blocks of files as the last argument( s )..

with the split line set to 10; this one seems to run much, much faster than the other three ways.. You could change -l10 to be higher or lower, if you set it to 1 though you'll need to add the -H flag to grep again.

Here's a simpler one in the same vein:

grep "some_string" `find some_folder -name "*.some_extension"`

i.e. grep "cerr" `find . -name "*.cpp"` note backticks (`) rather than single quotes around the find subcommand..

Try this; it relies on the 'find' command.

find . -name "*.php" -exec grep -H "some_string" {} \;

Which translates in english to.. search (find) in this folder (.) for files matching the filter ( -name ) *.php [ recursiveness should be default ]; when each file is found, execute grep, look for 'some_string', and pass in the found filename ( where the {} placeholder is ). Because that effectively executes grep once per file ( rather than once for many files ), you need the -H option to force grep to turn on the output of the filename; it wouldn't bother otherwise for a single file grep.

Messy eh? No wonder they put this functionality directly into grep for the next version...

EDIT: By the way, use that with the /usr/bin/grep.

grep -r --include=*.php "some_string" some_directory

works in GNU grep 2.5.1

post output of `grep --version` and `grep --help` if that doesn't work... there might be another way.

Heh. I read that article and comments before making the post.. I'm firmly on the "it's not a bug" side of the fence, although it may or may not be a misinterpretation of the specification, which is another matter entirely. Looking at that Mozilla link makes me think that Opera have done it better ( by avoiding it ).

It has annoyed me in the past, that onunload doesn't work the same everywhere. But I can't think of a single case where it's truely neccessary to do something when a user 'unloads' a page, at least not any case that can't be worked around by looking at the problem in a different way.

Besides; you can never tell if a user turns the computer off, or sends a terminate signal to the browser, or unplugs their net connection ( ok, you can.. but you can't tell which one they did ).

The standard doesn't well indicate whether onunload should be called when a browser window is closed, or if the browser is closed, or when the page is changed. It says:

W3C Event Model Specification for 'onunload' : "The onunload event occurs when the user agent removes a document from a window or frame. This attribute may be used with BODY and FRAMESET elements."

Since techincally, the document is never in a window or frame ( it's on a server silly! ) there's no real necessity to implement onunload, or onload >_>

Seriously; browser developers shouldn't implement this EVER. It's too much of an annoyance. You get 'web developers' making sites that have onload="return false;" onunload="window.location = 'elsewhere'" onunload="window.open('dont_leave.html')" onunload="while(1){alert('Come back!');}" et-cetera.

Opera doesn't call onunload, when going backwards and forwards between pages - with good reason; it remembers javascript state between pages; thus, the javascript is not unloaded in the normal sense. I suppose then, in Opera certainly, you're more likely to get an unload fired if and and only if the browser is closed. However, I'm pretty sure that closing the application stops javascript, thus ignoring remaining events. It should.

Firefox, I don't know. Do they remember JS state through navigation history?

Hybridize?

<a href="#" onmousedown="changeImages('topevents', 'images/topevents-over.gif'); return true;" onmouseup="changeImages('topevents', 'images/topevents-over.gif'); return true;" onmouseout="MM_startTimeout(); changeImages('topevents', 'images/topevents.gif'); return true;" onmouseover="MM_showMenu(window.mm_menu_0728010700_0,0,49,null,'topevents'); changeImages('topevents', 'images/topevents-over.gif'); return true;">

I haven't used 'code tags' for a good reason.

Note: You need to make sure that where more one statement ( a statement in javascript is terminated by a semicolon ) is put in a sequence; that return [something]; is only ever the LAST statement in that sequence.

There is nothing specific about blogs that generates more traffic. Unless you have something interesting to say and enough interested people to visit frequently; a blog will generate no more or less traffic than any other site. Things like RSS are only useful if people actually care enough to 'watch' your channel, which implies they are interested in the source of the channel, i.e. your site.

Pingback seems like more of an egotrip than anything functionally useful. I can get a relatively good idea of 'who' links to my pages by logging the HTTP referer request header, and any other website developers who care enough should be able to do the same to find out if I link them.

What you're describing ( allowing other people to come in and edit pages freely ) sounds more like a Wiki to me. Blogs are usually interlinked articles by one author, with perhaps user submitted comments under each article. Wikis on the other hand, are like a public free-for-all; the information is added and maintained by visitors and resident admins if necessary. Forums are about halfway inbetween. I prefer forums, personally.

There's very little 'technical' about a blog to be honest. User comments don't make something a blog, or not a blog; so if I wrote my daily workings in plain old HTML and uploaded them somewheter, I could still legitimately call it a blog - a (we)blog is just a fancy word for an online diary, basically.

You can make CSS files server parsed... Either as SSI with an Apache htaccess directive, or using some other server language to generate the CSS file automatically.

You can include arbitrary text through CSS using the 'content' property in newer browsers; i.e:

<html>
<head>
<style type="text/css">
.placeholder
{
  content: "hello!";
}
</style>
</head>
<body>
<span class="placeholder">...</span>
</body>
</html>

! This doesn't work on IE <= 6; no idea about 7.

However; importantly: the 'date modified' reported if you server-parse certain CSS is going to be the date that the CSS file was modified, not the date that any individual document that links the CSS was modified.

If you want to server parse all CSS:

AddHandler server-parsed .css

Doing the above should allow you to write <!--# --> blocks in your CSS, as you would in shtml.

If you want to parse SOME CSS, ( I used to use SSI to server-parse XML files called ssixml, and ssixsl [ if you wonder; 'why not sxml?'; try pronouncing it with <=3 syllables ] ).

It's probably better to make a custom name than server parse ALL CSS files, server parsing takes some amount of time and processing; in this example, all files with extension 'ssicss' will be server parsed. The AddType line is important because some newer browsers choke on CSS/JS served as text/html...

AddType text/css .ssicss
AddHandler server-parsed .ssicss

In both cases, that information can be added to some .htaccess file that will …

Go back to using

document.getElementById('a2z:saveMessage')

and ignore what I said about not using the a2z:, I didn't realise that your serverside application would prefix that to the element's id.

you should avoid outputting this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

in the middle of the page... it's invalid after or inside the document's root element; it should be the first line of an html file.

I'm assuming, not knowing JSF atall, that you're trying to refer to some element created by this line...

<h:inputHidden id="saveMessage" value="#{addEditController.successfulSave}"/>

and, again, not knowing JSF, I'm guessing that will resolve to:

<input type="hidden" id="saveMessage" value="some_value" />

In which case; why are you using:

document.getElementById('a2z:saveMessage')

Try using just 'saveMessage' as the Id. If that doesn't work, can you post the HTML output (View Source from a browser) instead of JSF?

Use the code given by stymiee; also, take the <SCRIPT Language="Javascript"> and </SCRIPT> tags out of the .js file... they are not needed in this case.

you don't need all of the fields; try this:

<object type="text/html" width="300" height="300" data="http://url/file.html"></object>

http://3spots.blogspot.com/2006/02/positioning-html-web-pages-inside.html

works ok for me in opera 9 and firefox 2.. doesn't seem to work atall in IE6 though.

=musing=
hm.. i wonder, how one would address parts of the inner document using this method? i'm suprised the W3 keep changing their mind about this really, a while back, iframes were supposed to be 'the way forward'.

to be honest, I prefer SSI (server side includes of any breed, not just SHTML) to stick things 'into' pages.. admitadly it forces cache-reduction/elimination, and causes marginally longer fetch times; but at least i don't have to worry about unsupported browsers and deprecated tags, to so much of a degree anyway.

Your question needs more clarification; development of what, and maintenance of what:

#include <iostream.h>

int main(void)
{
std::cout << "Hello, world!";
}

That code cost more (time) to develop than it will to maintain, and some 'real-life' trivial/one-function applications are the same. Others are not; things like web browsers/APIs/etc need to follow changing standards, but that should be seen less as maintenance than it is further development.

In an ideal world one released version of an application shouldn't need extensive maintenance - if maintenance means patching, covering holes, or fixing bugs; because good development should include a period of very, very detailed testing; and it should be based on well-considered plans.

The real world isn't an ideal world by any means; but program code is a complete infallible unit; it shouldn't break down like a lawnmower; because it isn't subject to mechanical stresses.

That is, perhaps an opinionated view; but it's the best reply I can give for such a general statement..

First up, add a body tag around the body, and a html close tag after everything:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <title>AlienNet Public Access Gateway</title>
  <embed src="audio/thunder3.wav" autostart="true" loop="false" width="0" height="0"></embed>
  <link rel="icon" type="image/png" href="http://alienlinux.homelinux.net/images/alien.png">
  <link rel="stylesheet" href="mystyle.css">
</head>
[B]<body>[/B]
<ul class="banner">
test
</ul>

<ul class="navbar">
test
</ul>

<ul class="main">
test
</ul>
[B]</body>
</html>[/B]

Then change your CSS like this:

ul.banner {
  position: fixed;
  top: 0px;
  left: 0px;
  right: 0px;
  height: 78px;
  background-color: green;
  padding: 0px;
[B]  margin-top:0;[/B]
}

ul.navbar {
  position: fixed;
  top: 78px;
  left: 0px;
  width: 180px;
  height: 100%;
  bottom: 0px;
  background-color: red;
  padding: 0px;
[B]  margin-top:0;[/B]
}

ul.main {
  position: fixed;
  top: 78px;
  left: 180px;
  right: 0px;
  width:100%;
  height: 100%;
  bottom: 0px;
  background-color: yellow;
  padding: 0px;
[B]  margin-top:0;[/B]
}
[B]body
{
  margin-top:0;
  padding-top:0;
}[/B]

It gets rid of the white top border for me on Opera9 and Firefox2. The whole layout doesn't work on Internet Explorer 6; you might want to check that out.

if your CSS files are ALWAYS in the folder that maps to http://yourdomain.tld/css_directory/, you can use an absolute link as follows:

<link rel="stylesheet" href="/css_directory/style.css" />

This is useful if your linking files are in folders nested to levels deeper than 1 from the document root.. note, it can make 'moving things around' easier or more difficult, depending on what you're trying to do..

absolute links can certainly make it more difficult to preview pages that you're working on offline, unless you go REALLY absolute:

<link rel="stylesheet" href="http://yourdomain.tld/css_directory/style.css" />

or run Apache offline, or always work at root or in some kind of dynamically rooted environment, or use a site-aware url rewriting preview tool; like that in Dreamweaver...

Check out this page:

http://apptools.com/examples/tableheight.php

the important part is this CSS snippet:

html,body{
      margin:0;
      padding:0;
      height:100%;
      border:none
   }

in a test with a new w3c doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html style="height:100%;padding:0;margin:0;border:none;">
<head>
</head>
<body style="height:100%;padding:0;margin:0;border:none;">
<div style="height:100%;background-color:blue">Anyone would think I've used a background color...</div>
</body>
</html>

This seems to work as expected in opera and firefox..

So, if you use that style in your page, anything you make as 100% high should be the height of the page at minimum, and otherwise as big as the content on the page, and not only in quirks mode..

The margin isn't an addressable area; it takes the colour/image that is assigned to the background of the outer container.

A given container has a padding (space inside) a margin (space outside) and I suppose a border (space between). Setting a margin or padding sets an amount of spacing around the border or inside the border; you can't change the background in a container's margin without changing the background of the container that respects the margin (usually the container's parent container), and you can't change the background of a container's padding without changing the background of that container.

Border is quite a useful property... you can make partial borders that are 0 - ? px / % / pt thick, and set a block color, this will act like a big coloured margin.

Margin styles don't exist per-se... The margin of the body tag works more like padding does in other containers; that is, a non-zero ( and positive ) margin on the body pushes content into the middle of the page. On any other element; a positive margin pushes content away from that element. <edit> or perhaps, it pushes that element away from other content.. depending on which way you look at it</edit>

I'd be interested to know if min-height: 100% works... if it sorts out scaled elements, it should sort out the half-page backgrounds I keep getting...

Aaah... it's a difficult one. Height 100% doesn't work in XHTML; it means '100% of the height of everything on the page'. So, if there's nothing on the page, 100% height is nothing. This even affects background images in some browsers... specifically Firefox if I remember correctly; the background image only covers the area from the top of the page to the bottom of the last piece of content; so if the page is very short in terms of its content; it gets a short background.

Wierd; but it seems that the functionality is either, not well standardised, or deliberately standardised in a way that goes against the largest of 100%-of-inner-window and 100%-of-content approach, which, in my opinion, is more intuitive and useful.

You can keep using 100%, and force the height of the div's immediate parent container to have a non-zero height that's close to a reasonable average screen height ( even specifying this on the <body> element should work ). The div should then always fill the same height that all content on the page fills, and it shouldn't ever be smaller than a screen, but, it might always be bigger than most screens..

I can't give a good one-size-fits-all solution to this problem, because I've never found one myself and it's a problem I've encountered quite a bit with various layouts.. Personally, I'd design without that aspect deliberately because I know it'll be problematic, or if it's absolutely essential, use Javascript to adjust with …

What does the code look like when you view-source in a browser ( i.e. after the PHP code has been executed ). Post the same code after PHP, and check to make sure those echos don't put invalid characters inside the value attribute.

Are you using an XHTML DTD, a HTML DTD, or no specified DTD? [ that code uses HTML tag closure rules, so you shouldn't use an XHTML DTD, a HTML DTD is preferable, but no DTD should work functionally ]

Try putting the form element outside the table element ( i.e. <form><table>..</table></form> rather than <table><form>..</form></table> ). Only certain things should go directly inside <table> elements ( tbody, tr etc )

EDIT: Oops; I didn't see the solved marker on this thread... How did you solve the problem in the end?

That's not JavaScript, it's VBScript.

it also looks like that should be executed on an ASP page (server application/script), rather than as client side script.

For client-side scripts, you do use the <script> etc </script> element, for server side scripts, you don't.

Both VBScript and Javascript can be used as client side scripting languges, AND used in ASP as the scripting language.. that seems quite confusing,

Think of a page in the browser as being one environment, and a page at the server as being in another enviornment... in those two environments there's a vast difference in what you can do, and how you do it.

You can use the same language in both environments, but it wont always have the same results, be used for the same reasons, or used in the same manner.

If that code was written like this:

<%
Dim strSelectedCountry = Request.Form("selCountry")
if strSelectedCountry == "Argentina" then
%>
Orders placed for shipments going to Latin American countries will have a minimum 3 week lead time and additional freight charges will apply.
<%
else
%>
Test
<%
end if
%>

it would be functional as a bit of (server-side) ASP script. Anything within <% %> pairs is treated as a block of ASP code, everything around <% %> pairs is treated as if it were output (text) data.

By the time ASP code reaches a browser, the server's already processed the ASP, and should have left 'clean' post-processed …

What code are you actually executing? Perhaps there is an error in your code somewhere, or perhaps you're not calling the code at the right time/atall.

This site can be useful; it's certainly very beginner-orientated; and it's by the W3C, so you can assume you're learning the correct way so to speak.

http://www.w3schools.com/js/default.asp

Otherwise, look at things like where your script element is, and what needs to be loaded before the script can do its work.

<script type="text/javascript"><script language="javascript>
blah, blah, blah, blah
</script>
is this correct?

No.

You don't need two opening tags.

Either:

<script type="text/javascript" language="javascript">
blah, blah, blah, blah
</script>

or:

<script type="text/javascript">
blah, blah, blah, blah
</script>

because type=text/javascript means language=javascript (infact, language=javascript is not considered correct these days, perhaps due to redundancy, perhaps for another reason) it's technically correct to use both attributes on the same tag, it's not correct to place <script> tags inside one another.

- Buy a mobile phone with WAP and use that in school.

or

- If you have a legitmate educational reason to use a site, ask why it's blocked and if it can be un-blocked.

or

- I won't be held accountable for the type of advice I'd give otherwise, so I won't give any.. But if you're really persistant, you'll find a way ^_-

you can turn them off on the table tag itself:

<table border="0"><tr><td>etc</td></tr></table>
[B](this will turn off the border throughout that table)[/B]

or with CSS:

table
{
    border-style:none;
}
[B](this will disable borders for all tables on a page that includes that rule)[/B]

I prefer to do it manually (first example) on all tables, and then turn them on where I want them with CSS.

The partial borders happen when you have cells without data in them.. if you wanted an unbroken border, just put this into otherwise empty cells:

 

It will force the cell to 'exist' and be rendered with a proper border.

I won't claim to know exactly why it won't work, and I don't know how you could make it work in that way.

However; a flash .swf file is not an image file. To put a flash object on a page, you have to have to 'embed' it on a page. Using an actual 'embed' tag work in most cases sometimes, but the apparent 'correct' way is to use 'object' tags.

The best way is to use embed tags inside object elements, because 'object' does some compatibiity delegation. (so if object fails, embed should work)

Linking a flash file from an image tag (equivelent to putting it as a background image in CSS) will not work; in the same way as linking an html file to an 'image' tag's src won't work. The browser expects the response to looking for that source image to return an image type result, if it doesn't find one, it treats it as it would if nothing was at that location. (Note: If the flash file identified itself as an image type, it wouldn't be processed as a flash movie,)

If you know how to embed flash movies on a page, and just want objects to appear on top of it (as if it was a background), you might have some sucess with absolutely positioned elements 'on top' of the movie. That's quite a detailed subject in itself, but as a snippet:

<html>
<body style="margin:0;padding:0">
<embed src="your_flash.swf" type="application/x-shockwave-flash"/>
<div style="color:white;position:absolute;left:0;top:0;"> …

You can run an executable on the server machine; but not on the client's machine.

VB probably isn't so common as a serverside application language; but hey, it could work.

Eek. Be careful that you check that the page still looks ok on all of your target browsers.

Try and look for a document type that doesn't cause ill effects but is still standardised, perhaps one of the latest HTML (4.0) ones.

How would you change the document type this late in the game.

Probably; delete it from the top of the page and see what happens :mrgreen:

Personally, I'd try and work around it rather than remove it. If you set the body height to something like 1400 pixels using CSS; then 100%/backgrounds will work; but you'll have a long scrollbar on your pages.

The entirely grey background works how you want in opera (although the images appear too high on the page to be seen properly). The background is short in Firefox 2, but the image appears in the center of the page and is visible.

I've noticed this happen often (always) in Firefox when you use XHTML and 100% height (and/or background properties). This is not the correct behaviour. In these contexts, 100% should be the height of the navigator window or the contents of the body, whichever is largest.

There's not much you can do about it, except set an absolute height for the body; which is a pain because how big is a window?, or remove the XHTML doctype and let browsers assume their quirks modes

text-align:center; in CSS is an extremely easy replacement for center; in the way you just suggested. A div with text-align:center; works pretty much exactly the same as <center>. As such, there's no real need for <center> in modern HTML versions. I'd say <center> is more functionally obsolete than neccessarily deprecated for a good reason.

The problem is always aligning things to the vertical center =P You can do it using hacky absolute positioning tricks in CSS, using hacky style-overrides in JavaScript; or you can make a giant table and use a vertical-align:center; TD. Still. Giant tables don't always work properly in true DOCTYPE (X)HTML (1+)4+.

Single tags without closing tags or closing slashes are deprecated (a fancy word meaning they plan to discontinue it shortly).

That's not true. In HTML the close tag or closing slash for lots of elements is optional. Unclosed tags are just illegal in XML and thus XHTML.

http://www.w3.org/TR/html4/intro/sgmltut.html
http://www.w3.org/TR/html4/index/elements.html
http://www.w3.org/TR/xhtml1/#h-4.3

I plan on learning to build web services using java. Can you tell me what softwares I need? Is the regular jdk 1.6.0 that I have installed sufficient? Or do I need a different version?

By the way I am trying follow instruction from a book and tomcat is installed twice in the book's example. First its installed in the home folder as a servlet !container! and then its installed in the /usr/local/ folder as a web server. Is this a typo? Should I follow these directions?

These questions will definately get better answers in the Java forum.

For the first one; it depends what kind of web application you're developing. You have the standard JDK which is fine for web-deployed desktop applications but not ideal because you need to create client-server pairs and/or get past security rules, You have the mobile device JDK (J2ME) which will probably be very web-orientated these days, and things like JSP for 'webpage applications' which you're probably considering if you want to use Tomcat...

For the second one; I imagine that the installation in a home directory is for a modifiable folder, and the installation in the /usr/ folder is for program binaries. Don't take that as an authoritative answer though... I haven't ever used JSP or Tomcat; I'm sure someone who has will be more helpful; and there's a large chance there'll be more of them watching the Java forum than the XML forum.

=)

You're getting closer certainly; and from a parser's perspective that's pretty much exactly how a namespace works.

From a developers perspective, although the namespace does visually separate those nodes from the surrounding document, it's more that we're highlighting those nodes as being a specific grouping so that a parser could decide to treat them differently to how it may treat nodes in another (different) namespace.

First of all thanks for replying to my post. So if I understand you correctly,

<a: node1>
...........
<b:node2>
.........
</a:node2>
<b:node1>

node1 will follow the rules described by page a. Where as node2 will follow rules from page b.

They wont neccessarily follow the rules, but they are in the same namespace and each namespace could be associated with a schema document; the parser reading that document could chose to enforce the rules of that schema, and it's probably better to assume that every parser will enforce those rules; and it certainly couldn't hurt to use 'real' schema documents rather than dead links for the namespace address.

It's more important that the namespaces separate the two types of data in that document, and that namespaces generally (although not officially) imply that a group of nodes could be processed by a different technology than other nodes in the document.

And the purpose of the m: before <getPrices> is to make sure that only the <Item> node can be placed inside the <getPrice> node. Am I getting this right?

Nope; the purpose of the m: before getPrices and item is to place those nodes to a namespace. Whether or not a parser looks at the schema relating to m: (or enforces its rules) is down to the parser, and what the parser does. An m: parser might be particularly interested in the latest m: schema; but an XSL parser wouldn't be interested atall.

…

The 'm' namespace by the way; has just been used as an example in that document. You'll see that there is no schema document at that location; wheras for the SOAP namespace; there is one (use View Source in your browser to see it).

You can always use the default namespace (element's with no prefix: part) if you're mixing a single custom schema with a 'technology' schema (like SOAP or XSLT),

In XHTML documents, the default namespace is usually set to the XHTML namespace... I suppose you should define the default namespace in the root node of any document.

Providing the <GetPrice> node is always going to be the root node; this would be correct:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body>
   <GetPrice xmlns="http://www.w3schools.com/prices">
      <Item>Apples</Item>
   </GetPrice>
</soap:Body> </soap:Envelope>

BUT! for the most part; not defining the default namespace is usually OK. Especially if you don't know where that node is going to end up within a larger document.

Namespaces are a way to separate or class the elements in a document that is composed of elements from multiple schema (different types of XML file)

You don't have to create schema documents; in essence a schema document (like the one at http://www.w3.org/2001/12/soap-envelope) just defines which elements can have which attributes/children. They do not define processing rules very thoroughly, and at the moment, can only really be seen as a strict 'template' definition for a nodeset representing the namespace.

Exactly "how" a processor interprets a namespace seems to be quite an arbitrary thing; most XML technology processors perform set tasks based on document structure/order, and perhaps only interpret namespaces by looking at a list of which URI schemas relate to their specific task(s). A good (but probably slow) parser for a technology could in theory, download the namespace schema and use it to validate the elements within its namespace. A developer could probably take that further by reading 'lookups'/references from the schema and using them programatically within a parser's processing job to control the parser's activity.

In theory; a good SOAP parser should be able to understand:

<?xml version="1.0"?>
<soapy:Envelope
xmlns:soapy="http://www.w3.org/2001/12/soap-envelope"
soapy:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soapy:Body>
   <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
      <m:Item>Apples</m:Item>
   </m:GetPrice>
</soapy:Body> </soapy:Envelope>

In practise, only new &conformant parsers would be able to deal with this. Some parsers may only respond (in a defined way) to elements that start with their prefered namespace regardless of where the namespace is sourced from via …

The control character linebreaks \n or \r will be shown in your markup when you view it as plain text. They can be used to organise your code better.

When it's rendered as HTML, \n, \r linebreaks aren't shown atall. You have to use <br> or <br/> or <p></p> etc to show linebreaks in rendered HTML.

XSLT processors generally use SAX and DOM as the core parser and RAM organisation method respectively.

SAX is a very low-level XML-to-event-chain parser, and DOM is just a list of interconnected nodes.

XSLT is a definition language that can sit on top of that, controlling the process of turning an input DOM into an output DOM.

Anything you write in XSLT could be implemented using SAX and DOM, but a single-input-file-to-single-output-file transformation (or even a multi-input-file-to-single-output-file transformation) is a relatively simple XSLT process whatever the rules for it are, and you should use XSLT.

<xsl:apply-templates> and mode will be your best friends =P

I'd advise learning the XPath rules for node selection (http://www.w3.org/TR/xpath)

and getting yourself a good XSL processor (http://xalan.apache.org/)

Using the target _blank attribute on a hyperlinked anchor tag is generally more likely to get past popup blockers...

That's not so good because you can't control the spawned window's size directly or open the new window automatically.

Some popup blockers would object to this kind of popup aswell O_O