Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Ian Hickson]

(Despite the subject line, this thread quickly veered way from Joe's blog 
post and instead covered a variety of subjects. I have attempts to address 
the points that had substance and may affect the spec in my replies below. 
Please let me know if I missed something in this thread that you believe 
should have resulted in a change to the spec.)

On Thu, 22 Mar 2007, Henri Sivonen wrote:
> > >
> > > FWIW, I think  and  don't deserve to be in HTML and I am 
> > > not convinced that the use cases for  could not be satisfied by 
> > > .
> > 
> > I'm lukewarm on all three, but the cost to keeping these is probably 
> > slightly less than the cost to removing them, so I'm tending towards 
> > keeping them...
> 
> I tend to agree. But then they should not be used as a basis for arguing 
> anything about the design of HTML5 or as bases for analogies for 
> including new "semantic" elements of similar kind.

Agreed.


> > The CSS community has requested a  or  element because 
> > they want to restyle dates and times according to locale.
> 
> I tend to think that this has huge potential for people getting confused 
> and missing appointments. Time zones are impractical and confusing 
> enough without DWIM changing them.

Sorry, by locale I just meant the syntax, not the time zone.


> > Also, the aforementioned research indicated that there are substantial 
> > amounts of content on the Web that uses invented elements, IDs, and 
> > class attributes to mark up dates and times. For example, I found 
> > about the same number of pages with the obscure ID "updatedtime" as I 
> > did pages with a  element; "date" was the 14th most frequently 
> > seen class name.
> 
> However, merely marking up something as *a* date without knowing *what* 
> date is not particularly interesting. (Compare with the fluffiness of 
> Dublin Core.)

Well, it helps a little -- microformats for example add the "what" using 
their own semantics, and CSS doesn't need the "what" to decide on the 
"how" (to present).


> > > I'm inclined to think that the  element is useless.  could 
> > > be used for marking up titles of works and  could be used for 
> > > magazine and newspaper-style marking up of first instance of 
> > > personal names. I have yet to see a markup consumption use case that 
> > > would work on the public Web and would use .
> > 
> >  is used more than . It's used almost as often as .
> > 
> > One of the reasons for keeping , , , etc, separate, 
> > instead of saying that authors should just use  for all of them, is 
> > that it makes styling them differently much easier.
> 
> Assuming, of course, that you want to style them differently instead of 
> just italicizing all of them.

This seems common enough to keep them, given the arguments listed at the 
top of this e-mail.


> I am still on the fence about using  in my thesis. Currently I am 
> using it to mark up titles of works.

Any advice as to what the specshould say on the matter is welcome; in fact 
I have a whole folder of such advice that I'll be addressing in due 
course.


> > (Why is  better than ?)
> 
> It isn't. But  is better than  for editor UIs if all you want to 
> do is to italicize (the common case).

Granted, and  is allowed. It is semantically less precise, but that 
doesn't necessarily matter.


> > > | * note and reference for footnotes, endnotes, and sidenotes 
> > > |   (not aside in �HTML5�)
> > > 
> > > Yes, this is an area where document and converter authors currently 
> > > need to come up with their own class-based hacks. Ideally a 
> > > continuous media user agent could show footnotes in context so that 
> > > they don't become de facto endnotes.
> > 
> > If anyone has any ideas on this, please post them to the list. (The 
> > CSS group is also looking at footnotes closely.) One thing to consider 
> > when looking at footnotes is "would the title="" attribute handle this 
> > use case as well as what I'm proposing?". If the answer is "yes", or 
> > "almost", then it's probably not a good idea to introduce the new 
> > feature.
> 
> I am not happy with title='' for footnotes.
> 
> First, there are all the usual objection against putting 
> natural-language text in attributes.

Agreed.


> Second, tooltips (the typical screen media presentation of title='') 
> have significantly different properties compared to print footnotes when 
> it comes to reader attention. Tooltips aren't very discoverable and are 
> inconvenient to read. Footnotes, on the other hand, are rather easy to 
> read. Moreover, footnotes containing prose (as opposed to just URIs or 
> other identifier data) actually work as a device for emphasizing stuff 
> that the author pretends to de-emphasize while knowing that (s)he is 
> really emphasizing. Tooltips don't work like this. I remember reading 
> somewhere (I forget where) that many people read the footnotes first 
> when they turn a new page in a book.
> 
> This is why I'd be interested in being able to turn s into

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Anne van Kesteren]

On Fri, 23 Mar 2007 15:08:16 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:

How does that help anyone? Putting them in a custom XML vocabulary
drops all semantics directly. (Unless a search engine does some
heuristics on element names I suppose.) Custom XML vocabularies are
really not something you want to have on the web as its implied
they have no known semantics.


Not true.


Well, that depends on your definition of custom vocabulary I suppose.



XHTML, MathML and SVG are all custom vocabularies with very widely
known semantics.


 1. I wouldn't call the custom.
 2. Internet Explorer and Google don't get them...



There's nothing preventing a future "CodeML" syntax from being
understood by Koders and Google Code Search.


It's not clear to me what the advantage of putting a few elements into a  
"separate" vocabulary is. I actually think that those type of document  
semantics, including math, should just be part of HTML.



--
Anne van Kesteren

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Benjamin Hawkes-Lewis]

Nicholas Shanks wrote:

> Coming up with usage examples is trivial, justifying why they deserve  
> to make the cut into a formal specification is not.

I think the need to distinguish stuff to be typed in by the user from
other text without any need for CSS support is reason enough for .
Once we have widespread assistive technology capable of DOM access (e.g.
via IAccessible2), we'll have a better idea of whether it has other
accessibility benefits: e.g. one might well wish to have 's content
spelled out.

I think the existing data set on semantic element usage is fundamentally
poisoned by broken implementations, never mind misconceived editors,
vague specs, and widespread misinformation. So it's best to be cautious
about getting rid of elements.

--
Benjamin Hawkes-Lewis

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Robert Brodrecht]

Nicholas Shanks said:
> Browsers that don't natively support XHTML aren't that important anyway.
> All of the browsers I have access to (that are currently maintained)
> seem to cope with it. This includes Firefox, Opera, Safari, Amaya,
> Lynx, Links, OmniWeb, iCab and many more smaller ones based on the
> Gecko and WebKit engines. Granted they may not understand the nuances
> of XHTML, but I can still read a document's contents.
> The browsers that doesn't are w3m 0.5.1 (2004), Netscape Communicator
> 4.8 (2002), Internet Explorer 5.2.3 (2001), TurboGopher 2.1 (1995)   and
> WWW/Samba 1.0.3 (1993)
> I can't test anything else as I don't have it.
>
> I don't see what the problem would be with serving HTML-compatible
> XHTML + CodeML to all of the above. Sure the older browsers wouldn't
> understand the CodeML, but there wouldn't be any great loss, and
> crucially the document authorship could retain it's semantics.
> You would also have to send the wrong MIME type to a few archaic
> browsers, but that doesn't really affect the HTML5 specifications.

No version of Internet Explorer does XHTML.  Unfortunately, due to IE's
market share, it is important.  Using html compatible XHTML would render
all my code-based markup pretty worthless (especially if some special
visual formatting were to arise like in MathML).

I don't know how different the HTML5 HTML serialization would be from the
XHTML5 serialization, but there are some cases where I need to use HTML,
not XHTML, regardless of browser support.  That would mean that, in those
instances, if we deported computer terms to CodeML (or whatever), I'd be
unable to markup code in my documents.

> Coming up with usage examples is trivial, justifying why they deserve
> to make the cut into a formal specification is not.

Hm.  On the Internet, we spend a lot of time doing keyboard input and
looking at computer output.  The use case was supposed to illustrate that.

> There has been so much previous discussion on  that I won't
> continue that here, except to say that I think you are using it
> wrongly unless you are actually citing a TV show rather than just
> talking about it and want to italicise the name. (Not sure on your
> meaning of 'reference' above.)

I totally agree that I'm misusing it.  It's due to a lack of another
semantic way to markup titles of books, tv shows, etc.  If cite were more
powerful or another element was available, I could differentiate between
"I am citing a quote" and "The book I am talking about."

> I like a good mix of specific tags and general tags, as long as both
> kinds are applicable to a general audience (meaning most of the
> people and companies that put content online).

But not companies like Google, Microsoft, Apple, Yahoo, etc. etc...

