boen_robot

<style>body {display: none;}.doNotHide {display: block;}</style> maybe this?after all, the fact that doNotHide is a class name and (supposibly) belongs to a child of body, it means it's treated with higher priority, making everything besides it invisible.Just notice that in the above case, your elements from this class should be block elements. Otherwise, they'll get the features of block elements.

And how would this tutorial be written? What it should contain?... honestly... I have never seen such tutorial. I can't image how would such thing be like.

Creating tableless layout is a matter of skill, not about knowing the possible things. A single pointer in the table section of the HTML tutorial about not using tables for layout would be enough.

The only wrong I see here is the first line. It has to go(be removed). What it shows is DTD's basic syntax. It's not suppose to be part of the DTD. Also, at the end of the whole code, there's the "]>" missing.

Execuse me for being so honest, but: hahaha . I never though I would see someone confusing Schema with XSLT. I mean, the overall fact that you've written something and use the XSL namespace should tell you at least that .Schema is a way to define legal building blocks of XML documents.XSLT is a way to transform XML documents to other documets from the XML family, another XML or just a plain text.Anyway... back to the problemYour XSLT actually worked when I tested it. The only adjustment I made was the reference to the XSLT file, because I stored the XSLT in the same folder as the XML, so I didn't needed the "C:\". Try this for starters...I also notice that you want XML output, but you haven't pointed any XML tags to use. XSLT uses XPath expression that extract the content of the desired element or attribute. This means that you must "manually" write the names of the new XML elements and attributes.Try this XSLT: <?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="xml" encoding="utf-8" indent="yes" version="1.0"/><xsl:template match="/"><goods_nom_item> <xsl:for-each select="//goods_nom_item"> <id><xsl:value-of select="@id"/></id> <expimp><xsl:value-of select="expimp[@typ]"/></expimp> <dat_start><xsl:value-of select="//dat_start"/></dat_start> <dat_end><xsl:value-of select="//dat_end"/></dat_end> </xsl:for-each></goods_nom_item></xsl:template></xsl:stylesheet> My tests display the output as a text though. There isn't any XML tree shown. I haven't tryed converting XML-to-XML so I don't know if that's how it's suppose to be.

Darn good point what vshris said . By the way, I think that if the background was... how do you say... light brown, beige, fown? Anyway... such a background would be more in W3Schools theme. Of couse if such is used, it would requre black text too.

What do you mean by "export"? If you want a link to it, you could always do something like <xsl:variable name="href" select="XPath to the node containing the URL to the video" /><a href="{$href}"><xsl:value-of select="title of the movie if there is one?" /></a> And if you want to embed it in the XHTML output, you could use the <object>. <xsl:variable name="name" select="XPath to the node containing the name of the video" /><xsl:variable name="href" select="XPath to the node containing the URL to the video" /><objectclassid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95"><param name="{$name}" value="{$href}" /></object> P.S. Not sure which videos is this classid going to play...If I haven't understood correctly, please paraphrase yourself.

And have you published this in the IE newsgroup?

Height to tell you this, but loading content from extental XML based languages is one of the main reasons I prefer SVG over Flash. If there's any way with Flash, it's probably really complicated. After all, Flash is suppose to run on pages, not pages on Flash .Unless you are already too deep into Flash, try doing some stuff with combinations of SVG and XSLT and you'll see what I mean

As far as I know flash could have form, could display previously entered in a form data, and can send form's content to another file(simmilarly to HTML ), but it can't alone process the form. Server side script is the one true way of processing AND saving form data.

A rule such as "duplicate posts not allowed without AT LEAST 24 hours delay" sounds good to me. Infact, I happen to be an admin of a forum where there's already such a rule .btw, in the above poll I voted for "don't care", cause there really isn't a best answer to this.

In theese particular cases: yes. But you shouldn't be so harsh either. It's true that most people just can't see everything and that it has to be on the top to be seen. I have happened to helped with a problem that was two weeks away, but I didn't knew about it until it's author said "anybody?". This makes people try to get their attention without writting real bulls*its (believe me, I know what I'm talking about by saying "real bulls*it"). Look at my topics(not posts) to see what I mean. I have written very few(5) and there are replies to only 2 of them. The other ones have "anyone?"s, scince they truly feel lonely.Infact, I feel kind'a bad that I can't help on theese topics above, you know...

