Re: [whatwg] HTML 5: Wording of license link type is too narrow
On Sat, 2 Feb 2008, Dave Hodder wrote: The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. Sure, the license can cover things other than copyright. But it is primarily a copyright license, and that is the part that the rel=license keyword is referring to. The copyright license being part and parcel of a bigger license isn't a problem, IMHO. In particular, we don't want people to use rel=license to point to trademark licenses or patent licenses that _aren't_ copyright licenses. On a related note, should the copyright keyword really be a synonym for license? They seem to have distinct purposes to me: meta name=copyright content=Copyright 2009-2010 Example.com Enterprises link rel=license href=http://www.apache.org/licenses/LICENSE-2.0; type=text/html The namespace of the name and rel attributes is distinct. The name=copyright above doesn't fall into the scope of the part of the spec that defines rel=copyright as a synonym for rel=license. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5: Wording of license link type is too narrow
Ian Hickson wrote: On Sat, 2 Feb 2008, Dave Hodder wrote: The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. Sure, the license can cover things other than copyright. But it is primarily a copyright license, and that is the part that the rel=license keyword is referring to. The copyright license being part and parcel of a bigger license isn't a problem, IMHO. Agreed. In particular, we don't want people to use rel=license to point to trademark licenses or patent licenses that _aren't_ copyright licenses. Why not, what's the downside? What is the correct way to mark up links to, say, a trademark license _not_ covering copyright, given the current draft of the spec? -- Arne Johannessen
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 27 Feb 2008, Shannon wrote:
With the capabilities of modern browsers it seems to me that a specific
tag for hyperlinks is no longer required or useful and could be
depreciated with a more versatile global link attribute.
This has been proposed several times but several browser vendors have
indicated that they would not implement such a feature.
In practice, if we look at existing global attributes, we find that
historically only attributes that have a very orthogonal effect on the
document are successful. For example, class=, lang=, and id= have no
direct effect on the element, style= and dir= are equivalent to CSS
rules, and title= is implemented as an orthogonal UI feature.
The one attribute that _does_ have any direct effect on the element,
contentEditable, is fraught with problems, and has caused us no end of
hassle for years.
I believe that hyperlinks now have more in common with attributes such
as ONCLICK than they do with tags since in web applications links often
define actions rather than simply being a part of the document
structure. The A tag would continue its role as an anchor but the HREF
attribute would be phased out making A a more consistent element
(since links and anchors are really quite separate concepts). Below is
an example of the proposed link attribute in action:
lia href=foo.htmlFoo/a/li
could be written as:
li link=foo.htmlFoo/li
No useful semantic information is lost however the markup is cleaner and
the DOM drops an unnecessary node (which could speed up certain
applications).
I am not convinced that this clutter is a big problem that we need to
solve.
This proposal would circumvent A's main limitation which is its
requirement to not wrap block-level elements or 'interactive' content.
The HTML5 draft requires it wrap 'phrasing content' (essentially
paragraphs) and not wrap 'interactive' content (such as other
hyperlinks) however I see no reason why a link attribute should require
these limits. Links would simply cascade as in the following example:
table link=alphabet.html title=Alphabetical List
tr
tdA/td
tdB/td
td link=c.html title=More about CC/td
tdD/td
/tr
/table
(Note that the ul or ol elements would be far more appropriate
elements here.)
I don't think that making an entire list into a link is really something
that is useful from a usability point of view.
In the example above clicking anywhere on the table except 'C' brings up
a generic page, whereas 'C' has dedicated content. The following nested
links would also be valid:
span link=foo.htmlclick anywhere on this line except b
link=bar.html title=Go to bar insteadhere/b to visit foo./span
That seems like terrible UI.
The link attribute would make adding hyperlinks to DOM nodes easy:
node.link = 'http://foo.bar.baz'; /* Create a hyperlink on an element */
nodes_with_a_link = document.getElementsByAttribute('link'); /* Get all links.
This method doesn't exist in the draft but can be written in javascript using
iterators */
Again, turning individual elements into links doesn't seem like a big
problem. DOM ranges with selectNode() and surroundContents() could easily
be wrapped in a utility function if that was really needed, and it would
even allow you to linkify spans of text rather than only elements.
I believe a link attribute would be a significant improvement to HTML.
The only reasons I can think of not to add this would be the added
complexity for browsers and authors during the transition period. The
advantages include less markup, simpler DOM structure, nested
hyperlinks, onclick fallbacks and better consistency in the spec.
I don't really understand what is more consistent than using href= on
a, area, and link. I further don't think that nested hyperlinks are
a good idea. onclick fallbacks can already be done using a, which also
provides a better user experience on existin UAs. The remaining advantages
are definitely not, IMHO, outweighed by the significant costs.
Being such a common element web authors will probably keep using a
href for many years to come regardless of the standard but that should
not be a problem since a href and link should coexist quite easily in
valid HTML. Once awareness has spread then future drafts could
depreciate the href attribute on anchors.
I think we're adding enough new features that we shouldn't be adding
features that don't really add anything substantial.
On Thu, 28 Feb 2008, Shannon wrote:
FAQ: * Browser vendors have reported that implementing it would be
extremely complex.
I find this claim incredible.
To be blunt, it doesn't matter. If the browser developers say no, there's
not much point trying to change their mind, it just causes them to ignore
us. We only have any power so long as we tell them to do things they are
willing to do -- when we start telling them to do things that they are not
Re: [whatwg] HTML 5: Wording of license link type is too narrow
The correct markup for a link trademark license would be A HREF=tmlic.html /trade;/A A trademark license does not apply to a Web page. It may of course apply to the product described on the page but such information is meaningless to HTML spiders and publishing tools; information an HTML-ignorant end user is expected to make use of should be exposed in the language she understands, not with specially dedicated HTML markup. That is, of course, IMHO - I am not a lawyer. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arne Johannessen Sent: Wednesday, May 28, 2008 10:24 AM To: Ian Hickson Cc: WHAT WG List; [EMAIL PROTECTED] Subject: Re: [whatwg] HTML 5: Wording of license link type is too narrow Ian Hickson wrote: On Sat, 2 Feb 2008, Dave Hodder wrote: The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. Sure, the license can cover things other than copyright. But it is primarily a copyright license, and that is the part that the rel=license keyword is referring to. The copyright license being part and parcel of a bigger license isn't a problem, IMHO. Agreed. In particular, we don't want people to use rel=license to point to trademark licenses or patent licenses that _aren't_ copyright licenses. Why not, what's the downside? What is the correct way to mark up links to, say, a trademark license _not_ covering copyright, given the current draft of the spec? -- Arne Johannessen
Re: [whatwg] HTML 5: Wording of license link type is too narrow
On Wed, 28 May 2008, Arne Johannessen wrote: In particular, we don't want people to use rel=license to point to trademark licenses or patent licenses that _aren't_ copyright licenses. Why not, what's the downside? It dilutes the point of the feature. The idea is to provide a way for tracking pages that are covered by a particular copyright license. What is the correct way to mark up links to, say, a trademark license _not_ covering copyright, given the current draft of the spec? Something like: psmallSee our a href=trademark.htmltrademark license/a./small/p In practice it's a non-issue since people rarely have Trademark licenses. Same with Patent licenses. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] The sizes= attribute for rel=icon
On Thu, 8 May 2008, Martin Atkins wrote: That isn't to say that media queries shouldn't be allowed, though, and if people use them then they should work, if the UA supports them. Would it not be better to explitly say that media queries are not appropriate for this, for interoperability? I'd rather not preclude that people implement support for it, I just don't want such support to be required. Sometimes we get lucky and things like this take off, at which point I'd be more than happy to require it. :-) 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 don't know what link rel type uses disabled, but I would have had the same objection to that. rel=stylesheet. If the meaning of title is something different for stylesheets than for other link rel types then that was an inappropriate use of that attribute as well. It's too late to change it now, but that's no reason to continue overloading generic elements/attributes with special cases. I don't think the overloading in this case is a big deal. It's not like object, it's not even as bad as input. link is also interesting in that unlike input type=... rel can contain several values. Is it conforming to use [sizes] on a link element that contains both icon and a another, non-icon keyword? Sure. What about a rel=icon ... width=... height=... ? rel=icon doesn't apply to a href. Finally, what is the process for contributors to the RelExtensions page to include extension attributes? They can't. 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/*.) On Fri, 9 May 2008, Kornel Lesinski wrote: If multiple icons are provided, the user agent must select the most appropriate icon according to the media and sizes attributes. If there are multiple equally appropriate icons, user agents must use the first one declared in tree order. Does this disallow composing .ico files from multiple separate files? UAs like Fluid or Prism can't know which sizes OS is going to use, so all valid ico sizes are 'equally appropriate'. Sure, the OS just becomes part of the UA in that case. The effect is the same. Also this algorithm doesn't match current browser behaviour, is this intentional? 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. I've changed the spec to say to use the last one specified in case of ties. 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 like the any keyword. SVG icons are scallable, but it's not the same as being usable at any size. For example Tango icons project provides PNG for 16, 22 and 32px icons in addition to SVG, because lines and finer details in SVG become illegible at small sizes. The spec allows the UA to make that distinction. Does the specified size imply that UA is required to display icon at given size only? (i.e. is any obligatory to have icon scaled at all?) The spec doesn't say what the UA is to do with the icon. What if sizes attribute is absent? I've clarfieid this case. On Thu, 8 May 2008, Ernest Cline wrote: Mainly, I am troubled by the statement: The keywords specified on the sizes attribute must not represent icon sizes that are not actually available in the linked resource. No matter what the spec says, I think we can all agree that once this enters the real world there will be times when the icon size given is wrong. So what to do? I've added a requirement in the spec that if an icon is found unsuitable, the next one must be tried. On Thu, 8 May 2008, Aaron Boodman wrote: I agree that mismatches will occur in the real world. I think it can be left to the UA as to what to do in that case,
Re: [whatwg] The sizes= attribute for rel=icon
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.)
Re: [whatwg] The sizes= attribute for rel=icon
On Wed, 28 May 2008 13:07:50 +0100, Ian Hickson [EMAIL PROTECTED] 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. 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). -- regards, Kornel Lesiński
[whatwg] Online whitelist problem
Hi, one problem with the online whitelist in cache manifest files is that it matches on whole URLs only. This makes embedding for example Google Maps into a web app difficult, since you want to allow urls like http://maps.google.com/maps/vp?spn=0.040888,0.085831z=13key=ABQIzr2EBOXUKnm_jVnk0OJI7xSosDVG8KKPE1-m51RBrvYughuyMxQ-i1QfUnH94QxWIa6N4U6MouMmBAvp=37.4419,-122.1419 http://maps.google.com/maps?file=apiv=2key=ABQIzr2EBOXUKnm_jVnk0OJI7xSosDVG8KKPE1-m51RBrvYughuyMxQ-i1QfUnH94QxWIa6N4U6MouMmBA http://mt0.google.com/mt?n=404v=ap.74hl=svx=1316y=3176zoom=4s=Gali http://mt1.google.com/mt?n=404v=ap.74hl=svx=1315y=3175zoom=4s= http://mt1.google.com/mt?n=404v=ap.74hl=svx=1315y=3177zoom=4s=Ga http://mt2.google.com/mt?n=404v=ap.74hl=svx=1316y=3175zoom=4s=Gal http://mt2.google.com/mt?n=404v=ap.74hl=svx=1316y=3177zoom=4s=Galil http://mt3.google.com/mt?n=404v=ap.74hl=svx=1315y=3176zoom=4s=G and it's especially a problem since you don't know beforehand what URLs to allow. Maybe the whitelist needs to be extended to do host matching or maybe we need another solution. Anders
