By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,236 Members | 1,354 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,236 IT Pros & Developers. It's quick & easy.

target

P: n/a
Hello
How do i get around target="_blank" is not allowed in xtml strict?
Thanks
Mike
Jul 20 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
On Thu, 22 Jan 2004 20:10:03 -0500, "Mike" <mi**@nospam.net> declared in
comp.infosystems.www.authoring.html:
Hello
G'day.
How do i get around target="_blank" is not allowed in xtml strict?


You leave it up to me. If I want a new window (or tab) opened, I can do
it myself.

Your consideration is appreciated.

--
Mark Parnell
http://www.clarkecomputers.com.au
Jul 20 '05 #2

P: n/a
Mike <mi**@nospam.net> wrote:
How do i get around target="_blank" is not allowed in xtml strict?


"Get around" it by not using it. This attribute was removed for a reason.
--
Michael Wilcox
mjwilco at yahoo dot com
Essential Tools for the Web Developer - http://mikewilcox.t35.com
Jul 20 '05 #3

P: n/a
On Fri, 23 Jan 2004 01:27:42 GMT, "Michael Wilcox"
<mj*****************@yahoo.com> wrote:
"Get around" it by not using it. This attribute was removed for a reason.


But not that one.

(Google)

Jul 20 '05 #4

P: n/a
DU
Mike wrote:
Hello
How do i get around target="_blank" is not allowed in xtml strict?
Thanks
Mike


This was discussed a lot before (maybe not in this newsgroup but
definitively in alt.html).
Either switch to XHTML 1.0 transitional or drop the target attribute.

If the long term, I think it's better to find an alternative to
requested popups as more and more browsers have (and new versions will
have) contextmenu commands allowing them to open referenced
resources/links into a new tab, in a new window and this, in background
or not. E.g.: K-meleon 0.8.2 (and probably recent Mozilla-based browser
versions) can open any link in at least 5 different manners and it will
override target attribute.

DU
Jul 20 '05 #5

P: n/a
"DU" <dr*******@hotWIPETHISmail.com> schrieb im Newsbeitrag
news:bu**********@news.eusc.inter.net...
Mike wrote:
Hello
How do i get around target="_blank" is not allowed in xtml strict?
Thanks
Mike


This was discussed a lot before (maybe not in this newsgroup but
definitively in alt.html).
Either switch to XHTML 1.0 transitional or drop the target attribute.

If the long term, I think it's better to find an alternative to
requested popups as more and more browsers have (and new versions will
have) contextmenu commands allowing them to open referenced
resources/links into a new tab, in a new window and this, in background
or not. E.g.: K-meleon 0.8.2 (and probably recent Mozilla-based browser
versions) can open any link in at least 5 different manners and it will
override target attribute.

DU


I have read some of these discussions and also googled for the topic for
some hours as I ran in the same recently. I see the point about
target="_blank" in connection with tabbed browsing and things like that.

There is just one point I consider as not consistent: There is a frameset
doctype. So, regardless of if you consider frames as bad or not, they are
part of the standards. So the standards should also provide a possibility to
navigate inside them. As they are now, I have to either use javascript or a
transitional doctype if I want to use frames; and both is worse than a
target attribute.

--
Markus
Jul 20 '05 #6

P: n/a
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:
There is just one point I consider as not consistent: There is a frameset
doctype. So, regardless of if you consider frames as bad or not, they are
part of the standards. So the standards should also provide a possibility to
navigate inside them.
They do. It's called the Transitional DTD.
As they are now, I have to either use javascript or a
transitional doctype if I want to use frames; and both is worse than a
target attribute.


If you are using frames then you are automatically writing (X)HTML
that is not in the spirit of Strict. In fact if you look in depth at
the Frameset DTD you will see that it's actually based on the
Transitional DTD (i.e. the content that goes inside the <noframes>
element follows Transitional not Strict rules). Transitional is what
you're supposed to use if you want to use the target attribute. So use
Transitional.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #7