> Depends on your definition of computer too. The abacus is a computer.
> Are punch cards computer code? Does assembly count or are we
> restricted to higher level computer languages like Ada? Does
> scripting count? What about completely visual programming/scripting
> where no code is hand-authored and the  block contains a series
> of screenshots or a movie demonstrating how to create the software?
>
>> It may, again, come down to the description of the tag, not
>> the tag itself.
>
> But as you have said, most people look at the tag name, draw a set of
> assumptions based on the use of the word in general English, and   never
> look at the specifications. They'll then go off and blindly use   it
> wrongly.
> Even Joe Clark (who's rant this thread originally referred to)
> clearly did not read  and assumed it meant  (he seeming
> cannot spell either :-)

That was your point with  and shampoo samples.  I'm saying that's
not proper usage for those guys.  My point when I said, "It may, again,
come down to the description of the tag, not the tag itself.," was that
the specifications aren't giving adequate descriptions of the elements. 
If your future shampoo company saw  and misused it, it's not our
fault.  However, if they read the description and thought they could
shoehorn shampoo into the definition, then our definition wasn't adequate.
 That would be our fault.

>> But some people (e.g. your programmer) do care if it is computer
>> output.
>> You are telling one group to go to hell while embracing another.
>
> Not at all, I'm saying "your usage case is not general enough for
> explicit support, please use a secondary vocabulary". Whether that
> vocab is Dublin Core, hCard, MathML or whatever is irrelevant.

We could split hairs about most tags, and we could ship most of them off
to a "secondary vocabulary."  That wouldn't make things any better,
though.  We'd end up with a bare and useless specification.

> Yep, this is what we all want, and what I am arguing for. A ‘purer’
> reality-based HTML and not a markup language for geeks.

Yes, totally agree.  However, geeks use the language, too.  If you cut
geeks out in an effort to make the language more accessible for others,
you've failed to 

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Nicholas Shanks]

On 23 Mar 2007, at 18:26, Robert Brodrecht wrote:


I welcome  to mark up blocks of code, but I don't think HTML
should go further than that, if you want to mark up computer  
code   that badly, use XHTML + some CodeML equivalent to MathML.


I'd love to, but one of the major browsers doesn't support XHTML. :(


Browsers that don't natively support XHTML aren't that important anyway.
All of the browsers I have access to (that are currently maintained)  
seem to cope with it. This includes Firefox, Opera, Safari, Amaya,  
Lynx, Links, OmniWeb, iCab and many more smaller ones based on the  
Gecko and WebKit engines. Granted they may not understand the nuances  
of XHTML, but I can still read a document's contents.
The browsers that doesn't are w3m 0.5.1 (2004), Netscape Communicator  
4.8 (2002), Internet Explorer 5.2.3 (2001), TurboGopher 2.1 (1995)  
and WWW/Samba 1.0.3 (1993)

I can't test anything else as I don't have it.

I don't see what the problem would be with serving HTML-compatible  
XHTML + CodeML to all of the above. Sure the older browsers wouldn't  
understand the CodeML, but there wouldn't be any great loss, and  
crucially the document authorship could retain it's semantics.
You would also have to send the wrong MIME type to a few archaic  
browsers, but that doesn't really affect the HTML5 specifications.


But how can you justify the presence of  when so few people
write content where keyboard input has to be represented?



 
   Enter your e-mail address (example: [EMAIL PROTECTED]
   
 



Coming up with usage examples is trivial, justifying why they deserve  
to make the cut into a formal specification is not.



Why isn't  an  element?


I just use  when I reference a TV show.  Cite is another element
that I wish had more power...


There has been so much previous discussion on  that I won't  
continue that here, except to say that I think you are using it  
wrongly unless you are actually citing a TV show rather than just  
talking about it and want to italicise the name. (Not sure on your  
meaning of 'reference' above.)



One only has to look at the examples given in the HTML5 spec to see
how esoteric  is:
http://www.whatwg.org/specs/web-apps/current-work/#the-samp


It's used to mark computer output.  That isn't esoteric.


I disagree. It's domain is the root of it's esoteric nature, as its  
domain is esoteric.


 might not be the best name for the tag, but it does have a  
specific meaning.


I like a good mix of specific tags and general tags, as long as both  
kinds are applicable to a general audience (meaning most of the  
people and companies that put content online).



I strongly agree. It's domain is also not clear enough either. Does
morse code count? What about encoded strings?  uryyb eboreg
People who aren't programmers have a different understanding of the
meaning of the word than we do. Confusing elements leads to both
decreased and incorrect usage.


It says "computer code."  That would rule out Morse code.  I've always
looked at "computer code" to be lay-speak  for "programming  
languages and the like."


Depends on your definition of computer too. The abacus is a computer.
Are punch cards computer code? Does assembly count or are we  
restricted to higher level computer languages like Ada? Does  
scripting count? What about completely visual programming/scripting  
where no code is hand-authored and the  block contains a series  
of screenshots or a movie demonstrating how to create the software?



It may, again, come down to the description of the tag, not
the tag itself.


But as you have said, most people look at the tag name, draw a set of  
assumptions based on the use of the word in general English, and  
never look at the specifications. They'll then go off and blindly use  
it wrongly.
Even Joe Clark (who's rant this thread originally referred to)  
clearly did not read  and assumed it meant  (he seeming  
cannot spell either :-)



No, you missed the point again.  is short for sample. Misguided
hair care people of the future will think their product sample counts
as a sample and use it for that.


My point was: I can sell you a hunting rifle for hunting, but I  
can't stop

you from using it as a walking stick.  All I can do is say, "this is
intended to be used to kill animals."  It's not the hunting rifle's  
fault.

 It's not my fault.  You're the one using it the wrong way.  People
misused  to indent text, for example.


I think misuse is something better handled by error and warning  
messages in the dominant user agents. For instance if every  
 required a non-empty child  element, then when  
that was not provided, the UA could say "This page contains 1721  
mistakes.   vv More Info vv
1. Error: This quotation does not cite it's source. All quotations  
are required to cite their source with a  element, even if all  
you can provide is ‘Anonymous poet’ or similar.
2. Warning: No citation href was provided for this quotation. Authors  
ar

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Robert Brodrecht]

Nicholas Shanks said:

> Mostly unused, not even deprecated, these elements bloat the spec,
> confuse lay authors (i.e. those not of a computer science background)
> and I feel would be better represented by a custom XML vocabulary.

Your method might introduce a lot of stuff a lot of people need, but it
would remove a lot of stuff a smaller group needs.  A properly sectioned
specification could group, e.g., computer related elements together and
put them on another page, much like W3C did with "phrase elements" [1]. 
Likewise, "legal" or "newspaper" based tags could be placed in their own
section, as well.

Most lay authors don't read the specs.  It doesn't help my case, but I
read a blog once that gave spotlight to tags that most people didn't use. 
Many comments were along the lines of, "I didn't know that existed."  If
the lay authors don't know about it, it won't confuse them.

As far as bloat, I wouldn't call these tags bloat.  Something is bloat if
it is there for no reason or because it really is useless.  I strongly
believe that more tags to define more semantics would be a good thing. 
I'd love to stop misappropriating the  tag when I really want something
like . [2]

[1] http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
[2] http://etext.virginia.edu/cgi-local/tei/tei.cgi?div=div3&id=COHQQ

> You completely misunderstood. I was arguing against the need for
> ,  et al.

My apologies.

> I.E. Markup *within* code/computer terminal representation, not
> against  itself.
> I welcome  to mark up blocks of code, but I don't think HTML
> should go further than that, if you want to mark up computer code   that
> badly, use XHTML + some CodeML equivalent to MathML.

I'd love to, but one of the major browsers doesn't support XHTML. :(

> But how can you justify the presence of  when so few people   write
> content where keyboard input has to be represented?


 
   Enter your e-mail address (example: [EMAIL PROTECTED]
   
 


> Why isn't  an  element?

I just use  when I reference a TV show.  Cite is another element
that I wish had more power...

> One only has to look at the examples given in the HTML5 spec to see
> how esoteric  is:
> http://www.whatwg.org/specs/web-apps/current-work/#the-samp

It's used to mark computer output.  That isn't esoteric.   might not
be the best name for the tag, but it does have a specific meaning.

> I strongly agree. It's domain is also not clear enough either. Does
> morse code count? What about encoded strings?   type="rot13">uryyb eboreg
> People who aren't programmers have a different understanding of the
> meaning of the word than we do. Confusing elements leads to both
> decreased and incorrect usage.

It says "computer code."  That would rule out Morse code.  I've always
looked at "computer code" to be lay-speak  for "programming languages and
the like."  It may, again, come down to the description of the tag, not
the tag itself.

> No, you missed the point again.  is short for sample. Misguided
> hair care people of the future will think their product sample counts
> as a sample and use it for that.

My point was: I can sell you a hunting rifle for hunting, but I can't stop
you from using it as a walking stick.  All I can do is say, "this is
intended to be used to kill animals."  It's not the hunting rifle's fault.
 It's not my fault.  You're the one using it the wrong way.  People
misused  to indent text, for example.

> Quite frankly most real-world/normal
> people (e.g. your greengrocer) don't care whether something is
> computer output or not, but they could very well benefit from
>  labelling up SKUs on their supplier's website, for example.
> We can't add elements willy-nilly without creating bloat though, and
> the dead wood has to be cropped to keep the tree healthy.

But some people (e.g. your programmer) do care if it is computer output. 
You are telling one group to go to hell while embracing another.  I don't
know why grocers are more important than programmers (and I'm certainly
not suggesting the other way around).  The problem with your
interpretation of the word "bloat" is that it is a see-saw.  We can either
1) serve one group better and another worse or 2) serve two groups poorly.
 Rather, we could serve all groups well by adding tags in a calculated
manner (not willy-nilly) so as to avoid cruft while still providing a rich
set of semantically useful elements.  Just because I like my programming
tags doesn't mean I don't like your retail tags.  We can coexist.

That said,  may be cruft.  I would just use .  But, I think
computer input (), computer output (), and the stuff that
processes it () are important to people who program for a living,
just as  would be important to someone who sells stuff for a
living.  Adding useful elements wouldn't hurt.  Removing perceived useless
elements may.

-- 
Robert 

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[James Graham]

Nicholas Shanks wrote:

On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:

Just because "most ... doesn't bother" doesn't mean it ought to be 
removed.

So let's not ignore elements because "no one uses them."
Ignore them because they are useless.


I was thinking more along the lines of:

1) We start with a set containing all potential authors, human and 
robotic, past present and future.
2) We remove from that set the people and programs who don't care about 
or are not willing to learn correct methods of authorship, these people 
should have no say.
3) We then take a poll of every possible string value for new elements, 
and sort the result as a priority list, amalgamating words that mean the 
same thing.
4) We decide how many elements HTML should have (i.e. how complicated it 
should be/how hard for new people to learn), and cut the list at this 
number.

