HighDots Forums  

NOSCRIPT element extended features

Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)


Discuss NOSCRIPT element extended features in the Cascading Style Sheets forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
VK
 
Posts: n/a

Default NOSCRIPT element extended features - 10-10-2009 , 06:56 PM






At test pages http://jsnet.sourceforge.net/elements.html and
http://jsnet.sourceforge.net/entities.html I am also testing the
noscript notification for some JavaScript intensive pages. Obviously
to see it in action it is necessary to disable script support. My
questions are:
1) overall styling observation as for a warning message
2) any thoughts of how to add another option (besides "Hide this
warning") to the warning window.

Reply With Quote
  #2  
Old   
Jukka K. Korpela
 
Posts: n/a

Default Re: NOSCRIPT element extended features - 10-11-2009 , 04:36 AM






VK wrote:

Quote:
At test pages http://jsnet.sourceforge.net/elements.html and
http://jsnet.sourceforge.net/entities.html I am also testing the
noscript notification for some JavaScript intensive pages. Obviously
to see it in action it is necessary to disable script support.
As a structure issue, the noscript element should appear first in the
document body, when the page is completely script-dependent, as it is here
(and hence the current wording of the noscript content is... an
understatement). You should not rely on CSS to put the notification first,
especially since in non-JavaScript browsing, CSS may well be unsupported or
disabled - or page style sheet may be overridden by a user style sheet.

Quote:
My questions are:
1) overall styling observation as for a warning message
I guess it's noticeable enough - when styled according to your stylesheet.
But maybe the situation would be clearer if the warning covered all of the
canvas. Then there's no particular reason for strong colors - one could use
just large font size and maybe reddish text color.

Quote:
2) any thoughts of how to add another option (besides "Hide this
warning") to the warning window.
An "×" in a corner of a box is often used as a close button, but "Hide this
warning" is clearer. An "×" may violate one of the basic rules of design:
"Don't make me think".

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Reply With Quote
  #3  
Old   
VK
 
Posts: n/a

Default Re: NOSCRIPT element extended features - 10-12-2009 , 04:05 AM



Quote:
VK wrote:
At test pageshttp://jsnet.sourceforge.net/elements.htmland
http://jsnet.sourceforge.net/entities.htmlI am also testing the
noscript notification for some JavaScript intensive pages. Obviously
to see it in action it is necessary to disable script support.

Jukka K. Korpela wrote:
As a structure issue, the noscript element should appear first in the
document body, when the page is completely script-dependent, as it is here
(and hence the current wording of the noscript content is... an
understatement). You should not rely on CSS to put the notification first,
especially since in non-JavaScript browsing, CSS may well be unsupported or
disabled - or page style sheet may be overridden by a user style sheet.
I do agree with the structural considerations but as often we have to
accommodate proper considerations to the improper world :-) In the
particular many search spiders (aka crawlers) are thaught to grab the
first paragraph-like text from the top of the page for a content
sample. As we don't want to have a page being presented in the search
results as "Client-side scripting is disabled", "You need Flash Player
installed", "MathML is not supported" etc. any service warning blocks
have to go at least one text unit (better two for safety sake) down
from the body. And to facilitate standard warning injection we are
adding it after the main content just before the closing body tag.

CSS may be disabled or overridden by custom CSS but it is a very
particular situation requiring very explicit user actions, unlike say
automatic scripting lock for a unknown page by an antivirus or a
browser plugin. The one taking explicit steps to remove provided CSS
styling has to be aware of all possible usability consequences
(positive as negative) it implies, so in such case the ball is on the
end-user side. Though it would be interesting to find a warning format
for CSS disabled situations.


Quote:
My questions are:
1) overall styling observation as for a warning message

I guess it's noticeable enough - when styled according to your stylesheet..
But maybe the situation would be clearer if the warning covered all of the
canvas. Then there's no particular reason for strong colors - one could use
just large font size and maybe reddish text color.

2) any thoughts of how to add another option (besides "Hide this
warning") to the warning window.

An "×" in a corner of a box is often used as a close button, but "Hide this
warning" is clearer. An "×" may violate one of the basic rules of design:
"Don't make me think".
Thank you. Actually by "add another option" I meant to add another
option besides "Hide this warning", say "How to enable client-side
scripting" navigation link within the same block.

I am also wondering if newer browsers with attribute selector support
would let to display the warning in userAgent language based on
lang="language code" attribute and hiding other language versions.

Reply With Quote
  #4  
Old   
Jukka K. Korpela
 
Posts: n/a

Default Re: NOSCRIPT element extended features - 10-12-2009 , 12:31 PM



VK wrote:

Quote:
Jukka K. Korpela wrote:
As a structure issue, the noscript element should appear first in the
document body, when the page is completely script-dependent, as it
is here (and hence the current wording of the noscript content is...
an understatement). You should not rely on CSS to put the
notification first, especially since in non-JavaScript browsing, CSS
may well be unsupported or disabled - or page style sheet may be
overridden by a user style sheet.

I do agree with the structural considerations but as often we have to
accommodate proper considerations to the improper world :-)
You might have a boss or a customer pointing a gun at you, or showing a huge
pile of money if you do improper things. Then it might be understandable to
ignore the structural point.