P: n/a
Markus Ernst wrote:
"DU" <dr*******@hotWIPETHISmail.com> schrieb im Newsbeitrag
news:bu**********@news.eusc.inter.net...
Mike wrote:
How do i get around target="_blank" is not allowed in xtml
strict?
Either switch to XHTML 1.0 transitional or drop the target
attribute.


There is just one point I consider as not consistent:


It's perfectly consistent.
There is a frameset doctype.
Then why were you asking about target="_blank"? That's used to try to
open a new window. So it's no wonder the answers that you received
were about new windows, and not frames.
So, regardless of if you consider frames as bad or not, they are
part of the standards.
And those standards describe how to manipulate frames to the extent
possible. I don't write in xhtml, and am unfamiliar with the spec; I
can never find what I need in it. But perhaps the corresponding part
in html4 will help.

http://www.w3.org/TR/html4/types.html#type-frame-target
So the standards should also provide a possibility to navigate
inside them.
As well they do.
As they are now, I have to either use javascript
bad idea, since not all clients will process js.
or a transitional doctype if I want to use frames;
Correct. You must transitional doctype for the documents included in a
frameset if you need the target attribute, which you almost certainly
will.
and both is worse than target attribute.


Not sure how to read this. You need the target attribute to use the
frameset. If you don't want to use target, then lose the frameset,
which is a good idea in any case.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #8

P: n/a
DU
Markus Ernst wrote:
"DU" <dr*******@hotWIPETHISmail.com> schrieb im Newsbeitrag
news:bu**********@news.eusc.inter.net...
Mike wrote:

Hello
How do i get around target="_blank" is not allowed in xtml strict?
Thanks
Mike
This was discussed a lot before (maybe not in this newsgroup but
definitively in alt.html).
Either switch to XHTML 1.0 transitional or drop the target attribute.

If the long term, I think it's better to find an alternative to
requested popups as more and more browsers have (and new versions will
have) contextmenu commands allowing them to open referenced
resources/links into a new tab, in a new window and this, in background
or not. E.g.: K-meleon 0.8.2 (and probably recent Mozilla-based browser
versions) can open any link in at least 5 different manners and it will
override target attribute.

DU

I have read some of these discussions and also googled for the topic for
some hours as I ran in the same recently. I see the point about
target="_blank" in connection with tabbed browsing and things like that.


The user gets more and more control over how documents should open. The
scripter and the web developer gets less and less power over how
documents should open. That's a clear, undeniable, indisputable trend
happening now in many browsers.
It was said loud and clear that MSIE 7 for windows would have tab
browsing; already MyIE2 has been supporting tab browsing for a long
time. It's already known that MSIE 6.05 SP2 for windows will give users
the ability to block, suppress unrequested popups just like so many
browsers do right now.
There is just one point I consider as not consistent: There is a frameset
doctype. So, regardless of if you consider frames as bad or not, they are
part of the standards. So the standards should also provide a possibility to
navigate inside them. As they are now, I have to either use javascript or a
transitional doctype if I want to use frames; and both is worse than a
target attribute.


Frames are bad. After reading on the issue, I had no idea how much they
were bad. I am even beginning to think that iframes as well are not
recommendable or imply a considerable usability burden in a wide
majority of cases. My mind is not fully made up on the iframe issue though.

Overall, I'm convinced you get the most benefits of complying with W3C
web standards (code once, read anywhere; speed; interoperability;
accessibility; etc..) by coding to strict definition more than you do by
choosing XHTML over HTML.

DU
DU
Jul 20 '05 #9

P: n/a
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:
There is just one point I consider as not consistent: There is a
frameset doctype. So, regardless of if you consider frames as bad
or not, they are part of the standards.
If you wish to call W3C recommendations standards, yes. (Frames are not
part of the International Standard for HTML, but that's rather
irrelevant, since few people even heard of ISO HTML.)
So the standards should
also provide a possibility to navigate inside them.
They do.
As they are
now, I have to either use javascript or a transitional doctype if I
want to use frames; and both is worse than a target attribute.


Pardon? The target attribute is part of the Transitional doctype. What
else do you want? What actual harm does it cause that you are said to
use the Transitional version when you use the target attribute? If it
makes you feel somehow impure, well, maybe you should. Frames,
especially as commonly used and implemented, are typically much worse
than a casual <font> or an occasional piece of text directly inside
<body>.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #10

