[whatwg] Link-related feedback

[Ian Hickson]

On Wed, 28 May 2008, Martin Atkins wrote:
> 
> [regarding <link rel=stylesheet> and .disabled]
>
> I wonder what use-case motivated that attribute that couldn't have been 
> satisfied by merely removing the LINK element from the DOM. Or, if you 
> wish to attack it from the other direction, why a generic solution for 
> causing browsers to temporarily ignore *any* HTML element (a use case 
> for which might be pop-up dialogs that are hidden at certain points) 
> wasn't more appropriate.
> 
> Also, I note that the spec as it currently stands defines "disabled" 
> only as a property of the HTMLLinkElement and not as an attribute of the 
> LINK element. I don't know if this was intentional. Of course, I could 
> very well make the same objection about a type-specific property on a 
> class being better implemented by creating a new class.

The spec merely describes what the implementations and earlier DOM specs 
do and say.


> > > Finally, what is the process for contributors to the RelExtensions 
> > > page to include extension attributes?
> > 
> > They can't.
> 
> Given that you obviously consider it useful for third-parties to be able 
> to introduce new rel values without changing the HTML5 spec

There have been convincing arguments made along these lines, yes. I'm not 
sure I would say that I think it's a good idea personally...


> and that you also obviously consider it useful for certain rel values to 
> carry additional attributes, I find it likely that some of these 
> third-parties will also find it useful to introduce additional 
> attributes. Would you not agree?

So far in ten years, we've only had one rel value that needed a new 
attribute. I think at that rate, we can rely on such extensions going 
through the normal spec extension mechanism rather than needing an 
expedited extension mechanism (which is what we have for rel values).