Quote:
In the
particular many search spiders (aka crawlers) are thaught to grab the
first paragraph-like text from the top of the page for a content
sample.
First of all, are pages ultimately for human beings or for software?

Second, spiders don't take the sequential order that seriously. Early search
engines used to show the start of a document as an extract, but this is no
longer common for several reasons. It made it all too easy to fool them
using invisible initial text, it was all too usual that the extract was
pointless because it contained just site-wide navigation, etc.

Quote:
As we don't want to have a page being presented in the search
results as "Client-side scripting is disabled", "You need Flash Player
installed", "MathML is not supported" etc. any service warning blocks
have to go at least one text unit (better two for safety sake) down
from the body.
The proper wording is not "Client-side scripting is disabled" or any of the
examples you mention. If you instead explain, say, "This page is for
generating absurd poems using JavaScript. Your browser does not support
JavaScript or has JavaScript currently disabled.", then the first statement
is informative. The second one isn't, but you could always formulate the
first statement verbosely enough so that any search engine that blindly
picks up the initial text will consume just the first statement-

Quote:
And to facilitate standard warning injection we are
adding it after the main content just before the closing body tag.
It's in a wrong place then. It's like giving lengthy instructions and then
saying something crucial that should have been said in the first place.

Quote:
CSS may be disabled or overridden by custom CSS but it is a very
particular situation requiring very explicit user actions,
No, it does not require any user action if, for example, the browser does
not support CSS (how do you expect Braille rendering to do CSS?) or some
helpful person has configured a user's browser for this user's specific
needs (and the said user never heard anything about CSS).

Quote:
The one taking explicit steps to remove provided CSS
styling has to be aware of all possible usability consequences
(positive as negative) it implies, so in such case the ball is on the
end-user side.
Why should users be aware of all possible consequences, when most authors,
who should be far more experienced than users, generally ignore such
considerations?

Quote:
Though it would be interesting to find a warning format
for CSS disabled situations.
Nothing especial is needed to warn "CSS disabled" users about
JavaScript-dependency. You just need to refrain from assuming that you can
revamp pages in CSS at will.

It is easy, and almost always (worse than) pointless, to issue warnings
about CSS-dependency. For example:

<p style="display:none"><big>This page relies on CSS style sheets and
probably looks like crap when the page's style sheet is not used. Currently
your browser is not obeying this page's style sheet.</big></p>

Quote:
Actually by "add another option" I meant to add another
option besides "Hide this warning", say "How to enable client-side
scripting" navigation link within the same block.
There are several web pages that give instructions on such matters. Most of
them are hopelessly out of date, if not originally flawed. Do you expect to
be able to do things better?

Quote:
I am also wondering if newer browsers with attribute selector support
would let to display the warning in userAgent language based on
lang="language code" attribute and hiding other language versions.
You would just get into more pointless complexity and sources of errors that
way. The idea is based on a misconception. Attribute selectors have
absolutely nothing to do with user agent language (which is completely out
of the scope of CSS). If you intended to do the language selection in
JavaScript, then it's a different matter. But why would you rely on CSS
there? Absolutely no reason. You could store the different language versions
in JavaScript strings, which are completely invisible in non-JavaScript
rendering, and write out just the "right" one.

(I wrote "right" because you would just make a guess on the language. User
agent language is not the same as the user's preferred language, and you
cannot really know the latter.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Reply With Quote
  #5  
Old   
David Stone
 
Posts: n/a

Default Re: NOSCRIPT element extended features - 10-13-2009 , 09:11 AM



In article <SRIAm.27547$La7.12818 (AT) uutiset (DOT) elisa.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> wrote:

Quote:
VK wrote:
[snip]
And to facilitate standard warning injection we are
adding it after the main content just before the closing body tag.

It's in a wrong place then. It's like giving lengthy instructions and then
saying something crucial that should have been said in the first place.
That's a bit like the MASH episode about the bomb. Dialogue goes
something like "Cut the red wire connecting the fuse to the casing.
[The docs perform this bit of surgery] But first...."

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.