Re: The style agenda
A few procedural points, then on to the meat.
| 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.
| > | 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',
| > | 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 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 (firstname.lastname@example.org) 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