SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 85
  1. #51
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    I'm not contradicting my self at all. I've said more than once that if the content in nav goes beyond just mere links, and if it's complex enough, you can make semantic constructs for that content, which may include lists, but only if lists are required by that content's context.

    "Links alone, by definition" comes from the specs:

    The nav element represents [...] a section with navigation links.

    [...]

    A nav element doesn't have to contain a list, it can contain other kinds of content as well.

    [...]

    User agents [...] can use this element as a way to determine what content on the page to initially skip and/or provide on request.



    That makes "Pictures Cookies" good enough, no lists required. That is, is you can break the lists barrier, if you can get past this lists obsession, where you see lists everywhere.

  2. #52
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Why is "Picture Cookies" good enough?

    You're pulling those quotes out of context. Let's look at the whole thing:
    Quote Originally Posted by W3C HTML5 Editor's Draft
    The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

    Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.

    User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.

    In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.
    Code:
    <body itemscope itemtype="http://schema.org/Blog">
     <header>
      <h1>Wake up sheeple!</h1>
      <p><a href="news.html">News</a> -
         <a href="blog.html">Blog</a> -
         <a href="forums.html">Forums</a></p>
      <p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
      <nav>
       <h1>Navigation</h1>
       <ul>
        <li><a href="articles.html">Index of all articles</a></li>
        <li><a href="today.html">Things sheeple need to wake up for today</a></li>
        <li><a href="successes.html">Sheeple we have managed to wake</a></li>
       </ul>
      </nav>
     </header>
     <div>
      <article itemprop="blogPosts" itemscope itemtype="http://schema.org/BlogPosting">
       <header>
        <h1 itemprop="headline">My Day at the Beach</h1>
       </header>
       <div itemprop="articleBody">
        <p>Today I went to the beach and had a lot of fun.</p>
        ...more content...
       </div>
       <footer>
        <p>Posted <time itemprop="datePublished" datetime="2009-10-10">Thursday</time>.</p>
       </footer>
      </article>
      ...more blog posts...
     </div>
     <footer>
      <p>Copyright 
       <span itemprop="copyrightYear">2010</span>
       <span itemprop="copyrightHolder">The Example Company</span>
      </p>
      <p><a href="about.html">About</a> -
         <a href="policy.html">Privacy Policy</a> -
         <a href="contact.html">Contact Us</a></p>
     </footer>
    </body>
    Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer.

    You can also see microdata annotations in the above example that use the schema.org vocabulary to provide the publication date and other metadata about the blog post.

    In the following example, there are two nav elements, one for primary navigation around the site, and one for secondary navigation around the page itself.
    Code:
    <body>
     <h1>The Wiki Center Of Exampland</h1>
     <nav>
      <ul>
       <li><a href="/">Home</a></li>
       <li><a href="/events">Current Events</a></li>
       ...more...
      </ul>
     </nav>
     <article>
      <header>
       <h1>Demos in Exampland</h1>
       <p>Written by A. N. Other.</p>
      </header>
      <nav>
       <ul>
        <li><a href="#public">Public demonstrations</a></li>
        <li><a href="#destroy">Demolitions</a></li>
        ...more...
       </ul>
      </nav>
      <div>
       <section id="public">
        <h1>Public demonstrations</h1>
        <p>...more...</p>
       </section>
       <section id="destroy">
        <h1>Demolitions</h1>
        <p>...more...</p>
       </section>
       ...more...
      </div>
      <footer>
       <p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
      </footer>
     </article>
     <footer>
      <p><small> copyright 1998 Exampland Emperor</small></p>
     </footer>
    </body>
    A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
    Code:
    <nav>
     <h1>Navigation</h1>
     <p>You are on my home page. To the north lies <a href="/blog">my
     blog</a>, from whence the sounds of battle can be heard. To the east
     you can see a large mountain, upon which many <a
     href="/school">school papers</a> are littered. Far up thus mountain
     you can spy a little figure who appears to be me, desperately
     scribbling a <a href="/school/thesis">thesis</a>.</p>
     <p>To the west are several exits. One fun-looking exit is labeled <a
     href="http://games.example.com/">"games"</a>. Another more
     boring-looking exit is labeled <a
     href="http://isp.example.net/">ISP™</a>.</p>
     <p>To the south lies a dark and dank <a href="/about">contacts
     page</a>. Cobwebs cover its disused entrance, and at one point you
     see a rat run quickly out of the page.</p>
    </nav>
    Notice the first two have lists in them.

    The third one doesn't have a list. However, it does have a paragraph. It's additional text to give meaning to the links. That is perfectly fine. However, there is no "Pictures Cookies".

  3. #53
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    However, there is no "Pictures Cookies"
    Make decisions on what you read in the specs. Those few examples in them will no be able to cover all possibilities.

    nav is for links. Start from here.

    Basically, an UA will look for nav and will expect to find links. It's possible it may encounter other elements: headings, paragraphs even lists. But the one thing that will make nav a liar would be links missing not lists or verbosity missing. Forcing lists in there for verbosity whenever paragraphs are missing is just a habit gone bad.

    Let's step aside from lists a bit. You said paragraph. The paragraph is not there to give links meaning, is there to make you read a comprehensible phrase containing links. Verbosity: "Look at my Pictures. I'll give you Cookies".

    If I don't choose verbosity, putting only links in there is just fine: "Pictures Cookies"

    Consider this:
    Code:
    Uită-te la Pozele mele. Iți dau Prăjituri.
    Not being able to translate Romanian, you will still be able to get by, simply because anchors alone will do:
    Verbosity is no use if you don't understand the natural language, whereas nav and simple links are good enough to relay the meaning. The same discussion I had in this thread about English and native speakers missing out on specs because they assume that English language rules all over. The nav element is for links not for poetry or prose. Those two would require different semantic approach. Not nav.

    And yes, if content in some links is complex enough, say two or three words, you could add structural or semantic element to distinguish where one starts and where one ends. That doesn't mean lists by default.


    About lists.

    To me, it seems that you look at the li element for links like a div element for content. But you pretend is for semantics.

    Something along the lines of the next two examples being equivalent.

    Code:
    <div><a href="#">Pictures</a></div>
    <div><a href="#">Cookies</a></div>
    Code:
    <li><a href="#">Pictures</a></li>
    <li><a href="#">Cookies</a></li>
    simply because

    Code:
    <ul>
    <li><a href="#">Look at Pictures</a></li>
    <li><a href="#">Eat Cookies</a></li>
    </ul>
    it's structurally better then

    Code:
    <a href="#">Look at Pictures</a>
    <a href="#">Eat Cookies</a>
    But lists have to be required, not by the "I see lists here 'cos there are a bunch of links here with nothing more and that makes it a list" rule but by the content's context. You need something more than something that spells out as list obsession.

  4. #54
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Paragraphs are containers for words. Those words don't have to make sense when read together. You would still use a paragraph for gibberish talk.

    Nav is container for links. Those links don't have to make sense when read together.

    Lists are elements for different concepts linked together by a common discussion topic, that has to be previously presented in a clear manner.

    Ironically, the English language is what stands in your way of fully understanding the specs.

  5. #55
    Life is not a malfunction gold trophysilver trophybronze trophy
    TechnoBear's Avatar
    Join Date
    Jun 2011
    Location
    Argyll, Scotland
    Posts
    6,059
    Mentioned
    253 Post(s)
    Tagged
    5 Thread(s)
    Quote Originally Posted by itmitică View Post
    Nav is container for links. Those links don't have to make sense when read together.
    There is, however, an accessibility problem with adjacent links. See WebAIM for full details, but the relevant section is:
    Adjacent links

    When using a screen reader, it can sometimes be a little difficult to tell when link text ends and when another begins. JAWS says "link" before each link, which minimizes this problem, but it can be a little more difficult with Home Page Reader, which uses a female-sounding voice for all of the links. It is a good thing that the voice changes from a male-sounding voice to a female-sounding voice, but if there are five links in a row, the voice will not change at all in between links, which can lead to some confusion.

    One solution is to provide a non-link character between each link. The vertical bar ( | ) is used quite often for this purpose. Another solution is to put the links in an ordered or numbered list. Screen readers tend to pause between list items, helping the user audibly distinguish between separate links.

  6. #56
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Hi TB.

    I think I've acknowledged this part:
    Quote Originally Posted by itmitică View Post
    And yes, if content in some links is complex enough, say two or three words, you could add structural or semantic element to distinguish where one starts and where one ends. That doesn't mean lists by default.
    The issue was raised in the early posts in the thread.


    It's solution to a problem outside the realm of semantics.

  7. #57
    Life is not a malfunction gold trophysilver trophybronze trophy
    TechnoBear's Avatar
    Join Date
    Jun 2011
    Location
    Argyll, Scotland
    Posts
    6,059
    Mentioned
    253 Post(s)
    Tagged
    5 Thread(s)
    Quote Originally Posted by itmitică View Post
    It's solution to a problem outside the realm of semantics.
    Unfortunately, semantics and accessibility are both relevant to good web design and I don't see how it's possible have a meaningful discussion of one without the other.

  8. #58
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    You make it sound like I advocate bad design. That's uncalled for.

    What you're reffering to as relevant accessibility in this thread is, in fact, plugging holes in lesser UAs.

  9. #59
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by itmitică View Post
    You make it sound like I advocate bad design. That's uncalled for.
    Nah, that's pretty much hitting the nail on the head... since you're basically saying to ignore semantics, structure and grammar.

    Quote Originally Posted by itmitică View Post
    What you're reffering to as relevant accessibility in this thread is, in fact, plugging holes in lesser UAs.
    Or actually providing structure since neither special or phrase elements do so. You are attributing capabilities to the anchor tag and/or whitespace that do not exist. Translating it to Romanian or even a ruby language wouldn't change that.

  10. #60
    Life is not a malfunction gold trophysilver trophybronze trophy
    TechnoBear's Avatar
    Join Date
    Jun 2011
    Location
    Argyll, Scotland
    Posts
    6,059
    Mentioned
    253 Post(s)
    Tagged
    5 Thread(s)
    Quote Originally Posted by itmitică View Post
    You make it sound like I advocate bad design. That's uncalled for.
    I'm sorry if you feel that was a personal attack - that was not my intention. I was simply trying to express my own point of view, and if I worded it badly, then I apologise.

  11. #61
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I agree with DS... you are advocating bad design, at least in the case of saying you can have nothing but anchors in a nav. It's simply untrue.

    Also, if the spec doesn't support your argument, it's not meant to happen. The spec CAN tell us everything about HTML, at least when it comes to how it's supposed to work.. That's what it's there for.

  12. #62
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    You can always agree with DS. I can't help that. It's probably bad design on your part.


    What I can do is correct you when you go overboard with your statements:

    1. The specs support my argument: nav is a container for links. Period.

    2. You are mixing it up to get your way. I was talking about examples in the specs. Those can't cover every aspect you argue against.

    Further more, I was giving this piece of advice: really really read the specs, don't draw your superficial conclusion based on a few examples (that can't cover all aspects) just to support an old bad habit in the process: list obsession.

    Pardon me if you think I'm being pert, but, as an advice, you, along with a few others, should mildly change your views to place your self in today's world of web development. But rest assure that you and some others firmly anchoring your self in 2000 will not be the end of the world. Your aggressive resistance to acknowledge that things change is only hurting you.


    Finally, did you really read all my posts? You should go further than just skipping to the posts of a certain user you want to get on board with. I'm afraid your superficial argument is just for the sake of being on a specific side. That's why I won't waste my time anymore.

  13. #63
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by itmitică View Post
    Pardon me if you think I'm being pert
    Pert? Flippantly cocky and ignoring the facts in front of you? Yeah, that sounds about right. To be brutally frank and curt, that truly does seem an accurate self assessment.

    You are alone on this one, and will be hard pressed to find anyone agreeing that omitting any form of delimiters, separators, grammar or formatting between a bunch of single or multi word links is going to be anything but gibberish... which of course is why you stopped responding to the examples when even your own started to contradict your view...

  14. #64
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,272
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Hi Guys,

    Lets keep the discussion free from antagonism or some spoilsport will come along and close an interesting thread.

  15. #65
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Pert? Flippantly cocky and ignoring the facts in front of you? Yeah, that sounds about right. To be brutally frank and curt, that truly does seem an accurate self assessment.
    Just want to point out that was a joke and not meant as actual antagonism -- I should have included smileys. Some of noonope's malapropisms can be quite funny.

  16. #66
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,269
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Paul
    Lets keep the discussion free from antagonism or some spoilsport will come along and close an interesting thread.
    WELL TOO LATE NOW HERE I AM

    This whole big stupid argument about what to put in <nav> is totally irrelevant. <nav> means nothing in browsers. It means NOTHING and browsers expect NOTHING inside them.

    There is only ONE group who possibly gets ANYTHING from <nav> tags today. Who? Screen reader users. Nobody else. Nobody at all. And this is only because AT is reading the native role the <nav> element has. Well, we don't need <nav>s to get roles, and the WHATWG and W3C haven't even decided all the roles yet anyway. DRAFT etc yadda yadda

    So, only screen reader users POSSIBLY get anything useful out of these new <nav> tags. And yet some folks here advocate filling them with a row of structureless links, or links with some random creative structure??? Why would you ever do such a thing? WHY? For some imaginary semantic purity? Purity for purity's sake? At the expense of users?? And no I don't care if you're addin in cute pipes or commas or what in between; everyone seems to understand this
    Code:
    <a href="foo">Home</a><a href="bar">About</a><a href="baz">Blawg</a>
    is foobarz so luckily I don't have to rant about why this is retarded to the point of making sloths blush.

    Making things more difficult for a group of people who already have a tougher time than the rest of us using the web and possibly NEED the web more than the rest of us aside, how about we AVOID the entire "problem" (fake invented problem) of <nav> tags entirely and just use the exact same thing <nav> does today in a way that has NOTHING to do with HTML semantics and other garbage argued about by web developers

    <ul role="navigation">

    There you go. This works. It works in all modern user agents. It works in most screen readers. Where it doesn't work, it STILL WORKS, because the users we are targeting are PEOPLE and they have experiences on the web and what have they experienced??? What do they know? What have they seen? What do they use? What is on practically EVERY. SINGLE. WEB SITE. OUT THERE. ? Lists of links.

    Almost every web site out there uses a list of links to contain site navigation. To contain product navigation. People are used to this. People know how they work. Experienced screen reader users waiting for a page to load of a web site where they know they just want to get to the navigation, what is the first thing they do? Wait to see how creative you were with your <nav> tags???
    They ask for a list of links on the page. They pull them up. They find the one starting with, usually, HOME. Boom. They have the navigation, and it's not all read out as one garbled chunk and it has not only LINKS in side them but also LIST ITEMS.

    You can navigate not only by lists, and not only by links, but also by list items. These are common enough that a separate quick key for running through List Items is available.

    List obsession? I counter that with what users expect and how they use websites (and a photo of a LOLCAT, for this is the Internet, good sirs). Users are people who take what they've already encountered and use it to help decide how they will navigate a new web site. The current paradigm is lists. Maybe next year image maps will come back into fashion and we'll be told to switch to some HTML5 version of those or something, but that's not today and that's not what people know. Web standardistas decided over the course of several years that navigation is best as a list of links and if you want to change that you WILL have mystery meat of one sort or another. Though confusing people might be the whole point of some web site, who knows.

    Everything above changes if/when large numbers of sites switch to some other set of tags. Fine, but as conscientious web developers you will make sure users have already accepted it as their navigation paradigm before you make any such switch. I argue that today lists are still the paradigm the average user expects, and users of AT rely on.


    Hey web developer peoples, you can do one of two things here:
    we can insist that current HTML semantics sucks balls (so it does, oh well, I wish snow were purple and where is my goddamned p0ny???) and decide to use "better" semantics to go with the shiny new mostly-harmless-but-generally-useless HTML5 tags that real users have not actually experienced and makes things suck big hairy donkey balls for them (unnecessarily),
    OR
    we can say, leave this stuff until it DOES have meaning and semantics and whatnot for browsers and other software, and until then, continue using the HTML structures real human beings have been using for years and are using today and will continue to use for the forseeable future and keep an eye on the new stuff for when it starts mattering to real users. "Real users" here is not referring to hipster nerds running Aurora and webkit nightlies because their idea of a good time is bug testing and brogramming, yo.


    You people are free to argue til the cows come home whether you use a list in a nav or just throw a bunch of links or a p or a div or other weird creative things in there but if any of you actually write code like this and launch it I'll have to get old Gonz to rally up the blinks and we'll come storming your houses with pitchforks and refreshable braille displays and force you 1 year web access using only text browsers or assistive software so you can experience the wonderful creativity of "HTML semantics" on a regular basis. The "OH GOD NO WE'RE JUST BEING OLD FARTS EATING HEART PILLS AND LIVING IN THE PAST AND BEING SURPASSED BY DRAFT SPECIFICATIONS AND HIPSTER CODE OH NOES" doesn't convince me, but some concrete evidence-based arguments coming from actual user testing showing people benefit from other HTML totally would.
    Actually I don't need to be convinced of anything, I'm not a web developer and I don't build these things, I just like to jump in and make messes for fun and profitz, lulz

    Again I'm focusing on this minority because currently they are the only ones involved as users when it comes to tags like <nav>. That, and web developers who do CTRL-U and peek at web site underwear to measure your hipness level like the code voyeurs they are.

    Edit:

    Oh and by the way... it may have occurred to several that the above statements can easily be used to defend sh*tty code practices that are used practically everywhere. And you can. And some do. Lately I've started to think that using the right tag today has more to do with "how do users use and perceive this?" than what someone on the W3C board said would be nice and p0nies 10 years ago. Yeah, midlife crisis, I'm losing my nazism... first I dump XHTML, now this... I may have to quit Python

  17. #67
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Though confusing people might be the whole point of some web site, who knows.
    Given how many of the sites out there behave for me as a user -- I think that is the point many 'designers' seem to be aiming for. Broken, buggy, non-graceful degrading crappy fixed width with nonsensical/broken heading orders, nonsensical division of links or worse, no division, and a whole host of other things we've been told for over a decade were bad practice.... and that's before we even talk about the ones that are too slow to even try to use unless I'm at home on my fat pipe... since on the road a lot of these megabyte plus sites are useless.

    Now with all this new crap the bad practices are back with a vengeance... and broken/bloated/idiotic websites await.

  18. #68
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,135
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by felgall
    As far as jQuery is concerned I see nothing wrong with people using it if they use it properly and their site is actually using most of the functionality it provides. Of course to be able to properly use a JavaScript library like that you need to understand JavaScript to a fairly advanced level in order to be able to properly understand how the jQuery code works. It is ridiculous how many sites there are that use 20 lines of code to call jQuery in order to do something that can be done in 10 lines of JavaScript without jQuery.
    ditto

    There was a time I didn't appreciate jQuery but have come around to see the light. I write JavaScript on a fairly often basis so having a tried, true well documented library of utilities is invaluable. Not only does it make me increasingly productive but results in less bug prone code. Before using jQuery I had my own little library of reusable functions anyway. jQuery in its purest form is merely that but more stable and future proof.
    The only code I hate more than my own is everyone else's.

  19. #69
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,135
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    I think having a well-documented, community driven, stable, extensible, constantly evolving library that makes one more productive with less bug prone code out-weighs a small load time disadvantage. For people who don't see that I just don't think they write that much JavaScript. If you don't write that much JavaScript than obviously you wouldn't be able to comprehend how valuable a library such as jQuery is in terms of productivity and being dry. In that case you shouldn't be commenting about its usefulness just because your regurgitating things you have heard rather than experienced yourself. The reason I say this is because I'm fairly certain that most people opposing it in this thread are not very familiar with JavaScript based on questions I have seen them ask in regards to JavaScript. It gets on my nerves that people who know very little about JavaScript and problems faced in general with programming are opposing the use of something they don't really understand purely based on load time.
    The only code I hate more than my own is everyone else's.

  20. #70
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TehYoyo View Post
    What I'm trying to say is that HTML5 increases acceptance for previously deprecated attributes and tags like target and align (if I'm not mistaken)
    You are mistaken about align.
    Simon Pieters

  21. #71
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,269
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Wut... target's in? Whoa.

    @ oddz: did you mean this thread? http://www.sitepoint.com/forums/showthread.php?839813

  22. #72
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Yeah, @oddz confused me a bit too. Shoot me a PM if those need to be moved. =p

    Also, @Stomme poes, -clap clap- It's been a while since I've seen you that fired up. That was a great post. =p

    You bring up a very good point that us arguing over pure semantics is a bit stupid, because pure semantics means absolutely nothing if it doesn't help out the users (which is what the standards are supposed to do for us: providing a consistent method for expressing documents in a way that a multitude of user agents can render the content for users).

    Quote Originally Posted by itmitica
    Further more, I was giving this piece of advice: really really read the specs, don't draw your superficial conclusion based on a few examples (that can't cover all aspects) just to support an old bad habit in the process: list obsession.
    It's a bit late, but at this point: I have read probably 90% of those specs (though admittedly, they keep changing and I haven't reread them all lately), and the HTML 4.01 and XHTML quite a few times as well. I've been at this for a while. I'd wager most of the others arguing in this thread are in the same boat.

  23. #73
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    In the words of Mammy from "Gone with the wind": That's some bubkis Mallory.

    That's no argument for accessibility. That's argument for list obsession. You addict!

    <li><a></a></li> in nav, or in a ul element, without any other related or introductory content whatsoever, is the same as <a></a> only worse, since you're using li for all the wrong reasons there, as a structural element, as a pause, instead of good old |, and then some. You know what looks better then <li><a></a></li>? Even this: <div><a></a></div>.

    Menus used to be select elements. You wonder why? Let's see.

    You speak about accessibility. The fact is that you see lists everywhere. Your page stretches vertically like the polar night. To get to the content, you need to scroll through 2-3 almost empty screens filled with nothing but lonely lists and your page ends with another 2-3 almost empty screens filled with nothing but lonely lists, for menus and nav. In the middle, scattered, there are another 2-3 almost empty screens filled with nothing but lonely lists for social links and such.

    That's pretty much UX in reverse: endless vertical lists, on a airport stretch like page, where you need to guess where the content is hidden. ...oh, and good luck guessing which lists are for navigation and which are actual content.

    Things change when you apply... style. Which is the same difference for when you apply style to navigation w/o lists.

    So nav is pretty much viable w/o lists. Granted, you need to feed your.. list obsession.


    And if content in nav is much bigger and complex, I think we can manage just beautiful w/o lists. The fact that I choose not to add redundant elements or content for simple navs like "Pictures Cookies" is no reason to look at lists as a must have. At all. Everyone will manage just swell with that markup, even more so the screen reader users.


    What about accessibility for the right reasons? You think lists are the only ones making the difference? Lists are the only ones doing the job of separating among those links? I don't need to answer to this, do I?

    What about lists for actual proper lists that actually fit naturally in content, don't just appear out of the blue? Since pretty much all the arguments for using lists in/for nav skip this part and tackle issues lists aren't meant to be the answer for. They're just opportunistic uses, renamed menus and navigation.


    "Do lists because everybody expects and uses them since... whatever."

    Right, fully comprehensible documented and technically sound arguments. As if.

    Two words: list obsession.


    Things change. Like it or not, nav actually means something now, to browsers, to users. Which is pretty much the same thing with role="navigation". It's your choice if it means something to you as a developer as well.

  24. #74
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    I'd wager most of the others arguing in this thread are in the same boat.
    Why are you always bringing into discussion: the others, he, she and so on? Why do you try to speak for the others? Like I said, a bad design. Speak for yourself.

    And I'm not looking to please the most in this thread. Nor the most in this thread define the majority by which the truth is established.

    I've given you a question mark: list obsession. It's your choice to treat it as a threat to forum tranquility and to your past knowledge or like a topic for a civilized exchange of views.

  25. #75
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Um... what?

    Do you know what accessibility means? Who cares how I style my elements, with or without lists. That means absolutely zero to a screen reader. The only thing that matters to them is if I make it invisible... that's it.

    Also, I'm not sure where you even get this "list obsession" thing you keep ranting about. The only places I use lists is for lists of things. A group of navigation elements is a list... a list of navigation elements. The nav element does mean something, but it doesn't change the meaning of what anchors mean, or lists. Sure, you can separate your anchors with divs. That's better than no separation. However, that's even sillier than using a list, because you are then dividing your links into different divisions, instead of keeping them together as a list of related navigation elements.

    You've yet to provide any real backing for why lists are pointless. I really hate to sound "elitist", but when you have all of the users that are agreeing on this topic agreeing... it usually means there is something to it (since half the time we are all disagreeing with each other over little nitpicky things =p).

    Oh, and on the point of the target attribute, it looks like it is indeed back in:
    Quote Originally Posted by W3C HTML5 Editor's Draft
    The target attribute, if present, must be a valid browsing context name or keyword. It gives the name of the browsing context that will be used. User agents use this name when following hyperlinks.
    http://dev.w3.org/html5/spec/single-...perlink-target

    Interesting... I think I kind of like this one, simply for the fact that it always felt weird having to use Javascript to open a new window. Though, I did kind of like it too, since I prefer to leave the user in control over where their page opened... so I guess I'm actually in the middle (as usual). =p

    EDIT: Just saw your second post. I'm not bringing others in to this argument in particular. Everything I've been arguing is my interpretation of the current specs, the previous specs, and the general discussions that go on in the web community as a whole. I didn't invent HTML, I'm not a member of the W3C, and I don't work for any major browsers. The best I (or anyone else in similar conditions) can do is interpret what has been published and go with it. I think the my interpretation (which just happens to coincide with just about everyone else's interpretation) is correct and yours is wrong. Simple. =p

    I'm not particularly concerned with forum tranquility either (in the sense that everyone agrees with everyone). When people disagree, we learn. If I'm always right, life is boring because I already know everything. I love being proved wrong, or shown some other method, because that's how I learn. However, I accept being wrong when given facts, not odd opinions.

    And my "past" knowledge is updated on a very regular basis. Aside from being an active member of these forums for the past... fairly long amount of time... I also read at least 100+ pages of industry news, new books, articles from well respected authors, etc., so I'd say my knowledge is pretty up-to-date.


Tags for this Thread

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
  •