Re: [whatwg] the cite element

[Erik Vorhes]

On Tue, Oct 6, 2009 at 3:31 PM, tjeddo  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."

Re: [whatwg] the cite element

[Erik Vorhes]

On Tue, Oct 6, 2009 at 2:52 PM, Gordon P. Hemsley  wrote:
>
> I was discussing the  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  (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 . If an author
> should have the need to differentiate between the two, I propose that
> they use  and .
>
> Thus, I propose the following (which TabAtkins generally agrees with):
>
> Leave the default styling of  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  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 , though I'm not sure if TabAtkins agrees with me
> on that point.


I suppose  allows for more functionality in current UAs, but this
is an interesting proposition, especially if there were a way to
crosslink  used in this way to the original source (or whatever
it would point to). Would it be something along the lines of , or did you have something else in mind?



Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Mon, Oct 5, 2009 at 9:13 PM, Ian Hickson  wrote:
> On Tue, 22 Sep 2009, Jim Jewett wrote:
>> On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson  wrote:
>> > On Wed, 16 Sep 2009, Erik Vorhes wrote:
>> >> On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson  wrote:
>> >> >> Unless there is some semantic value to the name being more than
>> >> >> "just" a name, yes.
>> >> > Is there?
>> >> Yes
>> > What is it?
>>
>>  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  element (of which I was unaware
>> >> when I sent my last message) makes a compelling case for the
>> >> re-expansion of  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  for this) can be properly evaluated.
>
> What does  do that you want?


It may not need to be , 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  makes the most sense.

To me, recommending  or  or  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:
>
>   Me: Can I say something?
>
> ...and you need neither  nor . 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:
>
>  
>   Welcome to my home page
>   My name is Bob Smith.
>   I like the book Pandora's Star.
>   What do you think?
>   
>    James Smith
>    I'm with you Bob!
>   
>   
>    Fred
>    James wrote:
>    I'm with you Bob!
>    But I disagree, I think Pat's blog post is better.
>   
>  
>
> ...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 s 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  (or some
nonexistent element whose name would likely be less logical) to mark
up text for attribution, which often would be a name.

Re: [whatwg] The new content model for breaks rendering in MSIE5-7

[Erik Vorhes]

On Wed, Sep 30, 2009 at 3:31 AM, Bruce Lawson  wrote:
> On Tue, 29 Sep 2009 20:53:44 +0100, Dean Edwards 
> wrote:
>>
>> Can't we just invent some new elements? We've already created 20 new ones.
>> Two more won't hurt. :)
>
> Or even just one for both:  anyone?

 and  (or ) could solve a lot of element rancor
on this list (and this icky IE DOM issue). So count me as +1!


Erik Vorhes

Re: [whatwg] Bibliography Markup in HTML5

[Erik Vorhes]

On Sun, Sep 27, 2009 at 8:28 PM, tjeddo  wrote:
> I am surprised at how little concern there seems to be over the lack of
> bibliography markup in HTML5.

Most of this discussion has revolved around the  element as well
as methods to mark-up attribution in such elements as .
There's also been some discussion about Bibtex as microdata, though I
think that's been dropped.


> I mean, there is new language support
> for an 'aside' section element but no 'bibliography' section element!?

A full-on bibliography (if it's not a separate page) would function
well as a  or , unless I misunderstand the way those
elements are supposed to work.


>  ...
> [RFC5322]
> http://www.ietf.org/rfc/rfc5322.txt";>Internet Message
> Format, P. Resnick. IETF, October 2008.
> ...
> 
>
> The value here is the elimination of ambiguity and that a number of new
> inferences can now be drawn by user agents.  With the  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).
> Additionally, in this context the 'dd' element would be defined to contain
> "a representation of a bibliography entry." Of course, more concise
> definitions for these elements occurring in the bibliography context should
> be worked out.


1. There'd need to be some clear-cut understanding about what would go
in the  and  elements. Would the  before the "citation
entry" and the  optional for "annotation" or something? Would
multiple s be allowed per ? Would authors understand the
difference? In your example, it feels like  is for "shorthand
bibliographic entry" and  is for "longer bibliographic entry,"
which feels a bit cumbersome and offers pretty good odds for repeated
content.

2. I'm not sure the  pattern allows for any useful mnemonic
device related to a dedicated  element.


My own practice has been to mark-up a bibliography as either a  or
 within a div, with each  being used to mark discrete items in
the list of works cited.

Would a more generalized block/inline element to identify
"attribution" (such as  or my own attempt to expand the
function of ) suit your needs?


Erik Vorhes

Re: [whatwg] the cite element

[Erik Vorhes]

