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

Discussion in 'HTML' started by richard, Jan 29, 2011.

  1. richard

    richard Guest

    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.
    richard, Jan 29, 2011
    #1
    1. Advertising

  2. richard

    richard Guest

    On Sat, 29 Jan 2011 15:11:52 -0700, richard wrote:

    > 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.
    richard, Jan 29, 2011
    #2
    1. Advertising

  3. richard wrote:
    > 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...

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 29, 2011
    #3
  4. richard

    richard Guest

    On Sat, 29 Jan 2011 17:58:34 -0500, Jonathan N. Little wrote:

    > richard wrote:
    >> 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...


    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?
    richard, Jan 29, 2011
    #4
  5. richard wrote:
    > 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.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 29, 2011
    #5
  6. On 29/01/11 22:11, richard wrote:
    > 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.
    Denis McMahon, Jan 30, 2011
    #6
  7. richard

    richard Guest

    On Sat, 29 Jan 2011 15:11:52 -0700, richard wrote:

    > 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?
    richard, Jan 30, 2011
    #7
  8. richard the sto0pid wrote:

    > Never mind. Got it figured out.


    No, you don't.

    --
    -bts
    -In a broadband world, you are just a dialup
    Beauregard T. Shagnasty, Jan 30, 2011
    #8
  9. 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.

    <http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>:

    > Contexts in which this element can be used:
    > When the element only contains phrasing content: where phrasing
    > content is expected.
    > Otherwise: where flow content is expected.
    > (...)
    > The a element may be wrapped around entire paragraphs, lists,
    > tables, and so forth, even entire sections, so long as there is no
    > interactive content within (e.g. buttons or other links).


    --
    Stanimir
    Stanimir Stamenkov, Jan 30, 2011
    #9
  10. Stanimir Stamenkov wrote:
    > <http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>:
    >
    >> Contexts in which this element can be used:
    >> When the element only contains phrasing content: where phrasing
    >> content is expected.
    >> Otherwise: where flow content is expected.
    >> (...)
    >> The a element may be wrapped around entire paragraphs, lists,
    >> tables, and so forth, even entire sections, so long as there is no
    >> interactive content within (e.g. buttons or other links).


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

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 30, 2011
    #10
  11. Sun, 30 Jan 2011 08:43:43 -0500, /Jonathan N. Little/:
    > Stanimir Stamenkov wrote:
    >
    >> <http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>:
    >>
    >>> Contexts in which this element can be used:
    >>> When the element only contains phrasing content: where phrasing
    >>> content is expected.
    >>> Otherwise: where flow content is expected.
    >>> (...)
    >>> The a element may be wrapped around entire paragraphs, lists,
    >>> tables, and so forth, even entire sections, so long as there is no
    >>> interactive content within (e.g. buttons or other links).

    >
    > 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.

    --
    Stanimir
    Stanimir Stamenkov, Jan 30, 2011
    #11
  12. Stanimir Stamenkov wrote:
    > Sun, 30 Jan 2011 08:43:43 -0500, /Jonathan N. Little/:
    >> Stanimir Stamenkov wrote:
    >>
    >>> <http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>:
    >>>
    >>>> Contexts in which this element can be used:
    >>>> When the element only contains phrasing content: where phrasing
    >>>> content is expected.
    >>>> Otherwise: where flow content is expected.
    >>>> (...)
    >>>> The a element may be wrapped around entire paragraphs, lists,
    >>>> tables, and so forth, even entire sections, so long as there is no
    >>>> interactive content within (e.g. buttons or other links).

    >>
    >> 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.
    >



    <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>


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 30, 2011
    #12
  13. 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>

    --
    Stanimir
    Stanimir Stamenkov, Jan 30, 2011
    #13
  14. On 30/01/11 04:55, richard wrote:

    > 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
    Denis McMahon, Jan 30, 2011
    #14
  15. Stanimir Stamenkov wrote:
    > 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>
    >


    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...

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 30, 2011
    #15
  16. Sun, 30 Jan 2011 11:32:42 -0500, /Jonathan N. Little/:
    > Stanimir Stamenkov wrote:
    >> 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>

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

    >
    > 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</a>

    > 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>

    --
    Stanimir
    Stanimir Stamenkov, Jan 30, 2011
    #16
  17. Stanimir Stamenkov wrote:
    > Sun, 30 Jan 2011 11:32:42 -0500, /Jonathan N. Little/:
    >> Stanimir Stamenkov wrote:
    >>> 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>
    >>>
    >>> (...)
    >>> Let alone 'somethingbad()' could be triggered by a simple mouse
    >>> move (no need for active content):

    >>
    >> 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:
    >


    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...

    >> 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>
    >


    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?

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jan 30, 2011
    #17
  18. richard

    richard Guest

    On Sun, 30 Jan 2011 16:00:33 +0000, Denis McMahon wrote:

    > On 30/01/11 04:55, richard wrote:
    >
    >> 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


    As I have found out, if there are no other errors, the "&" error isn't even
    mentioned.
    richard, Jan 30, 2011
    #18
  19. richard

    dorayme Guest

    In article <ii3rfh$q6$-september.org>,
    Stanimir Stamenkov <> wrote:

    > 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.

    --
    dorayme
    dorayme, Jan 30, 2011
    #19
  20. Sun, 30 Jan 2011 13:43:41 -0500, /Jonathan N. Little/:
    > Stanimir Stamenkov wrote:
    >
    >> <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...


    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>

    --
    Stanimir
    Stanimir Stamenkov, Jan 30, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee
    Replies:
    22
    Views:
    1,108
    Tim Roberts
    Mar 21, 2006
  2. Luigi Donatello Asero

    [OT] Dorayme and movies

    Luigi Donatello Asero, Jan 6, 2006, in forum: HTML
    Replies:
    0
    Views:
    374
    Luigi Donatello Asero
    Jan 6, 2006
  3. Xah Lee
    Replies:
    23
    Views:
    1,047
    Tim Roberts
    Mar 21, 2006
  4. richard

    ping dorayme

    richard, Aug 9, 2009, in forum: HTML
    Replies:
    3
    Views:
    438
    dorayme
    Aug 9, 2009
  5. Xah Lee
    Replies:
    21
    Views:
    766
    Tim Roberts
    Mar 21, 2006
Loading...

Share This Page