Re: [whatwg] several messages about cite
I seemed to have missed these when going through the cite e-mails recently. On Sat, 16 Apr 2005, John Lewis wrote: A way to mark up titles is something I've always wanted in HTML. Currently, cite is only appropriate for actual citations. I rarely cite books, movies, etc.; I'm usually just talking about them. i is worse. It's basically meaningless. The best I can do is i class=movie or something, and even then it's only appropriate for titles that are italicized. Song names (and other minor works) are generally written in quotation marks, not italicized. i class=song is awful. cite has been extended to cover these cases now. On Sun, 17 Apr 2005, Matthew Thomas wrote: I think distinguishing between ordinary titles and real citations is untenable, because there's not a workable dividing line. Consider these examples: 1. pMy favorite book is citeThe reality dysfunction/cite by Peter F. Hamilton. It begins: qSpace outside the attack cruiser somethingBeezling/something tore open in five places./q/p 3. pMy favorite book is somethingelseThe reality dysfunction/somethingelse by Peter F. Hamilton./p Why should the title markup have suddenly changed? Do you expect the editor of an online magazine's book reviews department, for example, to have the presence of mind to change the title markup in the first paragraph of a review if she happens to excise the last quote from somewhere else in the review? I agree. The spec is aligned with this thinking as well now. On Sun, 17 Apr 2005, Anne van Kesteren wrote: I think that would be acceptable. Although I wonder if CITE would still be the right name... Can you still use CITE for persons in that case? pciteJohn E. Simpson/cite said in citeXPath and XPointer/cite: q.../q/p Per the current spec, you explicitly can't. On Sun, 17 Apr 2005, fantasai wrote: Anne van Kesteren wrote: Ian Hickson wrote: Then would you want different markup for book titles, movie titles, play titles, song titles, etc? Or would you just expect the script to search IMDB for anything marked up with cite? Again, I don't really know. I could see a use case for a type attribute (as was suggested earlier in this thread), but that seems like a slippery slope. Suggestions? If we go with something like a TYPE attribute, I hope we can give it a better name. However, hiding semantics inside the value of an attribute is a poor markup design in humble opinion. (Although it also has some advantages.) It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. On Sat, 7 May 2005, Henri Sivonen wrote: I'd define cite meaning a title of work (not a person and not limited to quoted works). The spec matches this now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
If we go with something like a TYPE attribute, I hope we can give it a better name. However, hiding semantics inside the value of an attribute is a poor markup design in humble opinion. (Although it also has some advantages.) It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. I've seen a few suggestions now that class be used as an identifying attribute for purposes other than CSS. While this seems logical it raises some issues for designers and implementers. Consider the following: cite class=small book blueThe Neutronium Alchemist/cite In this example which of these classes is the type, and which serve only as style? A type or rel attribute is the better solution since it is generally understood to have a single value. book is an option but as others have pointed out it leads to potentially millions of new tags. There is also the issue to consider that website developers and website designers are usually a totally different species. Designers often have little understanding of how classes may be used in an application. The potential is high that the designer will use class=book on a totally unrelated element which is bound to cause visual problems if the application/developer is using the class as a program element. My proposed solution is to use the rel attribute which basically serves this purpose already. It also has less potential for conflicts than the type attribute since I have only ever seen rel used in the header whereas type has existing meaning for input fields and script tags. cite rel=book class=small blueThe Neutronium Alchemist/cite Shannon
Re: [whatwg] several messages about cite
On Tue, 15 Apr 2008, Shannon wrote:
I've seen a few suggestions now that class be used as an identifying
attribute for purposes other than CSS. While this seems logical it
raises some issues for designers and implementers. Consider the
following:
cite class=small book blueThe Neutronium Alchemist/cite
In this example which of these classes is the type, and which serve only
as style?
All of them. class isn't intended for styling, it's intended to subclass
elements. The subclassing can then be used for style, but using
presentational classes (that is, classes that describe the desired
presentation instead of the reason for that desire, the subclass of the
element) misses the point.
For example, saying class=blue with an associated .class { color: blue }
will quickly become confusing if you decide those things should be red. It
is in fact no better to use CSS that way than to use font color=blue.
There is also the issue to consider that website developers and
website designers are usually a totally different species. Designers
often have little understanding of how classes may be used in an
application. The potential is high that the designer will use
class=book on a totally unrelated element which is bound to cause
visual problems if the application/developer is using the class as a
program element.
All the people involved in the developement of a site and its style sheets
should of course agree on a set of class names.
My proposed solution is to use the rel attribute which basically serves
this purpose already. It also has less potential for conflicts than the
type attribute since I have only ever seen rel used in the header
whereas type has existing meaning for input fields and script tags.
cite rel=book class=small blueThe Neutronium Alchemist/cite
I strongly disagree with the characterisations of the class attribute in
this example.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
All of them. class isn't intended for styling, it's intended to subclass
elements.
Regardless of the intention of the class element it is NOT used in the
real world to subclass anything but styles and custom script. We may
wish otherwise but that is irrelevant. The value of class to me is:
* To get style information out of the content stream.
* To allow the re-use and grouping of style information.
* To provide alternate styles for printing, or user choice.
* To identify related elements to javascript code.
If class attribute was supposed to represent logical relationships or
groupings in the information/content then it has already failed.
The subclassing can then be used for style, but using
presentational classes (that is, classes that describe the desired
presentation instead of the reason for that desire, the subclass of the
element) misses the point.
For example, saying class=blue with an associated .class { color: blue }
will quickly become confusing if you decide those things should be red. It
is in fact no better to use CSS that way than to use font color=blue.
Agreed, I would personally never use class=blue. It was intended for
the example only so the distinction I was making between types and
styles was obvious. Designers are not used to thinking about these
things. They'll use whatever Dreamweaver offers them regardless of the
purpose for the information they are styling. Regardless of the
enlightened opinion here designers will continue to do what works
rather than what makes sense. You won't change that with a spec (that
most won't ever read). I've done a 2-year formal course in
computer-aided design and these things were just not taught.
All the people involved in the developement of a site and its style sheets
should of course agree on a set of class names.
In a perfect world, yes. In reality the people involved may not even
work for the same company. I can see a situation arising where the
meaning of classes are being assigned by a company like Google for use
with their crawler but those classes are already be in use for
presentation purposes. How will the crawler know which uses are
intentional and which are not. How will the designer know which classes
are reserved, when the system that will use them may not even exist yet.
I strongly disagree with the characterisations of the class attribute
in this example
As do I but that isn't relevant to the problem. If you feel that class
should have a purpose other than it's widely used ones (styles and JS)
then HTML5 must provide an alternative for these uses. I for one do not
intend to use inline styles at all as I prefer keeping the design
decisions outside of the HTML. That means you'll need to give me a list
of all meaningful classes that might be used with cite and other
elements - but of course nobody can.
On the other hand except for rel=stylesheet the rel attribute does not
have these encumbrances and so deserves consideration.
Shannon