On Sun, Sep 20, 2009 at 4:09 AM, Smylers  wrote:
> Erik Vorhes writes:
>
>> A use-case for "person's name" in the context of :
>>
>> In reference to many Classical texts one will often refer to the
>> author in lieu of the title (or in some cases that author's corpus).
>
> That isn't an argument for people's names _in general_ being marked up;
> it's an argument for marking them up in the specific case where they are
> used as (nicknames of) titles of works.


I never suggested otherwise. I want to be able to mark up names, etc.,
not just titles of works, with  when the context is appropriate.
That is, I want to mark up these things when they function as an
attribution. (As I have previously detailed.)


>
>> E.g.:
>>
>> You should read Herodotus.
>
> That's using "Herodotus" as the title of a work.  In many fields it's
> common to refer to well-known works by nicknames, such as 'Smith &
> Thomas', 'The Dragon Book', 'The Red Book', or 'The White Album'.  So
>  should be used for them.


I feel here that you're stretching the definition of "title of work"
beyond its usefulness. If we can use aliases within , great, but
that seems to make more apparent the usefulness of having  be
for more than just "title of work." Indeed, titles of works and these
other examples more readily fall under the rubric of "something for
attribution." (I'm working on more specific wording but wanted to get
this out there.)


> But it doesn't follow that  should be used for any other
> occurrences of those terms -- the people Smith and Thomas, or a book
> which just happens to be red.

Really? ;)


Erik

Re: [whatwg] the cite element

[Erik Vorhes]

A use-case for "person's name" in the context of :

In reference to many Classical texts one will often refer to the
author in lieu of the title (or in some cases that author's corpus).
E.g.:

You should read Herodotus.



Erik

Re: [whatwg] article/section/details naming/definition problems

[Erik Vorhes]

On Wed, Sep 16, 2009 at 3:35 AM, Bruce Lawson  wrote:
> there would also need to be a  element

I'd be *slightly* concerned that confusion could arise between a
 element and the , at least in
discussion. (I.e., what would "HTML comment" mean?)

 (which has already been proposed) might more logically suit
the bill for standalone articles (in a blog or whatever) as well as
blog/forum comments. And since it's part of the Atom spec., there's
some precedent for defining its use.

That said, I don't have a problem with  as a special kind of
 (though having articles nested within articles doesn't agree
with my brain at this point).

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

A few points of clarification:

On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson  wrote:
>> Unless there is some semantic value to the name being more than "just" a
>> name, yes.
>
> Is there?

Yes, and with the removal of the  element (of which I was
unaware when I sent my last message) makes a compelling case for the
re-expansion of  for dialog.

On October 31, 2006, Michael Fortin suggested the following pattern:
Me: Can I say something?

Which Jeremy Keith also recommends. [1]

(For longer text it would make more sense to do something like
, but that's beside the point.)

You didn't explicitly object to such a pattern (though implemented a
different one for ) as late as May 5, 2008 [2].

Aside from the current definition of , I think this would be a
good use of the element, since it makes more sense than  or 
(what do those signify in this context?) and there's nothing wrong
with an italicized name in this context. Moreover, there are examples
of Fortin/Keith's usage in the wild.


> There's nothing wrong with overriding default presentaional styles, but
> there _is_ something wrong with a spec's defaults being different than
> what authors want.

Agreed.


>> How many sites using  for people's names (or other reasonable uses
>> that deviate from "title of work") would it take to convince you that it
>> _was_ a common case?
>
> Benjamin already asked me that, I was turning the tables on him when I
> asked the question above. :-)

Oops! I like to think of myself as a better reader than that. Sorry! :)


> I had answered:
>
>> > A random sample of the Web would need to show more uses of this than
>> > uses of other things.

I'm not sure the lack of majority use should be an impediment, but
that's an issue of conclusions rather than reasoning. (And I
sympathize with needing to draw the line at some point, even if it
makes some of us unhappy or some of us feel it's incorrect.)



> ... I don't understand what your proposal is, at this
> point. How do you define "citation"? What problem does it solve?

I should have made this clearer, I suppose, sorry. What I propose is
that  should be allowed for markup in the following instances:

- titles of works
- full citations
- names and other sources of quote attribution (including identifying
speakers in dialog)
- names of blog post commenters and authors (in the context of their
comments, posts, etc.)


> It doesn't matter how many people say something on this mailing list,
> that's not an unbiased sample. (The people who think  is fine as
> defined in HTML5 don't have motivation to say so, for example.)

I agree that basing decisions exclusively on what is said on the
mailing list is not always the right approach. The length of this
thread (and filtering out your and my messages) suggests that the
representation of voices pro & con (re:  in HTML5) is pretty
close to equal. In other words, it's not just you and a bunch of
cranky folks objecting to the specification (as much as it may feel
that way sometimes).


Erik


[1] http://adactio.com/journal/1609/
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014684.html

Re: [whatwg] the cite element

[Erik Vorhes]

g in
>> the absence of CSS, and meets the English language definition of the
>> term, should that also be allowed?
>
> Whether it is useful, what problems it solves, and how it works in
> existing implementations are more important concerns than all the ones you
> listed, IMHO.

