File input problem
Mark Smith
some forms.
CSS support is almost not existent for file inputs on all the major
browsers.
So I decided to hide the ugly standard file input control and wrap
some javascript around some styleable buttons and input text boxes to
drive the actual file input.
This works in IE6, IE7 and Safari but unfortunately not Firefox.
Code to replicate:
<form method="post" enctype="multipart/form-data" action="filetest/
upload">
<input type="file" name="file" id="file" value="" />
<input type="button" value="Browse for file"
onclick="document.getElementById('file').click();"/>
</form>
This is an almost 10 year old bug that is still open:
https://bugzilla.mozilla.org/show_bug.cgi?id=36619
After a bit of googling it looks like my options are:
#1 Use flash. (Not a desirable dependancy)
#2 Drop support for FF. (Can't do that)
#3 Use some hacky CSS and overlays to style the file picker:
http://www.quirksmode.org/dom/inputfile.html
#4 Do some browser detection, hide with JS if I can, FF users have to
live with the normal ugly ass control.
I'm leaning towards options 3 or 4 right now, unless anyone else has
better suggestions?
Thanks
David Mark
> I've been spending the last day trying to prettify the file inputs on
> some forms.
>
> CSS support is almost not existent for file inputs on all the major
> browsers.
>
> So I decided to hide the ugly standard file input control and wrap
> some javascript around some styleable buttons and input text boxes to
> drive the actual file input.
The "ugly" file buttons are what the users are used to. ;)
>
> This works in IE6, IE7 and Safari but unfortunately not Firefox.
That is too bad.
>
> Code to replicate:
> <form method="post" enctype="multipart/form-data" action="filetest/
> upload">
> <input type="file" name="file" id="file" value="" />
> <input type="button" value="Browse for file"
> onclick="document.getElementById('file').click();"/>
> </form>
>
> This is an almost 10 year old bug that is still open:https://bugzilla.mozilla.org/show_bug.cgi?id=36619
Read carefully. It is not a bug at all. There are security concerns
and there is no spec that says this behavior must exist in a browser.
So maybe they will change it, maybe they won't...
>
> After a bit of googling it looks like my options are:
>
> #1 Use flash. (Not a desirable dependancy)
Yeah, that would be suicidal unless you can find a viable Flash script
(good luck with that!) And, of course, even if it works it is still
Flash. :(
> #2 Drop support for FF. (Can't do that)
Clearly.
> #3 Use some hacky CSS and overlays to style the file picker:http://www.quirksmode.org/dom/inputfile.html
Please don't.
> #4 Do some browser detection, hide with JS if I can, FF users have to
> live with the normal ugly ass control.
That would be silly as FF may change the behavior in the future (and
it is non-trivial to detect a specific browser, let alone version).
>
> I'm leaning towards options 3 or 4 right now, unless anyone else has
> better suggestions?
>
Looks like #3 or nothing as the others are impossible, silly or Flash.
David Stone
<55537546-2fa4-4295...@p8g2000yqb.googlegroups.com>,
Mark Smith <marksm...@jungle-monkey.com> wrote:
> I've been spending the last day trying to prettify the file inputs on
> some forms.
>
> CSS support is almost not existent for file inputs on all the major
> browsers.
>
> So I decided to hide the ugly standard file input control and wrap
> some javascript around some styleable buttons and input text boxes to
> drive the actual file input.
>
> This works in IE6, IE7 and Safari but unfortunately not Firefox.
>
> Code to replicate:
> <form method="post" enctype="multipart/form-data" action="filetest/
> upload">
> <input type="file" name="file" id="file" value="" />
> <input type="button" value="Browse for file"
> onclick="document.getElementById('file').click();"/>
> </form>
What exactly is it about the above that you don't like? When
I click on the resulting "Browse..." button, I see exactly the
system file dialog I am used to seeing - and expect - complete
with all the features of that dialog that I have come to rely on.
(FF 3.5.5/OS X) Is it really your intention to override the file
dialog on the user's OS, or are you simply trying to change the
appearance of the button that invokes it?
Mark Smith
> In article
> <55537546-2fa4-4295-ab95-d96e8e4b1...@p8g2000yqb.googlegroups.com>,
The latter. I obviously want to keep the modal dialog as this is
platform specific. I just want to invoke the dialog from script,
rather than using the unstyleable file input button.
Mark Smith
> On Dec 4, 8:57 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > I've been spending the last day trying to prettify the file inputs on
> > some forms.
>
> > CSS support is almost not existent for file inputs on all the major
> > browsers.
>
> > So I decided to hide the ugly standard file input control and wrap
> > some javascript around some styleable buttons and input text boxes to
> > drive the actual file input.
>
> The "ugly" file buttons are what the users are used to. ;)
>
But they look different to all the other input buttons on the side.
Looking different to every other button on the site is more likely to
confuse the user.
I don't want to change the layout or behavior, I just want to make the
"Browse" button look the same as all the other buttons on the page. It
looks weird otherwise.
>
>
> > This works in IE6, IE7 and Safari but unfortunately not Firefox.
>
> That is too bad.
>
Indeed.
>
>
> > Code to replicate:
> > <form method="post" enctype="multipart/form-data" action="filetest/
> > upload">
> > <input type="file" name="file" id="file" value="" />
> > <input type="button" value="Browse for file"
> > onclick="document.getElementById('file').click();"/>
> > </form>
>
> > This is an almost 10 year old bug that is still open:https://bugzilla.mozilla.org/show_bug.cgi?id=36619
>
> Read carefully. It is not a bug at all. There are security concerns
> and there is no spec that says this behavior must exist in a browser.
> So maybe they will change it, maybe they won't...
>
This is still an open bug and set to "Future" btw. This feature exists
in almost every other browser.
And I did read the comments, very carefully. There is no real security
risk here, as one commenter put it:
"as to your first concern, we already allow webpages to display modal
informational messages with alert(), modal ok/cancel dialogs with
confirm(),
and under some circumstances to pop up new modeless windows with open
(). I
submit that there are ways to annoy a user already, and popping up a
file
picker dialog is no worse than any of the existing methods (which are
also not
seeing widespread abuse).
As to any potential security issue, I think that even the most naïve
computer
user knows what a file picker is and what it does. The only thing
they may not
understand is that the file they select in that dialog will be
transmitted to
the server. If we're really concerned about that, we ought to put a
confirmation message during the submit process that informs the user"
Oh, and for anyone else that is interested, I found an option 5. Ajax
uploads seem to be triggerable from script:
http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
Stefan Weiss
> Oh, and for anyone else that is interested, I found an option 5. Ajax
> uploads seem to be triggerable from script:
>
> http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
Did you look at how this was actually implemented? Apart from requiring
JQuery, that demo page has file upload fields with opacity:0 overlayed
above its buttons and links. I'd say this qualifies as
| #3 Use some hacky CSS and overlays to style the file picker.
They're also moving these fields around whenever the mouse moves, which
causes the mouse cursor to blink very fast in Firefox 3.0. Worst of all,
they initiate the upload as soon as a file has been selected (before the
user submits the form). This is *NOT* how forms usually work; I hope
this behavior can be disabled.
Now try turning off CSS and/or JavaScript -> upload fields are broken or
missing :-( As far as I can see, PPK's example has the same problem.
For what it's worth, I don't even try to style these elements anymore. I
just explain the situation to the client, and put the upload field at
the very end of the form, so it doesn't mess up the rest of the layout.
:wq
stefan
David Mark
> On Dec 4, 2:40 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 4, 8:57 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > > I've been spending the last day trying to prettify the file inputs on
> > > some forms.
>
> > > CSS support is almost not existent for file inputs on all the major
> > > browsers.
>
> > > So I decided to hide the ugly standard file input control and wrap
> > > some javascript around some styleable buttons and input text boxes to
> > > drive the actual file input.
>
> > The "ugly" file buttons are what the users are used to. ;)
>
> But they look different to all the other input buttons on the side.
And who did that?
> Looking different to every other button on the site is more likely to
> confuse the user.
I agree completely.
>
> I don't want to change the layout or behavior, I just want to make the
> "Browse" button look the same as all the other buttons on the page. It
> looks weird otherwise.
No, the other ones look weird. ;)
>
>
>
> > > This works in IE6, IE7 and Safari but unfortunately not Firefox.
>
> > That is too bad.
>
> Indeed.
>
>
>
>
>
> > > Code to replicate:
> > > <form method="post" enctype="multipart/form-data" action="filetest/
> > > upload">
> > > <input type="file" name="file" id="file" value="" />
> > > <input type="button" value="Browse for file"
> > > onclick="document.getElementById('file').click();"/>
> > > </form>
>
> > > This is an almost 10 year old bug that is still open:https://bugzilla.mozilla.org/show_bug.cgi?id=36619
>
> > Read carefully. It is not a bug at all. There are security concerns
> > and there is no spec that says this behavior must exist in a browser.
> > So maybe they will change it, maybe they won't...
>
> This is still an open bug and set to "Future" btw. This feature exists
> in almost every other browser.
It is _not_ a bug. Read it again (or just take my word for it as I
have read it).
>
> And I did read the comments, very carefully. There is no real security
> risk here, as one commenter put it:
That's your opinion.
>
> "as to your first concern, we already allow webpages to display modal
> informational messages with alert(), modal ok/cancel dialogs with
> confirm(),
> and under some circumstances to pop up new modeless windows with open
> (). I
> submit that there are ways to annoy a user already, and popping up a
> file
> picker dialog is no worse than any of the existing methods (which are
> also not
> seeing widespread abuse).
They are clearly wrong. A file picker dialog is much worse,
especially considering it is more of an upload dialog in this
case. ;)
>
> As to any potential security issue, I think that even the most naïve
> computer
> user knows what a file picker is and what it does.
How does that mitigate the problem?
> The only thing
> they may not
> understand is that the file they select in that dialog will be
> transmitted to
> the server.
That could lead to one hell of a misunderstanding.
> If we're really concerned about that, we ought to put a
> confirmation message during the submit process that informs the user"
Ought they?
>
> Oh, and for anyone else that is interested, I found an option 5. Ajax
> uploads seem to be triggerable from script:
>
> http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
I see. And it uses what?
David Mark
> On 07/12/09 11:50, Mark Smith wrote:
>
> > Oh, and for anyone else that is interested, I found an option 5. Ajax
> > uploads seem to be triggerable from script:
>
> >http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>
> Did you look at how this was actually implemented? Apart from requiring
> JQuery, that demo page has file upload fields with opacity:0 overlayed
> above its buttons and links. I'd say this qualifies as
>
> | #3 Use some hacky CSS and overlays to style the file picker.
Yes. Most Web developers (or "designers") want everything to look
exactly the way they want it to look and never mind what the user
agent thinks. CSS "resets", brittle hacks, anything goes if it makes
it look exactly the same in IE, FF and Safari. It's backwards as the
developers of the user agents probably had a good idea of what sort of
default style would work best for inputs (buttons particularly).
>
> They're also moving these fields around whenever the mouse moves, which
> causes the mouse cursor to blink very fast in Firefox 3.0.
Always nice. :)
> Worst of all,
How could it get worse?
> they initiate the upload as soon as a file has been selected (before the
> user submits the form).
Oh brother.
> This is *NOT* how forms usually work; I hope
> this behavior can be disabled.
I hope nobody is dense enough to use this thing.
>
> Now try turning off CSS and/or JavaScript -> upload fields are broken or
> missing :-(
But would would disable CSS and/or JS? Seriously, they've excluded
scores of corporate and mobile users, handicapped people, sailors,
people who hate JS and/or CSS, etc. But, on the upside, their buttons
will all look alike on their test machines. That's the mentality.
> As far as I can see, PPK's example has the same problem.
Unsurprising. :(
>
> For what it's worth, I don't even try to style these elements anymore.
That's the best policy. Usability always trumps "coolness". Don't
see marquees around much anymore and eventually clown buttons will go
away too.
> I
> just explain the situation to the client, and put the upload field at
> the very end of the form, so it doesn't mess up the rest of the layout.
Not sure how the default button style would mess up a layout. Clash
perhaps. But the end is a good place for them anyway.
Mark Smith
> > "Browse" button look the same as all the other buttons on the page. It
> > looks weird otherwise.
>
> No, the other ones look weird. ;)
>
So, you are in favor of getting rid of CSS styling of any buttons?
Nice.
> > Oh, and for anyone else that is interested, I found an option 5. Ajax
> > uploads seem to be triggerable from script:
>
> >http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>
> I see. And it uses what?
I'm just saying it's obviously possible to do.
Not advocating lifting this guys implementation.
Mark Smith
> On 07/12/09 11:50, Mark Smith wrote:
>
> > Oh, and for anyone else that is interested, I found an option 5. Ajax
> > uploads seem to be triggerable from script:
>
> >http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>
> Did you look at how this was actually implemented? Apart from requiring
> JQuery, that demo page has file upload fields with opacity:0 overlayed
> above its buttons and links. I'd say this qualifies as
>
Like I said, not advocating lifting his implementation.
If it's doable in jQuery, as jQuery is just a framework, it must be
possible to do with pure JavaScript also.
> For what it's worth, I don't even try to style these elements anymore. I
> just explain the situation to the client, and put the upload field at
> the very end of the form, so it doesn't mess up the rest of the layout.
Might have to do that.
Who is responsible for deciding that file inputs should not be styled
but text inputs and buttons, (that compose a file input) can be? And
what were they smoking at the time?
rf
> On Dec 7, 11:54 am, Stefan Weiss <krewech...@gmail.com> wrote:
> If it's doable in jQuery, as jQuery is just a framework, it must be
> possible to do with pure JavaScript also.
And just what do you think jQuery is? Not pure javascript? Just what do you
think jQuery is?
David Mark
> > > I don't want to change the layout or behavior, I just want to make the
> > > "Browse" button look the same as all the other buttons on the page. It
> > > looks weird otherwise.
>
> > No, the other ones look weird. ;)
>
> So, you are in favor of getting rid of CSS styling of any buttons?
>
> Nice.
Don't you think having them work for most (if not all) users is more
important than making them match your site? Nothing wrong with
colors, BTW (just realize that they may be rejected by the browser and/
or user). Best the padding, borders, outlines, etc. alone.
>
> > > Oh, and for anyone else that is interested, I found an option 5. Ajax
> > > uploads seem to be triggerable from script:
>
> > >http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>
> > I see. And it uses what?
>
> I'm just saying it's obviously possible to do.
It uses one of the four (bad) choices you enumerated. And does it
quite badly, with jQuery (of all things). Good luck with that!
>
> Not advocating lifting this guys implementation.
Trouble is that posting the link will lead others to follow it, assume
the thing "just works", etc. Next thing you know, it's all over the
Web and the author is emboldened to publish more bad scripts.
Mark Smith
Yes it is just javascript, a framework not liked round these parts,
but it is just javascript - that was my point.
Mark Smith
> On Dec 7, 7:38 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > > > I don't want to change the layout or behavior, I just want to make the
> > > > "Browse" button look the same as all the other buttons on the page. It
> > > > looks weird otherwise.
>
> > > No, the other ones look weird. ;)
>
> > So, you are in favor of getting rid of CSS styling of any buttons?
>
> > Nice.
>
> Don't you think having them work for most (if not all) users is more
> important than making them match your site? Nothing wrong with
> colors, BTW (just realize that they may be rejected by the browser and/
> or user). Best the padding, borders, outlines, etc. alone.
Border and outline have no effect (in FF)
Neither does width or line-height...
It's these omissions that are cause for me to look for an alternative.
>
>
> > > > Oh, and for anyone else that is interested, I found an option 5. Ajax
> > > > uploads seem to be triggerable from script:
>
> > > >http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>
> > > I see. And it uses what?
>
> > I'm just saying it's obviously possible to do.
>
> It uses one of the four (bad) choices you enumerated. And does it
> quite badly, with jQuery (of all things). Good luck with that!
>
That's true, I didn't take the time to 'look under the hood' before
posting the link.
Mark Smith
>
* Meant to say borders and padding don't work. - outline does.
David Mark
It's not a framework. It's around 70-100K (depending on version) of
badly designed and implemented JS, largely centering on a CSS selector
query engine. The idea is that it is somehow simpler (and cooler) to
replace:-
var el = document.getElementById('d');
doSomething(el);
doSomethingElse(el);
...with this sort of gobbledygook:-
$('#d').doSomething().doSomethingElse();
Now, if you are trying to save keystrokes (assuming you haven't heard
of macros), this might seem appealing, until you find out it requires
100K of shifty JS to (almost) work, complicates debugging, arbitrarily
excludes users, etc. Not to mention the pattern creates a new jQuery
object on every line. Look at the code in that object and you'll find
it's a horror show. But the typical jQuery-indoctrinated Web
developer is not a programmer, so they never look at the code (and
wouldn't be able to spot its shortcomings anyway).
It's all based on blind faith, which has never been rewarded.
Requiring constant upgrades just to tread water in the very latest
browsers is hardly an indication of cross-browser success, nor is it
practical as unit testing starts over with each revision. For those
who don't know, I guess any result can seem like a reward.
Mark Smith
That's nice.
Tell it to someone who is advocating jquery.
dorayme
<153dc4bd-bdd8-46d7...@j24g2000yqa.googlegroups.com>,
Mark Smith <marksm...@jungle-monkey.com> wrote:
> > > I don't want to change the layout or behavior, I just want to make the
> > > "Browse" button look the same as all the other buttons on the page. It
> > > looks weird otherwise.
> >
> > No, the other ones look weird. ;)
> >
>
> So, you are in favor of getting rid of CSS styling of any buttons?
>
> Nice.
Are you playing some sort of weird game in your posts, not quoting who
you are replying to etc? Even in Google Groups you can quote properly,
perhaps you don't know this. Go to alt.html where pretty well anything
can be discussed and I will help you on this.
--
dorayme
David Mark
> > Border and outline have no effect (in FF)
>
> * Meant to say borders and padding don't work. - outline does.
Best not to change any of those for inputs. Their characteristic
borders (however defined by the UA/OS) identify them as inputs.
Changing their padding can be a usability concern (think mobile
devices). Removing outlines (fairly common flourish) breaks
accessibility (think keyboard users).
David Mark
This is a discussion group. You may well view the messages in your
mail client, but they are not posted exclusively for you. ;)
Mark Smith
I didn't see anyone advocate jQuery, your anti jquery rant just seemed
out of context.
Glad you got it off your chest though. ;)
Mark Smith
Oh yeah, and WIDTH can't be set either....
Best not to use border and padding to style my inputs? Ha, thats
funny, you must have very undemanding clients.
My iphone handles these attributes fine btw.
Andrew
Hi,
First, I would like advise you to forget about styling upload buttons
if you
are using them in a regular forms. They look different in each
browser, and
users get used to the way they look like. I believe that native
controls
are always better than some styled ones.
Now about my component http://valums.com/ajax-upload/ It was meant to
be
used in js web applications, that require different file upload
strategy,
not in simple forms, which are better with the select->browse->submit.
(Think of google docs -> open file from pc)
And here are comments to other things about AJAX Upload you got wrong.
> Did you look at how this was actually implemented? Apart from requiring
> JQuery.
Look more closely, it doesn't require jQuery, it just uses it for the
demo,
as it's the most popular js library among the users of my component.
> they initiate the upload as soon as a file has been selected (before the
> user submits the form).
This can be changed in the options.
> Now try turning off CSS and/or JavaScript -> upload fields are broken or
> missing :-(
You should just add a normal file input to the markup, and then
replace it
with any div or link you want to style. And then create an instance of
my plugin.
Also, I'm just curios why you don't like jQuery so much? It has some
flaws, but it does what it promises really well. Quote from jquery.com
jQuery is js library that simplifies HTML document traversing,
event handling, animating, and Ajax interactions for rapid web
development.
There are the things jQuery can really help with, making your code
more readable.
Mark Smith
> Also, I'm just curios why you don't like jQuery so much? It has some
> flaws, but it does what it promises really well. Quote from jquery.com
>
> jQuery is js library that simplifies HTML document traversing,
> event handling, animating, and Ajax interactions for rapid web
> development.
>
> There are the things jQuery can really help with, making your code
> more readable.
First thanks for finding this post and writing back to clarify how
your component was intended to be used.
I still can't believe simple things like WIDTH, LINE-HEIGHT, PADDING
and BORDER don't style file inputs in firefox. At least in IE, I can
align the control nicely on the form. In FF it just looks terrible. My
client might just have to live with that.
I half agree with you about jQuery.
In the Real World (tm) I like to use jQuery for simple things like
wiring up events, or if I want to concisely manipulate a lot of
elements using a css selector. I also like it for reliably working
around buggy type selectors in IE6.
However, try to do anything more complicated than that and that
requires real debugging. Forget it, you are better off writing it
yourself.
rf
> There are the things jQuery can really help with, making your code
> more readable.
And more breakable.
Jonathan N. Little
> I didn't see anyone advocate jQuery, your anti jquery rant just seemed
> out of context.
>
> Glad you got it off your chest though. ;)
Rant? Try asking about the virtues of JQuery in alt.comp.lang.javascript
to the folks that really deal with JavaScript and you will get a
detailed and spirited dissertation on what is the problem with JQuery.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Stefan Weiss
>> Did you look at how this was actually implemented? Apart from requiring
>> JQuery.
>
> Look more closely, it doesn't require jQuery, it just uses it for the
> demo, as it's the most popular js library among the users of my component.
I stand corrected. The ajaxupload script itself apparently works without
jQuery. I saw the inline script on the demo-jquery.htm page (which
obviously does use jQuery) and a small passage in the external script,
which also refers to window.jQuery, so I just assumed that jQuery was a
prerequisite.
>> they initiate the upload as soon as a file has been selected (before the
>> user submits the form).
>
> This can be changed in the options.
I thought so. I was surprised to accidently send a file when I only
wanted to try out your upload form element. Good thing I didn't test it
with an image from my... uh... special folder ;-)
Incidentally, I just saw the same behavior yesterday at tineye.com, an
image search engine.
>> Now try turning off CSS and/or JavaScript -> upload fields are broken or
>> missing :-(
>
> You should just add a normal file input to the markup, and then
> replace it
> with any div or link you want to style. And then create an instance of
> my plugin.
Yes, that should work if JS is disabled, but probably not when only CSS
is disabled. Not a very common situation, granted, but I think that
(apart from specialized applications) accessibility shouldn't be
sacrificed for pretty upload buttons. YMMV.
> Also, I'm just curios why you don't like jQuery so much? It has some
> flaws, but it does what it promises really well.
I only mentioned it as an aside; it's an extra 56K download in addition
to the frontend script, which seems a little excessive just for styled
upload elements. If the rest of the page uses jQuery, the point is moot.
:wq
stefan
David Mark
It's always a good day to bash jQuery. And it leaves a trail for the
lost to follow. You can find out a lot more about the consequences of
that most dubious script here than in the jQuery lists.
David Mark
> On Dec 7, 7:55 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 7, 8:39 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > > > Border and outline have no effect (in FF)
>
> > > * Meant to say borders and padding don't work. - outline does.
>
> > Best not to change any of those for inputs. Their characteristic
> > borders (however defined by the UA/OS) identify them as inputs.
> > Changing their padding can be a usability concern (think mobile
> > devices). Removing outlines (fairly common flourish) breaks
> > accessibility (think keyboard users).
>
> Oh yeah, and WIDTH can't be set either....
Good. Leave it alone. You have no idea how wide the button needs to
be. The UA does. ;)
>
> Best not to use border and padding to style my inputs? Ha, thats
> funny, you must have very undemanding clients.
You are supposed to be the expert. You have to explain to clients
what is practical and what is not.
>
> My iphone handles these attributes fine btw.
So? All you can do is make the buttons harder to identify and
possibly harder to touch.
Michael Haufe ("TNO")
> This works in IE6, IE7 and Safari but unfortunately not Firefox.
If bored enough, here's the bug report for FireFox:
https://bugzilla.mozilla.org/show_bug.cgi?id=52500
Mark Smith
> On Dec 8, 3:57 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > On Dec 7, 7:55 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 7, 8:39 am, Mark Smith <marksmith5...@jungle-monkey.com> wrote:
>
> > > > > Border and outline have no effect (in FF)
>
> > > > * Meant to say borders and padding don't work. - outline does.
>
> > > Best not to change any of those for inputs. Their characteristic
> > > borders (however defined by the UA/OS) identify them as inputs.
> > > Changing their padding can be a usability concern (think mobile
> > > devices). Removing outlines (fairly common flourish) breaks
> > > accessibility (think keyboard users).
>
> > Oh yeah, and WIDTH can't be set either....
>
> Good. Leave it alone. You have no idea how wide the button needs to
> be. The UA does. ;)
>
Lets just do away with styling all together then. Just serve raw text
- let the UA decide how it should look.
Next you'll be telling me not to use placeholders. "The UA knows best
where things should go..." Ridiculous.
>
>
> > Best not to use border and padding to style my inputs? Ha, thats
> > funny, you must have very undemanding clients.
>
> You are supposed to be the expert. You have to explain to clients
> what is practical and what is not.
>
Despite that we 'experts' know that functionality and appearance are
two seperate things. Form elements with differently sized, differently
styled inputs just looks bad and unprofessional.
Leaving everything unstyled as you are recommending does not look very
'Web 2.0'.
>
> > My iphone handles these attributes fine btw.
>
> So? All you can do is make the buttons harder to identify and
> possibly harder to touch.
This is a red herring, we have a seperate front end for mobile users.
David Mark
[...]
>
> Hi,
Hi!
>
> First, I would like advise you to forget about styling upload buttons
> if you
> are using them in a regular forms.
That's (sort of) what I said. Perhaps you are trying to address the
OP?
> They look different in each
> browser, and
> users get used to the way they look like.
Exactly.
> I believe that native
> controls
> are always better than some styled ones.
That seems a bit non-committal. :)
>
> Now about my componenthttp://valums.com/ajax-upload/
Okay.
/**
* AJAX Upload
* Project page - http://valums.com/ajax-upload/
* Copyright (c) 2008 Andris Valums, http://valums.com
* Licensed under the MIT license (http://valums.com/mit-license/)
*/
(function(){
var d = document, w = window;
/**
* Get element by id
*/
function get(element){
if (typeof element == "string")
element = d.getElementById(element);
return element;
}
That's a worthless pattern.
/**
* Attaches event to a dom element
*/
function addEvent(el, type, fn){
if (w.addEventListener){
Bad inference.
el.addEventListener(type, fn, false);
That's not a window.
} else if (w.attachEvent){
Bad feature detection. Use typeof.
var f = function(){
fn.call(el, w.event);
Don't preserve references to host objects (especially window). Will
lead to memory leaks in IE.
};
el.attachEvent('on' + type, f)
Oh, it leaks anyway. Well, you could cut down on that a bit.
}
}
/**
* Creates and returns element from html chunk
*/
var toElement = function(){
var div = d.createElement('div');
return function(html){
div.innerHTML = html;
var el = div.childNodes[0];
firstChild?
div.removeChild(el);
return el;
}
}();
Some browsers will choke on this pattern (missing paranthesis around
the function expression).
function hasClass(ele,cls){
return ele.className.match(new RegExp('(\\s|^)'+cls+'(\\s|$)'));
}
Why match? You aren't doing anything with the match.
function addClass(ele,cls) {
if (!hasClass(ele,cls)) ele.className += " "+cls;
}
function removeClass(ele,cls) {
var reg = new RegExp('(\\s|^)'+cls+'(\\s|$)');
ele.className=ele.className.replace(reg,' ');
I don't think so. :(
}
// getOffset function copied from jQuery lib (http://jquery.com/)
Do _not_ copy jQuery code. We'll skip this one.
[...]
/**
* Crossbrowser mouse coordinates
*/
function getMouseCoords(e){
// pageX/Y is not supported in IE
// http://www.quirksmode.org/dom/w3c_cssom.html
Do _not_ copy code from quirksmode.org.
if (!e.pageX && e.clientX){
// In Internet Explorer 7 some properties (mouse coordinates) are
treated as physical,
// while others are logical (offset).
var zoom = 1;
var body = document.body;
if (body.getBoundingClientRect) {
var bound = body.getBoundingClientRect();
zoom = (bound.right - bound.left)/body.clientWidth;
}
That looks suspiciously like bullshit.
return {
x: e.clientX / zoom + d.body.scrollLeft +
d.documentElement.scrollLeft,
y: e.clientY / zoom + d.body.scrollTop +
d.documentElement.scrollTop
This is definite bullshit. :)
};
}
return {
x: e.pageX,
y: e.pageY
};
}
[...]
/**
* Cross-browser way to get xhr object
*/
There's nothing cross-browser about this script.
var getXhr = function(){
var xhr;
return function(){
if (xhr) return xhr;
Waste of time and space.
if (typeof XMLHttpRequest !== 'undefined') {
xhr = new XMLHttpRequest();
} else {
var v = [
"Microsoft.XmlHttp",
"MSXML2.XmlHttp.5.0",
"MSXML2.XmlHttp.4.0",
"MSXML2.XmlHttp.3.0",
"MSXML2.XmlHttp.2.0"
Too many.
];
for (var i=0; i < v.length; i++){
try {
xhr = new ActiveXObject(v[i]);
Where's the detection of ActiveXObject?
break;
} catch (e){}
}
Well, at least it won't bomb in IE6 when ActiveX is disabled
(something jQuery never figured out).
}
return xhr;
}
}();
// Please use AjaxUpload , Ajax_upload will be removed in the next
version
Okay.
Ajax_upload = AjaxUpload = function(button, options){
if (button.jquery){
// jquery object was passed
button = button[0];
} else if (typeof button == "string" && /^#.*/.test(button)){
button = button.slice(1);
}
More waste. Why would you pass "#id" to this? It's a string or an
object. If it is a string, it's an ID.
button = get(button);
this._input = null;
this._button = button;
this._disabled = false;
this._submitting = false;
// Variable changes to true if the button was clicked
// 3 seconds ago (requred to fix Safari on Mac error)
That sounds mystical. :)
this._justClicked = false;
this._parentDialog = d.body;
if (window.jQuery && jQuery.ui && jQuery.ui.dialog){
window.jQuery?!
var parentDialog = jQuery(this._button).parents('.ui-dialog');
if (parentDialog.length){
this._parentDialog = parentDialog[0];
}
Whatever.
[...]
// Fixing problem with Safari
// The problem is that if you leave input before the file select
dialog opens
// it does not upload the file.
// As dialog opens slowly (it is a sheet dialog which takes some
time to open)
// there is some time while you can leave the button.
// So we should not change display to none immediately
addEvent(input, 'click', function(){
self._justClicked = true;
setTimeout(function(){
// we will wait 3 seconds for dialog to open
self._justClicked = false;
}, 2500);
});
In other words, you couldn't make it work, so you added a flimsy hack
based on timing. :(
[...]
response = window["eval"]("(" + response + ")");
Stop copying from Resig. He doesn't have a clue. ;)
// method, enctype must be specified here
// because changing this attr on the fly is not allowed in IE 6/7
var form = toElement('<form method="post" enctype="multipart/form-
data"></form>');
Mystical incantation.
Anyway, you were saying...
> It was meant to
> be
> used in js web applications, that require different file upload
> strategy,
> not in simple forms, which are better with the select->browse->submit.
> (Think of google docs -> open file from pc)
Whatever. I don't care to think of "google docs".
>
> And here are comments to other things about AJAX Upload you got wrong.
Huh?
>
> > Did you look at how this was actually implemented? Apart from requiring
> > JQuery.
I didn't say that. Is this your first time on Usenet?
>
> Look more closely, it doesn't require jQuery, it just uses it for the
> demo,
> as it's the most popular js library among the users of my component.
So? Your users are ignorant. They'd almost have to be to use this
"solution". ;)
>
> > they initiate the upload as soon as a file has been selected (before the
> > user submits the form).
>
> This can be changed in the options.
Great! But I didn't say that either.
>
> > Now try turning off CSS and/or JavaScript -> upload fields are broken or
> > missing :-(
>
> You should just add a normal file input to the markup, and then
> replace it
> with any div or link you want to style. And then create an instance of
> my plugin.
I should? It's _your_ demo.
>
> Also, I'm just curios why you don't like jQuery so much? It has some
> flaws, but it does what it promises really well.
It does not.
> Quote from jquery.com
There's an impartial source!
>
> jQuery is js library that simplifies HTML document traversing,
> event handling, animating, and Ajax interactions for rapid web
> development.
>
> There are the things jQuery can really help with, making your code
> more readable.
That's nonsense. Document traversing? It can't even _read_
documents.
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/d2c0407a7fc2e33a#
Event handling is simple to begin with and their (very simple)
animations are known to be third-rate, even by the most devoted jQuery
junkies.
The idea is that you don't want to mash all of these things together
in one monolithic script that you then have to swap out every year
just to tread water in the latest versions of major browsers. It's
just a stupid strategy for browser scripting. A million code monkeys
_can_ be wrong.
David Mark
> On Dec 8, 1:10 pm, Andrew <val...@gmail.com> wrote:
>
> > Also, I'm just curios why you don't like jQuery so much? It has some
> > flaws, but it does what it promises really well. Quote from jquery.com
>
> > jQuery is js library that simplifies HTML document traversing,
> > event handling, animating, and Ajax interactions for rapid web
> > development.
>
> > There are the things jQuery can really help with, making your code
> > more readable.
>
> First thanks for finding this post and writing back to clarify how
> your component was intended to be used.
>
> I still can't believe simple things like WIDTH, LINE-HEIGHT, PADDING
> and BORDER don't style file inputs in firefox. At least in IE, I can
> align the control nicely on the form. In FF it just looks terrible. My
> client might just have to live with that.
>
> I half agree with you about jQuery.
Then you are half-wrong.
>
> In the Real World (tm)
What world do you think you are on?
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/d2c0407a7fc2e33a#
David Mark
> Mark Smith wrote:
> > I didn't see anyone advocate jQuery, your anti jquery rant just seemed
> > out of context.
>
> > Glad you got it off your chest though. ;)
>
> Rant? Try asking about the virtues of JQuery in alt.comp.lang.javascript
> to the folks that really deal with JavaScript and you will get a
> detailed and spirited dissertation on what is the problem with JQuery.
The folks that really deal with JS are exclusively in the alt branch?
David Mark
wrote:
[...]
>
> > Good. Leave it alone. You have no idea how wide the button needs to
> > be. The UA does. ;)
>
> Lets just do away with styling all together then. Just serve raw text
> - let the UA decide how it should look.
Raw text? Are you starting a new discussion?
>
> Next you'll be telling me not to use placeholders. "The UA knows best
> where things should go..." Ridiculous.
Placeholders? And you said it, not me.
>
>
>
> > > Best not to use border and padding to style my inputs? Ha, thats
> > > funny, you must have very undemanding clients.
>
> > You are supposed to be the expert. You have to explain to clients
> > what is practical and what is not.
>
> Despite that we 'experts' know that functionality and appearance are
> two seperate things. Form elements with differently sized, differently
> styled inputs just looks bad and unprofessional.
No, using bizarre hacks to try to force the issue is unprofessional.
Professionals know what is practical. If it looks "bad" (to you),
that's too bad.
>
> Leaving everything unstyled as you are recommending does not look very
> 'Web 2.0'.
I didn't recommend "leaving everything unstyled". And what does "Web
2.0" have to do with CSS?
>
>
>
> > > My iphone handles these attributes fine btw.
>
> > So? All you can do is make the buttons harder to identify and
> > possibly harder to touch.
>
> This is a red herring, we have a seperate front end for mobile users.
Of course you do. ;)
Mark Smith
One where deliverables come before ideologies.
David Mark
In other words, you have no idea what you are talking about. :)
Mark Smith
> On Dec 8, 10:49 am, Mark Smith <marksmith5...@jungle-monkey.com>
> wrote:
>
> [...]
>
>
>
> > > Good. Leave it alone. You have no idea how wide the button needs to
> > > be. The UA does. ;)
>
> > Lets just do away with styling all together then. Just serve raw text
> > - let the UA decide how it should look.
>
> Raw text? Are you starting a new discussion?
>
>
No, just following your logic to it's twisted conclusion.
>
>
>
> > > > Best not to use border and padding to style my inputs? Ha, thats
> > > > funny, you must have very undemanding clients.
>
> > > You are supposed to be the expert. You have to explain to clients
> > > what is practical and what is not.
>
> > Despite that we 'experts' know that functionality and appearance are
> > two seperate things. Form elements with differently sized, differently
> > styled inputs just looks bad and unprofessional.
>
> No, using bizarre hacks to try to force the issue is unprofessional.
> Professionals know what is practical. If it looks "bad" (to you),
> that's too bad.
>
It's better than dictating your clients requirements to them.
>
>
> > Leaving everything unstyled as you are recommending does not look very
> > 'Web 2.0'.
>
> I didn't recommend "leaving everything unstyled".
You told me to leave with width alone, "the user agent knows best".
FF leaves the field fixed at 195px. Nomatter what style you put on it.
That is certainly not wide enough for most file paths and definitely
not best for this page.
>
>
> > > > My iphone handles these attributes fine btw.
>
> > > So? All you can do is make the buttons harder to identify and
> > > possibly harder to touch.
>
> > This is a red herring, we have a seperate front end for mobile users.
>
> Of course you do. ;)
Yes. Highly cut down. You can't upload files from most mobile
platforms anyway.
If you want to point your phone to a front end designed for a desktop
- do it, but don't compain it it doesn't look great on your tiny
screen.
Jonathan N. Little
Nope, I just flubbed up not noticing the cross-post...maybe time for
another cup of coffee...
David Mark
The width is not everything. And I don't think that's a _direct_
quote, is it?
>
> FF leaves the field fixed at 195px. Nomatter what style you put on it.
Leaves what field at 195px in what mode and on what PC?
> That is certainly not wide enough for most file paths and definitely
> not best for this page.
I was referring to the width of buttons.
>
>
>
> > > > > My iphone handles these attributes fine btw.
>
> > > > So? All you can do is make the buttons harder to identify and
> > > > possibly harder to touch.
>
> > > This is a red herring, we have a seperate front end for mobile users.
>
> > Of course you do. ;)
>
> Yes. Highly cut down. You can't upload files from most mobile
> platforms anyway.
And why did you have to cut it down? Because it was bloated with
dubious scripts. It's a very common problem that leads to two sites
where one would suffice. ;)
>
> If you want to point your phone to a front end designed for a desktop
> - do it, but don't compain it it doesn't look great on your tiny
> screen.
My phone? I guess you've never used it. And you don't design front-
ends exclusively for desktops (that's your other problem).
Mark Smith
> > FF leaves the field fixed at 195px. Nomatter what style you put on it.
>
> Leaves what field at 195px in what mode and on what PC?
FF 3.5.5, on XP. Default settings. Though judging by the age of the
bug report linked to by Michael, it will happen on a few other
versions as well...
>
> > That is certainly not wide enough for most file paths and definitely
> > not best for this page.
>
> I was referring to the width of buttons.
>
Then you where changing the topic - again.
We where talking about the lack of css support for the FILE INPUT
element.
>
>
> > Yes. Highly cut down. You can't upload files from most mobile
> > platforms anyway.
>
> And why did you have to cut it down? Because it was bloated with
> dubious scripts. It's a very common problem that leads to two sites
> where one would suffice. ;)
>
...
>
> My phone? I guess you've never used it. And you don't design front-
> ends exclusively for desktops (that's your other problem).
I guess you know better than the people behind a few little web sites
like , Google, MSN, Amazon, Ebay... etc, all of which have seperate
front ends designed specifically for mobile devices.
David Mark
wrote:
> On Dec 8, 4:29 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > FF leaves the field fixed at 195px. Nomatter what style you put on it.
>
> > Leaves what field at 195px in what mode and on what PC?
>
> FF 3.5.5, on XP. Default settings. Though judging by the age of the
> bug report linked to by Michael, it will happen on a few other
> versions as well...
Okay.
>
>
>
> > > That is certainly not wide enough for most file paths and definitely
> > > not best for this page.
>
> > I was referring to the width of buttons.
>
> Then you where changing the topic - again.
I where (sic) what? As for padding and borders, leave them alone on
_all_ input elements. That should be easy enough to remember. :)
>
> We where talking about the lack of css support for the FILE INPUT
> element.
Which is rendered as a *button* and a text input.
>
>
>
>
>
> > > Yes. Highly cut down. You can't upload files from most mobile
> > > platforms anyway.
>
> > And why did you have to cut it down? Because it was bloated with
> > dubious scripts. It's a very common problem that leads to two sites
> > where one would suffice. ;)
>
> ...
>
> > My phone? I guess you've never used it. And you don't design front-
> > ends exclusively for desktops (that's your other problem).
>
> I guess you know better than the people behind a few little web sites
> like , Google, MSN, Amazon, Ebay... etc, all of which have seperate
> front ends designed specifically for mobile devices.
Why is it that those who have the most to learn always cite terrible
decisions by large Websites as if they were gospel (thus learning
nothing?) Google, MSN, Amazon, eBay. What a rogue's gallery that
is. Copy their developers at your own risk. ;)
And search the archive. We've discuseed - for example - Google's
crappy sites to death. There's not a scintilla of evidence that
anyone at Google knows the first thing about Web development.
Advertising yes, Web sites no. Oh, but they are so successful! How
much more successful would they be if they had competent developers?
Andrew
> On Dec 8, 8:10 am, Andrew <val...@gmail.com> wrote:
>
> [...]
>
>
>
> > Hi,
>
> Hi!
>
>
>
> > First, I would like advise you to forget about styling upload buttons
> > if you
> > are using them in a regular forms.
>
> That's (sort of) what I said. Perhaps you are trying to address the
> OP?
>
> > They look different in each
> > browser, and
> > users get used to the way they look like.
>
> Exactly.
>
> > I believe that native
> > controls
> > are always better than some styled ones.
>
> That seems a bit non-committal. :)
>
>
>
> > Now about my componenthttp://valums.com/ajax-upload/
>
> Okay.
>
> /**
> * AJAX Upload
> * Copyright (c) 2008 Andris Valums,http://valums.com
>
> Event handling is simple to begin with and their (very simple)
> animations are known to be third-rate, even by the most devoted jQuery
> junkies.
>
> The idea is that you don't want to mash all of these things together
> in one monolithic script that you then have to swap out every year
> just to tread water in the latest versions of major browsers. It's
> just a stupid strategy for browser scripting. A million code monkeys
> _can_ be wrong.
Thanks for your review! It worth a lot for me.
And sorry for comments that were addressed to other people,
it's my first time here.
David Mark
Hey, nice attitude. :) Sorry, but I didn't have time to finish it.
>
> And sorry for comments that were addressed to other people,
> it's my first time here.
NP.
Mark Smith
> > > I was referring to the width of buttons.
>
> > Then you where changing the topic - again.
>
> I where (sic) what? As for padding and borders, leave them alone on
> _all_ input elements. That should be easy enough to remember. :)
>
Yeah, who cares if the site looks like it was designed in 1997.
>
> > We where talking about the lack of css support for the FILE INPUT
> > element.
>
> Which is rendered as a *button* and a text input.
>
That's how its rendered on most browsers, but it's not a button and
text box, its a file input and css rules are not being applied.
Hence the need for a workaround, not a change in requirements. Try to
keep up.
> > > > Yes. Highly cut down. You can't upload files from most mobile
> > > > platforms anyway.
>
> > > And why did you have to cut it down? Because it was bloated with
> > > dubious scripts. It's a very common problem that leads to two sites
> > > where one would suffice. ;)
>
> > ...
>
> > > My phone? I guess you've never used it. And you don't design front-
> > > ends exclusively for desktops (that's your other problem).
>
> > I guess you know better than the people behind a few little web sites
> > like , Google, MSN, Amazon, Ebay... etc, all of which have seperate
> > front ends designed specifically for mobile devices.
>
> Why is it that those who have the most to learn always cite terrible
> decisions by large Websites as if they were gospel (thus learning
> nothing?) Google, MSN, Amazon, eBay. What a rogue's gallery that
> is. Copy their developers at your own risk. ;)
>
> And search the archive. We've discuseed - for example - Google's
> crappy sites to death. There's not a scintilla of evidence that
> anyone at Google knows the first thing about Web development.
> Advertising yes, Web sites no. Oh, but they are so successful! How
> much more successful would they be if they had competent developers?
Ha ha, I was being sarcastic, but no, you actually do think you know
better.
Like I said before, in the Real World, deliverables come before
ideologies.
David Mark
> On Dec 8, 4:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > I was referring to the width of buttons.
>
> > > Then you where changing the topic - again.
>
> > I where (sic) what? As for padding and borders, leave them alone on
> > _all_ input elements. That should be easy enough to remember. :)
>
> Yeah, who cares if the site looks like it was designed in 1997.
>
>
>
> > > We where talking about the lack of css support for the FILE INPUT
> > > element.
>
> > Which is rendered as a *button* and a text input.
>
> That's how its rendered on most browsers, but it's not a button and
> text box, its a file input and css rules are not being applied.
Yes.
>
> Hence the need for a workaround, not a change in requirements. Try to
> keep up.
You don't help yourself, do you? :)
>
>
>
> > > > > Yes. Highly cut down. You can't upload files from most mobile
> > > > > platforms anyway.
>
> > > > And why did you have to cut it down? Because it was bloated with
> > > > dubious scripts. It's a very common problem that leads to two sites
> > > > where one would suffice. ;)
>
> > > ...
>
> > > > My phone? I guess you've never used it. And you don't design front-
> > > > ends exclusively for desktops (that's your other problem).
>
> > > I guess you know better than the people behind a few little web sites
> > > like , Google, MSN, Amazon, Ebay... etc, all of which have seperate
> > > front ends designed specifically for mobile devices.
>
> > Why is it that those who have the most to learn always cite terrible
> > decisions by large Websites as if they were gospel (thus learning
> > nothing?) Google, MSN, Amazon, eBay. What a rogue's gallery that
> > is. Copy their developers at your own risk. ;)
>
> > And search the archive. We've discuseed - for example - Google's
> > crappy sites to death. There's not a scintilla of evidence that
> > anyone at Google knows the first thing about Web development.
> > Advertising yes, Web sites no. Oh, but they are so successful! How
> > much more successful would they be if they had competent developers?
>
> Ha ha, I was being sarcastic, but no, you actually do think you know
> better.
Sarcastic about what? That Google, Amazon, etc. are shining
examples? So you have no point then?
>
> Like I said before, in the Real World, deliverables come before
> ideologies.
The "Real World" is what neophytes bring up when painted into a
corner. Do you think you can delivery anything (reliable) with jQuery
than I can without it? If so, you are living in a fantasy world. ;)
Mark Smith
> > That's how its rendered on most browsers, but it's not a button and
> > text box, its a file input and css rules are not being applied.
>
> Yes.
>
Sucks. You would have thought web standards could have sorted stuff
like this out. It's not like they haven't had over 15 years or
anything!
> > > > > > Yes. Highly cut down. You can't upload files from most mobile
> > > > > > platforms anyway.
>
> > > > > And why did you have to cut it down? Because it was bloated with
> > > > > dubious scripts. It's a very common problem that leads to two sites
> > > > > where one would suffice. ;)
>
> > > > ...
>
> > > > > My phone? I guess you've never used it. And you don't design front-
> > > > > ends exclusively for desktops (that's your other problem).
>
> > > > I guess you know better than the people behind a few little web sites
> > > > like , Google, MSN, Amazon, Ebay... etc, all of which have seperate
> > > > front ends designed specifically for mobile devices.
>
> > > Why is it that those who have the most to learn always cite terrible
> > > decisions by large Websites as if they were gospel (thus learning
> > > nothing?) Google, MSN, Amazon, eBay. What a rogue's gallery that
> > > is. Copy their developers at your own risk. ;)
>
> > > And search the archive. We've discuseed - for example - Google's
> > > crappy sites to death. There's not a scintilla of evidence that
> > > anyone at Google knows the first thing about Web development.
> > > Advertising yes, Web sites no. Oh, but they are so successful! How
> > > much more successful would they be if they had competent developers?
>
> > Ha ha, I was being sarcastic, but no, you actually do think you know
> > better.
>
> Sarcastic about what? That Google, Amazon, etc. are shining
> examples? So you have no point then?
>
Get a clue. You think google and amazon would not use one frontend if
they thought it would benefit their customers? After all money is the
bottom line.
Mobile users have different requirements to desktop users.
Show me a site with as much functionality as eBay or Amazon, that
looks good and works from desktop and mobile platforms.
(A simple web page that renders some controls won't cut it - I mean
something that is used and works in a real business scenario. I bet
you can't.)
> > Like I said before, in the Real World, deliverables come before
> > ideologies.
>
> The "Real World" is what neophytes bring up when painted into a
> corner. Do you think you can delivery anything (reliable) with jQuery
> than I can without it? If so, you are living in a fantasy world. ;)
Non sequitur. You really do have trouble concentrating, nowhere did I
make any such claim.
David Mark
What you don't understand is that their sites are focused on the
past. There was a time (long ago) when it might have made sense to
have two. And how do you conclude that their obviously incompetent
Web developers can explain anything to management. The
recommendations of "experts" is all that the bean counters have to go
on. ;)
And I still can't figure out if you like Google, Amazon, etc. You
dropped their names to try to make a point, then claimed sarcasm. (?)
>
> Mobile users have different requirements to desktop users.
Exactly. So leave the input styles alone.
>
> Show me a site with as much functionality as eBay or Amazon, that
> looks good and works from desktop and mobile platforms.
As much functionality as eBay and Amazon? What does that mean?
Perhaps you mean as unnecessarily bloated and poorly laid out as those
two? That won't work. That's why they ended up with two sites. ;)
>
> (A simple web page that renders some controls won't cut it - I mean
> something that is used and works in a real business scenario. I bet
> you can't.)
Controls? Real business scenario? Google's pages are about as bare
bones as they come (in terms of content). Are you saying their pages
couldn't work equally well in the majority of mobile devices released
this century?
>
> > > Like I said before, in the Real World, deliverables come before
> > > ideologies.
>
> > The "Real World" is what neophytes bring up when painted into a
> > corner. Do you think you can delivery anything (reliable) with jQuery
> > than I can without it? If so, you are living in a fantasy world. ;)
>
> Non sequitur. You really do have trouble concentrating
You really do have trouble staying on topic.
> , nowhere did I
> make any such claim.
Then what is your big "Real World" claim? Oh, that you can deliver
something that doesn't really work and ignore the reasons why. Good
luck with that!
Mark Smith
> > Get a clue. You think google and amazon would not use one frontend if
> > they thought it would benefit their customers? After all money is the
> > bottom line.
>
> What you don't understand is that their sites are focused on the
> past. There was a time (long ago) when it might have made sense to
> have two. And how do you conclude that their obviously incompetent
> Web developers can explain anything to management. The
> recommendations of "experts" is all that the bean counters have to go
> on. ;)
>
> And I still can't figure out if you like Google, Amazon, etc. You
> dropped their names to try to make a point, then claimed sarcasm. (?)
>
Politics aside, they are highly popular successful cash generating web
sites.
Their developers probably have many thousands of years experience
between them.
If they could make the user experience better by cutting back the
front end - and make more money, they would. The sarcasm was that you
knew better than them.
You failed to provide any counter examples, as I expected ;)
>
>
> > Mobile users have different requirements to desktop users.
>
> Exactly. So leave the input styles alone.
>
You are saying we should design every page as if it was for a mobile
device.
This inherently limits functionality - notably mobile users have
limited bandwidth and screen space.
> > Show me a site with as much functionality as eBay or Amazon, that
> > looks good and works from desktop and mobile platforms.
>
> As much functionality as eBay and Amazon? What does that mean?
> Perhaps you mean as unnecessarily bloated and poorly laid out as those
> two? That won't work. That's why they ended up with two sites. ;)
>
If they could have one site to do it all and/or better, they would do
it, out of pure self interest.
Again, I ask that you show me some examples of businesses 'doing it
right'.
Since you can't provide any, I submit that your 'way' is wrong.
>
>
> > (A simple web page that renders some controls won't cut it - I mean
> > something that is used and works in a real business scenario. I bet
> > you can't.)
>
> Controls? Real business scenario? Google's pages are about as bare
> bones as they come (in terms of content).
As bare bones as their front page is, the engineers at google still
decided to make a seperate mobile homepage.
Haven't you heard of gmail, google news, etc they all have plenty of
content and seperate mobile and desktop front ends - to meet different
requirements. Why do you find it so hard to understand?
> Are you saying their pages
> couldn't work equally well in the majority of mobile devices released
> this century?
>
Yes, they lack the resolution, and sometimes the bandwidth.
Here's some more for you:
Wikipedia.org (Hardly bloated, yet they recognise the need for a cut
down mobile front end)
Digg.com
Slashdot.org
In fact all the main news/social websites have mobile front ends.
I guess you know better, eh?
>
>
> > > > Like I said before, in the Real World, deliverables come before
> > > > ideologies.
>
> > > The "Real World" is what neophytes bring up when painted into a
> > > corner. Do you think you can delivery anything (reliable) with jQuery
> > > than I can without it? If so, you are living in a fantasy world. ;)
>
> > Non sequitur. You really do have trouble concentrating
>
> You really do have trouble staying on topic.
>
> > , nowhere did I
> > make any such claim.
>
> Then what is your big "Real World" claim? Oh, that you can deliver
> something that doesn't really work and ignore the reasons why. Good
> luck with that!
My claim is that the standards need fixed - at least for the file
upload control.
This is why people are resorting to abortions - like flash. Because
like it or not, money makes the world go round and business
requirements always trump a technically elegant solution.
beegee
> There are the things jQuery can really help with, making your code
> more readable.
You were making sense up to this comment.
Having worked on (added features and fixed bugs) on a couple of sites
that used jQuery I would have to disagree. The noise that DM exampled
above: "$('#d').doSomething().doSomethingElse();" was typical except
the chains I found would stretch across the page and wrap down to the
next line. Utterly unreadable and undebuggable.
I believe jQuery is an "ah hah!" for relatively new javascript coders
but anyone who has experienced a real develop-qa-release-maintain-qa-
release etc. cycle would avoid it. I guess it might be good for
disposable websites that have to 'appear' to work across the most
popular browsers.
Bob
David Mark
> On Dec 9, 1:18 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Get a clue. You think google and amazon would not use one frontend if
> > > they thought it would benefit their customers? After all money is the
> > > bottom line.
>
> > What you don't understand is that their sites are focused on the
> > past. There was a time (long ago) when it might have made sense to
> > have two. And how do you conclude that their obviously incompetent
> > Web developers can explain anything to management. The
> > recommendations of "experts" is all that the bean counters have to go
> > on. ;)
>
> > And I still can't figure out if you like Google, Amazon, etc. You
> > dropped their names to try to make a point, then claimed sarcasm. (?)
>
> Politics aside, they are highly popular successful cash generating web
> sites.
Politics were never part of it. And what do their advertising and
marketing abilities prove about their Web development proficiency?
>
> Their developers probably have many thousands of years experience
> between them.
>
> If they could make the user experience better by cutting back the
> front end - and make more money, they would.
As in the future? Who knows what they will do. The sites you refer
to were clearly designed and implemented years ago.
> The sarcasm was that you
> knew better than them.
So you really are trumpeting Google, eBay, etc. as good examples. Ask
their users about that. And it's a non-argument anyway.
And certainly I _knew_ better than them, I most likely _know_ better
than them now. Time will tell. ;)
>
> You failed to provide any counter examples, as I expected ;)
Any counter examples of what? ISTM you asked for an example of a site
that was "actually used" for a "real business scenario" and could
possibly work on some mobile device(s)? Can you be more specific?
>
>
>
> > > Mobile users have different requirements to desktop users.
>
> > Exactly. So leave the input styles alone.
>
> You are saying we should design every page as if it was for a mobile
> device.
Nope. Neither am I saying you should design pages as if they were for
desktop PC's with huge monitors, maximized browsers, etc.
>
> This inherently limits functionality - notably mobile users have
> limited bandwidth and screen space.
All sorts of users have limited bandwidth. Low bandwidth does not
inherently limit functionality in Web pages (unless you use 100K of
script where 10K would do, fail to use progressive enhancement, etc.).
And how much bandwidth do you think it takes to produce Google's pages
(if they were designed competently).
>
> > > Show me a site with as much functionality as eBay or Amazon, that
> > > looks good and works from desktop and mobile platforms.
>
> > As much functionality as eBay and Amazon? What does that mean?
> > Perhaps you mean as unnecessarily bloated and poorly laid out as those
> > two? That won't work. That's why they ended up with two sites. ;)
>
> If they could have one site to do it all and/or better, they would do
> it, out of pure self interest.
There you go again. Your examples are from the past. How do you know
what these companies will produce in the future? And as you examples
are all bad, it wouldn't surprise me if they kept going in the wrong
direction, even if it detracts from their profitability. They don't
know what they are doing.
>
> Again, I ask that you show me some examples of businesses 'doing it
> right'.
You mean with Websites that work well in mobile devices? If you can't
find any (I think you can find at least one), that only indicates mass
incompetence on the Web, which is not news.
>
> Since you can't provide any, I submit that your 'way' is wrong.
So, your proof is that because I don't know what you are talking about
and _you_ can't seem to find whatever it is you are trying to
describe, my "way" is wrong. I can't see it.
>
>
>
> > > (A simple web page that renders some controls won't cut it - I mean
> > > something that is used and works in a real business scenario. I bet
> > > you can't.)
>
> > Controls? Real business scenario? Google's pages are about as bare
> > bones as they come (in terms of content).
>
> As bare bones as their front page is, the engineers at google still
> decided to make a seperate mobile homepage.
I know! :)
>
> Haven't you heard of gmail, google news, etc they all have plenty of
> content and seperate mobile and desktop front ends - to meet different
> requirements. Why do you find it so hard to understand?
So your proof is to endlessly trumpet Google properties (GMail!) as if
they were good examples. I find that very hard to understand (though
I hear such "arguments" once a week at least). Mass hysteria,
perhaps? Google's properties are uniformly awful. How do you not
understand that?
>
> > Are you saying their pages
> > couldn't work equally well in the majority of mobile devices released
> > this century?
>
> Yes, they lack the resolution, and sometimes the bandwidth.
I said _could_ work (if they were competently designed). It's not the
devices that are lacking.
As for bandwidth, how much bandwidth do you think competent versions
of Google's pages would need?
>
> Here's some more for you:
>
> Wikipedia.org (Hardly bloated, yet they recognise the need for a cut
> down mobile front end)
I don't know what they recognized. Note the tense.
> Digg.com
Bloated beyond belief, IIRC.
> Slashdot.org
Who?
>
> In fact all the main news/social websites have mobile front ends.
And when were those sites designed and implemented?
>
> I guess you know better, eh?
You don't seem to grasp the concept of time. Yes, I _knew_ better
than whomever built the "main" news/social websites. Virtually all of
the major news sites are disasters full of popup ads, Flash, script
errors, etc. These are your examples? Are you saying _you_ don't
know any better than the anonymous clods who fouled up - for example -
ESPN's sites? I don't think I can think of one major news site that
isn't cringe-worthy and exasperating to use. And yeah, that hurts
their business. I, for one, avoid such sites like the plague.
As for the major social sites. Most use jQuery or YUI IIRC. Copy
past mistakes at your own risk.
>
>
>
>
>
> > > > > Like I said before, in the Real World, deliverables come before
> > > > > ideologies.
>
> > > > The "Real World" is what neophytes bring up when painted into a
> > > > corner. Do you think you can delivery anything (reliable) with jQuery
> > > > than I can without it? If so, you are living in a fantasy world. ;)
>
> > > Non sequitur. You really do have trouble concentrating
>
> > You really do have trouble staying on topic.
>
> > > , nowhere did I
> > > make any such claim.
>
> > Then what is your big "Real World" claim? Oh, that you can deliver
> > something that doesn't really work and ignore the reasons why. Good
> > luck with that!
>
> My claim is that the standards need fixed - at least for the file
> upload control.
There's no standard that says inputs must reflect style changes.
>
> This is why people are resorting to abortions - like flash. Because
> like it or not, money makes the world go round and business
> requirements always trump a technically elegant solution.
Abominations? So, people are resorting to Flash to do what? To make
the world go around?
And what is the business requirement that mandates the use Flash with
no recourse? I'm having trouble following this latest argument.
Mark Smith
> > Their developers probably have many thousands of years experience
> > between them.
>
> > If they could make the user experience better by cutting back the
> > front end - and make more money, they would.
>
> As in the future? Who knows what they will do. The sites you refer
> to were clearly designed and implemented years ago.
>
> > The sarcasm was that you
> > knew better than them.
>
> So you really are trumpeting Google, eBay, etc. as good examples. Ask
> their users about that. And it's a non-argument anyway.
You think the way to satisy users is to cripple the web page by coding
for the lowest common denominator. Ha. Good luck with that!
> > You failed to provide any counter examples, as I expected ;)
>
> Any counter examples of what? ISTM you asked for an example of a site
> that was "actually used" for a "real business scenario" and could
> possibly work on some mobile device(s)? Can you be more specific?
>
Anything really, something with a large user base to give it
credibility.
If your way is so good there must be some examples in use out there...
> > > > Mobile users have different requirements to desktop users.
>
> > > Exactly. So leave the input styles alone.
>
> > You are saying we should design every page as if it was for a mobile
> > device.
>
> Nope. Neither am I saying you should design pages as if they were for
> desktop PC's with huge monitors, maximized browsers, etc.
>
I agree, but if a page is complex enough that it needs a larger window
increases usability then it's not an unreasonable prerequisite - if
you provide an alternative customised for mobile users.
>
>
> > This inherently limits functionality - notably mobile users have
> > limited bandwidth and screen space.
>
> All sorts of users have limited bandwidth. Low bandwidth does not
> inherently limit functionality in Web pages (unless you use 100K of
> script where 10K would do, fail to use progressive enhancement, etc.).
>
No but as a general rule, desktop users have more bandwidth, you can
therefore serve them richer content.
> And how much bandwidth do you think it takes to produce Google's pages
> (if they were designed competently).
>
Not much, but the google homepage is obviously designed for a desktop
user. (The toolbar at the top, that produces drop downs on mouse over
etc)
Their mobile front end is much more basic, smaller images, and focuses
on lists of items.
Sure, they could replace it with one that functions adequatley on both
platforms. But as a competent business they want to target their users
and provide the best experience on each device.
>
>
> > > > Show me a site with as much functionality as eBay or Amazon, that
> > > > looks good and works from desktop and mobile platforms.
>
> > > As much functionality as eBay and Amazon? What does that mean?
> > > Perhaps you mean as unnecessarily bloated and poorly laid out as those
> > > two? That won't work. That's why they ended up with two sites. ;)
>
> > If they could have one site to do it all and/or better, they would do
> > it, out of pure self interest.
>
> There you go again. Your examples are from the past. How do you know
> what these companies will produce in the future?
That's your argument, that maybe these companies will do it your way
in the future?! Haha. That's not very compelling.
>
>
> > Again, I ask that you show me some examples of businesses 'doing it
> > right'.
>
> You mean with Websites that work well in mobile devices? If you can't
> find any (I think you can find at least one), that only indicates mass
> incompetence on the Web, which is not news.
>
There are plenty of web sites designed for mobile, see my examples.
Sure there are even some very basic web pages that render adequatley
on desktops and mobile devices.
For a business that wants to target it's users and provide the best
possible interface for their platform, it's best to keep them
seperate.
Your excuses for not providing any counterexamples are becoming quite
comical!
>
>
> > Since you can't provide any, I submit that your 'way' is wrong.
>
> So, your proof is that because I don't know what you are talking about
> and _you_ can't seem to find whatever it is you are trying to
> describe, my "way" is wrong. I can't see it.
>
You're the one that can't cite any successful websites that use only
lukewarm barely styled pages in order to look, just OK on every
conceivable device.
> > > Are you saying their pages
> > > couldn't work equally well in the majority of mobile devices released
> > > this century?
>
> > Yes, they lack the resolution, and sometimes the bandwidth.
>
> I said _could_ work (if they were competently designed). It's not the
> devices that are lacking.
>
> As for bandwidth, how much bandwidth do you think competent versions
> of Google's pages would need?
>
That would depend entirely on the requirements. (Both frontend and
backend).
I'm damn sure google know what they need, and how to do it better than
you.
>
> You don't seem to grasp the concept of time. Yes, I _knew_ better
> than whomever built the "main" news/social websites.
Hahahaha. Bravo. You're a genius. Ahead of your time. Well done!
>
>
>
> > This is why people are resorting to abortions - like flash. Because
> > like it or not, money makes the world go round and business
> > requirements always trump a technically elegant solution.
>
> Abominations? So, people are resorting to Flash to do what? To make
> the world go around?
It's widely used to deliver embedded video and games. Obviously mobile
support is limited (another reason to keep it seperate).
I would have thought you would know this. (Being smarter than the
engineers at all the other web companies and all...)
In the context of this discussion, Flash could be used to work around
the shortcomings of the file input element.
>
> And what is the business requirement that mandates the use Flash with
> no recourse? I'm having trouble following this latest argument.
No need to mandate, if done right it should degrade gracefully.
FWIW I don't like flash either, these are just the reasons it is used.
David Mark
wrote:
> On Dec 9, 3:07 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Their developers probably have many thousands of years experience
> > > between them.
>
> > > If they could make the user experience better by cutting back the
> > > front end - and make more money, they would.
>
> > As in the future? Who knows what they will do. The sites you refer
> > to were clearly designed and implemented years ago.
>
> > > The sarcasm was that you
> > > knew better than them.
>
> > So you really are trumpeting Google, eBay, etc. as good examples. Ask
> > their users about that. And it's a non-argument anyway.
>
> You think the way to satisy users is to cripple the web page by coding
> for the lowest common denominator.
No. The last thing I would call my clients' sites is crippled. Oddly
enough, they work on mobile devices too. ;)
> Ha. Good luck with that!
You are not me. :)
>
> > > You failed to provide any counter examples, as I expected ;)
>
> > Any counter examples of what? ISTM you asked for an example of a site
> > that was "actually used" for a "real business scenario" and could
> > possibly work on some mobile device(s)? Can you be more specific?
>
> Anything really, something with a large user base to give it
> credibility.
A large user base doesn't imply credible Web design. I already
answered this question: most Web developers are incompetent, so
looking for good examples can be time-consuming (and whether found or
not, it doesn't change what is good practice). Good luck in your
quest to find a decent site with a large user base.
>
> If your way is so good there must be some examples in use out there...
I'm sure there are and they are definitely not the norm. See above
concerning the current state of the Web.
>
> > > > > Mobile users have different requirements to desktop users.
>
> > > > Exactly. So leave the input styles alone.
>
> > > You are saying we should design every page as if it was for a mobile
> > > device.
>
> > Nope. Neither am I saying you should design pages as if they were for
> > desktop PC's with huge monitors, maximized browsers, etc.
>
> I agree, but if a page is complex enough that it needs a larger window
> increases usability then it's not an unreasonable prerequisite - if
> you provide an alternative customised for mobile users.
Or if you know what you are doing. ;)
>
>
>
> > > This inherently limits functionality - notably mobile users have
> > > limited bandwidth and screen space.
>
> > All sorts of users have limited bandwidth. Low bandwidth does not
> > inherently limit functionality in Web pages (unless you use 100K of
> > script where 10K would do, fail to use progressive enhancement, etc.).
>
> No but as a general rule, desktop users have more bandwidth, you can
> therefore serve them richer content.
So? What does that have to do with a "real business scenario" like
Google's home page?
>
> > And how much bandwidth do you think it takes to produce Google's pages
> > (if they were designed competently).
>
> Not much, but the google homepage is obviously designed for a desktop
> user.
I don't think it was so much designed as spat out.
> (The toolbar at the top, that produces drop downs on mouse over
> etc)
What about them? If the site is unusable without the JS menus, it's
broken for a lot more than phones.
>
> Their mobile front end is much more basic, smaller images, and focuses
> on lists of items.
Smaller images? On the Google home page? And focusing on "lists of
items" seems an odd strategy for their home page. Try it with an
iPhone or the like. I imagine it looks like an old WAP-style site.
See what I mean about focusing on the past? Mobile devices have
evolved. And they could present a WAP-like interface to older phones
that need it by including a handheld style sheet.
>
> Sure, they could replace it with one that functions adequatley on both
> platforms.
I'm sure they could replace it with one that works stunningly on "both
platforms". It's been done, trust me.
> But as a competent business they want to target their users
> and provide the best experience on each device.
It is incompetent to maintain two pages where one would suffice. For
Google's home page, it is clear that one would suffice.
>
>
>
> > > > > Show me a site with as much functionality as eBay or Amazon, that
> > > > > looks good and works from desktop and mobile platforms.
>
> > > > As much functionality as eBay and Amazon? What does that mean?
> > > > Perhaps you mean as unnecessarily bloated and poorly laid out as those
> > > > two? That won't work. That's why they ended up with two sites. ;)
>
> > > If they could have one site to do it all and/or better, they would do
> > > it, out of pure self interest.
>
> > There you go again. Your examples are from the past. How do you know
> > what these companies will produce in the future?
>
> That's your argument, that maybe these companies will do it your way
> in the future?! Haha. That's not very compelling.
No. My argument has never been based on what Google (or anyone else)
has done, is doing or will do. Quite the opposite.
I do disagree with your use of name-dropping for your arguments (and
your odd interpretations of mine).
>
>
>
> > > Again, I ask that you show me some examples of businesses 'doing it
> > > right'.
>
> > You mean with Websites that work well in mobile devices? If you can't
> > find any (I think you can find at least one), that only indicates mass
> > incompetence on the Web, which is not news.
>
> There are plenty of web sites designed for mobile, see my examples.
Again. Go back and re-read.
> Sure there are even some very basic web pages that render adequatley
> on desktops and mobile devices.
Your qualification of "very basic" is off IMO. What do you consider
very basic? The Google home page was your example of one that needed
to be split up.
>
> For a business that wants to target it's users and provide the best
> possible interface for their platform, it's best to keep them
> seperate.
You are starting to repeat yourself.
>
> Your excuses for not providing any counterexamples are becoming quite
> comical!
I think you know right where you can find one. If not, it doesn't
affect my position at all. I know it affects your position as you
don't think anything is good unless you see a huge site using it.
>
>
>
> > > Since you can't provide any, I submit that your 'way' is wrong.
>
> > So, your proof is that because I don't know what you are talking about
> > and _you_ can't seem to find whatever it is you are trying to
> > describe, my "way" is wrong. I can't see it.
>
> You're the one that can't cite any successful websites that use only
> lukewarm barely styled pages in order to look, just OK on every
> conceivable device.
Who said anything about lukewarm or "barely styled" pages?
>
> > > > Are you saying their pages
> > > > couldn't work equally well in the majority of mobile devices released
> > > > this century?
>
> > > Yes, they lack the resolution, and sometimes the bandwidth.
>
> > I said _could_ work (if they were competently designed). It's not the
> > devices that are lacking.
>
> > As for bandwidth, how much bandwidth do you think competent versions
> > of Google's pages would need?
>
> That would depend entirely on the requirements. (Both frontend and
> backend).
You are just blithering now. :(
>
> I'm damn sure google know what they need, and how to do it better than
> you.
You seem sure that Google knew what they needed years ago. You have
no idea what they might be thinking now (and no way to tell). See the
problem?
>
>
>
> > You don't seem to grasp the concept of time. Yes, I _knew_ better
> > than whomever built the "main" news/social websites.
>
> Hahahaha. Bravo. You're a genius. Ahead of your time. Well done!
Have you ever looked at those sites from a technical perspective? You
seem to think they are good examples. (?)
>
>
>
> > > This is why people are resorting to abortions - like flash. Because
> > > like it or not, money makes the world go round and business
> > > requirements always trump a technically elegant solution.
>
> > Abominations? So, people are resorting to Flash to do what? To make
> > the world go around?
>
> It's widely used to deliver embedded video and games. Obviously mobile
> support is limited (another reason to keep it seperate).
So are we talking about "real business scenarios" (e.g. Google's
pages) or video games?
>
> I would have thought you would know this.
You would have thought I would know you'd change your tack again?
Maybe I should have.
> (Being smarter than the
> engineers at all the other web companies and all...)
It is irritating that you keep putting your own bizarre spin on
everything I say. I don't know if it's a language barrier or you are
a child or what, but please go away.
>
> In the context of this discussion, Flash could be used to work around
> the shortcomings of the file input element.
We've been over that. Don't do it. It's stupid.
>
>
>
> > And what is the business requirement that mandates the use Flash with
> > no recourse? I'm having trouble following this latest argument.
>
> No need to mandate, if done right it should degrade gracefully.
Then you answered your own question.
>
> FWIW I don't like flash either, these are just the reasons it is used.
And why do I care why you think Flash is used? Away with you.
Mark Smith
> > > > You failed to provide any counter examples, as I expected ;)
>
> > > Any counter examples of what? ISTM you asked for an example of a site
> > > that was "actually used" for a "real business scenario" and could
> > > possibly work on some mobile device(s)? Can you be more specific?
>
> > Anything really, something with a large user base to give it
> > credibility.
>
> A large user base doesn't imply credible Web design.
No, but it would give your example credibility. But you obviously
haven't got any... watching you squirm like this and cop out of giving
any real world examples is funny ;)
> I already
> answered this question: most Web developers are incompetent, so
> looking for good examples can be time-consuming
A few posts back you said it should be easy - which is it??
> > > > This inherently limits functionality - notably mobile users have
> > > > limited bandwidth and screen space.
>
> > > All sorts of users have limited bandwidth. Low bandwidth does not
> > > inherently limit functionality in Web pages (unless you use 100K of
> > > script where 10K would do, fail to use progressive enhancement, etc.).
>
> > No but as a general rule, desktop users have more bandwidth, you can
> > therefore serve them richer content.
>
> So? What does that have to do with a "real business scenario" like
> Google's home page?
>
Some businesses need to deliver richer content to their customers. Not
all businesses are the same.
> > (The toolbar at the top, that produces drop downs on mouse over
> > etc)
>
> What about them? If the site is unusable without the JS menus, it's
> broken for a lot more than phones.
Google is not broken without javascript - it degrades very gracefully.
Idiot.
> > Sure, they could replace it with one that functions adequatley on both
> > platforms.
>
> I'm sure they could replace it with one that works stunningly on "both
> platforms". It's been done, trust me.
And where are these live mythical front ends that work 'stunningly' on
all platforms?? Put up or shut up.
>
> > But as a competent business they want to target their users
> > and provide the best experience on each device.
>
> It is incompetent to maintain two pages where one would suffice. For
> Google's home page, it is clear that one would suffice.
>
Exactly, "suffice". What do you not understand about "best experience
on each device"?
>
> > Sure there are even some very basic web pages that render adequatley
> > on desktops and mobile devices.
>
> Your qualification of "very basic" is off IMO. What do you consider
> very basic? The Google home page was your example of one that needed
> to be split up.
>
They split it up to deliver the BEST possible experience on each
device. Not because it couldn't be done any other way. You are acting
clinically retarded now.
> > For a business that wants to target it's users and provide the best
> > possible interface for their platform, it's best to keep them
> > seperate.
>
> You are starting to repeat yourself.
>
You started doing that a long time ago.
>
>
> > Your excuses for not providing any counterexamples are becoming quite
> > comical!
>
> I think you know right where you can find one.
So now it's easy again - make up your mind!
> If not, it doesn't
> affect my position at all.
You're spouting these claims - without any evidence to back it up.
It seriously effects your credability.
Mark Smith
> > > Abominations? So, people are resorting to Flash to do what? To make
> > > the world go around?
>
> > FWIW I don't like flash either, these are just the reasons it is used.
>
> And why do I care why you think Flash is used? Away with you.
You asked!
Retard.
Gregor Kofler
[ebay, Google, Amazon et. al.]
> Politics aside, they are highly popular successful cash generating web
> sites.
>
> Their developers probably have many thousands of years experience
> between them.
The user interface of ebay is a nightmare. Anything but intuitive,
ridden with rendering errors, inconsistent appearance, menus designed by
imbeciles. It's just that everyone flocks to ebay, because everyone else
does. And everyone does, because one has always done so - ebay was the
first (or one of the first with the best marketing) online auctioning
platform. It's the sheer number of possible customers, not their idiotic
user interface. (BTW: Their upload buttons look plain.)
Amazon? 2109 validity errors? What should any respectable web author
learn from that? Again it's not their pretty average user interface, but
their free shipping and competitive prices and customer generated
content, that makes them popular.
> If they could make the user experience better by cutting back the
> front end - and make more money, they would. The sarcasm was that you
> knew better than them.
Hey, Amazon got rid of table layout some time ago. For no apparent
reason, since their markup is still one of the - if not /the/ - worst on
this planet's face.
What was your point?
Gregor
dorayme
<76db11a9-4044-49d5...@k17g2000yqh.googlegroups.com>,
Mark Smith <marksm...@jungle-monkey.com> wrote:
It is rare to see such a nice long styled thread (a la pissing comp
style) in this usenet group! Passionate folk those JS boys!
--
dorayme
Harlan Messinger
> On Dec 7, 6:54 am, Stefan Weiss <krewech...@gmail.com> wrote:
>> On 07/12/09 11:50, Mark Smith wrote:
>>
>>> Oh, and for anyone else that is interested, I found an option 5. Ajax
>>> uploads seem to be triggerable from script:
>>> http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
>> Did you look at how this was actually implemented? Apart from requiring
>> above its buttons and links. I'd say this qualifies as
>>
>> | #3 Use some hacky CSS and overlays to style the file picker.
>
> Yes. Most Web developers (or "designers") want everything to look
> exactly the way they want it to look and never mind what the user
> agent thinks. CSS "resets", brittle hacks, anything goes if it makes
> it look exactly the same in IE, FF and Safari. It's backwards as the
> developers of the user agents probably had a good idea of what sort of
> default style would work best for inputs (buttons particularly).
>
Imagine if every song you downloaded were to impose its producer's own
conception of how music player controls should look on your music
player, or if the display of the volume control bar on your TV screen
depended on what channel or program you were watching. Perhaps a station
broadcasting a slasher film would want your volume control display to
look like it was dripping with blood. Wouldn't that be awesome? (being
ironic)
Branco
> David Mark wrote:
<snip>
> > Yes. Most Web developers (or "designers") want everything to look
> > exactly the way they want it to look and never mind what the user
> > agent thinks. CSS "resets", brittle hacks, anything goes if it makes
> > it look exactly the same in IE, FF and Safari. It's backwards as the
> > developers of the user agents probably had a good idea of what sort of
> > default style would work best for inputs (buttons particularly).
>
> Imagine if every song you downloaded were to impose its producer's own
> conception of how music player controls should look on your music
> player, or if the display of the volume control bar on your TV screen
> depended on what channel or program you were watching. Perhaps a station
> broadcasting a slasher film would want your volume control display to
> look like it was dripping with blood. Wouldn't that be awesome? (being
> ironic)
You are comparing apples to bananas. The media player where a movie or
music is played isn't part of the nature of that movie or music. On
the other side, the visual aspects of the page are the very nature of
web pages (duh...).
Arguing that web designers shouldn't try to change certain visual
aspects of the page (such as buttons) because these features were
conceived this way is the same as saying (using your examples) that
all music players should only use hand made accustic instruments, or
all movie makers should create silent and black and white pieces,
because that's how music and movies where originally conceived by pre-
historic musicians and movie pioneers of yore (being ironic, too).
IMHO, let the designer try it. If it doesn't work the masses will shy
away from that site and run like crazy to the sites where buttons look
like buttons and form fields are bare (ops, boarding sarcasm, here).
Best regards,
Branco.
The Natural Philosopher
> Imagine if every song you downloaded were to impose its producer's own
> conception of how music player controls should look on your music
> player, or if the display of the volume control bar on your TV screen
> depended on what channel or program you were watching.
Indeed. Then you would know you had an Apple Mac ;-)
Perhaps a station
> broadcasting a slasher film would want your volume control display to
> look like it was dripping with blood. Wouldn't that be awesome? (being
> ironic)
Just buy a mac..
Harlan Messinger
> Harlan Messinger wrote:
>> David Mark wrote:
> <snip>
>>> Yes. Most Web developers (or "designers") want everything to look
>>> exactly the way they want it to look and never mind what the user
>>> agent thinks. CSS "resets", brittle hacks, anything goes if it makes
>>> it look exactly the same in IE, FF and Safari. It's backwards as the
>>> developers of the user agents probably had a good idea of what sort of
>>> default style would work best for inputs (buttons particularly).
>> Imagine if every song you downloaded were to impose its producer's own
>> conception of how music player controls should look on your music
>> player, or if the display of the volume control bar on your TV screen
>> depended on what channel or program you were watching. Perhaps a station
>> broadcasting a slasher film would want your volume control display to
>> look like it was dripping with blood. Wouldn't that be awesome? (being
>> ironic)
> <snip>
>
> You are comparing apples to bananas. The media player where a movie or
> music is played isn't part of the nature of that movie or music.
Uploading a file to a server is just as much a generic UI function as is
setting the volume on a song you are listening to or fast-forwarding a
movie or changing the channel on a TV.
Mark Smith
I think the anology needs taken one step further to reflect where we
are currently with web standards.
Imagine if every song you downloaded sounded different on every type
of player - not how the musician intended. Wouldn't that be awesome? :)
dorayme
<915fbe3e-4d34-47eb...@v30g2000yqm.googlegroups.com>,
Mark Smith <marksm...@jungle-monkey.com> wrote:
> > Imagine if every song you downloaded were to impose its producer's own
> > conception of how music player controls should look on your music
> > player, or if the display of the volume control bar on your TV screen
> > depended on what channel or program you were watching. Perhaps a station
> > broadcasting a slasher film would want your volume control display to
> > look like it was dripping with blood. Wouldn't that be awesome? (being
> > ironic)
>
> I think the anology needs taken one step further to reflect where we
> are currently with web standards.
>
> Imagine if every song you downloaded sounded different on every type
> of player - not how the musician intended. Wouldn't that be awesome? :)
It would be wrong to take the analogy so far because all browsers need
to very good at delivering some constants like *what is being said about
what* (as well as other things like pictures). Only the actions of
webpage makers obscure this (eg. by making the main message hard to read
for some people).
It would be a bad browser, a naughty browser, a browser who would miss
out on dessert and sent to bed early, that break into a song to
rearrange it or made it any different to what it should be. As naughty
as it would for a browser to take it on itself to alter the order of the
words in the content of a P element, a particular song is a very
particular thing and not something to be trifled with. Please withdraw
your analogy. Now.
--
dorayme
Harlan Messinger
Music does sound different depending on the player and device. The music
coming out of my Treo sounds very different from the sound coming out of
my Toshiba Satellite's built-in speakers, and different again from the
sound that comes out of my Onkyo tuner through my five KLM speakers. In
addition, the sound coming out of my Onkyo can sound "multidimensional",
and I can apply MY choice of sound distribution, and the musicians can't
do a damn thing about it.
Mark Smith
Type of speaker, distribution, sound levels, post processing effects
etc are analogous to the screen type, browser zoom, window size
controls etc, i.e. they are under the user control and can override
the defaults (if they wish).
Playlist management and navigation controls are analogous to the
browser address bar, back forward and history, i.e. nothing to do with
the content provider.
Elements on a web page however are like the instruments in music.
Having css styles applied to some elements on some browsers but not
others is like having a cd player that (without being asked) replaces
all percussion instruments on a track with a crappy sounding keyboard
synthesiser! (It's a mess and the standards need fixed).
Harlan Messinger
Your notion that the same considerations apply uniformly to anything
that is part of the web page is flawed. Form controls are user interface
devices, regardless of the fact that they are on the page rather than
built into the browser, and therefore there are considerations that
apply to them independently of those that apply to lists and tables.
Mark Smith
I didn't start the analogy.
> Form controls are user interface
> devices, regardless of the fact that they are on the page rather than
> built into the browser, and therefore there are considerations that
> apply to them independently of those that apply to lists and tables.
If that's the case, the standards still need fixed to specify that it
is up to the agent.
Rather than this halfway house where we currently have elements that
are partly styled by css and partly by the browser. To make things
worse, which parts that CAN be styled are also different between
browsers.
Harlan Messinger
It can't be fixed to specify that because it already specifies that:
http://www.w3.org/TR/CSS21/conform.html#conformance
"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental."
Mark Smith
What ambiguity "User agents **may** apply CSS properties to these
elements"! How did that get interpretted as, user agents MAY apply
SOME but not necessarly ALL css properties?
So, the consensus here is that we should not be styling input
elements, why even 'experiment' with the feature?
The support is kind of, sort of there in most browsers. Most designers
will try and use it, look at the rest of the web.
Do you not think it would be better if the standard said - such
elements are NOT to be styled, or if they are to be styled at least
use ALL of the properties, rather than leave such a gaping hole for
both designers and users to get into trouble with?
I can't believe that that is the official line!
Harlan Messinger
How is it ambiguous? I can only think of one thing that it means. If I
invite you to a party and you ask me what you should wear, and I reply
that you can wear whatever you want, do you think the word "ambiguous"
correctly describes my response?
> How did that get interpretted as, user agents MAY apply
> SOME but not necessarly ALL css properties?
Since it doesn't say, "the agent must apply none or all", there is no
basis for not understanding it to be granting this leeway to the user agent.
> So, the consensus here is that we should not be styling input
> elements, why even 'experiment' with the feature?
I think a more accurate description of the consensus is that the
*inability* to style these elements in a given browser is not an
infringement of a God-given right, and might actually be reasonable.
> The support is kind of, sort of there in most browsers. Most designers
> will try and use it, look at the rest of the web.
>
> Do you not think it would be better if the standard said - such
> elements are NOT to be styled, or if they are to be styled at least
> use ALL of the properties, rather than leave such a gaping hole for
> both designers and users to get into trouble with?
>
> I can't believe that that is the official line!
If I invite you to a party, I'll be sure to tell you exactly what you
must wear, since I gather that you would consider me to be remarkably
wishy-washy otherwise.
Mark Smith
A party invitation and a technical specification are two entirely
different things.
>
> > How did that get interpretted as, user agents MAY apply
> > SOME but not necessarly ALL css properties?
>
> Since it doesn't say, "the agent must apply none or all", there is no
> basis for not understanding it to be granting this leeway to the user agent.
>
Exactly, since it doesn't say, all we can say is... it doesn't say!
Which is why things are such a mess.
Harlan Messinger
Stating the obvious fact that the things being compared in an analogy
are different doesn't defeat the analogy. EVERY analogy compares things
that are different in some way. Otherwise, the only valid analogy in the
world would be the trivial one that compares a thing to itself.
>>> How did that get interpretted as, user agents MAY apply
>>> SOME but not necessarly ALL css properties?
>> Since it doesn't say, "the agent must apply none or all", there is no
>> basis for not understanding it to be granting this leeway to the user agent.
>>
>
> Exactly, since it doesn't say, all we can say is... it doesn't say!
> Which is why things are such a mess.
It specifies very, very clearly that in the case of form controls the
user agent can do what it wants. What part of that are you finding unclear?
Mark Smith
The analogy is invalid because the standards of specificity are so
wildy different when writing a formal document and a party invitation.
>
> >>> How did that get interpretted as, user agents MAY apply
> >>> SOME but not necessarly ALL css properties?
> >> Since it doesn't say, "the agent must apply none or all", there is no
> >> basis for not understanding it to be granting this leeway to the user agent.
>
> > Exactly, since it doesn't say, all we can say is... it doesn't say!
> > Which is why things are such a mess.
>
> It specifies very, very clearly that in the case of form controls the
> user agent can do what it wants. What part of that are you finding unclear?
Crystal, I'm just saying it's a bad thing that it's left unspecified,
fair enough leave it optional. But not to say which attributes are
optional has lead to the mess. Do a google for "style input css" to
see what I mean.
Harlan Messinger
Why? Where did you get the idea that a specification can, or should,
only have mandatory provisions, or apply a given requirement in exactly
the same way to every single thing that the specification governs? You
are under the false impression that some sort of constraint exists
regarding what specifications may state.
>>>>> How did that get interpretted as, user agents MAY apply
>>>>> SOME but not necessarly ALL css properties?
>>>> Since it doesn't say, "the agent must apply none or all", there is no
>>>> basis for not understanding it to be granting this leeway to the user agent.
>>> Exactly, since it doesn't say, all we can say is... it doesn't say!
>>> Which is why things are such a mess.
>> It specifies very, very clearly that in the case of form controls the
>> user agent can do what it wants. What part of that are you finding unclear?
>
> Crystal, I'm just saying it's a bad thing that it's left unspecified,
> fair enough leave it optional. But not to say which attributes are
> optional has lead to the mess. Do a google for "style input css" to
> see what I mean.
It says user agents don't have to apply styles to form controls. So
don't expect user agents to apply styles to form controls. You can try
it if you want to, but don't rely on it happening. How is this a "mess"?
Mark Smith
"A specification is an explicit set of requirements to be satisfied by
a material, product, or service."
http://en.wikipedia.org/wiki/Specification_(technical_standard)
> >>>>> How did that get interpretted as, user agents MAY apply
> >>>>> SOME but not necessarly ALL css properties?
> >>>> Since it doesn't say, "the agent must apply none or all", there is no
> >>>> basis for not understanding it to be granting this leeway to the user agent.
> >>> Exactly, since it doesn't say, all we can say is... it doesn't say!
> >>> Which is why things are such a mess.
> >> It specifies very, very clearly that in the case of form controls the
> >> user agent can do what it wants. What part of that are you finding unclear?
>
> > Crystal, I'm just saying it's a bad thing that it's left unspecified,
> > fair enough leave it optional. But not to say which attributes are
> > optional has lead to the mess. Do a google for "style input css" to
> > see what I mean.
>
> It says user agents don't have to apply styles to form controls. So
> don't expect user agents to apply styles to form controls. You can try
> it if you want to, but don't rely on it happening. How is this a "mess"?
Because dum dum, it's there so expect designers to *try* and use it.
And expect it to break because it's not defined *explicitly* how a
browser should handle it in the spec.
Harlan Messinger
Ignoring the fact that Wikipedia is not the master specification for how
everything in the world works, this does not mean that a specification
can only contain *absolutely required provisions*. A specification
specifies how a system is supposed to work. That includes specifying
what aspects must be chosen from among a set of options, and which items
are optional altogether (while possibly stating that, if they ARE used,
they must be used in such-and-such a way).
>>>>>>> How did that get interpretted as, user agents MAY apply
>>>>>>> SOME but not necessarly ALL css properties?
>>>>>> Since it doesn't say, "the agent must apply none or all", there is no
>>>>>> basis for not understanding it to be granting this leeway to the user agent.
>>>>> Exactly, since it doesn't say, all we can say is... it doesn't say!
>>>>> Which is why things are such a mess.
>>>> It specifies very, very clearly that in the case of form controls the
>>>> user agent can do what it wants. What part of that are you finding unclear?
>>> Crystal, I'm just saying it's a bad thing that it's left unspecified,
>>> fair enough leave it optional. But not to say which attributes are
>>> optional has lead to the mess. Do a google for "style input css" to
>>> see what I mean.
>> It says user agents don't have to apply styles to form controls. So
>> don't expect user agents to apply styles to form controls. You can try
>> it if you want to, but don't rely on it happening. How is this a "mess"?
>
> Because dum dum,
<plonk/>
Mark Smith
Just because something can be done, does not imply that it *should* be
done.
Leaving it open like that has manifested itself in many problems, most
of which are covered in this thread.
dorayme
<ed668f6f-218a-4781...@g23g2000vbr.googlegroups.com>,
Mark Smith <marksm...@jungle-monkey.com> wrote:
You should stop quoting so much stuff that no one will read, not even
Harlan...
--
dorayme
Jonathan N. Little
Harlan Messinger
dorayme
Harlan Messinger <hmessinger...@comcast.net> wrote:
Well, perhaps he did but he did respond once afterwards, so he certainly
did not think you were *deadly* serious.
--
dorayme
GTalbot
> I've been spending the last day trying to prettify the file inputs on
> some forms.
>
> CSS support is almost not existent for file inputs on all the major
> browsers.
Maybe, just maybe, a file input control should look like a default
file input control on a platform so that users can always find,
recognize, notice a standard file input control looking like a
default, standard file input control. Maybe the unstylable state of
file input controls exist for security reasons.
Not pretty for you but reliable, efficient for the users of the
webpage.
> So I decided to hide the ugly standard file input control and wrap
> some javascript around some styleable buttons and input text boxes to
> drive the actual file input.
>
> This works in IE6, IE7 and Safari but unfortunately not Firefox.
Does it? What if the user unchecks the checkbox "Enable visual styles
on buttons and controls in webpages"?
> After a bit of googling it looks like my options are:
>
> #1 Use flash. (Not a desirable dependancy)
> #2 Drop support for FF. (Can't do that)
> #3 Use some hacky CSS and overlays to style the file picker:http://www.quirksmode.org/dom/inputfile.html
> #4 Do some browser detection, hide with JS if I can, FF users have to
> live with the normal ugly ass control.
>
> I'm leaning towards options 3 or 4 right now, unless anyone else has
> better suggestions?
Maybe your option #0 is best for users and for you: do nothing about
the style of a file input control. Efficient. Reliable.
Gérard