Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 8/2/11, Ian Hickson i...@hixie.ch wrote: Unfortunately, as I said above... what we want and what we get don't always match. There's not much we can do here to push authors further. On the other hand, why accommodate the desires of authors? Why let authors decide whether I use gold on black or black on white? But I guess my concern is mainly an implementation issue at this point, as authors have assumed complete control over the rendering of their documents.
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On Wed, 4 May 2011, Bjartur Thorlacius wrote: On 5/4/11, Ian Hickson i...@hixie.ch wrote: IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) On a more serious note, implementing link can't be that hard. It's not a matter of it being hard. Some browsers have even implemented it and then dropped support. I'll probably patch my UA myself when I get the graphics layer working on my system (or just use links2). But I'm slowly coming to the conclusion that a should be used for creating hyperlinks that seem to belong to head, in a tree of htmlbodyasidea, for compatibility with mainstream UAs. That seems fine to me. My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... Sadly, the things authors desire may conflict with the things users desire. I also desire control over navigation links (among many other things). From authors, I desire only content. Unfortunately, as I said above... what we want and what we get don't always match. There's not much we can do here to push authors further. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. 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, without a nav element. Minor inconsistency, but felt it was worth pointing out to avoid confusion. On Fri, 14 Jan 2011, Ian Hickson wrote: It doesn't say it's inappropriate, [just] that it's not necessary. It's still fine to use it there. I'll try to clarify that. I've updated the advice in the nav section accordingly, and made the advice explicitly non-normative. On Tue, 25 Jan 2011, Bjartur Thorlacius wrote: On 1/24/11, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Jan 2011, Bjartur Thorlacius wrote: But then, when should hyperlinks be created with links? More or less never. link links don't show on most Web browsers. IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) Navigation links are clearly metadata, belonging to head. How do you distinguish what is data vs what is metadata? Generally, I categorize everything which isn't mentioned in the title or Content-Description (or would be, as there's usually none). No document would be described as My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 5/4/11, Ian Hickson i...@hixie.ch wrote: IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) I'll be a dick and quote your sig: Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' On a more serious note, implementing link can't be that hard. I'll probably patch my UA myself when I get the graphics layer working on my system (or just use links2). But I'm slowly coming to the conclusion that a should be used for creating hyperlinks that seem to belong to head, in a tree of htmlbodyasidea, for compatibility with mainstream UAs. My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... Sadly, the things authors desire may conflict with the things users desire. I also desire control over navigation links (among many other things). From authors, I desire only content. Bjartur Thorlacius yet another End-User(tm)
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 1/24/11, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Jan 2011, Bjartur Thorlacius wrote: But then, when should hyperlinks be created with links? More or less never. link links don't show on most Web browsers. IMO browsers should implement link. link should be implementable cross-browser in CSS. And what happened to @rel=related being the default relation? Not sure to what you are referring. Sorry, my memory failed me. There is no default relation in HTML 4. Navigation links are clearly metadata, belonging to head. How do you distinguish what is data vs what is metadata? Generally, I categorize everything which isn't mentioned in the title or Content-Description (or would be, as there's usually none). No document would be described as My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. For the record links and links2 render all hyperlinks (including ones with unrecognized values of @rel). Noted.
[whatwg] Small consistency issue with HTML5 nav element examples
In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. 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, without a nav element. Minor inconsistency, but felt it was worth pointing out to avoid confusion. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to.
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. 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, without a nav element. It doesn't say it's inappropriate, such that it's not necessary. It's still fine to use it there. I'll try to clarify that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
Ah, I misinterpreted. With this in mind, I'm a bit unclear as to when nav should be used. If it's intended for primary navigation but secondary navigation can also be marked up with it, does that mean it's best to use nav whenever you have more than one link grouped together? Thanks. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Friday, January 14, 2011 3:58 PM To: Nicholas Zakas Cc: wha...@whatwg.org Subject: Re: [whatwg] Small consistency issue with HTML5 nav element examples On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. 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, without a nav element. It doesn't say it's inappropriate, such that it's not necessary. It's still fine to use it there. I'll try to clarify that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
