On Tue, Mar 13, 2012 at 01:37:24AM -0400, Nick Sabalausky wrote: [...]
> Yea, there's a lot of things that are much better done in CSS that a lot of people don't even know about. For example, most rollovers are easily doable in pure CSS. But there's a lot stuff out there (paricularly things created in Adobe's "software") that use JS for rollovers, which doesn't even work as well (even with JS on).

Ugh. Don't get me started on Adobe. I don't know what they do to their programmers, but obviously UI design is not part of their staff training. Have you seen acrobat reader's UI? It's utterly atrocious. Completely counterintuitive, and an embarrassment to modern UI design. And that's their product line. Don't even mention their website.


> OTOH, I don't like CSS drop-down menus. Maybe it's different in CSS3, but in CSS2 the only way to make CSS menus work is for them to open upon rollover, not click. And dropdown menus opening upon rollover is just a usability mess, IMO, *and* inconsistent with pretty much any GUI OS I've ever used.
[...]

Hmm. I rather *like* CSS drop-down menus, actually. At least, it's *way* better than those annoying badly-written bloated JS menus. Though if it's not done properly, it can be an utter annoyance. E.g., if the menu is separated from the element that triggers it by a gap of several pixels... then it's almost impossible to actually use it. (This happens to me a lot 'cos I fiddle with default font size settings. Which lets me see the pervasiveness of broken pixel-dependent CSS in all its glory. OK, I better stop now, 'cos static vs. fluid layouts are another of my pet peeves... this thread will never end if I keep going.)


T

-- 
Amateurs built the Ark; professionals built the Titanic.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.601.1331619011.4860.digitalmars-d@puremagic.com...
> On Tue, Mar 13, 2012 at 01:37:24AM -0400, Nick Sabalausky wrote: [...]
>> Yea, there's a lot of things that are much better done in CSS that a lot of people don't even know about. For example, most rollovers are easily doable in pure CSS. But there's a lot stuff out there (paricularly things created in Adobe's "software") that use JS for rollovers, which doesn't even work as well (even with JS on).
>
> Ugh. Don't get me started on Adobe. I don't know what they do to their programmers, but obviously UI design is not part of their staff training. Have you seen acrobat reader's UI? It's utterly atrocious. Completely counterintuitive, and an embarrassment to modern UI design. And that's their product line. Don't even mention their website.
>

Yea, I have a *very* low opinion of Adobe's products in general. They can barely get anything right, and that's on top of their sky-high prices. Each CS is more absurdly bloated than the last, and uses weirder and weirder skins, and Adobe clearly has zero understanding of security. I don't "hate" Adobe like I hate some other companies, but I consider their output to mostly be garbage and I hate dealing with their products (and documentation).

It's a shame they no longer have *really good* competition, like Paint Shop Pro which used to compete toe-to-toe with Photoshop and at a much lower price (until Corel bought it and drive it straight into the ground along with the rest of Corel's products). I use GIMP, but it's uhh...kind of a "gimpy" program (aptly-named).

Have you heared of the Corona SDK? It's not technically made by Adobe but...I'll put it this way: Corona does intially come across as fairly slick. But then you compare it to one of their competitors, Marmalade SDK, and despite Marmalade's lack of "slickness", you quickly realize that Marmalade was made by and for grownups, while Corona...is basically just an overpriced toy in grown-ups clothing. *After* I came to that conclusion, I discovered the company which makes Corona, surprise surprise, was founded by former higher-ups from Adobe's Flash dept. Go figure. Flash, which can *also* be accurately described as "an overpriced toy in grown-ups clothing".

On 03/13/2012 02:14 AM, H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:
>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
>> news:mailman.572.1331601463.4860.digitalmars-d@puremagic.com...
> [...]
>>> All I'm saying is that if it makes sense for the web developer to
>>> use javascript given what they're trying to do, it's completely
>>> reasonable to expect that their users will have javascript enabled
>>> (since virtually everyone does). If there's a better tool for the
>>> job which is reasonably supported, then all the better. And if it's
>>> easy to provide a workaround for the lack of JS at minimal effort,
>>> then great. But given the fact that only a very small percentage of
>>> your user base is going to have JS disabled, it's not unreasonable
>>> to require it and not worry about the people who disable it if
>>> that's what you want to do.
>>>
>>
>> Personally, I disagree with the notion that non-JS versions are a
>> "workaround".
> [...]
>
> Me too. To me, non-JS versions are the *baseline*, and JS versions are
> enchancements. To treat JS versions as baseline and non-JS versions as
> "workaround" is just so completely backwards.

