You're right, of course - standing up and being counted is a noble effort, and one which I attempt to support at every opportunity.
That said, there is a certain level of professionalism necessary in web design - for example, the most important requirement is that information is accessible first, pretty second.
By this metric you can make the "Firefox experience" of a page as spanky as you like, and the "IE experience" as plain and ugly as you want - as long as the lowest-level version has all its content accessible.
What I think most of the experienced webmasters (including myself) here were complaining about was not that the menu system worked better in Firefox, nor even that it had the (slightly juvenile, if this is intended for a wider audience than a personal website) "SWITCH TO Firefox NOW" incitement slapped on it - we were complaining that it didn't work at all in IE.
Ploughing all your design efforts into the version for your favourite browser is fine, but allowing this to make the base content inaccessible to other browsers is (unarguably) poor design.
Remember - accessibility before prettiness;-)
"We will all be better off standing up and saying, you know what, this does not work well in this environment, so I'll switch and I recommend that you do the same. That's what will change the situation."
Not in web design, mate. In web design refusing to work with the browser that has 80%+ market share means no-one looks at your page. I can't imagine a page important enough that I'd seriously consider changing my default browser to view it, and I've got Firefox, IE, and Opera already downloaded and installed.
In addition, (with the DHTML menu) you aren't doing anything that hasn't already been done on a million other sites, and those all work with IE. This heavily implies (even to uneducated users) that it's not IE that's poor, just that you don't know what you're doing with web design.
Basically, if IE's got 80% market share, then any "principled stand" that excludes it is just cutting off your nose to spite your face. Instead, make sure both versions work (so you don't look bad), but make the Firefox one prettier (so IE looks bad). This means you still look good, you've made your point, and the user isn't forced to suffer because of a choice ("which browser to use") they might not even have made.
Incidentally, many thanks for a calm and considered response. Having re-read my first post I was hardly gentle in my criticism - you have my apologies.;-)
Ah, I see where you're coming from now - the ease of use and wiki-integration rather than user-interface or concept.[1]
That's fair, but I still think you'll find a lot of/.ers will consider it too trivial to be front-pageworthy. Again, I don't know how difficult it is to write PmWiki plugins specifically, but in terms of the task I could write you a Perl RegExp (or at most a few lines of Perl) that would take some minimally-formatted plain text and turn it into a cross-browser, standards-compliant DHTML menu - all you've really got to do is parse the markup for links, massage them into HTML and paste them as items into a pre-working DHTML menu.
I figured there had to be some angle here (namely the Wiki-integration) that was newsworthy - unfortunately the implementation of the front-end (DHTML menu) isn't up to much, so you're probably going to have an awful lot of people going "So what?" until it's pretty, well-coded and cross-browser-compatible.
So, old idea, nice integration, interface needs some work;-)
Footnotes:
[1] I think the Slashdot article overplayed the "revolutionary user-interface advance" angle and underplayed the "handy Wiki addition" one - this is (in part) why you've copped such a lot of flak so far.
"[on that note, yeah, it is excessive for tampon commercials to be piped into a house with 3 20-something guys as the only residents.]"
Indeed, until that fateful day when your girlfriend's bedridden and needs you to dash out to the supermarket and buy her a giant multipack of tampons. Trust me, you grab the first packet you recognise and high-tail it out of there...
I'm sorry about this, and I don't mean to be an arse, but you can argue hypertext theory and philosophy all day. The fact remains that this is neither insightful, interesting, new nor well-executed.
As you indicate in your post, fat (or multi-) linking is not a new idea.
"This is not about being compatible with a popular browser"
Hate to break it to you bud, but in web design, on the web, it is.
If you were doing something really revolutionary here the shoddy implementation would be cut some slack for the conceptual innovation, but what you've produced is fundamentally a drop-down menu.
These have been around as long as layers/divs and javascript - probably pushing ten years now. We've got them in javascript, cross-browser and even CSS-only incarnations.
In addition, you haven't even implemented fat links properly - true fat links should open all the pages they link to from a single click - this is the only thing that separates "multi-links" from "drop-down menus", and your version doesn't do it.
Now, it might be hard to write a plugin for PmWiki, but that's the only bit of (even potential) innovation here, and it's ridiculously self-aggrandising to submit it to Slashdot as any kind of news item.
You might well be owed some small amount of kudos for extending PmWiki's functionality, but your "solution" is so terribly executed (FFS, cross-browser menus aren't hard) and unprofessionally produced ("SWITCH TO Firefox NOW") that any tiny helpful advance is quite lost in the roaring mediocrity of the "feature".
In fact, I know of several rather more militant webmasters who'd probably rather string you up (for encouraging the use and dissemination of such terrible broken code) than pat you on the back for writing this Wiki plugin.
Basically, possibly apart from the Wiki back-end (which might well be hard, but which nobody's interested in), it's not innovative, interesting or elegant. Submitting such a non-event to a widely-read and volatile environment like Slashdot is just asking for people to beat on you for your presumption, especially when you present it like it's the Philosophers' Stone or something.
I'm assuming from your code that you're a beginner web-developer - if so I humbly apologise for the kicking you're getting, and suggest you gain a bit more experience before hyping your next hack. Hackers (and the Slashdot crowd) are generally very sensitive to over-hyping and BS - make sure it's at least interesting before you start telling people it's revolutionary.
HTH
If not, you should seriously consider reading up - may I suggest A List Apart, CSS Edge and Jakob Nielson's Alertbox. They'll save you a lot of embarrassment before going quite so public next time...
Exactly - even if multilinks ("fat links" in HCI) are a good idea (as opposed, for example, to a hideous confusing misfeature), this ain't it.
Multilinks should:
Work in all current browsers. Oh well, that's it fucked right there.
Degrade gracefully on older browsers. IE (no pun intended), the plain, unvarnished HTML link should default to a "disambiguation" page which just links to each of the possible fat link's destinations.
Open all the destinations at the same time (otherwise it's not a fat link, just a menu).
So, what we have here is not a multilink. It is, in fact a javascript drop-down menu, which we've had since... ooooh... the late '90s at least.
About the only mildly "clever" bit of this is that he's written a plugin for a Wiki to generate them automatically. I've never written a plugin for PmWiki, but unless PmWiki-plugin-writing is superhumanly difficult it certainly doesn't warrant a front-page on Slashdot. Hell, it doesn't even warrant a submission.
Not so much "multi-target hyperlinks for the masses" as "a badly-coded dropdown menu generating plugin for an obscure Wiki".
1) The fuckwit Joe Sixpacks who actually click on links in spam are exactly the same users least likely in the world[1] to be using Firefox. These people are typically using AOL and IE because "That's what teh intarweb is" as far as they understand. Sociology 101 - if they're stupid or ill-educated enough to click on links in spam, they'r far too stupid or ill-educated to be relied upon to use a minority (<10%) browser like Firefox, or to download a specific plugin for IE (if it's even possible to do that with an IE plugin).
2) Quis custodiet ipsos custodes? Or, to put it another way, who decides who should go on the list? And what happens when they're sued by the spammers?
3) Exactly how fast would one have to be to keep up with the spammers? They can change servers/hosts/accounts on a daily or weekly basis - exactly how responsive do you see this list being? Helpful hint - the list's level of democracy is inversely proportional to its responsiveness.
Footnotes:
[1] Well, ok, a small one-legged Mongolian peasant box with no access to the internet might be slightly less likely to use Firefox. But only slightly.
I don't know - out of N. Korea, Iran, Libya and the rest of the "Axis of Evil" Saddam was the only one (so far) who woke up to an impromptu visit from the full might[1] of the US military.
[1] Yeah, ok, this might be sarcasm... but "full might of all twelve remaining members of the US military they can still afford to recruit and fund" just doesn't roll off the tongue so well...;-p
The single problem seems to be the insistence that researchers be measurable by a single metric - like sales people are measured by "leads generated", or programmers by "lines of code".
This is a shortsighted impulse beloved of small-minded PHBs (and entire companies), who'd rather add up a column of figures than think about their subordinates and make a judgement call which more accurately reflects their value to a company.
The problems with such arbitrary metrics are obvious - a salesperson may make one sale of ten times as much product as another who makes ten smaller sales, but using the single metric of "sales generated" undervalues the (in fact) more valuable employee.
Programmers can be judged by "number of lines of code per day", but this positively encourages poor programming practices - a good programmer will generally generate smaller, terser programs than a newbie, and time spent on commenting/refactoring code or re-thinking the overall architecture isn't considered.
Likewise (in fact, even more so), researchers are measured in terms of "patents or research papers generated". This is doubly inappropriate, since researchers function essentially as intellectual scouts - foraging ahead and attempting to map out the lay of the land. You rate scouts based on how much they see or how far they range, not on the worth of the items they find, since these are in large part down to dumb luck. In addition, paying scouts based on the worth of what they find ensures only one thing - they'll stick to the areas that look good, and ignore the ones which don't look immediately profitable.
Now, there's nothing wrong with offering incentives for things like papers produced or patents granted, but assessing their worth to a business in these terms misses the point entirely.
Exactly. And the next "generation" is high-quality digital media files that can (in theory) be transcoded indefinitely to whatever's the trendiest format at the moment.
Part of the problem is that content-producers are finally waking up to the idea that, as far as media formats go, this is the last generation.
They weren't so worried about tape piracy, because CDs came along and forced you to re-purchase all your existing media. They stopped worrying about VHS piracy when DVDs came along, because they knew you'd have to "upgrade" all your existing media.
Now it looks like they're off the "customers paying for what they've already bought" gravy-train, they're shitting bricks and trying to move the entire industry to a rental/pay-per-play-micropayments model, since this is even better (in terms of reliable, regular income) than a once-per-generation splurge of replacement purchases.
If free, open-format computer files become the platform of choice, the industry as it presently stands is screwed - no "medium-upgrade" tax, free copying - the whole thing comes crashing down around their ears. This is why they're betting the bank on DRM, and using it to grab as many rights as they can - if they have the chance to set the ground-rules, they might manage to make DRM entrenched enough that they can effectively dictate the direction that the technology takes in the future.
Of course, this is the very definition of a cartel, but since when has being a convicted monopolist ever hurt anyone in the IT/technology industry?
"Over the internet, from people in countries with sane copyright law, same as a lot of/.ers do now."
Right. And when the US uses the heavyhanded threats of (for example) trade sanctions (as, I believe, it already has in the past) to force those countries into line that aren't already lined up behind it champing at the bit, what then?
"Congratulations to SAS on successfully bribing so many various different sources worldwide."
Riiiight. I suspect every "company employee satisfaction survey" is, in fact, filled out only by the staff of the magazine it appears in, right? And not, you know, by the company's actual employees?
Oh, wait, I suppose they could still "bribe" the employees with perks like relaxed working hours, well-equipped break-rooms and timesaving on-campus facilities, right?
So how is that different to actually "being a fun place to work"?
But, of course, that doesn't matter because SAS is clearly a 3v1l c0Rpor4tion - tehy are teh suXX0rz, right?
"Video encryption in real time is doable, but how will they protect the LCD matrix? I'm genuinely curious."
They won't have to - at that point they've won.
As soon as you need actual hardware to pirate the signal, copying movies becomes a restricted occupation again, just like selling free cable boxes. You won't be able to acquire them easily (selling will be illegal, so you'll have to build your own).
Software solutions are freely copyable, anonymously and easily spread and can (in time) be made simple enough that even Joe Sixpack can use them.
Hardware solutions rely on specialist knowledge to build or implement, can't be anonymously "spread" without special skills (namely, building your own or working out a way to mass-sell them without getting caught), and will never (well, not in the near future) be simplified to the point Joe SP can contemplate building his own.
By shifting all the sscurity into hardware they don't just make it harder to break in the first place - they make it damn near impossible to mass-disseminate the crack once you've achieved it.
The best we can hope for is for the details of the (hardware) hack to be made public in philes, messageboards, etc, and that you'll either have the requisite skills to make one yourself, or have a tame geek standing by who can.
Unless we can find a way to abstract the whole architecture (so it's fooled into running in a virtual machine which can report whatever hardware it likes), moving the problem back into software, unauthorised viewing or copyrighted content will become just another low-key cottage industry, like illicit cable boxes.
"IMHO web devellopement is a very specific kind of devellopement. And while respecting standard is important, pragmatism is far more important."
It depends - pragmatism in the sense of ignoring standards got us the fingernails-down-a-blackboard-experience that was web design for most of the late 90s/early 2000s, and often produces pages that look great on IE but don't work or look ugly on other browsers. Call this "code pragmatism".
Pragmatism in the sense of being prepared for your lovely graphical design to degrade right back to ASCII text (or using sematic markup so it can be mashed-up and re-presented by people or scripts) is pretty much what people mean by "standards-compliant coding". Call this "presentational pragmatism".
Generalising madly, the "non-standards" crowd mainly seem to be code pragmatics, whereas the "standards-are-all" crowd seem to be presentational pragmatists.
Being pragmatic doesn't mean anything in the context of the debate - it's what you're most pragmatic about that they disagree on.
"Choosing a target as specific as possible (e.g. Mozilla + IE) and define precise design practices is the only practical choice if you don't wanna end up in CHAOS."
Not even slightly. This sounds like another version of the "standards are bad because they restrict my design options" (which is false, if you know what you're doing) or "standards are bad because they're hard" arguments (which is false because many other people are fine, so it's clearly your failing not the standard's). You could say the same thing about compiling C++ code - you'd be much free-er to write complete gibberish if it didn't have to compile, but a C++ program that doesn't compile is useless.
Likewise (albeit to a lesser degree) non-standards-compliant code is less useful. It won't be semantic markup, so it isn't easy (sometimes even possible) to automatically aggregate it and customise how you access it. Presentation isn't separate from content or behaviour, so it's harder to manage sites or effect large-scale changes to a design. It's tightly tied to old, obsolete ways of doing things that don't degrade well, so when the technology changes (eg, if in five years' time mobile devices are the most popular way to access the web rather than PCs) you find you have to recode everything you've ever written or write it off and lose it forever.
"You need to be very very pragmatic..."
Which doesn't mean anything on its own, as I've demonstrated above.
"...and do everything as simply as possible."
Exactly - this I agree with wholeheartedly.
"Great revolutionnary designs, Design patterns for every problems, extreme modularity, and cutting the codes in many many very small practical functions may often end up being impractical with a web project and make it a hell of a job to be maintained."
Indeed, but those (with the exception of extreme modularity) are all more symptomatic of non-standards-compliant "tag-soup" code than clean, semantic markup, presentation mostly/entirely in CSS and well-coded javascript in a separate file.
Semantic markup is simpler to read than presentational markup - this is pretty much unarguable.
Extreme modularity is almost universally agreed to be a Good Thing - practically every advance or increase in power in computing seems to be a drive towards modularity - OOP, XML, Firefoxes "extensions" vs traditional plugins, DLLs vs duplicated code, interacting suites of tools vs bloated, monolithic applications, etc, etc, etc.
I'm not sure where you got the idea modularity's bad, but it's vastly simpler and vastly more powerful than spaghetti code, and I think you'll find it hard to find a single experienced programmer or developer who'd disagree. Bringing it back to web design, see the CSS Zen Garden for examples of the power of separating content from design.
That's very true - developer-lead sites tend to be ugly but functional, graphic designer-lead sites tend to be pretty, also tend to be badly-coded (or just don't work at all) on other browsers/OSs/days.
Personally (and maybe it's a developer-webmaster thing) I'd rather have a site which was ugly but functional/navigable than one which was pretty but very obviously broken. I've always thought the most important thing was to reach your audience with your message - too many designer-lead sites fail even to do this (or just frustrate users before they have time to absorb your message - I'm looking at you, Flash-only sites).
Regardless of how pretty they'd look if they worked, they still turn users off even faster than an ugly site if/when they don't.
Of course, I'm arguing stereotypes here, but I always design sites from a functionality/navigation angle first, then pretty it up once it's working.
As I've had to explain to wannabe-web designer Directors more times than I can count, "cut the wood and nail it together before you paint the table".;-)
Fair play. Even in the case of IE bugs, you can generally code around them with either the odd CSS hack or some creative javascript.
When I say standards-compliant code, I mean "validating where possible and not causing errors in other browsers" - there's nothing dangerous (IMO) about javascript code like:
Ok, that code might actually cause errors (I haven't got any tested examples to hand to cut-and-paste from), but you get the idea - document.all (IIRC) isn't according to the W3C DOM, but since the script tries to do it the W3C way first (and the non-W3C bit is wrapped in a DOM-detection if statement), it's standards-compliant.
I always find that retrofitting the (standards-working) site to work with IE generally consists of a small number of additional if() statements (like above) in a few low-level functions (generally getters and setters), and some creative CSS hackery to sort out the presentation.
Flawed analogy. One person browsing the web doesn't inconvenience another in any way, unless they DoS the server (which was rather out of the scope of the discussion).
Writing a page in standards-compliant code doesn't inconvenience the IE browser at all, it just allows everyone to use it.
A better analogy would be making the entrance road extra-wide, in case anyone wanted to come down in a horse-buggy (or tank, or whatever). This doesn't inconvenience normal car drivers, and while it may take a tiny fraction more land (to accommodate the wider road), the first time someone comes driving through your drive-in in a tank and buys thousands of dollars-worth of burgers you otherwise wouldn't have sold, it's worth it.
Not to mention the fact that other architects will respect you more for producing such an accessible design, and you'll have that lovely warm glow of knowing you've done your bit to keep road-width-standards open and non-proprietary... (to stretch the metaphor to breaking-point).
Maybe you didn't read my post(s) carefully enough. Using standards-complient code doesn't mean you have to use every bit of markup, and that every element has to work perfectly in every browser. It means writing code that doesn't contravene the standards. IE, no proprietary HTML tags/CSS markup, every page validates, scripts don't cause errors in other browsers, etc, etc. It's not hard.
With absolutely standard HTML/CSS you can do about 95% of everything you'll ever need. For the other 5% there's CSS browser hacks or javascript workarounds (eg, onmouseover instead of:hover CSS rules).
Javascript presents more of a problem (due to differing DOMs), but a simple bit of DOM sniffing (not browser-sniffing) and sensible code-design means that every browser should either (a) support the advanced behaviour or (b) fail silently but usably.
This is not a position held in ignorance - I've been developing for the web since about 1994, and since the advent of XHTML/semantic markup/CSS 2.x/javascript 1.x I've never had a problem doing anything in standards-compliant ways.
That includes converting a site from presentational tables-based HTML 4.? (they didn't even know themselves) produced in Frontpage to one hand-coded in XHTML Strict 1.0/CSS 2.1/Javascript 1.5. In the end (as requested) it was pixel-perfect in IE, and had some small (<10 pixel) margin differences in Firefox/Opera.
Again, and sorry to sound insulting, but if you think standards-compliance can't be done you're either disagreeing with my definition of standards-compliance or just not experienced enough at web development.
Yeah. I was going to perjoratively leave it at the other three, but then I remembered some of the piles of festering crap that have been uploaded to our web server in the past, while I knelt in the background crying and beating my head against the desk.
Seriously - what is it with managers who hire you to be "the expert" in something, then refuse to listen to your advice on scheduling?
You've got a lot more flexibility in intranet development, but you're still voluntarily walking into vendor lock-in, even (as with Firefox) if the vendor vends for £0.
Stick to the standards, and all will be well. Even proprietary extensions from open-source apps aren't always perfectly safe - how would you feel if you'd invested in loads of Mozilla Suite-specific code, when Firefox came out? Or how about if (god forbid) Firefox dies on its arse, and the only options are Opera or (hackcoughspit) IE? You're voluntarily and short-sightedly stuffing yourself, for no real gain.
I really don't understand why people have a problem with sticking to standards. You can basically do anything you'll ever want or need to while still having validating code, but people persist in treating it like some kind of groupthink. Does anyone argue that C/C++ code doesn't have to compile? Or how about the ISO standards for C/C++ - pointless? Or are they the reason we still basically have one language each of C and C++, instead of hundreds of incompatible, balkanised rip-offs?
It depends on the country you're in. Groups in the UK (and I believe Australia) have successfully sued (or at least, settled out of court) over websites that were inaccessible to the disabled.
"Why is it that amongst web developers there is only considered to be 'one way to do things'."
My theory is that it's a combination of:
1. More complex up-front design considerations than many other development tasks - your code is written once, but should run perfectly (or degrade gracefully) on every browser for every operating system for every architecture it ever runs on. In the website design community we deal every day with headaches caused by bugged or incompatible-by-design APIs, sketchy standards support and incredibly customisable interfaces (what's the C/C++/Java equivalent of "disable stylesheets", eh?). When you find a technique that works perfectly/degrades well on all known implementations, you stick to it like glue, and disseminate the word so others don't have to rip their own hair out. CSS tricks are even more slavishly followed, because so many rely on precise, back-engineered quirks of different browsers' rendering algorithms.
2. A large segment of much less-educated community participants. A lot of web designers (even now) have come at it from a graphic design background, and fail to appreciate the complex requirements and difficulties inherent in javascript, XHTML, CSS and how they all interact. Solving a lot of common problems with one approach which can be copied by the less-knowledgeable is a big win when it stops people re-inventing the wheel (and making it square - Flash developers, I'm looking at you).
3. Look where pandering to IE/Netscape and coding to browser quirks got us in the 90s - sometimes it took longer to make a site work acceptably in all browsers than it did to design and implement the first complete version! Quite often these days you'll find the "one way to do it" is basically conforming to the standards, avoiding proprietary extensions and writing pages which validate. There's nothing wrong with it, it encourages browser-manufacturers to conform to the standards, it simplifies the job of the web designer/developer and it doesn't restrict creativity one jot.
"Standards compliance is a good guideline, but it is not law."
No, but it is the only thing that stops you unnecessarily spending twice as long on a job coding to browser quirks. And it does ensure that everyone will be able to at least see the information, even if it's not necessarily pretty (pretty is easy too, for a further small investment of time). And it does mean you can tell the difference between a skilled, professional webmaster and someone's kid nephew with a copy of Frontpage.
"Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA."
Then, with apologies, you fail to understand the fundamental nature of the web. The whole point of the web is that anyone should be able to access information (and web apps count as information), however they like.
"Not expecting" customers to use different browsers only shows that you're closed-minded or not very imaginative (especially for someone posting on Slashdot!). "I didn't expect it" is a pathetic justification when something doesn't work unnecessarily, and indicates a lack of professionalism in your execution.
"Not desiring" it (eg, coding to a specific browser as my company does - I don't) means you're effectively locking yourself and your customers into one company, and everyone knows vendor lockin is a pointless risk - even Microsoft's now paying lip-service to interoperability.
"Yet, people wear their xhtml compliant gif's like medals of honor."
Yes. They're proudly saying "Look - I'm a professional". Or "I care about doing things The Right Way". Or even "Fuck off browser-makers, unless you can make it work according to the standards". How are these a bad thing?
"Write your pages with compliance in mind, but never lose site of refining your apps and pages for your tar
Slashdot Mirror
You're right, of course - standing up and being counted is a noble effort, and one which I attempt to support at every opportunity.
;-)
;-)
That said, there is a certain level of professionalism necessary in web design - for example, the most important requirement is that information is accessible first, pretty second.
By this metric you can make the "Firefox experience" of a page as spanky as you like, and the "IE experience" as plain and ugly as you want - as long as the lowest-level version has all its content accessible.
What I think most of the experienced webmasters (including myself) here were complaining about was not that the menu system worked better in Firefox, nor even that it had the (slightly juvenile, if this is intended for a wider audience than a personal website) "SWITCH TO Firefox NOW" incitement slapped on it - we were complaining that it didn't work at all in IE.
Ploughing all your design efforts into the version for your favourite browser is fine, but allowing this to make the base content inaccessible to other browsers is (unarguably) poor design.
Remember - accessibility before prettiness
"We will all be better off standing up and saying, you know what, this does not work well in this environment, so I'll switch and I recommend that you do the same. That's what will change the situation."
Not in web design, mate. In web design refusing to work with the browser that has 80%+ market share means no-one looks at your page. I can't imagine a page important enough that I'd seriously consider changing my default browser to view it, and I've got Firefox, IE, and Opera already downloaded and installed.
In addition, (with the DHTML menu) you aren't doing anything that hasn't already been done on a million other sites, and those all work with IE. This heavily implies (even to uneducated users) that it's not IE that's poor, just that you don't know what you're doing with web design.
Basically, if IE's got 80% market share, then any "principled stand" that excludes it is just cutting off your nose to spite your face. Instead, make sure both versions work (so you don't look bad), but make the Firefox one prettier (so IE looks bad). This means you still look good, you've made your point, and the user isn't forced to suffer because of a choice ("which browser to use") they might not even have made.
Incidentally, many thanks for a calm and considered response. Having re-read my first post I was hardly gentle in my criticism - you have my apologies.
Ah, I see where you're coming from now - the ease of use and wiki-integration rather than user-interface or concept.[1]
/.ers will consider it too trivial to be front-pageworthy. Again, I don't know how difficult it is to write PmWiki plugins specifically, but in terms of the task I could write you a Perl RegExp (or at most a few lines of Perl) that would take some minimally-formatted plain text and turn it into a cross-browser, standards-compliant DHTML menu - all you've really got to do is parse the markup for links, massage them into HTML and paste them as items into a pre-working DHTML menu.
;-)
That's fair, but I still think you'll find a lot of
I figured there had to be some angle here (namely the Wiki-integration) that was newsworthy - unfortunately the implementation of the front-end (DHTML menu) isn't up to much, so you're probably going to have an awful lot of people going "So what?" until it's pretty, well-coded and cross-browser-compatible.
So, old idea, nice integration, interface needs some work
Footnotes:
[1] I think the Slashdot article overplayed the "revolutionary user-interface advance" angle and underplayed the "handy Wiki addition" one - this is (in part) why you've copped such a lot of flak so far.
"[on that note, yeah, it is excessive for tampon commercials to be piped into a house with 3 20-something guys as the only residents.]"
Indeed, until that fateful day when your girlfriend's bedridden and needs you to dash out to the supermarket and buy her a giant multipack of tampons. Trust me, you grab the first packet you recognise and high-tail it out of there...
Advertising mission accomplished.
Wow... just... wow.
I'm sorry about this, and I don't mean to be an arse, but you can argue hypertext theory and philosophy all day. The fact remains that this is neither insightful, interesting, new nor well-executed.
As you indicate in your post, fat (or multi-) linking is not a new idea.
"This is not about being compatible with a popular browser"
Hate to break it to you bud, but in web design, on the web, it is.
If you were doing something really revolutionary here the shoddy implementation would be cut some slack for the conceptual innovation, but what you've produced is fundamentally a drop-down menu.
These have been around as long as layers/divs and javascript - probably pushing ten years now. We've got them in javascript, cross-browser and even CSS-only incarnations.
In addition, you haven't even implemented fat links properly - true fat links should open all the pages they link to from a single click - this is the only thing that separates "multi-links" from "drop-down menus", and your version doesn't do it.
Now, it might be hard to write a plugin for PmWiki, but that's the only bit of (even potential) innovation here, and it's ridiculously self-aggrandising to submit it to Slashdot as any kind of news item.
You might well be owed some small amount of kudos for extending PmWiki's functionality, but your "solution" is so terribly executed (FFS, cross-browser menus aren't hard) and unprofessionally produced ("SWITCH TO Firefox NOW") that any tiny helpful advance is quite lost in the roaring mediocrity of the "feature".
In fact, I know of several rather more militant webmasters who'd probably rather string you up (for encouraging the use and dissemination of such terrible broken code) than pat you on the back for writing this Wiki plugin.
Basically, possibly apart from the Wiki back-end (which might well be hard, but which nobody's interested in), it's not innovative, interesting or elegant. Submitting such a non-event to a widely-read and volatile environment like Slashdot is just asking for people to beat on you for your presumption, especially when you present it like it's the Philosophers' Stone or something.
I'm assuming from your code that you're a beginner web-developer - if so I humbly apologise for the kicking you're getting, and suggest you gain a bit more experience before hyping your next hack. Hackers (and the Slashdot crowd) are generally very sensitive to over-hyping and BS - make sure it's at least interesting before you start telling people it's revolutionary.
HTH
If not, you should seriously consider reading up - may I suggest A List Apart, CSS Edge and Jakob Nielson's Alertbox. They'll save you a lot of embarrassment before going quite so public next time...
Multilinks should:
So, what we have here is not a multilink. It is, in fact a javascript drop-down menu, which we've had since... ooooh... the late '90s at least.
About the only mildly "clever" bit of this is that he's written a plugin for a Wiki to generate them automatically. I've never written a plugin for PmWiki, but unless PmWiki-plugin-writing is superhumanly difficult it certainly doesn't warrant a front-page on Slashdot. Hell, it doesn't even warrant a submission.
Not so much "multi-target hyperlinks for the masses" as "a badly-coded dropdown menu generating plugin for an obscure Wiki".
That's great, apart from:
1) The fuckwit Joe Sixpacks who actually click on links in spam are exactly the same users least likely in the world[1] to be using Firefox. These people are typically using AOL and IE because "That's what teh intarweb is" as far as they understand. Sociology 101 - if they're stupid or ill-educated enough to click on links in spam, they'r far too stupid or ill-educated to be relied upon to use a minority (<10%) browser like Firefox, or to download a specific plugin for IE (if it's even possible to do that with an IE plugin).
2) Quis custodiet ipsos custodes? Or, to put it another way, who decides who should go on the list? And what happens when they're sued by the spammers?
3) Exactly how fast would one have to be to keep up with the spammers? They can change servers/hosts/accounts on a daily or weekly basis - exactly how responsive do you see this list being? Helpful hint - the list's level of democracy is inversely proportional to its responsiveness.
Footnotes:
[1] Well, ok, a small one-legged Mongolian peasant box with no access to the internet might be slightly less likely to use Firefox. But only slightly.
I don't know - out of N. Korea, Iran, Libya and the rest of the "Axis of Evil" Saddam was the only one (so far) who woke up to an impromptu visit from the full might[1] of the US military.
;-p
I'd say that makes him the most "distinguished", "outstanding" and "famous" threat to the US. Just not the most "scary", "factually-accurate" or "credible" one.
[1] Yeah, ok, this might be sarcasm... but "full might of all twelve remaining members of the US military they can still afford to recruit and fund" just doesn't roll off the tongue so well...
The single problem seems to be the insistence that researchers be measurable by a single metric - like sales people are measured by "leads generated", or programmers by "lines of code".
This is a shortsighted impulse beloved of small-minded PHBs (and entire companies), who'd rather add up a column of figures than think about their subordinates and make a judgement call which more accurately reflects their value to a company.
The problems with such arbitrary metrics are obvious - a salesperson may make one sale of ten times as much product as another who makes ten smaller sales, but using the single metric of "sales generated" undervalues the (in fact) more valuable employee.
Programmers can be judged by "number of lines of code per day", but this positively encourages poor programming practices - a good programmer will generally generate smaller, terser programs than a newbie, and time spent on commenting/refactoring code or re-thinking the overall architecture isn't considered.
Likewise (in fact, even more so), researchers are measured in terms of "patents or research papers generated". This is doubly inappropriate, since researchers function essentially as intellectual scouts - foraging ahead and attempting to map out the lay of the land. You rate scouts based on how much they see or how far they range, not on the worth of the items they find, since these are in large part down to dumb luck. In addition, paying scouts based on the worth of what they find ensures only one thing - they'll stick to the areas that look good, and ignore the ones which don't look immediately profitable.
Now, there's nothing wrong with offering incentives for things like papers produced or patents granted, but assessing their worth to a business in these terms misses the point entirely.
What is so hard to understand about this?
Exactly. And the next "generation" is high-quality digital media files that can (in theory) be transcoded indefinitely to whatever's the trendiest format at the moment.
Part of the problem is that content-producers are finally waking up to the idea that, as far as media formats go, this is the last generation.
They weren't so worried about tape piracy, because CDs came along and forced you to re-purchase all your existing media. They stopped worrying about VHS piracy when DVDs came along, because they knew you'd have to "upgrade" all your existing media.
Now it looks like they're off the "customers paying for what they've already bought" gravy-train, they're shitting bricks and trying to move the entire industry to a rental/pay-per-play-micropayments model, since this is even better (in terms of reliable, regular income) than a once-per-generation splurge of replacement purchases.
If free, open-format computer files become the platform of choice, the industry as it presently stands is screwed - no "medium-upgrade" tax, free copying - the whole thing comes crashing down around their ears. This is why they're betting the bank on DRM, and using it to grab as many rights as they can - if they have the chance to set the ground-rules, they might manage to make DRM entrenched enough that they can effectively dictate the direction that the technology takes in the future.
Of course, this is the very definition of a cartel, but since when has being a convicted monopolist ever hurt anyone in the IT/technology industry?
"Over the internet, from people in countries with sane copyright law, same as a lot of /.ers do now."
Right. And when the US uses the heavyhanded threats of (for example) trade sanctions (as, I believe, it already has in the past) to force those countries into line that aren't already lined up behind it champing at the bit, what then?
That attitude is just another example of "First they came for the Communists, but I was not a Communist..."
"No, I see mislabelled bestiality porn, the Paris Hilton sex video, and 200MB TMD divx rips."
;-p
Ah, but is it mislabelled because it contains bestiality porn, or because it doesn't?
"Congratulations to SAS on successfully bribing so many various different sources worldwide."
Riiiight. I suspect every "company employee satisfaction survey" is, in fact, filled out only by the staff of the magazine it appears in, right? And not, you know, by the company's actual employees?
Oh, wait, I suppose they could still "bribe" the employees with perks like relaxed working hours, well-equipped break-rooms and timesaving on-campus facilities, right?
So how is that different to actually "being a fun place to work"?
But, of course, that doesn't matter because SAS is clearly a 3v1l c0Rpor4tion - tehy are teh suXX0rz, right?
"Video encryption in real time is doable, but how will they protect the LCD matrix? I'm genuinely curious."
They won't have to - at that point they've won.
As soon as you need actual hardware to pirate the signal, copying movies becomes a restricted occupation again, just like selling free cable boxes. You won't be able to acquire them easily (selling will be illegal, so you'll have to build your own).
Software solutions are freely copyable, anonymously and easily spread and can (in time) be made simple enough that even Joe Sixpack can use them.
Hardware solutions rely on specialist knowledge to build or implement, can't be anonymously "spread" without special skills (namely, building your own or working out a way to mass-sell them without getting caught), and will never (well, not in the near future) be simplified to the point Joe SP can contemplate building his own.
By shifting all the sscurity into hardware they don't just make it harder to break in the first place - they make it damn near impossible to mass-disseminate the crack once you've achieved it.
The best we can hope for is for the details of the (hardware) hack to be made public in philes, messageboards, etc, and that you'll either have the requisite skills to make one yourself, or have a tame geek standing by who can.
Unless we can find a way to abstract the whole architecture (so it's fooled into running in a virtual machine which can report whatever hardware it likes), moving the problem back into software, unauthorised viewing or copyrighted content will become just another low-key cottage industry, like illicit cable boxes.
End-run.
And not enough bloody light, at that.
Hmmm.
...
Thanks a lot you shit-brained, fuck-faced, ball breaking, duck fucking pain in the ass.
See you in a minute.
"IMHO web devellopement is a very specific kind of devellopement. And while respecting standard is important, pragmatism is far more important."
It depends - pragmatism in the sense of ignoring standards got us the fingernails-down-a-blackboard-experience that was web design for most of the late 90s/early 2000s, and often produces pages that look great on IE but don't work or look ugly on other browsers. Call this "code pragmatism".
Pragmatism in the sense of being prepared for your lovely graphical design to degrade right back to ASCII text (or using sematic markup so it can be mashed-up and re-presented by people or scripts) is pretty much what people mean by "standards-compliant coding". Call this "presentational pragmatism".
Generalising madly, the "non-standards" crowd mainly seem to be code pragmatics, whereas the "standards-are-all" crowd seem to be presentational pragmatists.
Being pragmatic doesn't mean anything in the context of the debate - it's what you're most pragmatic about that they disagree on.
"Choosing a target as specific as possible (e.g. Mozilla + IE) and define precise design practices is the only practical choice if you don't wanna end up in CHAOS."
Not even slightly. This sounds like another version of the "standards are bad because they restrict my design options" (which is false, if you know what you're doing) or "standards are bad because they're hard" arguments (which is false because many other people are fine, so it's clearly your failing not the standard's). You could say the same thing about compiling C++ code - you'd be much free-er to write complete gibberish if it didn't have to compile, but a C++ program that doesn't compile is useless.
Likewise (albeit to a lesser degree) non-standards-compliant code is less useful. It won't be semantic markup, so it isn't easy (sometimes even possible) to automatically aggregate it and customise how you access it. Presentation isn't separate from content or behaviour, so it's harder to manage sites or effect large-scale changes to a design. It's tightly tied to old, obsolete ways of doing things that don't degrade well, so when the technology changes (eg, if in five years' time mobile devices are the most popular way to access the web rather than PCs) you find you have to recode everything you've ever written or write it off and lose it forever.
"You need to be very very pragmatic..."
Which doesn't mean anything on its own, as I've demonstrated above.
"...and do everything as simply as possible."
Exactly - this I agree with wholeheartedly.
"Great revolutionnary designs, Design patterns for every problems, extreme modularity, and cutting the codes in many many very small practical functions may often end up being impractical with a web project and make it a hell of a job to be maintained."
Indeed, but those (with the exception of extreme modularity) are all more symptomatic of non-standards-compliant "tag-soup" code than clean, semantic markup, presentation mostly/entirely in CSS and well-coded javascript in a separate file.
Semantic markup is simpler to read than presentational markup - this is pretty much unarguable.
Extreme modularity is almost universally agreed to be a Good Thing - practically every advance or increase in power in computing seems to be a drive towards modularity - OOP, XML, Firefoxes "extensions" vs traditional plugins, DLLs vs duplicated code, interacting suites of tools vs bloated, monolithic applications, etc, etc, etc.
I'm not sure where you got the idea modularity's bad, but it's vastly simpler and vastly more powerful than spaghetti code, and I think you'll find it hard to find a single experienced programmer or developer who'd disagree. Bringing it back to web design, see the CSS Zen Garden for examples of the power of separating content from design.
"And overall, in any languages, co
That's very true - developer-lead sites tend to be ugly but functional, graphic designer-lead sites tend to be pretty, also tend to be badly-coded (or just don't work at all) on other browsers/OSs/days.
;-)
Personally (and maybe it's a developer-webmaster thing) I'd rather have a site which was ugly but functional/navigable than one which was pretty but very obviously broken. I've always thought the most important thing was to reach your audience with your message - too many designer-lead sites fail even to do this (or just frustrate users before they have time to absorb your message - I'm looking at you, Flash-only sites).
Regardless of how pretty they'd look if they worked, they still turn users off even faster than an ugly site if/when they don't.
Of course, I'm arguing stereotypes here, but I always design sites from a functionality/navigation angle first, then pretty it up once it's working.
As I've had to explain to wannabe-web designer Directors more times than I can count, "cut the wood and nail it together before you paint the table".
When I say standards-compliant code, I mean "validating where possible and not causing errors in other browsers" - there's nothing dangerous (IMO) about javascript code like:Ok, that code might actually cause errors (I haven't got any tested examples to hand to cut-and-paste from), but you get the idea - document.all (IIRC) isn't according to the W3C DOM, but since the script tries to do it the W3C way first (and the non-W3C bit is wrapped in a DOM-detection if statement), it's standards-compliant.
I always find that retrofitting the (standards-working) site to work with IE generally consists of a small number of additional if() statements (like above) in a few low-level functions (generally getters and setters), and some creative CSS hackery to sort out the presentation.
Flawed analogy. One person browsing the web doesn't inconvenience another in any way, unless they DoS the server (which was rather out of the scope of the discussion).
Writing a page in standards-compliant code doesn't inconvenience the IE browser at all, it just allows everyone to use it.
A better analogy would be making the entrance road extra-wide, in case anyone wanted to come down in a horse-buggy (or tank, or whatever). This doesn't inconvenience normal car drivers, and while it may take a tiny fraction more land (to accommodate the wider road), the first time someone comes driving through your drive-in in a tank and buys thousands of dollars-worth of burgers you otherwise wouldn't have sold, it's worth it.
Not to mention the fact that other architects will respect you more for producing such an accessible design, and you'll have that lovely warm glow of knowing you've done your bit to keep road-width-standards open and non-proprietary... (to stretch the metaphor to breaking-point).
Maybe you didn't read my post(s) carefully enough. Using standards-complient code doesn't mean you have to use every bit of markup, and that every element has to work perfectly in every browser. It means writing code that doesn't contravene the standards. IE, no proprietary HTML tags/CSS markup, every page validates, scripts don't cause errors in other browsers, etc, etc. It's not hard.
:hover CSS rules).
With absolutely standard HTML/CSS you can do about 95% of everything you'll ever need. For the other 5% there's CSS browser hacks or javascript workarounds (eg, onmouseover instead of
Javascript presents more of a problem (due to differing DOMs), but a simple bit of DOM sniffing (not browser-sniffing) and sensible code-design means that every browser should either (a) support the advanced behaviour or (b) fail silently but usably.
This is not a position held in ignorance - I've been developing for the web since about 1994, and since the advent of XHTML/semantic markup/CSS 2.x/javascript 1.x I've never had a problem doing anything in standards-compliant ways.
That includes converting a site from presentational tables-based HTML 4.? (they didn't even know themselves) produced in Frontpage to one hand-coded in XHTML Strict 1.0/CSS 2.1/Javascript 1.5. In the end (as requested) it was pixel-perfect in IE, and had some small (<10 pixel) margin differences in Firefox/Opera.
Again, and sorry to sound insulting, but if you think standards-compliance can't be done you're either disagreeing with my definition of standards-compliance or just not experienced enough at web development.
Yeah. I was going to perjoratively leave it at the other three, but then I remembered some of the piles of festering crap that have been uploaded to our web server in the past, while I knelt in the background crying and beating my head against the desk.
Seriously - what is it with managers who hire you to be "the expert" in something, then refuse to listen to your advice on scheduling?
Maybe, if vi had about four users ;-)
You've got a lot more flexibility in intranet development, but you're still voluntarily walking into vendor lock-in, even (as with Firefox) if the vendor vends for £0.
Stick to the standards, and all will be well. Even proprietary extensions from open-source apps aren't always perfectly safe - how would you feel if you'd invested in loads of Mozilla Suite-specific code, when Firefox came out? Or how about if (god forbid) Firefox dies on its arse, and the only options are Opera or (hackcoughspit) IE? You're voluntarily and short-sightedly stuffing yourself, for no real gain.
I really don't understand why people have a problem with sticking to standards. You can basically do anything you'll ever want or need to while still having validating code, but people persist in treating it like some kind of groupthink. Does anyone argue that C/C++ code doesn't have to compile? Or how about the ISO standards for C/C++ - pointless? Or are they the reason we still basically have one language each of C and C++, instead of hundreds of incompatible, balkanised rip-offs?
It depends on the country you're in. Groups in the UK (and I believe Australia) have successfully sued (or at least, settled out of court) over websites that were inaccessible to the disabled.
"Why is it that amongst web developers there is only considered to be 'one way to do things'."
My theory is that it's a combination of:
1. More complex up-front design considerations than many other development tasks - your code is written once, but should run perfectly (or degrade gracefully) on every browser for every operating system for every architecture it ever runs on. In the website design community we deal every day with headaches caused by bugged or incompatible-by-design APIs, sketchy standards support and incredibly customisable interfaces (what's the C/C++/Java equivalent of "disable stylesheets", eh?). When you find a technique that works perfectly/degrades well on all known implementations, you stick to it like glue, and disseminate the word so others don't have to rip their own hair out. CSS tricks are even more slavishly followed, because so many rely on precise, back-engineered quirks of different browsers' rendering algorithms.
2. A large segment of much less-educated community participants. A lot of web designers (even now) have come at it from a graphic design background, and fail to appreciate the complex requirements and difficulties inherent in javascript, XHTML, CSS and how they all interact. Solving a lot of common problems with one approach which can be copied by the less-knowledgeable is a big win when it stops people re-inventing the wheel (and making it square - Flash developers, I'm looking at you).
3. Look where pandering to IE/Netscape and coding to browser quirks got us in the 90s - sometimes it took longer to make a site work acceptably in all browsers than it did to design and implement the first complete version! Quite often these days you'll find the "one way to do it" is basically conforming to the standards, avoiding proprietary extensions and writing pages which validate. There's nothing wrong with it, it encourages browser-manufacturers to conform to the standards, it simplifies the job of the web designer/developer and it doesn't restrict creativity one jot.
"Standards compliance is a good guideline, but it is not law."
No, but it is the only thing that stops you unnecessarily spending twice as long on a job coding to browser quirks. And it does ensure that everyone will be able to at least see the information, even if it's not necessarily pretty (pretty is easy too, for a further small investment of time). And it does mean you can tell the difference between a skilled, professional webmaster and someone's kid nephew with a copy of Frontpage.
"Web developers only need to cater to those devices in which they expect their content to be viewed. I do not expect, nor do I desire for someone to use my company's web apps from a cellphone or PDA."
Then, with apologies, you fail to understand the fundamental nature of the web. The whole point of the web is that anyone should be able to access information (and web apps count as information), however they like.
"Not expecting" customers to use different browsers only shows that you're closed-minded or not very imaginative (especially for someone posting on Slashdot!). "I didn't expect it" is a pathetic justification when something doesn't work unnecessarily, and indicates a lack of professionalism in your execution.
"Not desiring" it (eg, coding to a specific browser as my company does - I don't) means you're effectively locking yourself and your customers into one company, and everyone knows vendor lockin is a pointless risk - even Microsoft's now paying lip-service to interoperability.
"Yet, people wear their xhtml compliant gif's like medals of honor."
Yes. They're proudly saying "Look - I'm a professional". Or "I care about doing things The Right Way". Or even "Fuck off browser-makers, unless you can make it work according to the standards". How are these a bad thing?
"Write your pages with compliance in mind, but never lose site of refining your apps and pages for your tar