I noticed that most form submits are handled with onclick javascript. In my humble opinion, this is a terrible choice. The result is that the site visitor can't just enter data into forms and press enter (for searches, logins etc.). He needs to grab the mouse to submit the form.
Don't you think a non-javascript method is a much better choice?
No because the searchs are more of a filter which needs to be built up depending on which fields have been clicked or not. Its hard to explain but suing standard forms to filter data is causes problems.
what you can do is set the javascript to submit when enter is pressed when the search field is selected.
what you can do is set the javascript to submit when enter is pressed when the search field is selected.
OpenCart®
Project Owner & Developer.
Hmm, but that's a developer point of view, without the user in mind. I'm not complaining. But I think it's really the center point of a website that's gonna be used by a wide/general audience of users (like a shop script). Ok it's 2009 already and websites are rather applications. But a simple search etc. is not so fancy. I tested the script with my sister and even she found that irritating. Even Gmail works without Javascript, not to forget about eBay or Amazon...
What I meant is that any site should degrade gracefully and work without Javascript.
It's fully your decision of course, I suck at PHP (only do UI development and xhtml/css at work) so I don't know if it's possible, but I really think it's a must for modern web dev.
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
Are you looking for more feature suggestions? I set up a few shops for different kind of businesses - using Magento (the horrors), Cubecart, Prestashop etc. I made a rather big list of feature ideas etc for a shop during the recent two years.
It's fully your decision of course, I suck at PHP (only do UI development and xhtml/css at work) so I don't know if it's possible, but I really think it's a must for modern web dev.
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
Are you looking for more feature suggestions? I set up a few shops for different kind of businesses - using Magento (the horrors), Cubecart, Prestashop etc. I made a rather big list of feature ideas etc for a shop during the recent two years.
Daniel,
To make the enter button work, you can do one of two simple thigns:
1) Add a listener on the field like so:
<input type="text" onKeyDown="if(event.keyCode==13){submitfunction();}">
2) Add a <form> tag around the input like the following:
<form onSubmit='submitfunction(); return false;'>
That makes it not refresh the pages because of the "return false" but instead simply runs the submitfunction()
It would make it a lot nicer to be able to use the enter key.
To make the enter button work, you can do one of two simple thigns:
1) Add a listener on the field like so:
<input type="text" onKeyDown="if(event.keyCode==13){submitfunction();}">
2) Add a <form> tag around the input like the following:
<form onSubmit='submitfunction(); return false;'>
That makes it not refresh the pages because of the "return false" but instead simply runs the submitfunction()
It would make it a lot nicer to be able to use the enter key.
I place my neck on the table and still say: Javascript should not be inline. It should be external and add behaviour. And there must be a fallback solution of course. That's a no brainer for modern web development. It would be acceptable in the backend, but not on the front end. Especially not on any E-Commerce site.
Daniel: is it even possible to make it work without Javascript? I would like to use Opencart for future carts that I set up. So I'm considering paying a PHP dev to make it work. I can't do myself because I'm a PHP noob.
Daniel: is it even possible to make it work without Javascript? I would like to use Opencart for future carts that I set up. So I'm considering paying a PHP dev to make it work. I can't do myself because I'm a PHP noob.
Hi nde,nde wrote:I place my neck on the table and still say: Javascript should not be inline. It should be external and add behaviour. And there must be a fallback solution of course. That's a no brainer for modern web development. It would be acceptable in the backend, but not on the front end. Especially not on any E-Commerce site.
Daniel: is it even possible to make it work without Javascript? I would like to use Opencart for future carts that I set up. So I'm considering paying a PHP dev to make it work. I can't do myself because I'm a PHP noob.
I don't mean to be rude but if you need to pay a web developer to do these alterations for you does that mean you don't know HTML and Javascript?
Every web 2.0 application uses JavaScript. I don't like Javascript, but its the only dynamic language available. Why do you think onclick, onfocus, onmousemove, etc.. are in HTML and defined in the W3C.
Daniel,
What I think he means is that the trend is toward unobtrusive javascript instead of inline. I am no javascript expert, but have been modifying current projects to use unobtrusive javascript based on some good examples I've found online. It certainly makes for a cleaner markup and is also more consistent with good programming practice of separating functionality from presentation.
What I think he means is that the trend is toward unobtrusive javascript instead of inline. I am no javascript expert, but have been modifying current projects to use unobtrusive javascript based on some good examples I've found online. It certainly makes for a cleaner markup and is also more consistent with good programming practice of separating functionality from presentation.
Hi Daniel,Daniel wrote:Hi nde,nde wrote:I place my neck on the table and still say: Javascript should not be inline. It should be external and add behaviour. And there must be a fallback solution of course. That's a no brainer for modern web development. It would be acceptable in the backend, but not on the front end. Especially not on any E-Commerce site.
Daniel: is it even possible to make it work without Javascript? I would like to use Opencart for future carts that I set up. So I'm considering paying a PHP dev to make it work. I can't do myself because I'm a PHP noob.
I don't mean to be rude but if you need to pay a web developer to do these alterations for you does that mean you don't know HTML and Javascript?
Every web 2.0 application uses JavaScript. I don't like Javascript, but its the only dynamic language available. Why do you think onclick, onfocus, onmousemove, etc.. are in HTML and defined in the W3C.
yes many web apps use Javascript, but most of them fall back nicely and work without Javascript too. Like I wrote above, even Gmail works without Javascript.
The thing is that there are people coming to a shop with a browser where Javascript just won't work. They are in the total minority, but in my eyes they can't be ignored.
Sure there are JS events defined in the W3C spec, but using them on sites targeted for end users is considered bad practice among people who build web sites. I would say this is similar to how PHP devs look at Register Globals or sticking to PHP5 now and things like that.
When I said I'm considering to pay a developer, I meant that I couldn't do these changes to the script myself. I am very firm in XHTML/CSS and making user interfaces, but not PHP.
Fyi: the current front end for the cart is broken in IE 6 and below (25% - 35% of users according to various stats). Maybe that's because you use a xml declaration which causes IE to render the site in quirks mode.
I'm making a new template which works in IE 5.0 and major browsers on Linux and Mac OS too.
Just in case it may be of help to anyone else, a customer insisted that he just had a plain quick search box that would submit on pressing enter (NO button wanted!) I've used this in template->common->search.tpl but it might be improved upon:
Code: Select all
<div>
<?php if ($keyword) { ?>
<input type="text" name="keyword" value="<?php echo $keyword; ?>" id="filter_keyword" onclick="this.value = ''" onChange="getsearch();"/>
<?php } else { ?>
<input type="text" name="keyword" value="<?php echo $text_keywords; ?>" id="filter_keyword" onclick="this.value = ''" onChange="getsearch();" onblur="if(this.value=='') this.value='<?php echo $text_keywords; ?>';" onfocus="if(this.value=='<?php echo $text_keywords; ?>') this.value='';"/>
<?php } ?>
</div>
<script type="text/javascript"><!--
function getsearch() {
url = 'index.php?route=product/search';
var keyword = $('#filter_keyword').attr('value');
if (keyword) {
url += '&keyword=' + encodeURIComponent(keyword);
}
location = url;
}
//--></script>Oh well on one hand people campaign against IE6 which may be used by a good number of users and on the other hand people worry about a small number who don't have JS in their browser – so just make a decision for yourselves who your audience is and use IE fixes and NoScript Tags to please most or all of them, I'd say.
Not much of a PHP/Ajax person myself, but doing ok… I'd say best practice is to develop the application based on Forms using POST without any JS and then apply your jQuery etc. to make it nice and hip, as well as functional. I'd say this is what nde wants someone to do for him… myself, codecreator and Qphoria agree on would be a nice thing for future releases.
I'm rather into Html/CSS/Usability and have some issues with OC regarding this — so maybe there'd be away to work all together on this?
Cheers
Not much of a PHP/Ajax person myself, but doing ok… I'd say best practice is to develop the application based on Forms using POST without any JS and then apply your jQuery etc. to make it nice and hip, as well as functional. I'd say this is what nde wants someone to do for him… myself, codecreator and Qphoria agree on would be a nice thing for future releases.
I'm rather into Html/CSS/Usability and have some issues with OC regarding this — so maybe there'd be away to work all together on this?
Cheers
Well the design here is that the buttons are all using 1 background image with actual text as a link... and just stretching across the span. As opposed to using actual images, which would mean 1 image for each button.SiteE@se wrote: Really? Surely you can use a fancy button, styled with css if it is placed within it's own fieldset in a traditional form?
It is a shame HTML never created an input type="link" or something that allowed this natively. All input types should be allowed to be a "submit" button imo. Then things like like submit on select and radio change would also be native
Entirely possible with the form/fieldset/css solution ... use the 'sliding doors' technique of CSS, plus two sliced background images with "on" and "off" states, to create flexible shaped CSS buttons. Each button can accommodate text of variable widths.Qphoria wrote: Well the design here is that the buttons are all using 1 background image with actual text as a link... and just stretching across the span. As opposed to using actual images, which would mean 1 image for each button.
Chris
I assume you are talking about something like the example towards the bottom of this link:SiteE@se wrote:Entirely possible with the form/fieldset/css solution ... use the 'sliding doors' technique of CSS, plus two sliced background images with "on" and "off" states, to create flexible shaped CSS buttons. Each button can accommodate text of variable widths.Qphoria wrote: Well the design here is that the buttons are all using 1 background image with actual text as a link... and just stretching across the span. As opposed to using actual images, which would mean 1 image for each button.
Chris
http://cssbutton.com/forms/
It's ugly to use that much code tho... maybe feasible. but eh. Tho I see his "submit" button image isn't stretching well.
I actually created a jscript that
- finds all input type="button"
- gets the "value"
- replaces the button with a text link, using the value for the link
- and styles the button
This way when javascript is enabled, you see the pretty button
When jscript is off, you see the standard gray button.
A bit overkill i guess.
There are also examples at http://www.dynamicdrive.com/style/cssli ... tegory/C7/ with well-commented (although slightly bulky) code.Qphoria wrote: I assume you are talking about something like the example towards the bottom of this link:
http://cssbutton.com/forms/
It's ugly to use that much code tho... maybe feasible. but eh. Tho I see his "submit" button image isn't stretching well.
With jscript the code still has to be rendered on the client side - There's probably only milliseconds in it but I'm not sure which solution css or javascript is actually the most efficient. Assuming the css is in a separate file it will be cached (as would jscript). However, not all javascript used in OC 1.2.6 (AFAIK) is stored in external files and some therefore isn't cached, which must slow things a little?Qphoria wrote: I actually created a jscript that
- finds all input type="button"
- gets the "value"
- replaces the button with a text link, using the value for the link
- and styles the button
This way when javascript is enabled, you see the pretty button
When jscript is off, you see the standard gray button.
A bit overkill i guess.
Who is online
Users browsing this forum: No registered users and 4 guests
