"BCS" <ao@pathlink.com> wrote in message news:78ccfa2d329128caebdfa6344eba@news.digitalmars.com...
> Reply to Nick,
>
>> "BCS" <ao@pathlink.com> wrote in message news:78ccfa2d3290a8caebd75c21451a@news.digitalmars.com...
>>
>>> Reply to Nick,
>>>
>>>> - Using PDF instead of HTML for anything except printing.
>>>>
>>> I'll grant you everything but the thing about PDFs. PDF's are good as stand alone long docs or anything where layout is important.
>>>
>> Ehh, I truely hate PDFs (except for highly accurate printing, of course). Anything that can't be read on a screen without a bunch of zooming and 2D-scrolling is just not suitable for being read on a screen.
>
> I'd go the other way, PDF's are suitable for anything you'd like in hardcopy but are to cheap to actually print off.
>
>> And that describes the vast majority of PDF's I've seen (For
>> example, a common occurrence is a single page with multiple columns of
>> text where the text is too small to be readable zoomed-out, but if you
>> zoom in, then every time you finish reading a column you have to
>> scroll *up* to the top of the page and then over to the right - which
>> is just a really stupid thing to have to do).
>
> OK so you can make a crappy layout, same goes for HTML.
>

But the PDF phenomenon I described isn't really a case of "bad layout". Those PDF files, like most PDF files, are designed specifically with printing in mind. For a printed page, what I described is often a perfectly good layout, maybe even great.

A person could, of course, have their usual "for print" PDF and, in addition to that, make another PDF that's laid out for screen viewing, but 1. It wouldn't be able to readjust the word wrapping as the window is resized (unless there's some obscure PDF extension to do that), and 2. If they're going to make two versions, they may as well just make the "for screen" version an HTML page.

>> Plus, vertical page
>> margins really have no business being in a screen-viewed document
>> either.
>>
>
> OK point to you
>
>> XHTML/CSS (despite it's flaws) is far better suited for screen-viewed layouts since, unlike PDF, it doesn't force the reader to use navigation that's, by comparison, incredibly awkward just for the sake of preserving the locations of linebreaks within a paragraph, which frankly is *rarely* important outside of printing (also true of any other detail where PDF provides more accuracy).
>>
>
> PDF does zoom better than HTML. With web pages, you as often as not get the tiny font wrapped to 1/2 the width of the screen or lines that are about a paragraph wide. With PDF you can zoom in without things going woonky.
>

I'd argue that's a browser issue. IE7 operates on the idea that zooming and layout should be completely independent, so it doesn't have that problem (Although I primarily use Firefox - I can't use the web without my favorite extensions :) ). Firefox (and probably other browsers) doesn't really have a true zoom. It just adjusts the text size (sometimes - it depends on the CSS), which is what screws up certain poorly-designed layouts. (Well-designed layouts also avoid that problem, even on Firefox.)

>> I might be mistaken, but I don't think editing a PDF can't really be done with typical text editing / word processing software. You need to either use the expensive Adobe Acrobat (full version), or some obscure 3rd party program from an obscure developer. Not that editing a PDF is needed nearly as commonly as reading one, but it is a problem that has bitten me more than once.
>
> I've maybe once wanted to edit a PDF. (HTML for things people might want to edit, docs and other book like things... Nope)
>

I think it's more of an issue when either 1. You're working on some organization's web team and a bunch of yahoos (from other departments) who can't proofread keep sending you things in PDF to put up on the site. 2. You need to fill out a form that only exists in PDF (and maybe hardcopy). But, to save time and dead trees, they allow you to email it back to them. Usually these people aren't aware that PDF is capable of having user-fill-in fields.

>>
>> Plus, the format itself is a bit of a kitchen-sink design. It's impossible for a program to fully support PDF loading without also supporting damn near every file format under the sun. And for something that's primarily a page layout format, I really see no reason for the added complexity that such flexibility entails.
>>
>
> Host Adobe and you don't need to bother.
>

Sometimes business reasons make it preferable not to rely on a third party for certain things because it can tie your hands and cause problems if the unforseen occurrs ("Hope for the best, plan for the worst"). If I were in charge of a program that needed to load PDFs, and that program and the PDF-loading feature were both mission-critical (for whatever reason) then I would make sure to have some fully in-house PDF-loading routines. Otherwise, the whims of Adobe could wind up endangering the whole company (The unthinkable does sometimes happen).

But rare scenario or not, contrived or not, my point is just that the format could have been designed better.