I want to be clear, I believe I understand why you have chosen to
define  as it appears in the current draft of the HTML5
specification; I just happen to believe that the current definition is
not as useful as it could be and (more importantly) invalidates
current reasonable uses of the element.

Allowing  to encompass the uses I have detailed above would be
useful, allow for  to provide semantic value (and not just a
styling hook that could just as easily be provided by something like
), and works perfectly well in all extant browser
implementations.


Sincerely,
Erik Vorhes



[1] http://www.w3.org/TR/html401/struct/text.html#h-9.2.1

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
>
> For words that you wish to have no distinct presentation from the
> surrounding text -- words that readers don't need calling out to them as
> being in any way 'special' -- simply don't mark them up.
>

Interesting point. Should the HTML5 specification explicitly admonish
against using microformats, microdata, RDFa, and the like?

Re: [whatwg] the cite element

[Erik Vorhes]

On Wed, Aug 12, 2009 at 6:21 PM, Ian Hickson wrote:
>
> Currently,  in HTML5 isn't for collecting anything, it's purely to
> provide a hook for styling.

Please explain how , if it is only a hook for styling titles of
works, is any different from  in the HTML5 specification, since an
italicized title of a work qualifies as "prose whose typical
typographic presentation is italicized."

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 8:50 AM, Remco wrote:
>> I defy you to show me in the HTML 4.01 specification where something
>> like the following is nonconforming:
>>
>> I like to read nonfiction, such as John Adams, but I
>> had more time for that when I was a professional academic.
>>
>
> I don't think John Adams is a name of a person in this context. It is
> a group of works.
>

Sorry, I shouldn't have been so obscure. I was referring to _John
Adams_, by David McCullough, not John Adams the person or the
collected works of John Adams.

The point I'm trying to make by referencing the above HTML fragment is
that using  to surround the title of a work is perfectly
acceptable in HTML 4.01, which Ian claims not to be the case.

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
>
> As Ian has pointed out, the above is technically non-conforming with
> what the HTML 4 spec claims.  But it's how I've been using  for
> years, since it makes sense and has a use.


I defy you to show me in the HTML 4.01 specification where something
like the following is nonconforming:

I like to read nonfiction, such as John Adams, but I
had more time for that when I was a professional academic.

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Wed, Aug 12, 2009 at 6:21 PM, Ian Hickson wrote:
> On Mon, 3 Aug 2009, Erik Vorhes wrote:
>> On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson  wrote:
>> > Not all titles are citations, actually. For example, I've heard of the
>> > /Pirates of Penzance/, but I'm not citing it, just mentioning it in
>> > passing.
>>
>> No, that actually is a citation, whether you realize it or not. You are
>> making reference to a musical and are therefore citing it, even in
>> passing.
>
> Your definition of "citation" is far looser than my dictionary's ("a
> quotation from or reference to"). In fact your definition seems to be
> basically the same as HTML5's -- a title of a work. Unless you think that
> this should be valid use of :
>
>   I picked up my favourite book, and put it next to
>   the painting I got from my aunt.
>
> I don't think that those references to works should use . Doing so
> has zero benefit, as far as I can tell.
>


No, No, NO. That is not what I mean at all. You again deliberately
misrepresent what I am trying to convey, that  should be for
citations, not for a subset of citations.

I agree (and never suggested otherwise): those are in no way explicit
citations, as there is nothing specific about them that would justify
calling them citations. Pirates of Penzance, however is
an explicit reference to that work and therefore a citation, not
"just" a title of the work.


>
> Why not? An orchestral arrangement is a work, and has a title -- the spec
> explicitly lists "score", "song", and "opera" as possible works, for
> instance.
>
> I've added "legal case report" to the list, to clarify that you can use
>  to name such reports.
>


So the definition of  in HTML5 should currently be "title of
work or something that could be construed as a title where one doesn't
exist in the explicit sense of 'title.' But not people's names, even
if they're the citation, because using  for citations is silly."



>> Unless by "title of work" you mean "standard citation for an item,
>> usually its title"; but then  really means what it is defined as
>> in the HTML 4.01 specification.
>
> Unless you have a very loose definition of "citation", or unless you
> consider a person to be a possible "source",  in HTML5 is a strict
> superset of HTML4's definition.
>
> For example, the following is valid HTML5 but wouldn't be valid HTML4,
> since it's not a citation or reference to another source, but merely
> something mentioned in passing:
>
>   Today, as I was moving my copy of Dreamer's Void, I
>   hurt my back.
>


That's perfectly fine in HTML4. It's a citation, as I have explained
previously, and there's nothing in the HTML4 spec that prohibits that
use. Why are you misrepresenting the HTML4 spec?


>> Besides, there's already , which could be used to identify "title
>> text" or something like that.
>
> It has the wrong default styles.


