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/
[whatwg] [Slightly OT(?)] Programmatically defined styles [Re: Superset encodings [Re: ISO-8859-* and the C1 control range]]
On 22 May 2008, at 11:40, Ian Hickson wrote:
[I wrote:]
PS: How should colour be added to tables like these in HTML5 with
neither of the attributes bgcolor and style?
Class attribute and external stylesheets. (Possibly a data-* attribute.)
I actually thought this might be one of the cases that could reasonably
and legitimately be solved using the style attribute (which was, I believe,
still absent from the draft when my PS was written), so it is interesting
to see that you think otherwise. I would like to point out that your suggested
solution would require a style sheet along the following lines:
.bg-00 {background-color: #00ff40} /* green */
.bg-01 {background-color: #02ff40}
.bg-02 {background-color: #04ff41}
/* ... */
.bg-7e {background-color: #fcff7f}
.bg-7f {background-color: #feff7f}
.bg-80 {background-color: #fffe7f}
.bg-81 {background-color: #fffc7f}
/* ... */
.bg-fd {background-color: #ff0441}
.bg-fe {background-color: #ff0240}
.bg-ff {background-color: #ff0040} /* red*/
Adding 256 classes (of which 100--200 are actually used in each document)
is certainly feasible.
However, this solution would not seem to be practical for a colour scheme
using a larger number of colours. Would your mantra remain the same
given, e.g., 256^2 or 64^3 distinct shades of colour? If not, where should
the boundary be drawn?
--
Øistein E. Andersen
Re: [whatwg] [Slightly OT(?)] Programmatically defined styles [Re: Superset encodings [Re: ISO-8859-* and the C1 control range]]
On Fri, 30 May 2008, �istein E. Andersen wrote:
[I wrote:]
PS: How should colour be added to tables like these in HTML5 with
neither of the attributes bgcolor and style?
Class attribute and external stylesheets. (Possibly a data-* attribute.)
I actually thought this might be one of the cases that could reasonably
and legitimately be solved using the style attribute (which was, I believe,
still absent from the draft when my PS was written), so it is interesting
to see that you think otherwise. I would like to point out that your suggested
solution would require a style sheet along the following lines: [...]
Adding 256 classes (of which 100--200 are actually used in each document)
is certainly feasible.
However, this solution would not seem to be practical for a colour
scheme using a larger number of colours. Would your mantra remain the
same given, e.g., 256^2 or 64^3 distinct shades of colour? If not, where
should the boundary be drawn?
I was thinking more along the lines of:
td data-value=2838../td !-- value ranges from 0..1 --
...with:
td[data-value] {
background: rgb(calc(255-255*attr(data-value)/1),
calc(255*attr(data-value)/1),
calc(127-63*abs(attr(data-value)/1-0.5;
}
...which would require some changes (in particular, adding abs() and
allowing colour calculations) to the calc() and attr() proposals, but
would be significantly better than hard-coding the colours into the
markup or having a bazillion classes.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Scoped tabindex proposal
On Thu, 31 Aug 2006, Simon Pieters wrote: Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. In general I think the better solution would be to change the tab order from CSS using CSS3UI's features, rather than changing the tabindex in HTML itself. For the rare cases where changing the tabindex is actually useful, it seems a small cost to require that the values be changed globally. It's also not that hard, you can just set all the tabindex values to increasing multiples of 100 in tree order, and then manipulate a local group by changing the values around. Basically I don't see this as something that is useful enough to warrant a new attribute. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. It seems like this would have a pretty poor back-compat story. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 This can be solved just by moving the tfoot. (Thanks to all the other people who contributed to this thread and gave good feedback. I don't have anything to add to those comments.) -- 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
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.
