Re: [whatwg] href attribute

[Colin Lieberman]

Hi all.  (Double apologies for accidentally sending that last email 
before finishing it)


My apologies for starting this rather exciting thread. :)

Several commenters (Matthew Raymond comes most prominently to mind) have 
convinced me that while a global href attribute would be handy, it's 
just not worth it:


One of his excellent points is a real clincher for me:

5) Using just an attribute can cause restructuring of markup when you
need to add content to a hyperlink. Let's say you start with this:

| http://w3.org"; title="World Wide Web Consortium">
|   W3C
| 

  Suppose you now want to add the word "Website" to the hyperlink:

| http://w3.org";>
|   W3C Website
| 


That case alone shows the need for an a element.

That said, I think there is a strong case for other element allowing 
links besides a... li and abbr pop to mind.



Daniel Glazman wrote:

On 11/03/2007 21:30, Anne van Kesteren wrote:

What does ... not offer that href="">... does? 


Code quality... The former is just ugly, really ugly, it smells like
HTML+ from 1993.

Re: [whatwg] href attribute

[Colin Lieberman]

Hi all.

My apologies for starting this rather exciting thread. :)

Several commenters (Matthew Raymond comes most prominently to mind) have 
convinced me that while a global href attribute would be handy, it's 
just not worth it:


One of his excellent points is a real clincher for me:


Daniel Glazman wrote:

On 11/03/2007 21:30, Anne van Kesteren wrote:

What does ... not offer that href="">... does? 


Code quality... The former is just ugly, really ugly, it smells like
HTML+ from 1993.

Re: [whatwg] href attribute

[Daniel Glazman]

On 11/03/2007 22:16, Matthew Raymond wrote:


   Why? A hyperlink is a relationship BETWEEN to anchors.


No. Between two resources. Resources can be anchors inside
document instances.

Re: [whatwg] href attribute

[Daniel Glazman]

On 11/03/2007 21:30, Anne van Kesteren wrote:

What does ... not offer that href="">... does? 


Code quality... The former is just ugly, really ugly, it smells like
HTML+ from 1993.

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Anne van Kesteren" <[EMAIL PROTECTED]>

To: "Daniel Glazman" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2007 11:52 AM
Subject: Re: [whatwg] href attribute


On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman 
<[EMAIL PROTECTED]> wrote:
In any case not all 's are hyperlinks so for your meaning of 
semantic they should also not be automatically hyperlinks (or anchors 
if you wish). I am pretty sure that existence of 'href' attribute is 
what creates semantic meaning of  for you. So why  cannot be href> or ?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)


I agree. One of the reasons HTML5 has  and redefined -.



Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.


What are the problems it solves? To my mind introducing it will just break 
compatibility and complicate implementations for no apparent benefit. You 
also get to deal with silly cases like:


There are many cases when hyperlink-head needs to be a block level
element. Not all contexts in html allow inline elements to appear.
And , as inline element, by itself cannot contain block elements.
Example #1
... is not acceptable.
... is not acceptable.

Example #2

  ...

in this example the desire is to declare the whole rectangle of li to be
a link, not just textual portion of it.  Think about tabs implementation
where each tab is a rectangle with clear visual borders. human
would expect that the whole area inside the borders (included)
of the tab  is a clickable area.

"... and complicate implementations..."

I do not know of how this is implemented in Opera but in my
case to support href globally is a matter of changing:
 a:link { behavior: hyperlink; }
to
 :link { behavior: hyperlink; }
in master style sheet.

I beleive that each modern and modular UA has similar
mechanism of assigning "behavior handlers".



  http://www.opera.com/>



Think about this:

http://www.opera.com/help/checkbox/explanation
 target="_new">
links like this can be used for contextual help and for me is perfectly 
valid

use case.

It is matter of UA implementation of how to support multiple behaviors
on the same element but it is feasible.

Andrew Fedoniouk.
http://terrainformatica.com




HTML5 already redefines  to be hyperlink or a placeholder for one (this 
should address your concern raised in another e-mail). The idea of name=""> is not mentioned in the draft and isn't even conforming (although 
I suppose user agents will be required to support it). Any element can be 
a link target much like in HTML4.



--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: [whatwg] href attribute

[Matthew Raymond]

Daniel Glazman wrote:
>> Indeed.  IMO, global |href| gives nothing but more confusion.  If we
>> want to have hyperlinks on block-level elements, it is simpler just
>> let  and/or other inline elements be legal to wrap block-level
>> elements.
> 
> No, it gives more than that : if |href| becomes global, the usage of
> |a| will decrease and that's a good thing. |a| is a bad element because
> it serves as source AND target of links, because it's not multivalued,

   How is that any different from this?...

