> This comment is incredible ! TR ___IS___ a table row (as a set of cells)
Thanks for spotting this out of date comment.
>> <!ENTITY % list "UL | OL">
> Once again, why do you separate UL and OL ???? This keeps compatibility with
> ancient GML styles but has no valid reason to exist any more.
The design criteria at the beginning of the proposal make this clear.
HTML 3.0 is designed to be backwards compatible with HTML 2.0, so we
have to keep this distinction. Furthermore, many of us like it!
> What about :
> <!ATTLIST LIST
> ....
> liststyle (unordered|arabic|capalpha|lowalpha|bullet|dash|star) #IMPLIED
> ....
> >
Now you are getting into matters better dealt with by style sheets.
We are working on guidelines for using style sheets with HTML 3.0
but this work is still at an early stage. You will be able to specify
style information in the document head (see STYLE element) as well
as with linked style sheets.
> Why don't you use the Euromath DTD for mathematics ?????
> Or even ISO 12083 ?????
I spent a lot of time looking at other approaches to representing math,
searching for a simple elegant approach that lent itself to writing by hand
as well as for wysiwyg editing, filters from common WP packages like Word and
FrameMaker, and conversion from other SGML formats. None of the other SGML
proposals matched the criteria. I am nearly done on writing up the math
proposal and hope you will take the time to look at the rationale and detailed
explanation of HTML-math.
> * ATOP is absolutely awful !!!!
Not at all, it is borrowed from LaTeX and means one thing on top of
another without an intervening line.
> * ABOVE and BELOW have a layout meaning !!!!!!! The correct names should
> be NUMERATOR and DENOMINATOR at least in a fraction !
You misundertand their purpose. ABOVE allows you to draw a line, arrow or
brace etc above an expression, while BELOW allows you to draw a line, arrow
or brace etc below an expression. They correspond to LaTeX's underline,
overline, underbrace and overbrace commands. Initially, I thought of using
under and over, but the latter made more sense for the markup for numerators
and denominators (see BOX).
> * integrals should be defined in an ELEMENT !!! <INTEGRAL>
Why? Its a symbol like many others with a well defined ISO entity name.
> * you forget so many mathematical objects that this DTD is unuseable !
Not at all. The objects are defined by ISO entity names. Wait for the
full spec for the details.
> How can you convince LaTeX users that their zillions of formulas
There is already an excellent filter for converting LaTeX documents
to HTML. HTML 3.0's support for tables and math etc will allow these
filters to do an even better job, particularly as I designed HTML-math
with this in mind.
> ****PLEASE**** take a look at Euromath DTD. Contacts (maybe outdated):
> EUROPEAN MATHEMATICAL TRUST
> Ian R.Stone
> University of Conterbury
> irs1@ukc.uk.ac
> fax: +44 227 452 196
> Bjo"rn von Sydow
> Chalmers Tekniska Ho"skolan, Sweden
> sydow@cs.chalmers.se
>> <!--
>> Note that table cells can include nested tables.
>> Missing cells are considered to be empty, while
>> missing rows should be ignored, i.e. if a cell
> This kind of cell handling derives from GML. CALS dtd also use a
> such mechanism for missing cells. When I implemented CALS tables
> for Grif, this point was the very worst one I had to deal with.
The ability for browsers to handle missing cells is an important
requirement for robustness, as well as being easy to handle.
> Wysiwyg implementations of CALS tables are rare... I'm afraid
> that a such rarity could be transmitted to HTML3...
I don't forsee any such problems, as the table model was designed
with the capabilities of existing wysiwyg editors in mind. Its true
that having the table resize itself every time you type a character
would slow things down, but you could avoid this by increasing the
size in larger steps for the editing process, or by using the COLSPEC
attribute to specify the table size directly.
> Let's imagine a HTML instance containing a table. In this table a
> row is not complete (a cell is missing) and there is a horizontal
> span... Modifying the table in ordre to 1) remove the span 2) add
> the missing cell (if not created at parsing time...) is not a simple
> problem.
To remove the span, you can replace the merged cell with all the
equivalent unmerged cells. One issue you will need to face is
what to do with the content, i.e. how to divide it up into the
resultant cells. As for missing cells. These can only occur when
the number of cells in a row (after allowing for merged cells)
is less than the number of columns in the table. Any given cell
is only defined once in the model, so what are the difficulties?
> Your mechanism of span also complicates the problem for an editor.
> Why don't you use id and idref for instance ?
The spanning mechanism is very robust, and matches nicely the
mechanism supported by common word processing packages. Using
id and idref would actually complicate matters.
>> message digest such as MD5 for the linked object and is needed
> As we say in French, you want the butter and the money for the butter.
> You are designing a SGML dtd. Not a network protocol. No other comment.
You are forgetting the times when its important to know that a link to
a remote object is still to the same version of that object as you
first intended. This is critical to legal applications for example.
> shape %SHAPE; #IMPLIED -- for shaped hotzones in FIGs --
> Interesting approach. Is a SGML instance really the place for such an
> information ? Answer is not obvious.
The ability to define graphical links in documents is useful for GIF and
JPEG which don't support links as part of the data format. It avoids the
need for separate files and makes it easy to ensure that the same documents
will be useable on both graphical and text-only clients.
>> <SUB> and <SUP> are used for subscripts and superscripts.
> Subscripts and superscripts are layout terms. Exponent and index are
> objects names...
I wanted to use the same elements for subscripts and superscripts in both
normal text and in maths. In math expressions, the SUB and SUP elements
serve as a number of roles, e.g. limits, scripts, and powers. This reflects
the reality of the wide range of semantics used in math today.
>> MARK is used as a generic marked range class, e.g. for change bars
> This reminds me something I workd with 2 years ago: Vincent Quint from
> IMAG designed at that time such "paired" elements. Their implementation is
> not easy for a HTML editor. And I think using them won't be simple either...
A simple rendering technique would be to shade or alter the color of the
marked region. For changebars, the usual line in left or right margin would
be fine too. Why is it difficult?
>> Do we want to support arbitrary elements for link starts? This would
>> involve adding HREF and related attributes to most elements.
> YES !!!!!!! DO IT !!!!!! Oh please do it !
> Why ? Because, for instance, it gives ID to SGML fragments in a HTML
> instance. This allows a object-oriented database to store SGML fragments;
> and more, it allows a such database to automatically retrieve information in
> a document ! Can't you see the power implied by a such implementation ?
> Imagine a HTML document made of fragments edited by different authors
> remotely... You see what I mean ?
The HTML 3.0 proposal already allows you to use SGML ID attributes on most
elements. It also includes a DIV tag for large scale containers, what more
do you need?
The above comments referred to the possibility of making the starting point
of a hypertext link into a larger unit than the <A> element. I don't see
how you explanation relates to this.
> I really see in HTML3.DTD some inconsistancies with the "spirit" of SGML and
> terrible problems of mixing between content and layout. The kind of things I
> saw in Netscape extensions.
You are wrong. I have worked hard to move layout issues out of html,
except for things which are essential for backwards compatibility or
simple alignment options, so that 3.0 clients aren't forced to support
style sheets. All this is described in the design criteria in the proposal.
-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom