Posts by MattEvans

<DIV STYLE="background-image:url('http://www.google.com.au/intl/en_au/images/logo.gif'); background-repeat:no-repeat; padding:0px; margin:0px; width:276; height:110;">
<IMG SRC="http://i14.photobucket.com/albums/a345/Instar/please_do_not_hotlink.gif" WIDTH="276" HEIGHT="110"  BORDER="0">
</DIV>

Hehe... this code has been programmed with a hypocritic personality!

I hope you used an image hotlinked from google as an example only =P

You also can't stop someone probing your code to find the image link; and if they're inclined to hotlink your images; they'll probably be even more inclined to do so if they encounter lax security.

Good idea though...

I'd advise looking into some server side techniques. Quite alot of the things you've been asking about here with Javascript (cookies, redirection, dynamically generated content, referer detection [which is what you'll need for this]) are much better suited to server-side scripts and technologies.

There's definately more output variety when it comes to some of the CSS placement/overflow rules in modern browsers than there is with table display rules, regardless of defined document type.

Tables are certainly more reliable when it comes to backwards display compatibility; there's not much that can go awry with a table: until you hit a text-only browser that is...

I disagree that everyone has the latest version of their browser... That's like assuming everyone uses Windows XP, and every WindowsXP user will be on Vista when it comes out publically.

I have a partition on this computer that boots Win98 with an IE version maybe before 5. MS have discontinued Windows 98 and ME support, so there's no neccessity for them to continue realeasing browsers that are compatible with Windows 2000 or lower. Luckiliy, I have more than one operating system on this computer; but not everyone has that luxury.

I haven't been on that partition since I installed the OS there, but it would be interesting to see how it renders newer standards of page..

It definately does pay to know, or at least be able to work out what you can and cannot do with or without tables, and it probably pays to define your target audience quite early in a project.

this line:

function ReDirect (http://download3-1.files-upload.com/2007-01/20/22/RP.html) {

should be:

function ReDirect (URL) {

and if that's the page you want to redirect to; this line:

ReDirect('/welcome');

should be:

ReDirect('http://download3-1.files-upload.com/2007-01/20/22/RP.html');

Sorry, I missed a bit of code you wrote in the original post:

You do this test in the ReDirect function: if(Splash == "TRUE"){ }; that test should be a test for Splash NOT being "TRUE". Otherwise; your redirect will only happen when the user has visited the page at least once.

The cookie code your using should return a null if the cookie isn't found; but perhaps it's better to test for it not being "TRUE" just in case.

So, the top part of your code should read:

var Splash = GetCookie('SplashSkip');
ReDirect('/welcome');
function ReDirect (URL) {
if (Splash != 'TRUE') {
SetCookie('SplashSkip','TRUE',1);
window.location=(URL);
}
}

O_O

the wildcard * generally relates to everything. If that was possible, your code would be saying "call every function you can find, and pass no parameters".

it would be more handy if you could go halfway, like onload = "wildfnc('_onload*')" to execute all functions prefixed with _onload....

But, unfortunately no. No such thing exists unless you implement it yourself.

The best way to manage such a thing is to append events to your body object from code rather than write them all in the onload attribute; that or call all of your onload functions from a single onload function.

To 'interact' between javascript and PHP, you have to either use PHP to create javascript code, or use XMLHTTP requests in javascript to access PHP scripts and then handle the output if neccessary.

You cannot write javscript code that directly invokes PHP code. javscript is processed on a client's computer; PHP is processed at the server as a page is requested. Javscript only ever runs after the PHP processor has done its work (and removed all PHP blocks from its output files)

That doesn't mean that you cant create javascript code based on or affected by a PHP process; it just means that the javascript in a PHP file will do what the PHP code tells it to do.

So, by the time javascript runs; this PHP code:

addBookmark('mysite',<? echo 'http://mysite'; ?>)

will always end up as this javscript code:

addBookmark('mysite',http://mysite);

And that code wont work because of quoting.

But this PHP code:

addBookmark('mysite','<? echo 'http://mysite'; ?>');

Generates this code:

addBookmark('mysite','http://mysite');

Which should work.

Forum software solutions have a way of indicating whether threads (and in the case of Daniweb forums to) have had their content viewed by a user.

How exactly is this done? Is reference to every page a user has explored stored somewhere, for every user (or for every page)? That seems like a huge amount of data potentially..

A solution I figured out was to write the modified date of a target file to a query string variable when rendering hyperlinks to that file; in most browsers, this makes links show as visited when a user has seen the target file but only if the target file hasn't been modified since the last time they saw it.

This is by no means ideal because a user might come on from a different computer or browser; and could think that they haven't followed any links...

I'm all for implementing detailed tracking per-authenticated user; but that means only authenticated users get the benefit of knowing when things are 'new'. Still; I suppose I could create a new guest account for every IP address.

Is there something I'm missing? I can see myself blowing my storage allowance on per-page user tracking O_o

Providing the cookie scipt you're using works correctly:

Change:

var Splash = GetCookie('SplashSkip');
ReDirect('/welcome');

To:

var Splash = GetCookie('SplashSkip');
if(Splash == null){ 
   ReDirect('/welcome');
}

Remember to clear your cookies to test (I find Opera is best for testing cookies)

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 …

That's quite comprehensive; but it doesn't cover the website situation well; because a user doesn't neccessarily have a sitemap in their head but links do usually have informative titles... =P To make it accurate for a website; you need a per-path constant of 'link naming sensibility', and per traverser constants of 'link name interpretation' and 'memory', infact link name interpretation should increase as the traverser explores the site, assuming that they have a good memory.

And hey, you do realise you have to implement human nature to get it truely accurate ^_-

you could do it if you changed the output from a textbox to a DIV and used the inner HTML property:

<table border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td width="100%"><form name="ddmessage"><table border="0" width="100%" cellspacing="0" cellpadding="0">
        <tr>
          <td width="100%"><select name="selectbox" size="1" onChange="changecontent(this)">
            <option selected value="What is JavaScript?">What is JavaScript?</option>
            <option value="Why learn JavaScript?">Why learn JavaScript?</option>
            <option value="The difference between JavaScript and Java">The difference between Java and JavaScript</option>
            <option value="What is DHTML?">What is DHTML?</option>
          </select><br>
          </td>
        </tr>
        <tr>
          <td width="100%"><div id="output"></div><br>
<font face="arial" size="-2">This free script provided by <a href="http://javascriptkit.com">JavaScript Kit</a></font>
</td>
        </tr>
      </table>
    </form>
    </td>
  </tr>
</table>

<p>

<script language="JavaScript">

/*
Drop down messages script
By JavaScript Kit (http://javascriptkit.com)
Over 400+ free scripts here!
*/

//change contents of message box, where the first one corresponds with the first drop down box, second with second box etc
var thecontents=new Array()

thecontents[0]='JavaScript is a scripting language developed by Netscape to add interactivity and power to web documents. Examples of JavaScript include live clocks, rollover effects, <img src="http://www.google.com.au/intl/en_au/images/logo.gif"></img>'

thecontents[1]='The first few words that come to mind are: "Freedom baby, freedom!" With html, you are restricted to creating static, non interactive webpages. This, in today\'s internet standards, is unacceptable. With JavaScript, you can change that. Imagine being able to break free and allow your creativity to dictate what you put on your webpage, instead of the other way round.'

thecontents[2]='Java is completely different from JavaScript-It\'s a lot more powerful, more complex, and unfortunately, a lot harder to master. It belongs …

Make sure that you call the script when the document has finished loading (that will mean that you will not be able to use document.write()) , otherwise make sure you don't use the XHTML doctype.

The XHTML doctype forbids document.write() because it messes with the output document tree during rendering.(http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite)

If you're not using XHTML (you'll know if your not) it still pays to avoid using hacky Javascript methods to generate HTML elements during rendering. What you're doing (or perhaps the way you're doing it) would be better suited to a server side scripting language.

Personally, I would define a single array, containing only the unique identifier for each thumb and preview pair, for example:

<script language="JavaScript">
<!--
function random_content(prefix){

//build the array
var mycontent=new Array();
mycontent[0]='black forna';
mycontent[1]='black lillies';
mycontent[2]='blue shell';
//.. etc..

//choose the random identifier
var num=Math.floor(Math.random()*mycontent.length);
myname = mycontent[num];

//change the src / href of prefixed attributes according to the chosen identifier 
document.getElementById(prefix + "_hyperlink").href = "images/pics/previews/" + myname + " PREVIEW.jpg";
document.getElementById(prefix + "_image").src = "http://grafax.co.uk/newtest/images/p...umbnails/" + myname + " thumb.jpg";
}
-->
</script>

And then, you can create the object and invoke the randomness using markup as follows:

<body onload="random_content('random1');">
<!--your other markup here-->
<a id="random1_hyperlink" class="randomthumb" target="_blank">
<img id="random1_image" />
</a>
<!--your other markup here-->
</body>

A bit more manageable maybe? Post back if you have problems with that.

Hm. You should be able to do something like this in your 'Activity' template in the XSL file.

<xsl:variable name="get_from"><xsl:value-of select="@Id"/></xsl:variable>
<xsl:copy-of select="/Package/Transitions/Transition[@From = $get_from]/ExtendedAttributes"/>

(I haven't tested that, I have no useable XSLT processor on this PC at this moment)

Your input XML file is a bit confusing.. But it does highlight one of the inherant difficulties in XML; showing relationships between sibling nodes (other than order-based relationships)...

I'm not quite sure if I get exactly what you're trying to do though; do you want the ExtendedAttributes in the Transition node with the same "From" attribute as the currently processed Activity node's "Id" attribute, to be placed in the <ntask> output node that's currently being processed?

Post back if that isn't the case.

Well. I can't debate unless I'm permitted to be completely literal, and to take things said as completely literal. Anything else would be, or result in the necessity for an assumption, would it not?

----

Hey. Overall apologies; I'll even drop out of the debate mode. I absolutely agree it's down to designers to chose, and has always been.

I should warn, I'll probably always argue about this when it comes up. Perhaps it's because I've never heard a good reason to change my mind, and the same reasons always come up.

Personally, I minimize the use of tables wherever possible; but sometimes, CSS and minimal markup alone is just too darn unreliable across browsers/with variable content. If it doesn't work today, it isn't working.

As roryt said, he finds it quicker to get a result with CSS alone. For the most part, I find it quicker to get a result with tables. I understand CSS, I just find it unsuitable after multiple attempts, when trying to do things that to me seem simple, and easy, with tables; including the entire structure of a page. I visualize the entire page as a tabular data structure. And thus I conform to the W3Cs recommendation.

Perhaps that is the fault of browsers, perhaps that's a fault of gaps in the specification of CSS. Perhaps it's a fault in my use of CSS.

If I don't like a table, I get rid of it. But I …

In order to keep up with the "trend" of modern design techniques you should really learn CSS and tableless (or less-table ) design practices. The key benefits I can think are as follows:

1) Using CSS makes your site more accessible to those with disablities and textbased web browsers (Lynx).
2) CSS makes your code easier to read and understand by search engine bots. (and yourself sometimes)
3) It's good practice to keep your Presentation/Layout layer seperate from your Data/Content layer. (updating is in-fact easier).

Think of it this way: You wouldn't use Excel to design a webpage so why would you use tables. Move on to CSS and don't look back.

Webpages with CSS are nothing without HTML ^_-

Perhaps my fault, but the thread thinking has deviated into assuming tabled designs make no use of CSS. This is far from the truth.

CSS by itself does not make sites more accessable, or search engines more effiicient. Using CSS may make sites more accessable, or it may make them less accessable.

Consider, a user with moderate long-sightedness; who prefers to view pages without any stylesheets atall. Not by overriding certain stylesheet rules, but by completely overruling stylesheets.

Anything now that uses CSS to re-order page content in a "tabular fashion" fails immediately and to the user, un- interpretably. Any organisiton of data is now as the document would read in markup, with markup-standard headings, fonts, and positions where elements are used. Tables noteably, …

I think a definate distinction needs to be drawn between designing with less tables, and tableless design.

Rigidly tableless design is as logically defunct as throwing all of the screwdrivers out of your toolbox because a chisel is good for presentation.
Mythical "CSS-only" chisels cause as much of a mess to the screwhead of any tabular data layout (which may or may not be presented as a table of figures) as a screwdriver would to a woodcarving.

Design with less tables is a process of natural selection. If "CSS-only" (which is an absolute myth anyway) could do everything tables could do, and reliably, and with the same markup overhead, and without being overall more hacky than a table solution, nobody would use tables; even if it were only to escape pre-spoken criticism.

All HTML markup is presentational to a point; HTML has almost none of the useful features a data definition language would have, and yet it's widely spoken as being 'data' that needs to be separated from presentation. All CSS solutions require markup, otherwise you have one element to work with; <body> (and even then you need a little markup).

You'll find, that the best designed websites and the best website designers make good use of the inherant advantages of tables, where and when they are appropriate.

I think it'd also be good to talk about the different types of website. Flashy graphical one-to-five page info-sites that never change unless the "website designer" …

Well. I apologise for my terseness in that post; but only if you're generally interested in this problem for entertainment, and not just after a quick answer.

There is no solution to the question, (partly because there's also no real question in your post).

If you want to model a complex system, the best place to start is planning. If you draw some diagrams, and work out the "answer" for those diagrams, perhaps it will help you to get closer to a reusable algorithm.

There's going to be an enourmous element of chance in "how long a user takes to explore a web site". Perhaps a better value to find is the maximum or minimum time it takes a user to explore a website.

Even then, the model will either have to be very comprehensive (with each page accounted for) or very vague (using averages/predictions).

I've had a little look at this tonight... There's always gonna be a huge number of solutions, and a huge number of questions.

Perhaps I'll reply my findings aswell at some point...

Is this one of those questions that's baffled mathematicians eternally?

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.

if you dont fill it in quick enough it will change

hehe... nah.. it wil only start timing out when the submit button is pressed... 20 timeout ticks is too short to do anything except blink... the reason for using timeout instead of setting the window.location first is that the form might not submit atall if the browser changes location before the form has been submitted.

CGI is quite a general term... it means Common Gateway Interface, and gramatically, the way I used it in that post was wrong.

CGI script is a better term; in the-most-basic terms, a CGI script is a program that you can access as if it were a webpage.

I think you can probably write CGI script in any programming language that supports character input and output... but the most common CGI languages today are PHP, ASP, and maybe Perl.

The kind of CGI script you'd want to write for the mailing purpose would need to accept the input sent to it from your HTML form (that's going in through the "Common Gateway"); perform a server-side mailing operation based on the input recieved, and then send Redirect 301 and Location headers to send the user's browser to the next page (that's going out of the 'Common Gateway')

So, I'd say you need a language that provides mail support 'automatically'; I'd advise PHP (only because it's very widely supported on different server platforms). Personally, Perl is always my first choice..

…

URLs in CSS files are relative to the location of the CSS file. URLs in embedded CSS are relative to the page the CSS is embedded in.

If you want to make sure that you always read the image from the same location, use an absolute link. Either root directory absolute: url("/images/header_background.jpg") or http absolute: url("http://www.njsymphony.org/images/header_background.jpg")

But, if you really want use mailto as an action, and can't use CGI for any reason, try adding this to the form tag attributes:

<form method="post" action="mailto:Customersupport@graf-x-designs.net" 
enctype="text/plain" [B]onsubmit="window.setTimeout(function(){window.location='http://redirect here'},20); return true;"[/B]>

Write a CGI script to perform the mailing operation from your server, and then redirect the page at the end of the script.

mailto: isn't totally reliable anyway. I don't use a default mail client on any computer except at work; and your code relies on me (as a user) having one enabled and letting webpages acess it.

An onsubmit event handler would probably be more use, and it's a form event rather than a button/input event.

http://www.htmlcodetutorial.com/forms/_FORM_onSubmit.html

onfocus would catch a click or a tab movement to the textarea.

make sure you only do anything the first time the textarea is focused though...

the only other problem with linking directly to their script is it's difficult to see exactly what the script is doing.

what's the problem? you said in your first post that you're having a problem getting it working, I'd ask them (Jacuba) if you're having a problem with their script.

Well... that's not conclusive information. What's a window.Jacuba?

I'd try downloading the script for a start, and putting it on your own server. Unless the site hosting the script specifically ask that you hotlink it like that, it's rude to do so.

No.

Why don't you plan out how to do your homework problem, work out the answer, and reply me with the solution; Now.

You shouldn't use JavaScript for restrictive/non-helpful form validation. It's amusingly easy to bypass.

When you download and install an application, the download part is deliberately in the user's control.

The install part is then able to access the filesystem, save files, etc.

Would you really want a server to be capable of installing software on your computer by the act of accessing a page on that server? Any browser or plugin that allows that kind of action is a total security risk.

(Temporarily ignoring Javascript) All you can do from a webpage is answer requests. A 'download' is just answering a request by sending the contents of a file. The browser then either asks the user where to put the file, or makes a good guess at where the file should go.

Javascript wont help you, because it's been designed deliberately to NOT allow read acces to anything on a user's computer, and to not allow write access anywhere.

Java Applets/Applications may help you out.

Unless your input stylesheet is extremely simple, the XSL processor deliberately wont parse all tags in an input file. XSL is like a data filtering language... it absolutely depends on you knowing the input schema, and knowing how to translate every part of the input document into an output document.

It's also quite top-down. Unless you make very generalized rules, you have to manually apply a transform directive to every node/set in your input documents that are important in the output document,

You should think of schema as being a set of unbreakable rules for the organisation of and type of content in a file; and XSLT as a way of moving content from a document of one schema to a document of another (or the same) schema.

XSL transformations themselves only neccessarily acknowledge the XSL namespace schema. An XSL transformation will not generate (or neccessarily comply with) an explicit schema defintion for an output document. There may be a way to enforce output document schema validity at a low level... I've never come accross it.

There's a few online tools for checking the validity of documents based on an explicit schema, I don't know if that's what you're looking for:

http://tools.decisionsoft.com/schemaValidate/

and offline tools:

http://www.altova.com/products/xmlspy/xml_editor.html

In my experience, the best way to test input against output is to create a load of test cases (documents that cover most potential inputs to a stylesheet) and transform them.

…

I can't test the PHP on a server/lhost at the moment, so this is based on source code analysis only, and given that the problem 'Operation Aborted' occurs as a result of the modification of incomplete elements.

----------------

On line 59 of xc_modules.js, is this statement:

this.CSSattach();

Try commenting it out/removing it temporarily.

That appears to be the only line that modifies the DOM while loading is incomplete (SI.onbeforeload is called from an inline script at the very end of topnav.php)

It also seems like when you include includes/gallery.php into index.php that you load a page with a 'double' <html><body> element.... You can see that for real by viewing the source from the page index.php?section=gallery at your domain.

You could fix that problem by removing this from the top:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
</head>

and this from the bottom:

</body>
</html>

of includes/gallery.php

whether that will cause stranger behaviour, I can't say without testing.

------------------------

I've gotta say, you paid too much to the wrong people for that implementation.. it's not very well done.

I will try and run a test of the files you attached tonight if I get some time...

Make sure that you don't call functions to modify the DOM for elements that have not yet been finished. That is, minimize the use of inline calls to JavaScript functions that attempt to modify the document.

You should put all calls to functions that use code like document.createElement(); or [object].appendChild(); in the body onload event; otherwise the body doesn't exist yet.

The 'Operation Aborted' error in IE is in relation to that; do a Google search for javascript "Operation Aborted" .

I imagine the problem is less about the code in that module than about the way you are using that code, I had a brief look, I see some cases where document.createElement is used. How are you calling the functions in that module from your PHP page?

You wont get a quick solution for the reason's I've already outlined. You'll need to redesign the entry to your website so that the main window is lanched using JavaScript (in order to close the main window) and accept that popup blockers / security rules might interfere with what you want to do.

Regardless of whether your page is JSP/ASP/PHP/HTML and whether you have no frames or 75 frames, th questions you want the answers to are:

- Can I close the current browser window?
Only if you opened it from script on your site, or if you're targetting browsers that ignore the rules for window ownership. Even if you 'own' the window; you may hit security problems in certain browsers, especially on high security modes.

- Can I open a new browser window without ever hitting a popup blocker?
No.

You shouldn't send an XML file with a linked transform directive directly to the user's browser. Not all browsers support client-side XSL transformations.

You should look for a server-side XSL processor, perform the transformation at the server end, and send (X)HTML.

There should be an ASP-ready XSL processor on Windows Servers based on MSXML (www.perfectxml.com/articles/xml/XSLTInMSXML.asp . See if it's on your server, if not, ask for/install it.

That's the same processor used by MSIE for client-side transforms; doing the process at your server though, means that you can serve to browsers other than MSIE and FF.

Even using a server side sripting language, you wont be able to grab everything in a folder on a user's computer from an HTML/browser page.

Those 'input = file' forms don't give the server any filesystem access; when you press 'submit' the browser finds the file, encodes it according to the form enctype and sends it to the server as (usually) a POST request.

The only way to do it would be write a control or application FOR THE CLIENT'S browser or computer, which they would then have to accept and install.

you can't nest elements inside other element's attributes. what you'll need to do is either store the data in a variable and then use shorthand variable syntax in the attribute, or use the <xsl:attribute> tag.

Method #1 (by storing variables)

<xsl:variable name="winWidth"><xsl:value-of select='imagesize/@width'/></xsl:variable>
<xsl:variable name="winHeight"><xsl:value-of select='imagesize/@height'/></xsl:variable>

<a href="#" onmouseover="zoom('{$winWidth}','{$winHeight}','logo','in')" onmouseout="clearzoom()">Zoom In</a>

Method #2 (by <xsl:attribute>

<a href="#" onmouseout="clearzoom()">
<xsl:attribute name="onmouseover">
zoom('<xsl:value-of select='imagesize/@width'/>','<xsl:value-of select='imagesize/@height'/>','logo','in')
</xsl:attribute>
Zoom In
</a>

You shouldn't use double quotes inside doublequoted attributes =P

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/)

well, if you're automatically opening windows you're always going to hit an alert on newer browsers, and you can only be sure you'll be able to close a window that you "own".

information doesn't have to be shared between the two pages. if you're worried about people pressing the 'back' button; that's a system beyond your control.

if you're using sessions (cookies/QSA) of some description, you can expire or invalidate the login; the users wont have authorititave access to your site after logging out; but they'll always be able to recall their cache.

The only way around that is 'scrambling' delivered pages and using JavaScript to 'unscramble' page content based on a cookie everytime a page loads. But even that won't stop browsers like Opera from recalling pages (it retains DOM/JS state between pages)

Why is easy:

1) Easier to update
2) Faster loading pages
3) More control