| 

   In the above, it has an |id|, so it can be a destination. It has a
global |href| attribute, so it can be a source. Heck, it can link to
itself for that matter:

| 

> and I have 5 or six other very good reasons in mind.

   Hope they're better than that last one, especially when you consider
that |name| can't be a global attribute since it's already defined on
form control elements. (Not that I'm a huge fan of |name|. I'm just
pointing out that  can't be completely replaced by globalizing its
attributes.)

> Anything we can do
> to prepare a future - in the long term - deprecation of |a| is a good
> thing for the future of HTML.

   I have yet to hear a convincing argument in that regard.
Specifically, I have yet to hear any semantic advantage to a global
|href| attribute. In my eyes, this is all just frivolous markup
restructuring.

Re: [whatwg] href attribute

[Matthew Raymond]

Andrew Fedoniouk wrote:
>>   This is not a definition of the  element. In fact,  is defined
>> as a anchor, not a hyperlink.
> 
> I think "hyperlink" is better in any sense 
> than "anchor" as a designation of this entity.

   Why? A hyperlink is a relationship BETWEEN to anchors. It can't be an
element any more than a journey can be considered a place.

> I beleive that you and me have different interpretation of 
> the term 'semantic'. 
> 
> For my semantic any HTML element that has 
> "href" attribute is not anyhow different from the  element
> with href.

   What you're creating is a new attribute that happens to have the same
name as the HTML 4.01 |href| attribute, not an extension thereof. The
fact that it could be implemented in a manner identical to  is a
function of implementation, not semantics.

> If I see  I recognize that this is a list item that
> leads somewhere.

   That's not saying much, because you already know how to use  and
are familiar with its attributes.

> Exactly (and even better) as ...

   No it's not, because if I want to move the anchor out of the list,
I'd have to create a new container element in your markup, whereas the
HTML 4.01 equivalent requires a mere cut and paste (or perhaps a
drag-drop, depending on your editor).

> For different tools it also does not matter what to use:
> 
> getElementsBySelector(":link") or 
> getElementsBySelector("a:link") or 
> getElementsBySelector("[href]") or 
> whatever.

   If you want to use the Selectors API:

| document.matchAll("[href]")

   However, my point was never that you couldn't find a newly defined
attribute with a newly defined DOM API...

> In any case not all 's are hyperlinks so 
> for your meaning of semantic they should also not be 
> automatically hyperlinks (or anchors if you wish).  

   An  element is always an anchor. It's simply not specified whether
or not it's a source or a destination. No element can be a hyperlink, by
the definition you provided in your earlier post, because a hyperlink is
a relationship between anchors.

> I am pretty sure that existence of 'href' attribute is 
> what creates semantic meaning of  for you. 

   The |href| attribute doesn't define anchors. It defines the
relationship between those anchors. It does imply that the anchor is a
source, but the actual anchor semantic is at the element level.

> So why  cannot be  or ?

1) It makes the markup brittle when editing.

2) It makes markup harder to read by:

   a) Forcing you to look for an attribute that can very in position
  relative to the start of the element tag instead of a letter
  that's the very first character in the element tag.

   b) Forcing you to look for the starting tag in order to determine if
  an ending tag ends an anchor for a hyperlink.

3) It's not compatible with legacy browsers.

4) It causes confusion because authors might infer the meaning of the
   attribute based on the element it's declared on.

5) It may be non-trivial to add to some browser implementations.

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 09:30:58PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 21:27:14 +0100, carmen <[EMAIL PROTECTED]> wrote:
> >suppose one is building a GUI with solely  elements. say you have a 
> >doorway, clicking on it opens into the room, which is another page. forcing 
> >this stuff into onclick() just because href= 
> >is invalid, decreases scrapability/accessibility. is one supposed to just 
> >wrap canvas polygons in s or something?
> 
> What does ... not offer that  href="">... does? And if this is in fact an application you might 
> actually want to have the  as fallback of the 

well i was thinking like . i guess its not that simple yet..

>  along with other content...
> 
> 
> --
> Anne van Kesteren
> 
> 
> 

Re: [whatwg] href attribute

[Anne van Kesteren]

On Sun, 11 Mar 2007 21:27:14 +0100, carmen <[EMAIL PROTECTED]> wrote:
suppose one is building a GUI with solely  elements. say you  
have a doorway, clicking on it opens into the room, which is another  
page. forcing this stuff into onclick() just because href= is invalid,  
decreases scrapability/accessibility. is one supposed to just wrap  
canvas polygons in s or something?


What does ... not offer that href="">... does? And if this is in fact an application you might  
actually want to have the  as fallback of the  along with other  
content...



--
Anne van Kesteren

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 08:52:36PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman <[EMAIL PROTECTED]> wrote:
> >>In any case not all 's are hyperlinks so for your meaning of semantic 
> >>they should also not be automatically hyperlinks (or anchors if you wish). 
> >>I am pretty sure that existence of 'href' 
> >>attribute is what creates semantic meaning of  for you. So why  
> >>cannot be  or ?
> >
> >Let me also play the devil (I love it) : a feature is not trashable
> >only because it comes from XHTML 2.0 :-)
> 
> I agree. One of the reasons HTML5 has  and redefined -.
> 
> 
> >Here, a global href is a really cool idea, we should have done it in
> >HTML 4 but we were too blind to see.
> 
> What are the problems it solves? To my mind introducing it will just break 
> compatibility and complicate implementations for no apparent benefit. You 
> also get to deal with silly cases like:

suppose one is building a GUI with solely  elements. say you have a 
doorway, clicking on it opens into the room, which is another page. forcing 
this stuff into onclick() just because href= is invalid, decreases 
scrapability/accessibility. is one supposed to just wrap canvas polygons in 
s or something?

> 
>   http://www.opera.com/>
> 
> 
> HTML5 already redefines  to be hyperlink or a placeholder for one (this 
> should address your concern raised in another e-mail). The idea of  name=""> is not mentioned in the draft and isn't even 
> conforming (although I suppose user agents will be required to support it). 
> Any element can be a link target much like in HTML4.
> 
> 
> --
> Anne van Kesteren
> 
> 
> 

Re: [whatwg] href attribute

[Anne van Kesteren]

On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman  
<[EMAIL PROTECTED]> wrote:
In any case not all 's are hyperlinks so for your meaning of  
semantic they should also not be automatically hyperlinks (or anchors  
if you wish). I am pretty sure that existence of 'href' attribute is  
what creates semantic meaning of  for you. So why  cannot be href> or ?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)


I agree. One of the reasons HTML5 has  and redefined -.



Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.


What are the problems it solves? To my mind introducing it will just break  
compatibility and complicate implementations for no apparent benefit. You  
also get to deal with silly cases like:


  http://www.opera.com/>


HTML5 already redefines  to be hyperlink or a placeholder for one (this  
should address your concern raised in another e-mail). The idea of name=""> is not mentioned in the draft and isn't even conforming (although  
I suppose user agents will be required to support it). Any element can be  
a link target much like in HTML4.



--
Anne van Kesteren

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Daniel Glazman" <[EMAIL PROTECTED]>

To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>; "Matthew Raymond" 
<[EMAIL PROTECTED]>

Sent: Saturday, March 10, 2007 9:03 PM
Subject: Re: [whatwg] href attribute



On 11/03/2007 05:59, Andrew Fedoniouk wrote:

In any case not all 's are hyperlinks so for your meaning of semantic 
they should also not be automatically hyperlinks (or anchors if you 
wish). I am pretty sure that existence of 'href' attribute is what 
creates semantic meaning of  for you. So why  cannot be  or 
?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)
Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.




:)

BTW: I had a feeling that anchor is a name of region in html.
So  or  are
anchors but  or  are links
to some anchors.

But it seems that in such semantically saturated
place as whatwg mail list my used to be clear perception
of simple things like anchors was changed significantly.
Or semanticly? Ah, whatever...

Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 06:03:02AM +0100, Daniel Glazman wrote:
> On 11/03/2007 05:59, Andrew Fedoniouk wrote:
> 
> >In any case not all 's are hyperlinks so for your meaning of semantic 
> >they should also not be automatically hyperlinks (or anchors if you wish). I 
> >am pretty sure that existence of 'href' 
> >attribute is what creates semantic meaning of  for you. So why  cannot 
> >be  or ?
> 
> Let me also play the devil (I love it) : a feature is not trashable
> only because it comes from XHTML 2.0 :-)

wow, thanks for pointing that out... i had no idea. at least if i start doing 
it i can prove someone else thought it was a good enough idea to put in 
writing..

[1] http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html




> Here, a global href is a really cool idea, we should have done it in
> HTML 4 but we were too blind to see.
> 
> 
> 

Re: [whatwg] href attribute

[Daniel Glazman]

On 11/03/2007 05:59, Andrew Fedoniouk wrote:

In any case not all 's are hyperlinks so for your meaning of semantic 
they should also not be automatically hyperlinks (or anchors if you wish). 
I am pretty sure that existence of 'href' attribute is what creates 
semantic meaning of  for you. So why  cannot be  or ?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)
Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Matthew Raymond" <[EMAIL PROTECTED]>

To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
Sent: Saturday, March 10, 2007 7:17 PM
Subject: Re: [whatwg] href attribute



Andrew Fedoniouk wrote:

Back to basics:

"A hyperlink is a relationship between two anchors,
called the head and the tail of the hyperlink[DEXTER]. " [1]


  This is not a definition of the  element. In fact,  is defined
as a anchor, not a hyperlink.


I think "hyperlink" is better in any sense 
than "anchor" as a designation of this entity.




  By contrast, the |href| attribute "specifies the location of a Web
resource". Thus, using |href| for hyperlinks on other elements is an
alteration of the attribute's semantics, because the element you put
them on doesn't have the semantics of a source anchor.


Any element is allowed to be a tail of the hyperlink:

"The id attribute may be used to create an anchor at the start tag
of any element (including the A element)." [2]


  While one could argue that the |id| element give anchor semantics to
an element, it is clear that in this context the text implicitly refers
to the semantics of a DESTINATION anchor, not a source anchor. Even if
you were to ignore this context, it would mean that using |href| as a
global attribute would ALWAYS require you to include an |id| attribute
on the element.


But I do not understand why we have such a limitation for
the head of the hyperlink.


  The definition of  as inline is the only limitation in HTML I'm
aware of. Everything else is a CSS issue, and we should generally avoid
making fundamental alterations to HTML purely to achieve presentational
ends.


There are multiple semantically correct cases when
block elements like , ,  ,  etc.
*are* hyperlinks.


  Actually, by the definition you quoted, they're not hyperlinks and
can never be hyperlinks because a hyperlink is a relationship. In HTML
4.01, they can't even be source anchors. The HTML 4.01 version of |href|
doesn't have the semantics to make them source anchors even if you made
the attribute global.

  So let's be clear that what you're talking about is making every
element semantically an  element. In other words, every element would
automatically be a source anchor. Thus, you have taken semantics that
were explicitly represented by an element and made them implicit and
invisible in the markup. This is a poor way of dealing with semantics
that are at the very heart of the World Wide Web, and I would certainly
not call it "semantically correct".


But designers are forced to use
weird tricks to fight with inline nature of s.


  That issue can be addressed without getting rid of , by either
allowing  to contain block-levels, or by creating a new block-level
container with equivalent semantics.



I beleive that you and me have different interpretation of 
the term 'semantic'. 

For my semantic any HTML element that has 
"href" attribute is not anyhow different from the  element
with href. 
If I see  I recognize that this is a list item that
leads somewhere. Exactly (and even better) as 
... 


For different tools it also does not matter what to use:

getElementsBySelector(":link") or 
getElementsBySelector("a:link") or 
getElementsBySelector("[href]") or 
whatever.


In any case not all 's are hyperlinks so 
for your meaning of semantic they should also not be 
automatically hyperlinks (or anchors if you wish).  

I am pretty sure that existence of 'href' attribute is 
what creates semantic meaning of  for you. 
So why  cannot be  or ?


Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] href attribute

[Daniel Glazman]

On 10/03/2007 02:28, Billy Wong wrote:


On 3/6/07, Matthew Raymond <[EMAIL PROTECTED]> wrote:

   To me, the only advantage of a global |href| is that you can use it
on block-level elements, and I don't see why a block-level version of
 couldn't fill the same use case.


Indeed.  IMO, global |href| gives nothing but more confusion.  If we
want to have hyperlinks on block-level elements, it is simpler just
let  and/or other inline elements be legal to wrap block-level
elements.


No, it gives more than that : if |href| becomes global, the usage of
|a| will decrease and that's a good thing. |a| is a bad element because
it serves as source AND target of links, because it's not multivalued,
and I have 5 or six other very good reasons in mind. Anything we can do
to prepare a future - in the long term - deprecation of |a| is a good
thing for the future of HTML.

Re: [whatwg] href attribute

[Matthew Raymond]

Andrew Fedoniouk wrote:
> Back to basics:
> 
> "A hyperlink is a relationship between two anchors,
> called the head and the tail of the hyperlink[DEXTER]. " [1]

   This is not a definition of the  element. In fact,  is defined
as a anchor, not a hyperlink.

   By contrast, the |href| attribute "specifies the location of a Web
resource". Thus, using |href| for hyperlinks on other elements is an
alteration of the attribute's semantics, because the element you put
them on doesn't have the semantics of a source anchor.