5) We then use this as the new HTML.

That way I'm sure there would be 100 million votes for  and 
perhaps 250,000 votes for , ,  etc.


Whilst I agree with your conclusion (drop , , ), I disagree with 
your methodology. All possible elements are not equal; some elements can be 
processed by general-purpose UAs to beneficial effect, others cannot. When 
designing the language we should be looking to include the first type of element 
and not the second.


--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Nicholas Shanks]

On 23 Mar 2007, at 13:17, Anne van Kesteren wrote:

On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:

Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better represented by a custom XML vocabulary.


How does that help anyone? Putting them in a custom XML vocabulary  
drops all semantics directly. (Unless a search engine does some  
heuristics on element names I suppose.) Custom XML vocabularies are  
really not something you want to have on the web as its implied  
they have no known semantics.


Not true.
XHTML, MathML and SVG are all custom vocabularies with very widely  
known semantics.
There's nothing preventing a future "CodeML" syntax from being  
understood by Koders and Google Code Search.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Anne van Kesteren]

On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:

Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better represented by a custom XML vocabulary.


How does that help anyone? Putting them in a custom XML vocabulary drops  
all semantics directly. (Unless a search engine does some heuristics on  
element names I suppose.) Custom XML vocabularies are really not something  
you want to have on the web as its implied they have no known semantics.



--
Anne van Kesteren

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Nicholas Shanks]

On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:

Just because "most ... doesn't bother" doesn't mean it ought to be  
removed.

So let's not ignore elements because "no one uses them."
Ignore them because they are useless.


I was thinking more along the lines of:

1) We start with a set containing all potential authors, human and  
robotic, past present and future.
2) We remove from that set the people and programs who don't care  
about or are not willing to learn correct methods of authorship,  
these people should have no say.
3) We then take a poll of every possible string value for new  
elements, and sort the result as a priority list, amalgamating words  
that mean the same thing.
4) We decide how many elements HTML should have (i.e. how complicated  
it should be/how hard for new people to learn), and cut the list at  
this number.

5) We then use this as the new HTML.

That way I'm sure there would be 100 million votes for   
and perhaps 250,000 votes for , ,  etc.


Mostly unused, not even deprecated, these elements bloat the spec,  
confuse lay authors (i.e. those not of a computer science background)  
and I feel would be better represented by a custom XML vocabulary.



 is not useless
And, frankly, you are wrong.  Lots of places I go markup code with  



You completely misunderstood. I was arguing against the need for  
,  et al.
I.E. Markup *within* code/computer terminal representation, not  
against  itself.
I welcome  to mark up blocks of code, but I don't think HTML  
should go further than that, if you want to mark up computer code  
that badly, use XHTML + some CodeML equivalent to MathML.
I also believe it should be preformatted as well as monospace (white- 
space: pre; font-family: monospace;) by default.


Indeed, if we were starting again I would probably make  block- 
level. Then again it's easier to write  (make a code  
block) than  (make a code run) And  
works with non-CSS capable UAs/devices.
I think the sample given for  in the spec should be wrapped in  
a  given that sample's inherent block-like nature. There could  
also be an example of it where just one word in a paragraph was  
marked up.



But how can you justify the presence of  when so few people  
write content where keyboard input has to be represented? I've never  
met anyone who's hobby is writing computer software manuals in HTML.  
By contrast there are millions upon millions of people who watch  
television and discuss it on the internet. Why isn't  an  
element?


One only has to look at the examples given in the HTML5 spec to see  
how esoteric  is:

http://www.whatwg.org/specs/web-apps/current-work/#the-samp


 isn't powerful enough as it is, in my opinion.


I strongly agree. It's domain is also not clear enough either. Does  
morse code count? What about encoded strings?  type="rot13">uryyb eboreg
People who aren't programmers have a different understanding of the  
meaning of the word than we do. Confusing elements leads to both  
decreased and incorrect usage.


I fear that in 100 years we'll be downloading free shampoo to our  
molecular synthesizers that will come wrapped in HTML  tags.


Well, only if the shampoo sample is output from a computer  
program.  We do have to care about the semantics...


No, you missed the point again.  is short for sample. Misguided  
hair care people of the future will think their product sample counts  
as a sample and use it for that. Quite frankly most real-world/normal  
people (e.g. your greengrocer) don't care whether something is  
computer output or not, but they could very well benefit from  
 labelling up SKUs on their supplier's website, for example.  
We can't add elements willy-nilly without creating bloat though, and  
the dead wood has to be cropped to keep the tree healthy.



Joe Clarke isn't calling for the removal of computer science elements.


I am. Or at least their deprecation, a notice that they will be  
removed in future version of HTML.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Henri Sivonen]

On Mar 23, 2007, at 02:04, Christoph Päper wrote:


(Why is  better than ?)


It isn't. But  is better than  for editor UIs if all you  
want to do is to italicize (the common case).


Isn't this a very western point of view?


Perhaps, but it is still the common case, because the bicameral  
scripts form the vast majority of Web content[1]. Just because  
something doesn't apply to *all* scripts doesn't make it irrelevant  
as far as optimizing for the common case goes.


PS: (Hyper)Text editors should never have had B, I and U buttons in  
the first place, but now it is an established concept.


I think fighting the B and I buttons is futile, but I defer to the  
authoring tool vendors on this list.


[1] According to http://macchiato.com/slides/unicode_at_google.pdf,  
the Latin script is used many times more often than all other scripts  
taken together. Of the rest, Han is used slightly more than Cyrillic,  
but Cyrillic is used more than everything else that is left after  
Latin and Han.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Robert Brodrecht]

On Mar 22, 2007, at 5:08 PM, Nicholas Shanks wrote:
• Bullet 7: I think people marking up computer code in HTML are  
completely wasting their time. Most sample code I have seen doesn't  
bother. e.g. some random OpenGL sample code:

http://developer.apple.com/samplecode/Red_Rocket/listing4.html
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=Mac_OS_X
The usage case for this vs. usage of HTML for the rest of the  
internet is insufficient to earn the right to be in HTML.


Just because "most ... doesn't bother" doesn't mean it ought to be  
removed.  Most people just use  instead of , , or  
whatever.  By your logic, we don't need anything other than , but  
you already argued for using things other than  to counter the  
articles points.  The problem is that to write semantically valid  
markup, there will be tags that don't get used very often.  So let's  
not ignore elements because "no one uses them."  Ignore them because  
they are useless.


 is not useless.  Code needs to be monospaced, and, sometimes  