So does , in many contexts even if we're relying on the
definition in HTML5 as it stands.


>  is also used to mark up titles that aren't citations, as shown by
> Philip's data.


Again. Those *are* citations.


>> There's no reason to limit it to a subset of citation (more below).
>
> I honestly don't understand how HTML5 is a subset of HTML4 here, unless
> you mean people's names, which as far as I can tell aren't commonly used
> with , and for which there is no benefit to using .


I believe they are more commonly used than you are willing to admit.



> Wikipedia's output is not an argument for consuming . In fact, what
> they're doing is an argument against keeping  for that purpose: they
> are explicitly overriding the only behaviour  gives them (italics)
> and then going out of their way to reintroduce that effect on a ! If
> that's not an argument for changing the meaning of  to something
> more convenient, I don't know what is.


Yes, Wikipedia's overall markup is problematic, but you seemed to be
needing some actual evidence that  is used for more than simply
"title of work" other than blog commenter names (which for some
inexplicable reason you have rejected out-of-hand as evidence that
 is used for people's names and other non-title citations).



>> Any reference to a title of a work is by definition a citation.
>> Therefore you are limiting  to a subset of citation.
>
> I disagree with your definition of "citation".


I'm sorry the New Oxford American Dictionary isn't good enough for you. I quote:

- a quotation fr

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Erik Vorhes]

On Fri, Aug 7, 2009 at 8:28 AM, Aryeh Gregor wrote:
> I think the meaning of "compatible with all existing browsers" here is
> that HTML 5 does not *require* authors to break compatibility with any
> existing browser.
>

I agree completely with your interpretation of the phrase. HTML5 is
intended to enhance the web without breaking it, so noting (or even
emphasizing) how it's backwards-compatible is important and useful.

But the phrase should be clarified along similar lines to what you've
articulated. Maybe: "HTML5 can be written in such a way that it is
compatible with all browsers made after X date"?

Erik

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Erik Vorhes]

On Fri, Aug 7, 2009 at 5:39 AM, Simon Pieters wrote:
>
> What is it that is not compatible with which browser?
>

Any use of  outside of a  is broken in every
"modern" browser: IE6-8, Firefox 3-3.5, Safari 3-4, and Opera 9-10b
all break in interesting ways. For more details, see Remy Sharp's
"Legend not such a legend anymore"
.

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson  wrote:
>
> >
> > See <http://www.four24.com/>; note near the top of the source:
> > ...
>
> My statement stands, on the aggregate:
>
> On Mon, 27 Jul 2009, Philip Taylor wrote:
> >
> > See http://philip.html5.org/data/cite-attribute-values.txt for some
> > data. (Looks like non-URI values are quite rare.)
>

I agree that @cite is rarely used as anything other than a URI; I was
attempting to demonstrate that even very recent uses of HTML don't
necessarily "get" that it is for URIs (the site I referenced launched
last month, as I recall).

>
> While we're at it, Philip had other data:
>
> > Also maybe relevant: see http://philip.html5.org/data/cite.txt for some
> > older data about . (Looks like non-title uses are very common.)
>
> This seems to support my point that  is used for a whole variety of
> purposes, like , , , HTML4's , and HTML5's . Very
> few, actually much fewer than I had remembered from my last look at the
> data, are names of people, citations or otherwise.
>

I actually took this information the other way, that there are indeed
other uses for  out there beyond titles.

>
> On Mon, 27 Jul 2009, Erik Vorhes wrote:
> >
> > > A new element wouldn't work in legacy UAs, so it wouldn't be as
> > > compelling a solution. Also,  is already being used for this
> > > purpose.
> >
> > My preference would be for  to retain the flexibility it has in
> > pre-HTML5 specifications, which would include referencing titles.
>
> The flexibility doesn't seem as useful as limiting it to titles. What is
> the problem solved by allowing names to be marked up in the same manner as
> titles? The problem solved by allowing titles specifically to be marked up
> is that titles are usually typographically offset from the surrounding
> text in a distinctive fashion. This doesn't apply to names. Reusing the
> same element for both encourages authors to use  for both which
> makes it harder for them to get the right typographic effect, leading to a
> lower quality of typography overall. I think this is a bad thing.
>

This is not just about names. It allows other (non-title) text to be
identified as a citation. If  is identified as "title of work,"
you can't cite many major orchestral arrangements at all, nor can you
cite legal decisions. Unless by "title of work" you mean "standard
citation for an item, usually its title"; but then  really means
what it is defined as in the HTML 4.01 specification.

>
> > If backwards compatibility is that big a concern, why does HTML5 use
> >  outside of  elements?
>
> There were no existing elements that could be reused for many of the new
> semantics. When there were, we used them (e.g. , , , ,
> , ).
>

