Re: New Working Draft : BECSS

On Fri, 5 Nov 1999, Jan Roland Eriksson wrote:

>> 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)

You misunderstood. I actually did mean <counter> _element_ -- I was
referring to a hypothetical XML language. 


> (and "clicked on" needs a qualifier too)

Ok, let me try again:

How would you make every <item> element with an attribute "writable"
increase another one of its attributes ("votes") by yet another one of
its attributes ("step") when it receives the 'onclick' event?

e.g.: 

   <catalogue name="parts">
      <item writable="writable" name="widget" votes="4" step="1"/>
      <item writable="writable" name="gizmo" votes="1" step="1"/>
      <item writable="writable" name="whatsit" votes="0" step="0.5"/>
      <item writable="writable" name="thing" votes="2" step="1"/>
   </catalogue>

Using BECSS, you can do this without even changing the markup:  

   item:after { content: attr(name) ": " attr(votes); }
   item[writable] { onclick: "this.getAttribute(votes) = ToString(
                              ToInteger(this.getAttribute(votes)) +
                              ToInteger(this.getAttribute(step)))"; }

Currently, one would need to add at least one "html:onclick" attribute
to every <item> element. Users are then unable to selectively override
this (since with HTML event attributes one can only enable or disable
all of the JavaScript, whereas with BECSS one can override individual
events:

   * { onclick: "" ! important; } 

...). BECSS also makes pages smaller (code appears only once) and is
easier to maintain. And so on.


> 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.

Need the functionality? Well, yes, since this could be a critical part
of a particular web-based application.

What good will it be to the user? Pages with the same content and same
behaviour would be smaller, so performance would be greater.

(The arguments for BECSS itself are the same as those proposing that
<font> be yanked from HTML and put into CSS in the first place.)

I don't see that it affects the user at all if BECSS properties are
allowed to be mixed with CSS1 properties in the same file. There, the
advantages are purely the developers'. And if a developer feels that
style and code should never appear together, then he need only not put
them in the same file!


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

My apologies for not being very clear -- I was not talking about a
static case as you describe, but of the dynamic and interactive
aspects of a page's _behaviour_. (Hence the B in BECSS.)


> 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.

Great, except if you are trying to use dynamic/interactive content. I
don't see how this affects the argument pro or against BECSS being
inside CSS files rather than being banned from them.

 
>> Find an equivalent way of doing...
> GoTo[1]

You have not provided an equivalent way of doing what I describe using
four lines or less of markup.

-- 
Ian Hickson
"So far, people have shown a reasonable amount of sense in evaluating
souls (whether they are properly priced)."
  -- Nick Gibbins; Author of http://totl.net/Soul/, 1999-10-05

Received on Sunday, 7 November 1999 14:16:58 UTC