Re: BECSS again (Was: Re: M$ proprietary CSS tags)

On Wed, 17 Nov 1999 10:16:13 +0100, Daniel Glazman
<Daniel.Glazman@der.edf.fr> wrote:

>Jan Roland Eriksson wrote:
[about BECSS]

>> Have you ever tried to think a bit about what might
>> be "wrong" with it?

>A smiley attached to that last question could have been useful.

Well, I thought that question was pretty serious, more on that later.

>Do you really think we discuss a standard without measuring the
>benefits *and* the risks ?

No discussions on that in the WD though?

>> Yes, discussions in (almost) "closed rooms"...
>...that old issue about W3C process vs. IETF process.
>I don't want to discuss that. Drop a mail to TBL if you want.

Nah, he's probably busy enough without me adding to it.
But since you bring his name up...

  "The concept of the web is of universal readership.
   If you publish a document on the web, it is important
   that anyone who has access to it can read it and link to it."
                             -- Tim Berners-Lee

BECSS as proposed has a potential to violate that statement. And the www
is on-topic, both the style list and ciwas have www in their names.

>> If you want to _really_discuss_ BECSS, you are welcome to do that here,
>Excerpt from the BECSS draft :
>	The working group would like to receive feedback:...
>	...mailing list www-style@w3.org

Ok, if you insist, this msg is cross posted to the style list

>You have things to say. Say it in www-style or understand that I can
>then be the only group member to read you.

Nah, slim chance, there are a lot of "lurkers" here in ciwas, even the
"once that counts"

>> CSS is _not_ to be reshaped into any form, that even resembles a client
>> side scripting language. I.e. keep the control structures out of there.

>Your personal opinion only. "You believe that CSS is _not_...", not "CSS
>is _not_ ...".

I can work for it though, as you will find out.

  "In HTML, scripts are embedded into the document
   and a site editor has to duplicate a script in all
   documents that have to use it."

Either this is badly formulated or members of the WG have problems
understanding the SCRIPT element as defined in the HTML4 DTD.

  <!ELEMENT SCRIPT - - %Script; -- script statements -->
  <!ATTLIST SCRIPT
    charset %Charset;  #IMPLIED  -- char encoding of linked resource --
    type %ContentType; #REQUIRED -- content type of script language --
    src  %URI;         #IMPLIED  -- URI for an external script --
    defer (defer)      #IMPLIED  -- UA may defer execution of script --
  >

See that "src" attribute first of all? It can be used to keep a script
in a separate file, to be requested by the UA's from several separate
pages if needed. To me that statement in the WD looks wrong.

See that "type" attribute then? with its #REQUIRED status. May I remind
you all that every single reference to a SCRIPT element in the WD seems
to be in syntax error. (then again, the SCRIPT element may have to be
redefined to be of use in BECSS, but of curse the WD makes no note about
that)

Ok then, let's accept for a minute that all the whole "kit and kaboodle"
of an HTC is really to be pulled into a STYLE element, as the last
example on the WD indicates.

How are we going to pull that off? The STYLE element has content model
of CDATA, the HTML parser could not care less about what's in there,
except it looks for the first occurrence of '</' to go back into parsing
mode again. No HTTP request will come from there of course.

So it will be up to the CSS engine to do the HTTP request for that HTC,
and then it will find a (mysterious) SCRIPT element in there that has to
be sent over to the script engine for processing.

All this calls for a "marriage" between the CSS engine and the script
engine. If this gets implemented (heaven forbid) will it ever be
meaningful to be in a browsing situation where scripting can not be
used? Give some thoughts to security aware fire wall admins, robots
etc...

And to add to that, this one is a killer of course...

  @script {
    var count = 0;
    function checkCount() {
      if (document.getElementsById("radio").value == "add") {
        count++;
      }
      else {
        count--;
      }
    }
  }

It looks so innocent as written in the WD, but we can all imagine how
"much fun" it will be for the average "deziner d00de" to start
generating what would appear to be real content to the rendered page
through a mechanism like this one. It can be done through scripting
already today, but why on earth is it necessary to "pollute" CSS the
same way? Any way, the street would now, yet again, be paved to break
another old maxim about the www.

  "A (complete) resource stored within the www shall be
   uniquely identified by a single URL"

FRAMES took the first shot at this www principle, now BECSS comes to
help reload the gun.

Spreading out info in separate locations that has to be combined in the
UA in order to get the full meaning of it, is not a way to go.

Leave CSS alone, it should stay as a safe and sound descriptive language
only, to be relied on in decent implementations.

Also this one looks "dangerous" to me.

  "Experimental implementations are encouraged,
   as long as they are clearly marked as experimental."

That "experimental" mark have never worked that good before, and to me
it looks like something is already "cooking" within BECSS, regardless if
it becomes a W3 rec or not.

-- 
Jan Roland Eriksson <jrexon@newsguy.com>
<URL:http://extra.newsguy.com/%7Ejrexon/>

Received on Thursday, 18 November 1999 16:15:03 UTC