Re: Allow whitespace after "rect" function identifier

Philip TAYLOR wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Besides CSS being AIUI not a programming language and thus there 
>> are no "CSS programmers" (but only CSS authors),
> I would respectfully suggest that CSS is a declarative programming 
> language by any reasonable definition of that term.


"A programming language or computer language is a standardized
communication technique for expressing instructions to a computer.
It is a set of syntactic and semantic rules used to define computer
programs." [Wikipedia] / "A formal language in which computer
programs are written." [FOLDOC]

"A computer program tells a computer what to do. Typically, what to do
to or with some data. 'Program' is generally considered as a separate
concept/entity from 'data'." [Wikipedia]

"computer program ==> software: The instructions executed by a computer,
as opposed to the physical device on which they run (the 'hardware')."

"(computer) program: a series of instructions which can be put into a
computer in order to make it perform an operation" [Cambridge]

"programming language: An artificial language used to write instructions
that can be translated into machine language and then executed by a
computer." []

CSS particularly does not "describe relationships between variables
in terms of functions or inference rules" [FOLDOC2], since there are no
variables in CSS.  [CSS2] states that CSS is "a style sheet language
that allows authors and users to attach style (e.g., fonts, spacing,
and aural cues) to structured documents (e.g., HTML documents and XML

So CSS is not a programming language, especially not a declarative
(programming) language.







>> style guides for programming languages usually recommend to write 
>> whitespace before paranthesed expressions only if it fits the 
>> previous code.  The "Code Conventions for the Java Programming 
>> Language" [1], e.g., recommend to write whitespace before 
>> conditional expressions being used as arguments of conditional 
>> statements (in general: keywords followed by paranthesis): [...]
> It would be interesting to know what fraction of practising Java 
> programmers (a) are aware of that recommendation, and (b) are 
> prepared to follow it.

Both questions are better asked in a newsgroup dealing with the
language, here* and the like.

>From what I know, Java IDEs tend to support that recommendation,
especially in their Pretty Printing/Auto-Format features.
Particularly eclipse (3.0M6), which I am using and where IBM
WebSphere products are based upon, follows the Java Code Conventions
by default.  I also know of universities in my country (Germany)
which disapprove code from their students of Computer Science if
these Conventions are not obeyed.  See Google results for "Java
Code Conventions" to see that and why those Conventions are widely

>> Since rect(...) is defined as a function by section 4.1.1 of the 
>> CSS2 Specification and its upcoming revision 1,
> If "rect (...)" [sorry, space crept in automatically) is defined as a
>  function, does that not add weight to my argument that CSS is a 
> programming language ?

No.  That an artificial language defines tokens as functions
does not qualify it as a programming language.

> [...] A programmer (or author, to avoid further argument about the
> exact nature of CSS) should surely be free to express his/her ideas
> in any way which seems to him/her to clarify his/her intent, provided
> only that his/her chosen way does not introduce ambiguity ?  [...]

Ambiguitity is the core problem of your suggestion:

>> [...] However, this nevertheless requires careful consideration:
>> if "clip" is likely to become part of a composed property (like 
>> "border"), the allowed whitespace would then aggravate parsing of 
>> the value of that property.
> That point I willing concede.

Thinking it over again: So if whitespace before the paranthesis of the
rect(...) function (what whitespace exactly?) would be allowed, for the
sake of uniformity whitespace must be allowed before paranthesis for all
function identifiers, including rgb(...).  That particular function may
already be used in the composed "border-color" property, e.g.:

 border-color:rgb(0, 0, 0) rgb(127, 0, 0) rgb(255, 0, 0) rgb(0, 127, 0);

This is parsed easily (though mine is most certainly not be the most
efficient approach and a real CSS parser surely works differently):

1) Splitting by ":" to get property name and value.

   property name:
   property value:
     rgb(0, 0, 0) rgb(127, 0, 0) rgb(255, 0, 0) rgb(0, 127, 0)

2) Splitting property value by whitespace that is not preceded by ","
   (PCRE: /(?!,)\s+/):


3) Iterating a resulting array, one could first strip the trailing ","
   and ")".  If an item starts with "rgb(", strip that prefix and read
   2 more items that therefore must be color components.  Otherwise
   the item is a keyword and the next item is part of a new property

You suggest allowing parantheses of functions to be preceded by
whitespace, like

  border-color:rgb (0, 0, 0) rgb (127, 0, 0) rgb (255, 0, 0) rgb
(0, 127, 0);

Since that would be optional to support the current grammar, too,
composed properties are no longer as easy/efficient to parse, since
whitespace then not only delimits components of the composed property
but also function identifier and function arguments.  Now which means
which?  One wants to avoid such ambiguities.


Please do not Cc: me, I am subscribed to the lists/groups I post to.
Sorry in advance if you are subscribed, too.

Received on Sunday, 4 April 2004 13:34:41 UTC