Re: [whatwg] Proposal for a link attribute to replace a href
Simon Pieters wrote: On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? Also it would quite likely clash with existing content that expects that those attributes don't exist on e.g. divs. (Opera has had problems with some new DOM attributes in WF2 due to legacy.) One idea is to enable all elements to cross-reference to hyperlink (a or link) elements. This could be achieved with a link attribute that contains the ID of the hyperlink element. The behavior of elements with @link would be UA defined, but could be: onclick: follow the hyperlink on the referenced a or link elemenr oncontextmenu: offer menu options to a) scrollTo the hyperlink element or b) follow the hyperlink. If the link attribute is present but empty then it could be assumed to reference getElementsByTagName(a)[0]. Pros: - don't need to add properties of hyperlink elements to other elements - Javascript implementations for older browsers would be trivial - the link attribute can be used as a styling hook - multiple elements can use the one hyperlink Cons: - won't inherit :visited styles
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. Which implementations have you heard this from? As far as mozilla goes we would have no technical problems implementing this. The problems that I can see are of a more 'social' type. I.e. how to behave when two links are nested, or when a button is nested inside a link. Or how the event model interacts with the navigation action. All these problems exist already, but might become more common if it was easier to sprinkle 'href' attributes throughout the DOM. / Jonas
Re: [whatwg] Proposal for a link attribute to replace a href
Jonas Sicking wrote: Ian Hickson wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. Which implementations have you heard this from? As far as mozilla goes we would have no technical problems implementing this. The problems that I can see are of a more 'social' type. I.e. how to behave when two links are nested, or when a button is nested inside a link. Or how the event model interacts with the navigation action. All these problems exist already, but might become more common if it was easier to sprinkle 'href' attributes throughout the DOM. Actually, I think I spoke a bit too broadly. Just adding support for the 'href' content attribute, and the ability to click and style those elements just like you can an a today should be easy, at least in gecko. This is modulo the issue of what happens with the elements that already have a 'href' attribute with a different meaning (i.e. other than making the element into a clickable link), such as base and link However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? However these are problems that can be solved on a spec level IMHO. / Jonas
Re: [whatwg] Proposal for a link attribute to replace a href
On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? Also it would quite likely clash with existing content that expects that those attributes don't exist on e.g. divs. (Opera has had problems with some new DOM attributes in WF2 due to legacy.) -- Simon Pieters Opera Software
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson wrote: On Wed, 30 Jul 2008, Simon Pieters wrote: There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. Ok. Fair enough. I have allowed a elements to surround other (non-interactive) elements. On Wed, 30 Jul 2008, James Graham wrote: I think tableatr also causes problems; being able to link whole table rows seems like one of the major use cases for this proposal. Yes. I don't see how to fix that one. Given that I'm not sure making a transparent is wise. It seems like authors will try to use this feature, get tripped up by the table voodoo and become confused about why it doesn't work for what seems to be one of the most desirable use cases. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Proposal for a link attribute to replace a href
Every now and then, the issue of a global href= attribute for all
elements comes up. There are many valid use cases for this, like being
able to make all cells in a table row act like a link, or making a banner
ad act like a single block of a link.
Unfortunately, I've been told over and over by implementers that a global
href= is a bad idea, and at the end of the day, the implementors are the
ones who have the final say, so that's just a non-starter.
There are also alternative suggestions, like making a contain any
element. Unfortunately, none of these end up working (e.g. for this
proposal, ap/a would create an unexpected DOM -- we'd have to make
/p end tags not optional when the next end tag was an /a, which would
be somewhat confusing).
So I apologise again for rejecting these proposals, and hope that it
doesn't discourage you from contributing further to other aspects of
HTML5.
I haven't included all the feedback on this topic that I received, but
here is a sampling with some responses:
On Wed, 28 May 2008, Martin Atkins wrote:
I agree that this is an unconvincing example, but consider instead
banner ads that are created from a bunch of HTML markup rather than a
single image; they generally want the entire banner rectangle to be
clickable but make use of tables and all sorts of other strange
things.
Just do:
div class=ad onclick=this.getElementsByTagName('a')[0].click()
...a href=...Buy viagra!/a...
/div
(Note that .click() is new in HTML5.)
On Thu, 29 May 2008, Frank Hellenkamp wrote:
But I step over different kinds of teaser (news- and article-teasers)
during my work, that are made out of images, text and headlines.
Now, you have to do this (without javascript):
div class=teaser
a href=link.htmlimg src=image.png/a
h3a href=link.htmlnewsteaser/a/h3
pa href=link.htmlText/a/p
pa href=link.htmlText/a/p
/div
If you are good, you also set the a-elements to display: block so that
the whole area is clickable, not only the text.
It would be *much* more simple/useful to have something like this:
div class=teaser href=link.html
img src=image.png
h3newsteaser/h3
pText/p
pText/p
/div
Or this:
a href=link.html
div class=teaser
img src=image.png
h3newsteaser/h3
pText/p
pText/p
/div
/a
You could just do:
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
h3a href=link.htmlNews Teaser/a/h3
figure
img src=image.png alt=...
legend.../legend
/figure
pText/p
pText/p
/article
...or some such (article and figure are new in HTML5).
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
On Sat, 31 May 2008, Shannon wrote:
http://www.duttondirect.com/automotive/for_sale
The table hover effect is not easily acheived without global href. My
client likes it, the users like it and it is perfectly obvious
navigation (despite being non-standard). At the moment I am acheiving
the effect with event bubbling but I consider this approach to be
bloated, ineligant, prone to breakage and lag on slower devices. It also
suffers from the poor compatibility of the event.button property
(activates on right/middle-click instead of just left). Nonetheless it
improves the ease of navigation for most users.
A global href would allow me too turn the whole mess of event code into:
tr href=foo.html ... /tr
... and all the issues I just mentioned would vanish.
Sure. What's wrong with doing this, though?:
tr onclick=location = this.querySelector(:link,:visited).../tr
(querySelector() is new in the Selectors API spec.)
Is global href a burden on browser vendors?
Unlikely. It's behaviour is nearly identical to onclick=window.location=foo
which is already supported on the majority of modern browsers except Lynx.
We don't get to decide if it's a burden or not, they do.
On Fri, 30 May 2008, Ernest Cline wrote:
What about adding a third non-metadata hyperlink element, say anchor,
which would be a flow content element with flow content allowed in it?
This would seem to cover the use cases presented, while preserving a
as being phrasing content only. The only issue I see if this were
added, is whether it would be better to have the ismap attribute of
img only work with a or to have it work with the new element as
well.
We already have three elements that do linking in HTML5, adding a fourth
seems like a lot.
On Sat, 31 May 2008, Anne van Kesteren wrote:
The a element can already do this and it would be backwards
compatible.
As far as I can tell this breaks down for ap.../a.
On Sun, 1
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008 13:50:18 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. -- Simon Pieters Opera Software
Re: [whatwg] Proposal for a link attribute to replace a href
Simon Pieters wrote: On Wed, 30 Jul 2008 13:50:18 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. I think tableatr also causes problems; being able to link whole table rows seems like one of the major use cases for this proposal. Would the implementor feedback that global href is a bad idea still apply if instead of global it was large set of elements where the large set would explicitly not include things like form elements? -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008 15:29:47 +0200, James Graham [EMAIL PROTECTED] wrote: I think tableatr also causes problems; Indeed. being able to link whole table rows seems like one of the major use cases for this proposal. I don't know how to do that short of using script. Perhaps HTMLElement should have a links collection to make it simpler to write the script? tr onclick=links[0].click() Would the implementor feedback that global href is a bad idea still apply if instead of global it was large set of elements where the large set would explicitly not include things like form elements? Allowing href in more places is potentially a security problem since suddenly you could run scripts from things that blacklist-based sanitizers don't filter out. -- Simon Pieters Opera Software
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson writes:
... global href= attribute for all elements ... Unfortunately, I've
been told over and over by implementers that a global href= is a bad
idea
Noted.
However:
div class=ad
onclick=this.getElementsByTagName('a')[0].click()
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
It may be, given implementers' requirements, that JavaScript solutions
like the above are the best we can do. But let's not pretend they are
as good as links that don't involve scripting.
Smylers
Re: [whatwg] Proposal for a link attribute to replace a href
What about an alternative attribute like navigate instead of href. It
would not carry the full weight of the anchor tag, but would handle the 90%
use case. It would not allow for the same options as the a tag, and the a
tag would continue to work the same way that it has been.
On Wed, Jul 30, 2008 at 10:45 AM, Smylers [EMAIL PROTECTED] wrote:
Ian Hickson writes:
... global href= attribute for all elements ... Unfortunately, I've
been told over and over by implementers that a global href= is a bad
idea
Noted.
However:
div class=ad
onclick=this.getElementsByTagName('a')[0].click()
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
It may be, given implementers' requirements, that JavaScript solutions
like the above are the best we can do. But let's not pretend they are
as good as links that don't involve scripting.
Smylers
Re: [whatwg] Proposal for a link attribute to replace a href
By the current spec, the Anchor element is phrasing content, which is a special case of flow content. Did you mean transparent content instead? EC! I cannot see any inline content in HTML5, at least not in 3.4.1 where content models are defined. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 1:50 PM Cc: WhatWG Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sun, 1 Jun 2008, Ernest Cline wrote: Backwards compatible with some user agents but not with the specs. The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite a, h3, and p appearing in all of them. a href=foo.html h3Heading/h3 pText/p /a The specs have always called for a to only have inline content save that for some reason, HTML 2.0 did allow h1 to h6 inside a though that was not recommended, and that was reverted back to inline only in 3.2. While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.) Changing the specs to match user agent behavior is the whole way HTML5 works, so that's not a big problem. The problem is that the current parse model results in odd behaviour if we allow a as a flow-content element.
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008, Simon Pieters wrote:
There are also alternative suggestions, like making a contain any
element. Unfortunately, none of these end up working (e.g. for this
proposal, ap/a would create an unexpected DOM -- we'd have to
make /p end tags not optional when the next end tag was an /a,
which would be somewhat confusing).
The rules for optional end tags are already pretty confusing. I don't
think it's a problem to require /p when the p element is the last
child of an a element.
Ok. Fair enough. I have allowed a elements to surround other
(non-interactive) elements.
On Wed, 30 Jul 2008, James Graham wrote:
I think tableatr also causes problems; being able to link whole
table rows seems like one of the major use cases for this proposal.
Yes. I don't see how to fix that one.
Would the implementor feedback that global href is a bad idea still
apply if instead of global it was large set of elements where the
large set would explicitly not include things like form elements?
Yeah -- the problem isn't so much the number of elements, as the
complexity of doing a link. Resolving URLs, making it match
:link/:visited, handling clicks, handling base URLs, hover effects with
status information, etc. Links are hard.
On Wed, 30 Jul 2008, Simon Pieters wrote:
Perhaps HTMLElement should have a links collection to make it simpler to
write the script?
tr onclick=links[0].click()
I don't know that that is all that much better than
getElementsByTagName('a')[0], or even:
tr onclick=link(event) ... /tr
script
function link(e) {
var a = e.currentTarget.getElementsByTagName('a')[0];
if (e.target != a)
a.click();
}
/script
On Wed, 30 Jul 2008, Smylers wrote:
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
Sure, but that's ok, because the link is still visible and present as a
link in this case -- it's just that the user can click anywhere to
activate it instead of only on the text. I don't think that's a
particularly horrible user experience, I think it's fine. No?
On Wed, 30 Jul 2008, Russell Leggett wrote:
What about an alternative attribute like navigate instead of href. It
would not carry the full weight of the anchor tag, but would handle the 90%
use case. It would not allow for the same options as the a tag, and the a
tag would continue to work the same way that it has been.
The difficulties are in the basic linking ability, not the more esoteric
features, sadly.
On Wed, 30 Jul 2008, Kristof Zelechovski wrote:
By the current spec, the Anchor element is phrasing content, which is a
special case of flow content. Did you mean transparent content instead?
EC! I cannot see any inline content in HTML5, at least not in 3.4.1 where
content models are defined.
HTML5 has no inline or block concept, indeed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a link attribute to replace a href
On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: Jun 2, 2008 5:39 AM On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. That might be a reason to adjust the spec for a to have it match current behavior, but in my opinion it would be better to provide for the block/inline distinction to be handled with recourse to CSS by having separate elements as is the case for div/span. There are alternatives to obtain this behavior in old browsers without using a in a block context, so the loss of backward compatibility would be a minor issue at most. That said, adjusting the spec to have a follow current behavior would be better than leaving the spec as it is and not have any spec compliant method to provide a block level hyperlink without the use of scripting.
Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 31, 2008 5:02 AM To: Ernest Cline [EMAIL PROTECTED], WhatWG [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline [EMAIL PROTECTED] wrote: What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well. The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite a, h3, and p appearing in all of them. a href=foo.html h3Heading/h3 pText/p /a The specs have always called for a to only have inline content save that for some reason, HTML 2.0 did allow h1 to h6 inside a though that was not recommended, and that was reverted back to inline only in 3.2. While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.)
Re: [whatwg] Proposal for a link attribute to replace a href
On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline [EMAIL PROTECTED] wrote: What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well. The a element can already do this and it would be backwards compatible. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
There's a lot of focus on use cases. Here is the one that led me to start this thread: http://www.duttondirect.com/automotive/for_sale (disclaimer: I am not responsible for the design of this page) The table hover effect is not easily acheived without global href. My client likes it, the users like it and it is perfectly obvious navigation (despite being non-standard). At the moment I am acheiving the effect with event bubbling but I consider this approach to be bloated, ineligant, prone to breakage and lag on slower devices. It also suffers from the poor compatibility of the event.button property (activates on right/middle-click instead of just left). Nonetheless it improves the ease of navigation for most users. A global href would allow me too turn the whole mess of event code into: tr href=foo.html ... /tr ... and all the issues I just mentioned would vanish. People on this list should be very careful about claiming properties and tags will be abused. Bad interfaces exist already and often as a result of missing behaviours in the standard. Wrapping tables and block content in a/a is just one example (it works, believe it or not). Trying to force designers into better layouts by denying features is stupid. It will simply drive them into invalid layouts, Javascript, Flash or Silverlight where they are free to make even bigger mockeries of standards and interface conventions. As far as designers are concerned HTML5 is a *competitor* to these technologies. If you cannot compete in terms of features and ease of use you'll end up with a proprietary web. In summary then: Is global href going to create bad layouts? Depends. Skilled UI designers can improve their layouts - bad designers can make theirs worse. Is global href a burden on browser vendors? Unlikely. It's behaviour is nearly identical to onclick=window.location=foo which is already supported on the majority of modern browsers except Lynx. Is denying designers features they want going to increase standards compliance? No. It will reduce compliance. Regards, Shannon
Re: [whatwg] Proposal for a link attribute to replace a href
Realistically, are people ever going to stop using a href= in the next twenty years? Even if it's marked deprecated? - d.
Re: [whatwg] Proposal for a link attribute to replace a href
On Fri, May 30, 2008 at 12:45 PM, Shannon [EMAIL PROTECTED] wrote:
There's a lot of focus on use cases. Here is the one that led me to start
this thread:
http://www.duttondirect.com/automotive/for_sale (disclaimer: I am not
responsible for the design of this page)
The table hover effect is not easily acheived without global href. My
client likes it, the users like it and it is perfectly obvious navigation
(despite being non-standard). At the moment I am acheiving the effect with
event bubbling but I consider this approach to be bloated, ineligant, prone
to breakage and lag on slower devices. It also suffers from the poor
compatibility of the event.button property (activates on right/middle-click
instead of just left). Nonetheless it improves the ease of navigation for
most users.
This is a good point - that style of navigation is indeed very easy and
intuitive for people to use. You *want* to click on the whole row,
especially with the nice color change on hover; making any particular piece
of the row the 'clickable' portion would actually reduce usability.
A global href would allow me too turn the whole mess of event code into:
tr href=foo.html ... /tr
... and all the issues I just mentioned would vanish.
However, I'm still quite aware of the issues with making href= global, which
have been brought up before (the big thing is that href doesn't work in
isolation - it's got a whole bevy of cousin attributes that would have to
move to global as well).
However, has there ever been a response from browser authors about just
making a allow block-level content within it? The main issue I can think
of with this is default UI - how should it be indicated that a block-level
element is a link? It's pretty well-established that authors generally hate
the border around images within an a (my default stylesheet turns off
image borders just for that reason). However, it at least gives *some*
indication of a link - should we be bordering all the block-level elements
(and underlining all the inline) within an a? It would be an ugly
default, but one that can be removed pretty trivially - a simple a * {
border: none; } rule would remove it and let you style your stuff as you
wish.
As far as I can tell a block-level a is already supported just fine, as
you *can* wrap block-level content in an a and have it work as expected
right now, and CSSing an a into display:block works wonderfully. It
*appears* that only the standard disallows this at the moment - the actual
browsers handle it just fine.
People on this list should be very careful about claiming properties and
tags will be abused. Bad interfaces exist already and often as a result of
missing behaviours in the standard. Wrapping tables and block content in
a/a is just one example (it works, believe it or not). Trying to force
designers into better layouts by denying features is stupid. It will simply
drive them into invalid layouts, Javascript, Flash or Silverlight where they
are free to make even bigger mockeries of standards and interface
conventions. As far as designers are concerned HTML5 is a *competitor* to
these technologies. If you cannot compete in terms of features and ease of
use you'll end up with a proprietary web.
In summary then:
Is global href going to create bad layouts?
Depends. Skilled UI designers can improve their layouts - bad designers can
make theirs worse.
Is global href a burden on browser vendors?
Unlikely. It's behaviour is nearly identical to
onclick=window.location=foo which is already supported on the majority of
modern browsers except Lynx.
Is denying designers features they want going to increase standards
compliance?
No. It will reduce compliance.
Regards,
Shannon
Re: [whatwg] Proposal for a link attribute to replace a href
On Fri, 30 May 2008 17:12:12 +0200, Tab Atkins Jr. [EMAIL PROTECTED] wrote: As far as I can tell a block-level a is already supported just fine, as you *can* wrap block-level content in an a and have it work as expected right now, and CSSing an a into display:block works wonderfully. It *appears* that only the standard disallows this at the moment - the actual browsers handle it just fine. This is probably more a question of whether we should allow this in HTML then whether or not we can allow this in browsers as browsers pretty much have to support this anyway. I personally think we should allow this for cases as demonstrated by this site: http://noorderlicht.vpro.nl/ (Disclaimer: I have worked on that site three years ago.) (I agree that a global href= attribute would not be very feasible given all the other attributes a has.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for a link attribute to replace a href
Having looked at the discussion thus has generated, I have a counterproposal to make. First of all, given that full support for hyperlinks requires support for seven attributes (href, target, ping, rel, media, hreflang, type), I can fully understand web developers not wanting to make it something applicable to any element. On the other hand, web authors have already indicated a desire through how they use a with exist tag soup browsers to have hyperlink support for more than just phrasing content as supported by a and embedded content as supported by area for img and object. What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well.
Re: [whatwg] Proposal for a link attribute to replace a href
I do not know how common the banner link abuse described is; using a table for banner layout is abusive enough to make this an edge case. The immediate remedy would be to transform the source document so as to propagate the anchors downwards, i.e. into each table cell. I am sure the banner server can do that. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, May 28, 2008 10:45 PM Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href Ian Hickson wrote: This proposal would circumvent A's main limitation which is its requirement to not wrap block-level elements or 'interactive' content. The HTML5 draft requires it wrap 'phrasing content' (essentially paragraphs) and not wrap 'interactive' content (such as other hyperlinks) however I see no reason why a link attribute should require these limits. Links would simply cascade as in the following example: table link=alphabet.html title=Alphabetical List tr tdA/td tdB/td td link=c.html title=More about CC/td tdD/td /tr /table [snip] I don't think that making an entire list into a link is really something that is useful from a usability point of view. I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. In the wild, I've seen advertisers do two different, undesirable things: some ignore the rules altogether and just put table inside a, which seems to work with some minor quirks in most browsers, or they just attach an onclick event to the root element and let events bubble up to it, where the event handler just navigates to the target page. It could be argued that the quirks you see when nesting table inside a show that implementing a block-level link element is troublesome, but I also consider that if browsers can successfully handle the bubbling of the click and mouseover event up the DOM tree through block elements they ought to be able to do the hit-testing necessary to support mouse-based navigation of a block-level link element. I'm not necessarily arguing for a global link attribute, but it would be useful if the A element's content model were extended to allow all elements so that there's a markup-only way to easily turn an entire block element into a link. This could also be extended to the LABEL element, which in visual user-agents is often interacted with in a way somewhat like a link.
Re: [whatwg] Proposal for a link attribute to replace a href
I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. I also think, that the banner is not a convincing example. But I step over different kinds of teaser (news- and article-teasers) during my work, that are made out of images, text and headlines. Now, you have to do this (without javascript): div class=teaser a href=link.htmlimg src=image.png/a h3a href=link.htmlnewsteaser/a/h3 pa href=link.htmlText/a/p pa href=link.htmlText/a/p /div If you are good, you also set the a-elements to display: block so that the whole area is clickable, not only the text. It would be *much* more simple/useful to have something like this: div class=teaser href=link.html img src=image.png h3newsteaser/h3 pText/p pText/p /div Or this: a href=link.html div class=teaser img src=image.png h3newsteaser/h3 pText/p pText/p /div /a By the way: It would be more accessible with the mouse in this case, because the clicking-area is much bigger (without css-tricks). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Hellenkamp Sent: Thursday, May 29, 2008 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. I also think, that the banner is not a convincing example. But I step over different kinds of teaser (news- and article-teasers) during my work, that are made out of images, text and headlines. Now, you have to do this (without javascript): div class=teaser a href=link.htmlimg src=image.png/a h3a href=link.htmlnewsteaser/a/h3 pa href=link.htmlText/a/p pa href=link.htmlText/a/p /div If you are good, you also set the a-elements to display: block so that the whole area is clickable, not only the text. It would be *much* more simple/useful to have something like this: div class=teaser href=link.html img src=image.png h3newsteaser/h3 pText/p pText/p /div Or this: a href=link.html div class=teaser img src=image.png h3newsteaser/h3 pText/p pText/p /div /a By the way: It would be more accessible with the mouse in this case, because the clicking-area is much bigger (without css-tricks). best regards frank
Re: [whatwg] Proposal for a link attribute to replace a href
As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris If you don't know the width and height of the element (because the text may have a differnet height for different teaser) you can't put a clic#kable rectangle over it - the content have to be inside to let the element grow with the content. best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris The thing is: You want to have it most intuitive for the user: You have a portal page for a newspaper for example. Every article has a teaser with an image, a headline and text. As a user, I don't want to search for a link text (like more..., which is really bad, or some small key phrase), i just want to click somewhere on the teaser (on the image or the text) to get the article I want to read. As a content producer, I have to honor that. It is good to have big clickable buttons, especially on present and upcoming mobile devices (like the iphone for example). In the best case the whole rectangle of the teaser is clickable. At the moment you need some javascript or an a-tag with display: block for it, to get this behavior (see example in my last mail). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
I agree that a more. link is a loss. However, the heading can serve as the anchor all right. If the whole text is in the anchor, it should be styled as a hyperlink, which would make it hard to read. OTOH, drawing a hyperlink border around the table makes the hyperlink hard to discover. Keep the Web consistent. Chris -Original Message- From: Frank Hellenkamp [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2008 10:59 AM To: Kristof Zelechovski Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris The thing is: You want to have it most intuitive for the user: You have a portal page for a newspaper for example. Every article has a teaser with an image, a headline and text. As a user, I don't want to search for a link text (like more..., which is really bad, or some small key phrase), i just want to click somewhere on the teaser (on the image or the text) to get the article I want to read. As a content producer, I have to honor that. It is good to have big clickable buttons, especially on present and upcoming mobile devices (like the iphone for example). In the best case the whole rectangle of the teaser is clickable. At the moment you need some javascript or an a-tag with display: block for it, to get this behavior (see example in my last mail). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 27 Feb 2008, Shannon wrote:
With the capabilities of modern browsers it seems to me that a specific
tag for hyperlinks is no longer required or useful and could be
depreciated with a more versatile global link attribute.
This has been proposed several times but several browser vendors have
indicated that they would not implement such a feature.
In practice, if we look at existing global attributes, we find that
historically only attributes that have a very orthogonal effect on the
document are successful. For example, class=, lang=, and id= have no
direct effect on the element, style= and dir= are equivalent to CSS
rules, and title= is implemented as an orthogonal UI feature.
The one attribute that _does_ have any direct effect on the element,
contentEditable, is fraught with problems, and has caused us no end of
hassle for years.
I believe that hyperlinks now have more in common with attributes such
as ONCLICK than they do with tags since in web applications links often
define actions rather than simply being a part of the document
structure. The A tag would continue its role as an anchor but the HREF
attribute would be phased out making A a more consistent element
(since links and anchors are really quite separate concepts). Below is
an example of the proposed link attribute in action:
lia href=foo.htmlFoo/a/li
could be written as:
li link=foo.htmlFoo/li
No useful semantic information is lost however the markup is cleaner and
the DOM drops an unnecessary node (which could speed up certain
applications).
I am not convinced that this clutter is a big problem that we need to
solve.
This proposal would circumvent A's main limitation which is its
requirement to not wrap block-level elements or 'interactive' content.
The HTML5 draft requires it wrap 'phrasing content' (essentially
paragraphs) and not wrap 'interactive' content (such as other
hyperlinks) however I see no reason why a link attribute should require
these limits. Links would simply cascade as in the following example:
table link=alphabet.html title=Alphabetical List
tr
tdA/td
tdB/td
td link=c.html title=More about CC/td
tdD/td
/tr
/table
(Note that the ul or ol elements would be far more appropriate
elements here.)
I don't think that making an entire list into a link is really something
that is useful from a usability point of view.
In the example above clicking anywhere on the table except 'C' brings up
a generic page, whereas 'C' has dedicated content. The following nested
links would also be valid:
span link=foo.htmlclick anywhere on this line except b
link=bar.html title=Go to bar insteadhere/b to visit foo./span
That seems like terrible UI.
The link attribute would make adding hyperlinks to DOM nodes easy:
node.link = 'http://foo.bar.baz'; /* Create a hyperlink on an element */
nodes_with_a_link = document.getElementsByAttribute('link'); /* Get all links.
This method doesn't exist in the draft but can be written in javascript using
iterators */
Again, turning individual elements into links doesn't seem like a big
problem. DOM ranges with selectNode() and surroundContents() could easily
be wrapped in a utility function if that was really needed, and it would
even allow you to linkify spans of text rather than only elements.
I believe a link attribute would be a significant improvement to HTML.
The only reasons I can think of not to add this would be the added
complexity for browsers and authors during the transition period. The
advantages include less markup, simpler DOM structure, nested
hyperlinks, onclick fallbacks and better consistency in the spec.
I don't really understand what is more consistent than using href= on
a, area, and link. I further don't think that nested hyperlinks are
a good idea. onclick fallbacks can already be done using a, which also
provides a better user experience on existin UAs. The remaining advantages
are definitely not, IMHO, outweighed by the significant costs.
Being such a common element web authors will probably keep using a
href for many years to come regardless of the standard but that should
not be a problem since a href and link should coexist quite easily in
valid HTML. Once awareness has spread then future drafts could
depreciate the href attribute on anchors.
I think we're adding enough new features that we shouldn't be adding
features that don't really add anything substantial.
On Thu, 28 Feb 2008, Shannon wrote:
FAQ: * Browser vendors have reported that implementing it would be
extremely complex.
I find this claim incredible.
To be blunt, it doesn't matter. If the browser developers say no, there's
not much point trying to change their mind, it just causes them to ignore
us. We only have any power so long as we tell them to do things they are
willing to do -- when we start telling them to do things that they are not
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 19:51 +, Philip Taylor pisze: Are there cases where div ...a href=... style=display:block; width:100%; height:100% ... /a/div is not adequate for making block links? It does not make the anchor a block element, it is still a text element, although with block display. It cannot contain flow content. button type=submit link=javascript:event.preventDefault() The URI is semantically incorrect because event is undefined. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Paweł Stradomski wrote: W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). Sorry, I should have explained that better (always in a rush to get my thoughts down), it was just a snippet that is actually inside a form. But you're right of course. Within a form wouldn't inputs with a type=button be appropriate? Why do we have type=button if it's completely useless without scripting? I view a checkout process as a multi-page form so my thinking was that from a user-perspective clicking buttons makes something happen in the scope of the form and does not 'take you elsewhere' as such regardless of what really goes on. It could get confusing but I'd definitely find it useful to apply to div elements and list items. Thanks for pointing that out, Robert
Re: [whatwg] Proposal for a link attribute to replace a href
Philip Taylor wrote: On 28/02/2008, Shannon [EMAIL PROTECTED] wrote: A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. Are there cases where div ...a href=... style=display:block; width:100%; height:100% ... /a/div is not adequate for making block links? If you could nest block elements inside a and have it validate then no. Would this be a possibility? Seems like it wouldn't be too difficult to implement if it's just a question of what validates and what doesn't. I guess a global attribute isn't the right thing.
Re: [whatwg] Proposal for a link attribute to replace a href
On 29 Feb 2008, at 01:29, Shannon wrote: Geoffrey Sneddon wrote: While yes, you could rely on something like that, it totally breaks in any user agent without scripting support. Nothing else, to my knowledge, in HTML 5 leads to total loss of functionality without JavaScript whatsoever. By total loss of functionality I meant something that is functionality provided by HTML itself (and not through CSS or some DOM API) which leads to the page being totally unusable. Well nothing except global/session/database storage, You already have the fallback for people without ECMAScript, so that works fine. the irrelevant attribute, So you can edit something which you otherwise couldn't. Oh well. Nothing breaks. contenteditable, Oh come on. Even IE supports this. This most certainly is backwards compatible. contextmenu, Again, this is a DOM API and can be recreated in ECMAScript (which, if you're try to use it at all, you know is enabled). draggable, Both IE and Safari have partial support for this already. the video and audio elements, canvas All three of these have fallback content, which is needed sometimes when a browser does support HTML 5 anyway. and the connection interface. Again, you know you have ECMAScript enabled already to be able to use this at all. Something similar could be done using XMLHttpRequest, if I am not mistaken. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Proposal for a link attribute to replace a href
On 28/02/2008, Robert O'Rourke [EMAIL PROTECTED] wrote: I don't understand why buttons should not be allowed an href, obviously when the button or input is to submit a form (ie. explicitly having type=submit as an attribute) it shouldn't be allowed but I'd find it useful where I've had to style a collection of links and inputs to be similar, for example the steps for a checkout process: One has to be careful here. You're absolutely right that form submission buttons need to be treated specially, as otherwise users' web accelerator software will start checking out their shopping carts, etc. I'm concerned that in all the exuberance to make more elements links, various basic problems like this might get overlooked. Sam
Re: [whatwg] Proposal for a link attribute to replace a href
Markus Ernst wrote:
Anyway, why do you suggest a new attribute rather than making the
existing href attribute global?
Because I think some current and depreciated tags still use href for a
different purpose (base for one). A global attribute should be unique.
I don't really mind what the attribute is called.
Anne van Kesteren wrote:
We have a FAQ entry on this -- quite common -- request:
http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F
Hope that helps!
I'm happy to see it's a common request but I really hope the FAQ entry
doesn't represent a final decision. I strongly disagree with its
conclusions, so I'll address each:
FAQ: * It isn't backwards compatible with existing browsers.
Not entirely true. I quote from the same FAQ:
What about Microsoft and Internet Explorer?
HTML 5 is being developed with IE compatibility in mind. Support for
many features can be simulated using JavaScript.
So 'backwards-compatibility', as defined by the same document, can be
achieved by using javascript to walk the DOM and add
'window.location(node.getAttribute('link'))' to the onclick handler of
any nodes with a link attribute. I have done a very similar thing before
to implement :hover on non-anchor elements in IE. Of course an author
wouldn't have to use this new attribute at all so
backwards-compatibility is the designers choice, not an issue with the
proposed attribute.
FAQ: * It adds no new functionality that can't already be achieved
using the a element.
Absolutely not true. A global attribute offers several features that a
does not - most importantly nested links and the ability to hyperlink
block and interactive elements without breaking validation.
FAQ: * It doesn't make sense for all elements, such as interactive
elements like input and button, where the use of href would interfere
with their normal function.
As long as the spec is clear about which actions take precedence then
this is not an issue. The spec should assume that if an author puts a
link on a form element then they are *deliberately* interfering with its
normal function. Trying to protect authors/users from their own bad
choices is a very 'Microsoft' way of thinking and not really appropriate
for spec targetting web authors. There might be good reasons for doing
this that are not immediately obvious.
FAQ: * Browser vendors have reported that implementing it would be
extremely complex.
I find this claim incredible. How is a global link/href any more
difficult than the existing implementations of onmouseup/down/whatever?
It's basically the same thing - only *simpler* (no scripting, events,
bubbling, etc).
So on all counts I find the claims in the FAQ incorrect and urge the
WHATWG and browser vendors to reconsider the inclusion of a global link
or href attribute.
Shannon
Re: [whatwg] Proposal for a link attribute to replace a href
W liście Shannon z dnia czwartek 28 lutego 2008: FAQ: * It adds no new functionality that can't already be achieved using the a element. Absolutely not true. A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. In my opinion this would be an important problem. How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. -- Paweł Stradomski
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 23:18 +1100, Shannon pisze: Markus Ernst wrote: Anyway, why do you suggest a new attribute rather than making the existing href attribute global? Because I think some current and depreciated tags still use href for a different purpose (base for one). A global attribute should be unique. I don't really mind what the attribute is called. BASE is invisible so it does not matter. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 27-02-2008, Śr o godzinie 23:25 +1100, Shannon pisze: ---LINK with block-level or interactive content--- This proposal would circumvent A's main limitation which is its requirement to not wrap block-level elements or 'interactive' content. The HTML5 draft requires it wrap 'phrasing content' (essentially paragraphs) and not wrap 'interactive' content (such as other hyperlinks) however I see no reason why a link attribute should require these limits. Links would simply cascade as in the following example: table link=alphabet.html title=Alphabetical List tr tdA/td tdB/td td link=c.html title=More about CC/td tdD/td /tr /table Tables should be used to present tabular data. Tabular data is something the user may want to meditate or to copy; their content cannot be grasped in a glance. Hyperlinked text should be a concise description of the content of the other page; a table does not meet that requirement. This design violates the least surprise principle. In the example above clicking anywhere on the table except 'C' brings up a generic page, whereas 'C' has dedicated content. The following nested links would also be valid: span link=foo.htmlclick anywhere on this line except b link=bar.html title=Go to bar insteadhere/b to visit foo./span It would be difficult to style a hyperlink within a hyperlink; moreover, a hyperlink that contains another hyperlink is not concise, see above. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Paweł Stradomski wrote: W liście Shannon z dnia czwartek 28 lutego 2008: FAQ: * It adds no new functionality that can't already be achieved using the a element. Absolutely not true. A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. In my opinion this would be an important problem. How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. I really like this idea too. I have no idea why anyone would want to nest links, whatever the parent element is. I don't understand why buttons should not be allowed an href, obviously when the button or input is to submit a form (ie. explicitly having type=submit as an attribute) it shouldn't be allowed but I'd find it useful where I've had to style a collection of links and inputs to be similar, for example the steps for a checkout process: currently I have this: div class=steps a href=/basket.html class=basket-stepBasket/span a href=/checkout.html class=current checkout-stepCheckout/a input type=submit class=confirm-step value=Confirm / span class=payment-stepPayment/span /div but it could become: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. There are plenty of other places where I'd like to put an href on an input or button within a form. For example when performing sub-tasks via a query string before a form is submitted, I think a button is more appropriate than an anchor tag (which is normally associated with navigating to another page). How web developers use it is up to them as always. It's up to the individual to use HTML appropriately so I think this would be a nifty addition to the repertoire. Cheers, Rob
Re: [whatwg] Proposal for a link attribute to replace a href
W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). -- Paweł Stradomski
Re: [whatwg] Proposal for a link attribute to replace a href
On 28/02/2008, Shannon [EMAIL PROTECTED] wrote:
http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F
So 'backwards-compatibility', as defined by the same document, can be
achieved by using javascript to walk the DOM and add
'window.location(node.getAttribute('link'))' to the onclick handler of
any nodes with a link attribute. I have done a very similar thing before
to implement :hover on non-anchor elements in IE.
I imagine the script would have problems with incremental loading - if
someone clicks a link before the page has finished loading and before
the script has executed, then it won't work. Is there a way to avoid
that problem and make it work as well as a real implementation?
There are also tools like search engines that need to recognise links
and can't be fixed by compatibility scripts. (Fortunately it's much
easier to upgrade all the world's search engines than all its web
browsers, so this is a less significant issue than with browsers.)
A global attribute offers several features that a
does not - most importantly nested links and the ability to hyperlink
block and interactive elements without breaking validation.
Are there cases where div ...a href=... style=display:block;
width:100%; height:100% ... /a/div is not adequate for making
block links?
FAQ: * It doesn't make sense for all elements, such as interactive
elements like input and button, where the use of href would interfere
with their normal function.
As long as the spec is clear about which actions take precedence then
this is not an issue.
Having to make the spec clear is an issue :-)
It would take quite a bit of effort to design and specify the feature
in sufficient detail, and to write test cases, and to update the spec
in response to implementor feedback about what would cause them fewer
problems. That is all much harder when the new feature interacts with
a lot of existing features (inputs, buttons, image maps, iframes, DOM
events, etc), compared to something fairly self-contained (like
video).
How is a global link/href any more
difficult than the existing implementations of onmouseup/down/whatever?
It's basically the same thing - only *simpler* (no scripting, events,
bubbling, etc).
As far as I'm aware, HTML elements currently have at most one default
click-event handler and any number of DOM handlers. The new link
attribute wouldn't be a DOM event handler (since it ought to behave
much more like a href), so it would either be an entirely new type
of event handler or it would break the assumption that there is a
single default handler, and I can imagine that that would cause
difficulties. (But I have no implementation experience so I could be
entirely wrong.)
There are cases like
button type=submit link=... onclick=event.preventDefault()
button type=submit link=javascript:event.preventDefault()
a href=1 link=2 onclick=window.location=3
a href=1 link=2 onclick=window.location=3; return false
etc
where the interaction between several aspects of the event model would
have to be defined (and implemented and tested), requiring some new
complexity on top of the current href+onclick model.
Another issue is that a href has a number of other attributes for
links, and it would be bad design if a generalisation of href didn't
allow those attributes on other elements. That includes 'target'
(conflicts with base target, form target), 'type' (conflicts with
style type, script type, embed type, object type), 'media'
(conflicts with style media, link media), etc.
Is there a nice way to solve those conflicts? Renaming the link
attributes (the same as renaming 'href' to 'link') would be confusing
to people who already know HTML, and it would be hard to find good
names that aren't used already. Defining lots of exceptional cases for
certain attributes on certain elements would make the language harder
to understand and implement and test. Defining exceptions for a
category of 'non-visible elements' (script, style, etc) wouldn't work
since script style=display:block is not non-visible. I'm not sure
how this could be made to work well.
Shannon
--
Philip Taylor
[EMAIL PROTECTED]
Re: [whatwg] Proposal for a link attribute to replace a href
On Thu, Feb 28, 2008 at 1:44 PM, Paweł Stradomski [EMAIL PROTECTED] wrote: W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). -- Paweł Stradomski Nod to Pawel. A workaround would be to custom-style your buttons so that you can match the links to their appearance. I override default button patterning completely in my pages for precisely that reason (also so they fit in the color scheme better). It's easy enough to style a link in the same fashion (easiest of all when you have proper inline-block support).
Re: [whatwg] Proposal for a link attribute to replace a href
Pawe? Stradomski wrote: W li?cie Shannon z dnia czwartek 28 lutego 2008: How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. Browsers were a lot more primitive back then. I have used nested onclick() handlers in the real world and had no problems, nor did my users. I have also safely used onclick on form elements. The browser always knows which element is directly under the mouse (that's why :hover works). Only the link directly under the mouse should trigger. Again, this is behaviour that onclick and :hover already perform in all major browsers. As I've said before, href should not be forbidden on interactive elements, the spec should define the event hierarchy, eg: event-input-link/href Chris wrote: Tables should be used to present tabular data. Tabular data is something the user may want to meditate or to copy; their content cannot be grasped in a glance. Hyperlinked text should be a concise description of the content of the other page; a table does not meet that requirement. This design violates the least surprise principle. ... It would be difficult to style a hyperlink within a hyperlink; moreover, a hyperlink that contains another hyperlink is not concise, see above. You'll never eliminate bad design by putting these limitations in the spec. What you'll do is make bad designers work around them (using onclick() or atable.../table/a). I've seen it happen before more times than I can count. Bad designers don't validate their code either. On the other hand designers who do know what they are doing can be artificially restricted or forced into non-compliance by these sorts of rules. What makes sense is really a matter of context (or clients), and cannot be discussed in abstract like this. The point is there _are_ situations I have experienced myself where link/href would be a better alternative than a or onclick() and situations where nested interaction is useful and still makes sense to the user. Finally, style should follow the stylesheet rules like everything else, nested or not. There is not a strong case for making the browser distinguish the boundaries between nested links if the designer chooses not to. Geoffrey Sneddon wrote: While yes, you could rely on something like that, it totally breaks in any user agent without scripting support. Nothing else, to my knowledge, in HTML 5 leads to total loss of functionality without JavaScript whatsoever. Well nothing except global/session/database storage, the irrelevant attribute, contenteditable, contextmenu, draggable, the video and audio elements, canvas and the connection interface. Some of these can't even be done in Javascript. Despite the efforts of this group backwards-compatibility is ultimately the authors responsibility. eg: !-- Modern content -- div link=foo.htmlfoo/div !-- Fallback / Search-engine content. Not rendered in HTML5 compliant browser -- a href=foo.html irrelevantfoo/a Nothing else reinvents the wheel for something with which we already have a perfectly fine solution already. If it were perfectly fine designers wouldn't be asking for this. My view is that a and onclick do not solve all cases where hyperlinks are needed. Overall I'd say that most objections to a global href tend to focus on all the bad things a designer could do with it. However I deal with many designers, good and bad, and I can categorical state that the bad ones have no qualms about mangling pages using the Javascript, plugins and non-compliant markup already at their disposal. Everytime you deny them a feature to make them behave you just encourage them to go out and write another hack. Making the language more flexible will not make things any worse. Using bad designers as a reason to deny features is basically an argument for aborting all work on new HTML5 features. I could name 100 ways to abuse the storage proposals yet we persist because they are useful. Global href is useful, and it should be discussed on the basis of correct usage and what its behaviour should be (ie, my first post). Shannon
Re: [whatwg] Proposal for a link attribute to replace a href
Shannon schrieb: With the capabilities of modern browsers it seems to me that a specific tag for hyperlinks is no longer required or useful and could be depreciated with a more versatile global link attribute. I believe that hyperlinks now have more in common with attributes such as ONCLICK than they do with tags since in web applications links often define actions rather than simply being a part of the document structure. The A tag would continue its role as an anchor but the HREF attribute would be phased out making A a more consistent element (since links and anchors are really quite separate concepts). Below is an example of the proposed link attribute in action: lia href=foo.htmlFoo/a/li could be written as: li link=foo.htmlFoo/li No useful semantic information is lost however the markup is cleaner and the DOM drops an unnecessary node (which could speed up certain applications). I like this idea - this could significantly reduce the amount of scripting in web pages and applications, and thus increase the accessibility of hyperlinks. Anyway, why do you suggest a new attribute rather than making the existing href attribute global? li href=foo.htmlFoo/li That makes your idea backwards compatible - provided UAs interpret attributes of unknown tags, they will even be capable to correctly handle occurrences of a href when the A element will be totally removed from their code. -- Markus Ernst
Re: [whatwg] Proposal for a link attribute to replace a href
[... global attribute for links ...] We have a FAQ entry on this -- quite common -- request: http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F Hope that helps! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
