ping dorayme.....can you fix this problem?

R

richard

http://1littleworld.net/sample/indexa.html

Problem is that when a second link is embedded inside the block, the
desired effect of linking the entire block is changed so that only the text
becomes a link.

Now for you flamers, I know you will harass me over the fact that I use
inches instead of pixels for the blocks. So flame away, I'm not gonna
change it for you.
 
R

richard

http://1littleworld.net/sample/indexa.html

Problem is that when a second link is embedded inside the block, the
desired effect of linking the entire block is changed so that only the text
becomes a link.

Now for you flamers, I know you will harass me over the fact that I use
inches instead of pixels for the blocks. So flame away, I'm not gonna
change it for you.

BTW, I tried it using <ul> instead of a table and got the same result.
 
J

Jonathan N. Little

richard said:
http://1littleworld.net/sample/indexa.html

Problem is that when a second link is embedded inside the block, the
desired effect of linking the entire block is changed so that only the text
becomes a link.

Now for you flamers, I know you will harass me over the fact that I use
inches instead of pixels for the blocks. So flame away, I'm not gonna
change it for you.

Forget that, you have made a more fundamental error. An A element is an
*inline* element and cannot contain a block element. Tip: DIVs and
TABLEs are block elements...
 
R

richard

Forget that, you have made a more fundamental error. An A element is an
*inline* element and cannot contain a block element. Tip: DIVs and
TABLEs are block elements...

I see your point. I changed the "a" properties to display:block and got the
same result in both examples.
Question is then, how do you resolve the issue of linking block elements?
 
J

Jonathan N. Little

richard said:
I see your point. I changed the "a" properties to display:block and got the
same result in both examples.
Question is then, how do you resolve the issue of linking block elements?

It is not a mater of how you style it. It is invalid markup to put a
block element inside an inline element. You need to rethink your design.
 
D

Denis McMahon

http://1littleworld.net/sample/indexa.html

Problem is that when a second link is embedded inside the block, the
desired effect of linking the entire block is changed so that only the text
becomes a link.

Now for you flamers, I know you will harass me over the fact that I use
inches instead of pixels for the blocks. So flame away, I'm not gonna
change it for you.

1) Fix your broken markup

http://validator.w3.org/check?verbose=1&uri=http://1littleworld.net/sample/indexa.html

2) There is a fairly easy method of making some elements that can not
normally be wrapped in an anchor-link appear as if they were one. You
will need to check the DTD for XHTML 1.0 Strict to see if this method
can be applied in this case.

3) If you use the method referenced at (2) above to simulate anchor-link
operation on a block level element, and then include an anchor-link
inside that block level element, you can not guarantee which of the two
destinations will appear if you click on the anchor-link inside the
simulated-anchor-link block.

Rgds

Denis McMahon

p.s. I'll tell you what the method of doing (2) is after and only after
you have corrected the page so that it generates no errors, warnings or
information markers on the validator. If you can not do that, you do not
get told the answer.
 
R

richard

http://1littleworld.net/sample/indexa.html

Problem is that when a second link is embedded inside the block, the
desired effect of linking the entire block is changed so that only the text
becomes a link.

Now for you flamers, I know you will harass me over the fact that I use
inches instead of pixels for the blocks. So flame away, I'm not gonna
change it for you.

Never mind. Got it figured out.
What bugs the hell out of me though is, that damned validator doesn't know
when to stop checking. If you're using javascript on the page, with no link
to an external file, the validator comes across a tag and gives you an
error if it finds one.

It's so damned picky that if you use "&" like in "Bob & Dave" in a text
line, you get smacked with an error then it says, oh but that's ok, it's in
data. So if it's ok, then why the sam hell did you give an error?
 
S

Stanimir Stamenkov

Sat, 29 Jan 2011 17:58:34 -0500, /Jonathan N. Little/:
Forget that, you have made a more fundamental error. An A element is
an *inline* element and cannot contain a block element. Tip: DIVs
and TABLEs are block elements...

Although not a final recommendation, HTML5 is the latest development
representing what modern browsers actually implement.
 
J

Jonathan N. Little

Even lowers my dwindling opinion of this developing standard. Lets make
is easier for the unsavory characters to abuse...
 
S

Stanimir Stamenkov

Sun, 30 Jan 2011 08:43:43 -0500, /Jonathan N. Little/:
Even lowers my dwindling opinion of this developing standard. Lets make
is easier for the unsavory characters to abuse...

Do you have an use case in mind where block-level links will make it
easier to abuse (what)?

See the <http://www.whatwg.org/> site for an example where
block-level links are necessary - a menu where links are not simple
titles but blocks with a title and further description. One wants
the whole blocks to be active (like <button> elements).

Currently, if one wants to validate against HTML 4, one needs to
resort to inline element styling it as a block. This leads to:

* Unnecessary complicated markup, like:

<div><a href="..."><span class="block">...</span></a></div>

