Re: The style agenda

A few procedural points, then on to the meat.

Hakon:
| Terry ( >) and Bert ( > |) write:
|  > | So I suggest that we collect some arguments pro and con the following
|  > | issues, before we start with the details of syntax and the list of
|  > | style properties. Now that the mailings are archived (thanks, Nick!),
|  > | we can refer back to those arguments when the full proposal is
|  > | written.
|  > What proposal is that, specifically?  Hakon's?
   ...
| I imagine this document going through several phases. Starting as a
| scratchpad, it should end up as an I-D. I've changed the wording on
| the top to better reflect this, thanks!

If it's going to be an I-D, does that mean it has to come under
the aegis of some WG?

|  > So what's going on?  Hakon, do you intend your work to become an
|  > IETF I-D, RFC, etc.?  Is this to be an independent effort of W3?
|  > What's the relationship to HTML-WG if any?  If none, who are we
|  > and to what extent is W3 going to pay any attention to what we
|  > say?  What's the W3 framework for independent efforts, if that's
|  > what this is?
| 
| The mailing was created to have a medium through which people
| interested in style sheets & the web can communicate since none of the
| existing mailing lists are fit for this purpose. I proposed an
| informal charter (.. to support the specification and the
| implementations of an HTML style sheet mechanism.) and gave a
| reference to Bert's more specific wordings. All of this is open for
| discussion, and I'm glad we've started!

As am I.

| The creation of this mailing list is not an official act of W3C or any
| other organization. W3C has (as far as I know) not made any statements
| with regard to the issues we will be discussing. W3C simply hosts the
| disussions like it hosts www-talk, www-lib etc. Will W3C pay attention
| in the end? I think so, if the end result is good. Will the commercial
| browser vendors pay attention? I think so, if the end result is
| good. Will HTTP-WG pay attention? Who knows?

It was W3's role in standardization that was confusing.  As I understand
your response, W3 is taking no such role; that's okay.

Okay.

|  > |      For example: do the phrases "not SGML-complete" from the former
|  > |      and "useful subset of all possible SGML" from the latter
|  > |      contradict each other or not?
|  > 
|  > Hakon might expand the first phrase so that it says
|  > what he means to convey.
| 
| If conflicts arise between legibility and completeness, I may end up
| on legibility's side. Also, the SGML community seems happy with
| DSSSL-*, so why spend the extra x months of discussions that we'll
| need to finalize an SGML-complete proposal? If (x<1) then..

Any proposal limited to a single DTD will have to be reworked later.
You might omit handling some SGML features, but we seem to have most
of them in HTML.  If x<1, then we'd still have spent x<1 months
discussing a proposal that might be bettered by DSSSL-L; I think
DSSSL would be a good point of reference here.

|  > |      In particular, do we agree on the fifth goal in the `Charter'[2],
|  > |      which states that the style language does not depend on the
|  > |      particular names of elements & attributes of HTML?
|  > why should it?
| 
| Agree, in principle. Conflicts arise when you want to specify style
| for non-HTML information, e.g.
|  - the whole document: "doc: margin.left = 50pt" -- I'm not sure
|    we can convince people to use "html of "body" instead of "doc".
|  - browser buttons: "browser: button.save = off"
|  - html source: "source: font.size = 14pt"
| These conflicts will arrive when we try to handle a DTD with <SOURCE>.
| So, an item for discussion should be to what extent, if any, the style
| sheet should be able to influence non-HTML properties, or take
| non-HTML information (like AGE and LANGUAGE) into account when
| rendering. The author of a document shouldn't decide how e.g. the html
| source should be displayed, but certainly the user should. And if it's
| not in the style sheet, where will in be? I hate .Xdefaults!

Margins aside, I think such things go in what I think of as another style 
sheet, though this could be info in HEAD or a part of the rendering style
sheet.  There's a large iceberg of nonrendering info people want to
convey to the browser (browser buttons being a good example).  

 ...
|  > |      As a computer scientist, I would say that H=E5kon's three[6] is a
|  > Did not find 3 mentioned there.  From what follows I assume you mean
|  > "insist, important, normal."  I agree I don't see the point of 
|  > normal.
| 
| Hehe. We can discuss this issue till the web is dead. Initially I
| wanted to give the author two levels (I've done some computer science
| :-), but in order for the user to "wrap around" the author on both
| sides, three was needed. Later, the "legal" flag came up (I'm still
| not happy about pretending to give legeal guarantees in an optional
| style sheet, though), and there are three on each side in the current
| propsal. With plenty of room for discussion.

I don't know about the current mechanism, but let me put the case for
something like "legal."  As a publisher, I may need to insist that 
my doc be read only according to a style sheet I supply.  I know that
I probably can't find a mechanism to enforce that on the browser,
but at least I have to be able to say it.  (Then if the user insists
on rendering Warnings as gray text on a grey background, fails to
read a Warning, and electrocutes himself, I'm in the clear.)

  ...
|  > we discard it, and what is Hakon's formatting model (it isn't obvious
| 
| I'm proposing a simple stream of boxes where the style sheet controls
| the margins of each box. The boxes are stacked on top of each other
| (perhaps with a page break here & there), and children inherit the
| parent's horizontal boundry + margins (i.e. to do indented nested
| list). Paper delivery will require some extensions to this model.

Could you compare this model to Tex's?  No glue, obviously ...


-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472
occasional column at:  http://gnn.com/meta/imedia/webworks/allen/

A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html

Received on Monday, 23 January 2023 01:05:37 UTC