P: n/a
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in
news:40**********************@news.easynet.ch:
provide a possibility to navigate inside them. As they are now, I have
to either use javascript or a transitional doctype if I want to use
frames; and both is worse than a target attribute.


I'm sorry; I really can't resist...

Part of that last phrase should be marked up as:

<span lang="en-gwb">both is worse</span>
Jul 20 '05 #11

P: n/a
"Eric Bohlman" <eb******@earthlink.net> schrieb im Newsbeitrag
news:Xn******************************@130.133.1.4. ..
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in
news:40**********************@news.easynet.ch:
provide a possibility to navigate inside them. As they are now, I have
to either use javascript or a transitional doctype if I want to use
frames; and both is worse than a target attribute.


I'm sorry; I really can't resist...

Part of that last phrase should be marked up as:

<span lang="en-gwb">both is worse</span>


Sorry I am not a native English speaker - could you explain? I was googling
for "en-gwb" but did only find some dutch pages that do not help.

Anyway I saw I made a mistake and should apparently have written "both are
worse". If anybody feels insulted by bad English I apologize :-)

Thanks
Markus
Jul 20 '05 #12

P: n/a
"Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:je********************************@4ax.com...
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:
There is just one point I consider as not consistent: There is a frameset
doctype. So, regardless of if you consider frames as bad or not, they are
part of the standards. So the standards should also provide a possibility tonavigate inside them.


They do. It's called the Transitional DTD.
As they are now, I have to either use javascript or a
transitional doctype if I want to use frames; and both is worse than a
target attribute.


If you are using frames then you are automatically writing (X)HTML
that is not in the spirit of Strict. In fact if you look in depth at
the Frameset DTD you will see that it's actually based on the
Transitional DTD (i.e. the content that goes inside the <noframes>
element follows Transitional not Strict rules). Transitional is what
you're supposed to use if you want to use the target attribute. So use
Transitional.


Thanks everybody for your replies. I was not enough aware of this before.

Actually I would love to use position:fixed and/or overflow:scroll, but the
browser support is too poor. IE 5 and 6 will not disappear for years, and
some big ISPs even still distribute Netscape 4.x in their starter kits!

--
Markus
Jul 20 '05 #13

P: n/a
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:
"Eric Bohlman" <eb******@earthlink.net> schrieb im Newsbeitrag
news:Xn******************************@130.133.1.4 ...
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in
news:40**********************@news.easynet.ch:
> provide a possibility to navigate inside them. As they are now, I have
> to either use javascript or a transitional doctype if I want to use
> frames; and both is worse than a target attribute.


I'm sorry; I really can't resist...

Part of that last phrase should be marked up as:

<span lang="en-gwb">both is worse</span>


Sorry I am not a native English speaker - could you explain? I was googling
for "en-gwb" but did only find some dutch pages that do not help.


"en" is English; en-XX normally means English as spoken in country XX.
So British English is en-GB, US English is en-US. However, I think
"gwb" stands for George W Bush...

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #14

P: n/a
On Mon, 26 Jan 2004 14:40:25 +0100, Markus Ernst <derernst@NO#SP#AMgmx.ch>
wrote:
"Eric Bohlman" <eb******@earthlink.net> schrieb im Newsbeitrag
news:Xn******************************@130.133.1.4. ..
<span lang="en-gwb">both is worse</span>


Sorry I am not a native English speaker - could you explain? I was
googling
for "en-gwb" but did only find some dutch pages that do not help.

Anyway I saw I made a mistake and should apparently have written "both
are
worse". If anybody feels insulted by bad English I apologize :-)

It was a joke. GWB is George W. Bush, and this is a typical nonsensical
phrase he seems to burst forth on a pretty regular basis. I'm sure your
English is at least as good, if not gooder, than the US president.
Jul 20 '05 #15

P: n/a
On Mon, 26 Jan 2004 15:04:42 +0100, Markus Ernst <derernst@NO#SP#AMgmx.ch>
wrote:
Actually I would love to use position:fixed and/or overflow:scroll, but
the
browser support is too poor. IE 5 and 6 will not disappear for years, and
some big ISPs even still distribute Netscape 4.x in their starter kits!

