On Friday 05 January 2007 22:47, D. E. Evans wrote:
But xhtml-1.0+ *requires* that tags be represented in *lower*
case *only*, and any mixed or upper case representation is
(strictly) invalid. AIUI, today's web authors really should be
striving towards xhtml standards compliance;
D. E. Evans writes [quoting me]:
No. From the HTML 4.01 spec:
Element names are written in uppercase letters (e.g., BODY).
Attribute names are written in lowercase letters (e.g., lang,
onsubmit). Recall that in HTML, element and attribute names are
grohtml outputs elements/tags as lowercase, not uppercase as
required by the HTML recommendations.
This is a contradiction. A `recommendation' can never be `required'.
I'll stick with requirement. Otherwise, what's the point of a
standard?
Read it again -- the spec itself uses upper- and lowercase for
readability, but HTML is case insensitive so BOLD, bold,
Bold, and bOlD are all equally valid.
I am corrected. Thank you.
___
Groff mailing list
Groff@gnu.org
On Friday 05 January 2007 15:25, Clarke Echols wrote:
grohtml outputs elements/tags as lowercase, not uppercase as
required by the HTML recommendations.
This is a contradiction. A `recommendation' can never be `required'.
I'll stick with requirement. Otherwise, what's the
But xhtml-1.0+ *requires* that tags be represented in *lower*
case *only*, and any mixed or upper case representation is
(strictly) invalid. AIUI, today's web authors really should be
striving towards xhtml standards compliance; in this respect,
grohtml's use of lower case is
Intervening to publicise a relevant but possibly collateral piece.
It is certainly very relevant to the present discussion, but
probably it does not of itself take it forward. Nevertheless, for
those who do not already know it (as I did not until I happened
upon it by chance this morning) it is a
Ted Harding [EMAIL PROTECTED]:
Intervening to publicise a relevant but possibly collateral piece.
It is certainly very relevant to the present discussion, but
probably it does not of itself take it forward. Nevertheless, for
those who do not already know it (as I did not until I happened
upon
(Ted Harding) [EMAIL PROTECTED] writes:
URL:
http://floppsie.comp.glam.ac.uk/Papers/grohtml-paper/grohtml.html
Thanks Ted,
for what it is worth there is a version 2 of the paper:
URL:
http://floppsie.comp.glam.ac.uk/Papers/grohtml-journal/grohtml.pdf
which contains a little more detail
Am Donnerstag, 4. Januar 2007 21:30 schrieb Gaius Mulley:
URL:
http://floppsie.comp.glam.ac.uk/Papers/grohtml-journal/grohtml.pdf
Interesting article Gaius.
Is it possible to get the groff source ? Looks like there is something to
learn from it.
Regards
Heinz
D. E. Evans writes:
Though not a big deal for the big web browsers, with error
correcting facilities (or many of the search engines that have
similar error correction), shouldn't all HTML entities be upper
case, and all attributes be case sensitive (99% are lower case)?
No. From the HTML
M Bianchi [EMAIL PROTECTED], 2006-12-22 20:00 -0500:
The value of man pages is not the markup language.
The value is (when done right):
structured, standardized presentation
NAME, SYNOPSIS, DESCRIPTION, OPTIONS, SEE ALSO, BUGS
standardized nomenclature
Eric S. Raymond [EMAIL PROTECTED], 2006-12-23 00:56 -0500:
Well, no, actually. DocBook - man is easy -- you're throwing away
structure when you do that. man - DocBook is *hard*, because you have
to deduce semantic structure from presentation-level cliches.
DocBook - man may be easy in
Eric S. Raymond [EMAIL PROTECTED], 2006-12-24 13:01 -0500:
Gunnar Ritter [EMAIL PROTECTED]:
But I think the most important question for troff people is,
where is a complete, high-quality converter for
+-+/ +===+
| XML-DocBook |===|
Michael(tm) Smith [EMAIL PROTECTED] wrote:
Eric S. Raymond [EMAIL PROTECTED], 2006-12-24 13:01 -0500:
XSL-FO to troff would be far more appropriate. XSL and troff are at about
the same level; thus, you wouldn't have to wire in all the policy/styling
decisions you would in a DocBook-troff
Gunnar Ritter [EMAIL PROTECTED], 2007-01-03 18:30 +0100:
The other side is that it is much easier to convert DocBook
to troff directly.
True. And people familiar with LaTex and ConTeXt find it much
easier to convert DocBook to those formats directly. It makes
great sense if DocBook is the only
As a troff user, my preference would actually be to have a
collection of XSLT stylesheets, one for each of the supported XML
input languages, and to have a common troff macro set to which all
of these are transformed.
This sounds good.
For doing anything which is not representable in the
Gunnar Ritter [EMAIL PROTECTED], 2007-01-03 19:55 +0100:
As a troff user, my preference would actually be to have
a collection of XSLT stylesheets, one for each of the
supported XML input languages, and to have a common troff
macro set to which all of these are transformed. This is
because I
M Bianchi [EMAIL PROTECTED] wrote:
+-+ ++
| man pages |-+ +---| HTML on browsers |
+-+ | / ++
|
On Dec 24, 2006, at 12:01 PM, Eric S. Raymond wrote:
Gunnar Ritter [EMAIL PROTECTED]:
But I think the most important question for troff people is,
where is a complete, high-quality converter for
+-+/ +===+
| XML-DocBook |===| troff | ?
On Sat, Dec 23, 2006 at 12:56:47AM -0500, Eric S. Raymond wrote:
M Bianchi [EMAIL PROTECTED]:
On Fri, Dec 22, 2006 at 06:19:15PM -0500, Eric S. Raymond wrote:
:
I think you'll see from my previous reply to Ted Harding that
I agree with this.
Yes, I see.
:
Well, of course
M Bianchi [EMAIL PROTECTED]:
I'm beginning to think that maybe a wiki front end that yielded
XML-DocBook of the RefEntry document type could encourage keeping
lots of documentation current. The Linux Documentation Project
might find that appealing also.
Perhaps that should be a project for
It also fails because it _insists_ on interactive navigation and
there is no way (that I am aware of) to print out a definitive
reference.
It's quite easy:
makeinfo --output=foo.txt --plaintext foo.texinfo
I like the texinfo format due to its decent output as PDF, plain text,
HTML and
But the world I'm trying to get us to looks something like this:
+-+ ++
| man pages |-+ +---| HTML on browsers |
+-+ | / ++
Werner LEMBERG [EMAIL PROTECTED]:
I don't disagree. However, how can I assure that the final result is
typographically well formatted? While working on groff.texinfo I've
found many shortcomings -- and normally texinfo does a good job. And
I'm really not willing to sacrifice that.
On Fri, Dec 22, 2006 at 06:19:15PM -0500, Eric S. Raymond wrote:
:
But I hear you asking Why fix what ain't broken?.
:
The philosophical issue this raises about groff's place in the world
is simple: are we willing to accept that it's a legacy rather than
a primary format?
26 matches
Mail list logo
