- From: Orion Adrian <oadrian@hotmail.com>
- Date: Thu, 08 Jul 2004 14:35:21 -0400
- To: www-style@w3.org
>On Wed, 07 Jul 2004 16:19:17 -0400, Orion Adrian <oadrian@hotmail.com> >wrote: > > > > >I idle in #css on efnet (SkierX) and we attempt to help people with a > > >slew of questions regarding CSS everyday. I cannot recall a single > > >instance in which any question ever involved a problem comprehending > > >the syntax. There are individuals who have incorrect or poorly > > >written syntax, but in my experience everyone has grasped the basic > > >syntactical format (selector { property: value; }). I feel any > > >attempt to alter this could only result in a language that is more > > >difficult to understand. > > > > There is a sweet spot when defining grammar (i.e. a place between too >simple > > and too complex) that one wants to target in their design. > > > > The current system has lots and lots rules about interactions that >aren't > > described by the grammar. > > > > Box properties can't be set on something using the Inline model, but can >be > > with the Inline-Block model. This is just one of dozens of complex > > interaction rules. > >This is true. I would argue, however, that simply including >indications in the grammar as to how things relate doesn't necessarily >make understanding those relations any easier. Sure it does. That's the whole point of grammar. The entire purpose of grammar is to create relations between ideas in words. We can at a minimum do two things: 1) tightly couple objects can be tightly coupled in the grammar ensuring that when a user is coding they don't forget to set one when they set the other. 2) make it blatently obvious what objects and concepts go together. >For new people to the >language grasping the underlying conecpt of the various boxes and >positioning is a real hurdle. Wholistic comprehension is something >grammatical inclusions would not compensate for. There are also >solutions aside from grammatical ones to deal with this type of a >thing. No, but grammatical changes would at least give them a context, which they don't have now. It would also give them a place to start when trying to look these properties up. >Take Bradbury's TopStyle program for example. There is a "Style >Checker" feature in that will list various a) shortcommings of styles >in browsers and b) best practice solutions. Solutions such as this >would allow explanations to be included with the problem, where the >grammar would not. You really can't be effective with CSS until you >"get it." This means reading, reading and reading. Getting takes time, but you don't want to frustrate the people in the mean time. There's nothing more infuriating than making a change to code and not seeing it change the output. It's that property of CSS that has driven me to more fits of yelling at my computer than almost anything else. Point of note: I own TopStyle and I find that needing a program to do the job of the grammar is just a little irritating. It's possible to do the same with assember, but not necessarily very nice. > > Assembler is one of the simplest grammars, but it does little to help a > > person code. > > Operation Param [, Param] [, Param] > > > > But I don't like coding in assembler, nor do most people based on the > > quanities of people who flock to other languages. > > > >Are you suggesting that people would code more in assembler if the >grammar was revised? I don't think that is a) true or b) a good >comparison. Assembler is just a hope skip and a jump away from the >hardware and CSS is a document presentation language. Aside from their >rather basic syntax, they are about as far apart on the language >spectrum as you could get. 1) They're both declarative 2) Neither grammar shows your context, but both languages have context. Almost every other language out there today is one that abstracts assembler. Take a simple if then else structure. You can do it in assember, but it's not very pretty. The point of grammar is to take commonly used structures and specialize them to 1) make them easier to specify and 2) make them easier to remember. Orion Adrian
Received on Thursday, 8 July 2004 15:16:09 UTC