formated like .  We could use  but  is just as bad as  
.  It only says "this is preformatted" and it has no semantic  
meaning.   means "This is computer code."  Using some CSS, I  
can make  act like  AND it will mean something (e.g. a  
search engine that helps people find computer code can index stuff in  
 elements).


And, frankly, you are wrong.  Lots of places I go markup code with  
. [1][2][3][4][5][6][7][8][9]  The examples you give markup  
their code.  The problem is that there is no "blockcode" element  
( would be to  as  is to ).  They use  
 because it is all they have.


 isn't powerful enough as it is, in my opinion.

I fear that in 100 years we'll be downloading free shampoo to our  
molecular synthesizers that will come wrapped in HTML  tags.


Well, only if the shampoo sample is output from a computer program.   
We do have to care about the semantics...


Joe Clarke isn't calling for the removal of computer science  
elements.  [10]  He's asking for other elements be added that will  
help, e.g., newspaper publishers.  As far as I know, HTML 5 accounts  
for many of these.


[1] http://www.456bereastreet.com/archive/200702/worst_code_ever/
[2] http://alistapart.com/articles/flashembedcagematch
[3] http://www.cherny.com/webdev/70/javascript-event-delegation-and- 
event-hanlders
[4] http://robertdot.org/2006/07/18/json-an-alternative-to-xml-in- 
ajax.html

[5] http://bitesizestandards.com/bites/automatic-coloured-rows
[6] http://www.json.org/js.html
[7] http://www.php.net/manual/en/function.echo.php
[8] http://developer.mozilla.org/en/docs/DOM:document.getElementById
[9] http://joeclark.org/book/sashay/serialization/Chapter08.html
[10] http://blog.fawny.org/2006/10/28/tbl-html/#TBL-HTML-not-the- 
problem-2006.10.28


--
Robert 

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Matthew Raymond]

Henri Sivonen wrote:
> On Oct 30, 2006, at 22:33, Ian Hickson wrote:
>> The CSS community has requested a  or 
>> element because they want to restyle dates and times according to  
>> locale.
> 
> I tend to think that this has huge potential for people getting  
> confused and missing appointments. Time zones are impractical and  
> confusing enough without DWIM changing them.

   I support the  element for the opposite reason, in fact. I
don't want to see authors styling the date format. I'd rather see the
date format localized or customized to a user preference. If the author
wants it in a specific format, they can use CSS to style the element in
such a way as to show its contents:

HTML:
| (*)???;YY;D???(*)

CSS (using css3-content):
| time { content: contents; }

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Nicholas Shanks]

Continuing today's flood of emails from me to this list, here's another.
Note: I never bothered to read this thread the first time, but since  
Henri has brought to the top of my email client again, I started from  
the beginning.


I want to comment on the eight bullets given at:
http://www.alleged.org.uk/pdc/2003/xhtml2-cite.html
(a page linked from Joe Clark's original article)

These aren't that well thought through, I'm just throwing them out to  
be peed upon.


• 1 and 2 are both proper nouns, names of things.
These could be addressed with  with predefined classes "book",  
"movie" and "ship" producing italic output (and "person", "animal",  
"product" etc not doing so)
More thought would be needed here, like perhaps only applying  
for :lang(en) parent elements, such as:
My favourite film is lang="fr">Amelie. I have it on DVD.


• Bullets 3 to 6 could be addressed with a  element, default  
rendering italic (not related to ). You can apply any adjective  
you want to term and it seems to remain valid: foreign term,  
mathematical term, new terminology, etc. It would seem quite  
versatile yet remain semantically useful without becoming too general.


• Bullet 7: I think people marking up computer code in HTML are  
completely wasting their time. Most sample code I have seen doesn't  
bother. e.g. some random OpenGL sample code:

http://developer.apple.com/samplecode/Red_Rocket/listing4.html
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=Mac_OS_X
The usage case for this vs. usage of HTML for the rest of the  
internet is insufficient to earn the right to be in HTML.


• Bullet 8: We already have 


On 22 Mar 2007, at 21:25, Henri Sivonen wrote:


On Oct 30, 2006, at 22:33, Ian Hickson wrote:


On Sun, 29 Oct 2006, Henri Sivonen wrote:
FWIW, I think  and  don't deserve to be in HTML and I  
am not
convinced that the use cases for  could not be satisfied by  
.


I'm lukewarm on all three, but the cost to keeping these is probably
slightly less than the cost to removing them, so I'm tending towards
keeping them... FWIW,  is used the most of those three, and  

the least; they are all three used more often than  or  
, at
least in the sample of several billion files I last made. (We're  
talking

in the 0.01% to 0.05% range here.)


I tend to agree. But then they should not be used as a basis for  
arguing anything about the design of HTML5 or as bases for  
analogies for including new "semantic" elements of similar kind.


I hate them :-)
I would love to seeet al. officially deprecated.
In fact, we could just deprecate anything that was in HTML 1.0 and  
hasn't earned itself more than 1% usage. No-one would miss them. (And  
if they do they can author in XML.)


I think elements should earn their place in the standard and get  
kicked out if the use case is too obscure or there is a more  
appropriate markup language available (MathML, DocBook).


I fear that in 100 years we'll be downloading free shampoo to our  
molecular synthesizers that will come wrapped in HTML  tags.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Christoph Päper]

Henri Sivonen:

On Oct 30, 2006, at 22:33, Ian Hickson wrote:

The CSS community has requested a  or 
element because they want to restyle dates and times according to  
locale.


Then the recent request to www-style for styling numbers would be  
justified as well. An element for times (or numbers) could have other  
uses, though.


One of the reasons for keeping , , , etc, separate,  
instead
of saying that authors should just use  for all of them, is  
that it

makes styling them differently much easier.


Assuming, of course, that you want to style them differently  
instead of just italicizing all of them.

(Why is  better than ?)


It isn't. But  is better than  for editor UIs if all you  
want to do is to italicize (the common case).


Isn't this a very western point of view?

PS: (Hyper)Text editors should never have had B, I and U buttons in  
the first place, but now it is an established concept.

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Henri Sivonen]

On Oct 30, 2006, at 22:33, Ian Hickson wrote:


On Sun, 29 Oct 2006, Henri Sivonen wrote:
FWIW, I think  and  don't deserve to be in HTML and I  
am not

convinced that the use cases for  could not be satisfied by .


I'm lukewarm on all three, but the cost to keeping these is probably
slightly less than the cost to removing them, so I'm tending towards
keeping them...


I tend to agree. But then they should not be used as a basis for  
arguing anything about the design of HTML5 or as bases for analogies  
for including new "semantic" elements of similar kind.



I can't remember seeing any use case-based rationale for the 
element. I'm not convinced that having it is a good idea.


 (or an equivalent) has been widely requested, especially in the
microformats and CSS communities. Several microformats have need for
encoding specific times and/or dates, and are currently (ab?)using  


for this purpose.


OK.


The CSS community has requested a  or 
element because they want to restyle dates and times according to  
locale.


I tend to think that this has huge potential for people getting  
confused and missing appointments. Time zones are impractical and  
confusing enough without DWIM changing them.



Also, the aforementioned research indicated that there are substantial
amounts of content on the Web that uses invented elements, IDs, and  
class
attributes to mark up dates and times. For example, I found about  
the same
number of pages with the obscure ID "updatedtime" as I did pages  
with a

 element; "date" was the 14th most frequently seen class name.


However, merely marking up something as *a* date without knowing  
*what* date is not particularly interesting. (Compare with the  
fluffiness of Dublin Core.)


I'm inclined to think that the  element is useless.   
could be
used for marking up titles of works and  could be used for  
magazine

and newspaper-style marking up of first instance of personal names. I
have yet to see a markup consumption use case that would work on the
public Web and would use .


 is used more than . It's used almost as often as .

One of the reasons for keeping , , , etc, separate,  
instead

of saying that authors should just use  for all of them, is that it
makes styling them differently much easier.


Assuming, of course, that you want to style them differently instead  
of just italicizing all of them.


I am still on the fence about using  in my thesis. Currently I  
am using it to mark up titles of works.



(Why is  better than ?)


It isn't. But  is better than  for editor UIs if all you want  
to do is to italicize (the common case).



* note and reference for footnotes, endnotes, and sidenotes (not
aside in “HTML5”)


Yes, this is an area where document and converter authors  
currently need
to come up with their own class-based hacks. Ideally a continuous  
media
user agent could show footnotes in context so that they don't  
become de

facto endnotes.


If anyone has any ideas on this, please post them to the list. (The  
CSS
group is also looking at footnotes closely.) One thing to consider  
when
looking at footnotes is "would the title="" attribute handle this  
use case
as well as what I'm proposing?". If the answer is "yes", or  
"almost", then