That went through as I was typing out my micro-essay...

As a rebuttal to 1, that depends entirely on how you update pages.

Tweaking the position of things is not the same as changing content, and a big style change usually involves some markup changing anyway.

In agreement with 2, in some circumstances.

In partial agreement with 3, except that a table is a controllable entity in itself, and sometimes control is more controllable when it's controlled. ^_-

Sometimes you can do things that could be done with tables with CSS instead; sometimes you can't, or it just becomes close to a waste of time trying (if you find your almost para-implementing tables with CSS + javscript, you're certainly wasting your time).

i guess the thinking is that a table is a restrictive structure (defined in markup) and CSS can be modular (by using different stylesheets)

CSS and tables aren't incompatible or exclusive. If you're being asked to do something without tables, you should ask the person commissioning you if they have a good reason why not to use them; and a reason based on heresay/myth-mongering isn't a valid one.

Here's some myths to dispell:

Myth - Screenreaders can't read tables
Fact - Well organised tables are easier to read in logical order (using a markup-based screenreader) than a load of floating/absolutely placed elements.

Myth - Tables are deprecated in the latest W3C HTML specs.:
Fact - Tables are not deprecated in any HTML or XHTML specification, although the WAI do advise against the use of tables in circumstances where they are inapropriate, or could be confusing if linearized.