I agree that there aren't always existing elements for the new
semantics included in HTML5, but I don't believe that backwards
compatibility is as big a concern as you claim it is. HTML5's re-use
of , for example, is completely broken in every extant
browser. (See <http://html5doctor.com/legend-not-such-a-legend-anymore/>
for evidence).

Besides, there's already , which could be used to identify "title
text" or something like that.


> > > What is the pressing need for an element for citations, which would
> > > require that we overload  with two uses?
> >
> > A title can be a citation, but not all citations are titles. What's the
> > pressing need for limiting  only to titles?
>
> As described above, the need to have an element for titles is that there
> are typographic conventions that apply to titles. What is the pressing
> need for an element for citations, which would require that we overload
>  with two uses?
>

As I have said previously, there aren't consistent typographic
conventions that apply to titles. The "pressing need" is that 
is already used to define citations. There's no reason to limit it to
a subset of citation (more below).

>
> But why does that have value? How would you use this information?
>

To collect citation information. I don't see how that as any less
value that collecting titles of works, especially since not all works
have titles or means of reference that would constitute a conventional
"title."

>
> > >> > Note that HTML5 now has a more detailed way of marking up
> > >> > citations, using the Bibtex vocabulary. I think this removes the
> > >> > need for using the  element in the manner you describe.
> > >>
> > >> Since this is supposed to be the case, why shouldn't HTML5 just ditch
> > >

Re: [whatwg] the cite element

[Erik Vorhes]

On Mon, Jul 27, 2009 at 10:17 AM, Kristof
Zelechovski wrote:
>  1. If you cite a person, the person you cite does not become a citation
> because of that.  Putting the person inside the CITE element distorts the
> meaning.

If you are citing a person (either as someone worth quoting or as,
say, the photographer of an image), how does using  to identify
the citation distort the meaning?


>  2. The example Chaucer and the Canterbury Tales> is invalid because "Canterbury Tales" are not being cited, at
> least not in the title page.

Why not? It seems clear to me that one title is citing the other.


>  3. The semantic potential does not decrease uniformly with specificity.
> Rather, there is an optimal value somewhere in the middle of specificity.
> Arguably, that optimum is attained with CITE reserved for titles.

Arguably, the optimum is attained with  reserved for citations.


>  4. Of course titles are not always styled the same way.  However, there is
> a requirement that the presentation makes sense in most cases when CSS is
> not supported.  The cases where styling all titles in the same way makes the
> information hard to understand are scarce.

This doesn't explain why  needs to be used exclusively used for
titles. (And I didn't realize that HTML was really just for use as
styling hooks. There's no audible difference between MLA Handbook for Writers of Research
Papers and MLA Handbook for Writers of Research
Papers.)


>  5. Random markup errors a few pages do not constitute an obstacle here,
> nor do errors in template code (they are ubiquitous once deployed but they
> are easy to fix, at least at Wikipedia).

Except that Wikipedia is not erroneous in its usage of . It is
declaring conformance to XHTML 1.0 Transitional, which is based off of
the HTML 4.01 specification, which defines  as "a citation or a
reference to other sources."

To the issue of  in HTML5, using  as "title of work"
provides for no distinction between editions or translations of works.


>  6. It does not mean anything to say "this is a citation"; this definition
> is too ambiguous to be useful.

I obviously disagree. " identifies a title" is too narrow a
definition to be useful.


Erik Vorhes

Re: [whatwg] the cite element

[Erik Vorhes]

On Sun, Jul 19, 2009 at 4:58 AM, Ian Hickson wrote:
>
>> If  is exclusively for titles, it shouldn't be called .
>
> Sure, but we're about 15 years too late for that.
>

Well, no: the as far as I have been able to determine, every HTML
specification (before HTML5) did not limit this element to titles.

>
> In practice, people haven't been confused between these two attributes as
> far as we can tell. People who use  seem to use it for titles, and
> people who use cite="" seem to use it for URLs. (The latter is rare.)
>

See <http://www.four24.com/>; note near the top of the source:
...

>
> A new element wouldn't work in legacy UAs, so it wouldn't be as compelling
> a solution. Also,  is already being used for this purpose.
>

My preference would be for  to retain the flexibility it has in
pre-HTML5 specifications, which would include referencing titles. If
backwards compatibility is that big a concern, why does HTML5 use
 outside of  elements? See:
http://twitter.com/rem/status/2869618614

And if the definition of new elements is such a concern, why introduce
*any* new elements? (Please forgive the snark.)

>
> What is the pressing need for an element for citations, which would
> require that we overload  with two uses?
>

A title can be a citation, but not all citations are titles. What's
the pressing need for limiting  only to titles?

>
>> I understand HTML5's attempts to provide semantic value to such elements
>> as , , and . To at the same time remove semantic value at
>> the same time is completely asinine.
>
> If 's original meaning has value, that is true; what is its value?

I would assume that this would be obvious.  both denotes and
connotes "citation."