it's probably not a good idea to introduce the new feature.


I am not happy with title='' for footnotes.

First, there are all the usual objection against putting natural- 
language text in attributes.


Second, tooltips (the typical screen media presentation of title='')  
have significantly different properties compared to print footnotes  
when it comes to reader attention. Tooltips aren't very discoverable  
and are inconvenient to read. Footnotes, on the other hand, are  
rather easy to read. Moreover, footnotes containing prose (as opposed  
to just URIs or other identifier data) actually work as a device for  
emphasizing stuff that the author pretends to de-emphasize while  
knowing that (s)he is really emphasizing. Tooltips don't work like  
this. I remember reading somewhere (I forget where) that many people  
read the footnotes first when they turn a new page in a book.


This is why I'd be interested in being able to turn s into  
footnotes in print.



* bibliographies, tables of contents, and indices (some in “HTML5”)


One of the issues here is the tension of HTML as an authoring  
format and
HTML as a delivery format. That is, do we really want the browser  
to do
the stuff BibTeX does? OTOH, if the browser just displays output  
from a

bibliography generator, what level of semantic encoding is actually
useful for the consumers of the document? PDF doesn't attempt to go
further than identifying what blocks are bibliography entries. Is  
that
useful enough to bother? If the markup is very detailed so that  
Google

Scholar (or whatever) could analyze cross-references in scientific
papers, wouldn't that veer back into focusing on computer science
papers?

I, for one, am writing about HTML5 

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello,

On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:


Hello,

On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> On 11/1/06, Charles Iliya Krempeaux < [EMAIL PROTECTED]> wrote:
> >
> > Hello Christoph,
> >
> > On 11/1/06, Christoph Päper < [EMAIL PROTECTED]> wrote:
> > >
> > > *Henri Sivonen*, 2006-10-29:
> > >
> > > >> http://blog.fawny.org/2006/10/28/tbl-html/
> > > >
> > > >> * HTML has samp, var, and kbd. I use all of them and I am
> > > >> pretty much the only one who does.
> > > >
> > > > FWIW, I think  and  don't deserve to be in HTML and I
> > > am
> > > > not convinced that the use cases for  could not be satisfied
> > > > by .
> > >
> > > I consider
> > >
> > > > > >
> >
> >
> Thinking about it some more, something like the  element may be
> useful as well for marking thumbnails.
>
> So, you might have something like this...
>
> http://example.com/video/123";>
>   http://example.com/video/123 ">
> http://example.com/thumbnail/123"; />
>   
> 
>
> (Although you'd probably want to add a "quotes:none;" to that 
> element, since some browsers wrap a  with quotes.)
>
> One would know that the  is from the video because the URL in
> "cite" attribute (for the  element) matches the URL in the "href"
> attribute (of the  element.)
>


Doing it this way (with the  element instead of the  element)
would also allow you to take the thumbnail outside of the link.  So, for
example...

http://example.com/video/123 ">
http://example.com/thumbnail/123"; />

http://example.com/video/123";>[download]

The "cite" attribute (of the  element) and the "href" attribute (for
the  element) could still be matched up to find thumbnail, in this
configuration too.



(Sorry for replying to my own e-mail message again)

If we still had the "urn" attribute on the  element, we could use it to
specify alternatives of the same video.

So, for example...

http://example.com/video/123/mpeg";>
 http://example.com/thumbnail/123"; />

http://example.com/video/123/mpeg";>[MPEG]
http://example.com/video/123/mov
">[QuickTime]


Just to say it explicitly, the "cite" attribute matches only one of those
links.  (It could be any of them.  It doesn't matter.)

Alternatively, I think it would probably be semantically OK if the urn was
even put in there -- in the "cite" attribute.  As in...


 http://example.com/thumbnail/123"; />

http://example.com/video/123/mpeg";>[MPEG]
http://example.com/video/123/mov
">[QuickTime]

(That way you don't have to play favorites.)


Any chance we can get the "urn" attribute on the  element back?  :-)


(And note... for those that think that
"urn:uuid:0a8d2f83-d5d2-44e7-bde9-319aaadc219c" looks ugly.  You do NOT have
to use URN's that look like that.  Another example of a URN is:
"urn:ietf:rfc:3023".)

See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello,

On 11/14/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:


Hello,

On 11/1/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:
>
> Hello Christoph,
>
> On 11/1/06, Christoph Päper < [EMAIL PROTECTED]> wrote:
> >
> > *Henri Sivonen*, 2006-10-29:
> >
> > >> http://blog.fawny.org/2006/10/28/tbl-html/
> > >
> > >> * HTML has samp, var, and kbd. I use all of them and I am
> > >> pretty much the only one who does.
> > >
> > > FWIW, I think  and  don't deserve to be in HTML and I am
> > > not convinced that the use cases for  could not be satisfied
> > > by .
> >
> > I consider
> >
> >
>
>
Thinking about it some more, something like the  element may be useful
as well for marking thumbnails.

So, you might have something like this...

http://example.com/video/123";>
  http://example.com/video/123 ">
http://example.com/thumbnail/123"; />
  


(Although you'd probably want to add a "quotes:none;" to that  element,
since some browsers wrap a  with quotes.)

One would know that the  is from the video because the URL in "cite"
attribute (for the  element) matches the URL in the "href" attribute (of
the  element.)




Doing it this way (with the  element instead of the  element) would
also allow you to take the thumbnail outside of the link.  So, for
example...

http://example.com/video/123 ">
   http://example.com/thumbnail/123"; />

http://example.com/video/123";>[download]

The "cite" attribute (of the  element) and the "href" attribute (for the
 element) could still be matched up to find thumbnail, in this
configuration too.


See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello,

On 11/1/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:


Hello Christoph,

On 11/1/06, Christoph Päper <[EMAIL PROTECTED]> wrote:
>
> *Henri Sivonen*, 2006-10-29:
>
> >> http://blog.fawny.org/2006/10/28/tbl-html/
> >
> >> * HTML has samp, var, and kbd. I use all of them and I am
> >> pretty much the only one who does.
> >
> > FWIW, I think  and  don't deserve to be in HTML and I am
> > not convinced that the use cases for  could not be satisfied
> > by .
>
> I consider
>
>



Thinking about it some more, something like the  element may be useful as
well for marking thumbnails.

So, you might have something like this...

http://example.com/video/123";>
 http://example.com/video/123";>
   http://example.com/thumbnail/123"; />
 


(Although you'd probably want to add a "quotes:none;" to that  element,
since some browsers wrap a  with quotes.)

One would know that the  is from the video because the URL in "cite"
attribute (for the  element) matches the URL in the "href" attribute (of
the  element.)


Comments?

See ya


--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Niels Fröhling]

>> * metaphorical semantics (the meaning of the things)
>> * structural semantic (the order of the things)
>> * purposal semantics (the purpose of the things)
>>
>> Let me denote some examples:
>>
>> * metaphorical:
>>   -  marks something to be funny, sarcastic or zynic
>>   -  emphasises a content strongly
>> * structural (aka. define dependencies):
>>   -  marks text to belong together, to be connected sentences
>>   -  marks sections to belong together
>>   -  marks an interactive region
>> * purposal:
>>   -  marks a region to be inside an interface-element
>>   -  marks a section to contain the/a navigation
>>   -  marks a region to be a chapters/documents title
>
> It's vaguely similar to some classification I was trying to do not long
> ago, although I could not come to something conclusive.
>
> Where would you put , , and  in this?

 There are some concepts/functionalities hidden in tags that you
can't map into CSS or JS. While you may create the  by a
+

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Michel Fortin]

Le 7 nov. 2006 à 18:59, Niels Fröhling a écrit :


* metaphorical semantics (the meaning of the things)
* structural semantic (the order of the things)
* purposal semantics (the purpose of the things)

Let me denote some examples:

* metaphorical:
  -  marks something to be funny, sarcastic or zynic
  -  emphasises a content strongly
* structural (aka. define dependencies):
  -  marks text to belong together, to be connected sentences
  -  marks sections to belong together
  -  marks an interactive region
* purposal:
  -  marks a region to be inside an interface-element
  -  marks a section to contain the/a navigation
  -  marks a region to be a chapters/documents title


It's vaguely similar to some classification I was trying to do not  
long ago, although I could not come to something conclusive.


Where would you put , , and  in this?


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Niels Fröhling]

