Velocity Reviews - Rationale question

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)

- Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)

- - Rationale question (http://www.velocityreviews.com/forums/t920657-rationale-question.html)

Rationale question

Hello,
I'm new in javascript programming (but am quite literate in HTML, CSS,
and C). It's amazing what one can do with JS and fairly modern browsers.

One thing that struck me as odd was that there is no way to portably
find out the size (in pixels) of the current browser window (or of any
HTML element for that matter, unless it was inline-CSSed).

I'm wondering what the reason for this might be.

Of course a properly authored web site should render well on any broser
window size, so one might argue that JS doesn't provide access to things
that needn't be accessed in well-designed web pages. On the other hand,
JS provides a plethora of annoying design "no-nos", such as creating of
pop-ups and even resizing and moving the browser window.

Somehow I can't believe that the creators of JS have simply forgotten to
give the "Window" object "width" and "height" properties. I believe they
omitted it on purpose, and I'd like to know the purpose just out of
curiosity (and while we're at it: What the hell am I supposed to do with
the pixel size of the screen the browser is running on?)

Thanks,
robert

Re: Rationale question

Robert Latest wrote:
> Hello,
> I'm new in javascript programming (but am quite literate in HTML, CSS,
> and C). It's amazing what one can do with JS and fairly modern browsers.
>
> One thing that struck me as odd was that there is no way to portably
> find out the size (in pixels) of the current browser window (or of any
> HTML element for that matter, unless it was inline-CSSed).
>
> I'm wondering what the reason for this might be.
>
> Of course a properly authored web site should render well on any broser
> window size, so one might argue that JS doesn't provide access to things
> that needn't be accessed in well-designed web pages. On the other hand,
> JS provides a plethora of annoying design "no-nos", such as creating of
> pop-ups and even resizing and moving the browser window.
>
> Somehow I can't believe that the creators of JS have simply forgotten to
> give the "Window" object "width" and "height" properties. I believe they
> omitted it on purpose, and I'd like to know the purpose just out of
> curiosity (and while we're at it: What the hell am I supposed to do with
> the pixel size of the screen the browser is running on?)
>
> Thanks,
> robert

Hi Robert,

Take a look at the screen object.

Re: Rationale question

web.dev said the following on 10/10/2005 12:26 PM:

> Robert Latest wrote:
>
>>Hello,
>>I'm new in javascript programming (but am quite literate in HTML, CSS,
>>and C). It's amazing what one can do with JS and fairly modern browsers.
>>
>>One thing that struck me as odd was that there is no way to portably
>>find out the size (in pixels) of the current browser window (or of any
>>HTML element for that matter, unless it was inline-CSSed).

Even that is not as possible as people think it is.

>>I'm wondering what the reason for this might be.

What use is it? Even if you know the outer dimensions of the window,
they are irrelevant as what you should want to know is the inner
dimensions of the view-port so that you can make some guess as to how
much real estate you have available. Even then, as you point out, it
shouldn't matter in a "properly authored web site" (although I have yet
to see very many of those).

>>Of course a properly authored web site should render well on any broser
>>window size, so one might argue that JS doesn't provide access to things
>>that needn't be accessed in well-designed web pages. On the other hand,
>>JS provides a plethora of annoying design "no-nos", such as creating of
>>pop-ups and even resizing and moving the browser window.

popups were a semi-good idea until they were abused into oblivion. Same
with resizing and moving (depending on who you ask). Some modern
browsers allow you disable some if not all of those no-no's.

>>Somehow I can't believe that the creators of JS have simply forgotten to
>>give the "Window" object "width" and "height" properties. I believe they
>>omitted it on purpose, and I'd like to know the purpose just out of
>>curiosity (and while we're at it: What the hell am I supposed to do with
>>the pixel size of the screen the browser is running on?)
>>
>>Thanks,
>>robert
>
>
> Hi Robert,
>
> Take a look at the screen object.
>

And the screen object tells you absolutely *nothing* about the browser
window size other than maybe what resolution monitor it is being viewed on.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

Re: Rationale question

Robert Latest wrote:

> One thing that struck me as odd was that there is no way to portably
> find out the size (in pixels) of the current browser window

That is a question of the browser object model then, not of a particular
scripting language.

> (or of any
> HTML element for that matter, unless it was inline-CSSed).

That is a question of the document object model then, have you ever
heard about the offsetWidth/offsetHeight properties that IE introduced
in IE 4 and that by now are part of the object model of element objects
in browsers like Mozilla, Netscape 6 and later, Opera 7 and later and
others?
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/offsetwidth.asp>

And there is more support in the DOM than for inline CSS
(element.style), the W3C DOM Level 2 defines stuff to get the computed
style and Mozilla and Opera support that e.g.
document.defaultView.getComputedStyle(someElementO bject, '').width