Fortunately, IE treats fixed like absolute, so it will not break your page.

In fact, at one time I was going to use fixed on an element, but when I
realized that smaller viewports would not be able to see it all, I
abandoned it. I don't see fixed as too terribly useful, except perhaps as
a small header, because of that scrolling problem.

overflow: scroll would be nice, though...
Jul 20 '05 #16

P: n/a
Neal <ne*****@spamrcn.com> wrote:
<span lang="en-gwb">both is worse</span>
- - It was a joke.


It was a poor joke, or a good joke, depending on the way you look at
it. At level 1, it was banal. At level 2, it might be seen as a form of
self-irony.

Since "en-gwb", as a language code (or "tag" in RFC 3066 parlance) is
of a format defined as being administered by IANA, and has not in fact
been registered, then anyone using it makes a fool of himself, to some
extent. If the intent was to ridicule another person for his use of
language, then there's a not-so-subtle unintentional self-irony
involved.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #17

P: n/a
"Neal" <ne*****@spamrcn.com> schrieb im Newsbeitrag
news:op**************@news.rcn.com...
On Mon, 26 Jan 2004 15:04:42 +0100, Markus Ernst <derernst@NO#SP#AMgmx.ch>
wrote:
Actually I would love to use position:fixed and/or overflow:scroll, but
the
browser support is too poor. IE 5 and 6 will not disappear for years, and some big ISPs even still distribute Netscape 4.x in their starter kits!
Fortunately, IE treats fixed like absolute, so it will not break your

page.
In fact, at one time I was going to use fixed on an element, but when I
realized that smaller viewports would not be able to see it all, I
abandoned it. I don't see fixed as too terribly useful, except perhaps as
a small header, because of that scrolling problem.
In some cases it is just useful to have the navigation bar staying visible.
To not break pages on small viewports you can provide an alternate
stylesheet for handhelds.

It would be very helpful to have the possibility to distinguish fixed and
absolute positions for x and y dimensions, i.e. define the left position as
absolute and the top position as fixed, which would not break the page for a
left navigation bar, as it would be horizontally scrollable if necessary.

Also things would be easier to code strict-compatible if there would be
relative values, like "width:100%-#navigation.width". As it is now, very
simple tasks like using a logo gif in connection with relative values can
break a page if the viewport is too small or font sizes are increased by the
user agent.

Well, these are dreams :-)
overflow: scroll would be nice, though...


This is much more realistic.
Jul 20 '05 #18

P: n/a
On Mon, 26 Jan 2004 20:44:52 +0100, Markus Ernst <derernst@NO#SP#AMgmx.ch>
wrote:
In some cases it is just useful to have the navigation bar staying
visible.
To not break pages on small viewports you can provide an alternate
stylesheet for handhelds.
Well, what I as referring to was navigation sidebars taller than a few
hundred pixels. Unless I'm sure all users are running a screen res of
800x600 any fixed element taller than 600 pixels will potentially run off
their screen. As there are still monitors using smaller resolutions in
use, fixed is something to be carefully considered.

If your application is for a closed network where you are assured each
user has a particular screen res, there's more leeway possible. But
typically this type of environment will be running IE anyway, so it's moot.

Also things would be easier to code strict-compatible if there would be
relative values, like "width:100%-#navigation.width".


Agreed. I'd like it if a future version of CSS could allow a bit of math
in the calculations of distances, so to clear a positioned image with 1em
of margin space we could set an element {margin-left: 167px+1em;} or
something.
Jul 20 '05 #19

P: n/a
In article <op**************@news.rcn.com>,
Neal <ne*****@spamrcn.com> writes:
Fortunately, IE treats fixed like absolute, so it will not break your page.
Not as I've seen it, it doesn't.
In fact, at one time I was going to use fixed on an element, but when I
realized that smaller viewports would not be able to see it all, I
abandoned it. I don't see fixed as too terribly useful, except perhaps as
a small header, because of that scrolling problem.