>
>> > Note that HTML5 now has a more detailed way of marking up citations,
>> > using the Bibtex vocabulary. I think this removes the need for using
>> > the  element in the manner you describe.
>>
>> Since this is supposed to be the case, why shouldn't HTML5 just ditch
>>  altogether? (Aside from "backward compatibility," which is beside
>> the point of the question.)
>
> Backwards compatibility (with legacy documents, which uses it to mean
> "title of work") is the main reason.
>

I'd beg to differ, regarding "legacy documents." See, for example the
automated citation generation at Wikipedia:
http://en.wikipedia.org/wiki/Wikipedia:Citation_templates

In addition, the comments at zeldman.com use  to reference
authors of comments. While that specific example is younger than
HTML5, this is merely an example of a relatively common use-case for
 that does not use it to signify "title of work."

>
>> There is no reason at all why it can't be defined as "citing whom".
>
> The main reason would be that there doesn't appear to be a useful purpose
> to doing that.
>

The above references suggest otherwise. There are plenty of instances
where one would want to cite people rather than just a "title of
work"; blog commenters are only the most obvious example.

>
> On Wed, 1 Jul 2009, Erik Vorhes wrote:
>> On Wed, Jul 1, 2009 at 11:49 AM, Kristof
>> Zelechovski wrote:
>> > I can imagine two reasons the CITE element cannot be defined as "citing
>> > whom":
>> >  1. Existing tools may assume it contains a title.
>>
>> Existing tools (which I would assume follow the HTML 4.01 spec)
>
> It appears this assumption is mistaken.
>

Really? Please provide evidence. Existing tools that treat 
exclusively as "title of work" do so against every HTML specification
out there (i.e., HTML 4.01 and earlier).

>
>> While the HTML 4.01 specification is hardly perfect, I don't see the
>> value in limiting the semantic potential of the  element in HTML5.
>
> As far as I can tell, increasing it from citations to titles of works is
> actually increasing its semantic potential, not limiting it.
>

Well, no. It's making it more exclusive. Defining  as "title of
work" increases its specificity, but limits its semantic potential. As
I noted before, all titles are citations, but not all citations are
titles. By defining  as an element that identifies a "citation"
you allow for "title of work" while not excluding other justifiable
uses of this element, e.g., "cited person."


>
> Indeed, there is a lot of misuse of the element -- as alternatives for
> , , , and HTML5's meaning of , in particular.
>
> Expanding it to cover the meanings of , , and  doesn't seem as
> useful as expanding it just to cover works.
>

I believe you mean "limiting it just to cover works" here.

Re: [whatwg] Nested list

[Erik Vorhes]

On Mon, Jul 13, 2009 at 11:34 AM, Ryosuke Niwa wrote:
>
> We can define it in this way.  When a list A appears within anther list B
> (without being enclosed by li), then the list A is a sublist of B and that
> lists A and B constitutes a tree structure.  When a list C appears within a
> list item of the list B, then list C is a list appears in a paragraph of a
> list item of B.  i.e. C ad B does not constitute a tree structure.
>
> This can be seen from the way those two constructs are rendered in major
> UAs.  Namely, when lists A and B are nested, you don't see a bullet before
> A.  Because A and B together constitutes a tree-structure, this rendering is
> semantically correct.  On the other hand, UAs render a bullet before C.  B
> has a list item that happens to contain a list, but that doesn't prevent B
> from having a bullet for that particular list item.
>

While I think I understand your description, I'm a little concerned
for a few reasons.

1. Depending on context, lists within lists don't render differently
than lists within list items do.

2. How does the User Agent determine if a list within a list is part
of the preceding  if that  isn't closed? Is it part of the
 or something on its own?

3. Why should  and  provide different semantic meaning
depending on context? Won't that lead to confusion?

4. If two lists aren't actually supposed to be items in the same list,
why would you group them as a list? Shouldn't they be separate
entities entirely?

I've cobbled together a demonstration page to address some of these
issues (more clearly, I hope): http://textivism.com/list-items/

Erik Vorhes

Re: [whatwg] Nested list

[Erik Vorhes]

On Mon, Jul 13, 2009 at 10:22 AM, Ryosuke Niwa wrote:
>
> Does anyone see a serious compatibility issue with adding ol / ul as child
> nodes of ol / ul?  I feel like not allowing them is more problematic given
> the situation.
>

Part of the reason that browsers handle this--





-- pretty well is because, in HTML 4.01 (and earlier HTML specs), 
was not required to be explicitly closed, so it would implicitly
handle that  as a child of the preceding . (Inconsistencies in
rendering most likely arise because the browser havs already found the
explicit close to a list item before getting to the nested list.)

