It's always fun seeing people going "this shows your lack of understanding", when CSS is in fact a huge monster of a spec, and extremely complex.
As for the matter of contention, yes, inline elements can contain block elements. This is usually illegal HTML, but XML is another ballgame.
Q: May elements with display:inline contain children with display:block? A: Yes, absolutely. I do this occasionally (by Bert Bos, you know, CSS guru and all?)
Now, I do not pretend to know whether Bert is right or not, but when I can find out this much, with five minutes, don't go around thinking you know it all.
Short of a theoretical Von Neumann machine, ALL computing devices are limited in one way or another.
There is no such thing, as a "/un/limited resource computing device".
Opera's reasoning for believing that MS deliberatly sent a *mangled* stylesheet to the *new* (v. 7 at the time) Opera browser is quite simply stunning.
Of course, since Håkon isn't exactly MS pro, it comes as no great surprise either.
Reading Howcome's page, there is one perfectly believeble view on the whole affair, that Howcome deliberatly leaves out, in order to make MSN look bad. How very fitting for him.
The simple point that Howcome forgets to leave out, is that, while Opera 7 (note the seven), does get "stupid" content (let's say it was designed for retarded browsers), the key point is, that Opera 6 gets the FULL content (I tested this, when this story first came out)! Thus, it's clear, that it's merely a really badly coded browser sniffer on MSN's part. Nothing to do with "evil intentions". Just shitty code, that forgets about future versions of browsers.
I wrote howcome on the issue. His reply? I'm paraphrasing, but basicly, "it was not important"...
(Note that I am an Opera user too, but this extreme fanboyism I see from some Opera users is scary. Crying murder, because you get served a special page is just weird. Especially When there's no such thing)
You look for the tag that never went out of the woods. And the last know "checkin" of that tag.
Sure, if someone (family?) comes and says "joey is lost in the woods, find him", you can't say "that record there, shows joeys last position", but you CAN say "here, we had a hiker, who after passing this sensor, went lost. probably our guy".
hand out some sort of tag to the hikers when they arrive. if the hiker wants it, they can carry it along. when they come within reach of a sensor, the tag gets a session id of sorts.
this way, you can track individual persons about the woods, but have no actual knowlegde of who they are, other then "some person".
when the hikers leave the area, they hand in the tag, which is reset and then given to someone else.
public disclosure in a system, which cannot expose individuals is a good thing:)
While what you say is true, Microsoft, especially with regards to Internet Explorer, also has a history of leading. IE4 was the first browser ever, to implement what was the core idea in DOM. It was one of the first to implement a solid event model (the NN4 model blew).
Interesting how Rob Pike also sees this.
http://www.cs.bell-labs.com/who/rob/utah2000.pdf
He comments how no place has space for the kinda breath that system design involves (ironically, working at Bell). All acedemia does, is to focus down, in extremely narrow topics, while the industry is caught up in solving technical problems. He notes: "Narrowness of experience leads to narrowness of imagination."
Sounds like the people here have no idea what makes GUI's so powerfull.
1. State. You can (should) always at a glance be able to see what state the system has. With a CLI interface, there's simply no state. It's a command execute cycle forever.
2. Exploration. Simply exploring a program, by seeing what it menu's contains, is a very easy, and intuitive way of exploring. CLI's have none of this.
3. Rote memorisation. There is no motor memory when using the CLI. You must remember the syntax of commands 100% accurately. GUI's support "knowlegde in the world", as Norman puts it. Consider a door handle on a door, it has an obvious way of being used. Staring at "~$", is so very different.
4. Easy reversal.
In fact, the benefits of GUI's over CLI's are so many fold, I won't bother with digging out the literature.
The command line has only one advantagde, it's speed, and the possibility of executing extremely complex commands. Both not things newbies are well known for.
"To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels."
Funny, I thought that was the same with CLI's. With a GUI, the GUI can at least support exploration of the interface. Click that arrow down, see what happens. A CLI can do none of these things, unless you consider adding random letters after a command, to be "exploration"...
Stereotype, that C/Cis "just faster"
on
Practical C++
·
· Score: 1
That C or C++ is "just faster", is a myth, and we should not further it. It should of course, be clear to anyone, that the language itself, makes no difference, but the implementation of said language, makes all the difference.
From "The Practice of Programming" ( http://cm.bell-labs.com/cm/cs/tpop/ ), I quote the following numbers, the running time, for a program, doing the Markov Chain algorithm on some large input text.
Email the author. I just did, rebutting two of his "points". rjones@devx.com
Hey Russel,
Just two obvious points of rebuttal.
1. Your question:
Who's Watching the Watchers?
Makes a cold chill run down my spine, when I think of closed source
software. In fact, many of your statements, such as the rogue coder,
holds just as true, for CSS. The difference? You (as a consumer)
cannot see the code. At atmosphere, which breeds closedness, and
non-disclosure of hacker attacks, is far more scary, then one (such
as Debian), which openly announces, that it has been hacked. Imagine
a hacker gaining access to Microsoft code. Imagine MS catching him,
and removing the malicious code. But... did they get it all? Only
the hacker will ever know.
Your statement, that "core" members, will port the code, just doesn't
make sense. Assuming we're not into the old chicken and egg problem,
with the bootstrapping compiler, an Open Source project, is defined
as having the source open. If you compile a program, and it ends up
different, then the one you downloaded, then something is very
wrong indeed.
2. In academia, and security circles, full disclosure, to be able to
repeat trials, and be able to uncover weaknesses in software, is the
norm. Hiding behind binary code, does not a very powerfull brickwall
make. Hiding behind a wellthought out design, which is not open to
attacks (confirmed by peerreview), and relies on algoritmic
defences, makes a strong brick wall.
When I am with like minded people, I can still call things a clever/bad/brilliant hack. And if I tell someone, "damn, you're a hacker", I only say it, if I know that person takes it as admiration.
Computing is, in some ways, a subculture, and as any other subculture, we can have our own sayings, traditions, and so on. If I talk with my dad, a hacker is a bad thing. When I talk with my CS fellow students, a hacker is something to be in admiration of.
I'm using XP here, I fired IE up, set it towards cryptome.org (been a while since I was there, and it's a fairly big page), it would and did take a while to load.
So while the status bar says "connecting to" I change focus to Notepad (which I had started up before hand), typing away. And know what? IE doesn't take focus, it doesn't even blink in the damn taskbar.
Me thinks you have a bad setup, or have messed with something you should not.
When a form in Windows wants focus, it should follow the guidelines, and blink in the taskbar. There, no focus stolen.
Of course, if you invoke a form, and you don't know it, perhaps you should pay attention to what's happening on the screen, instead of blindingly assume that you type perfection.
Perl was amongst the first. Perl was created sometime in the eighties, well before the net. PHP has it's roots in another product, created in 1995. ASP was even later, coming out in 1996. While CGI can be written in pretty much any language, perl has long been recognized, as leading the way forward in CGI, it doesn't do this anymore, since specialized languages and frameworks have come out, but that doesn't make it any less true, that Perl was there first and foremost (look at the URL of this site, see the.pl?) (and let's ignore that Java isn't a scripting language).
The other thing you say, is mostly personal opinion, but weighted against these comments, I wouldn't put much into them, you obviously weren't there back then. CGI allowed for dynamic content, a site such as/. couldn't have been created, without CGI.
How the comment is modded as "score: 3, informative" is beyond me.
Because people just don't know dick about what they're modding, and as such, will mod anything which sounds remotely plausible (it sounds plausible in my ears after all) up.
Re:The online PHP documentation could be improved
on
Core PHP Programming
·
· Score: 4, Informative
Also, when you want the lowdown on a function, it's super easy to just enter
www.php.net/functionname
into your browser, and you're forwarded straight to the functions documentation, and usually also the local mirror. Sweet stuff.
Making scripts in either JS, or in BASH (which is the only shell for which I've made anything larger) is IMO equally challenging (what is the deal with backticks anyway?). I've written Windows scripts for years, go to Uni, and learning Unix, wanting to write a few competent scripts (which I succeeded in) was hard, and it didn't look pretty. At all. It's all a mindset thing.
Using Windows scripting, yes, it's a real language, I suppose it would be like writing scripts in perl. I've quickly written large text processing scripts, and similar stuff. I don't know why bash programming and perl/jscript/vbscript should differ so much. When you use bash you still need to know the syntax of all those cli programs you're calling (egrep, whoo, what a hoot!), and the basic "how to get this done" syntax (which can be arcane, if-fi with []??).
Calling something as an object requires very little work (it requires some work from the object makers side though). CreateObject(classidhere) usually does the trick.
Windows has a focus, as you say, towards the user interface, but to totally deny it's scripting powers, seems silly to me. They are definently not in the area of shell scripting, but it's (well, what to call it, I don't think there's a unix equiv) general scripting abilities are strong. Surf around technet, and it's scripting center, just to get an idea, of what is possible.
And to say that MS should change, is not realistic. Putting effort into serving a certain style of usage, which isn't the one their core demographic exhibits, is a waste of money. I'd rather they spend that money on much more urgent things. And write nero, and suggest it!:)
1. there is no DOS anymore. If you mean CMD, then it does suck badly for scripting, but if you want to do anything serious, JScript (or *shudder*, VBScript) is a very strong and powerfull alternative. I've done tons of scripting in it, and it has alot of enterprise capabalities. Many of the AD (google ADSI), and WMI stuff is scriptable.
2. Well, that's a philosophy thing, but many programs can be called as objects, you can call word this way, and print out stuff, and other dark voodoo (well, I never tried it, so I think of it as dark voodoo). It's program dependent though. Not something to blame MS for.
In short, Windows has strong scripting, JScript and VBScript are capable languages. That Windows as a whole doesn't follow the Unix way, with tons of small tools is not really related. You can always download win32 versions of most Unix tools anyway. The rest is a nice list though.
Re:shouldn't this be called ECMASCrypt?
on
Javascrypt
·
· Score: 1
ECMAScript is just the core. It does not define the various clientside elements that this program takes advantagde of, such as using mouse input, to generate something random. Describing it as ECMAScript would be wrong. Describing it as JavaScript or JScript would, OTOH be correct.
Slashdot Mirror
It's always fun seeing people going "this shows your lack of understanding", when CSS is in fact a huge monster of a spec, and extremely complex.
0 02 May/0226.html
As for the matter of contention, yes, inline elements can contain block elements. This is usually illegal HTML, but XML is another ballgame.
Q: May elements with display:inline contain children with display:block?
A: Yes, absolutely. I do this occasionally (by Bert Bos, you know, CSS guru and all?)
http://lists.w3.org/Archives/Public/www-style/2
Now, I do not pretend to know whether Bert is right or not, but when I can find out this much, with five minutes, don't go around thinking you know it all.
Short of a theoretical Von Neumann machine, ALL computing devices are limited in one way or another. There is no such thing, as a "/un/limited resource computing device".
Opera's reasoning for believing that MS deliberatly sent a *mangled* stylesheet to the *new* (v. 7 at the time) Opera browser is quite simply stunning.
Of course, since Håkon isn't exactly MS pro, it comes as no great surprise either.
Reading Howcome's page, there is one perfectly believeble view on the whole affair, that Howcome deliberatly leaves out, in order to make MSN look bad. How very fitting for him.
The simple point that Howcome forgets to leave out, is that, while Opera 7 (note the seven), does get "stupid" content (let's say it was designed for retarded browsers), the key point is, that Opera 6 gets the FULL content (I tested this, when this story first came out)! Thus, it's clear, that it's merely a really badly coded browser sniffer on MSN's part. Nothing to do with "evil intentions". Just shitty code, that forgets about future versions of browsers.
I wrote howcome on the issue. His reply? I'm paraphrasing, but basicly, "it was not important"...
(Note that I am an Opera user too, but this extreme fanboyism I see from some Opera users is scary. Crying murder, because you get served a special page is just weird. Especially When there's no such thing)
You look for the tag that never went out of the woods. And the last know "checkin" of that tag. Sure, if someone (family?) comes and says "joey is lost in the woods, find him", you can't say "that record there, shows joeys last position", but you CAN say "here, we had a hiker, who after passing this sensor, went lost. probably our guy".
keep it anonymous and public.
:)
hand out some sort of tag to the hikers when they arrive. if the hiker wants it, they can carry it along. when they come within reach of a sensor, the tag gets a session id of sorts.
this way, you can track individual persons about the woods, but have no actual knowlegde of who they are, other then "some person".
when the hikers leave the area, they hand in the tag, which is reset and then given to someone else.
public disclosure in a system, which cannot expose individuals is a good thing
While what you say is true, Microsoft, especially with regards to Internet Explorer, also has a history of leading. IE4 was the first browser ever, to implement what was the core idea in DOM. It was one of the first to implement a solid event model (the NN4 model blew).
Interesting how Rob Pike also sees this. http://www.cs.bell-labs.com/who/rob/utah2000.pdf He comments how no place has space for the kinda breath that system design involves (ironically, working at Bell). All acedemia does, is to focus down, in extremely narrow topics, while the industry is caught up in solving technical problems. He notes: "Narrowness of experience leads to narrowness of imagination."
Mine is aptly named "The Idiots Around Me".
Also, don't forget the modus operanti of Unix tools on succesfull operation. No feedback...
How the hell do you have a dialogue with someone who won't talk with you?
Sounds like the people here have no idea what makes GUI's so powerfull.
...
1. State. You can (should) always at a glance be able to see what state the system has. With a CLI interface, there's simply no state. It's a command execute cycle forever.
2. Exploration. Simply exploring a program, by seeing what it menu's contains, is a very easy, and intuitive way of exploring. CLI's have none of this.
3. Rote memorisation. There is no motor memory when using the CLI. You must remember the syntax of commands 100% accurately. GUI's support "knowlegde in the world", as Norman puts it. Consider a door handle on a door, it has an obvious way of being used. Staring at "~$", is so very different.
4. Easy reversal.
In fact, the benefits of GUI's over CLI's are so many fold, I won't bother with digging out the literature.
The command line has only one advantagde, it's speed, and the possibility of executing extremely complex commands. Both not things newbies are well known for.
"To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels."
Funny, I thought that was the same with CLI's. With a GUI, the GUI can at least support exploration of the interface. Click that arrow down, see what happens. A CLI can do none of these things, unless you consider adding random letters after a command, to be "exploration"
That C or C++ is "just faster", is a myth, and we should not further it. It should of course, be clear to anyone, that the language itself, makes no difference, but the implementation of said language, makes all the difference.
From "The Practice of Programming" ( http://cm.bell-labs.com/cm/cs/tpop/ ), I quote the following numbers, the running time, for a program, doing the Markov Chain algorithm on some large input text.
250MHz 400MHz
R1000 Pentium LOC
Irix 6.4 WinNT 4
C | 0.36 sec | 0.30 sec | 150
Java | 4.9 | 9.2 | 105
C++/STL/dequeue | 2.6 | 11.2 | 70
C++/STL/list | 1.7 | 1.5 | 70
Awk | 2.2 | 2.1 | 20
Perl | 1.8 | 1.0 | 18
(C/C++ compiled with optimizing compilers, Java had JIT enabled)
Sorry, I've always been berated for my poor commas when I write english. I do try to constrain myself, but well :)
Email the author. I just did, rebutting two of his "points". rjones@devx.com
... did they get it all? Only
Hey Russel,
Just two obvious points of rebuttal.
1. Your question:
Who's Watching the Watchers?
Makes a cold chill run down my spine, when I think of closed source
software. In fact, many of your statements, such as the rogue coder,
holds just as true, for CSS. The difference? You (as a consumer)
cannot see the code. At atmosphere, which breeds closedness, and
non-disclosure of hacker attacks, is far more scary, then one (such
as Debian), which openly announces, that it has been hacked. Imagine
a hacker gaining access to Microsoft code. Imagine MS catching him,
and removing the malicious code. But
the hacker will ever know.
Your statement, that "core" members, will port the code, just doesn't
make sense. Assuming we're not into the old chicken and egg problem,
with the bootstrapping compiler, an Open Source project, is defined
as having the source open. If you compile a program, and it ends up
different, then the one you downloaded, then something is very
wrong indeed.
2. In academia, and security circles, full disclosure, to be able to
repeat trials, and be able to uncover weaknesses in software, is the
norm. Hiding behind binary code, does not a very powerfull brickwall
make. Hiding behind a wellthought out design, which is not open to
attacks (confirmed by peerreview), and relies on algoritmic
defences, makes a strong brick wall.
I am sorry, but all in all, a very poor article.
Regards,
Svend
When I am with like minded people, I can still call things a clever/bad/brilliant hack. And if I tell someone, "damn, you're a hacker", I only say it, if I know that person takes it as admiration.
Computing is, in some ways, a subculture, and as any other subculture, we can have our own sayings, traditions, and so on. If I talk with my dad, a hacker is a bad thing. When I talk with my CS fellow students, a hacker is something to be in admiration of.
There is room for both.
Actually, she's only expected to be a JavaScript programmer.
.
.
.
.
No, I don't know whether that's funny or sad.
Ok, so we all know that CS guru != Computer wiz
But come on!
Running Windows 98, with a shortcut to AOL on the desktop, and this was just 1 1/2 year ago. For real?? This is his everyday desktop work enviroment?
Nerds truly rule!
Seriously?
I'm using XP here, I fired IE up, set it towards cryptome.org (been a while since I was there, and it's a fairly big page), it would and did take a while to load.
So while the status bar says "connecting to" I change focus to Notepad (which I had started up before hand), typing away. And know what? IE doesn't take focus, it doesn't even blink in the damn taskbar.
Me thinks you have a bad setup, or have messed with something you should not.
When a form in Windows wants focus, it should follow the guidelines, and blink in the taskbar. There, no focus stolen.
Of course, if you invoke a form, and you don't know it, perhaps you should pay attention to what's happening on the screen, instead of blindingly assume that you type perfection.
Perl was amongst the first. Perl was created sometime in the eighties, well before the net. PHP has it's roots in another product, created in 1995. ASP was even later, coming out in 1996. While CGI can be written in pretty much any language, perl has long been recognized, as leading the way forward in CGI, it doesn't do this anymore, since specialized languages and frameworks have come out, but that doesn't make it any less true, that Perl was there first and foremost (look at the URL of this site, see the .pl?) (and let's ignore that Java isn't a scripting language).
The other thing you say, is mostly personal opinion, but weighted against these comments, I wouldn't put much into them, you obviously weren't there back then. CGI allowed for dynamic content, a site such as /. couldn't have been created, without CGI.
Because people just don't know dick about what they're modding, and as such, will mod anything which sounds remotely plausible (it sounds plausible in my ears after all) up.
Also, when you want the lowdown on a function, it's super easy to just enter
www.php.net/functionname
into your browser, and you're forwarded straight to the functions documentation, and usually also the local mirror. Sweet stuff.
Making scripts in either JS, or in BASH (which is the only shell for which I've made anything larger) is IMO equally challenging (what is the deal with backticks anyway?). I've written Windows scripts for years, go to Uni, and learning Unix, wanting to write a few competent scripts (which I succeeded in) was hard, and it didn't look pretty. At all. It's all a mindset thing.
Using Windows scripting, yes, it's a real language, I suppose it would be like writing scripts in perl. I've quickly written large text processing scripts, and similar stuff. I don't know why bash programming and perl/jscript/vbscript should differ so much. When you use bash you still need to know the syntax of all those cli programs you're calling (egrep, whoo, what a hoot!), and the basic "how to get this done" syntax (which can be arcane, if-fi with []??).
Calling something as an object requires very little work (it requires some work from the object makers side though). CreateObject(classidhere) usually does the trick.
Windows has a focus, as you say, towards the user interface, but to totally deny it's scripting powers, seems silly to me. They are definently not in the area of shell scripting, but it's (well, what to call it, I don't think there's a unix equiv) general scripting abilities are strong. Surf around technet, and it's scripting center, just to get an idea, of what is possible.
And to say that MS should change, is not realistic. Putting effort into serving a certain style of usage, which isn't the one their core demographic exhibits, is a waste of money. I'd rather they spend that money on much more urgent things. And write nero, and suggest it! :)
1. there is no DOS anymore. If you mean CMD, then it does suck badly for scripting, but if you want to do anything serious, JScript (or *shudder*, VBScript) is a very strong and powerfull alternative. I've done tons of scripting in it, and it has alot of enterprise capabalities. Many of the AD (google ADSI), and WMI stuff is scriptable.
2. Well, that's a philosophy thing, but many programs can be called as objects, you can call word this way, and print out stuff, and other dark voodoo (well, I never tried it, so I think of it as dark voodoo). It's program dependent though. Not something to blame MS for.
In short, Windows has strong scripting, JScript and VBScript are capable languages. That Windows as a whole doesn't follow the Unix way, with tons of small tools is not really related. You can always download win32 versions of most Unix tools anyway. The rest is a nice list though.
ECMAScript is just the core. It does not define the various clientside elements that this program takes advantagde of, such as using mouse input, to generate something random. Describing it as ECMAScript would be wrong. Describing it as JavaScript or JScript would, OTOH be correct.