Re: New Working Draft : BECSS

On Fri, 5 Nov 1999 05:30:40 +0000 (GMT), you wrote:

>On Wed, 3 Nov 1999, Jan Roland Eriksson wrote:

[...]

>> At the end of 1996, NS was suffering a lot of ridicule...

>JSSS had many other problems. The fact that it contained executable
>code was a minor detail.

JSSS was an attempt to create a style sheet language that happened to
fall off "on the other side of the razor blade edge". The fact that the
specific proposal as such did not make an A+ at school does not take
away the principle behind it. It was still a base for a possible client
side DSSSL-light.

It used client side _executable_code_ to manipulate a DOM (which at that
time was not defined into any detail either)

>> The line has to be drawn somewhere and I say that no executable
>> code, not even in it's absolute simplest form, as in a function call
>> to a scripting language as a property value, should be let in there,
>> period.
>
>That is simply unrealistic.

Of course not. It's just a matter of deciding on what side of the "razor
blade edge" you want to fall off, because not many but "magicians" can
walk it for long without being hurt in the process.

And you need to qualify "unrealistic"

>How would you make every <counter> element with an attribute
>"writable" increase one of its attributes by one of its other
>attributes when clicked on?

(there are no <counter> _elements_ that I know of)
(and "clicked on" needs a qualifier too)

[1]
By giving up the "I want to be in control" attitude and ask my self if I
really need this functionality to start with, and more important, what
good will it be to the user.

Inherent in proper markup you already have the structure that is needed
to "extract" the nesting and eventual "counting" attributes of list
elements.

There's always this issue of trying to decide how to use the _structure_
of a document when it comes to presentation of it in any given
situation. But the basis is to let the user decide on that first of all
and all s/he has to go on is the _structure_ at first.

For all you know only parts or nothing of scripts or CSS may pass
through to your end user. I myself is sitting happy behind a damned good
proxy/firewall at work. It strips out everything but passive info in
docs and I'm just happy with that.

Our main suppliers of components knows this too and they have all made
provisions to make their web sites available to us in the form we need
them, i.e. in the form they need them to make money on our activities.

>With BECSS it is easy...
[...]
>Find an equivalent way of doing...

GoTo[1]

>On Wed, 3 Nov 1999, Håkon Wium Lie wrote:
>> I'm happy for these to live in the same file as long as they're not
>> labelled "text/css". We could find a new Content-type for the mix of
>> declarative CSS and imperative whatever.

>Ok, fine, let's register a new MIME type "application/css"

Ok, we can always find out about a proper MIME type...
compromises are Ok in any given situation. But why don't you go all the
way to create a DSSSL-light proposal? I'm pretty sure that all those
DHTML'ers out there would love you for it.

>I don't mind what its called, so long as it can do what I want! :-)

GoTo[1] (if you ever managed to arrived here after that last GoTo :)

-- 
Jan Roland Eriksson <rex@css.nu> .. <URL:http://css.nu/>

Received on Sunday, 7 November 1999 11:46:01 UTC