Ian Hickson wrote:
In general I agree that attributes are not a scarce resource, but if you
need to add use-specific attributes to a supposedly-generic element I
think that indicates that the generic element is inappropriate for the
use-case.
I disagree. Look at input, for instance.
I wouldn't have designed input as it is either. It seems arbitrary
(and initially, confusing) to me that most form elements share one
element but then a random handful have their own custom elements. (I
guess you might argue, though, that textarea and button ought to be
input types rather than the other way around.)
I don't know what link rel type uses disabled, but I would have had
the same objection to that.
rel=stylesheet.
Without wishing to take this thread off on a tangent (in other words,
feel free not to address this here except as relates to the discussion
at hand) 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.
(In other words, I don't find the disabled attribute on LINK to be a
compelling argument for overloading elements either.)
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, 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?
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!)
On Fri, 9 May 2008, Kornel Lesinski wrote:
I did a quick test with a bunch of random favicons:
* Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide
Leopard's monsterous 300KB icons) and displays last icon loaded,
* Firefox 3b5 picks last icon regardless of attributes. It loads all icons
when I reload page after restoring session.
* WebKit nightly and Fluid pick last icon that has type attribute (even if
type is bogus), or just last if none have type.
[snip]
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.)