Myth - Search engines don't like tables, a site without tables is going to get a lower rank in a search engine.
Fact - Search spiders don't like confusing or invalid markup, but they are intelliigent enough to work out what is markup and what is keywordable data. If your …

Why not use myspace's inbuilt song sharing? You can set up a band profile, add the song you want, and then add that song onto your profile as the background music, all using myspace's functionality.

Otherwise, try embeding the same music on a standard HTML page using your embed code and see what happens. Then try embedding the same music using the myspace-altered embed code.

My question, is there any way to protect my idea, like, to have it patented?

Yes and no.

Firstly, it depends on your local jurisdiction; in America, patents can cover very general ideas, in the UK they can only cover certain things; with exceptions including computer software and mathematic methods.

Secondly, it depends on proofing. You need to be able to prove that you either have implemented, or have throughoughly planned how to implement the idea. You also need to be able to comprehensively detail the parts of your idea that are unique and your own, and therefore patentable. It's more common for companies to patent tiny details of a product or service or system rather than the entire thing, which leads on to...

Thirdly, you need to know exactly what a patent protects you against. In actuality, unless you're already very rich or legally well connected, it's very little. A useful patent covers an extremely specific idea rather than a generalization, otherwise it's easy for a competing company to change a sufficient part of the details of a general 'idea' and get away with it being a different one. That makes patents about as useful as copyright, which is inherent to any implementation.

Still, that doesn't stop companies successfully patenting the stupidest things and then trying to enforce the patent...
http://www.theregister.co.uk/2003/01/23/sbc_enforcing_allencompassing_web_patent/

You should know, that if you attempt to sue against a company that 'steals your ideas', it might end up costing …

If it's going to be in London; I'm flexible.

But, Febuary would be better for me than January: I gotta get a load of work finished this month.

And Febuary would be better than March, because I can't plan that far ahead =P

Well. All style rules for the class a.externallink will be applied during the 'pseudoclass states' (a.externallink:link a.externallink:hover a.externallink:active and a.externallink:visited) unless style rules defined for those pseudoclasses overide rules defined for the class.

Putting the definition for CSS3 target properties in a pseudoclass might cause seemingly erratic behaviour; I don't know whether a:link and a:visited are mutually exclusive... if they are, and you put the definition in :link, then your links would only open in a new window the first time they are visited.

I don't know whether the :hover state is dropped when a link is clicked: If it is, and you put the link in :hover or :active; your links would only open in a new window until they are clicked... i.e. never =P

i imagine that you wouldn't need the :link psuedoclass on that selector when/if it is implemented.. so it'll just be: a.externallink{...}

did you see the link in that post?

i guess it would be something like:

a.externallink:link { 
  target-name: new;
  target-new: window;
}