> > > > > <link rel="icon" type="image/gif; width=24, height=24" 
> > > > > href="...">
> > > >
> > > > This doesn't really work because we would need to add parameters 
> > > > to types we might not yet know. It also results in potentially 
> > > > complicated parsing rules, which I don't think people would get 
> > > > right. (See the comments I made for media queries.)
> > >
> > > Presumably this would be defined (if at all) for everything under 
> > > "image/", just as "charset" is defined for everything under "text/". 
> > > (In theory, at least.)
> > 
> > Getting the relevant RFCs changed would likely be non-trivial. (Though 
> > we should probably look into it, actually, to fix text/*.)
> 
> Given that (for now, at least) these type attributes would be of little 
> use outside of HTML, could HTML not define them itself? Sure, it's a bit 
> of a layering violation, but I would put it in the same boat as 
> modifying MathML/SVG so that it works inside HTML: you just reference 
> the bits of the other spec that suit you, and make your own exceptions, 
> right? (loud objections from the MathML guys notwithstanding, of course. 
> The MIME type RFC isn't authored by a W3C working group, so they won't 
> find it so easy to complain!)

We're not changing MathML and SVG either. As you say, it would be a 
layering violation.


> > On Fri, 9 May 2008, Kornel Lesinski wrote:
> > > 
> > > I'm afraid that this could cause trouble (every visitor downloading 
> > > icon that's 20–300 times larger than typical favicon). Why not use 
> > > rel=application-icon or rel=appicon?
> > 
> > I don't understand the question.
> 
> I don't know exactly what Kornel was asking, but this seems to be a 
> backward-compatibility concern. When given the following:
> 
> <link rel="icon" sizes="16x16" ... />
> <link rel="icon" sizes="512x512" ... />
> 
> ...current Opera will download both, which is suboptimal however you 
> look at it. Current Firefox, though, will presumably download the 
> 512x512 version in preference to the 16x16 one even though its icon slot 
> is (usually) 16x16 pixels.
> 
> I guess this concern would be solved (aside from Opera's behavior) if 
> the spec were to say that a 16x16 icon, if specified, should be the last 
> one listed for compatibility with legacy browsers.
> 
> (Also, a 9.5 beta tester should probably inform Opera of that issue if 
> they aren't already aware of it.)

I think it would make sense for an authoring guide to mention this, but I 
don't think we need to saddle the language with this requirement forever. 
This isn't a huge deal really.


On Wed, 28 May 2008, Kornel Lesinski wrote:
> 
> <link rel=icon> is currently used for favicons. Favicons are expected to 
> be small (in byte size). Current browsers always download favicons on 
> every website.
> 
> If page author adds high-quality image using rel=icon (like Vista's 
> 100KB icon or Leopard's 300KB monstrosity), it may significantly 
> increase site's traffic (these icons will be downloaded by every visitor 
> rather than only those who create a shortcut).
> 
> e.g.:
> <link rel=icon sizes=16x16 href=tinyicon.png>
> <link rel=icon sizes=256x256 href=hugeicon.ico>
> 
> In current browsers this will not work as expected - browsers will 
> download the big application icon, which is going to be order of 
> magnitude larger (in byte size) than a favicon.
> 
> Using rel=application-icon instead of rel=icon would avoid this problem. 
> Another solution would be to suggest that authors specify favicon as 
> last in the tree order (example it the spec lists favicon first).

The idea is that this icon _will_ indeed be used as the favicon. Icons are 
getting bigger (though not 300KB bigger yet, surely). Screens are becoming
higher resolution displays. 16x16 won't really cut it any more.



On Wed, 9 Jul 2008, Gervase Markham wrote:
> 
> Some WHAT-WG participants may be aware of Link Fingerprints, which was a
> way to embed the hash of a file in a link to that file, thereby ensuring
> that the link user got only the exact file the link creator was
> referring to.
> http://www.foo.com/file.zip#!sha256:09F9...
> 
> Implementing this idea was a Summer of Code project for Mozilla in 2007,
> but the draft RFC received a chilly reception on various IETF mailing
> lists. I have therefore reformulated Link Fingerprints as a simple
> extension to HTML. This makes it useful in a smaller set of contexts,
> but still hits the major use cases.
> <a href="http://www.foo.com/file.zip" checksum="sha256:09F9...">File</a>
> 
> The updated spec is here:
> http://www.gerv.net/security/link-fingerprints/
> Please read it for more detailed aims, rationale and behaviour. It is
> now very similar to the microformat proposals here:
> http://microformats.org/wiki/hash-examples
> 
> Would the WHAT-WG be interested in looking at standardising this?

It's not clear to me that this idea would work in practice. Why would 
authors not get the fingerprint wrong more often than attacks being 
caught? This is especially serious since the feature's failure mode 
(browser A incorrectly says there's a problem, browser B downloads the 
file fine and the file appears to work fine) looks the same as a 
successful trojaning (browser A accurately says there's a problem, browser 
B downloads the file fine and the file appears to work fine, though with 
trojan code running unbeknownst to the user).

Also, I don't really understand the attack scenario it is protecting 
against. If the idea is that a file on site A will include a fingerprint 
that protects against a file on site B being replaced with a trojan, this 
assumes that either the person uploading the file will be tricked into 
using a different file, or they will intentionally upload another file, or 
site B will be attacked and a new file put in its place.

However, all three of these scenarios seem like they are still vulnerable. 
In the first case, surely the person uploading the file and updating the 
fingerprint would just accidentally use the fingerprint of the trojan 
file; in the second case, they would presumably do it on purpose; and in 
the third case, why wouldn't the attacker just attack the site with the 
fingerprint instead? Nothing in the attack scenario would lead us to 
assume that the site with the fingerprint is less vulnerable.

If you disagree with this analysis, I would recommend demonstrating this 
feature's viability by implementing it (using a vendor prefix if you use a 
new attribute, e.g. -moz-fingerprint="...").



On Thu, 31 Jul 2008, James Graham wrote:
> > On Wed, 30 Jul 2008, James Graham wrote:
> > > I think <table><a><tr> 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.

The failure more isn't that bad (the link just doesn't show), so I don't 
think it's that bad.


On Mon, 4 Aug 2008, 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.

On Mon, 4 Aug 2008, Jonas Sicking wrote:
> 
> 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.

On Mon, 4 Aug 2008, Simon Pieters wrote:
> 
> 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.)

It would also mean any element could be in the :link/:visited dynamic 
update list, it would mean that even elements like <frameset> and <tr> 
could be links, it would mean putting all the various accesors on all 
elements (like .hash, .search). I'm not really sure how we'd deal with 
clashes of property and attribute names.

I'm sure it can be done, technically; but the cost would be high.

Having said that if all the browser vendors are ok with it, then it's 
certainly something I'd be open to speccing out -- I think what would be 
most helpful here is an experimental implementation showing it can be 
done, so that we can get a better idea of what problems we'd run into.


On Wed, 6 Aug 2008, Sean Hogan wrote:
>
> 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

It's an idea, but it doesn't seem especially more compelling than just an 
onclick="" that just invokes .click() on the first descendant <a> element.



On Sun, 19 Oct 2008, Håkon Wium Lie wrote:
>
> I'd like to have a simple way of using <button> along with <a> to create 
> pretty links. This markup works in Opera, Mozilla, and Webkit:
> 
>   <a href="http://www.w3.org/"><button>W3C</button></a>
> 
> but it's not valid HTML5 it seems. I propose to make it valid.

The problem with this is that it would be very confusing if the button was 
in a form.

If the goal is to make a link look like a button, this seems to be a 
presentational concern. I would recommend solving this issue from CSS. In 
particular, the 'appearance' property can make any element into a 
button-like object.

Having said that, in HTML5 you can now do:

   <form>
    ...
    <button action="http://www.w3.org/">W3C</button>
    ...
   </form>

...to create a button that acts like a link. Indeed even in HTML4 you can 
today do:

   <form action="http://www.w3.org/">
    <button>W3C</button>
   </form>

...to get the effect you describe.


On Mon, 24 Nov 2008, Philipp Serafin wrote:
> 
> I've noticed that the paragraph on the MetaExtensions wiki page[1] still 
> lists the Microformats process as the only way to get a keyword 
> approved.
>
> The equivalent paragraph on the RelExtensions page[2] had been changed 
> to "... or must be defined by a W3C specification in the Candidate 
> Recommendation or Recommendation state." some time ago.
>
> Shouldn't both paragraphs be identical, or are @rel and <meta> values 
> really handled differently?

I've made them more consistent. I was also going to change the spec to 
match, but I've decided to not do so, so that we don't need to update the 
spec when the community decides to change the mechanism for agreeing on
new values.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'