|
|
Posted by Michael Winter on 11/03/08 11:48
On 24/05/2006 18:46, Spartanicus wrote:
[snip]
> http://homepage.ntlworld.com/spartanicus/temp.htm
>
> I've replaced the reload with an alert dialog for testing.
That's the source of your problem. Without the reload, the width
variable is never changed. The specific instances where is appears to
fail are special cases because they switch between two exact sizes.
Consider opening the panel. When initially loading, the viewport width
will be 1000px wide, for example. Open the panel, and it's reduced to
say, 800px. At this point, the two widths will compare as unequal,
thereby reloading the document. This reload will set a different value
for the width variable, but as you prevent that, it will remain the
original value of 1000. When hiding the panel, the viewport will enlarge
to its original width of 1000px, so nothing will appear to have
happened. Include both the reload and the alert, and you'll see that
there are no problems.
If it were to important to update the width variable, whether or not the
document is reloaded, the if expression can be changed to:
(width != (width = document.body.clientWidth))
though it's not necessary, here. The change of operand order is
important: the width variable clearly needs to be evaluated before it's
assigned to on the right-hand side.
[snip]
> But there are potentially a fair number of different things that
> media queries could be used for, it could be neigh impossible for a
> browser to determine what action to take depending on the significant
> number of UI actions that a user may initiate.
That is a fair point, but how many of these properties will change in
response to specific actions? Resizing the viewport will only affect the
(min/max-) height and width properties. It needn't involve re-evaluating
the entire style sheet, though that is a possibility.
The most awkward to handle is font changes (family or size) as any query
containing an em or ex length value would need to be re-evaluated.
However, it's far from infeasible (though I'd understand why it wouldn't
be the first thing an implementer might concentrate on).
> The author coding these functions on the other hand knows what
> behaviour is needed, it seems reasonable to me that the author should
> also implement the behaviour such as in this case triggering a
> reload. After all, dynamic behaviour belongs in the Javascript
> domain.
That is also true, but as you and I both know, client-side scripts
should be considered optional features. That notwithstanding, refreshing
the document isn't a particularly nice solution. For simple content,
it's not that big a deal, but it could play havoc with forms and the
like. It would be better for the UA to deal with it as it is the UA that
is providing the feature, not a script.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Navigation:
[Reply to this message]
|