Re: [whatwg] href on any element
On Mon, 04 Sep 2006 19:37:30 +0200, Keryx webb [EMAIL PROTECTED] wrote:
To make the whole LI-element clickable I have to resort to CSS
( ul#nav li a { display: block } ) which does not work in all browsers
or JavaScript, which also is a hassle.
Yeah, li href=test/li does work in all browsers obviously. Seems
like a good reason to put it in HTML5!
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] href on any element
Keryx webb wrote: Will it break backwards compatibility? Yes, if todays browsers are supposed to be able to render WHATWG-pages. But there are lots of other things in WHATWG that they do not understand either. It's only the very latest browsers that can handle canvas. No browser fully implements Web Forms 2.0 (as far as I know). But there is usually some way to use other HTML5/WF2 features without breaking current browsers. The only way I can see to do this with href on many elements is to manually walk the DOM inserting a href=bar / elements as children of the foo href=bar / elements, with some care needed for elements such as tr that really won't take a as a child. Authors doing this would also have to be very careful about not breaking their CSS rules etc. in current browsers. href on multiple elements is a nice idea but I'm not sure the benefits outweigh the costs.
Re: [whatwg] href on any element
Sorry for starting a thread and then being away for quite a while. I've been
exceptionally busy!
Let's clarify some of my wishes:
Do I wish that the href-attribute is available on exactly *every* element? No,
but on many *more* than today.
A. I do find myself writing a lot of:
abbr title=foobara href=foobar/a/abbr
dfna href=foobar/a/dfn
ema href=foobar/a/em
B. I also find myself writing large amounts of:
ul
lia href=page1Menuitem 1/a/li
lia href=page2Menuitem 2/a/li
/ul
To make the whole LI-element clickable I have to resort to CSS
( ul#nav li a { display: block } ) which does not work in all browsers or
JavaScript, which also is a hassle.
Why would it be better to loose the a-tags?
- Code-reduction is always a good thing! (The XLink solution means a lot of
code = no reduction.)
- Convenience for hand-coders, whose work often make it into CMS-templates.
Will it break backwards compatibility? Yes, if todays browsers are supposed to
be able to render WHATWG-pages. But there are lots of other things in WHATWG
that they do not understand either. It's only the very latest browsers that can
handle canvas. No browser fully implements Web Forms 2.0 (as far as I know).
Please point me to a document if I've got this wrong - I am after all a newbie
on this list - but adding href on more elements is not *changing* todays HTML,
but *adding* to it. Isn't that what HTML 5 is all about.
And how much it may be disliked by browser vendors, I still think they do intend
to support XHTML 2.0, and need to prepare for a day when href is available on
*most* elements, anyway.
Actually, if one dislikes XHTML 2.0, implementing its one killer feature in
HTML 5 would make sense as well. Who would want to use XHTML 2.0 if it does not
offer any significant advantage?
As Molly H writes:
All I really, really want from XHTML 2.0 is href to be available for any
element. (I'd like to change that to many more elements than today)
http://www.molly.com/2006/08/14/angry-not-zeldman-meyer-and-fair-concerns-about-the-w3c/
Lars Gunther
Re: [whatwg] href on any element
Kornel Lesinski wrote:
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
This can be accomplished by having a elements in each individual
cell...
Of course it can, but it bloats code a lot. You have to add several
redundant links, add tabindex=-1 to avoid breaking keyboard navigation,
move all table and cell styles to anchors, and if cells contain block
elements you have to bloat your code even more.
It didn't occur to me until recently, but the behavior you originally
described isn't desirable from an interface design standpoint. How is a
person supposed to highlight and copy specific information within an
given cell in the row? Furthermore, if two cells next to each other have
the same hyperlink, but the row has a different hyperlink, it's not
entirely clear what happens if you click the space between the two
cells. With hyperlinks for each cell, or even each block, the worst that
happens is that the hyperlink doesn't get clicked, whereas with a
potential |href| attribute would have to handle nested hyperlinks and
multi-block hyperlinks that imply a grouping of elements without
necessarily encouraging a parent element with the semantics necessary to
identify the nature of that grouping.
That said, I'd also like to point out that most of your arguments for
|href| fall into the category of convenience rather than necessity.
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
People don't typically don't initiate a purchase in a user interface
by clicking on the product description.
Make it href=/info then. Sometimes it doesn't make sense to have
separate page for each listed detail.
The fundamental problems with the UI design don't really go away when
you change the purpose of the hyperlink. You still have the problem that
people don't necessarily expect that clicking anywhere on an entire
list, or even the opening paragraph, would lead to another page. It also
has issues with interacting the individual elements of the list, just
like you would with cells in a row.
Of course you can live without href on every element if you apply a bit of
scripting and CSS tricks, but the same thing can be said about almost
every thing in WHATWG specifications.
The difference here is that the potential for poor interface design
goes up significantly. In fact, |href| could be used as a means of
preventing the user from interacting with an element and its descendants.
It can have some backwards-compatibility. AFAIK XHTML/2 allows nested
anchors, so I'd use it like this:
tr href=..tda href=..anchor/a/tdtdno anchor/tdtdno
anchor/tdtdno anchor/td/tr
Problem is that you essentially have to do all the stuff you
complained about earlier to get full backwards compatibility...
With some scripting (see first code in this post) this could work in
current browsers and had fallback for bots and non-JS agents.
With some scripting, you could just use the scripting trick you
showed in an earlier example, so what's the point? Just use that little
bit of scripting:
| tr onclick=this.getElementsByTagName('a')[0].click()
Re: [whatwg] href on any element
Andrew Fedoniouk wrote: Ian Hickson wrote: a href= h2.../h2 p.../p /a If we will change model of A from !ELEMENT A - - (%inline;)* -(A) -- anchor -- to something else then it will create implications for parser. What implications? Changing the formal content model of an element doesn't change the way a parser needs to work. Ian's example above is very similar to some real world examples I've seen and browser's already handle it just fine. The DOM looks like this: A +-H2 + P -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
- Original Message - From: Lachlan Hunt [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED] Cc: Ian Hickson [EMAIL PROTECTED]; Anne van Kesteren [EMAIL PROTECTED]; WHATWG [EMAIL PROTECTED] Sent: Monday, August 28, 2006 11:05 PM Subject: Re: [whatwg] href on any element Andrew Fedoniouk wrote: Ian Hickson wrote: a href= h2.../h2 p.../p /a If we will change model of A from !ELEMENT A - - (%inline;)* -(A) -- anchor -- to something else then it will create implications for parser. What implications? Changing the formal content model of an element doesn't change the way a parser needs to work. Ian's example above is very similar to some real world examples I've seen and browser's already handle it just fine. These are non-conformant browsers :) A simply cannot have content other than inline constructions. What UA should do in this case is not specified. Using this is as bad as violation of following: The P element represents a paragraph. It cannot contain block-level elements (including P itself). We all can see that browsers that just ignore this rule. And where are we now? The DOM looks like this: A +-H2 + P And what is semantical meaning of that? Some hyperlinked section? If yes then let it be just : section href=... h2... p... /section Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] href on any element
Andrew Fedoniouk wrote: Lachlan Hunt wrote: Andrew Fedoniouk wrote: Ian Hickson wrote: a href= h2.../h2 p.../p /a If we will change model of A from !ELEMENT A - - (%inline;)* -(A) -- anchor -- to something else then it will create implications for parser. What implications? Changing the formal content model of an element doesn't change the way a parser needs to work. Ian's example above is very similar to some real world examples I've seen and browser's already handle it just fine. These are non-conformant browsers :) No, in this case, they're just handling the non-conformant content in the most sane way, which I believe (in this case) is correct handling according to traditional SGML rules. See the Parse Tree produced by the validator for that construct (ignore the 2 expected validation errors): http://validator.w3.org/check?uri=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%253C%21DOCTYPE%2520a%2520PUBLIC%2520%2522-%252F%252FW3C%252F%252FDTD%2520HTML%25204.01%252F%252FEN%2522%253E%250D%250A%253Ca%2520href%253D%2522%2523%2522%253E%250D%250A%2520%2520%253Ch2%253E...%253C%252Fh2%253E%250D%250A%2520%2520%253Cp%253E...%253C%252Fp%253E%250D%250A%253C%252Fa%253E%2520charset=%28detect+automatically%29doctype=Inlinesp=1 A simply cannot have content other than inline constructions. According to the formal content model, yes, but when a browser encounters a real world document has that construct, what do you think the browser should do with it? What UA should do in this case is not specified. Using this is as bad as violation of following: See section 8 of the Web Apps 1.0 spec. http://www.whatwg.org/specs/web-apps/current-work/#parsing The DOM looks like this: A +-H2 + P And what is semantical meaning of that? Some hyperlinked section? The A element is just defined as a hyperlink. Whether or not it's a section is irrelevant. If yes then let it be just : section href=... h2... p... /section But that isn't backwards compatible. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Ian Hickson wrote: On Mon, 28 Aug 2006, Anne van Kesteren wrote: On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ...or the currently non-conforming: a href= h2.../h2 p.../p /a We could make it conforming, I guess. The parser already supports it to some extent. I've run up against this before, the only way you can get it to conform is by repeating the anchor: h2a href=... title=... rel=etc.Foo/a/h2 pa href=... title=... rel=etc.Bar/a/p or by the previous, non semantic use of spans. All that is required is to allow the anchor to be used around block level elements. The anchor could be treated as a non element, where any plain text within is by default treated as inline. after all it's fine to surround some inline-replaced elements such as images with A but not others, such as inputs (though why anyone would want to do the latter is open to debate.) this could also lead to clearer use of named anchors too, if they were allowed to 1. surround the entire region they refer to 2. nest a name=appendix_1 h2Appendix 1/h2 h3References/h3 a name=ref_1p1. cite.../cite em.../em/p/a a name=ref_2p.../p/a /a Question is, is this backwards compatible? do existing UAs treat this as a series of a/a tag pairs or does the nesting break it? If a named-anchor surrounded it's region it would also allow screen readers (for example) to very easily jump to a footnote and read it without having to guess where to stop and return to the main text. Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] href on any element
Lachlan Hunt wrote: Andrew Fedoniouk wrote: If yes then let it be just : section href=... h2... p... /section But that isn't backwards compatible. data:text/html,tabletra hef=www.google.comtdlink to google/td/atdplain text/td/tr/table Neither is a around table cells or list items. Personally, I like the semantics of href on any element. This element is a link seems cleaner than Here is a link element that surrounds some other element or text content. Assuming no one does find a backwards-compatible way to link any element, I'd prefer going forwards with href applying to everything. (Note that I haven't thought about it much, though, and I do have a vague hazy memory of not liking something about the way XHTML 2 is doing it. I would definitely want more thought put into it than I have.) -- dolphinling http://dolphinling.net/
Re: [whatwg] href on any element
What practical use has this for Mr Joe Public? Give me a really useful example in very simple wording! Francisco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dolphinling Sent: 29 August 2006 16:46 To: WHAT WG List Subject: Re: [whatwg] href on any element Lachlan Hunt wrote: Andrew Fedoniouk wrote: If yes then let it be just : section href=... h2... p... /section But that isn't backwards compatible. data:text/html,tabletra hef=www.google.comtdlink to google/td/atdplain text/td/tr/table Neither is a around table cells or list items. Personally, I like the semantics of href on any element. This element is a link seems cleaner than Here is a link element that surrounds some other element or text content. Assuming no one does find a backwards-compatible way to link any element, I'd prefer going forwards with href applying to everything. (Note that I haven't thought about it much, though, and I do have a vague hazy memory of not liking something about the way XHTML 2 is doing it. I would definitely want more thought put into it than I have.) -- dolphinling http://dolphinling.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] href on any element
On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro
[EMAIL PROTECTED] wrote:
What practical use has this for Mr Joe Public?
Give me a really useful example in very simple wording!
Having data table representing list of items where large clickable area is
useful - i.e. inbox in a webmail, list of contacts, forum threads listing,
etc.
I've ran into this problem many times and seen many questions about this
on forums/usenet.
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
--
regards, Kornel Lesiński
Re: [whatwg] href on any element
Kornel Lesinski wrote:
On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro
Having data table representing list of items where large clickable area is
useful - i.e. inbox in a webmail, list of contacts, forum threads listing,
etc.
I've ran into this problem many times and seen many questions about this
on forums/usenet.
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
This can be accomplished by having a elements in each individual
cell...
| tr
| tda href=[...]Content for Cell 1/a/td
| tda href=[...]Content for Cell 2/a/td
| tda href=[...]Content for Cell 3/a/td
| /tr
...where you just style the a element to be a block that takes up
the entire cell. It's not as convenient for hand-coded pages, but I
don't see a lot of use cases where you would need this for hand-coded
pages anyways.
Now, it does make cell borders and padding a bit sticky, which is
something to consider, but that can be largely circumvented by some
clever styling. Furthermore, it represents only a small amount of the
click area that's unlikely to be clicked in the first place.
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
People don't typically don't initiate a purchase in a user interface
by clicking on the product description. For instance, they may simply be
clicking on the individual list items as they're reading them. (In fact,
this was an argument used against supporting label focus passing for all
types of input elements.) Simply put, what you're suggesting above is
bad UI design.
Re: [whatwg] href on any element
On Tue, 29 Aug 2006 22:55:01 +0100, Matthew Raymond
[EMAIL PROTECTED] wrote:
Having data table representing list of items where large clickable area
is useful - i.e. inbox in a webmail, list of contacts, forum threads
listing, etc.
I've ran into this problem many times and seen many questions about this
on forums/usenet.
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
This can be accomplished by having a elements in each individual
cell...
Ofcourse it can, but it bloats code a lot. You have to add several
redundant links, add tabindex=-1 to avoid breaking keyboard navigation,
move all table and cell styles to anchors, and if cells contain block
elements you have to bloat your code even more.
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
People don't typically don't initiate a purchase in a user interface
by clicking on the product description.
Make it href=/info then. Sometimes it doesn't make sense to have
separate page for each listed detail.
Ofcourse you can live without href on every element if you apply a bit of
scripting and CSS tricks, but the same thing can be said about almost
every thing in WHATWG specifications.
It can have some backwards-compatibility. AFAIK XHTML/2 allows nested
anchors, so I'd use it like this:
tr href=..tda href=..anchor/a/tdtdno anchor/tdtdno
anchor/tdtdno anchor/td/tr
With some scripting (see first code in this post) this could work in
current browsers and had fallback for bots and non-JS agents.
--
regards, Kornel Lesiński
Re: [whatwg] href on any element
On Sat, 26 Aug 2006, Keryx webb wrote: Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? It's been mentioned, mostly in passing. The biggest problem with this feature is that some UA vendors have indicated that they are strongly opposed to overloading every element as being a link. It isn't always clear what it would mean, either (consider col href=, or optgroup href=). Generally, overloading a single element to do multiple tasks leads to bugs. Consider, for instance, object, which has been overloaded to do a wide variety of different things (plugins, images, subdocuments, etc). It is one of the most poorly implemented parts of HTML4. Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. Turning a href=http://www.whatwg.org/;abbr title=Web Hypertext Application Technology Working GroupWHATWG/abbr/a into abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. It's arguably a very minor improvement, but probably not worth the huge specification and implementation cost. Certainly there are bigger bang for the buck improvements that can be made. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] href on any element
Keryx webb wrote: Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. What are the perceived benefits that make it such a killer feature? abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. Theoretically, for XHTML, you could use XLink and write this (assuming the appropriate namespace is declared) abbr xl:type=simple xl:href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr But my tests with Firefox showed that, even though it supports simple XLink links for generic XML, that doesn't work for XHTML elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Ian Hickson wrote: It isn't always clear what it would mean, either (consider col href=, or optgroup href=). If the feature were to be added to Web Apps 2.0 (or other future spec) I think it would be sensible to limit it to inline, non-interactive, non-empty elements (e.g. abbr, em, strong, etc.) and a few other selected elements (e.g. li and td). It should not apply to elements like col, br, hr, input, select, etc. It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] href on any element
On Mon, 28 Aug 2006, Anne van Kesteren wrote: On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ...or the currently non-conforming: a href= h2.../h2 p.../p /a We could make it conforming, I guess. The parser already supports it to some extent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] href on any element
Hi all Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. Turning a href=http://www.whatwg.org/;abbr title=Web Hypertext Application Technology Working GroupWHATWG/abbr/a into abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. 1. (Repeat) if this has already been discussed, please give me a relevant link. 2. If not, correct the errors of my way, if there actually is some good arguments against this being part of WHATWG as well as XHTML 2.0 Lars Gunther
Re: [whatwg] href on any element
Hi, From: Keryx webb [EMAIL PROTECTED] Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-January/005410.html Regards, Simon Pieters
