SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 85
  1. #26
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    1. "safely to look at as an advance", or ""safely to look at as progress".

    2. And no, I'm not referring to rollover effects. I mean the CSS3 that starts dictating what links do, how links behave like, instead of what links look like.
    I've argued a few with Craig about that.

    But I know you know that too. Those two are just part of classic Jason's Gorilla War of Argument: first change the color of the weaker spots and then invade the whole place LOL


    3. Again, links in nav are not part of a sentence.

    Let's say this:
    - you ask me: What countries are there in Eastern Europe?
    - and I may respond: Romania, Moldova, Bulgaria, Ukraine, Poland.

    See what I did there: an enumeration. A list. If this was a conversation then yes, those would belong in a paragraph at least. They could also be in a list element. But that's scenario number one for nav use.

    Scenario number two: we're not talking about content in nav like that, a conversation. Content in nav can also be plain simple: an enumeration of links. Without a story behind. Remember: "a section with navigation links". So you don't need to get on a stage and recite it. You just go through it, knowing it's an enumeration.

    Making the nav element redundant with list elements is what you have in mind and it's because you don't accept it's role.

    Indeed, put in nav some semantic elements and you have your self a complex content. After all, it is a section.
    But put there just links and you have there a enumeration of links. This argument I've done it before with you.

    Simple as that: complex content vs. simple content.
    You don't have to justify your links, but you can include them in a more complex content, if you feel like.

    This is a whole other argument: HTML5 is so different in some areas that people with habits have trouble adjusting to it. Which is just fine, since HTML5 offers them the option of remaining true to their habits. Like SASS does: any valid CSS is also valid SASS.


    Oh, and HAML, at least, does simplify the markup process and it does help you make fewer to no errors. But, like with HTML5, you should at least try it before use it. And then there's Slim for you, if HAML is still your bad medicine.

    What I don't get is why are you still arguing that writing opening tags/closing tags is safer and smarter than having a mechanism in place to automatically do that for you, error free.

  2. #27
    SitePoint Guru Jason__C's Avatar
    Join Date
    Oct 2009
    Location
    Racoon City
    Posts
    660
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Nah, I will wait 20 years for XHTML2, then to use that s**t known as HTML5. End the W3C.
    Chuck Norris is so tough,
    mosquitos ask for permission before they bite him

  3. #28
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,822
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by itmitică View Post
    1. HTML5 will be ready for use in 20nn. No use until then. Notice I say "use" not "try".

    I'd point out that we're constantly using software "not ready yet". Your OS, *nix, Windows, Mac, all are constantly receiving updates, service packs. Your compiler. Your interpreter. Your everything in day to day production use. The same thing.
    No it isn't - there is a huge difference between software that has already gone through ALPH, BETA GAMMA/PRODUCTION repeases and which is subsequently receiving minor patches. HTML 4 has received minor patches like that since its PRODUCTION release in 1997.

    HTML 5 is still some years away from the ALPHA release stage.

    Quote Originally Posted by itmitică View Post
    Browsers and browser vendors are doing exactly the same thing with HTML5. That makes HTML5 ready for use today.
    and all are behind the current draft to varying extents since the HTML 5 draft can be updates several times a DAY and new browsers only come out a few times a YEAR.



    Quote Originally Posted by itmitică View Post
    And HTML5 is user friendly. Why would we want anything else? You want penalties for those writing bad markup? That's not the name of the game.
    Penalties for writing bad markup - such as refusing to display the page at all - is essential if we want to ensure that markup is written properly. That's one of the biggest benefits of XHTML over HTML. It is also one of the benefits that "strict" mode JavaScript introduced. The errors you find and fix now are the ones that will not turn around and bite you in three years time when you make changes where the error actually creates problems.

    Also HTML 5 allows you to define contradictions in your page such as specifying that an input field is mandatory but must be left empty both at the same time by introducing the useful patrtern attribute wnich makes the required attributealso introduced in HTML 5 obsolete. <input type="text" required pattern="^$">

    It also introduces multiple tags that all do the exact same thing - by the time HTML 5 becomes a standard all browsers will properly support using the object tag for those things that HTML 5 is proposing to introduce the iframe and embed tags for. The embed tag became obsolete when IE5 died and iframe will be obsolete once IE7 dies as the object tag works correctly for those purposes in all more recent browsers. A matter of shutting the barn door not only after the horse has gone but where all of the walls of the barn have been blown away as well.

    Once IE8 dies there is likely to be a split in what languages are used for writing web pages. Those who want to use correct markup will use XHTML while those who don't care will continue on as they have until now with the HTML 3.2 they currently use (although they might switch from the HTML 4 transitional doctype they currently use to pretend that they are using HTML 4 to using the short version of the doctype that doesn't distinguish whether the page is written in HTML 2 or HTML 5).



    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.
    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="^$">

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:


    Quote Originally Posted by itmitică View Post
    1. "safely to look at as an advance", or ""safely to look at as progress".
    Neither of those makes any sense -- I think the word "safely" is what's throwing me since that's an adverb, not a transitive verb. That whole statement ending up being akin to "When nine hundred years old you reach, look as good, you will not, hmmm?"


    Quote Originally Posted by itmitică View Post
    I mean the CSS3 that starts dictating what links do, how links behave like, instead of what links look like.
    ... and how is the behavior and PRESENTATION of that effect any different that using a hash link? Hell, if you look at the mechanism:

    Code:
    	<section id="acc1">
    		<h2><a href="#acc1">Title One</a></h2>
    		<p>This content appears on page 1.</p>
    		<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum lacinia elit nec mi ornare et viverra massa pharetra. Phasellus mollis, massa sed suscipit pharetra.</p>
    		<p class="accnav"><a href="#acc2">next ➧</a></p>
    	</section>
    It IS a hash link effect; it's just being PRESENTED different -- that's not behavior, it's not actually CHANGING the content or checking the content, it's just presenting it in a different manner; WASTING javascript on that would be crossing the line; but people have been crossing that line from JS for ages with fat bloated stupid nonsense.

    That's not behavior.

    Though personally I'd never put an effect like that on a website since transitions don't work with auto, and fixed dimensions suck.... but that's a whole different argument.

    Quote Originally Posted by itmitică View Post
    3. Again, links in nav are not part of a sentence.
    and how is one saying that? With other tags, or in your case:

    Quote Originally Posted by itmitică View Post
    Romania, Moldova, Bulgaria, Ukraine, Poland.
    PUNCTUATION! Throw a few commas between them then fine, but I'm seeing people do this with 5:

    <nav><a href="#">Home</a><a href="#">Forums</a><a href="#">Links</a></nav>

    Which is a laugh as semantically that's the same as saying
    <nav>HomeForumsLinks</nav>

    Or this with 5:
    <nav>
    <a href="#">Home</a>
    <a href="#">Forums</a>
    <a href="#">Links</a>
    </nav>

    Which is the same as saying
    <nav>Home Forums Links</nav> -- the single block level wrapper doesn't change that the special inline element A does jack to the meaning of it's content.

    Since anchor does NOT break word or change the meaning. You're latching onto the word "sentence" when the more important part was -- ok, let's spell it out: "run-on of unstyled undelimited unbroken text with no pauses."

    See what I did there: an enumeration. A list. If this was a conversation then yes, those would belong in a paragraph at least. They could also be in a list element. But that's scenario number one for nav use.

    Quote Originally Posted by itmitică View Post
    Scenario number two: we're not talking about content in nav like that, a conversation. Content in nav can also be plain simple: an enumeration of links.
    Enumerated by WHAT? Spaces are not a delimiter, and anchors do not change the meaning of what they are wrapping or add separation in any way, shape or form, which is why it's just as valid to do:

    <b>H</b>Home
    or
    <span>H</span>Home
    or
    <a href="#" accesskey="H">H</a>ome

    without breaking up the word...

    While
    <a href="#">Home</a>
    <a href="#">Our Story</a>

    "Home Our Story" with no delimiters makes about as much sense as "safely to look at as an an advance" or "engrish moist goodry I be speaking" -- and that's what omitting block level containers around them, delimiter text between them (punctuation), or any other form of separation means.

    Quote Originally Posted by itmitică View Post
    This is a whole other argument: HTML5 is so different in some areas that people with habits have trouble adjusting to it. Which is just fine, since HTML5 offers them the option of remaining true to their habits. Like SASS does: any valid CSS is also valid SASS.
    ... and some people are trying to make it more different than it is -- and different from what the specification and it's examples even SAY.

    Putting what you are saying squarely into the same category of nonsense as "text/html makes it not XHTML" or "full XHTML isn't supported because you can't do <div />" -- it's the same complete misunderstanding of what the specification pages even SAY.

    Which again, look at their examples; still using list for menus, and the nav section that isn't a list is in prose with paragraphs. The natural language of the text doing the job instead of just randomly slapping words together without block delimiters. Even your own argument uses commas as breaks/delimiters... whitespace and inline level tags are not a delimiter in HTML! EVEN 5!!!

    Quote Originally Posted by itmitică View Post
    Oh, and HAML, at least, does simplify the markup process and it does help you make fewer to no errors.
    Looks more like being too lazy to type out full opens and closes, which IMHO is more likely to cause errors/mistakes since you can't clearly see them.

    Quote Originally Posted by itmitică View Post
    And then there's Slim for you, if HAML is still your bad medicine.
    Oh yes, because removing ALL structural elements makes it even clearer... RIGHT... though I can see how it might be useful for people who can actually read with color syntax highlighting; which is to say USELESS for me since that headache inducing acid trip is one of the many 'modern' tools on my **** list of how not to learn to code.

    Quote Originally Posted by itmitică View Post
    What I don't get is why are you still arguing that writing opening tags/closing tags is safer and smarter than having a mechanism in place to automatically do that for you, error free.
    Because it's more cryptic, harder to read, likely breaks if you miss even something as simple as a tab, you can't see where anything actually ends in a clear or realistic fashion or even indicate what is being cleared when scrolling down anything that's bigger than you have lines on the screen.

    Oh yes, such a big improvement. You know, there's a reason Prolog was stillborn... and Ruby was stillborn until someone had the brilliant idea to make it do something useful with RAILS. But again, I'm a Wirth language guy -- I'm all about verbose code with clear openings and endings to elements/blocks/sections. Relying on whitespace to handle it (python comes to mind) or using oddball shortcuts or funky orders to indicate it is NOT clear code; it's the exact opposite...

    All I can figure is hunt and peck people who can't take the time to learn to use the input device they should know how to use are behind this garbage; see Ruby's "elsif" or Mozilla "rust" for prime examples of that type of shortsighted half-assed idiocy in action.... where it ends up being akin to class="f l bR cf w90 a" -- effectively useless a year after you write it or for the next poor shlub who comes along and has to maintain it.

    though also, if you have enough markup to require those types of 'shortcuts' or precompilers... yeah, lets call it what it is, a precompiler... you have enough markup to need those, there's probably something WRONG with your markup.

  5. #30
    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 felgall View Post
    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.
    or that same 20 lines + jquery for something that's CSS' job. As we were joking about a year ago someone posts the question "how do I make a link red on hover" some script-tard will creep out of the woodwork saying "use jquery".

    As evidenced by the trash nube-bait found on sites like Dynamic Drive.

  6. #31
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall
    Penalties for writing bad markup - such as refusing to display the page at all
    While something like this would be nice, since it'd make it much easier to separate the good and bad developers... it's not going to happen.

    As Tantek Çelik (Mozilla’s web standards lead) said in an interview with Eric Meyer: "When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device."

    Nobody is going to enforce the bad markup = nothing rendered strategy in their browser, because then the browsers that don't look "better". So, all of the browsers will contain to work on their "guessing" features so they can render bad markup. Unfortunately that's how the real world works.

    I think we're wasting our breath hoping for this magical perfect world were all websites are coded properly. It's not going to happen. The best we can do is continue to evangelize good practices and enforce them where we can.

    HTML5 may not help curb bad habits, but that doesn't mean it prohibits you from using self-enforce good practices.

  7. #32
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    I really don't like the new none media tags of HTML5 to much but given everyone is huffing and puffing about it these days it would probably be difficult to get a job without something to show. I haven't had to deal with it yet but I would assume dropping HTML5/CSS3 knowledge is a must. It may be crap… but the opinions of many outweigh the opinions of a small majority. Especially when those supporting it are leaders in the industry. A year or so back I though there might be hope but I have pretty much given up on that considering all the hype and promotion it is getting. At this point I'm thinking it is better to embrace it and make a good living than keep to achieve some self-fulfilling prophecy for nothing but a few pats on the back by a small majority. deathshadow60 or anyone can say how much HTML5 sucks and is not ready but the fact of the matter is all the promotion and support it is getting by the leaders in the industry makes it alright. Sad… but true. I may have just talked myself into using it to the full extent for my current project… oh this thread is dangerous…
    The only code I hate more than my own is everyone else's.

  8. #33
    SitePoint Mentor silver trophybronze trophy

    Join Date
    Feb 2008
    Location
    Preston, Lancashire
    Posts
    1,378
    Mentioned
    72 Post(s)
    Tagged
    1 Thread(s)
    The hype is something out of this world. It's like when everybody was saying web 2.0 not knowing what this even was. Many even incorporate such words in their proposal. So you can imagine the ambiguity there.

    HTML5 is a lot of the same. Many are using HTML5 knowing it does not improve, just to get on the bandwagon. Publishers, article writers etc. are all writing about HTML5 to join the hype and to get recognition whilst they do it. It's like a vicious circle, but during that time you either profit from this circle or be left out. Big companies believe what they read and when they've read it they will no doubt post jobs in this related field. I've already seen well paid jobs asking for HTML5 and CSS3.
    follow me on ayyelo, Easy WordPress; specializing in setting up themes!

  9. #34
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Jason,

    You keep saying you don't want to phrase the content in nav... but you do. It's a simple concept you can't seem to grasp: links, one after the other, are not words in a sentence.

    But I keep looking at you revolving around your tail, saying that the enumeration it's not a sentence yet is should make sense as a text when read one after the other, like a sentence does. You require punctuation. There is no need for that. Links in nav are like cans in a shelf: pick one, don't try to make the shelf a book you have to read. And I believe you manage to pick one even if they don't have any punctuation to separate among them.

    So... inspect the shelf, don't read it. It will never make sense like that. Get it now?

    And you'll notice some examples in the specs that aren't using lists. And those examples also have more complex content, that's why there are a few more elements beside links in them.

    Anyway.

    Basically: when I put links in nav, by its definition, I don't have to throw wrapping elements around them. Any other element element, beside links, means overkill.
    Unless the content in the nav element is complex enough to demand another semantic construction. A simple enumeration of a few links is not. Is not.

    Simple menus or multilevel menus spells out lists. Notice the difference: menus, nav.

    And it doesn't mean it was the right choice. Lists are used in menus because they degraded in a comprehensible way. Lists are used in menus for structure, and not for semantics needs. Lists replaced divs in menus and that was regarded as a semantics win. Is it?


    What is a link? A piece of content, inside an anchor element.

    What is nav? A section with links, pieces of content, inside anchor element. Like a shelf (nav), with cans (anchors), and the juicy content inside them. You'll also notice the content in one can doesn't run over the content in some other.

    When I put links in nav, the content is already well delimited. Being inside the anchor tags. Automatically wrapping lists around them is overkill. Why slapping some other outer li tags around them will make more sense? Only because you can't step outside of your habit's box. A habit gone bad.


    When do I think about putting other elements in the nav element? When my nav content starts telling a story. That is, when I have enough links and enough content to semantically structure that story. And using lists for that is but one way to tell that story.

    When do I think about wrapping lists around links in nav? Only when is semantically viable. Which may be never. A list element has a place wrapping links only when is semantically required. Not to structure the content, to delimit the content, or in hope it will be, somehow, brighter than the sun

  10. #35
    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 keep saying you don't want to phrase the content in nav... but you do. It's a simple concept you can't seem to grasp: links, one after the other, are not words in a sentence.

    But I keep looking at you revolving around your tail, saying that the enumeration it's not a sentence yet is should make sense as a text when read one after the other, like a sentence does. You require punctuation. There is no need for that. Links in nav are like cans in a shelf: pick one, don't try to make the shelf a book you have to read. And I believe you manage to pick one even if they don't have any punctuation to separate among them.

    So... inspect the shelf, don't read it. It will never make sense like that. Get it now?
    Honestly, I'm wondering if we're hitting up against ranguage rarrier, since I'm having a devil of a time figuring out what it is the above is even trying to say.... "don't want to phrase the content in nav"?!? What does that even MEAN? " don't try to make the shelf a book you have to read"?!? HUH? Soon the super karate monkey death car would park in my space. But Jimmy has fancy plans... and pants to match.

    So I'm not 'getting it' -- because to be frank I'm having trouble deciphering what on earth you were even trying to say there... though that seems to be a problem with a LOT of posts 'round these parts lately. Like we're getting this weird mix of Yoda and Super Karate Monkey Death Car.

    Quote Originally Posted by itmitică View Post
    And you'll notice some examples in the specs that aren't using lists. And those examples also have more complex content, that's why there are a few more elements beside links in them.
    Which is EXACTLY what I'm saying -- they have more complex content because you need more complex content than just running out a bunch of words with no delimiters. Whitespace aren't delimiters, anchors aren't delimiters, so it's just a jumble of nonsensical words. Putting it into sentences with punctuation, making it a comma separated list or using other punctuation, THEN it would make sense. Just going:

    <a href="#">My Profile</a>
    <a href="#">Settings</a>
    <a href="#">Log Out</a>

    EVEN INSIDE NAV, is the same as omitting those anchors altogether gramatically and semantically. It is semantically the EXACT SAME THING as just going "My Profile Settings Log Out" as if there was no markup -- which is gibberish where you can't even tell where one thing begins and the next one ends. It's WHY we were supposed to use lists on that stuff in the first place -- and NAV does absolutely nothing to change that! Might as well be saying "The monkey clown horrible karate round and yummy like cute small baby chick would beat the donkey."

    Quote Originally Posted by itmitică View Post
    A simple enumeration of a few links is not. Is not.
    enumerated by WHAT? Anchors don't enumerate, spaces don't enumerate, the wrapping container doesn't enumerate them... You need delimiters or block level tags to SAY they're enumerated -- otherwise you're just dumping random words or groups of words in there any old way... the OPPOSITE of semantic markup. You're gonna do that one might as well go back to not using paragraphs and going with double-breaks and instead of using heading tags just do <font size="+1"><b>

    That's what I think you're missing -- ANCHORS DO NOT CHANGE THE MEANING OR STRUCTURE OF THE TEXT THEY ARE APPLIED TO -- HTML 5 does nothing to change that! Omitting block level containers, text delimiters or natural language is the same as taking your book shelf, ripping all the bindings off the books, cutting all the pages to the same side then stuffing them loose on the shelf end to end. Good luck finding where one book ends and the next begins.

  11. #36
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Your verbose obsession over a simple enumeration of links. The fact that they are there one after the other, in a dedicated, semantic container element, that alone makes it a semantic enumeration. You're trying to write a lengthy poem that bores the hell out of everybody, when a simple haiku is all your readers ask.

    The links in nav HAVE NO MEANING. The CONTENT in which they appear, if any, has to have some meaning. But IF you only got links in it, then LISTS are the last things you can apply and say: "Whoa, semantics!". It's DIV's you have to put there, for structure, not lists.

    Off Topic:

    You sure people understand better with caps on!? Or do you believe battles are easily won with cheap little angry sarcasm over language?! I won't go down the Gorilla War path with you, I know better than that.



    Nav is a semantic container. For "links". Not for "lists of links". You're adding lists because you're used to a lie: a ul, and an id="nav" for it, equals the biggest semantic win. It was not. It still isn't. It will never be.

    You can add div's to structure your links, you can add headings, paragraphs in the nav element, if you want it to make sense when reading it like a book, and it's possible you may NEVER use lists in it. LISTS AREN'T A MUST!


    Let's say anchors don't have a role to play: "ANCHORS DO NOT CHANGE THE MEANING OR STRUCTURE OF THE TEXT THEY ARE APPLIED TO".

    Well then, you make a ul, put some "regular" content in its li elements (no links what so ever), and then put an id="nav" to your ul? Does it still apply? Is an anchor a missing link somehow?

    After that, you make a ul, put some anchors in its li elements, and then put an id="ניווט" to your ul? Does it still spell out as being a navigation element? Can you go straight to navigation then?


    You're missing a lot of points more often because you believe your native language rules over the whole world. Well, it's not, and a nav element is one missing link over all natural languages involved in web developing. It's a step forward. If you can see that.

  12. #37
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:


    Quote Originally Posted by itmitică View Post
    You sure people understand better with caps on!?
    Nah, BBCode just lacks STRONG or EM tags.


    Quote Originally Posted by itmitică View Post
    Nav is a semantic container. For "links".
    Agreed.

    Quote Originally Posted by itmitică View Post
    Not for "lists of links". You're adding lists because you're used to a lie: a ul, and an id="nav" for it, equals the biggest semantic win.
    No, because if I have a list I need to make it a list, instead of a bunch of words just thrown in there randomly with nothing separating them -- and again, anchors don't separate/delimit them. SPACES don't separate/delimit them since you can also have spaces INSIDE them. You seem to think I'm saying you HAVE to use a list - and AGAIN I'm saying you need to use DELIMITERS, which could be a list, or P, or DIV, or commas, or hyphens, or natural language text.

    Failing to add punctuation, block level containers of some sort (not just lists) or natural language texts -- and just dumping the average menu into NAV without any extra markup is exactly that -- just throwing the words in there any old way. That's so simple I can't understand how you could even argue it.

    Quote Originally Posted by itmitică View Post
    Well then, you make a ul, put some "regular" content in its li elements (no links what so ever), and then put an id="nav" to your ul? Does it still apply? Is an anchor a missing link somehow?
    and...
    Quote Originally Posted by itmitică View Post
    After that, you make a ul, put some anchors in its li elements, and then put an id="ניווט" to your ul? Does it still spell out as being a navigation element? Can you go straight to navigation then?
    It's not about saying it's a navigation, it's about saying it's a list -- so that the words inside it are broken up semantically by SOMETHING instead of just being crapped inside a container any old way with NOTHING MEANINGFUL separating them. Why you are even bringing an ID into the equation is beyond me since that means jack so far as semantics are concerned and has nothing to even do with the discussion. Only reason to put an ID there is to hotlink to it with a hash or to target it with CSS or scripting... in other words NOTHING to do with the discussion.

    BECAUSE AGAIN:

    <nav><a href="#">My Profile</a><a href="#">Settings</a><a href="#">Log Out</a></nav>

    Is gramatically and semantically the EXACT SAME THING as saying:
    <nav>My ProfileSettingsLog Out</nav>

    and
    <nav>
    <a href="#">My Profile</a>
    <a href="#">Settings</a>
    <a href="#">Log Out</a>
    </nav>

    Is gramatically and semantically the EXACT SAME THING as saying:
    <nav>My Profile Settings Log out</nav>

    Because anchor opens/closes are no more separating the content than a SPAN or B or I or any other phrase element would! If it's a list of choices, you put it in a list; because as you implied and as the specification says, all that NAV means is that there are navigational links inside this block level container. "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." -- That's it...

    It does NOT provide any formatting or structure for it's content; as indicated by it being nothing more than a block level container and the ONLY reason for it's existence according to the specification being as a indicator that allows some user agents to skip past it to get to the content. Which means if you have a list of choices, it still goes in a list. Which means if you have paragraphs, you put them in paragraphs... and if they are multiple separate items that don't fit any of those descriptions, you'd use DIV, or punctuation, or any other form of delimiter to separate them grammatically.

    Otherwise, AGAIN, you're just dumping the words in there any old way with NOTHING to say they are separate items grammatically or structurally...

  13. #38
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Geez, I've agreed and disagreed with DS about 50 times in this thread. =p

    However, this time, I completely agree with DS.

    Just because you are putting something in a nav element doesn't mean you can neglect it's other semantics. A list of items needs to be in a list element. Period.

    DS' sentence explanation is completely accurate, though it may seem a bit off.

    However, consider this:
    <p>This is a <a href="#">picture</a> of a <a href="#">cookie</a>.</p>

    Do you agree that semantically is equivalent to:
    <p>This is a picture of a cookie.</p>

    (If you don't, I give up now. =p)

    So, why would the anchors magically give meaning to this?
    Code:
    <nav>
    <a href="#">My Profile</a>
    <a href="#">Settings</a>
    <a href="#">Log Out</a>
    </nav>
    One thing that's nice about HTML is a list's a list, a paragraph's a paragraph, and so on. All elements have exactly one semantic meaning. Their parent containers have no influence on that meaning.

  14. #39
    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 samanime View Post
    Their parent containers have no influence on that meaning.
    Which is why MOST of the fancy new HTML 5 structural elements are pointless redundancies -- since the content inside them still needs semantic tags; Notice that for HEADER you'd still be putting numbered headings in them? The examples for NAV, ARTICLE and SECTION are wrapping tags that already have meaning? Putting extra 'semantic' meanings around tags that already HAVE meanings is pointless; yet that's EXACTLY what the new elements seem to be for.

    Which is why I still say if people bothered to use H1..H6 and HR properly, you wouldn't need any of it excepting perhaps NAV's suggestion of user agents skipping it in some instances -- at which point why do we need a new tag?

  15. #40
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I disagree with that.

    While they are redundant now, a parent does give semantic meaning to it's children (in a sense). For example, the nav element would help screen readers provide more consistent access to navigation (or at least a skip to navigation feature without the need to actually implement one).

    Likewise, the section and article tags have the handy ability that you can restart your headers while still giving your document a proper outline (which is an amazing feature for CMS and the like). Also, nested sections and articles give meaning as well (an example they use is having a nested section in a blog post which could be for comments).

    The time element is also a great one for providing a way to give machine-readable times while still providing the format you want for users.

    I'm not saying I like all of them, but there are about a dozen that after studying the current specs and doing some research I've come to embrace. It still has some growing pains, but hopefully those will get sorted out and we'll get something that adds new features without becoming redundant. The ones I currently like are nav, time, section, article, header, footer (when inside of section or article), video, audio (though they still have many growing pains ahead), and canvas (I'm on the fence with this one, in regards to if we need another element, but I use it because it's the only real way to access the canvas API). I'm still undecided on the others.

    Most of the elements don't give the end-user anything new in and of themselves, however, it gives more semantic meaning to certain things, which then allows user agents to do things they couldn't (or at least couldn't reliably) before.

    (It's fun being in the middle, I get to argue no matter what is posted. =p)

  16. #41
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    Just because you are putting something in a nav element doesn't mean you can neglect it's other semantics. A list of items needs to be in a list element. Period.
    But who says when a list is really a list? Having two somehow related item one after the other means you got a list? Where is this lists obsession, this lists overkill stops?


    Quote Originally Posted by samanime View Post
    However, consider this:
    <p>This is a <a href="#">picture</a> of a <a href="#">cookie</a>.</p>

    Do you agree that semantically is equivalent to:
    <p>This is a picture of a cookie.</p>
    Consider this:
    <nav>Here you'll find <a href="#">pictures</a> and <a href="#">cookies.</a></nav>


    Semantically equivalent to:
    <nav>
    <a href="#">Pictures</a>
    <a href="#">Cookies</a>
    </nav>

    Do you honestly believe you need lists for this?
    (If you do, I give up now. =p)


    Quote Originally Posted by samanime View Post
    So, why would the anchors magically give meaning to this?
    Code:
    <nav>
    <a href="#">My Profile</a>
    <a href="#">Settings</a>
    <a href="#">Log Out</a>
    </nav>
    One thing that's nice about HTML is a list's a list, a paragraph's a paragraph, and so on. All elements have exactly one semantic meaning. Their parent containers have no influence on that meaning.
    Here we go again with the meaning. What meaning is there in a shelf with three cans: none. It's a shelf, pick one already. Do you need to make a shelf for each can?

    Don't try to find another "meaning" on top of the semantics already in place. And if you want to use lists with that one, you really have to do something like this:

    Code:
    <nav>
    <h1>Welcome</h1>
    <p>Thank you for embarking on a journey around my website.</p>
    <p>Here are the places I recommend you to visit:</p>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>
    Notice the verbosity required?


    Code:
    <nav>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>
    doesn't mean zit more than

    Code:
    <nav>
    <a href="#">My Profile</a>
    <a href="#">Settings</a>
    <a href="#">Log Out</a>
    </nav>
    because the ul element only serves a mechanical separation purpose, it's just a punctuation replacement, it conveys no extra "meaning", it only serves an obsession for blindly wrapping links in lists. That's what's wrong: lists looked at as div's with list bullets in front of them.

    I mean, let's talk about serious semantics, not semantics that suits your bad habits.

  17. #42
    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
    But who says when a list is really a list? Having two somehow related item one after the other means you got a list? Where is this lists obsession, this lists overkill stops?
    That it's a list? That it needs delimiters? A menu is a list -- so if you have a menu, use a list tag... That's about as simple as you can get. If it's not a menu and it's a natural language sentence, P is probably more appropriate -- if for some weird reason its' not a list, use punctuation, or some other block level tag to separate them. Otherwise you're just slapping words in there any old way and making a run-on of gibberish.

    Quote Originally Posted by itmitică View Post
    Consider this:
    <nav>Here you'll find <a href="#">pictures</a> and <a href="#">cookies.</a></nav>
    Nothing wrong with that - natural language sentence where it's clear they are separate thoughts.

    Quote Originally Posted by itmitică View Post
    Semantically equivalent to:
    <nav>
    <a href="#">Pictures</a>
    <a href="#">Cookies</a>
    </nav>
    Not even close to semantically equivalent because there's NOTHING separating them, nothing to put them in context, you're just slapping words in there any old way! When dealing with semantics special or phrase elements do not break flow, therein they do not say they are separate choices, thoughts or destinations.

    Quote Originally Posted by itmitică View Post
    Do you honestly believe you need lists for this? (If you do, I give up now. =p)
    Lists, or add commas between them, or put it in a sentence, or add SOMETHING to tell us they are separate from each-other. Otherwise it's just a run-on of words just slapped in there any old way... since:

    "pictures cookies" with nothing else around it is gibberish; you need something to separate them -- whitespace and anchors aren't it!

    Quote Originally Posted by itmitică View Post
    Here we go again with the meaning. What meaning is there in a shelf with three cans: none. It's a shelf, pick one already. Do you need to make a shelf for each can?
    In that example (and why I choose it) is that's actually five cans -- and since anchors apply NO MEANING or SEPARATION between then, You don't know if they're all five different choices, you don't know if "My Profile Choices" are all one 'can' -- That provides NOTHING to say there's just three cans or if it's just one big can or anything else!

    Quote Originally Posted by itmitică View Post
    doesn't mean zit more than
    Means a lot more, it means it's a list; as opposed to without the list where it's just a bunch of words with NOTHING separating them because as a special inline Anchors do NOT make them separate items!

    Quote Originally Posted by itmitică View Post
    because the ul element only serves a mechanical separation purpose, it's just a punctuation replacement, it conveys no extra "meaning"
    Apart from saying it's a list which is the ENTIRE reason semantically you're supposed to do it in the first place... Calling good practice a bad habit and then slapping a bunch of text with NO punctuation or formatting at all?

    RIGHT. That makes sense... Don't know where you got that from, but WOW that's some messed up nonsense that has NOTHING to do with proper practice of semantics, anything in either the HTML 4 or HTML 5 spec, and on the whole feels like you are pulling this out of your rump as we go.

  18. #43
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    BTW:
    Quote Originally Posted by itmitică View Post
    Where is this lists obsession, this lists overkill stops?
    You seem to be overfocusing on 'list' as opposed to 'something to format the text, be it a list, natural language text, or punctuation' -- in fact you're raving about lists like the anti-table folks who won't even use tables on tabular data.

    I was thinking on your re-using my examples to support your view on it, and more specifically your shelf analogy... My saying "you can't tell if it's five cans, three cans or one can" being better explained in another of my posts, and I just think it needs to be said again:

    What you are defending is more like having a bookshelf where all the books have the same size pages, and you've ripped all the pages out of their bindings and just shoved them on a shelf end-to-end; good luck telling where one book begins and another book ends... because instead of nice neat covers containing sets of pages, you just have a endless stack of paper with no clear divisions.

    "My Profile Settings Log Out" -- is that five items? Three items? One Item? Your guess is as good as mine, and that's what not having SOME FORM of delimiter other than whitespace basically is saying.

    ... and anchors aren't delimiters. Screen readers, search engines, non-desktop screen renderers; they'll have no clue -- and that's the entire REASON to use semantic markup instead of just sleazing out presentational markup of nothing but font, bold and line-breaks. At that point you should probably not even bother using HMTL/CSS and just ASCII format the text and set BODY to "white-space: pre;" with no other tags for all the difference it makes.

    Since that's basically what you're advocating.

    Let's use an example you used:
    <p>This is a <a href="#">picture</a> of a <a href="#">cookie</a>.</p>

    Do you consider that four separate items, or a single sentence? It most certainly isn't two items thanks to the CDATA textnodes, it's certainly not four separate items because it's all one flow text. Inline-level phrasing -- as such removing all the text between them just makes it gibberish.

  19. #44
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Jason,

    I'm focusing on lists because you said:
    Quote Originally Posted by deathshadow60 View Post
    'nav' -- like most of the new allegedly semantic structural containers seems to be JUST for the people who were slapping a div around their UL for nothing
    which clearly shows me you're missing the point on nav, like you're missing the point on a bunch of whole other HTML5 elements.

    First off, a list can't be used in menus unless those menus have a context for those lists. If you don't have a context for a list, then you're taking a shortcut. See my nav example where I show you need to have a context for a list.

    Secondly, I'm glad to see you've adopted my view on navigation, that is that navigation can be links with everything, not just links in lists. That's a step forward.

    Slapping lists on a bunch of links just to structure them is opportunistic, is not semantic heaven. Much like pretending the content in nav has to make sense like a book chapter. But you insisted ul, and not div, or p, or some other elements, are a must, always and forever. I strongly disagree with you since.

    And here is where you exaggerate: like I said, if you only have links, anchors are enough:
    Quote Originally Posted by deathshadow60 View Post
    every blasted anchor on a page is 'navigation'
    So? You're kind of not making sense anymore.

    I said that when you have other content in nav, you should use the proper elements for that content. I never said "restrain your self and put only links in there", I said "Jason is wrong thinking nav is an ul element in disguise since he is wrong about using ul as a semantic element for a bunch of links in the first place".

    So, I have nothing against punctuation, paragraphs and such to be present in nav. Even lists, with the condition that there is a context requiring their presence. And that doesn't mean you saying: "look, I see here lists of links", no. Actual content that dictates a list to be present.

    Since nav is pretty much self explanatory, just the anchors alone will do. If I have complex enough content in nav, meaning more than just a bunch of links, or links complex enough as content, then, other elements, semantic or not, but proper ones, non the less, can help better distinguish them. Only then.

    Otherwise, you're just following a bad habit: lists are for a bunch of links 'cos a benevolent dictator say so and you should obey No, I don't! The dictator needs to change its attitude.

    Off Topic:


    As about your Gorilla War approach to dialog, this one has Jason written all over it:
    http://www.youtube.com/watch?v=nITLob098W8

    "There are two ways of living: giving a f-word, not giving a f-word. GIVE A NEGATIVE F-WORD !"
    "Giving a negative f-word can destroy the universe as we know it !"
    "I don't care!!"

    LOL

  20. #45
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    I think you're not understanding my posts about as much as I'm not understanding yours.

    Quote Originally Posted by itmitică View Post
    which clearly shows me you're missing the point on nav, like you're missing the point on a bunch of whole other HTML5 elements.
    The alleged purpose, the real one that holds any water, is it being a hint to certain user agents that it's ok to skip what it wraps to get to the main content of the page -- a minor and pointless aid not worthy of a tag... so why bother having the tag... Only thing I can fathom is to placate the people who go:

    <div id="nav"><ul>

    Site after site you'll see people wrapping a UL in a DIV -- even if as you say it doesn't need the UL, then it's still extra wasted markup as anything they are doing to the div could be done to the UL, or vice versa -- bad markup is bad markup, there's no reason to justify it... most all of these allegedly semantic extra tags from HTML 5 seems to fall into one of two categories -- legitimizing the bad practice of slapping extra DIV around everything for no good reason (HEADER, NAV and SECTION being the worst offenders) when the existing semantic tags and proper use of heading tags should already be providing MORE than enough semantics in that regard...

    Quote Originally Posted by itmitică View Post
    First off, a list can't be used in menus unless those menus have a context for those lists. If you don't have a context for a list, then you're taking a shortcut. See my nav example where I show you need to have a context for a list.
    What does that even mean, "a context for a list"?!? I literally cannot figure out what it is you are even trying to say, or even what example that would apply to.

    Quote Originally Posted by itmitică View Post
    Secondly, I'm glad to see you've adopted my view on navigation, that is that navigation can be links with everything, not just links in lists. That's a step forward.
    Adopt nothing, you were shoving words in people's mouths and failing to understand what was being said from the start if you thought anyone here was saying otherwise!

    Quote Originally Posted by itmitică View Post
    But you insisted ul, and not div, or p, or some other elements, are a must, always and forever
    Where did you see me say or even imply that -- that has ABSOLUTELY NOTHING TO DO with any of my posts so far. If you thought I was saying that, then you completely failed to understand anything I was saying!

    Quote Originally Posted by itmitică View Post
    So? You're kind of not making sense anymore.
    (in regards to 'every anchor on a page is navigation)
    I was just saying that class="nav" or id="nav" or even NAV as a tag is uselessly vague; cryptic, not verbose... bordering on being gibberish -- but again I'm a Wirth language type of guy, so I like to have meaningful class-names, meaningful function names, and fail to grasp this obsession of late on how "everything has to be abbreviated"... If every anchor on a page is navigation, what is the point of having a navigation tag? If every anchor on a page is navigation, how does class="nav" under HTML 4 help anyone figure out what a list of links even is? It's as uselessly vague as the idiocy you see from time to time of people going class="style1" "style2" etc, etc.... or the nonsense like class="b lt qp dl ct cf". Just like the idiotic 'link src="style.css"' begging the question "which style?" -- screen? Print? handheld?

    Piss poor naming conventions make code harder to maintain - that's all I was saying there.

    Quote Originally Posted by itmitică View Post
    Jason is wrong thinking nav is an ul element in disguise since he is wrong about using ul as a semantic element for a bunch of links in the first place".
    which I think is the problem because I didn't say that!!!. In fact my reading that you apparently thought that was my meaning just brought forth a string of expletives that would make truckers at a truck stop say "watch your mouth, there are mechanics in here." If you thought that was my intent or what I was saying, you failed to comprehend my posts! COMPLETELY!

    Quote Originally Posted by itmitică View Post
    So, I have nothing against punctuation, paragraphs and such to be present in nav. Even lists, with the condition that there is a context requiring their presence. And that doesn't mean you saying: "look, I see here lists of links", no. Actual content that dictates a list to be present.
    ... and yet it appeared you were defending the LACK of such elements as valid, which is where I took issue. that is what you were saying and showing in your examples -- as per this next bit I'm quoting:

    Quote Originally Posted by itmitică View Post
    Since nav is pretty much self explanatory, just the anchors alone will do.
    Again, no they don't... that's EXACTLY what I've been saying is wrong and taking issue with as anchors do not change the flow and as such do not delimit the values in any way. Using JUST the anchors means no structure -- words just slapped inside it any old way with no method whatsoever of telling that they are different thoughts. As in my last post, is that five separate items, three separate items, one separate items; it's like a bookshelf filled with unbound pages of uniform size.

    Quote Originally Posted by itmitică View Post
    Otherwise, you're just following a bad habit: lists are for a bunch of links 'cos a benevolent dictator say so and you should obey No, I don't! The dictator needs to change its attitude.
    No, I'd be using a list around a list of choices; that's what semantic markup is -- lists around lists, headings around headings, paragraphs around paragraphs... I wouldn't be using it 'just because'. It's certainly not a bad habit on say... menus, since menus are LISTS of choices.

    Off Topic:


    Quote Originally Posted by itmitică View Post
    As about your Gorilla War approach to dialog, this one has Jason written all over it:
    Gorilla war? What, you mean like monkeys flinging feces at visitors to the zoo? Guerrilla; it's Spanish for "little war" (making Guerilla War redundant... kinda like &copy; copyright). Methinks you meant Che Guevara, not Jane Goodall. Next thing you'll be talking about what a rouge I am going down to the local bizarre to buy some things, awaiting your next post with baited breath.

    (rogue, bazaar and bated, respectively)

    Though I have no idea what that annoying **** was you linked to, or what it has to do with anything -- had to kill it after five seconds for being too stupid.

    You know noonope this little shell game of yours with accounts every time you get banned grows tiresome, as does your intentional belligerence and repeated attempts to take things out of context, stuff words in peoples mouths, and claim things were said that have nothing to do with the originating post.

  21. #46
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    A context for a list:

    Content that prepares you for a list appearing. Lists are not something you can just pull out of the sleeve whenever convenient.

    "Site after site doing it" it's not a reason. There was a time when "site after site" were doing tables for layout. And that became a bad habit.

    Quote Originally Posted by itmitică View Post
    And if you want to use lists with that one, you really have to do something like this:

    Code:
    <nav>
    <h1>Welcome</h1>
    <p>Thank you for embarking on a journey around my website.</p>
    <p>Here are the places I recommend you to visit:</p>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>
    Notice the verbosity required?
    Notice the p preparing the list? The whole heading and introductory stuff? Why would it be OK for you to say: "don't strip down the nav to links alone" but it's not OK for me to say "don't strip down content to lists alone", or "don't just run lists out of the blue"? Since, like you, talking about more elements for links in nav, I believe you need more content in order to have lists anywhere, lists alone doesn't cut it. At all.

    I'll leave it to that, since, apparently, it's about to escalate into something else. Not on my behalf.

    Off Topic:



    Quote Originally Posted by deathshadow60 View Post
    Off Topic:



    Gorilla war? What, you mean like monkeys flinging feces at visitors to the zoo? Guerrilla; it's Spanish for "little war" (making Guerilla War redundant... kinda like © copyright). Methinks you meant Che Guevara, not Jane Goodall. Next thing you'll be talking about what a rouge I am going down to the local bizarre to buy some things, awaiting your next post with baited breath.
    You read too much into words and you document too little before jumping to conclusions and resorting to cheap shots:

    http://www.gorillawarpaintball.com
    http://paintballreservations.com/gorilla_war

    I bet you can find a coloring war game near your home too. It's a fun game to play, that's all. Notice the gorilla masks? Have a good day.

  22. #47
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,822
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by samanime View Post
    While something like this would be nice, since it'd make it much easier to separate the good and bad developers... it's not going to happen..
    Why isn't it going to happen. Just imagine that we are far enough in the future for IE8 to be dead and gone.

    At that point it becomes practical to use XHTML. At least some web browsers will stop at the point where they uncover a syntax error in the XHTML and will only render the page to that point followed by an error message telling you what is wrong. You use that information while TESTING your web page to fix the errors in the XHTML and get it rendering the page properly - only the final working version gets uploaded to the web and so all your visitors (except for the one person still using IE8) will see your page exactly the same. Only you got to see the broken version because you fixed the error that caused it to be broken before you uploaded it to the web. The result is that the uploaded XHTML web pages are all valid XHTML without even needing to mess about with validators.

    The bad developers will be able to continue using HTML and uploading any old garbage to the web even where it isn't valid HTML.

    The only two things necessary for that to happen is for IE8 to die out and for the good developers to switch from using HTML to XHTML once all the browsers support it (and IE8 is the most recently released browser that doesn't support XHTML).

    So you are wrong - it is going to happen because there's nothing to prevent it happening once IE8 is deaqd.
    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="^$">

  23. #48
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    First, to the list thing.

    If it's two items that are related, it probably is a list. You can give context to a list from within the list. The nav element helps add context:
    Code:
    <nav>
      <ul>
        <li><a href="#">A</a></li>
        <li><a href="#">B</a></li>
      </ul>
    </nav>
    The context for that list is it's a navigation. You don't have to add all of that extra stuff to give it context.

    And what's wrong with being verbose? That's what HTML is. It's a verbose description of a document. If verbose was bad, then we should all just put stuff into as few divs as possible and ignore all the other elements.

    As for the browser thing, I don't see it happening where they are going to properly stop with XHTML syntax errors. If one browser doesn't do it, then they are all going to implement "guessing", because like that quote says: if a site breaks in a browser, people blame the browser, not the site or developer. So, if just one of them doesn't do it, none of them will or they will "lose".

  24. #49
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Not so fast, or I might believe you're always talking "lists"?

    "I talked with Amy, Brad, Cindy and Joe to team with us at paintball"

    vs

    "I talked with:

    o Amy
    o Brad
    o Cindy
    o Joe

    to team with us at paintball".

    Yeah, yeah, punctuation. Only the content in nav is self described, much like elements in a phrase: subject, predicate, adjective. And since I don't wrap spans around every word and punctuation in p, I don't wrap every anchor in nav in li. If a few anchors is all I have in nav.

    And I was making the same argument: what's wrong with being verbose?

    No

    <nav>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>

    but

    <nav>
    <h1>Welcome</h1>
    <p>Thank you for embarking on a journey around my website.</p>
    <p>Here are the places I recommend you to visit: </p>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>.


    And my whole point was, what's wrong with being less verbose? Nothing, also.

    No

    <nav>Here you'll find <a href="#">pictures</a> and <a href="#">cookies.</a></nav>

    but

    <nav>
    <a href="#">Pictures</a>
    <a href="#">Cookies</a>
    </nav>.

    Links alone, by definition. No redundant elements. And no lists to force a false sense of semantics and since it's not always about lists. Lists have their place less often then commodity dictates. And I mean here menus also.

  25. #50
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    If that sentence contained elements, I would put it in a list. However, that's a sentence. It's one paragraph, not a collection of elements (in the semantics of HTML).

    You mention a phrase. All phrases are different. You have to analyze the phrase to determine what the various parts are. Same with HTML. You must analyze (and tell) the browser what each element is, because it can't figure it out itself.

    Also, you contradict yourself. You say a nav by definition means it's filled with links... but your other nav example has lots of content. A list of links needs to be marked up as a list. It's simple.

    There is nothing with being verbose, but your example of being verbose:
    Code:
    <nav>
    <h1>Welcome</h1>
    <p>Thank you for embarking on a journey around my website.</p>
    <p>Here are the places I recommend you to visit: </p>
    <ul>
    <li><a href="#">My Profile</a></li>
    <li><a href="#">Settings</a></li>
    <li><a href="#">Log Out</a></li>
    </ul>
    </nav>
    is being verbose with the user. That's completely different from being verbose with HTML.

    I don't know what you mean by "links alone, by defintion". Nothing is defining that.

    As DS said, that'd be interpreted as "Pictures Cookies". The links aren't redundant.

    Take this for example: screen readers.

    If you just have your links like:
    Code:
    <nav>
    <a href="#">Pictures</a>
    <a href="#">Cookies</a>
    </nav>
    it's going to say "Pictures Cookies". Huh?

    If you have a list, it'll know to take a break in between each ones so it'll say "Pictures. Cookies."


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
  •