You may do something like this: <?xml version="1.0" encoding="windows-1251"?><xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="html" version="1.1" encoding='UTF-8' indent='yes' doctype-public="-//W3C//DTD XHTML 1.1//EN"/><xsl:template match="/"><html xmlns="http://www.w3.org/1999/xhtml"> <xsl:apply-templates /></html></xsl:template><xsl:include href="header.xsl" /><xsl:include href="body.xsl" /></xsl:stylesheet> The XML file this would be attached to would be the XML files that contain the real content. The included XSLTs (header.xsl and body.xsl in this case) should contain whatever you want to put inside theese parts and the header should include reference to another XML document (using the document() function) that would display their content.This is actually pretty neat to get rid of the frames and still keep the flexibility of it. Infact... hey! You were the one who showed me this method .

Not quite... It all matters which stylesheet is ran first. That stylesheet imports the rest and all the things inside the included stylesheets are ran if the stylesheet was one and all.That doesn't matter though. The importaint thing here is that:<xsl:for-each select="skill"><xsl:apply-templates /></xsl:for-each> Is (as you suggested) going to (try to) apply all other templates at that spot, but technically speaking, if there are no possible relative matches inside, XSLT doesn't have anything to apply the templates on.In short:1st line. Correct2nd line. Wrong

Oh well... another idea:Apply all the properties of sub2 to the container. This creates the illusion that it's sub2 which is configured. This would look ugly if there were margins though.

80% in sub2 and 20% to sub1?[edit]posted similtaniously with pulpfiction [/edit]

By the way:background-color:green;notbackground-color=green;

XML only carries "ordinary" data. You could however mark the things that are superscripts:<text>2<superscript>2</superscript>=4</text>And then use some XSLT with proper CSS to adjust the sisez and positions .

I added the select attribute to ensure that this would work if there are other things in the XSLT. However, if that's not the case, you can simply remove the select attribute. This would apply ALL templates if only they have appropriate matches inside. This could make the things unstable if not used wisely, but if you have a single XSLT containg only all skills, then you don't need the select attribute and you can remove it without any worries in the short and long term.

As far as I know, nested templates are not allowed. You could use <xsl:call-templates/> element though. Adding attribute "select" would activate the desired template at that spot.I almost see where this is all going. Perhaps the unclear XSLT is the only thing that confuses me now. Here's an altered version of the code: <xsl:template match="skills"><xsl:for-each select="skill"><xsl:apply-templates select="Sense Motive" /></xsl:for-each> </xsl:template><xsl:template match="name" name="Sense Motive"/> <xsl:variable name="Sensemotivemisc" select="modifiers/modifier[@name = 'misc']/@value" /> <intvalue name="sensemotivemisc"> <xsl:value-of select="$Sensemotivemisc"/> </intvalue> <xsl:variable name="Sensemotiveranks" select="modifiers/modifier[@name = 'rank']/@value" /> <intvalue name="sensemotiveranks"> <xsl:value-of select="$Sensemotiveranks"/> </intvalue > <xsl:variable name="Sensemotivestat" select="modifiers/modifier[@name = 'ability']/@value" /> <intvalue name="sensemotivestat" <xsl:value-of select="$Sensemotivestat"/> </intvalue> </xsl:template> I haven't tested it, but if all is correct, it should work.If you want to ensure priority you could use the "priority" attribute of the xsl:template. Just use integer value in it to specify which should have a higher one.

I haven't seen that XMetal, but from what I understand, the application automatically generates a schema for the XML file, so it could force you to write valid code. Is there some window like that? If so, could you manually edit the schema? If you could, you could define the new element as valid in the schema and then feel free to use it everywhere in the document.

http://www.w3schools.com/site/site_search.aspSays enough

Most companyes want a CV when you apply for a job. You can easily say "x ears of experience. A detailed list of previous clients could be found at www.yoursite.com/portfolio. Some of them include:..."So, a freelancer is judged by his/her work, not by what he/she points as a years of experience and a web design worker is judged by the number of years.

There are always meta redirects if that's what you want, but this could "break" the back button. <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://www.example.org/bar">

I can't suggest much without knowing the full server side's system... hmm...A thing you might do, would be to add an attribute to each menu about which group should have acces to it. Example: <menu> <item access="admin"> <title>Site control panel</title> <link>http://example.com/admin/</link> </item> <item> <title>Home</title> <link>http://example.com</link> </item></menu> Then use the server side script to generate only the menus that have the corresponding attribute(s). You may use XSLT too, but there's a tricky point here for dealing with security. Hmm... you may use the server side to generate the appropriate XML and apply a fixed XSLT that would render the menus there.Again... nothing is certain. There are many ways to do the things, but it all depends on the rest of the system.