Re: [whatwg] [html5] r4029 - [e] (0) Example of section use without article.
On Tue, 29 Sep 2009, Simon Pieters wrote: + + prelt;!DOCTPE Htmlgt; s/DOCTPE/DOCTYPE/ Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] the cite element
On Mon, Oct 5, 2009 at 7:13 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 22 Sep 2009, Jim Jewett wrote:
On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 16 Sep 2009, Erik Vorhes wrote:
On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson i...@hixie.ch wrote:
Unless there is some semantic value to the name being more than
and with the removal of the dialog element (of which I was unaware
when I sent my last message) makes a compelling case for the
re-expansion of cite for dialog.
I disagree with the above statement. I believe that the current HTML5 spec is
heading in the right direction by narrowing the meaning of the cite element
compared to its ambiguous use in HTML documents in the past. Overloading
the meaning of the cite element further by using it to distinguish
speaker's names
would not only add ambiguity but would require developer's (who want to honor
typographical convention) to undo the default italics styling that
would be applied to
the speaker's name when enclosed by cite tags.
That almost sounds as though the real specification were:
Book Title, even if you aren't quoting or
paraphrasing anything -- this isn't really about
citations; we just call it cite for historical reasons.
That's exactly what HTML5 says, yes.
I feel it is an improvement to HTML that the cite element is being focused to
specify the title of a work. It is however unfortunate that the element's name
is 'cite' for legacy HTML reasons. I would much prefer the name of the
cite element
be reserved for a purpose equivalent to the use of \cite{} in LaTeX.
However, given the ambiguity of the HTML4 specification as to the correct usage
of the 'cite' element, I'm wondering if we shouldn't align the 'cite'
element with a more
intuitive use case matching that of satisfied by \cite{} in LaTeX. And
introduce a new inline
element called 'tow' (title of work) or 'tor' (title of reference),
for example, to explicitly
specify the title of a work.
For example,
pI enjoyed reading towEast of Eden/tow./p
instead of
pI enjoyed reading citeEast of Eden/cite./p
In fact, the two examples given in the HTML4 spec for using cite are
both incorrect
according to the current HTML5 definition:
- As CITEHarry S. Truman/CITE said,
- More information can be found in CITE[ISO-]/CITE.
Note, the second example is being used to cite a source with a
displayed bibliography
entry key of ISO-, which is not the title of the work; rather an
identifier for the work.
So using cite in the LaTeX sense, you may have HTML5 markup that looks like:
A proof of Theorem 2.4 is provided in cite
href=#local_bib_keytowSurvey of Foo Theory/tow/cite.
or
Given that the existence of foo we infer bar cite
href=http://example-math.org/bibliography#ABC;[ABC, p.
47--48]/cite.
Admittedly, besides the improved legibility of the proposed cases, I'm
sure the more general a tag is just as sufficient.
Ships get i. Search for ship name in the spec (it's mentioned twice).
By the way, what is the reasoning in the HTML5 spec for stating that
ship names should not be
marked up with cite but should use i instead?
I guess I'm saying, why are ship's not considered works?
Merriam-Webster's definition:
7 a : something produced or accomplished by effort, exertion, or
exercise of skill this book is the work of many hands b : something
produced by the exercise of creative talent or expenditure of creative
effort : artistic production an early work by a major writer
I would say a ship fits this definition and is certainly on par with
other large engineering/sculpture works such as the Statue of
Liberty--which is the title of a work.
Here are three references that indicate specifically that Ship names
receive the same typographic treatment as other titles of works.
http://grammar.ccc.commnet.edu/grammar/italics.htm
http://grammartips.homestead.com/titles.html
http://englishplus.com/grammar/0113.htm
Let me know if I'm missing something as to why ship names should not
be surrounded by cite tags.
Regards,
Tim Eddo
Re: [whatwg] Bibliography Markup in HTML5
On Mon, Oct 5, 2009 at 7:51 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 27 Sep 2009, tjeddo wrote: I am surprised at how little concern there seems to be over the lack of bibliography markup in HTML5. There's a lot of concern, but it was deemed that microdata is a better way of addressing this than specific elements. Thanks for your response. After reviewing the info on microdata, I certainly agree that microdata would be a great fit for marking up bibliographies and their entries. I do hope that a controlled vocabulary is worked out and gets widely adopted... but I recall this issue was already discussed at length. What if HTML5 specified this approach--except that in place of the dl (definition list) tags, a collection of entries would be contained between bibliography tags? That is, the above example would look as follows: bibliography ... dt id=refsRFC5322[RFC5322]/dt ddcitea href=http://www.ietf.org/rfc/rfc5322.txt;Internet Message Format/a/cite, P. Resnick. IETF, October 2008./dd ... /bibliography The value here is the elimination of ambiguity What ambiguity? In my example scheme, a parsing program that encounters a bibliography section would be able to determine (by context) that the dt and dd elements encountered within represent bibliography entries. Just like a parsing program that encounters a figure section can determine that a dt element contains the caption for the figure. However, if dt and dd are encountered simply within a dl element; then no additional semantic information can be determined. It would have been more appropriate if I said that ambiguity is reduced in my example scheme (not eliminated). and that a number of new inferences can now be drawn by user agents. With the dl tags, the interpreting agent can only determine that there is a definition list containing term/definition entries. Whereas, in the context of a new bibliography section element, user agents can unambiguously interpret the 'dt' element to be the displayed content that humans identify a bibliography entry by (e.g., [RFC5322] in the example given). Why is this valuable? How do you expect browser vendors to change their interface to use this? Why would it not be better to have a microdata vocabulary for this? In my understanding, microdata certainly seems like a sufficient way to handle bibliography entries--once again, hoping that a standardized vocabulary develops. The scheme I discussed about introducing a 'bibliography' element and reusing the 'dt' and 'dd' elements within, I simply felt was consistent with the introduction of other new HTML5 elements describing the pieces of a virtual document (e.g., article, section, figure, aside, etc.). Additionally, the scheme consistently reused the elements 'dt' and 'dd' in the 'bibliography' context just as they are reused in the new 'figure' and 'details' context. Although, I have to admit I'm not sure I'm a fan of this element overloading as opposed to introducing explicit tags to cover these concepts when appropriate. But I do understand that HTML5 is constrained by legacy HTML and also that microdata is another way to work around these constraints. I'm not arguing that microdata isn't the best approach here; but it should be considered that first class elements are more legible than microdata. And I'm sure this is why many of the new HTML5 elements are not implemented as microdata. I'm just raising ideas here. Regards, Tim Eddo
[whatwg] HyBi BoF: on Tuesday, November 10
Hi there, accordingly to the provisional IETF 76 agenda in Hiroshima (https://datatracker.ietf.org/meeting/76/agenda.html) the HyBi BoF will be on TUESDAY, November 10, 2009 at 1300-1500 during the Afternoon Session I We are now working on a clean version of the Charter Proposal that will be posted during the next days and on the Agenda so all the proposal and comments are welcome! cheers Salvatore Loreto www.sloreto.com * *
Re: [whatwg] document.head
2009/9/21 Garrett Smith dhtmlkitc...@gmail.com: It wasn't very long ago though that in Opera for example, head wasn't guaranteed to be the first child of the documentElement. But, that'll work now and is pretty good. The documentElement.firstChild cannot be expected to be head. It could be a text node. For example:- html head ... the first child node of HTML looks like a textNode with the value \n\n\u0020\u0020. You might think so. However, as Michael stated above Opera used to do this, and it broke a number of websites that expected documentElement.firstChild to be HEAD no matter what the actual markup looked like. So we had to implement a somewhat magic firstChild on documentElement and I expect other browsers had to too (as your testing seems to confirm, more or less). Which reminds me, this peculiarity should possibly be documented in HTML5 :-) . -- Hallvord R. M. Steen
Re: [whatwg] document.head
On Tue, 06 Oct 2009 16:02:58 +0200, Hallvord R M Steen hallv...@gmail.com wrote: You might think so. However, as Michael stated above Opera used to do this, and it broke a number of websites that expected documentElement.firstChild to be HEAD no matter what the actual markup looked like. So we had to implement a somewhat magic firstChild on documentElement and I expect other browsers had to too (as your testing seems to confirm, more or less). Which reminds me, this peculiarity should possibly be documented in HTML5 :-) . This is only about what happens during parsing right? I.e. if you create a DOM with a text node there firstChild would get it as expected. I think that is already covered. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] document.head
You might think so. However, as Michael stated above Opera used to do this, and it broke a number of websites that expected documentElement.firstChild to be HEAD no matter what the actual markup looked like. So we had to implement a somewhat magic firstChild on documentElement ..though less magic than I remembered - it only skips text nodes, not comments.. And perhaps what happens is that the text node is put inside body instead? I'd have to do some more testing to tell what browsers actually do.. -- Hallvord R. M. Steen
Re: [whatwg] document.head
On Tue, 06 Oct 2009 10:14:13 -0400, Hallvord R M Steen
hallv...@gmail.com wrote:
You might think so. However, as Michael stated above Opera used to do
this, and it broke a number of websites that expected
documentElement.firstChild to be HEAD no matter what the actual
markup looked like. So we had to implement a somewhat magic firstChild
on documentElement
..though less magic than I remembered - it only skips text nodes, not
comments.. And perhaps what happens is that the text node is put
inside body instead? I'd have to do some more testing to tell what
browsers actually do..
Here's an example to play with:
document.documentElement.firstChild results:
!DOCTYPE html
html!--Not head --head
title/title
script
window.onload = function() {
var de = document.documentElement;
var fc = de.firstChild;
alert(fc);
de.insertBefore(document.createTextNode(test), fc);
alert(de.firstChild);
};
/script
/head
Safari, Opera, and Firefox with HTML5 parser enabled:
alert1: comment node
alert2: text node
IE8 and Firefox:
alert1: head element
alert2: text node
document.head definitely solves that mess.
--
Michael
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
Boris Zbarsky wrote: On 10/5/09 12:48 PM, Mark Kaplun wrote: I have only learned now that there is a text/palin option that I have never heard of, so maybe I'm wrong, but my impression is that there are only two forms of form, a textual and a file upload. IMHO the browser can inspect the form before submitting it and decide by itself what is the correct encoding to use. You can use multipart/form-data with a form that doesn't include any file uploads (and people do this). Presumably they might have reasons for this (e.g. they happen to have a sane multipart MIME parsing library and don't want to deal with the url-encoding mess the application/x-www-form-urlencoded option produces. -Boris Fair enough. Can the spec be changed in regard to the default encoding, and make it depend on the content of the form instead of being application/x-www-form-urlencoded, and then like today, the enctype attribute can be used to override the default encoding? Mark. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.3/2414 - Release Date: 10/04/09 18:42:00
Re: [whatwg] the cite element
On Mon, Oct 5, 2009 at 9:13 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 22 Sep 2009, Jim Jewett wrote: On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 16 Sep 2009, Erik Vorhes wrote: On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson i...@hixie.ch wrote: Unless there is some semantic value to the name being more than just a name, yes. Is there? Yes What is it? cite points to a primary source of the statement, as opposed to an someone merely named by the statement. I hate to be so repetitive, but why is that beneficial? What is the semantic value of this? Is there as much semantic value in pointing to the primary source of a statement as there is in knowing that the word earth refers to the planet and not the dirt, for example? If so, what is that extra value? Identifying speakers and other sources of attribution have multiple use-cases, as identified previously to this list. Such uses are often extra-contextual, unlike your example of earth. I don't know how otherwise to respond to such laughably obvious reductio ad absurdum arguments. and with the removal of the dialog element (of which I was unaware when I sent my last message) makes a compelling case for the re-expansion of cite for dialog. Why? dialogues and transcripts and credits and theatrical scripts are all arguably too fine-grained for a citation, as opposed to a label or attribution, but they are certainly real use cases where the attribution is important. Why? This is not a rhetorical question, I'm trying to get to the use case that means that there is an actual benefit to what you are asking for. Just saying that it's important doesn't say _why_ it is important. I'm not denying that it is important, I'm just trying to work out _why_, so that the proposal (e.g. to use cite for this) can be properly evaluated. What does cite do that you want? It may not need to be cite, per se, but that is the element that has been used in examples of multiple kinds of quote + attribution markup patterns. And since the WG has a general aversion to creating new elements (except when it doesn't), using cite makes the most sense. To me, recommending b or i or span for such contexts is a nonstarter, as these all appear to be designated for marking up text without conveying any extra importance. The desire is to have speakers' names and other sources of attribution marked up in such a way that sets them apart from the surrounding context. Especially in the cases of dialog and transcription, their being special is important. For example, listen to any of Nina Totenberg's reports on US Supreme Court proceedings, or read just about any printed play text in existence. Above other sources of attribution, it is important for speakers' names to be marked up as distinct from its surrounding context. Moreover, this markup is not something that can be properly conveyed by any element whose primary function is presentation- or typographic-only. I don't buy that at all. It's just one way that people write dialogs, but as far as I can tell this is perfectly adequate: pMe: Can I say something?/p ...and you need neither q nor cite. I really feel that you are trying too hard to solve a problem that really doesn't exist here. Surely you jest. Have you ever read a play? In every instance I have run across, speakers and their words are clearly demarcated (not to mention stage directions, etc. I've started asking people what they think the errors are in the following snippet: article h1Welcome to my home page/h1 pMy name is citeBob Smith/cite./p pI like the book citePandora's Star/cite./p pWhat do you think?/p article citeJames Smith/cite pI'm with you citeBob/cite!/p /article article citeFred/cite pciteJames/cite wrote:/p blockquotepI'm with you citeBob/cite!/p/blockquote pBut I disagree, I think citePat/cite's blog post is better. /article /article ...but frankly I'm having trouble working out which you are proposing to have valid and not, which is not a good sign. Given that I don't see the use case of marking up any of the cites in the above except the book title (which would be styled differently), I really don't see the point of having this level of complexity. Your example hardly dignifies a response, but here goes: 1. The proposal, as far as I can tell, is to allow cite (or some nonexistent element whose name would likely be less logical) to mark up text for attribution, which often would be a name. I don't believe *anyone* is arguing that every name should be marked up with cite. Who are you trying to argue against here? You're not arguing against those of us advocating for additional allowable uses for cite. 2. If you want to play the reductio ad absurdum game, I propose we eliminate article from the specification, because some stupid content author might try to create a document with the following markup:
[whatwg] Experiments in end-tag attributes
The html-parsing section of the spec and the browsers I've tested [1] seem to be doing the right thing, however I'd love if this was noted as a conforming pattern. Probably more testing is prudent. PROBLEM: p id=something-here [ massive bloviation and many inner tags pincluding Not-well indented p-tags /p /p !-- ad hoc solution! comment: id=something-here -- MORE ELEGANT ALTERNATIVE: p id=something-here /p id=something-here If it was noted as specifically conformant, this could possibly help parsers in some cases, including the human variety. cheers, Schuyler Duveen [1] Firefox, Safari, Chromium linux trunk, IE8
[whatwg] 4.10.5 - value of hidden inputs
If we have this page:
htmlbody
input type=hidden value=foo id=i
script type=text/javascript
var i = document.getElementById('i');
i.value = 'bar';
alert( i.getAttribute('value') );
/script
/body/html
What should the alert display? From my reading of the spec I believe it should
display 'foo'. For type=hidden, The value IDL attribute applies to this
element and is in mode value and in mode value, On setting, it must set the
element's value to the new value, set the element's dirty value flag to true
[...]. Reading the content attribute after should still return the original
'foo'.
However, Firefox, Opera, IE6, and Chrome all alert 'bar'.
If I change the type from hidden to text, then FF, Opera, and Chrome all alert
'foo', but IE6 still gives me 'bar'. This, despite both 'hidden' and 'text' are
in mode value, and so should behave the same according to the spec.
Another related test case is this one:
htmlbody
input type=hidden value=foo id=i
script type=text/javascript
var i = document.getElementById('i');
i.value = 'bar';
i.removeAttribute('value');
alert( i.value );
/script
/body/html
According to the spec, setting i.value should set the dirty value flag. This
means that when the content attribute is removed, it shouldn't affect what
i.value returns for the alert. However, Firefox, Opera, and Chrome all alert
the empty string. It seems they all have special behavior for type=hidden that
isn't specced fully.
Cheers,
kats
Re: [whatwg] the cite element
(I'm ignoring all of the unproductive back-and-forth that has occurred thus far. This is meant to start the discussion off fresh.) I was discussing the cite element with TabAtkins on IRC and I proposed analyzing the actual word 'cite'. Using it as a verb, the definition of 'cite' applies to quotes/quotations, titles, and people, depending on the context. TabAtkins noted that the first use case is so far off of legacy implementations, that it wouldn't even be worth considering for cite (especially because we have other elements that function as such). That leaves usages of 'cite' for both titles of works and authors of works. Putting aside the issue of styling for a moment, these two pieces of data both fall under the semantic meaning of 'cite'. Thus, they should fall under the semantic meaning of cite. If an author should have the need to differentiate between the two, I propose that they use cite class=title and cite class=author. Thus, I propose the following (which TabAtkins generally agrees with): Leave the default styling of cite to be italicized for legacy implementations and allow any reference to any work or author, with the granularity decided by the individual web developer. I also propose allowing parenthetical citations and footnote markers (as is used in the various W3C/WHATWG specifications) to also be marked up with cite, though I'm not sure if TabAtkins agrees with me on that point. I hope this message can help bring the discussion back to a neutral zone that will lead to an amicable resolution of this long debate. Regards, Gordon -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ http://sasha.sourceforge.net/ • http://www.yoursasha.com/
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 2:52 PM, Gordon P. Hemsley gphems...@gmail.com wrote: I was discussing the cite element with TabAtkins on IRC and I proposed analyzing the actual word 'cite'. Using it as a verb, the definition of 'cite' applies to quotes/quotations, titles, and people, depending on the context. TabAtkins noted that the first use case is so far off of legacy implementations, that it wouldn't even be worth considering for cite (especially because we have other elements that function as such). That leaves usages of 'cite' for both titles of works and authors of works. Putting aside the issue of styling for a moment, these two pieces of data both fall under the semantic meaning of 'cite'. Thus, they should fall under the semantic meaning of cite. If an author should have the need to differentiate between the two, I propose that they use cite class=title and cite class=author. Thus, I propose the following (which TabAtkins generally agrees with): Leave the default styling of cite to be italicized for legacy implementations and allow any reference to any work or author, with the granularity decided by the individual web developer. +1 for this redefinition. I believe it addresses most common non-title uses of cite without opening it up to the kind of confusion/abuse that Ian and others have been concerned about. It has the added benefit of not adding a new element to the spec. I also propose allowing parenthetical citations and footnote markers (as is used in the various W3C/WHATWG specifications) to also be marked up with cite, though I'm not sure if TabAtkins agrees with me on that point. I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? Erik
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 4:15 PM, Erik Vorhes e...@textivism.com wrote: On Tue, Oct 6, 2009 at 2:52 PM, Gordon P. Hemsley gphems...@gmail.com wrote: I also propose allowing parenthetical citations and footnote markers (as is used in the various W3C/WHATWG specifications) to also be marked up with cite, though I'm not sure if TabAtkins agrees with me on that point. I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? Erik Hmm... I hadn't given much thought to the implementation of that, as I was more worried about the other part of the debate, but I think treating cite as analogous to label in that situation is indeed a good idea. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ http://sasha.sourceforge.net/ • http://www.yoursasha.com/
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 10:45 AM, Erik Vorhes e...@textivism.com wrote: On Mon, Oct 5, 2009 at 9:13 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 22 Sep 2009, Jim Jewett wrote: On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 16 Sep 2009, Erik Vorhes wrote: On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson i...@hixie.ch wrote: I don't know how otherwise to respond to such laughably obvious reductio ad absurdum arguments. Erik, Just so you are aware in the future, reductio ad absurdum (aka proof by contradiction) is a legitimate technique used in mathematics and logic to deductively prove statements. I'm not sure your usage of that phrase is correct or common--that is, to simply call someones argument absurd. If you realize that someones argument is absurd it means you have identified at least one invalid statement in the argument. If you desired you could even prove them wrong by constructing a proper reductio ad absurdem argument. 2. If you want to play the reductio ad absurdum game, I propose we eliminate article from the specification, because some stupid content author might try to create a document with the following markup: particleThe/article rain in Spain falls mainly on articlethe/article plain./p Again. If you appropriately play the reductio ad absurdum game, then that would be a good thing. You would be proving the other person's argument wrong. I'm sure I'm wasting other peoples time too iif they've read this far; but there is probably a more productive way to discuss HTML5 topics than using insults. HTML5 topics without
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 3:31 PM, tjeddo tje...@gmail.com wrote: Erik, Just so you are aware in the future, reductio ad absurdum (aka proof by contradiction) is a legitimate technique used in mathematics and logic to deductively prove statements. I'm not sure your usage of that phrase is correct or common--that is, to simply call someones argument absurd. If you realize that someones argument is absurd it means you have identified at least one invalid statement in the argument. Apologies for the error; in both instances I meant to use slippery slope.
[whatwg] Removing rel=feed
This is an email followup from an IRC discussion long ago, at Ian's request. http://krijnhoetmer.nl/irc-logs/whatwg/20090416#l-507 # [23:30] mpilgrim test cases: http://diveintomark.org/tmp/relalternate.html and http://diveintomark.org/tmp/relfeed.html # [23:30] mpilgrim all modern browsers support the former (except google chrome, which has no feed autodiscovery at all) # [23:31] mpilgrim firefox 3 supports rel=feed # [23:31] Hixie sounds right # [23:31] mpilgrim firefox 2 does not support rel=feed # [23:32] mpilgrim opera 9.62 does not support rel=feed # [23:32] mpilgrim safari 4 beta does not support rel=feed # [23:32] mpilgrim IE8 final does not support rel=feed http://krijnhoetmer.nl/irc-logs/whatwg/20090518#l-32 # [04:45] mpilgrim i've completed my rel=feed research ( c.f. http://krijnhoetmer.nl/irc-logs/whatwg/20090416#l-507 ) # [04:46] mpilgrim i sampled 3 billion web pages from google's latest index # [04:46] mpilgrim weeding out errors like rel='RSS 2.0 feed' and false positives like rel='service.feed', # [04:46] mpilgrim i found exactly 1 page that uses rel='feed' according to specification and to the exclusion of any other autodiscovery mechanism # [04:46] mpilgrim http://seiji.asia/ # [04:47] mpilgrim and they have a visible link on their page that also links to their feed # [04:48] mpilgrim so there would be little harm in removing rel=feed support from the only browser that actually supports it # [04:48] mpilgrim and little harm in removing it from html 5 To sum up: only one browser has ever implemented rel=feed, despite it being in the draft spec for several years, and real-world usage of the feature is miniscule. I recommend removing the section called 'Link type feed' from HTML5 altogether, and redefining 'Link type alternate' in a way that does not depend on rel=feed. Cordially, -Mark Pilgrim
Re: [whatwg] the cite element
On Tue, Oct 6, 2009 at 4:15 PM, Erik Vorhes e...@textivism.com wrote: I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? How about cite cite=uri, as it would have been in XHTML 2?
Re: [whatwg] the cite element
2009/10/6 Hugh Guiney hugh.gui...@gmail.com On Tue, Oct 6, 2009 at 4:15 PM, Erik Vorhes e...@textivism.com wrote: I suppose a allows for more functionality in current UAs, but this is an interesting proposition, especially if there were a way to crosslink cite used in this way to the original source (or whatever it would point to). Would it be something along the lines of cite for=aside-id, or did you have something else in mind? How about cite cite=uri, as it would have been in XHTML 2? I don't know about others, but that just looks ugly to me (the repetition of 'cite' looks unnecessary). I know elegance isn't crucial, but given the choice between cite for= and cite cite= I'd go for the former. As a possibility though, cite could have a 'for' attribute in the same manner as a label and also support a 'src' attribute to link the element to the original source, giving: cite for=aside-id src=uri What browsers do with the src attribute can be decided later, but it could easily be used as a more semantically meaningful a tag where appropriate.
