Re: The style agenda
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 have suggested teaming up to write a new, complete proposal -- but
not a completely new proposal. We have a number of proposals from
which we can do some cutting & pasting. I have started working on such
a document (http://www.w3.org/hypertext/WWW/Style/css/draft.html) and
will happily continue unless other people have better strategies.
> is called a "Draft Specification," yet remarks
> "The purpose of this document is to keep track of ideas and suggestions
> related to the cascading style sheet proposal. It's a scratchpad."
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!
> says bluntly, "Discussions take place in email@example.com."
Blunt it was. Rephrased.
> 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!
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?
Some people have privately suggested that we form a new working group
within IETF. This may be an option in the future, but for now I think
we should concentrate on finding/developing a commmon foundation.
> | 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..
> | 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!
Perhaps there are ways to cleanly avoid conflicts?
> | For example: TeX uses `boxes & glue', DSSSL has a `page model &
> | flow ojects', the simple model that I described has a page
> | model with five areas each of which is filled with a continuous
> | stream of words. And how about non-visual media?
> Yes, well, who are we and what are we doing? I don't need a style
> sheet for nonvisual media, but if "sound alternatives" could be
> specified in a graphical style sheet that presumably would be a
> plus for the blind (in the manner of ALT).
One of the reasons why I like the term "style sheet" is that it's
neutral with regard to the visibility of the medium.
"H1: speech.volume = 50db" should be within reach.
> | 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
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.
> | We probably don't need things like macros right away, but
> | numerical and other operators might be useful.
> | And finally, we can invent a syntax (context-free, of course) and draw
> | up a list of style properties, being careful that we don't include
> | things that will make it impossible to add more powerful properties
> | later.
> Um, why do we have to write a programming language for this?
We shouldn't. We may need a little language, but not a programming
language. Simple, declarative statements will do just fine. If not,
use PDF or DSSSL. I vote for having +-/*, the ability to refer to
other properties, and simple constants.
When choosing the syntax for the declarative statements, user
legibility/writability should be #1.
> You admit that your model is insufficient for tables; why shouldn't
> 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.
Hakon W Lie, WWW project CERN, CH-1211 Geneva 23