>   I thought Joe Clark's opinions and criticisms of the WHATWG and HTML5
> might be of interest to people here.
> 
> http://blog.fawny.org/2006/10/28/tbl-html/
> 
> I don't agree with everything he said, but he points out a lot of issues
> and lists several limitations and suggestions.  Some of the suggestions
> are already included or have at least been discussed, but some a new and
> worth looking into.

 I would like to put this into discussion:

A view into the past:

In the beginning HTML's only ability to define presentation was 
through
tags (with predefined visual behaviour/presentation) and it's 
modification
through attributes.
This obviously leaded to the invention of tags for 
presentational purposes.

The definition and invention of tags, it's semantic and 
presentational
meaning was (and is) developed by various groups with various 
interests,
browser-developers (who sometimes also re-used HTML for alienous
applications), work-groups and companies that really re-(or 
miss-)used
HTML for their proprietary needs.
Most of these groups developed/extended HTML under a commercial 
point of
view: 'How can I offer a feature more excessive and faster than 
the others'.
It was rather not developed under the LCD 
(least-common-denominator) of
all participants, long ignored (and still yet) the end-user.

With the shift of presentational definition away from tags and 
inline-
attributes to CSS, and shortly after the introduction of 
free-formable
HTML (in the sense of tag-name freedom) by XML the situation has
fundamentally changed, is fundamentally different.

The situation:

From a technical point of view there don't exist a reason of 
existance
for the majority of the tags anymore (in effect most browsers 
do NOT make
any difference between the majority of the tags, with the ONLY 
exception
that they have different CSS-templates, which is a consequence 
of the
transition of the ability of the parser-engine to display from 
HTML to
XHTML to XML).
From a semantical point of view the majority of the tags are 
poluted/biased
by presentational meanings, and under the belief to rescue 
compatibility
the cleanup-forces stick with the majority of the old concepts 
without
attenting new needs.

The change in the paradigma:

At this point I suggest the complete break with the semantical 
past. And
it's easier than at any time before. There is quasi no software 
that
depends on semantic (except screen-readers, I'm going to talk 
about that
later) as mentioned above.
It's time to reflect actual streams in development of HTML; 
now, with the
introduction or the dusk of RIAs the semantic camp got split in 
three:

* metaphorical semantics (the meaning of the things)
* structural semantic (the order of the things)
* purposal semantics (the purpose of the things)

Let me denote some examples:

* metaphorical:
-  marks something to be funny, sarcastic or zynic
-  emphasises a content strongly
* structural (aka. define dependencies):
-  marks text to belong together, to be connected 
sentences
-  marks sections to belong together
-  marks an interactive region
* purposal:
-  marks a region to be inside an 
interface-element
-  marks a section to contain the/a navigation
-  marks a region to be a chapters/documents 
title

In the order written it's sensefull to assume, that metaphorical
semantics may be contained by structural elements, and 
structural
elements by purposal elements.

Though this doesn't solve the LCD-problem it makes it way more 
easy as
the variety within each LCD-problem becomes less much smaller 
(for
technicians: 2^9 < 2^3 + 2^3 + 2^3), and it has an elegant 
fall-back
path.
The split of responsability and area of application makes it 
way more
easier to meet the needs of:

* more metaphorical semantic, which is an inherit need of 
screen-
  readers, which is liked to be blamed for being not 'smart' 
enough
* more structural semantic, which is an inherit need of 
typograp

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Jonathan Worent]

--- James Graham <[EMAIL PROTECTED]> wrote:

> Anne van Kesteren wrote:
> > On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper 
> > <[EMAIL PROTECTED]> wrote:
> >> And HTML5 isn't that semantically pure anyway.
> > 
> > Where can it be improved?
> 
> To take a slight detour into the (hopefully not too) abstract, what 
do 
> people think the fundamental point of semantics in HTML is? 

I've always thought that an element was semantically correct if its 
name alone conveyed, or at
least gave some indication, of how the element is to be used. This of 
course has to be balanced
with compatibility. IMHO a, q, m, x and t all lack semantic richness. 
Obviously some of these
couldn't be changed, like a. But if you think about it, how would 
someone that doesn't know html
know that a meas anchor, and for that matter how is "anchor" indicative 
of a link. I'm not
suggesting a be changed, as I said a balance has to be found and some 
names can't be made more
descriptive.

┌── Jonathan Worent 
──┐
└─ 
Webmaster ─┘


 

Get your email and see which of your friends are online - Right on the New 
Yahoo.com 
(http://www.yahoo.com/preview) 

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello James,On 11/1/06, James Graham <[EMAIL PROTECTED]> wrote:
Charles Iliya Krempeaux wrote:>> To take a slight detour into the (hopefully not too) abstract, what do>> people think the fundamental point of semantics in HTML is? I'd say Machine readability.
>Sorry to be pedantic but what do you mean "machine readable"? All(conforming) HTML documents are "machine readable" in the sense thatthey can be parsed by machines, and no machine is capable of
understanding the actual content, so presumably you mean something else.I mean so that a machine can understand what you are saying... what you mean.For example... I could write...
    And Jane Blow said... you are so cool.  To which I said... I know.A machine (of today) isn't going to understand this.  But I could mark it up with        And    http://jane.example.com/">Jane Blow    said...     http://jane.example.com/1234.html#xyz
">you are so cool.            To which    
http://joe.example.com/">I    said...    http://jane.example.com/1234.html#zzz
">I know.    And a machine would understand that alot better.Make sense?  (Or should I explain more?... I'm being lazy by asking this... I just don't feel like doing alot of typing right now... but if it needs more explanation let me know.)
See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: 
http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Håkon Wium Lie]

Also sprach James Graham:

 > To take a slight detour into the (hopefully not too) abstract, what do 
 > people think the fundamental point of semantics in HTML is?

To keep HTML high enough on the ladder of abstraction [1] to remain a
media-independent markup language.

[1] http://people.opera.com/howcome/2006/phd/#h-37

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[James Graham]

Charles Iliya Krempeaux wrote:

To take a slight detour into the (hopefully not too) abstract, what do
people think the fundamental point of semantics in HTML is?



I'd say Machine readability.



Sorry to be pedantic but what do you mean "machine readable"? All 
(conforming) HTML documents are "machine readable" in the sense that 
they can be parsed by machines, and no machine is capable of 
understanding the actual content, so presumably you mean something else.


--
"The universe doesn't care what you believe. The wonderful thing about 
science is that it doesn't ask for your faith, it just asks for your 
eyes" --- http://xkcd.com/c154.html

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Christoph Päper]

*Anne van Kesteren*, 2006-11-01:

On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper  
<[EMAIL PROTECTED]>

And HTML5 isn't that semantically pure anyway.


Oh, I thought I had removed this slightly offending sentence before  
sending, anyways ...



Where can it be improved?


I just think that redefining the meaning of existing element types,  
like |dl| or |small| (and I hadn't realized that |i| has been  
replaced by |x|), is a bit odd, although it is a very practical  
solution, which is a good thing for a language that is no longer  
intended solely for (hyper)texts, but also for application interfaces.

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello,On 11/1/06, James Graham <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:> On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper> <[EMAIL PROTECTED]> wrote:>> And HTML5 isn't that semantically pure anyway.
>> Where can it be improved?To take a slight detour into the (hopefully not too) abstract, what dopeople think the fundamental point of semantics in HTML is?I'd say Machine readability.
[...]See ya -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[James Graham]

Anne van Kesteren wrote:
On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper 
<[EMAIL PROTECTED]> wrote:

And HTML5 isn't that semantically pure anyway.


Where can it be improved?


To take a slight detour into the (hopefully not too) abstract, what do 
people think the fundamental point of semantics in HTML is? Henri has 
been talking about the possibility of making HTML5 more "semantically 
lax", and here Anne is interested in where it is not "semantically 
pure", presumably with a desire to fixing it. I'm not sure that these 
views are necessarily contradictory because I don't really know what 
people mean by "lax" or "pure". I also don't know which view best fits 
my position because I don't really understand what people are trying to 
achieve with (the markup in) HTML -- I think there are things I would 
change in the current draft, but there seems little point talking about 
which markup elements should or shouldn't exist without having some 
overall framework against which the merit of various proposals can be 
measured.


--
"The universe doesn't care what you believe. The wonderful thing about 
science is that it doesn't ask for your faith, it just asks for your 
eyes" --- http://xkcd.com/c154.html

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello Christoph,On 11/1/06, Christoph Päper <[EMAIL PROTECTED]> wrote:
*Henri Sivonen*, 2006-10-29:>> http://blog.fawny.org/2006/10/28/tbl-html/>>> * HTML has samp, var, and kbd. I use all of them and I am
>> pretty much the only one who does.>> FWIW, I think  and  don't deserve to be in HTML and I am> not convinced that the use cases for  could not be satisfied
> by .I consider   That's a really good idea!
 more semantic than the frequent   alt="Foo">.Alas nobody is using it that way. (What kind of |rel| could one usefor this kind of links BTW?)See ya