> Any element is allowed to be a tail of the hyperlink:
> 
> "The id attribute may be used to create an anchor at the start tag
> of any element (including the A element)." [2]

   While one could argue that the |id| element give anchor semantics to
an element, it is clear that in this context the text implicitly refers
to the semantics of a DESTINATION anchor, not a source anchor. Even if
you were to ignore this context, it would mean that using |href| as a
global attribute would ALWAYS require you to include an |id| attribute
on the element.

> But I do not understand why we have such a limitation for
> the head of the hyperlink.

   The definition of  as inline is the only limitation in HTML I'm
aware of. Everything else is a CSS issue, and we should generally avoid
making fundamental alterations to HTML purely to achieve presentational
ends.

> There are multiple semantically correct cases when
> block elements like , ,  ,  etc.
> *are* hyperlinks.

   Actually, by the definition you quoted, they're not hyperlinks and
can never be hyperlinks because a hyperlink is a relationship. In HTML
4.01, they can't even be source anchors. The HTML 4.01 version of |href|
doesn't have the semantics to make them source anchors even if you made
the attribute global.

   So let's be clear that what you're talking about is making every
element semantically an  element. In other words, every element would
automatically be a source anchor. Thus, you have taken semantics that
were explicitly represented by an element and made them implicit and
invisible in the markup. This is a poor way of dealing with semantics
that are at the very heart of the World Wide Web, and I would certainly
not call it "semantically correct".

> But designers are forced to use
> weird tricks to fight with inline nature of s.

   That issue can be addressed without getting rid of , by either
allowing  to contain block-levels, or by creating a new block-level
container with equivalent semantics.

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Anne van Kesteren" <[EMAIL PROTECTED]>

To: "Billy Wong" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
Sent: Saturday, March 10, 2007 12:32 AM
Subject: Re: [whatwg] href attribute


On Sat, 10 Mar 2007 02:28:32 +0100, Billy Wong <[EMAIL PROTECTED]> 
wrote:

Indeed.  IMO, global |href| gives nothing but more confusion.  If we
want to have hyperlinks on block-level elements, it is simpler just
let  and/or other inline elements be legal to wrap block-level
elements.


Yup. If I recall correctly parsing-wise it's possible to let  contain 
block level elements. That's being considered now to cater for those use 
cases.





Anne, but what about this:


  


it is not about  itself.
It should also be a mechanism for the container similar to
CSS's display-model attribute for the container of .
But this is out of influence of HTML per se.

Back to basics:

"A hyperlink is a relationship between two anchors,
called the head and the tail of the hyperlink[DEXTER]. " [1]

Any element is allowed to be a tail of the hyperlink:

"The id attribute may be used to create an anchor at the start tag
of any element (including the A element)." [2]

But I do not understand why we have such a limitation for
the head of the hyperlink.

There are multiple semantically correct cases when
block elements like , ,  ,  etc.
*are* hyperlinks. But designers are forced to use
weird tricks to fight with inline nature of s.

Andrew Fedontiouk.
http://terrainformatica.com


[1] http://www.ietf.org/rfc/rfc1866.txt
[2] http://www.w3.org/TR/html401/struct/links.html#h-12.2.3

Re: [whatwg] href attribute

[Anne van Kesteren]

On Sat, 10 Mar 2007 02:28:32 +0100, Billy Wong <[EMAIL PROTECTED]>  
wrote:

Indeed.  IMO, global |href| gives nothing but more confusion.  If we
want to have hyperlinks on block-level elements, it is simpler just
let  and/or other inline elements be legal to wrap block-level
elements.


Yup. If I recall correctly parsing-wise it's possible to let  contain  
block level elements. That's being considered now to cater for those use  
cases.



--
Anne van Kesteren

Re: [whatwg] href attribute

[Billy Wong]

On 3/6/07, Matthew Raymond <[EMAIL PROTECTED]> wrote:

   To me, the only advantage of a global |href| is that you can use it
on block-level elements, and I don't see why a block-level version of
 couldn't fill the same use case.


Indeed.  IMO, global |href| gives nothing but more confusion.  If we
want to have hyperlinks on block-level elements, it is simpler just
let  and/or other inline elements be legal to wrap block-level
elements.

Billy

Re: [whatwg] href attribute

[Matthew Raymond]

Leons Petrazickis wrote:
> The sister issue of easy-of-typing is ease-of-reading. Human editing
> of raw HTML isn't going away. In headier coding disciplines, high
> readability is prized. Most code -- even HTML code -- will spend a lot
> more of its time being maintained than being written. Being able to
> understad things at a glance is important.
> 
>  is easier to read than .

   Hardly. It may be more appealing to the eye for some people, but
