Wtf about TheDailyWTF
-
From the requirements standpoint, the method you propose would look like "if (hasDhtml) then displayDhtmlMenu() else displayHtmlMenu()".
It's more than testing once, but certainly not twice. Maybe 1.25 times the testing.I think that from a technical standpoint, you could let the browser use that logic through NOSCRIPT and whatnot, but from what I can see it still requires twice the development and twice the testing. I see this same logic applying throughout a site.
And if you're truly serious about professional webdevelopment, you don't make the choice to omit that 25%. You just do it. It's part of the job.
When people think the web is fast, they confuse using for building. [i]Building[/i] the web is just as slow or fast as any other kind of development.
It takes a lot of effort to make things efforless. :)
-
-
@ammoQ said:
@felix said:
Shameless plug:
http://shadow-v.home.ro/computer/dhtml.html
Great! Really!
Why, thank you.
-
@felix said:
I've read the HTML 4.01 recommendation end-to-end and I liked it a lot
HTML is fundamentally flawed for how its used today. The 4.01 standard is probably as good as they can get -- but it's still a poor platform to do "good design" with -- and this is how the majority of businesses communicate their messages, via "good design."
@felix said:
38 lines of CSS, 50 lines of Javascript, works out-of-the-box in IE6, Ff, Opera and Konqueror... Shameless plug: http://shadow-v.home.ro/computer/dhtml.html
Looks neat (although, slightly broken on IE6 as the attachment shows), but I doubt this technique could be applied to the level of detail that a graphic designer would require -- it has been my personal experience that using anything but tables and spacer images don't work. The last time I worked with HTML/CSS, I desperately tried to be "good" and use only DIVs/CSS, but for the design I was working with, it just wasn't happening.
-
@Alex Papadimoulis said:
it has been my personal experience that using anything but tables and spacer images don't work. The last time I worked with HTML/CSS, I desperately tried to be "good" and use only DIVs/CSS, but for the design I was working with, it just wasn't happening.
Then you need more experience. :)
-
@dhromed said:
Then you need more experience. :)
There is no doubt about that -- rarely will I start with a PSD file, usually a production guy (or the designer) will produce the HTML. However, despite having a CSS book (one to show you how to transition from tables to CSS), I couldn't get it to work -- there were like 2px differences between the IE and FF version that just would not go away. After several hours, I went to tables, which took about half an hour to do.
-
@Alex Papadimoulis said:
@felix said:
38 lines of CSS, 50 lines of Javascript, works out-of-the-box in IE6, Ff, Opera and Konqueror... Shameless plug: http://shadow-v.home.ro/computer/dhtml.html
Looks neat (although, slightly broken on IE6 as the attachment shows),
Odd, I thought I fixed that issue... Oh well, a <br/> should do the trick.
@Alex Papadimoulis said:
However, despite having a CSS book (one to show you how to transition from tables to CSS), I couldn't get it to work -- there were like 2px differences between the IE and FF version that just would not go away.
You see, that's the problem with "modern" web design. This crazy idea that a Web page should look the same on every computer down to pixel level. I could go on and on with reasons why it's wrong but, honestly, I'm out of words. See "The Essence of the Web" on Web Matters (http://www.xs4all.nl/~sbpoley/webmatters/essence.html). It explains things better than I can.
-
@felix said:
You see, that's the problem with "modern" web design. This crazy idea that a Web page should look the same on every computer down to pixel level. I could go on and on with reasons why it's wrong but, honestly, I'm out of words. See "The Essence of the Web" on Web Matters (http://www.xs4all.nl/~sbpoley/webmatters/essence.html). It explains things better than I can.
I don't think a web page can or should look the same on every computer, but in some cases, those 2 pixels simply break the design. Just imagine a border with rounded corners where the corners are displaced by 2 pixels (relative to the edges). Ugly.
-
In my experience CSS can really be a pain in the ass, if you want to achieve the same result with a normal browser and IE. Out of nowhere you'll have an invisible 1px border somewhere, although you set everything to 0px etc, etc. I (not being a professional) usually end up using a table() in the end, which hurts even more if you know that you already had a css-version that worked in all browsers except IE.
()I could of course also use some of those hacks floating through the web, where you add some nonsense into a .css file and only the IE reads the crap that comes after it or something like that..
-
@felix said:
You see, that's the problem with "modern" web design. This crazy idea that a Web page should look the same on every computer down to pixel level. I could go on and on with reasons why it's wrong but, honestly, I'm out of words. See "The Essence of the Web" on Web Matters (http://www.xs4all.nl/~sbpoley/webmatters/essence.html). It explains things better than I can.
Interesting article. I've read through it and I believe that I understand the message. It seems best summarized with the the following priorities:
- Content (HTML, and sometimes also audio, video etc)
- Presentation (typically CSS)
- Decoration (typically Javascript, Java, Flash etc)
However, this heirarchy goes against very nature of the science/art of visual communication: a message is only as important as how it's presented and percieved. This is a fact that accessibility proponents (including the author) don't quite understand. Everything from the typeface to the kerning to the color are all essential parts of the communication and without those the message changes and is not what is desired to be conveyed.
The statement "if a browser is unable to view the decoration, there is no need to prevent it from viewing the content" is probably true for only purely-information sites, such as a news database and a message board. But for most other professional sites ("brochure sites"), it's definitely not the case.
-
And you've cut to the very heart of why the web sucks so much. HTML was *never* written to be a presentation/decoration layer, it was for simple formatting and hyperlinking only. Scientific stuff and papers and such. Content.
Everything that has tried to add presentation and/or decoration to the web has been a convoluted hack written on top of a layer that was never designed to handle it. Look at web2.0 stuff. It's all hacks. Javascript that calls activeX that calls webservices then wraps it all into "neat" HTML/CSS and/or flash.
What you describe *is* a Good Thing (tm). Presentation and Decoration should be available and the content *is* reflected by the way it's decorated and organized, but HTML and its grandson XHTML shouldn't be the way to do it. What we need is an entierly *new* way to browse the web, one that scraps HTML entirely and begins from the ground up with an eye for presentation, content, and user interaction, with each concern separated but integrated.
-
This is a really good way of expressing exactly what I've been trying to say. Well put.
-
@Alex Papadimoulis said:
Everything from the typeface to the kerning to the color are all essential parts of the communication and without those the message changes and is not what is desired to be conveyed.
You mean, like in those commercials that say "call this number to win... bla bla", where the (outrageous) toll is written in teeny tiny letters at the very bottom of the screen? :D
But, really, I have a minimum font size set in the browser, as I like to keep my distance from the monitor. Guess what, a lot of layouts are broken for me because they assume I can see 10-pixel fonts. Doesn't that "change the message"? On the other hand, Yahoo looks good no matter how I set my browser, even if I disable image loading (I did that too, for a while).
@Alex Papadimoulis said:
The statement "if a browser is unable to view the decoration, there is no need to prevent it from viewing the content" is probably true for only purely-information sites, such as a news database and a message board. But for most other professional sites ("brochure sites"), it's definitely not the case.
How about an online shop? If I can't read the price/see a picture, I will most certainly not buy. If for some reason I surf with Javascript disabled and the checkout button requires it, I won't turn it on... thus I won't buy.
-
@TDC said:
In my experience CSS can really be a pain in the ass, if you want to achieve the same result with a normal browser and IE. Out of nowhere you'll have an invisible 1px border somewhere, although you set everything to 0px etc, etc. I (not being a professional) usually end up using a table() in the end, which hurts even more if you know that you already had a css-version that worked in all browsers except IE.
()I could of course also use some of those hacks floating through the web, where you add some nonsense into a .css file and only the IE reads the crap that comes after it or something like that..
You need more experience, too. ;) ;) ;)
I fully agree that the web as we know it is a heap of several incomplete languages trying to work together.
Keeping them all as clean a possible helps. A lot.
I've never had pixel-precision inconsistencies between browsers in critical places.
There was this one site I managed to get indistinguishable in IE6, FFX, Opera 7.5, Safari AND ie:mac 5.5
Skillz, baby.
flexes css muscle
-
@dhromed said:
@Alex Papadimoulis said:
it has been my personal experience that using anything but tables and spacer images don't work. The last time I worked with HTML/CSS, I desperately tried to be "good" and use only DIVs/CSS, but for the design I was working with, it just wasn't happening.
Then you need more experience. :)Not really no, he's right on the fact that you can't achieve pixel-perfection using CSS (unless you're using fully specified absolute positioning and sizing).
The point is that even tables or absolute positioning only works on an artificially restricted set of browsers, a restricted set of resolutions and a restricted set of OS, and that more fluid designs work much better on the web. The web is not print, god damn it.
@felix said:You see, that's the problem with "modern" web design. This crazy idea that a Web page should look the same on every computer down to pixel level. I could go on and on with reasons why it's wrong but, honestly, I'm out of words. See "The Essence of the Web" on Web Matters (http://www.xs4all.nl/~sbpoley/webmatters/essence.html). It explains things better than I can.
There is nothing modern in this, it's remnants from print and print-based designers (and professors).
It's nowhere "modern" web design, quite the opposite in fact since that's the kind of reasons why table-based designs were created in the first place.
-
@masklinn said:
@dhromed said:
@Alex Papadimoulis said:
it has been my personal experience that using anything but tables and spacer images don't work. The last time I worked with HTML/CSS, I desperately tried to be "good" and use only DIVs/CSS, but for the design I was working with, it just wasn't happening.
Then you need more experience. :)Not really no, he's right on the fact that you can't achieve pixel-perfection using CSS (unless you're using fully specified absolute positioning and sizing).
The point is that even tables or absolute positioning only works on an artificially restricted set of browsers, a restricted set of resolutions and a restricted set of OS, and that more fluid designs work much better on the web. The web is not print, god damn it.
Tru, dat.
What that doesn't mean though, is that, as one is generally unable to make stuff look pixel-perfect everywhere, one should throw away the concept of a clean web design and implement in some fugly hack. Particularly if that fugly hack involves using javascript to submit forms because it's easier to style a link than a button.
Simon
-
@tufty said:
As an example, your current demo site [b]won't let me log in[/b] without javascript enabled due to its fuck-awful javascript-reliant login form (with no fallback) that [i]does nothing to improve usability or security[/i].
Minor correction - it's not just a login form - it's also a Search form as well. You see, instead of having a separate form for each thing, they made the entire page into one giant form and used a hidden field (filled in by the JavaScript that submits the form) to inform the server whether the user is logging in or searching. Slightly unusual...
Incidentally, this might explain why, even if I can persuade the non-JavaScript-enabled browser Lynx to submit the login form, nothing actually happens. It definitely explains why they have to intercept someone hitting Enter in a form field and call the JavaScript code to submit the form, instead of letting nature take its course (so to speak).
-
@makomk said:
instead of having a separate form for each thing, they made the entire page into one giant form and used a hidden field.
This isn't Telligent's doing -- but the ASP.NET model. ASP.NET tries to make web programming as painless as possible so that you don't ever need to dig into the HTML code. The goal is so that you don't have to work at the "Html level" or worry about how the web works -- just plop a few buttons down, assign server-side events to them, and now you have a quickly built web application. This has the unfortunate side effect of making the product and resulting HTML code very painful.
Relating to the previous conversation bits, this is just piling another "hack" on top of the already hacked-up platform known as the web. I should note that this is not the required way of doing ASP.NET, but it's by far the easiest and the recommended. When I develop in ASP.NET, I avoid this method as much as possible (I go the old fasion way and use things like the querystring to pass data between pages).
-
@Alex Papadimoulis said:
@makomk said:
instead of having a separate form for each thing, they made the entire page into one giant form and used a hidden field.
This isn't Telligent's doing -- but the ASP.NET model. ASP.NET tries to make web programming as painless as possible so that you don't ever need to dig into the HTML code. The goal is so that you don't have to work at the "Html level" or worry about how the web works -- just plop a few buttons down, assign server-side events to them, and now you have a quickly built web application. This has the unfortunate side effect of making the product and resulting HTML code very painful.
Relating to the previous conversation bits, this is just piling another "hack" on top of the already hacked-up platform known as the web. I should note that this is not the required way of doing ASP.NET, but it's by far the easiest and the recommended. When I develop in ASP.NET, I avoid this method as much as possible (I go the old fasion way and use things like the querystring to pass data between pages).
To be honest, I suspected that might've been the case (having heard a bit about ASP myself). This also has the very large downside that there's no way in Hell it'll all work properly without JavaScript. (Imagine someone hits Enter in one of the entry boxes to submit the form; the action should depend on which one they hit Enter in, but that isn't sent to the server IIRC. You might be able to get submit buttons working properly, if you were clever about it - but there aren't any submit buttons on this page anywhere!)
In fact, if you hit Enter in one of the form fields with JavaScript disabled, it seems to feed you back the page you submitted, complete with all the form fields filled out as they were when you did it (minus any passwords). I presume that's ASP.NET's doing too?
-
@Alex Papadimoulis said:
You should like the new version. Looks promising: take a look at what comes out of the box:
If you're using a browser that doesn't support the rich editor, you can now use HTML, but you can't put < symbols in, since entities don't work in this mode. Also, in this mode a newline is a <br>, but it isn't in the HTML view of the rich editor. So if you quote someone who didn't have access to the rich editor, and you're using the rich editor to do it (or vice-versa), the quoted text gets horribly mangled. I suspect the same applies when editing existing posts...
Oh, and if you make a post using the text-box-based fallback entry form, then edit it using the same, any entities you might've typed seem to be converted to the literal character in the raw text displayed in the edit box (if you originally put <lt; you get < in the edit box, which is then treated as a tag opening if you submit it that way).
-
@Alex Papadimoulis said:
ASP.NET tries to make web programming as painless as possible so that you don't ever need to dig into the HTML code. The goal is so that you don't have to work at the "Html level" or worry about how the web works -- just plop a few buttons down, assign server-side events to them, and now you have a quickly built web application. This has the unfortunate side effect of making the product and resulting HTML code very painful.
Amazing... ASP.NET is officially promoting incompetence. I can't believe you're actually defending that piece of c**p!
@Alex Papadimoulis said:
Relating to the previous conversation bits, this is just piling another "hack" on top of the already hacked-up platform known as the web.
The only hacked-up platform here is ASP...
-
@felix said:
@Alex Papadimoulis said:
ASP.NET tries to make web programming as painless as possible so that you don't ever need to dig into the HTML code. The goal is so that you don't have to work at the "Html level" or worry about how the web works -- just plop a few buttons down, assign server-side events to them, and now you have a quickly built web application. This has the unfortunate side effect of making the product and resulting HTML code very painful.
Amazing... ASP.NET is officially promoting incompetence. I can't believe you're actually defending that piece of c**p!
If they (MS) do it right (can't say, I'm not in the MS world), there is a real advantage in doing it that way: Abstraction.
For an example how not to do it, look at JSF. They hide everything in controls that could be rendered in one way or another, but the container for whole stuff is still a JSP page which contains HTML-specific tags. Because of that, there is no clean way to make the same application render, say, XUL, without changing the JSP page or doing some nasty hacks that catch and replace those HTML tags. This is disappointing, since the whole JSF frameworks seems prepared for that kind of frontend-independence. For an application with a life cycle of seven or more years, it can be a major drawback if it is hardcoded to have an HTML frontend. The kind of frontend-independence I'm thinking of obviously requires some restrictions on what can be done, so it might not have the most fancy Web2.0 design one can imagine. But, with the right level of abstraction, even that is possible. Just have an abstraction for "tree view" and let the renderer make it a simple list of links or a stylish DOM+Javascript+CSS thingy, depending on the possibilities.
-
@felix said:
Amazing... ASP.NET is officially promoting incompetence. I can't believe you're actually defending that piece of c**p!
That's not the case -- what they've done is shifted the way web apps are built. The application now "understands" what the INPUT and SELECT elements are, where as before all you were able to do was read the POST or GET data and output HTML. For example, if you place a DropDownList control (renders to a select box) on your aspx page, your code can do this:
myDropDownList.DataSource = usStatesDataTable;
myDropDownList.DataTextField = "State_Name";
myDropDownList.DataValueField = "State_Abbrev";
myDropDownList.DataBind();... when page is posted back ...
myTextBox.Text = "You selected " + myDropDownList.SelectedText + " as your state."
To do that on a "traditional" platform of "input -> process -> output", that'd require a heck of a lot more code that adds cluttler to the business logic of "have a textbox that lists the US states".
Of course, ASP.NET does a heck of a lot more than just that -- and what you see as "bad" (and not that I disagree with that assessement) is IMO worth the benefit provided by the platform. I always recommend that developers take a bit more time to minimize the "bad" stuff -- like that stupid javascript pager that switches you from one set of messages to another.
Speaking of that -- from a framework perspective, there's a perfectly rational reason for that. The message list is stored in a DataGrid control -- which you can have as many as you'd like. If you were to design such a control, there'd be no other way than to use Javascript to have a pager. It's the implementor's job to override the Javascript pager and use a querystring -- Telligent didn't do that b/c it seems to work fine without it and it'd a bit of an effort.
-
@Alex Papadimoulis said:
That's not the case -- what they've done is shifted the way web apps are built. [..] before all you were able to do was read the POST or GET data and output HTML.
And now you do the same, except you no longer have any control.
@Alex Papadimoulis said:
It's the implementor's job to override the Javascript pager and use a querystring
Ok, so you can wrestle back control, with a lot more effort than it's worth, so nobody's actually doing it. Great!
@Alex Papadimoulis said:
For example, if you place a DropDownList control (renders to a select box) on your aspx page, your code can do this:
myDropDownList.DataSource = usStatesDataTable;
myDropDownList.DataTextField = "State_Name";
myDropDownList.DataValueField = "State_Abbrev";
myDropDownList.DataBind();... when page is posted back ...
myTextBox.Text = "You selected " + myDropDownList.SelectedText + " as your state."
To do that on a "traditional" platform of "input -> process -> output", that'd require a heck of a lot more code that adds cluttler to the business logic of "have a textbox that lists the US states".
<select name="states">{html_options options=usStatesAray}</select>
in the HTML template. and a 3-line loop to set up the associative array in PHP (once I have the data). Actually, I use a helper function, so it's only one line...
@ammoQ said:For an example how not to do it, look at JSF.
And for an example of how to do it right, look at PHP+Smarty. You get MVC, or at least MV, out-of the-box and you maintain full control. But then, PHP is not "enterprise". It's not backed up by a big company, right? That's way more important than ease of use, clean output and everything else, isn't it?
Sorry for the rant. But I can't help it when people with lots of common sense won't even consider an alternate solution just because... because what? You tell me...
-
@felix said:
Oops, the Smarty code should have been:
<select name="states">{html_options options=$usStatesArray}</select>
-
@makomk said:
@tufty said:
As an example, your current demo site [b]won't let me log in[/b] without javascript enabled due to its fuck-awful javascript-reliant login form (with no fallback) that [i]does nothing to improve usability or security[/i].
Minor correction - it's not just a login form - it's also a Search form as well. You see, instead of having a separate form for each thing, they made the entire page into one giant form and used a hidden field (filled in by the JavaScript that submits the form) to inform the server whether the user is logging in or searching. Slightly unusual...
Yeah. An 'interesting' design. Still, even that doesn't need javascript to work. Consider the following:
<font style="font-family: Courier New;" size="2"><form action="do_everything">
<input type="text" id="search" />
<input type="submit" id="search_button" value="Search" />
...
<input type="text" id="login" />
<input type="password" id="password" />
<input type="submit" id="login_button" value="Login" />
</form>
</font>
Which will submit everything to the url do_everything, which can then decide what it's supposed to do depending on what button was clicked. One might then use javascript to enhance the interface, but the basic structure would work with any browser. One might argue that this is a fucked up design, but it's a workable fucked up design should you want to go that way.
Simon
-
@tufty said:
@makomk said:
@tufty said:
As an example, your current demo site [b]won't let me log in[/b] without javascript enabled due to its fuck-awful javascript-reliant login form (with no fallback) that [i]does nothing to improve usability or security[/i].
Minor correction - it's not just a login form - it's also a Search form as well. You see, instead of having a separate form for each thing, they made the entire page into one giant form and used a hidden field (filled in by the JavaScript that submits the form) to inform the server whether the user is logging in or searching. Slightly unusual...
Yeah. An 'interesting' design. Still, even that doesn't need javascript to work. Consider the following:
<font style="font-family: Courier New;" size="2"><form action="do_everything">
<input type="text" id="search" />
<input type="submit" id="search_button" value="Search" />
...
<input type="text" id="login" />
<input type="password" id="password" />
<input type="submit" id="login_button" value="Login" />
</form>
</font>
Which will submit everything to the url do_everything, which can then decide what it's supposed to do depending on what button was clicked. One might then use javascript to enhance the interface, but the basic structure would work with any browser. One might argue that this is a fucked up design, but it's a workable fucked up design should you want to go that way.
SimonWhat if the user didn't hit any of the submit buttons to submit the form?
@makomk said:
This also has the very large downside that there's no way in Hell it'll all work properly without JavaScript. (Imagine someone hits Enter in one of the entry boxes to submit the form; the action should depend on which one they hit Enter in, but that isn't sent to the server IIRC. You might be able to get submit buttons working properly, if you were clever about it - but there aren't any submit buttons on this page anywhere!)
In fact, if you hit Enter in one of the form fields with JavaScript disabled, it seems to feed you back the page you submitted, complete with all the form fields filled out as they were when you did it (minus any passwords). I presume that's ASP.NET's doing too?
-
@felix said:
[SELECT name=states]{html_options options=usStatesAray}[/SELECT]
I did the same thing with Perl (waaaay back when) and ASP (much more recently), and yes, it makes it easier. But being able to access the "DOM" from server-side script is far superior. You can change every attribute, from MAXLENGTH to DISABLED directly in your server side script without having to worry about variables, helper functions, or anything like that.
Everything in HTML is exposed this way -- from TABLES to UL, and makes it a much easier way to do common tasks, such as displaying a list of items (used to require a FOR loop, now can be done with a DataBind) to showing/hiding a DIV (used to require a large IF block)
-
@Alex Papadimoulis said:
@felix said:
[SELECT name=states]{html_options options=usStatesAray}[/SELECT]
I did the same thing with Perl (waaaay back when) and ASP (much more recently), and yes, it makes it easier. But being able to access the "DOM" from server-side script is far superior. You can change every attribute, from MAXLENGTH to DISABLED directly in your server side script without having to worry about variables, helper functions, or anything like that.
Everything in HTML is exposed this way -- from TABLES to UL, and makes it a much easier way to do common tasks, such as displaying a list of items (used to require a FOR loop, now can be done with a DataBind) to showing/hiding a DIV (used to require a large IF block)
Interesting. I'm currently working on a web project, and right now I am making a JSP page that includes a SELECT list to be filled from the database. The current code to fill the select list looks like that:Something: <select name="somethingid">
<% { org.hibernate.Session s = whatever.getSession();
List somethingList = SomeClass.getSomethingList(s);
if (somethingList != null) {
Iterator iter = somethingList.iterator();
while (iter.hasNext()) {
SomeThing something = (SomeThing) iter.next();
out.println("<option value=\""+something.getId()+"\" "+(somethingid==something.getId().longValue()?"selected":"")+">"+something.getName()+"</option>");
}
}
whatever.closeSession();
}
%>
</select>I'm not very satisfied with this Java-HTML-mix, but don't know how to make it better. Of course I can shift to problem into some helper class to hide it there, but that doesn't make it better IMO. How would it look like with DOM? I guess it need JavaScript to work...?
-
@ammoQ said:
Interesting. I'm currently working on a web project, and right now I am making a JSP page that includes a SELECT list to be filled from the database
...
I'm not very satisfied with this Java-HTML-mix, but don't know how to make it better. Of course I can shift to problem into some helper class to hide it there, but that doesn't make it better IMO. How would it look like with DOM? I guess it need JavaScript to work...?
Interesting -- I thought Java was control based, the code you showed looked much more like how I'd do it in ASP (or any other language). As far as the DOM -- the reason it was enquoted is because it isn't the same DOM that's exposed to Javascript. The only elements the server "sees" are ones where you add a "runat=server" attribute to. The rest are just written out to the response stream as per normal. But to translate your JSP snipped to ASP.NET ...
... in the whatever.aspx file (not even going to try LT/GT tags ...
{asp:DropDownList id=somethingid runat="server" /}
... and in the code behind (generally whatever.aspx.cs) ...
org.hibernate.Session s = whatever.getSession();
List somethingList = SomeClass.getSomethingList(s);somethingid.DataSource = somethingList;
somethingid.DataValueField = "Id";
somethingid.DataTextField = "Name";
somethingid.DataBind(); //could also be done at the page level, which cascades to all controls on the page
somethingid.SelectedValue = somethingid;also, depending on your preference, you could just as easily define the properties in the ASPX page ...
{asp:DropDownList id=somethingid runat="server" DataValueField="Id" DataTextField="Text" /}
-
@Alex Papadimoulis said:
Interesting -- I thought Java was control based, the code you showed looked much more like how I'd do it in ASP (or any other language).
What you mean is JSF (JavaServerFaces), JSP, in general, is just like ASP (more-or-less). And, guess what, a JSF page is a JSP page (that uses tags from the JSF tag library).
-
Or alternativly let the forum track what you've read? and when you're done mark the forum as read for the posts you wern't interested in. It has the watch function (notify) so the only function it really misses is an ignore flag for threads you arn't interested in so they don't show up as unread. Although I personaly prefer my news reader to sort by the date of the last post to the thread (except watched threads that have unread posts, these should always be displayed at the top, unfortunatly I havn't found a newsreader that does this).
-
@Alex Papadimoulis said:
@masklinn said:
There is only one deliverable that does all the shades of techs from cavemen browsing with Telnet:80 to hip kids using Safari or Camino under OSX
Perhaps we're not using the same definition for deliverable: I'm refering to an atomic piece of functionality (single functional requirement). The code "if (x) then a() else b()" would contain two functional requirements a() and b().
Let's consider the simple requirement of a navigation bar. Often times such a feature calls for pull-down menus -- something which can only be done (AFAIK) using DHTML / Flash / Applet. From the requirements standpoint, the method you propose would look like "if (hasDhtml) then displayDhtmlMenu() else displayHtmlMenu()".
I think that from a technical standpoint, you could let the browser use that logic through NOSCRIPT and whatnot, but from what I can see it still requires twice the development and twice the testing. I see this same logic applying throughout a site.
Missed that one last time, so I'll answer it now (even though others already have): no it wouldn't god damn it, that's the point of Progressive Enhancement. Here the requirements would look like "displayFixedMenu; if(hasJS) transformToPulldown", I'm not building two menus I'm building one and then applying a generic "pulldown" behavior to it.
And was it not for MSIE you wouldn't even need JS to create a pulldown menu.
Pulldowns still suck though.
@makomk said:What if the user didn't hit any of the submit buttons to submit the form?
As in he felt so l33t that he oppened a javascript console and did a
document.getElementsByTagName("FORM")[0].submit()? Duh, sorry, that's not even stupidity that's malignity, fuck him.
-
@masklinn said:
@makomk said:
What if the user didn't hit any of the submit buttons to submit the form?
As in he felt so l33t that he oppened a javascript console and did a
document.getElementsByTagName("FORM")[0].submit()? Duh, sorry, that's not even stupidity that's malignity, fuck him.No, as in he hit Enter in one of the form fields to submit it, thereby saving himself the hassle of figuring out whether there was a submit button (not all forms have one), and if so either tabbing across to it or lifting a hand off the keyboard and clicking it...
-
@makomk said:
@masklinn said:
@makomk said:
What if the user didn't hit any of the submit buttons to submit the form?
As in he felt so l33t that he oppened a javascript console and did a
document.getElementsByTagName("FORM")[0].submit()? Duh, sorry, that's not even stupidity that's malignity, fuck him.No, as in he hit Enter in one of the form fields to submit it, thereby saving himself the hassle of figuring out whether there was a submit button (not all forms have one), and if so either tabbing across to it or lifting a hand off the keyboard and clicking it...
If he was using Opera or Firefox then the browser automatically used/validated the first submit button of the form; if he used MSIE he's out of luck.
