W3C HTML Checker: <BLINK> tag not defined?
Harry Gibbens, Jr.
I ran the W3C HTMTL Validator checker on one of my pages and learned
that <BLINK> tag is not defined in the HTML version
Does anyone knows how to make a subsitutue for <BLINK> tag?
Thanks,
Harry Jr.
Chuck Taylor
Gibbens, Jr.) wrote:
>Does anyone knows how to make a subsitutue for <BLINK> tag?
<SPAN STYLE="text-decoration: blink;">Blinking text</SPAN>
This would be one of the standards-compliant ways to do it, but at
least one of the mainstream browsers fails to support it.
You could also apply the STYLE="text-decoration: blink;" attribute to
other elements, such as P or A for example, or define a style class.
See the comp.infosystems.www.authoring.stylesheets newsgroup,
http://css.nu/, and http://www.w3.org/Style/CSS/ for more.
--
Chuck Taylor
http://home.hiwaay.net/~taylorc/contact/
Harry Gibbens, Jr.
I ran the W3C HTMTL Validator checker on one of my pages and learned
that <UL> or <OL> tag contains an error as:
Error: element "UL" not allowed here; possible cause is an inline
element containing a block-level element. This is for line 209.
What does this mean? How to correct the problem? It was the same
problem when I changed to <OL>.
For your reference, please run the HTML checker at my page:
http://validator.w3.org/check?uri=http://www.deafworks.com/ALARM_CLOCKS/orga.htm
Funny, there are two <UL> tags in the page. The first one is on line
209 (the </UL> is at line 219) flunks and got the above error
message. But, on line 421 (the </UL> is at line 428) passed. Why
didn't it flunk? I don't get it.
Thanks,
Harry Jr.
Calvin Walton
> Hi,
>
> I ran the W3C HTMTL Validator checker on one of my pages and learned
> that <UL> or <OL> tag contains an error as:
>
> Error: element "UL" not allowed here; possible cause is an inline
> element containing a block-level element. This is for line 209.
>
> What does this mean? How to correct the problem? It was the same
> problem when I changed to <OL>.
<snip>
> Funny, there are two <UL> tags in the page. The first one is on line
> 209 (the </UL> is at line 219) flunks and got the above error
> message. But, on line 421 (the </UL> is at line 428) passed. Why
> didn't it flunk? I don't get it.
>
> Thanks,
> Harry Jr.
The validator says:
Error: element "UL" not allowed here; possible cause is an inline
element containing a block-level element.
And that's what it is. The <UL> is inside a <font> tag, on line 186. You
could add a </font> before the <ul>, or replace the font tag with
cascading stylesheets and paragraphs.
Hope that helped!
Calvin
--
remove the .nospam. to email me
Simon Brooke
Don't be so bl**dy silly.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; It appears that /dev/null is a conforming XSL processor.
Simon Brooke
> For your reference, please run the HTML checker at my page:
>
> http://validator.w3.org/check?uri=http://www.deafworks.com/ALARM_CLOCKS/orga.htm
>
I get a 404 on that page, presumably you've moved it.
However, the *only* thing you're allowed to put in UL or OL is
LI. You're allowed to put more or less anything inside an LI, but it
*must* be inside an LI.
Harry Gibbens, Jr.
Thanks for the inputs. It has been corrected by putting anything
inside the <LI>. It passed the validator!
Cheers,
Harry Jr.
>Calvin wrote
>
>The validator says:
>Error: element "UL" not allowed here; possible cause is an inline
>element containing a block-level element.
>And that's what it is. The <UL> is inside a <font> tag, on line 186. You
>could add a </font> before the <ul>, or replace the font tag with
>cascading stylesheets and paragraphs.
>
Chuck Taylor
Holmboe) wrote:
>Chuck Taylor <chuck.taylor@spamtrap> exclaimed in <6a4a3us2hfsmegqsn...@4ax.com>:
>> <SPAN STYLE="text-decoration: blink;">Blinking text</SPAN>
>> This would be one of the standards-compliant ways to do it, but at
>> least one of the mainstream browsers fails to support it.
> I'm not sure "fails" is the proper word to use, here. [because the
> CSS spec doesn't require conforming UAs to support "blink"]
I understand your point and read the same text from the CSS spec. But
in terms of support for the original questioner's requirement, the
browser fails.
Harry Gibbens, Jr.
I decided to remove the <BLINK> tag for now to validate my webpage
because I don't want any of the browsers fails to recognize the <SPAN
STYLE> tag.
I noticed that on the W3C website, a message reads that all of the
HTML definition tags are NOT setforth permanently. In other words,
there will be more future changes on HTML tags in terms of adding or
modifiying. I hope when the time is right, I may use the <BLINK> tag
if W3C ever recognize it.
~Harry Jr.
Andrew Glasgow
harryj...@deafworks.com (Harry Gibbens, Jr.) wrote:
> I hope when the time is right, I may use the <BLINK> tag
> if W3C ever recognize it.
Why? Haven't you ever noticed how annoying blinking text is?
--
| Andrew Glasgow <amg39(at)cornell.edu> Note: address in header munged. |
| "A computer lets you make more mistakes faster than any invention in human |
| history, with the possible exceptions of handguns and tequila." |
| -- Mitch Ratcliffe, Technology Review, April 1992 |
Harry Gibbens, Jr.
Hi,
I wrote this HTML line:
<textarea name="Comments" rows="6" cols="60"
wrap="virtual"></textarea>
I ran the W3C HTML Validator and learned that <TEXTAREA> tag has an
error message:
Error: there is no attribute "WRAP" for this element (in this HTML
version)
I understood that there is no such thing as "WRAP" on the validator's
TEXTAREA element listing.
But, if I remove "WRAP", the user types in will keep the cursor
continue to scrolling to the right on ONE line forever. This is not
something I want. I want a wordwrap automatically done to the NEXT
line when the cursor reaches to the end of the previous line within
the textarea visual box.
Since the validator does not accept "WRAP", what is the alternative
solution?
Thanks,
Harry Jr.
Harry Gibbens, Jr.
<amg39.RE...@cornell.edu.INVALID> wrote:
>In article <3c369d0a...@news.burgoyne.com>,
> harryj...@deafworks.com (Harry Gibbens, Jr.) wrote:
>
>> I hope when the time is right, I may use the <BLINK> tag
>> if W3C ever recognize it.
>
>Why? Haven't you ever noticed how annoying blinking text is?
>
**** It is all depend on which website you have looked at. If there
were too many "Christmas blinking lights" - that'll annoy me and
what's more, it'll freeze up my browser. Just only ONE blinking text
word in my entire webpage, I don't see it as an annoy. That's my
personal perspective. :)
~Harry Jr.
Simon Brooke
> Hi,
>
> I wrote this HTML line:
>
> <textarea name="Comments" rows="6" cols="60"
> wrap="virtual"></textarea>
>
>
>
> I ran the W3C HTML Validator and learned that <TEXTAREA> tag has an
> error message:
>
>
> Error: there is no attribute "WRAP" for this element (in this HTML
> version)
Yes, that's absolutely right. 'wrap' is a non-standard proprietary
extension, although it is recognised by a lot of browsers these days.
> But, if I remove "WRAP", the user types in will keep the cursor
> continue to scrolling to the right on ONE line forever. This is not
> something I want. I want a wordwrap automatically done to the NEXT
> line when the cursor reaches to the end of the previous line within
> the textarea visual box.
>
> Since the validator does not accept "WRAP", what is the alternative
> solution?
Invalid code. To quote from the documentation for one of my own
products:
/** A textarea widget implemented as an HTML TEXTAREA object. Note:
* The wrap attribute of a textarea widget is not valid HTML 4,
* although it is widely supported. If you set wrap to be anything
* other than the default NO_WRAP, this widget will generate
* technically invalid HTML. This is the only deliberate mistake in
* Jacquard's HTML generation.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
Morning had broken, and we had run out of gas for the welding torch.
Andrew Glasgow
harryj...@deafworks.com (Harry Gibbens, Jr.) wrote:
> On Sun, 06 Jan 2002 22:44:28 -0500, Andrew Glasgow
> <amg39.RE...@cornell.edu.INVALID> wrote:
>
> >In article <3c369d0a...@news.burgoyne.com>,
> > harryj...@deafworks.com (Harry Gibbens, Jr.) wrote:
> >
> >> I hope when the time is right, I may use the <BLINK> tag
> >> if W3C ever recognize it.
> >
> >Why? Haven't you ever noticed how annoying blinking text is?
> >
> **** It is all depend on which website you have looked at. If there
> were too many "Christmas blinking lights" - that'll annoy me and
> what's more, it'll freeze up my browser. Just only ONE blinking text
> word in my entire webpage, I don't see it as an annoy. That's my
> personal perspective. :)
Your perspective is wrong. ^_^
Seriously, any motion (blinking is effectively motion) on a page will
distract and annoy viewers of the page. This is because the human
visual system is very sensitive to motion.
--
| Andrew Glasgow <amg39(at)cornell.edu> Note: address in header munged. |
| "This site was constructed with FrontPage. We regret any inconvenience and |
| irritation this may cause. We're sorry about the whole thing, really, but |
| Frontpage seemed like a good idea at the time." -- Jerry Muelver in alt.html|
Jukka K. Korpela
>> Since the validator does not accept "WRAP", what is the alternative
>> solution?
>
> Invalid code.
This might indeed be one of the rare cases where invalid markup is
justifiable - but _not_ using wrap="virtual", which invokes incorrect
behavior on browsers that would otherwise work well, but using
wrap="off", which makes most of those browsers that by default
incorrectly wrap lines!
A textarea is for input where arbitrarily long input lines are allowed.
If you "need" wrapping (in the processing of user input in a browser) in
a textarea, then you need something that HTML was not meant for, and
you're probably solving a wrong problem. (E.g., you should solve the
problem of making the _form handler_ wrap lines as needed.) More on this:
http://www.cs.tut.fi/~jkorpela/forms/textarea.html
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Simon Brooke
> Simon Brooke <si...@jasmine.org.uk> wrote:
>
> >> Since the validator does not accept "WRAP", what is the alternative
> >> solution?
> >
> > Invalid code.
>
<snip />
> A textarea is for input where arbitrarily long input lines are allowed.
> If you "need" wrapping (in the processing of user input in a browser) in
> a textarea, then you need something that HTML was not meant for, and
> you're probably solving a wrong problem.
Jukka, I generally agree with everything you post, but I don't agree
with this.
Textareas are for input of larger amounts of text. Sometimes this text
necessarily has arbitrarily long lines. Very often it doesn't. Naiive
users, or users carrying expectations over from other software, become
confused and disoriented either when the caret goes out of the
viewport, or the viewport scrolls laterally. For these users, the
'valid' form of the textarea widget is a user-hostile control.
In many cases good user interface design will require the use of
'wrap="soft"', and this is what I would recommend in normal usage - it
is a great shame that the authors of HTML 4 did not make this the
*default* behaviour, overridable with 'wrap="off"'.
I can rarely see justification for 'wrap="hard"', however.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; I'd rather live in sybar-space
Harry Gibbens, Jr.
I created a button that will allow the user to click on to open a new
full window. With the understanding, the window will NOT show those
items (toolbar, menubar, directories, and location). A script is
indicated below that does the job:
function openwindow() {
winConfig='scrollbars=1,resizable=1,toolbar=0,menubar=0,directories=0,location=0'
winConfig+='width=790,height=520'
newWin=window.open("test.htm",+
"",winConfig)
}
The click on button reads "Open Window"
I don't have any problems with above code.
Now, I do have a problem with creating a reload button.
Before clicking the reload button, the window shows those items
(toolbar, menubar, directories, and location). I want to reload into
a full window WITHIN the same existing window without showing those
items automatically making those items disappeared. I wrote a script
below and it appears that it doesn't work (seems has no effect) unless
I have to OPEN a brand new window as shown above script.
function reloadwindow() {
winConfig='scrollbars=1,resizable=1,toolbar=0,menubar=0,directories=0,location=0'
winConfig+='width=790,height=520'
ReloadWin=window.location.reload("test.htm",+
"",winConfig)
}
The click on button reads "Reload Window"
Also, while I am at the full window without those items (toolbar,
menubar, directories, and location), I attempted to reload the window
to restore (re-appeared) those items. Still, it doesn't work (no
effect) at all. A written script:
function restorewindow() {
winConfig='scrollbars=1,resizable=1,toolbar=1,menubar=1,directories=1,location=1'
winConfig+='width=790,height=520'
RestoreWin=window.location.reload("test.htm",+
"",winConfig)
}
The click on button reads "Restore Window"
What did I went wrong with those reload/restore scripts...or is
impossible to do it within the same existing window, but works on new
window only?
Thanks,
Harry Jr.
Chuck Taylor
Gibbens, Jr.) wrote:
[re: window-manipulation scripts]
Try posing your question in comp.lang.javascript.
Harry Gibbens, Jr.
Thanks for the referral. I visited their usergroup. Gee! They
discussed alot about HTML stuffs which they should be in this group.
Someone needs to tell them about this because I am afraid that they
may receive the wrong or misinformation on how to use HTML.
It is like going to a Ford new car dealership and ask about their
sales opinions on their competitor, Toyota. Ford is wrong place to
ask! If I want to know about Toyota stuff, I go to Toyota - not Ford.
Have a good weekend.
~Harry Jr.
Jukka K. Korpela
> Textareas are for input of larger amounts of text. Sometimes this
> text necessarily has arbitrarily long lines. Very often it doesn't.
> Naiive users, or users carrying expectations over from other
> software, become confused and disoriented either when the caret goes
> out of the viewport, or the viewport scrolls laterally.
The fundamental problem here is that there are two different mental
models (and corresponding implementations) of "typing text". The first
one, the older one, is based on explicit line breaks entered by the user.
It corresponds to typing on a typewriter, and it is common among
programmers, and it's also the model on which several Internet protocols
(like E-mail and Usenet protocols) are based. The second one, now more
common among "ordinary users", was introduced by text processing programs
(as opposite to text editors), and it means that the user need not, and
normally should not, hit Enter or Return but just watch the program
divide the text into lines. - Enter or Return generally means end of
_paragraph_ in this model.
Quite some confusion has arisen when the two models, or conventions, have
been used in the same environment without any conventions and
arrangements for conversions. The confusion is described somewhat more
technically at the end of an otherwise all-too-technical Unicode report
on newline guidelines: http://www.unicode.org/unicode/reports/tr13/
The HTML specifications are clearly based on the first mental model as
regards to <textarea>. Quite a many browsers have implemented <textarea>
more or less according to the "text processing" model, at least
optionally. And it's optional in the sense of being, to some extent,
settable by the _author_.
This adds confusion to confusion. If the <textarea> element were
specified more flexibly, it could be a _browser_ option whether it works
in "typewrite mode" or "text processing mode". Each user could then
select the method he is familiar with, or just prefers. But now users
have to guess how each <textarea> works; you can't see it without trying,
or peeking at the HTML markup.
Since both browser behavior and user behavior (i.e., users' understanding
on how their input will be handled, by the browser and by the server, if
they can tell the difference) varies, you cannot really know much of the
intended newlines in input. You can't even know, in general, whether they
were entered by the user or inserted by the "friendly" browser. So if
it's some text that might logically consist of paragraphs, you can't
recognize paragraphs without special conventions. The best workaround is
probably an explicit statement "please use an empty line between
paragraphs", if you wish to be able to recognize paragraphs, as you
probably do quite often (even for a simple guestbook application).
> In many cases good user interface design will require the use of
> 'wrap="soft"', and this is what I would recommend in normal usage -
> it is a great shame that the authors of HTML 4 did not make this the
> *default* behaviour, overridable with 'wrap="off"'.
Wrapping behavior isn't really something that HTML should deal with, is
it? But it's not that important whether we consider it as an HTML issue
or a CSS issue.
Simon Brooke
> Simon Brooke <si...@jasmine.org.uk> wrote:
>
> > Textareas are for input of larger amounts of text. Sometimes this
> > text necessarily has arbitrarily long lines. Very often it doesn't.
> > Naiive users, or users carrying expectations over from other
> > software, become confused and disoriented either when the caret goes
> > out of the viewport, or the viewport scrolls laterally.
>
> The fundamental problem here is that there are two different mental
> models (and corresponding implementations) of "typing text". The first
> one, the older one, is based on explicit line breaks entered by the user.
> It corresponds to typing on a typewriter, and it is common among
> programmers, and it's also the model on which several Internet protocols
> (like E-mail and Usenet protocols) are based. The second one, now more
> common among "ordinary users", was introduced by text processing programs
> (as opposite to text editors), and it means that the user need not, and
> normally should not, hit Enter or Return but just watch the program
> divide the text into lines. - Enter or Return generally means end of
> _paragraph_ in this model.
... and this is the model most naiive users are now accustomed to.
> Quite some confusion has arisen when the two models, or conventions, have
> been used in the same environment without any conventions and
> arrangements for conversions.
> The HTML specifications are clearly based on the first mental model as
> regards to <textarea>. Quite a many browsers have implemented <textarea>
> more or less according to the "text processing" model, at least
> optionally. And it's optional in the sense of being, to some extent,
> settable by the _author_.
Which is, on the whole, how it should be, since there are some forms
of data which you want to collect through a textarea where lineends
are significant, and others where they aren't. Obviously, some
indication to the user of which mode is in use would be a good thing.
> This adds confusion to confusion. If the <textarea> element were
> specified more flexibly, it could be a _browser_ option whether it works
> in "typewrite mode" or "text processing mode".
No, this would make confusion worse, since server-side processing
would then have to guess whether and where the user intended
significant line ends.
> > In many cases good user interface design will require the use of
> > 'wrap="soft"', and this is what I would recommend in normal usage -
> > it is a great shame that the authors of HTML 4 did not make this the
> > *default* behaviour, overridable with 'wrap="off"'.
>
> Wrapping behavior isn't really something that HTML should deal with, is
> it? But it's not that important whether we consider it as an HTML issue
> or a CSS issue.
An input widget that wraps is a different thing from an input widget
which doesn't wrap, just as a set of radio buttons is a different
thing from a set of checkboxes. The difference in behaviour is
important and significant.
It's possibly a mistake to overload the same textarea element for both
widget types, but on the other hand we don't have any problem with the
input being overloaded with numerous widget types. But both behaviours
are necessry in a toolbox of user interface widgets, the two
behaviours are different, and the difference is significant.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; killing afghan civilians is not 'justice'