that's not the same thing as being easier to read. When I'm reading
markup, I tend to look for elements first, then the first attribute, et
cetera. So, when I'm scanning markup, an I come across the markup above,
I would see this:

| 

   That's because when you look at enough markup, you train yourself to
treat the element name as the most important and search for that first.
You only see the attributes when you've already matched on the element.

   Now, consider the two markup examples above again. Find the hyperlinks:

| ItemItemItemItem
| ItemItem
| ItemItemItem
| ItemItemItemItem

   Now try again:

| ItemItemItemItem
| ItemItem
| ItemItemItem
| ItemItemItemItem

   To me, the second example is more readable. Now, it may very well be
that you have no problem finding the |href| attributes in the first
example. However, if that's the case, how can it be harder for you to
find the same attribute name in the second?

   Also note that applications like Mozilla Firefox's DOM Inspector
present information in a node tree where attributes are only visible
when you click on an element node. Thus, a global |href| attribute would
result in hyperlinks being entirely hidden if you haven't specifically
clicked on its parent element.

   To me, the only advantage of a global |href| is that you can use it
on block-level elements, and I don't see why a block-level version of
 couldn't fill the same use case.

Re: [whatwg] href attribute

[Colin Lieberman]

Cheers Matthew - That's probably the most sensible explanation possible. 
Well done. I'm convinced.


Matthew Raymond wrote:

carmen wrote:
  

On Fri Mar 02, 2007 at 08:09:10PM +0100, David Håsäther wrote:
  

I don't see the href attribute specified anywhere but the a
element in the current Web Applications spec. Is there interest
in expanding actionable elements in this way?


definitely, as it facilitates the DRY principle of not repeating
tags just to fulfll the browser's wishes of only having the href
attribute on certain tags..



   In that case, why not make  an attribute:

| http://w3.org"; abbr="World Wide Web Consortium">W3C

   But why stop there? Can't there be a list of abbreviated italicized
headers with strong emphasis?...

| http://w3.org"; h="1" i strong abbr="World Wide Web
| Consortium">W3C

   The desire to save seven characters simply isn't sufficient,
especially when the disadvantages are just as great:

1) A full tag is more visible than just the attribute.

2) With DOM tools that represent the document as a tree with each
element as a node, you have to examine the properties of each node to
find the hyperlinks.

3) The structure of markup encourages people to view elements as having
stronger semantics than attributes. Therefore, converting  into
just an attribute is a semantic demotion. (And if you don't think so,
consider this: .)

4) If you can't see the starting tag, and thus can't see its attributes,
then you don't know that the element and its contents are part of a
hyperlink, even if the end tag is visible.

5) Using just an attribute can cause restructuring of markup when you
need to add content to a hyperlink. Let's say you start with this:

| http://w3.org"; title="World Wide Web Consortium">
|   W3C
| 

   Suppose you now want to add the word "Website" to the hyperlink:

| http://w3.org";>
|   W3C Website
| 

   Notice that you had to add an element to accommodate the extra
content. If you had just used the  element, you'd only need to type
"Website". Thus a universal |href| attribute promotes fragile markup
structure.

6) Legacy browsers will ignore the hyperlink entirely if you use |href|
on elements other than .

7) The ability to make block-level elements hyperlinks promotes bad UI,
because it makes it more difficult to perform operations like
highlighting and copying text, and because current web users are
unaccustomed to hyperlinks on such elements.

8) The attribute may cause confusion on some elements, such as ,
, et cetera. For example, would a web author know the
difference between |href| and |cite| on a  element?

  

No, as this would not be backwards-compatible.
  

instead of the generic 'no'. can you implicate situations where a
href tag on a non-'a' element confuses the browser?



   See #6 above.

  

Re: [whatwg] href attribute

[Leons Petrazickis]

On 3/4/07, Alexey Feldgendler <[EMAIL PROTECTED]> wrote:

On Fri, 02 Mar 2007 18:25:45 +0100, Colin Lieberman <[EMAIL PROTECTED]>
wrote:

> Alexey, I see your point regarding buttons, but there are many other
> cases where an a element seems unnecessary and redundant (as others have
> pointed out):
>
> Navigation:
> 
> Home
> About
> 

How is this better than , not taking the amount of typing
into account?


The sister issue of easy-of-typing is ease-of-reading. Human editing
of raw HTML isn't going away. In headier coding disciplines, high
readability is prized. Most code -- even HTML code -- will spend a lot
more of its time being maintained than being written. Being able to
understad things at a glance is important.

 is easier to read than .