I like it for a menu of links. Put it at the bottom so text-only
readers don't have to waste time tabbing through every link, but #fix
it at the top for the benefit of graphical browsers. MSIE gets
the same fallback as Lynx.

Example: http://apache.webthing.com/

--
Nick Kew
Jul 20 '05 #20

P: n/a
On Mon, 26 Jan 2004 16:59:46 -0500, Neal <ne*****@spamrcn.com> wrote:


Well, what I as referring to was navigation sidebars taller than a few
hundred pixels. Unless I'm sure all users are running a screen res of
800x600 any fixed element taller than 600 pixels will potentially run off
their screen.


Such an example can be found at:

<http://www.w3.org/Style/CSS/>

in which the bottom menu item(s) is not visible to me running at 800 x
600 (using Mozilla 1.4).

Nick
--
Nick Theodorakis
ni**************@hotmail.com
nicholas_theodorakis [at] urmc [dot] rochester [dot] edu
Jul 20 '05 #21

P: n/a
/Nick Theodorakis/:
On Mon, 26 Jan 2004 16:59:46 -0500, Neal <ne*****@spamrcn.com> wrote:
Well, what I as referring to was navigation sidebars taller than a few
hundred pixels. Unless I'm sure all users are running a screen res of
800x600 any fixed element taller than 600 pixels will potentially run off
their screen.


Such an example can be found at:

<http://www.w3.org/Style/CSS/>

in which the bottom menu item(s) is not visible to me running at 800 x
600 (using Mozilla 1.4).


There are number of alternative styles to choose. Unfortunately
Mozilla doesn't remember the choice when you leave and re-enter the
page.

--
Stanimir
Jul 20 '05 #22

P: n/a
"Nick Theodorakis" <ni**************@hotmail.com> schrieb im Newsbeitrag
news:40***************@netnews.worldnet.att.net...
On Mon, 26 Jan 2004 16:59:46 -0500, Neal <ne*****@spamrcn.com> wrote:


Well, what I as referring to was navigation sidebars taller than a few
hundred pixels. Unless I'm sure all users are running a screen res of
800x600 any fixed element taller than 600 pixels will potentially run off
their screen.


Such an example can be found at:

<http://www.w3.org/Style/CSS/>

in which the bottom menu item(s) is not visible to me running at 800 x
600 (using Mozilla 1.4).


Ooops - nice example :-) Let's say: "Optimized for 1024 x 768 pixels and
Netscape 7.0" is not actually what the W3C stands for.

--
Markus
Jul 20 '05 #23

P: n/a
"Stanimir Stamenkov" <s7****@netscape.net> schrieb im Newsbeitrag
news:bv************@ID-207379.news.uni-berlin.de...
/Nick Theodorakis/:
On Mon, 26 Jan 2004 16:59:46 -0500, Neal <ne*****@spamrcn.com> wrote:
Well, what I as referring to was navigation sidebars taller than a few
hundred pixels. Unless I'm sure all users are running a screen res of
800x600 any fixed element taller than 600 pixels will potentially run off their screen.


Such an example can be found at:

<http://www.w3.org/Style/CSS/>

in which the bottom menu item(s) is not visible to me running at 800 x
600 (using Mozilla 1.4).


There are number of alternative styles to choose. Unfortunately
Mozilla doesn't remember the choice when you leave and re-enter the
page.


I did not find out how to make the choice, though I saw the style sheets in
the source.

--
Markus
Jul 20 '05 #24

P: n/a
/Markus Ernst/:
"Stanimir Stamenkov" <s7****@netscape.net> schrieb im Newsbeitrag
news:bv************@ID-207379.news.uni-berlin.de...
/Nick Theodorakis/:
<http://www.w3.org/Style/CSS/>

in which the bottom menu item(s) is not visible to me running at 800 x
600 (using Mozilla 1.4).


There are number of alternative styles to choose. Unfortunately
Mozilla doesn't remember the choice when you leave and re-enter the
page.


I did not find out how to make the choice, though I saw the style sheets in
the source.


Using Mozilla/Netscape: View -> Use Style -> ...

--
Stanimir
Jul 20 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.