Do you have use case for when a child list is *not* an item in the
parent list? Otherwise, it doesn't make sense *not* to wrap the child
list in the  element.

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Wed, Jul 1, 2009 at 11:49 AM, Kristof
Zelechovski wrote:
> I can imagine two reasons the CITE element cannot be defined as "citing
> whom":
>  1. Existing tools may assume it contains a title.

Existing tools (which I would assume follow the HTML 4.01 spec) would
be mistaken in their implementation of the  element, then:
"CITE: Contains a citation or reference to other sources." (See
<http://www.w3.org/TR/html401/struct/text.html#h-9.2.1>.) Moreover, in
its sample usage, the HTML 4.01 spec uses  for more than titles.

While the HTML 4.01 specification is hardly perfect, I don't see the
value in limiting the semantic potential of the  element in
HTML5.

Erik Vorhes

Re: [whatwg] the cite element

[Erik Vorhes]

On Tue, Jun 30, 2009 at 11:19 PM, Ian Hickson wrote:
> I don't understand why it would be more useful. Having an element for the
> typographic purpose of marking up titles seems more useful than an element
> for the purpose of indicating what is a citation.

Why is it more useful?

If  is exclusively for titles, it shouldn't be called . In
addition to the semantic difference between a title and a citation,
limiting  to titles potentially raises confusion between this
element and the cite attribute (for  and ), as the
latter is limited to URLs. Yes, elements and attributes are different
things. But in one context the concept "cite" is limited only to
titles (and forbids URLs); in another context "cite" is limited only
to URLs (and forbids titles).

While it makes some sense, I suppose, to limit the cite attribute to
URLs, it makes absolutely no sense to limit the  element only to
titles. If it's so pressing for there to be an element allowed in the
 to mark up titles, why not create a new element for that
purpose or allow for a -specific attribute to note that
designation?

I understand HTML5's attempts to provide semantic value to such
elements as , , and . To at the same time remove semantic
value at the same time is completely asinine.


> Note that HTML5 now has a more detailed way of marking up citations, using
> the Bibtex vocabulary. I think this removes the need for using the 
> element in the manner you describe.

Since this is supposed to be the case, why shouldn't HTML5 just ditch
 altogether? (Aside from "backward compatibility," which is
beside the point of the question.)


Erik Vorhes

Re: [whatwg] consideration

[Erik Vorhes]

On Mon, Jun 15, 2009 at 7:28 PM, Thomas Powell wrote:
>
> There is no intention of that in the proposal, you seem to have eliminated
> the discussion about dynamic content which is also discrimentory of such
> users as well as well as the error reporting examples.  I showed a variety
> of negative and positive cases.
> My interest here in this tag in fact has grown out of a problem with lack of
> understanding of users with various
> capabilities rather than some particular design or tech agenda.
>


For the same reason you shouldn't rely only on JavaScript to provide
necessary content, you shouldn't rely on generated content in CSS. If
you follow this very basic principle, you obviate the "need" for
. I encourage you to view the following excerpt from an Eric
Meyer presentation, on the perils of relying on CSS to generate
content: http://www.vimeo.com/1149007?pg=embed&sec=1149007

The key point is this: "If it's important, it should be in the
content, it shouldn't be generated."


Erik Vorhes

Re: [whatwg] attributes

[Erik Vorhes]

On Fri, Jun 5, 2009 at 2:21 PM, Tab Atkins Jr. wrote:
>> On the other hand,
>> a simple
>>
>> 
>>
>> could be used to introduce the  and all the < s
>
> This is the one part of the suggestion that I could possibly see being
> introduced in the language, but the benefit is *still* very small.

It's also worth pointing out that currently the lang attribute is
supposed to designate language codes defined in RFC 3066, which (as
far as I can tell) don't include programming languages. A microformat
approach (using class attributes) to programming languages for 
probably makes more sense than using lang.

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Jun 4, 2009 at 12:53 PM, Kristof Zelechovski
 wrote:
> The level of surprise of an article cited as a book is far smaller than a
> real author looking like a fictitious person, as in the default rendering of
>
>        Aristotle said.

How does this make Aristotle look like a fictitious person? I'm afraid
I don't follow how  suggests this.


> Not everybody is an expert in scholarly style guides but most readers feel
> the difference between direct speech and indirect speech.

This isn't about expertise in scholarly style guides, it's about the
silliness of limiting what  encompasses in the specification
merely because the typical default text rendering is italic. Such an
approach falls into the trap of using HTML elements based on their
presentation, not their semantics. My reference to scholarly style
guides was to point out that in various circles that have thought
about it, there is some consensus that not all titles are italicized.
It follows that if  is limited to titles because by default it
italicizes titles, you run into a logical trap for having relied on
the presentation of  (possibly to the detriment of its
semantics): How do you cite a title that requires non-italic
characters if italicization is integral to the  element? The
obvious answer is to use CSS to remove the italics, but then italics
are no longer an essential part of the  element, which leads me
to wonder why it would need to be limited to titles in the first
place. (I should also point out that Lynx doesn't italicize  by
default; nor do screenreaders, as far as I can tell.)

Moreover, at no point did I mention anything about direct and indirect
speech. That's another subject entirely. Perhaps the  element
has something to do with these modes of discourse in relation to using
, , and in-text paraphrase, but again my main point of
contention is that  is the most appropriate element for a
variety of semantic uses beyond wrapping a title in an element.


> You can, of course, say
>        It was not Plato, it was Aristotle!
> but this kind of emphasis is rarely needed and the interpretation of the
> rendering is obvious from the context in this case.

I don't see how the  element is relevant to your example. You're
emphasizing their names. And if this is indeed part of an argument
about which philosopher said that famous quote, there's nothing that
prevents you from wrapping multiple elements around the correct name.
So, in your example you could write Aristotle.


> I contend that citing articles from periodicals is not well supported,
> starting with the problem of lack of support in the NID urn:ISSN.

That's beyond the scope of this discussion, but there's nothing that
says those titles can't be wrapped in . (The rest is probably
better left to the heated microformats/RFDa/microdata debates. :)