Admittedly, the main reason bullet code is hard to read is because IE6
doesn't handle indentation in bullets properly. Specifying a new
attribute on  that won't be parsed correctly by IE6 is not a
solution to that.
--
Leons Petrazickis

Re: [whatwg] href attribute

[Elliotte Harold]

Alexey Feldgendler wrote:


Navigation:

Home
About



How is this better than , not taking the amount of 
typing into account?


One less nested element means a simpler, cleaner more navigable DOM.

I'm not saying that's a sufficient advantage to justify the proposal, 
but the more ugly DOM code you've had to unravel the better this looks.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] href attribute

[Alexey Feldgendler]

On Fri, 02 Mar 2007 18:25:45 +0100, Colin Lieberman <[EMAIL PROTECTED]>  
wrote:


Alexey, I see your point regarding buttons, but there are many other  
cases where an a element seems unnecessary and redundant (as others have  
pointed out):


Navigation:

Home
About



How is this better than , not taking the amount of typing  
into account?



clickable images (like a thumbnails gallery)


This is not really different from "clickable text".

Clickability is a presentational/behavioral property specific to  
interactive visual media with a pointing device, but the semantics of  
clickable-something is usually "hyperlink" (though sometimes e.g.  
"button"). To express hyperlink semantics, we have .


glossary links: href="/glossary.php#html">html


For , it's probably worth adding the href attribute if the use case  
is frequent. The rationale would be that the semantic unit delimited by  
 can be said to have such property as the reference URL to look up  
the definition.


There are, I think, numerous cases like these we encounter every day  
where an a is slipped inside another element because that's the only way  
to make the link, and the anchor itself serves no other purpose.


Most cases when there are nested  and some other element which cover  
exactly the same range (... or  
...) don't deserve merging of  and   
because it just happens sometimes that the elements cover the same range,  
but it could be different. For example, an  could cover only part of a  
 in your example above, or  in a gallery item could include both a  
thumbnail and a caption below that.


 From a semantics point of view, the clickablility of an object and the  
destination URI of that action is a property of the element itself, and  
it makes much more sense to me to use an attribute, rather than a  
separate element, for these sorts of cases.


"Clickability" is presentational/behavioral. "Destination URI" has  
different semantic meaning when applied to different elements, and no  
meaning at all when applied to some (e.g. ).



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] href attribute

[Matthew Raymond]

carmen wrote:
>> On Fri Mar 02, 2007 at 08:09:10PM +0100, David Håsäther wrote:
>>> I don't see the href attribute specified anywhere but the a
>>> element in the current Web Applications spec. Is there interest
>>> in expanding actionable elements in this way?
> 
> definitely, as it facilitates the DRY principle of not repeating
> tags just to fulfll the browser's wishes of only having the href
> attribute on certain tags..

   In that case, why not make  an attribute:

| http://w3.org"; abbr="World Wide Web Consortium">W3C

   But why stop there? Can't there be a list of abbreviated italicized
headers with strong emphasis?...

| http://w3.org"; h="1" i strong abbr="World Wide Web
| Consortium">W3C

   The desire to save seven characters simply isn't sufficient,
especially when the disadvantages are just as great:

1) A full tag is more visible than just the attribute.

2) With DOM tools that represent the document as a tree with each
element as a node, you have to examine the properties of each node to
find the hyperlinks.

3) The structure of markup encourages people to view elements as having
stronger semantics than attributes. Therefore, converting  into
just an attribute is a semantic demotion. (And if you don't think so,
consider this: .)

4) If you can't see the starting tag, and thus can't see its attributes,
then you don't know that the element and its contents are part of a
hyperlink, even if the end tag is visible.

5) Using just an attribute can cause restructuring of markup when you
need to add content to a hyperlink. Let's say you start with this:

| http://w3.org"; title="World Wide Web Consortium">
|   W3C
| 

   Suppose you now want to add the word "Website" to the hyperlink:

| http://w3.org";>
|   W3C Website
| 

   Notice that you had to add an element to accommodate the extra
content. If you had just used the  element, you'd only need to type
"Website". Thus a universal |href| attribute promotes fragile markup
structure.

6) Legacy browsers will ignore the hyperlink entirely if you use |href|
on elements other than .

7) The ability to make block-level elements hyperlinks promotes bad UI,
because it makes it more difficult to perform operations like
highlighting and copying text, and because current web users are
unaccustomed to hyperlinks on such elements.

8) The attribute may cause confusion on some elements, such as ,
, et cetera. For example, would a web author know the
difference between |href| and |cite| on a  element?