> Somehow I can't believe that the creators of JS have simply forgotten to
> give the "Window" object "width" and "height" properties.

I think you need to first understand the difference between the
JavaScript language some creators defined and implemented and the object
model an application like a browser exposes to script.
<http://jibbering.com/faq/#FAQ2_6>
<http://jibbering.com/faq/#FAQ2_8>

As for such properties lots of browsers (Netscape, Mozilla, Opera) have
window.outerWidth
window.outerHeight
for instance.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Re: Rationale question

On Mon, 10 Oct 2005 13:14:30 -0400,
Randy Webb <HikksNotAtHome@aol.com> wrote
in Msg. <L86dnRa6l4bMPNfenZ2dnUVZ_tGdnZ2d@comcast.com>

> What use is it? Even if you know the outer dimensions of the window,
> they are irrelevant as what you should want to know is the inner
> dimensions of the view-port so that you can make some guess as to how
> much real estate you have available.

That's exactly what I meant. And what I don't understand is why this
easily obtainable information is not being made available to the user
via the standard DOM. Good website "penmanship" not needing this
information is out as a rationale because I'm still allowed to do a lot
of other ugly stuff.

> Even then, as you point out, it
> shouldn't matter in a "properly authored web site" (although I have yet
> to see very many of those).

Yes. Like I said, I'm not so much interested in how to pull it off, but
why I'm not supposed to. I'm just wondering why the JS designers were
considerate enough to give me an "onresize" handler but not the
information on what the window was resized to?

Thanks,
robert

Re: Rationale question

On Tue, 11 Oct 2005 07:03:59 +1000,
RobG <rgqld@iinet.net.au> wrote
in Msg. <434ad785$0$16848$5a62ac22@per-qv1-newsreader-01.iinet.net.au>

> Others have pretty much filled you in, here's a pretty good roundup of
> what's available:
>
> <URL:http://www.quirksmode.org/viewport/compatibility.html>

Thanks. Like I pointed out in my original post, the method of how to
actually do this is secondary to the question of why there doesn't exist
a portable way of getting the information.

Other than that I want to design websites using only features that are
part of the W3C standard /and/ work consistently on a common set of
browsers (of which, sadly, IE6 has to be a member).

Thanks,
robert

Re: Rationale question

Robert Latest wrote:
> On Tue, 11 Oct 2005 07:03:59 +1000,
> RobG <rgqld@iinet.net.au> wrote
> in Msg. <434ad785$0$16848$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
>
>> Others have pretty much filled you in, here's a pretty good roundup of
>> what's available:
>>
>> <URL:http://www.quirksmode.org/viewport/compatibility.html>
>
> Thanks. Like I pointed out in my original post, the method of how to
> actually do this is secondary to the question of why there doesn't exist
> a portable way of getting the information.
>
> Other than that I want to design websites using only features that are
> part of the W3C standard /and/ work consistently on a common set of
> browsers (of which, sadly, IE6 has to be a member).
>
> Thanks,
> robert
>

While it is certainly possible to create web pages that correctly and
exclusively implement W3C standards (which includes "Document Object
Model" or "DOM" and "Cascading Style Sheets" or "CSS" and others - but
not javascript which implements an ECMA standard) it is quite difficult,
since you will find that only a subset of the features work and work the
same in the majority of popular browsers, and there is no simple place
to find a list of which features are supported by a specific set of
target browsers (such a database would be quite helpful).

Things are further complicated because in many cases there are ways to
take advantage of various browser quirks by using hacks (particularly in
CSS) and still provide code that is technically standards compliant
(http://www.dithered.com/css_filters/css_only/).

As for _why_ you should develop web pages using standards like xhtml and
css, some of the reasons I hear are:

1. These standards when marked up properly are easier for search
engines, screen readers and other parsers to read and understand.

2. The seporation of content, presentation, and structure (or was that
content/structure, presentation and logic?)

3. Easier to maintain/change (because of #2)

I have to say though, sometimes, it's just easier (hear comes the
groaning) to open a WYSIWYG editor and through together some html 4.01
table based markup - which oddly enough, seems to be easier for many
devices to parse and display - including some screen readers (since it
has been around for so long presumably.)

I'd love to hear others' points of view on the matter though..

Kevin N.

P.S. I've read (in this group somewhere) that HTML was always meant to
be machine generated code - I've never found a tool that will allow you
to easily generate html/css while at the same time follow current trends
about semantically marking up documents with separated presentation.

I guess this is because there are no clearly defined semantic markup
industry standards to follow - if there were, and a tool was available -
I'd be a very happy man (if there were standards, I'd build a tool ;-) ).