> formal citations are not inserted into running text, which is what the CITE
> element in principle is for.  They are set aside as footnotes or endnotes in
> order to keep the text readable.  There is nothing wrong with the default
> rendering of the article title in running text where symbolic bibliography
> references are not used, e.g. because the text is for the average reader.

I'm not talking about bibliographic information or a list of works
cited, although marking them up properly is relevant to this
discussion. And I should point out that the MLA, APA, AP, and Chicago
style guides aren't exclusively about bibliography. They also
recommend how best to discuss articles, books, and other texts within
the context of your writing itself. I find it hard to believe that
you've never run across an article (or other non-italicized) title in
the context of regular text. For example:

Say, have you read "Palm Pre, Elegant Contender," David Pogue's new
review in the New York Times?

I defy you to find anyone who would expect the article title (in
quotes) to be italicized in the above sentence, but there are (I
believe) three places where  could be used justifiably.

Again, my point is that one shouldn't rely on default HTML rendering
to justify certain uses of an element. To do so can diminish the
semantics of the element in discussion and in cases like 
actually makes the too-limited scope even narrower. (To reiterate, if
italics are an essential component of , and  is used
exclusively to mark up titles, you can't appropriately use  with
every title, which cripples even that limited use.)

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Jun 4, 2009 at 3:13 AM, Kristof Zelechovski
 wrote:
> The HTML is required to produce a meaningful rendering without CSS.  The
> level of reader surprise at the default rendering of
>        Aristotle said
> is high and such markup should be verbally deprecated.  (I agree that it
> cannot be technically invalid, of course.)
>

If I'm reading your message correctly, you assert that the spec's
documentation of semantic uses for  must be limited because of
how browsers render text within  by default.

But the argument in favor of limiting  in the spec. to titles
becomes almost immediately problematic. According to many scholarly
style guides (e.g., APA, MLA, and Chicago), default browser styles
properly italicize Crime and Punishment, but they would
improperly italicize the title to an article in a periodical.
Logically, then, if we are to use default styling as a baseline for
the usage of , the spec. would need to identify which kinds of
titles are appropriate to wrap within that element.

In addition, I'm skeptical about how much users are surprised when
they encounter italicized text. Visually, at least, by default 
renders no differently from , so it's not as if italicization is
an issue in itself; and judging my some of the seemingly random uses
of  in the wild, I doubt this is as big an issue as you suggest.

So count me as seconding Andrew Hagen's suggestions regarding .
It's too semantically useful an element to preemptively limit its use
only to titles.

Erik Vorhes

Re: [whatwg] Spec should require UAs to have control to mute/ pause audio/ video

[Erik Vorhes]

On Sat, May 9, 2009, at 2:16 PM, Tab Atkins Jr. wrote:
> The issue is that not all browsers have significant configs (I'm
> thinking of mobile browsers here), and I don't believe their inability
> to provide such a choice to the user should make them nonconforming.

If a UA is incapable of audio output, by extension it conforms to
wording that uses MUST. (That is, it mutes audio by default, as it
provides no means to play audio.) So I'm not sure this is an actual
issue. In the illogical event that an audio-free UA wouldn't conform
to this requirement, surely it's possible to word the specification in
such a way that exempts those browsers from the requirement.


> As well, recall that the majority browser for 'unsophisticated' users
> is still IE6 or 7, and IE8 still lacks any support for  at all

What does the lack of support for  in IE 6-8 have to do with an
argument against requiring UAs to mute audio in  and ?
Because those browsers exist without support for those elements, it
falls upon developers, content producers, et al., to make a good-faith
effort to provide accessible (and screenreader-friendly) content; the
wording of the HTML5 spec doesn't change current conditions, nor
should it be expected to.


Thanks,
Erik Vorhes