or (exclusive)...

a.externallink:link { 
  target: new window;
}

the stuff outlined at that location (http://www.w3.org/TR/css3-hyperlinks/) is a working draft... that means it isn't necessarily going to end up like that in the official CSS3 spec when it's done.

personally, i'd stick with the target='_blank' or target='<string>' method until/unless that spec is implemented in at least one popular browser...

by the way. you will probably get an alert or 2 if that kind of thing is done on a browser that's alert-ridden, like IE7.

FOLLOWUP:
Even on an oldish version of Firefox (1.0.2), the correct behaviour is adhered to; the correct behaviour being that only script-generated windows can close themselves or be closed. Proofing is as follows:

File #1 (test1.html)

<html>
<head></head>
<body>
<script type="text/javascript">
alert("Opening test2 in a new window");
var newWindow = window.open('/home/matt/test2.html');
</script>
</body>
</html>

File #2 (test2.html)

<html>
<head></head>
<body>
<script type="text/javascript">
alert("Closing test2's window");
window.close();
var newWindow = window.open('/home/matt/test3.html');
</script>
</body>
</html>

File #3 (test3.html)

(doesn't matter)

Opening the browser on test1.html causes test2.html to be opened in a new window, then that window is closed and test3.html is loaded in another new window.

Opening the browser on test2.html causes test3.html to be opened in another window: but the window holding test2.html doesn't close.

There was also a 'popup blocked' bar until I allowed popups from my local machine. That would be present in most browsers. Except the ultimate Opera of course..

...perhaps that's not true.

in Opera:

<html>
<head></head>
<body>
<script type="text/javascript">
window.close();
var newWindow = window.open('/home/matt/test3.html');
</script>
</body>
</html>

works whether the window that processes that code was opened via a javascript process or not..

...interesting info.