-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: 
http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Anne van Kesteren]

On Wed, 01 Nov 2006 19:24:17 +0100, Christoph Päper  
<[EMAIL PROTECTED]> wrote:

And HTML5 isn't that semantically pure anyway.


Where can it be improved?


--
Anne van Kesteren

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Christoph Päper]

*Henri Sivonen*, 2006-10-29:


http://blog.fawny.org/2006/10/28/tbl-html/


* HTML has samp, var, and kbd. I use all of them and I am  
pretty much the only one who does.


FWIW, I think  and  don't deserve to be in HTML and I am  
not convinced that the use cases for  could not be satisfied  
by .


I consider

  

more semantic than the frequent

  alt="Foo">.


Alas nobody is using it that way. (What kind of |rel| could one use  
for this kind of links BTW?)


If |kbd| is understood as a general element type for any user input/ 
action, no online software or hardware documentation or help file  
could do without it and there are a lot of these. In practice it is  
sometimes considered to mean "key" instead and thus styled with  
"border-style: outset".



* “HTML5” has meter (for measurements) and t for time notation.


Joe Clark basically disqualifies himself here for any serious  
comments on any standard, because he appears to only skim over them,  
not read them. (What makes it worse is his repeated mentioning of is  
wrongly-guessed understanding of |meter|.) Despite that, an element  
type for measurements, i.e. pairs of value and unit, might not be the  
worst idea, although low in priority.



* annotation
* note and reference for footnotes, endnotes, and sidenotes  
(not aside in “HTML5”)


That's basically all the same (to me), just presented differently,  
except that some footnotes may well be rendered inline -- e.g. like  
this -- and |aside| always is a paragraph of its own.



* Ban tables for layout.


As long as graphic designers want to use grid-based layouts,  
telling them to fake them with floats or, worse, positioning is  
jumping from the frying pan into the fire. (And telling them to use  
display: table; doesn't work if IE doesn't support it.)


I think the best thing to do is declaring a |table| that is the only  
child of |body| (perhaps not counting text nodes and enclosing |div|)  
to be a layout table -- always. All other tables would have to be  
semantic. This would make many simpler ones of the existing table- 
layout sites conforming, but at the same time (preferably strongly)  
discouraged nested layout tables. Another option was an extra  
attribute for |table|. I still think a 2- to ca. 5-cell layout table  
doesn't harm anyone (if done right), but benefits many until the  
browser world changes for a better. And HTML5 isn't that semantically  
pure anyway.


In practice, as far as mobile accessibility for me is concerned  
with today's shipping software, traditional single-column HTML  
works great, table layouts are a bit annoying but mostly harmless  
and the supposedly accessible cool CSS stuff can make content  
unreadable.


You can tell a misguided or under-experienced CSS advocate by his  
recommendations incorporating |float| for layout purposes (and some  
similar flaws).


Even those devilish frames /may/ be more accessible than CSS layouts,  
when the frameset is displayed as a plain list of links.

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Leons Petrazickis]

On 10/31/06, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote:

Hello,


On 10/31/06, Rimantas Liubertas <[EMAIL PROTECTED]> wrote:
> <...>
> > To get valid markup I must use a table tags if I want my layout to
> > *function* that way. There is no way to fake it. It took three minutes
> > to change the tags to table tags and the page functions perfectly now.
> > This is for the benefit of the users.
>
> Some case of non sequitur, imho.
>
> I am in "ban tables for layout" camp. If anyone want to use them for
> this purpose
> they are free to use some other standard or do not use any standard at
all...
>

Weren't we talking about creaing new HTML elements for a grid layout before?
 (Or am I dreaming?)

What ever happened to that?



The Dojo Javascript Toolkit (http://dojotoolkit.org/) has excellent
several excellent layout widgets, including a grid layout achieved
with proprietary attributes. I used it for an intranet web
application, and it's very intuitive. For example:



left


top bar


bottom bar


inner left


inner right


This is the main panel.  It expands to fill all the left-over 
space
after placing all the top/bottom/left/right panels.



Take a look on the website. It's under See it in Action > Layout >
LayoutContainer. The demos are broken in Opera because of stupid site
design.

A straight conversion to tags is even clearer, but might be too presentational:

 outer left
 top bar
 bottom bar
 inner left
 inner right
 remainder


So we could move it to CSS, though that may present difficulties in
simulating browser compatibility via Javascript:
#container {  layout-type: grid;  }
#navbar{  layout-position: left;  }
#masthead {  layout-position: top;  }
#footer { layout-position: bottom; }
#sidenotes { layout-position: left; }
#sidelinks { layout-position: right; }
#text { layout-position: client; }


 outer left
 top bar
 bottom bar
 inner left
 inner right
 remainder


Again, you can stuff as many lefts, rights, and so ons in as you want.
It's like the inverse of an onion. The order in the CSS file
determines what's on the outside and what's on the inside.

Having made many CSS layouts by hand and having also used the Dojo
implementation, I have to say that this is a degree of magnitude
easier. A few lines of code sets up the whole layout without having to
worry about the arcanes of floating, widths, z-order, relative vs
absolute, and so on.

Regards,
--
Leons Petrazickis
http://lpetr.org/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Charles Iliya Krempeaux]

Hello,On 10/31/06, Rimantas Liubertas <[EMAIL PROTECTED]> wrote:
<...>> To get valid markup I must use a table tags if I want my layout to> *function* that way. There is no way to fake it. It took three minutes> to change the tags to table tags and the page functions perfectly now.
> This is for the benefit of the users.Some case of non sequitur, imho.I am in "ban tables for layout" camp. If anyone want to use them forthis purposethey are free to use some other standard or do not use any standard at all...
Weren't we talking about creaing new HTML elements for a grid layout before?  (Or am I dreaming?)What ever happened to that?See ya-- Charles Iliya Krempeaux, 
B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Rimantas Liubertas]

<...>

To get valid markup I must use a table tags if I want my layout to
*function* that way. There is no way to fake it. It took three minutes
to change the tags to table tags and the page functions perfectly now.
This is for the benefit of the users.


Some case of non sequitur, imho.

I am in "ban tables for layout" camp. If anyone want to use them for
this purpose
they are free to use some other standard or do not use any standard at all...


Regards,
Rimantas
--
http://rimantas.com/

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Peter Michaux]

On 10/29/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:


> * Ban tables for layout.

As long as graphic designers want to use grid-based layouts, telling
them to fake them with floats or, worse, positioning is jumping from
the frying pan into the fire. (And telling them to use display:
table; doesn't work if IE doesn't support it.)


I agree with this and I just burned three hours trying to find a
table-free layout that would work cross browser and *function* well
for a new page page. I would like it if I could assign
display:table-cell to divs and get a column design. IE won't let me.
To get valid markup I must use a table tags if I want my layout to
*function* that way. There is no way to fake it. It took three minutes
to change the tags to table tags and the page functions perfectly now.
This is for the benefit of the users.

Peter

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Ian Hickson]

On Sun, 29 Oct 2006, Henri Sivonen wrote:
> > 
> > Due in no small part to WHAT WG�s leadership by a strict standardista
> 
> Well, the leadership applies different kind of strictness to the 
> tokenizer/DOM level and to semantics. Personally, I'd like the 
> tokenizer/DOM part to be a tad stricter and the semantics part to be 
> more lax.

FWIW, I'm pretty sure that when I get to going through your comments in 
detail that this is pretty much the direction the spec will go in.


> FWIW, I think  and  don't deserve to be in HTML and I am not 
> convinced that the use cases for  could not be satisfied by .

I'm lukewarm on all three, but the cost to keeping these is probably 
slightly less than the cost to removing them, so I'm tending towards 
keeping them... FWIW,  is used the most of those three, and  
the least; they are all three used more often than  or , at 
least in the sample of several billion files I last made. (We're talking 
in the 0.01% to 0.05% range here.)


> I can't remember seeing any use case-based rationale for the  
> element. I'm not convinced that having it is a good idea.

 (or an equivalent) has been widely requested, especially in the 
microformats and CSS communities. Several microformats have need for 
encoding specific times and/or dates, and are currently (ab?)using  
for this purpose. The CSS community has requested a  or  
element because they want to restyle dates and times according to locale. 
The blogging and content publishing communities have also raised the need 
for a way to unambiguously mark up what part of their document is a date 
and/or time, though in their case (as with microformats) they need a way 
to then mark each date/time element as being a particular semantic 
(publishing date, birth date, calendar event time etc).