"Nick Sabalausky" <a@a.a> wrote in message news:gbcm76$484$1@digitalmars.com...
> "BCS" <ao@pathlink.com> wrote in message
>>
>> PDF does zoom better than HTML. With web pages, you as often as not get the tiny font wrapped to 1/2 the width of the screen or lines that are about a paragraph wide. With PDF you can zoom in without things going woonky.
>>
>
> I'd argue that's a browser issue. IE7 operates on the idea that zooming and layout should be completely independent, so it doesn't have that problem (Although I primarily use Firefox - I can't use the web without my favorite extensions :) ). Firefox (and probably other browsers) doesn't really have a true zoom. It just adjusts the text size (sometimes - it depends on the CSS), which is what screws up certain poorly-designed layouts. (Well-designed layouts also avoid that problem, even on Firefox.)

Also, small font sizes in HTML at the very least tend to still be fairly crisp (except maybe in Safari, but that's a different issue, and a whole separate rant). In PDF, if something's too small to read it's generally because it's in a reasonably-sized font that's been scaled down. Problem is, that scaling-down degrades the quality (Since the scaling algorithm is chosen for print accuracy rather than readability). Look at a small font, maybe 8 or 10pt, on a web page, and compare that to a PDF, say, from a book, that's been zoomed out so that the text is exactly the same *physical* size as the text on the web page. The text in the PDF will be a lot harder to read.

Reply to Nick,

> But the PDF phenomenon I described isn't really a case of "bad
> layout". Those PDF files, like most PDF files, are designed
> specifically with printing in mind. For a printed page, what I
> described is often a perfectly good layout, maybe even great.
> 

Only issue there is I can't ever recall seeing a 2 column page that benefited from it.


Short version. PDF has it place. Things like documentation and manuals do well as PDFs (if they are made by someone who has a functioning brain).

"Nick Sabalausky" <a@a.a> wrote in news:gb9gjc$3od$1@digitalmars.com:

> Meh, stack overflow needs to die a swift death. OpenID-only login, modal dhtml "dialog boxes" (WTF were people thinking when they first created these?!?!), and complety Ajax (I *HATE* Ajax).

Just curious, why do you hate Ajax?  (This question comes from someone who doesn't know enough about Ajax or web sites that use it to have his own opinion about it.)

--
JMNorris

"JMNorris" <nospam@nospam.com> wrote in message news:gbg3e2$1230$1@digitalmars.com...
> "Nick Sabalausky" <a@a.a> wrote in news:gb9gjc$3od$1@digitalmars.com:
>
>> Meh, stack overflow needs to die a swift death. OpenID-only login, modal
>> dhtml "dialog boxes" (WTF were people thinking when they first created
>> these?!?!), and complety Ajax (I *HATE* Ajax).
>
> Just curious, why do you hate Ajax?  (This question comes from someone who doesn't know enough about Ajax or web sites that use it to have his own opinion about it.)
>
> --
> JMNorris

Well, from a developer's standpoint, I don't like it because it involves using ECMAScript/JavaScript, and I consider that to be a terrible language (though I admit the newer versions really are are improvements. Of course, it's still basically a case of polishing a turd - they can polish it all they want, it's still a turd.)

Also, it involves DHTML, which involves using the browser DOMs and those things are terribly inconsistent across browsers, and even the "official" standard is poorly designed in places (for instance, the value that gets returned to indicate which mouse button(s) is/are down is *FAR* better in IE, but the official standard's way of doing it is both completely incompatible with that and is practically useless by comparison anyway). It's possible to get things working reliably and consistently across browsers, but it involves an enormous amount of the absolute most ridiculous and obscure trickery I've ever seen on any platform (And I've coded for the Atari VCS). There's a site somewhere that explains a lot of it, but it's (thankfully) been awhile since I've had to do much DHTML so unfortunately I don't have the link handy.

From a user's standpoint, I have a whole other set of reasons, which I mentioned in different branch of this thread. I use an actual newsgroup reader so I can't link to it, so I'll just quote it here:

> I guess I overstated my point a little bit. Ajax (as well as
> non-Ajaxy JS/DHTML) is great for simple things like voting on posts
> (Provided that Ajax/JS isn't required for the feature, because there's
> really no reason for these things not to have graceful non-JS fallbacks.
> Or
> at least there wouldn't be any reason if it weren't for the fact that
> (X)HTML/CSS has certain appallingly-ridiculous limitations that will never
> get fixed just because everyone's fearful of changing HTML anymore and has
> gotten used to using JS-based workarounds - and that *is* what they are -
> workarounds).
>
> But these days, web or not, you can pretty much guarantee: if there's a
> way
> to screw up the design of something, it will get screwed up *and* millions
> of developers will then run around all copying the same screwup after
> either
> not noticing it, or mistaking it for a good idea.
>
> Examples:
> - Breaking the "Back" button
> - Breaking the bookmarking ability
> - Flash intro pages / Intro pages, period / Flash intros on the homepage
> (Ie, the animating GIFs/blink tags of the 21st century) / Flash sites
> - Loads of invisible text on any system that uses a non-default color
> scheme.
> - Crapping all over established design standards (in general).
> - Menus that expand upon mouseover instead of click.
> - "Close" buttons that minimize instead of close (typically a non-web
> issue).
> - Adding the "feature" of modal dialog boxes to something (ie, a web page)
> that has no technical or design justification for such modality.
> - Forcing a custom skin upon users of an app instead of at least
> *allowing*
> the user to use *their own system settings* (another typically non-web
> issue).
> - Screwing up the ability to work with two instances at the same time
> (*cough* Adobe LiveDocs *cough*).
> - Inadvertently preventing full archival for offline reference (*cough*
> Adobe LiveDocs *cough*).
> - Insanely slow page loading and navigation (*cough* Adobe LiveDocs and
> Joystiq/Engadget *cough*).
> - Using PDF instead of HTML for anything except printing.
> - Eliminating the user's ability to make their own decisions of when to
> open
> something in a new tab/window or the same tab/window.
>
> Ajax/JS/DHTML is what enables many of those problems to occur (not all of them, though, I kinda got carried away). Disable JS and many of those problems go away. Or at least they *would* go away if everyone wasn't so keen on throwing away the whole idea of non-JS-fallbacks.
>
> I mean really, there is absolutely no useful functionality that
> JS/Ajax/DHTML provide that can't be accomplished in a non-JS/Ajax/DHTML
> way,
> either right now or with a few minor improvements to XHTML/CSS (such as
> allowing the "action" and "method" attributes to be associated with an
> "input/submit" tag instead of the "form" tag, or allowing link tags to
> perform a form submission - actually these things are the exact examples I
> had in mind when I said above that JS is sometimes used as a workaround
> for
> (X)HTML's limitations).
>
> The only *real* use of JS/Ajax/DHTML is that they allow for fewer full-page-loads. That's really all it comes down to. And that's not a bad thing, but for some people, like myself, the benefit of having fewer full-page-loads just isn't worth the cost of having to deal with all that crap design that JS/Ajax/DHTML end up allowing. But unfortunately, I don't have the option of actually *making* that choice thanks to all of those yahoos that have jumped onto the "JS is now a standard feature that we can safely require" bandwagon.

It may be that it "involves" using Javascript in the same sense that using D involves using assembler code, but Javascript implementations are becomming increasingly fast, as latest witnessed by the Squirrelfish Extreme Javascript VM (and V8 and TraceMonkey). There are also languages like haXe, Java and C# that can be compiled to Javascript. It's becomming increasinly nice to work with, with type inference, intellisense etc.

That said, the platform is aging and ad-hoc. But there is some new life being breathed into it.

Bent


"Nick Sabalausky" <a@a.a> skrev i meddelelsen news:gbgo8e$2m2i$1@digitalmars.com...
> "JMNorris" <nospam@nospam.com> wrote in message news:gbg3e2$1230$1@digitalmars.com...
>> "Nick Sabalausky" <a@a.a> wrote in news:gb9gjc$3od$1@digitalmars.com:
>>
>>> Meh, stack overflow needs to die a swift death. OpenID-only login, modal
>>> dhtml "dialog boxes" (WTF were people thinking when they first created
>>> these?!?!), and complety Ajax (I *HATE* Ajax).
>>
>> Just curious, why do you hate Ajax?  (This question comes from someone who
>> doesn't know enough about Ajax or web sites that use it to have his own
>> opinion about it.)
>>
>> --
>> JMNorris
>
> Well, from a developer's standpoint, I don't like it because it involves using ECMAScript/JavaScript, and I consider that to be a terrible language (though I admit the newer versions really are are improvements. Of course, it's still basically a case of polishing a turd - they can polish it all they want, it's still a turd.)
>
> Also, it involves DHTML, which involves using the browser DOMs and those things are terribly inconsistent across browsers, and even the "official" standard is poorly designed in places (for instance, the value that gets returned to indicate which mouse button(s) is/are down is *FAR* better in IE, but the official standard's way of doing it is both completely incompatible with that and is practically useless by comparison anyway). It's possible to get things working reliably and consistently across browsers, but it involves an enormous amount of the absolute most ridiculous and obscure trickery I've ever seen on any platform (And I've coded for the Atari VCS). There's a site somewhere that explains a lot of it, but it's (thankfully) been awhile since I've had to do much DHTML so unfortunately I don't have the link handy.
>
> From a user's standpoint, I have a whole other set of reasons, which I mentioned in different branch of this thread. I use an actual newsgroup reader so I can't link to it, so I'll just quote it here:
>
>> I guess I overstated my point a little bit. Ajax (as well as
>> non-Ajaxy JS/DHTML) is great for simple things like voting on posts
>> (Provided that Ajax/JS isn't required for the feature, because there's
>> really no reason for these things not to have graceful non-JS fallbacks. Or
>> at least there wouldn't be any reason if it weren't for the fact that
>> (X)HTML/CSS has certain appallingly-ridiculous limitations that will never
>> get fixed just because everyone's fearful of changing HTML anymore and has
>> gotten used to using JS-based workarounds - and that *is* what they are -
>> workarounds).
>>
>> But these days, web or not, you can pretty much guarantee: if there's a way
>> to screw up the design of something, it will get screwed up *and* millions
>> of developers will then run around all copying the same screwup after either
>> not noticing it, or mistaking it for a good idea.
>>
>> Examples:
>> - Breaking the "Back" button
>> - Breaking the bookmarking ability
>> - Flash intro pages / Intro pages, period / Flash intros on the homepage
>> (Ie, the animating GIFs/blink tags of the 21st century) / Flash sites
>> - Loads of invisible text on any system that uses a non-default color
>> scheme.
>> - Crapping all over established design standards (in general).
>> - Menus that expand upon mouseover instead of click.
>> - "Close" buttons that minimize instead of close (typically a non-web
>> issue).
>> - Adding the "feature" of modal dialog boxes to something (ie, a web page)
>> that has no technical or design justification for such modality.
>> - Forcing a custom skin upon users of an app instead of at least *allowing*
>> the user to use *their own system settings* (another typically non-web
>> issue).
>> - Screwing up the ability to work with two instances at the same time
>> (*cough* Adobe LiveDocs *cough*).
>> - Inadvertently preventing full archival for offline reference (*cough*
>> Adobe LiveDocs *cough*).
>> - Insanely slow page loading and navigation (*cough* Adobe LiveDocs and
>> Joystiq/Engadget *cough*).
>> - Using PDF instead of HTML for anything except printing.
>> - Eliminating the user's ability to make their own decisions of when to open
>> something in a new tab/window or the same tab/window.
>>
>> Ajax/JS/DHTML is what enables many of those problems to occur (not all of
>> them, though, I kinda got carried away). Disable JS and many of those
>> problems go away. Or at least they *would* go away if everyone wasn't so
>> keen on throwing away the whole idea of non-JS-fallbacks.
>>
>> I mean really, there is absolutely no useful functionality that
>> JS/Ajax/DHTML provide that can't be accomplished in a non-JS/Ajax/DHTML way,
>> either right now or with a few minor improvements to XHTML/CSS (such as
>> allowing the "action" and "method" attributes to be associated with an
>> "input/submit" tag instead of the "form" tag, or allowing link tags to
>> perform a form submission - actually these things are the exact examples I
>> had in mind when I said above that JS is sometimes used as a workaround for
>> (X)HTML's limitations).
>>
>> The only *real* use of JS/Ajax/DHTML is that they allow for fewer
>> full-page-loads. That's really all it comes down to. And that's not a bad
>> thing, but for some people, like myself, the benefit of having fewer
>> full-page-loads just isn't worth the cost of having to deal with all that
>> crap design that JS/Ajax/DHTML end up allowing. But unfortunately, I don't
>> have the option of actually *making* that choice thanks to all of those
>> yahoos that have jumped onto the "JS is now a standard feature that we can
>> safely require" bandwagon.
>
> 

"Bent Rasmussen" <IncredibleShrinkingSphere@Gmail.com> wrote in message news:gbgoq1$2o10$1@digitalmars.com...
> It may be that it "involves" using Javascript in the same sense that using D involves using assembler code, but Javascript implementations are becomming increasingly fast, as latest witnessed by the Squirrelfish Extreme Javascript VM (and V8 and TraceMonkey). There are also languages like haXe, Java and C# that can be compiled to Javascript. It's becomming increasinly nice to work with, with type inference, intellisense etc.
>
> That said, the platform is aging and ad-hoc. But there is some new life being breathed into it.
>

That's really good to know, about compiling decent languages to JS. Thanks :)

FWIW, I was thrilled to see that newer versions of JS actually allow variables to be declared as actual specific types instead of just variant. So, in other words, it's finally catching up to Visual Basic ;) [/snide jab]

> That said, the platform is aging and ad-hoc.

Yea, that's a pretty good summary of my opinion on it.

Nick Sabalausky:
> FWIW, I was thrilled to see that newer versions of JS actually allow variables to be declared as actual specific types instead of just variant.

Everyone is free to like or dislike JavaScript, but the point here is that all JS and all its features are designed to be a small dynamic language with prototype-based OOP. So bolting on it fake-static-typing plus Java-style classes makes it a mess. That's why I was not trilled.
If you like static typing and Java-style OOP, is much better to start with a Java/C#-like language instead, and keep using it. Think about adding to the current D2 language prototype-based OOP too and a lot of dynamic typing here and there, and you get an image of a reversed situation.

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gbgr2h$306j$1@digitalmars.com...
> Nick Sabalausky:
>> FWIW, I was thrilled to see that newer versions of JS actually allow variables to be declared as actual specific types instead of just variant.
>
> Everyone is free to like or dislike JavaScript, but the point here is that
> all JS and all its features are designed to be a small dynamic language
> with prototype-based OOP. So bolting on it fake-static-typing plus
> Java-style classes makes it a mess. That's why I was not trilled.
> If you like static typing and Java-style OOP, is much better to start with
> a Java/C#-like language instead, and keep using it. Think about adding to
> the current D2 language prototype-based OOP too and a lot of dynamic
> typing here and there, and you get an image of a reversed situation.
>
> Bye,
> bearophile

As far as I'm concerned, dynamic typing and prototype-OO are mistakes period. I can understand that it's good for a language to be true to itself, but when "itself" is just a giant pile of bad ideas in the first place, then shoehorning it into something more sensible, despite being messy or inconsistent, is at least the next best thing to the ideal action of just abandoning the monstrosity entirely and replacing it with what it should have been from the start.

Nick Sabalausky wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:gbgr2h$306j$1@digitalmars.com...
>> Nick Sabalausky:
>>> FWIW, I was thrilled to see that newer versions of JS actually allow variables to be declared as actual specific types instead of just variant.
>> Everyone is free to like or dislike JavaScript, but the point here is that
>> all JS and all its features are designed to be a small dynamic language
>> with prototype-based OOP. So bolting on it fake-static-typing plus
>> Java-style classes makes it a mess. That's why I was not trilled.
>> If you like static typing and Java-style OOP, is much better to start with
>> a Java/C#-like language instead, and keep using it. Think about adding to
>> the current D2 language prototype-based OOP too and a lot of dynamic
>> typing here and there, and you get an image of a reversed situation.
>>
>> Bye,
>> bearophile
> 
> As far as I'm concerned, dynamic typing and prototype-OO are mistakes
> period. I can understand that it's good for a language to be true to itself,
> but when "itself" is just a giant pile of bad ideas in the first place, then
> shoehorning it into something more sensible, despite being messy or
> inconsistent, is at least the next best thing to the ideal action of just
> abandoning the monstrosity entirely and replacing it with what it should
> have been from the start.
> 
> 
I've got to disagree with you here.
prototype OOP is a sensible and much *much* more flexible than your
plain old class based OOP. for small scripts and little snippets the
flexibility of both the prototype OOP and dynamic typing is much better
than the the respective opposite. for those use cases (for which
javascript was initially intended) js is perfect. the problem was never
in the language itself.
WWW was designed to be a platform for mostly static _documents_.
when people started to create those god-damn awful web-apps they broke
that design. they use the browser for use-cases it was never meant to
do. js is used too for large code-bases. it's like trying to build a
house in the sea with a screwdriver.

what we really need is a suitable platform with different protocols (not http which is stateless and not suitable for applications), a different client software agent (what does it really mean to press the back button in gmail, or take a bookmark? that UI is wrong for the app. the browser is the wrong place to put a mail program in) and different languages. for a real app you'd want to use a statically typed class based OOP language such as D and not js.