>> No, as this would not be backwards-compatible.
> 
> instead of the generic 'no'. can you implicate situations where a
> href tag on a non-'a' element confuses the browser?

   See #6 above.

Re: [whatwg] href attribute

[carmen]

On Fri Mar 02, 2007 at 08:09:10PM +0100, David Håsäther wrote:
> Colin Lieberman wrote:
> 
> >I don't see the href attribute specified anywhere but the a element in the 
> >current Web Applications spec. Is there interest in expanding actionable 
> >elements in this way?

definitely, as it facilitates the DRY principle of not repeating tags just to 
fulfll the browser's wishes of only having the href attribute on certain tags..

> 
> No, as this would not be backwards-compatible.

instead of the generic 'no'. can you implicate situations where a href tag on a 
non-'a' element confuses the browser?

> 
> --
> David Håsäther
> 

Re: [whatwg] href attribute

[David Håsäther]

Colin Lieberman wrote:

I don't see the href attribute specified anywhere but the a element in  
the current Web Applications spec. Is there interest in expanding  
actionable elements in this way?


No, as this would not be backwards-compatible.

--
David Håsäther

Re: [whatwg] href attribute

[David Walbert]

On Mar 2, 2007, at 12:20 PM, Nicholas Shanks wrote:

 it also helps remove redundancy when you have any two tags opening  
and closing at the same place, such as foo (or  
foo — which is better anyway?)


I would say foo -- the abbreviation is the think  
that is linked, but the  element is not part of the abbreviation. 

Re: [whatwg] href attribute

[Colin Lieberman]

Alexey, I see your point regarding buttons, but there are many other 
cases where an a element seems unnecessary and redundant (as others have 
pointed out):


Navigation:

Home
About


clickable images (like a thumbnails gallery)

glossary links: href="/glossary.php#html">html


There are, I think, numerous cases like these we encounter every day 
where an a is slipped inside another element because that's the only way 
to make the link, and the anchor itself serves no other purpose.


From a semantics point of view, the clickablility of an object and the 
destination URI of that action is a property of the element itself, and 
it makes much more sense to me to use an attribute, rather than a 
separate element, for these sorts of cases.


Colin Lieberman

Alexey Feldgendler wrote:

On Fri, 02 Mar 2007 17:55:34 +0100, Colin Lieberman <[EMAIL PROTECTED]> wrote:

  

One of the strengths of the current XHTML2 spec is the broadened use of
the href attribute
(http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_href)
-- and the resulting requirement for user agents that any element with a
(valid) href element be an actionable link.



Any element can be made into a button, but HTML has the  element to 
explicitly express the button semantics. I think you won't argue that

Calculate

...is preferable than

Calculate

Likewise, HTML has  to explicitly express the semantics of a hyperlink. I 
don't see how the language would benefit from the ability of turning any element into 
a link.


  

Re: [whatwg] href attribute

[Nicholas Shanks]

On 2 Mar 2007, at 17:00, Alexey Feldgendler wrote:

Likewise, HTML has  to explicitly express the semantics of a  
hyperlink. I don't see how the language would benefit from the  
ability of turning any element into a link.


The main use I would put it to is on  elements, especially tables  
of contents—the usage would be hyperlinks, not buttons. it also helps  
remove redundancy when you have any two tags opening and closing at  
the same place, such as foo (or fooabbr> — which is better anyway?)


- Nicholas.




smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] href attribute

[Alexey Feldgendler]

On Fri, 02 Mar 2007 17:55:34 +0100, Colin Lieberman <[EMAIL PROTECTED]> wrote:

> One of the strengths of the current XHTML2 spec is the broadened use of
> the href attribute
> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_href)
> -- and the resulting requirement for user agents that any element with a
> (valid) href element be an actionable link.

Any element can be made into a button, but HTML has the  element to 
explicitly express the button semantics. I think you won't argue that

Calculate

...is preferable than

Calculate

Likewise, HTML has  to explicitly express the semantics of a hyperlink. I 
don't see how the language would benefit from the ability of turning any 
element into a link.


-- 
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

[whatwg] href attribute

[Colin Lieberman]

My apologies if this has already been discussed -

One of the strengths of the current XHTML2 spec is the broadened use of 
the href attribute 
(http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_href) 
-- and the resulting requirement for user agents that any element with a 
(valid) href element be an actionable link.


I don't see the href attribute specified anywhere but the a element in 
the current Web Applications spec. Is there interest in expanding 
actionable elements in this way?


Regards,
Colin Lieberman