Also, the aforementioned research indicated that there are substantial 
amounts of content on the Web that uses invented elements, IDs, and class 
attributes to mark up dates and times. For example, I found about the same 
number of pages with the obscure ID "updatedtime" as I did pages with a 
 element; "date" was the 14th most frequently seen class name.


> I'm inclined to think that the  element is useless.  could be 
> used for marking up titles of works and  could be used for magazine 
> and newspaper-style marking up of first instance of personal names. I 
> have yet to see a markup consumption use case that would work on the 
> public Web and would use .

 is used more than . It's used almost as often as .

One of the reasons for keeping , , , etc, separate, instead 
of saying that authors should just use  for all of them, is that it 
makes styling them differently much easier. (Why is  better 
than ?)


> Also, I was unable to explain to my mother why she should use  
> instead of whatever command-i does in Dreamweaver. (Apparently, 
> command-i applied  Dreamweaver 4 but applies  in Dreamweaver MX, 
> which should indicate to semanticist that  and  are a lost 
> cause and really are only aliases for  and .)

WYSIWYG editors really should use  and , I think. I'll probably be 
including a section specifically targetted at WYSIWYG editors that don't 
have semantic support.


> > * note and reference for footnotes, endnotes, and sidenotes (not 
> > aside in �HTML5�)
> 
> Yes, this is an area where document and converter authors currently need 
> to come up with their own class-based hacks. Ideally a continuous media 
> user agent could show footnotes in context so that they don't become de 
> facto endnotes.

If anyone has any ideas on this, please post them to the list. (The CSS 
group is also looking at footnotes closely.) One thing to consider when 
looking at footnotes is "would the title="" attribute handle this use case 
as well as what I'm proposing?". If the answer is "yes", or "almost", then 
it's probably not a good idea to introduce the new feature.


> > * bibliographies, tables of contents, and indices (some in �HTML5�)
> 
> One of the issues here is the tension of HTML as an authoring format and 
> HTML as a delivery format. That is, do we really want the browser to do 
> the stuff BibTeX does? OTOH, if the browser just displays output from a 
> bibliography generator, what level of semantic encoding is actually 
> useful for the consumers of the document? PDF doesn't attempt to go 
> further than identifying what blocks are bibliography entries. Is that 
> useful enough to bother? If the markup is very detailed so that Google 
> Scholar (or whatever) could analyze cross-references in scientific 
> papers, wouldn't that veer back into focusing on computer science 
> papers?
> 
> I, for one, am writing about HTML5 in LaTeX. One of the reasons was 
> BibTeX even though I have to hack a .bst of my own.

I have to be honest that personally I've not really found a need for a 
bibliography tool. In fact, the preprocessor I use to generate the WHATWG 
specs (the one that does all the cross-references) supports automatic 
bib

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Henri Sivonen]

(Sent both to the WHAT WG list and to Joe Clark himself, because I  
assume he doesn't subscribe to the list.)


On Oct 29, 2006, at 06:33, Lachlan Hunt wrote:

  I thought Joe Clark's opinions and criticisms of the WHATWG and  
HTML5 might be of interest to people here.


http://blog.fawny.org/2006/10/28/tbl-html/


Quotes hereafter from the blog post.

Tim Berners-Lee decides to actually do something for a change.  
Unfortunately, it’s the wrong thing.


I am very interested in what the W3C is really up to. I am unable to  
figure out if they are doing the right thing (endorsing the WHAT WG  
work) or the wrong thing (doing their own competing and conflicting  
incremental improvements).



Due in no small part to WHAT WG’s leadership by a strict standardista


Well, the leadership applies different kind of strictness to the  
tokenizer/DOM level and to semantics. Personally, I'd like the  
tokenizer/DOM part to be a tad stricter and the semantics part to be  
more lax.


* HTML has samp, var, and kbd. I use all of them and I am  
pretty much the only one who does.


FWIW, I think  and  don't deserve to be in HTML and I am  
not convinced that the use cases for  could not be satisfied by  
.



* “HTML5” has meter (for measurements) and t for time notation.


The meter element is not for marking up measurements like "1.6 km".  
It is for displaying a gauge widget that visualizes a semi-static  
fraction (for example usage of Gmail storage quota) as opposed to a  
progress bar. It is for applications--not prose documents.


I can't remember seeing any use case-based rationale for the   
element. I'm not convinced that having it is a good idea.


But, true to member biases, “HTML5” bans the use of dl–dt/dd for  
dialogue, a usage permitted by the HTML spec and in wide use by  
intelligent developers like me who have to mark up documents  
unrelated to computer science.


This issue came up on the list recently.
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
October/007348.html
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
October/007418.html
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
October/007424.html


(They’d prefer you use a thicket of blockquotes and cites. And,  
presumably, nullify all the indention and italicization that  
browsers will do by default.)


I'm inclined to think that the  element is useless.  could  
be used for marking up titles of works and  could be used for  
magazine and newspaper-style marking up of first instance of personal  
names. I have yet to see a markup consumption use case that would  
work on the public Web and would use .


Also, I was unable to explain to my mother why she should use   
instead of whatever command-i does in Dreamweaver. (Apparently,  
command-i applied  Dreamweaver 4 but applies  in Dreamweaver  
MX, which should indicate to semanticist that  and  are a  
lost cause and really are only aliases for  and .)



Tantek told me (E-mail, 2006.05.16):

[T]he “print publications” crowd… cares much more about pixel  
precision, etc. They don’t (typically) bother to even mark up their  
headings using h1…h6. Now, if there were a bunch of Web pages today  
which were adaptations of print publications where they tried to  
use semantic markup as much as they could and then started using  
 for semantics that HTML didn’t capture, then that  
would be evidence.


Of course there weren’t “a bunch of Web pages today” that did so;  
the elements didn’t exist. And that proved the elements didn’t need  
to be invented.


This attitude – still present in WHAT WG, though it is separate and  
was formed later – can be summed up as “Until we decide you are  
using our computer-science tags adequately, we won’t even consider  
the semantic needs of your documents.”


Well that's not the whole story in the Tantek quote above. The same  
 appearing over and over on different sites does  
indicate demand for an element.


For “HTML5” and the new HTML variants, why can’t we just adopt  
what’s already been done in other namespaces, like the Text  
Encoding Initiative and tagged PDF?


I think learning from tagged PDF is a good idea.

However, the last time I properly read the PDF spec was in 2002 and I  
haven't done much testing. (I try to stay away from Adobe Reader. I  
use Preview.app and PDF readers derived from xpdf. In the environment  
where I'd benefit from tagged PDF, the reader doesn't support it.) I  
understand how Adobe Reader uses paragraph, heading and table markup,  
but I don't know about the rest. How are the other tags actually put  
to use?



* annotation


How would that work?

* note and reference for footnotes, endnotes, and sidenotes  
(not aside in “HTML5”)


Yes, this is an area where document and converter authors currently  
need to come up with their own class-based hacks. Ideally a  
continuous media user agent could show footnotes in context so that  
they don'

Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Anders Rundgren]

It is equally interesting that W3C intends to start a new browser
authentication WG but have excluded digital signatures and key
provisioning from the charter in spite of the fact that about 10M
people today have to use proprietary browser-plugins in order
to get their work done.  Maybe an answer to that is that this
is only happening in the EU which in this particular space is roughly
5 years ahead of the US government and financial industry.

Anders Rundgren

- Original Message - 
From: "Lachlan Hunt" <[EMAIL PROTECTED]>
To: "whatwg" <[EMAIL PROTECTED]>
Sent: Sunday, October 29, 2006 05:33
Subject: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5


Hi,
   I thought Joe Clark's opinions and criticisms of the WHATWG and HTML5 
might be of interest to people here.

http://blog.fawny.org/2006/10/28/tbl-html/

I don't agree with everything he said, but he points out a lot of issues 
and lists several limitations and suggestions.  Some of the suggestions 
are already included or have at least been discussed, but some a new and 
worth looking into.

-- 
Lachlan Hunt
http://lachy.id.au/

[whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

[Lachlan Hunt]

Hi,
  I thought Joe Clark's opinions and criticisms of the WHATWG and HTML5 
might be of interest to people here.


http://blog.fawny.org/2006/10/28/tbl-html/

I don't agree with everything he said, but he points out a lot of issues 
and lists several limitations and suggestions.  Some of the suggestions 
are already included or have at least been discussed, but some a new and 
worth looking into.


--
Lachlan Hunt
http://lachy.id.au/