While I don't agree that non-JS is the baseline (because most if not all browsers come with JS enabled by default, so why would you want to disable javascript for?), I'm starting to understand that providing both non-JS and JS versions is useful.

At least so that:
 - Some users don't go mad when they can't use it, and then realise it's because JS is disabled
 - And for the above reason, not to loose reputation to those people :-P

But if people didn't have an option to disable JS, we wouldn't have this discussion. I think it as having an option to disable CSS.

(I was going to put as an argument that my cellphone didn't have an option to disable JS, but it does... hmmmmmmmmmmmmmmmm... :-P)

On 03/13/2012 01:52 AM, Nick Sabalausky wrote:
> "Ary Manzana"<ary@esperanto.org.ar>  wrote in message
> news:jjmhja$3a$2@digitalmars.com...
>> On 03/12/2012 10:58 PM, H. S. Teoh wrote:
>>>
>>> The problem today is that JS is the "next cool thing", so everyone is
>>> jumping on the bandwagon, and everything from a single-page personal
>>> website to a list of links to the latest toaster oven requires JS to
>>> work, even when it's not necessary at all. That's the silliness of it
>>> all.
>>>
>>>
>>> T
>>
>> It's not the next cool thing. It makes thing more understandable for the
>> user. And it makes the web transfer less content,
>
> That gets constantly echoed throughout the web, but it's a red herring: Even
> if you handle it intelligently like Adam does (ie, lightweight), the amount
> of data transfer saved is trivial. We're talking *part* of *one* measly HTML
> file here. And even that can be gzipped: HTML compresses *very* well. Yes,
> techincally it can be less transfer, but only negligably so. And bandwith is
> the *only* possible realistic improvement here, not speed, because the speed
> of even a few extra K during a transfer that was already going to happen
> anyway is easily outweighed by the overhead of things like actually making a
> round-trip to the server at all, plus likely querying a server-side DB, plus
> interpreting JS, etc.
>
> If, OTOH you handle it like most people do, and not like Adam does, then for
> brief visits you can actually be tranferring *more* data just because of all
> that excess JS boilerplate people like to use. (And then there's the
> start-up cost of actually parsing all that boilerplate and then executing
> their initialization portions. And in many cases there's even external JS
> getting loaded in, etc.)
>
> The problem with optimization is that it's not a clear-cut thing: If you're
> not looking at it holistically, optimizing one thing can either be an
> effective no-op or even cause a larger de-optimization somewhere else. So
> just because you've achived the popular goal of "less data transer" upon
> your user clicking a certain link, doesn't necessarily mean you've won a net
> gain, or even broken even.

True.

I always have to remember this interesting talk about saying "This is faster than this" without a scientific proof:

http://vimeo.com/9270320

On Tuesday, 13 March 2012 at 12:22:00 UTC, Ary Manzana wrote:
> But if people didn't have an option to disable JS, we wouldn't have this discussion. I think it as having an option to disable CSS.

You can disable css :P

Keeping your site working without css is a lot harder IMO
than doing the same without javascript. I often assume
display: none; will work to hide unnecessary things.

Sometimes, doing simple things with css is a bit hard too.

For example, one easy way to make a site still work without
css is to put your content at the top of the HTML page,
with  as few as possible distractions in the process.

Oh yeah, and of course, always use the proper semantic
tags, which you should do anyway. Descriptive tags
help css too!

Anyway, so, you put the navigation menus, etc., at the
bottom of the html file.


Here's the problem though: you want those menus to show
up at the top for people with css. And that is incredibly
hard to get right currently. (I think css3 will make it
easier, but IE10 is the only browser to properly support
the needed features last I checked, and IE10 has 0% market.)


But with css2, you can't float to the top.... you can't
display: table to the top.

The best you can do is position: absolute, which can get
you trapped in the document tree and is just generally
a pain in the butt - you have to break the natural flow.


I often just say gah to it and either minimize those
things so it isn't too big of a hassle anyway, or put
a display: none #content link at the top.

(The only people who go without css in my experience are
lynx users anyway, so making it easier to scroll past the
crap is the important thing.)




Now, here's one case I never think about: what about if
JS is enabled, and CSS is not? Now that would be weird.

Probably usable but just really weird.

On Tuesday, 13 March 2012 at 05:38:44 UTC, Nick Sabalausky wrote:
> OTOH, I don't like CSS drop-down menus. Maybe it's different in CSS3, but in CSS2 the only way to make CSS menus work is for them
> to open  upon rollover, not click.

Yeah, the way I do it is with a hybrid approach:

menu.onclick = function() { toggleClass(this, "opened"); };

.with-js menu > ul {
   display: none;
   /* or if you want it to roll, use the transition */
}

.with-js menu.open > ul {
   display: block;
}


and there you go. If you ask me, most your javascripts
should be changing classes, not actually doing the
work itself. That way, you keep the clean separation -
the class just represents the current state.

(indeed, with-js is another toggled class; put a little
script in the head that adds it to the html element.)



One downside of the css3 animations though is that
doing it without fixed height kinda sucks.

I wanted a quick foldout of something for the work
site. The simple height: 0px then open means
height: auto didn't work - you can't animate
to height: auto. Which sucks and they should
fix that, but apparently Apple's developers are
too incompetent to implement it in Safari, so
it gets left out of the standard. Or something
like that. I hate the standard, the process is
biased bullshit.


Anyway, to make it work, I ended up doing this:

/* overflow: hidden rox btw, use it a lot, you'll
thank me later */
max-height: 0px; overflow: hidden; transition: max-height 0.2s;

.open { max-height: 20em; }



Which gives the effect.. but the animation is from the
numbers given, not the actual height.

So, if you say max-height: 200em for instance, and
your content is only 20em tall, the visible animation
will complete in 0.02 seconds instead of 0.2!


Thus, I decided to pick an approximately right,
and call the animation time good enough.

The problem is now though: what if you add an item
to the drop down? If you don't remember to adjust
max-height too.... the new thing is just hidden.


Gah, the css is now dependent on the specific
content!



But, you don't always have to do this stuff
(BTW if anyone knows a better technique, let
me know!), and even so, it beats the crap
out of javascript animations.

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjne58$1ouf$1@digitalmars.com...
> On 03/13/2012 02:14 AM, H. S. Teoh wrote:
>> On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:
>>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message news:mailman.572.1331601463.4860.digitalmars-d@puremagic.com...
>> [...]
>>>> All I'm saying is that if it makes sense for the web developer to use javascript given what they're trying to do, it's completely reasonable to expect that their users will have javascript enabled (since virtually everyone does). If there's a better tool for the job which is reasonably supported, then all the better. And if it's easy to provide a workaround for the lack of JS at minimal effort, then great. But given the fact that only a very small percentage of your user base is going to have JS disabled, it's not unreasonable to require it and not worry about the people who disable it if that's what you want to do.
>>>>
>>>
>>> Personally, I disagree with the notion that non-JS versions are a "workaround".
>> [...]
>>
>> Me too. To me, non-JS versions are the *baseline*, and JS versions are enchancements. To treat JS versions as baseline and non-JS versions as "workaround" is just so completely backwards.
>
> While I don't agree that non-JS is the baseline (because most if not all browsers come with JS enabled by default, so why would you want to disable javascript for?), I'm starting to understand that providing both non-JS and JS versions is useful.
>
> At least so that:
>  - Some users don't go mad when they can't use it, and then realise it's
> because JS is disabled
>  - And for the above reason, not to loose reputation to those people :-P
>
> But if people didn't have an option to disable JS, we wouldn't have this discussion.[...]
>

Bullcrap. If people didn't have an option to disable JS, there'd be a lot more people using *very* *VERY* old browsers, and that would piss of *cough*modern*cough* webdevs even more.

The problem isn't that JS *can* be disabled. Some people *just don't want it*:

When they disable JS, yea, ok, on *some* sites they get a *slighty worse* user experience with, say, posting a comment. But it *also* gives them a *far BETTER* user experience on all those sites that misuse and overuse JS. It also increases security. The idea that JS-enabled pages are "just simply better" is patently false: Yes, *some* are *slightly* better, but many are *much* worse (no matter how good their respective developers believe themselves to be. *Everyone* believes "Oh, well, when *I* use it, it works very well." I'm sure the Reddit developers have fooled themselves into thinking their site is reasonably fast).

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjne58$1ouf$1@digitalmars.com...
>
> But if people didn't have an option to disable JS, we wouldn't have this discussion. I think it as having an option to disable CSS.
>

That's not even an accurate comparison anyway. Disabling CSS never does much to improve things, and usually it'll just make things *far* worse. People don't fuck up CSS nearly to the extent that they fuck up JS. Hell, CSS *can't* be fucked up as badly as JS can be. The "no JS == no CSS" comparison is like saying "Disabling JS is like disabling vowels". No, no it isn't like that. Not remotely.

"Nick Sabalausky" <a@a.a> wrote in message news:jjo65v$305$1@digitalmars.com...
> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjne58$1ouf$1@digitalmars.com...
>> On 03/13/2012 02:14 AM, H. S. Teoh wrote:
>>> On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:
>>>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message news:mailman.572.1331601463.4860.digitalmars-d@puremagic.com...
>>> [...]
>>>>> All I'm saying is that if it makes sense for the web developer to use javascript given what they're trying to do, it's completely reasonable to expect that their users will have javascript enabled (since virtually everyone does). If there's a better tool for the job which is reasonably supported, then all the better. And if it's easy to provide a workaround for the lack of JS at minimal effort, then great. But given the fact that only a very small percentage of your user base is going to have JS disabled, it's not unreasonable to require it and not worry about the people who disable it if that's what you want to do.
>>>>>
>>>>
>>>> Personally, I disagree with the notion that non-JS versions are a "workaround".
>>> [...]
>>>
>>> Me too. To me, non-JS versions are the *baseline*, and JS versions are enchancements. To treat JS versions as baseline and non-JS versions as "workaround" is just so completely backwards.
>>
>> While I don't agree that non-JS is the baseline (because most if not all browsers come with JS enabled by default, so why would you want to disable javascript for?), I'm starting to understand that providing both non-JS and JS versions is useful.
>>
>> At least so that:
>>  - Some users don't go mad when they can't use it, and then realise it's
>> because JS is disabled
>>  - And for the above reason, not to loose reputation to those people :-P
>>
>> But if people didn't have an option to disable JS, we wouldn't have this discussion.[...]
>>
>
> Bullcrap. If people didn't have an option to disable JS, there'd be a lot more people using *very* *VERY* old browsers, and that would piss of *cough*modern*cough* webdevs even more.
>
> The problem isn't that JS *can* be disabled. Some people *just don't want it*:
>
> When they disable JS, yea, ok, on *some* sites they get a *slighty worse* user experience with, say, posting a comment. But it *also* gives them a *far BETTER* user experience on all those sites that misuse and overuse JS. It also increases security.

Oh, and with JS disabled, it's impossible for sites *cough*GitHub*cough* to break the back button.

>The idea that JS-enabled pages are "just simply better" is patently false: Yes, *some* are *slightly* better, but many are *much* worse (no matter how good their respective developers believe themselves to be. *Everyone* believes "Oh, well, when *I* use it, it works very well." I'm sure the Reddit developers have fooled themselves into thinking their site is reasonably fast).
>
> 

"Nick Sabalausky" <a@a.a> wrote in message news:jjmmh3$9jb$1@digitalmars.com...
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:oxkxtvkuybdommyerrke@forum.dlang.org...
>> On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:
>>> 2. On the web, animation means JS.
>>
>> css3 does animations that are pretty easy to use,
>> degrade well, and tend to be fast. Moreover css
>> is where it belongs anyway - it is pure presentation.
>>
>
> Interesting, I had no idea! Thanks for the tip :)
>
>> Far, far superior to the JS crap.
>>
>
> Yea, there's a lot of things that are much better done in CSS that a lot of people don't even know about. For example, most rollovers are easily doable in pure CSS. But there's a lot stuff out there (paricularly things created in Adobe's "software") that use JS for rollovers, which doesn't even work as well (even with JS on).
>

Another thing is Flash. Almost *everyone* uses JS to embed flash. But *it's not needed*! I embed Flash with pure HTML and it works perfectly fine. Don't even need any server-side code! (You probably need JS to tell the user when they don't have Flash or, in some cases, when they don't have a new enough version, and suggest a download link. But including those features with JS still does *nothing* to prevent you from making the applet run without JS. And...It's not even a fallback! It's just embedding with method A instead of method B. And method A is, frankly, dead-simple.)