SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 47
  1. #1
    SitePoint Wizard bronze trophy PicnicTutorials's Avatar
    Join Date
    Dec 2007
    Location
    Carlsbad, California, United States
    Posts
    3,658
    Mentioned
    15 Post(s)
    Tagged
    0 Thread(s)

    html5 = <a><div></a>

    I didn't know that. http://html5doctor.com/block-level-links-in-html-5/.

    I think I'll make the switch.

  2. #2
    SitePoint Wizard bronze trophy chris.upjohn's Avatar
    Join Date
    Apr 2010
    Location
    Melbourne, AU
    Posts
    2,197
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I find this to be an extremely difficult concept to understand since XHTML tells us not to do this, I have been working with jQuery Mobile which uses the technique but I just can't get used to it.


    Sent from my iPhone using Tapatalk

  3. #3
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    See the following:
    Quote Originally Posted by Stephen Chapman View Post
    Quote Originally Posted by Robert Wellock
    Actually Poes, I was thinking something more like: <p id="<!--<a><div>http://html5sucks.org/</div></a>-->"></p> for a valid HTML5 id attribute value.
    That's the second best demonstration of HTML 5 stupidity that I have come across so far. The best being the "mandatory empty" input field definition at the bottom of my sig.
    Obviously I was purposely demonstrating at least two nonsense ideas there, that would be perfectly valid. No doubt you'll get some idiots wrapping TABLE in anchor.

  4. #4
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,301
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    It's known as the principle of "paving the cowpats".

  5. #5
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    This is a very good idea. But does it work? I remember seeing if it was possible a couple of years ago and it always broke things in firefox.

    @chris.upjohn that's interesting. Why does XHTML tell us not to do this? I can't see the reasoning for it.

  6. #6
    SitePoint Wizard bronze trophy chris.upjohn's Avatar
    Join Date
    Apr 2010
    Location
    Melbourne, AU
    Posts
    2,197
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    This is a very good idea. But does it work? I remember seeing if it was possible a couple of years ago and it always broke things in firefox.
    Works very well on mobile but older browsers such as IE have a hell of a time trying to render things right if you don't make the anchor display: block

    @TomB ; Block level elements in XHTML are strictly for layouts E.g. containers for headers, content wrappers and such, using a block level element within an inline element is wrong because you are changing the design of what an inline element is supposed to be used for hence you have already written bad markup for doing so. HTML5 gets around this by adding one extra section to the specification that says we can do this but it still goes against the reasoning why an anchor element is inline in the first place, personally I feel that an anchor tag should be used for nothing else but text and span elements for icon purposes since they are both inline but anything like a <div>, <canvas> etc... should be made clickable another way.

  7. #7
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    That reasoning is fine, but only because of the way we've already defined block and inline. From a practical perspective, linking a block or group of elements makes perfect sense. Semantically, there's nothing wrong with wrapping a element in an anchor.

    In fact, I'd argue that it's a poor separation of concerns that inline/block should be a consideration when marking up a document because it's display only.

  8. #8
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,484
    Mentioned
    182 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by TomB View Post
    Semantically, there's nothing wrong with wrapping a element in an anchor.
    .
    Except that I'm seeing people wrap all sorts of blocks in anchors including blocks of code that already contain other anchors!!

    It just opens up all sorts of problems not to mention rendering problems in certain well known browsers and is best left alone. I agree it would be handy in some cases to link a block of heading and text content but than can often be confusing for users (and I should think confuse screen readers) if not done correctly. In most other cases though it is unnecessary to do that.

  9. #9
    SitePoint Wizard bronze trophy PicnicTutorials's Avatar
    Join Date
    Dec 2007
    Location
    Carlsbad, California, United States
    Posts
    3,658
    Mentioned
    15 Post(s)
    Tagged
    0 Thread(s)
    Not that <a> is the reason I'm switching. I just think its time. Ill start with the doctype and meta character set for now. And work the semantic tags in over time as I get to know their correct usuage.

  10. #10
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    Except that I'm seeing people wrap all sorts of blocks in anchors including blocks of code that already contain other anchors!!
    But that's viable at the moment. Inline elements can contain other inline elements. There's nothing to stop someone putting an anchor in an anchor at the moment! I don't really think that's enough of a reason on it's own. The DTD should specify what elements are allowed in others and the validator would be able to pick up nested anchors wheer they're inline or block.

  11. #11
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    An A element cannot contain another A element in HTML 4.01 and that actually is a normative markup language.

    Like I mentioned above you no doubt you'll get some idiots wrapping complex tables with an anchor. Imagine the craziness of a whole structural data table defining a hypertext link, etc.

    X(HT)ML 'block' and 'inline' elements have little to do with display if anything (markup wise) they are structural. Block-level elements typically contain inline elements and other block-level elements. Inherent in this structural distinction is the idea that block elements create "larger" structures than inline elements.

    People too often get overly confused with the CSS 'display' property, which is a Style Sheet Language and that would actually cover Separation of Concerns, as its 'display' not 'structural' content.

  12. #12
    SitePoint Wizard bronze trophy PicnicTutorials's Avatar
    Join Date
    Dec 2007
    Location
    Carlsbad, California, United States
    Posts
    3,658
    Mentioned
    15 Post(s)
    Tagged
    0 Thread(s)
    Well people could of always done it they just for the most part didn't because of the validation error. I think anything that prevents all the css hacks that used to happen to make valid is a good thing.

    Do you guys use html5 now? I've been holding off but I think it's time on new projects. I won't go and recode all my old stuff. The only problem is ie8 tide to XP. I still have an XP as an example. Therefore ie8 will be around for a while to come. html5 shim then you say. No, I've never been a fan of that mentality of thinking. XHTML as an example. That's why I always chose html. Even my web design site which presumably is mostly web designers has 60-70% ie visitors. Purposefully designing in a way that demands making work-arounds for the majority of your users makes no sense to me. Mine as well just take the simple route. Hence my hesitance for html5.

  13. #13
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,863
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Its a pity that XHTML 2 died to be replaced with XHTML 5.

    XHTML 2 had done away with the <a> tag completely and allowed the href attribute to be added to any tag that you also wanted to be a link. That idea makes far more sense now than having the <a> tag. After all browsers have already got rid of one of the two uses for the <a> tag by allowing an id on any tag to be used as the destination for a link so why not do away with the other one and allow any tag to be a link.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  14. #14
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Do I author non normative HTML5? The answer is; no; the only place you'd see me write any h5 would be answering a forum question on Fred5. I'd have a similar opinion to Stephen regarding the XHTML 2 hyperlink approach over the h5 anchor solution. Though I believe either two methods would be misused and wasn't that thrilled over the XHTML 2 idea either at the time.

  15. #15
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    The reason HTML5 allowed the "anchors wrapping blocks" thing, really, is because

    - authors have been doing this since the beginning of time (even tho it was wrong and even tho IE and FF puked chunks when they saw it)
    - browsers have been dealing with this bad markup since the beginning of time (error rendering)

    Because all browsers had some kind of error rendering to deal with inline anchors around blocks, and because so many people were using this bad markup for a reasonable idea (making a whole chunka somethin clickable to a single URL, instead of multiples of the same URL), when they were writing their Unified Error Rendering, the vendors realised they could set the same behaviour cross-browser for this. And apparently this was easier than adding working href attributes to non-anchors (they looked at that, with <nav> and then directly <li href="blah"> inside).

    So while they were at it, they mumbled something about smelly cowpaths and legalised it. Kinda like embed.

    Quote Originally Posted by ericwatson
    Do you guys use html5 now? I've been holding off but I think it's time on new projects. I won't go and recode all my old stuff. The only problem is ie8 tide to XP. I still have an XP as an example. Therefore ie8 will be around for a while to come. html5 shim then you say. No, I've never been a fan of that mentality of thinking.
    I've gone ahead and started even using the crappy new tags, only because in my eyes they're good for just one little thing: they add an easy anchor (for browsers) for the accessibility layer.

    And because of this (mostly, there were other reasons too), Steve Faulkner proposed a new element: <main>. And just to be difficult, I decided to add <main> to a page I was rewriting anyways. It's <main role=main>. W00ts.

    So far as I know, the other new elements aren't used by any other software. At least not like we were so promised with diamonds in the sky. That was the dream, right? We wanted more semantics so other software could figure out what kind of data our web page/app content was? The dream's still a lie, with the small exception (slowly getting there) of screen readers and probably Dragon Naturally Speaking (not sure about anything else though).

    So the new elements otherwise don't give us any real semantics. They let us style based on tag, which is cute (I like it), and they make IE required to run Javascript (not cute).

    So I figured, if I'm going to use crappy meaningless tags, I'll add <main> just because it'll not only help map the role=main to a tag, but unlike nav and header and footer, it'll probably help software like Readability, stuff that takes out the meat of the page and removes all the crap and chrome and junk around it. I like that. Sounds nice.

    And since browsers and other software don't really otherwise have any clue what any of this all means, and IE needs JS, I just do a
    document.createElement('main');
    and make a <main role="main">
    and style with
    [role=main] {display: block; background-color: #080;}
    (which does work in IE7 so long as it runs JS and after you make it a block element of course)

    and now I can officially call myself a hipster, but a hipster with a heart of gold cause I'm doing it for a Good Cause. Righteousness, brotha!

  16. #16
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    It's like the Browser Wars in reverse.

  17. #17
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    I should stop now with the madness, because I may be setting a barrier for this little guy


    then again I'm one of these

  18. #18
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,863
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    The reason HTML5 allowed the "anchors wrapping blocks" thing, really, is because

    - authors have been doing this since the beginning of time (even tho it was wrong and even tho IE and FF puked chunks when they saw it)
    - browsers have been dealing with this bad markup since the beginning of time (error rendering)
    Since browsers work around it anyway it makes absolutely no difference with HTML 5 that they allow it.

    Where it does make a difference is with XHTML 5. Sonce XHTML does not try to patch up junk code the only way to allow that particular coding practice in XHTML was to allow it in XHTML 5.

    So you could say that this particular change is more for future use in XHTML since it has long been allowed by browsers in HTML and so with HTML 5 it is just a matter of dejeure catching up with defacto.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  19. #19
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by felgall
    Since browsers work around it anyway it makes absolutely no difference with HTML 5 that they allow it.
    True, except the unified error rendering thing is kinda new. Someone (or a few intrepid someones) actually crawled through tests and vomit to see how browsers dealt with all sorts of errors. And they were all different. And this was not good. And the WHATWG were Displeased. And so they said, "Let there be Unified Error Rendering". And So It Was Done. And they agreed it was Good. Or something. So I heard, once. Rumours on teh interwebs. And actually, it wasn't really unified error rendering, but more the idea that how browsers deal with errors also belongs in the HTML specs, so they added it.

    Quote Originally Posted by felgall
    So you could say that this particular change is more for future use in XHTML since it has long been allowed by browsers in HTML and so with HTML 5 it is just a matter of dejeure catching up with defacto.
    Maybe, I dunno. Since XHTML (even 5) still uses XML parsing, they would have to actively change parsing for that. I know they made some changes for "XHTML5" (but they were really arcane and weird and had to do with tokens and schemas and stuff I don't understand cause actually I no speak-a de XML) but I dunno if they were planning to do that for anchors wrapping blocks. Probably not. Part of the whole "cowpaths" thing is partially the reluctant admission that, yeah, HTML is sloppy and silly by nature and is meant for nose-picking dreambeaver-using humans to mutilate and modify and get wrong, because, well, it must be good because Postal's law something something. Or in other words, correct HTML must not be placed above making sure your Tumbler's 10px-font-sized rage against, like, the system man, or what you think about some celebrity shows up to grandma who clicked a link. Cause grandma'd be all like, "what's this 'XML error' thing mean? What did I do wrong? I don't get it." <back button> So everyone's all like POSTAL'S LAW DON'T BREAK IT! IT'S SAVIOUR OF TEH INTERNETS

    Or whatever.

    XML/XHTML wasn't like 'Nam, man. There are rules.

  20. #20
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,116
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Anchors are the most important element on the web, this change makes perfect sense to me. Why not be able to link a block of content? It's also becoming important because of newer devices that require large hit targets. I like interfaces where you can click anywhere. e.g.

    It's a trend that will continue for good reason and all new browsers handle it well.

  21. #21
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,301
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by markbrown4 View Post
    I like interfaces where you can click anywhere. e.g. ...
    Not sure what that pic is meant to demonstrate. Do you want to be able to click the whole page? There are some blue links there, but if there are other places to click, the design should really make that clear. It hate touching the screen to find I'm being taken somewhere I didn't want to go.

    The whole links within links things sounds like the ultimate web disaster to me.

  22. #22
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    I don't use a mobile or a touchy-screen-thingie, which is probably why I don't know how you're supposed to scroll on those things without hitting a link.

    I do know that since I've gotten machines that upgraded to Unity, my habit of clicking on the white space to the left of page content in order to give myself page focus so I can arrow up/down the page has now suddenly started activating crap I don't intend hiding in the sidebar which pops up whenever my mouse or worse, trackpad, gets close.

    Honestly who thought putting a menu at the left was a good idea?? Zomg. And I heard even though I'm using desktops, they insisted it was a Good Thing to make me work with what is supposed to be a touch/tablet interface.

    I hope actual touch/tablet interfaces suck so much less. I don't know how much longer I'll be on desktop. And so anyways, how would I scroll a page without clicking some link?

  23. #23
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,116
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ralph.m View Post
    Not sure what that pic is meant to demonstrate. Do you want to be able to click the whole page? There are some blue links there, but if there are other places to click, the design should really make that clear. It hate touching the screen to find I'm being taken somewhere I didn't want to go.
    Every red area is a link. I don't want the whole page to be clickable, but each block of related content should take you to somewhere you expect. I find it intuitive and obvious. There's no links within links, the blue text is just there to prompt action, which it does. Mashing anywhere in the cell will take you where you want to go.

  24. #24
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,116
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    And so anyways, how would I scroll a page without clicking some link?
    All touch devices detect scrolling and don't follow links. Only when you tap without moving does it follow a link.

  25. #25
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    If every red area is a link - extremely worrying regarding content - then (looking at the image) most of it can be already achieved with an inline hyperlink. In either case small screen mobile device are too narrowly focused for user-agents. It would be the purpose of CSS, Scripts or the OS to create larger targets. Else it's looking more like or they should have adopted the XHTML 2 approach.

    Markup should be mainly device independent, visual rendering is a very different topic.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •