For what it is worth, I've discovered that asking the FOP Caller to send you a packet of information so you can make your decision based on that pretty much ends all the pain. They thank you and hang up. A couple weeks later you get the packet of info... which sometimes even contains the coveted FOP sticker!
Okay, very valid points. I agree with you on most points: Adding one attribute at a time can be time consuming, though i suppose you could write a function and pass it all the values and let the function handle it for you (though that certainly wouldn't limit the number of bytes involved). Traversing the tree can be relatively cumbersome, but at least it is _somewhat_ standard. Replacing children and oh-my-god-insertBefore absolutely suck.
I think, though, that a lot of this is encumbered by not being able to swear up and down that the data is valid xml data. Javascript can't be allowed to die a horrible, horrible death upon finding nodes that are a little out-of-spec. If all the data was in xml format, then why would you expect to be able to pull plaintext (containing line-breaks) out of a paragraph? should pulling the textual data from <p>some text<br/>some more text<p> really return <br/> as part of the text string? Should it return all the text minus the break? I think the current implementation (a collection of two text nodes and a br node) makes more sense those two options.
And more importantly, is there a programming language that already handles this in a sensible and concise manner? Something that can set the stage? I haven't played with the DOM in anything other than javascript and php.
Thanks for the insight(s). I really am curious to see if there are some really good implementations of DOM parsers out there.
According to the internet, he's a really swell guy.
"Chuck Norris built a time machine and went back in time to stop the JFK
assassination. As Oswald shot, Chuck met all three bullets with his beard,
deflecting them. JFK's head exploded out of sheer amazement."
As a web developer this comes as great news; the more OSs you can boot into and browsers you can use on a single machine, the better. I've always lacked an OSX/Safari testbed... who the hell wants to buy a separate (and pricey!) machine just for testing?
You would think so, but then you've got my gf. She has mozilla forcing some cursed fantasy-style font regardless of the intended website font. Even she has difficulty reading it, but it "looks nice". *sigh*
In a pseudo-similar vein, my company's ridiculous "brand identity" mandates using trebuchet ms on the website. Imagine the VP of Marketing's discontent when she opens the website on a non-MS machine (which, luckily, hasn't happened yet). I can guarantee you she will come to me to ask why it looks like that and what we can do about it.
IE, i believe, has a proprietary method for implementing this that violates quite a few specs.
Also: it is part of the spec for css3 (background-size property) as seen here: http://www.w3.org/TR/2005/WD-css3-background-20050 216/
Slashdot Mirror
what is really funny is that your joke actually made me understand this whole quantam computing thing better than the actual explanations did.
For what it is worth, I've discovered that asking the FOP Caller to send you a packet of information so you can make your decision based on that pretty much ends all the pain. They thank you and hang up. A couple weeks later you get the packet of info... which sometimes even contains the coveted FOP sticker!
Okay, very valid points. I agree with you on most points: Adding one attribute at a time can be time consuming, though i suppose you could write a function and pass it all the values and let the function handle it for you (though that certainly wouldn't limit the number of bytes involved). Traversing the tree can be relatively cumbersome, but at least it is _somewhat_ standard. Replacing children and oh-my-god-insertBefore absolutely suck.
I think, though, that a lot of this is encumbered by not being able to swear up and down that the data is valid xml data. Javascript can't be allowed to die a horrible, horrible death upon finding nodes that are a little out-of-spec. If all the data was in xml format, then why would you expect to be able to pull plaintext (containing line-breaks) out of a paragraph? should pulling the textual data from <p>some text<br />some more text<p> really return <br /> as part of the text string? Should it return all the text minus the break? I think the current implementation (a collection of two text nodes and a br node) makes more sense those two options.
And more importantly, is there a programming language that already handles this in a sensible and concise manner? Something that can set the stage? I haven't played with the DOM in anything other than javascript and php.
Thanks for the insight(s). I really am curious to see if there are some really good implementations of DOM parsers out there.
Javascript's DOM access is hideous? I've always thought it was rather straightforward and relatively powerful. How would you do it?
Damn. Valid point.
Chuck Norris.
According to the internet, he's a really swell guy.
"Chuck Norris built a time machine and went back in time to stop the JFK assassination. As Oswald shot, Chuck met all three bullets with his beard, deflecting them. JFK's head exploded out of sheer amazement."
As a web developer this comes as great news; the more OSs you can boot into and browsers you can use on a single machine, the better. I've always lacked an OSX/Safari testbed... who the hell wants to buy a separate (and pricey!) machine just for testing?
If they had sold the games without a modded console would they have been charged, or if they just modded the console?
only one way to find out... wish me luck!
You would think so, but then you've got my gf. She has mozilla forcing some cursed fantasy-style font regardless of the intended website font. Even she has difficulty reading it, but it "looks nice". *sigh* In a pseudo-similar vein, my company's ridiculous "brand identity" mandates using trebuchet ms on the website. Imagine the VP of Marketing's discontent when she opens the website on a non-MS machine (which, luckily, hasn't happened yet). I can guarantee you she will come to me to ask why it looks like that and what we can do about it.
IE, i believe, has a proprietary method for implementing this that violates quite a few specs. Also: it is part of the spec for css3 (background-size property) as seen here: http://www.w3.org/TR/2005/WD-css3-background-20050 216/
And why not legally restrict advertising and viruses to particular ports too? Gosh, this is going to solve all the internet's problems!
fwiw, they've fixed an issue with the removal of plugins crashing ff. https://bugzilla.mozilla.org/show_bug.cgi?id=31602 5#c6
appears to have been a popular issue.