instead of:

<a href="..."><div>...</div></a>

Why forbidding the second form if it just makes things easier
for authors and then have no more complications for browser
implementations?

* Styling being optional may result in suboptimal rendering where
author styling not applied.
 
J

Jonathan N. Little

Stanimir said:
Sun, 30 Jan 2011 08:43:43 -0500, /Jonathan N. Little/:

Do you have an use case in mind where block-level links will make it
easier to abuse (what)?

See the <http://www.whatwg.org/> site for an example where block-level
links are necessary - a menu where links are not simple titles but
blocks with a title and further description. One wants the whole blocks
to be active (like <button> elements).

Currently, if one wants to validate against HTML 4, one needs to resort
to inline element styling it as a block. This leads to:

* Unnecessary complicated markup, like:

<div><a href="..."><span class="block">...</span></a></div>

instead of:

<a href="..."><div>...</div></a>

Why forbidding the second form if it just makes things easier for
authors and then have no more complications for browser implementations?

* Styling being optional may result in suboptimal rendering where author
styling not applied.


<html>
<head><title>Lollipop Guild</title></head>
<body>
<a href="somewherenasty" onclick="somethingbad()">
<div>
Innocent looking page...

<span class="fakelink" title="http://www.safeplace.com">Somewhere
Safe</span>
....

</div>
</a>
</body>
</html>
 
S

Stanimir Stamenkov

Sun, 30 Jan 2011 10:05:35 -0500, /Jonathan N. Little/:
<html>
<head><title>Lollipop Guild</title></head>
<body>
<a href="somewherenasty" onclick="somethingbad()">
<div>
Innocent looking page...

<span class="fakelink" title="http://www.safeplace.com">Somewhere
Safe</span>
...

</div>
</a>
</body>
</html>

If one wants to do such nasty stuff, nothing prevents him from doing
it even in an HTML 4 valid way (as pointed previously). But I don't
think people making such nasty stuff care about validation -
browsers don't care about nesting block-level into inline-level
elements for years.

The exact abuse in your example is applicable for simple links also:

<a href="http://www.safeplace.com/"
onclick="somethingbad()">Somewhere Safe</a>

Let alone 'somethingbad()' could be triggered by a simple mouse move
(no need for active content):

<html>
<head><title>Lollipop Guild</title></head>
<body onmousemove="somethingbad()">
<div>
Innocent looking page...
</div>
</body>
</html>
 
D

Denis McMahon

Never mind. Got it figured out.

No you haven't, and you never will, but dream on.
What bugs the hell out of me though is, that damned validator doesn't know
when to stop checking. If you're using javascript on the page, with no link
to an external file, the validator comes across a tag and gives you an
error if it finds one.

I think you mean these errors:

required attribute "type" not specified

It's nothing to do with using or not using an external file. type is a
required attribute for script and style elements.
It's so damned picky that if you use "&" like in "Bob & Dave" in a text
line, you get smacked with an error then it says, oh but that's ok, it's in
data. So if it's ok, then why the sam hell did you give an error?

The warning message is actually:

character "&" is the first character of a delimiter but occurred as data

So what it's telling you is that you can not use "&" as data, not that
it's ok that you did so.

I note that your clue level is, if anything, reducing with time.

Rgds

Denis McMahon
 
J

Jonathan N. Little

Stanimir said:
Sun, 30 Jan 2011 10:05:35 -0500, /Jonathan N. Little/:


If one wants to do such nasty stuff, nothing prevents him from doing it
even in an HTML 4 valid way (as pointed previously). But I don't think
people making such nasty stuff care about validation - browsers don't
care about nesting block-level into inline-level elements for years.

The exact abuse in your example is applicable for simple links also:

<a href="http://www.safeplace.com/" onclick="somethingbad()">Somewhere
Safe</a>

Let alone 'somethingbad()' could be triggered by a simple mouse move (no
need for active content):

<html>
<head><title>Lollipop Guild</title></head>
<body onmousemove="somethingbad()">
<div>
Innocent looking page...
</div>
</body>
</html>

One REQUIRES JavaScript, the other does not. Also having the whole page
a link can mean that a innocent click not intending to click any link
can be a link click...a little like those popups with the fake min, max,
and close control but in reality the whole popups is just a link with an
image.

There was a time that invalid markup of a nested links was explored
until browsers where patched...

I just think is it is a bad idea and too ease to exploit...
 
S

Stanimir Stamenkov

Sun, 30 Jan 2011 11:32:42 -0500, /Jonathan N. Little/:
One REQUIRES JavaScript, the other does not.

O.k. I was misled by the script usage. So if we ignore the
scripting stuff, the example you give should indicate the whole page
as href="somewherenasty" and the user _could_ (but not necessary) be
misled by the title="http://www.safeplace.com", _only_ if he/she
happens to mouse over the <span class="fakelink">. That's not very
different from:

<a href="somewherenasty" title="http://www.safeplace.com">Somewhere
Safe said:
Also having the whole
page a link can mean that a innocent click not intending to click
any link can be a link click...a little like those popups with the
fake min, max, and close control but in reality the whole popups is
just a link with an image.

There was a time that invalid markup of a nested links was explored
until browsers where patched...

I just think is it is a bad idea and too ease to exploit...

I really don't see it easing exploits any more than currently it is
possible. It just officially allows block-level elements to be
links making certain non-malicious use cases valid. Note also the
standard says if the <a> element is descendant in an inline-level
element it can't contain block-level elements:

Invalid:

<span>...<a href="...">...<div>...</div>...</a>...</span>

Valid:

<span>...<a href="...">...<span>...</span>...</a>...</span>
<div>...<a href="...">...<div>...</div>...</a>...</div>
<div>...<a href="...">...<span>...</span>...</a>...</div>
 
J

Jonathan N. Little

Stanimir said:
Sun, 30 Jan 2011 11:32:42 -0500, /Jonathan N. Little/:

O.k. I was misled by the script usage. So if we ignore the scripting
stuff, the example you give should indicate the whole page as
href="somewherenasty" and the user _could_ (but not necessary) be misled
by the title="http://www.safeplace.com", _only_ if he/she happens to
mouse over the <span class="fakelink">. That's not very different from:

That was me covering all bases
<a href="somewherenasty" title="http://www.safeplace.com">Somewhere
Safe</a>

No, with the ability proposed, you could make the whole page the link so
clicking anywhere on the page, even an image with the word "close" or
"cancel" present to complete the human engineering...
I really don't see it easing exploits any more than currently it is
possible. It just officially allows block-level elements to be links
making certain non-malicious use cases valid. Note also the standard
says if the <a> element is descendant in an inline-level element it
can't contain block-level elements:

Invalid:

<span>...<a href="...">...<div>...</div>...</a>...</span>

Valid:

<span>...<a href="...">...<span>...</span>...</a>...</span>
<div>...<a href="...">...<div>...</div>...</a>...</div>
<div>...<a href="...">...<span>...</span>...</a>...</div>

I don't see the advantage. Why would anyone want a paragraph to be a
link, although you could now great it now:

<p><a href="example.com">Lorem ipsum dolor ... </a></p>

or a table or nay other block element, when you can either style the
link or the inline element within to display block?
 
R

richard

No you haven't, and you never will, but dream on.


I think you mean these errors:

required attribute "type" not specified

It's nothing to do with using or not using an external file. type is a
required attribute for script and style elements.


The warning message is actually:

character "&" is the first character of a delimiter but occurred as data

So what it's telling you is that you can not use "&" as data, not that
it's ok that you did so.

I note that your clue level is, if anything, reducing with time.

Rgds

Denis McMahon

As I have found out, if there are no other errors, the "&" error isn't even
mentioned.
 
D

dorayme

Stanimir Stamenkov said:
Currently, if one wants to validate against HTML 4, one needs to
resort to inline element styling it as a block. This leads to:

* Unnecessary complicated markup, like:

<div><a href="..."><span class="block">...</span></a></div>

instead of:

<a href="..."><div>...</div></a>
Perhaps it is unnecessarily egging the pudding putting the first
alternative so? Why not, to be fairer, it not looking more
complicated:

<div><a class="block" href="...">...</a></div>

....
* Styling being optional may result in suboptimal rendering where
author styling not applied.

Well, that is always the risk where competent author styling is
disabled. Nevertheless, perhaps you are making a good point that
the danger is particularly acute here.
 
S

Stanimir Stamenkov

Sun, 30 Jan 2011 13:43:41 -0500, /Jonathan N. Little/:
No, with the ability proposed, you could make the whole page the
link so clicking anywhere on the page, even an image with the word
"close" or "cancel" present to complete the human engineering...

But then the user will get indication he is over a link to
"somewherenasty" and clicking the mouse will follow it. Yes, it
could be that the user could miss this indication, but again,
achieving this currently is no any harder (if all one wants is to
mislead the user).
Why would anyone want a paragraph to be a
link, although you could now great it now:

<p><a href="example.com">Lorem ipsum dolor ... </a></p>

or a table or nay other block element, when you can either style the
link or the inline element within to display block?

I've already given an example, but again:

<a href="section1.html">
<h2>Section 1</h2>
<p>Section about...</p>
</a>

<a href="section2.html">
<h2>Section 2</h2>
<p>Section about...</p>
</a>

The benefit is one could use richer markup including block-level
elements like headings and paragraphs. Using <span>s may not be as
expressive (let alone default styling, if no author styles are applied):

<div>
<a href="section1.html">
<strong>Section 1</strong>
<span>Section about...</span>
</a>
</div>

<div>
<a href="section2.html">
<strong>Section 2</strong>
<span>Section about...</span>
</a>
</div>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top