._. / \ / \ /-------\ | |_| | __ | | || |
>whien the browser window is wider than some value you specify.
If this is possible then it's the end of the thread.
kit blake
From www-html-request@www10.w3.org Sun Jun 25 19:52:24 1995
Return-Path:
>whien the browser window is wider than some value you specify.
If this is an option then I have yet to hear of it. Thanks for pointing its
existence.
>> Having some control mechanism to organize text in columns makes for better
>> communication. A caption can be under a picture. Or on a side.
>
>Ah. See the FIG element too for that. A caption is best in a This is an introduction to Section One
This is Section One Dot Two's body.
This is an introduction to Section Two
, but I want to do this with text/html. If I reload
> the whole page with multipart/x-mixed-replace as the primary document type
> it causes the whole screen to flash because Netscape clears the screen
> and reloads every push (which is every couple milliseconds, so it is
> quite annoying).
>
> Multipart/mixed seems the most logical method, with the x-mixed-replace
> document placed in between text/html, but as I said, Netscape
> (Mozilla/1.1N) doesn't recognize that type.
>
Unfortunatly it can't be done with server push. Small image animations
work because images can be inlined. There is currently no client mechanism
to inline HTML. Hopefully in the future there will be a standard for
inlining HTML and other arbitrary data types.
:lou
--
Lou Montulli http://www.mcom.com/people/montulli/
Netscape Communications Corp.
From www-html-request@www10.w3.org Sun Jun 25 22:25:59 1995
Return-Path:
. We could define a couple basics, say bar, line, pie and
chart. Everything else (including 2D vs. 3D) could be done via style
sheets. Well, actually, charts could be done via style sheets entirely
too, but I think that HTML needs to stand on its own without them, and
this would be a good feature to add directly to the spec.
Of course, it'd be a somewhat optional feature of HTML 3.0 (use that magic
'should' word when discussing implemntation), sorta like displaying the
image in the SRC attribute of IMG or (the proposed) FIG. If the client
was unable to display a graph (either it didn't support it - try doing
this reliably on a vt100 - or the data was too complex or
non-numerical), it would simply display the table, as written.
All the TABLE tags would be supported (BORDER, ALIGN, CLASS, ID, all
that other stuff that no browser supports currently), as with TABLE's
content tags.
And, although the spec (IMO) shouldn't say anything about how the table
is to be formatted, it should reccomend something like the following:
And so forth. Obviously, that's not perfect (and, if you've kept track,
there's no way - at least that I can see - to make a pie chart with more
than one data set. But then, HTML 3.0 tables also let you, using the
COLSPAN and ROWSPAN attributes, let you overlap tags, so I think it'll
work.)
Comments?
--/ Alexei Kosut
First data point name
Second data point name
...
First data set name
Data for first data point, first data set
Data for second data point, first data set
...
...
Second data set name
Data for first data point, second data set
...
. We could define a
> couple basics, say bar,line, pie and chart. Everything else
> (including 2D vs. 3D) could bedone via style sheets. Well, actually,
> charts could be done viastyle sheets entirely too, but I think that
> HTML needs to stand onits own without them, and this would be a good
> feature to add directly to the spec.
[snip]
Here's my two-penneth contribution towards this one :-)
In the HTML document
Then, in your style sheet ...
Table.ChartFormat1 : renderstyle.type = 2dbar
Table.ChartFormat1 : data.header = DataHead
Table.ChartFormat1 : data.sets = Set1, Set2, Set3
The rest can be inferred by the location of the TH header elements
within each Row.
This is slightly basic; it could probably be extended to include
styles for functions such as the visual "angle" or tilt of a 3d
chart, exploding portions of a pie chart, i.e
Table.ChartFormat : renderstyle.type = 3dpie
Table.ChartFormat : renderstyle.angle = 30
Table.ChartFormat : renderstyle.thickness = 10
Table.ChartFormat : data.header = dataHeaderClass
Table.ChartFormat : data.sets = Set1
TD.ExplodeThisEntry : datasetstyle.type = exploded
TD.ExplodeThisEntry : datasetstyle.size = 10
Why do I think this should be entirely left up to the Style Sheet
mechanisms, with no attributes added to the table element? What the
table element represents, in this case, is a collection of data. At
present, this data is rendered (or presented) in the form of a table,
constructed using Rows, and Cells within those Rows, using the
Object Name
Width (meters)
Height (meters)
Breadth (meters)
Blue Cube
10
7
9
Black Cube
5
9
16
Mauve Cube
9
18
23
,
table data, element or , table header, element. The precise
rendering of that data is really not a content issue, which the HTML
markup describes, but a presentation issue, which should be managed
not in the markup, but in style sheets.
> Comments?
Anyone else have any?
Regards,
Chris
--
Chris Tilbury, Estates Office, University of Warwick, UK, CV4 7AL
Tel: +44 1203 523523 x2665 Fax: +44 1203 524444
MIME mail welcomed mailto:Chris.Tilbury@estate.warwick.ac.uk
From www-html-request@www10.w3.org Fri Jul 7 02:08:43 1995
Return-Path: which is ideally suited to
storing numeric /data/ - a markup version of
text/tab-separated-values, if you like - and along with the
and
elements and the CLASS attribute (as well as the AXIS and AXES
attributes in more complex cases) we can sufficiently identify the
structure of that data such that it can be interpreted by a browser.
I would personally like to avoid a new tag, if for no other reason than if a platform
is unable to have an external chart viewer it can merely ignore the
styles applied to that TABLE element and render in a tabular text
format, or read it aloud in the case of a visually impaired or
blind user. Yes, we could come up with a standard which could
be interpreted in different fashions by a range of viewers, or
incorporate an existing standard into HTML/Web Browsers), but
why do this (see [i] above) if what we have already is
sufficient - isn't it this which HTML is supposed to do be so
good at?
(iii) Using the
Section One
Section One Dot One
Section One Dot One Dot One
Section One Dot One Dot Two
Section One Dot Two
Section Two