| embed
| The resource identified by the link should be considered to be
| embedded in the initiating resource. This includes images and
| other media resources, as well as such resources as scripts and
| style sheets.
This needs to be better defined, although I agree with the principle.
Do I assume that this means that:
<img src="default.css"/>
...and:
<link rel="next" href="default.css"/>
...have the same effect, using HLink, as:
<?xml-stylesheet href="default.css"?>
...assuming that default.css is sent back with the text/css namespace?
Does this mean that if the MIME type is text/xml, the UA has to check
the root namespace to work out if it is a tranformation sheet (XSL), a
binding (XBL), a privacy description file (P3P) or a resource with an
embeddable content (SVG, MathML, XHTML, XSL:FO) before handing it to
the appropriate handler?
I think this would be a good thing (no more specialist linking
mechanisms!) but I think some people may find it odd -- e.g.
<style src="foo.js"/>
...runs some script while
<script src="bar.css"/>
...styles the document.
I note that this spec seems to specify the behaviour of
<script src="..."/>
...but not
<script type="text-javascript">...</script>
Is this intentional?
Similary, this spec only seems to define persistent stylesheet
linking. Can the title attribute be assumed to be able to control
whether a link to a stylesheet is alternate or not, as in other
linking mechanisms?
How is embedding defined to work with CSS? CSS3 will include features
that perform exactly the same as embed with images (and other
content), and will also have fallback mechanisms like HLink. How will
this work? Will HLink simply say that effect="embed" (and onSuccess/
onFailure) are ignored when there is rendering system involved?
CSS3 may also introduce behaviour mechanisms to control things like
link actuation, again, is this a layer above HLink which HLink defers
to? I think this (along with the DOM interface belo) would make the
most sense.
| onRequestSecondary
This is unimplementable. Typically the "secondary request mechanism"
is an item on a context menu such as "View quote source" or "View long
description". This context menu item has to be localised to the UA's
chrome language. Simply saying that an element has a secondary request
mechanism doesn't cut it.
Having said that, if HLink is designed to be a layer under a binding
or behaviour layer controlled, e.g., by CSS and scripting, then this
would be enough. However, if this is the case, you should explicitly
define the DOM interface which is to be used to trigger the primary
and secondary request mechanisms. The following would be an adequate
interface:
interface HLinkElement {
void primaryRequest();
void secondaryRequest();
};
You may like to also define return values or events that trigger at
certain appropriate times, although that would just be a bonus. I
recommend working with the DOMWG on this.
| role
How is this expected to help? Would all links be at the same level?
(At the moment, browsers such as Lynx and Mozilla handle <link>
elements' rel separately from <a> elements', because <link> elements
are assumed to be relative to the document, and <a> elements relative
to that part of the document.)
| arcrole
| See Xlink [XLINK] for description.
| label
| See Xlink [XLINK] for description.
| from
| See Xlink [XLINK] for description.
| to
| See Xlink [XLINK] for description.
I saw XLink and still have _no clue_ what these are supposed to do.
(I think they could be totally removed, myself.)
| mediaType
| This attribute may be used to specify the media type of the
| linked-to resource. A user agent may use this attribute to decide
| whether to actuate a link or not, depending on whether it can
| process a resource of the indicated type, or it may prefer to
| ignore this attribute and query the resource directly.
So all resources are assumed to have an "intrinsic media type" that
overrides the linking element's specified media type? (This would work
like all documents are assumed to have an intrinic Content-Type, and
the <link> element's type attribute is merely advisory.)
If so, I like it.
Could you reference the Media Queries spec normatively for the
contents of this attribute?
| onSuccess
Could you give a processing model and use case for the processChildren
value? I don't see how it can work.
| onFailure
This is good, but doesn't seem to be able to describe XHTML1's <img>
element's fallback behaviour (namely the alt attribute; this is also
an issue for <input type="image">) -- is this intentional, or is it an
oversight?
| The definition of the <a href="..."> element in XHTML:
This doesn't cover the charset, type, rel and rev attributes. This
should be mentioned (or fixed).
| Defining <img/> in XHTML
This doesn't cover the alt attribute.
| Defining redirection:
Do you really want to mention that? Do you even want it to be
possible? HTTP redirects are by _far_ the preferred way of doing this.
Is there a way to define a link such as the Pingback link seen in
http://www.hixie.ch/specs/pingback/pingback
...?
Otherwise, this looks like a great start. If only XLink had actually
fixed this all those years ago when it was supposed to.
--
Ian Hickson )\._.,--....,'``. fL
"meow" /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'