NEWS: Further Netscape Information Regarding CSS
Mark A. Fuller
>In addition to my original post,
Maybe my news server is having problems, but I didn't see an original
post.
>... The new NGLayout engine for Netscape 5.0, is a rewrite and "will
>be much more modular and extensible". In other words, it will be more
>flexible to handle new features.
>
>I hope this helps those who are concerned about Netscape Navigator's future
>with regard to CSS.
That's good news indeeed. Although calling it news seems odd since the
same info has been available on "Mozilla".org for quite some time.
While it sounds good and I hope it pans out, the impression I get is
that it won't be readily available for a very long time, perhaps an
incredible 1 1/2 years since 4.0 -- during which time MS will
presumably have had 3 major releases. I hate to be cynical, but there
could be a great deal of damage to undo from that kind of
responsiveness.
As the AVIS commercial goes, "being number two, we try harder". I'm
afraid NS isn't too far from that reality. Given the past, it may very
well be a good thing.
Mark
Second Amendment Law Library, recent legal scholarship at:
http://www.2ndlawlib.org/
soni...@my-dejanews.com
has a lack of support for much of CSS 1.
In my previous post, I explained they are still committed to supporting
standards but it has been difficult for them to add stylesheet features
because of the "convolutedness of the current layout engine". Instead, the
team of programmers hacked as many features as they possibly could that it
was never designed to do and "it has been extremely difficult to extend and
maintain". The new NGLayout engine for Netscape 5.0, is a rewrite and "will
be much more modular and extensible". In other words, it will be more
flexible to handle new features.
I hope this helps those who are concerned about Netscape Navigator's future
with regard to CSS.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Roger
Fuller) wrote:
>While it sounds good and I hope it pans out, the impression I get is
>that it won't be readily available for a very long time, perhaps an
>incredible 1 1/2 years since 4.0 -- during which time MS will
>presumably have had 3 major releases.
Oh, please! Three *major* releases in such a short space of time?
If they needed to do that then MS deserves to go bankrupt.
On a different note perhaps that is exactly what they deserve. I
read recently that parts NT4 are programmed as though the year
2000 isn't a leap year and other parts as though it is.
Apparently this should be fixed in service pack 4.
--
Roger
Mark A. Fuller
(Roger) wrote:
>On 12 Jul 1998 21:13:01 -0700, mfu...@2ndlawlib.org (Mark A.
>Fuller) wrote:
>
>>While it sounds good and I hope it pans out, the impression I get is
>>that it won't be readily available for a very long time, perhaps an
>>incredible 1 1/2 years since 4.0 -- during which time MS will
>>presumably have had 3 major releases.
>
>Oh, please! Three *major* releases in such a short space of time?
They've already had one. A second is on the way and had been slated
for inclusion in Win98. If NS gets 5.0 out before the end of the year
then I doubt a third major release would occur. If it drifts into next
year it becomes less unrealistic.
>If they needed to do that then MS deserves to go bankrupt.
MS going bankrupt? Are they having financial woes? Last I heard they
were going to buy our government and issue Microsoft Dollars as the
currency of the realm. :)
>On a different note perhaps that is exactly what they deserve. I
>read recently that parts NT4 are programmed as though the year
>2000 isn't a leap year and other parts as though it is.
>Apparently this should be fixed in service pack 4.
Welcome to the triple-aught issue. You'd be surprised who hasn't even
validated their product's compliance. Like so much of this, my guess
is they didn't even know about the leap year problem until they tested
triple-aught, testing which usually includes a feb 28-29 test. If
they could find they source they're doing much better than most
companies I have personal knowlege of. :)
Thilo Pfennig
> In my previous post, I explained they are still committed to supporting
> standards but it has been difficult for them to add stylesheet features
> because of the "convolutedness of the current layout engine". Instead, the
I can hardly believe this. First it is that simple: There are different
colors,fonts and graphic-formats. Then there are possible
script-languages and stylesheets that deal with that. As far as I know
there are external engines for Java and Javascript in Netscape? So why
isn't there an external enhancement for "Stylesheets"?
And I don't understand why something simple like:
Q {font-style: italic} does not result in italics in my Communicator
(Mac,4.03). I am not a programmer, but I think it should be easy to
define, what forces the browser to do italics. I really mist that
feature for my own definition of a quotation
> maintain". The new NGLayout engine for Netscape 5.0, is a rewrite and "will
> be much more modular and extensible". In other words, it will be more
> flexible to handle new features.
I can not image why Netscape builded a code which was not so open to
extensions and new features. Everybody knew that the tempo of new
technolgy is increasing daily. The reason could not be more stability,
because this is still a problem!
> I hope this helps those who are concerned about Netscape Navigator's future
> with regard to CSS.
Well, let's see what it really does...
--
Thilo Pfennig
vi...@2012.org
D-97421 Schweinfurt
James M. Cape
Don't forget that the original layout engine was made
quite a while back. Stylesheets weren't around then,
and a top of the line PC was a 486, so the programmers
had a lot more to think about than what the next
generation of websites would do. After all, until David
Siegel came along with some real design reqs., the
tag-soup browser idea seemed fine, and its treating the
tags as commands seemed like a good decision at the
time. Just like non-SGML compliance was "good" too.
Hindsight is 20/20.
Jim Cape
http://www.jcinteractive.com
"All animals are equal, some animals
are more equal than others."
-- George Orwell, Animal Farm
Thilo Pfennig
> Don't forget that the original layout engine was made
> quite a while back. Stylesheets weren't around then,
> and a top of the line PC was a 486, so the programmers
> had a lot more to think about than what the next
> generation of websites would do. After all, until David
> Siegel came along with some real design reqs., the
> tag-soup browser idea seemed fine, and its treating the
> tags as commands seemed like a good decision at the
> time. Just like non-SGML compliance was "good" too.
But I think StyleSheets were an idea in W3C, where Netscape is a member
(since when?) long before the official CSS1-Definition. And whatelse
should bother a software company as what the future will bring. maybe
they just waited too long? Also Netscapes authoring tools allways
collidated with the official HTML-proposals which deprecated the use of
style-elements like <B> and <I>. Communicator and N.Gold allways
translate <STRONG> into <B>, when importing external HTML-code. So I see
that people at Netcape seemingly did some things in full conscious
agagainst proposed standards!? Did they forget, that the whole internet
is based upon common standards? Don't they know that every violation of
a standard can be
1. a self-goal, because people begin to deprecate the use of
nonstandard-software (look at Mail-apps with stupid MIME-encoding, which
may cause non-readabiliy for a user)
2. hindering the development of the net and so less potential users.
The idea behind seems to me: Else we make the money,
, or no one!
BTW: What about Mozillas CSS2-capabilities?
..
quickly the browser maker is blamed for something that is equally the fault
of the standards committee.
While CSS and HTML have vastly different intentions and syntax, the
underlying data conveyance needs are basicly the same. It would have been
better design practice to
create CSS syntax from the parsing space already in the browser, i.e <label
name=value>
as opposed to label { name:value}. By all means we could have extended the
current
element parsing structure to emcompass the additional needs of CSS.
This would have made life easier for both browser makers as well as those
having to
create content with the new standard.
The creation of standards has some unspoken rules of creation , one of which
is
that one should leverage those exisiting standards in the space/context in
which the
new one will be parsed. While CSS can claim all sorts of linage outside of
the space/context of the browser, it cannot claim anything asside from
bastard status within the space they targeted.
I have had many long winded discusions in which everyone misses the point.
That being that while the concept of CSS is a bit different and valuable ,
it's conveyance needs are not really unique, and the only conclusion I can
reach is that the syntax was derived out of
politics or stupidity (If there is much a difference).
That simple syntactical design blunder is THE single most responsible reason
for poor implementation in the market.
Anyone got a beef with that statement? ;)
Thilo Pfennig wrote:
--
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=--
--=<[]>=- http://www.drclue.net
--=<[]>=- C++ HTML JavaScript JAVA VRML
--=<[]>=- CGI NSAPI TCP/IP SQL Sybase Informix (Interest In Oracle)
--=<[]>=- Dr. Clue's famous HTML/CGI guide.
--=<[]>=- http://www.drclue.net/F1.cgi/HTML/HTML.html
Arjun Ray
| Don't forget that the original layout engine was made quite a
| while back.
How far back? Early 1995, when they had to work out how to implement
tables? Summer 1994, leading up to the 0.9 beta?
| Stylesheets weren't around then,
They most certainly were. Only the programmers in question had a habit
of not paying attention.
| and a top of the line PC was a 486,
In Summer 94, you could use a 386 to view SGML documents, using
stylesheets. In fact, without stylesheets, you couldn't view SGML
documents at all -- but SGML documents have been viewable since the
'80s.
For HTML specifically, ViolaWWW had a stylesheet add-on (albeit
experimental), and MidasWWW was in a sense *entirely* stylesheet
driven.
I know it would be comforting to have history rewritten to the effect
that "stylesheets weren't around then", but this is nonetheless a
crass fabrication. The truth you want to whitewash is something like
this: "Since these programmers had no clue about stylesheets, it's not
surprising that they made no provision for them."
| After all, until David Siegel came along with some real design reqs.,
You need to go easy on the hagiography.
| the tag-soup browser idea seemed fine, and its treating the tags as
| commands seemed like a good decision at the time.
Decision? Try concept, or understanding. They *believed* tags were
commands.
| Just like non-SGML compliance was "good" too.
A consequence of the belief. "We'll do it all with tags."
| Hindsight is 20/20.
Hindsight? You mean no one knew any better? Gee, how comforting. No
wonder Marc A took such offense at Peter Flynn's intemperate reaction:
<URL:http://www.acl.lanl.gov/HTML_WG/html-wg-94q4.messages/0091.html>
(The first paragraph of which is actually a quote of
<URL:http://www.acl.lanl.gov/HTML_WG/html-wg-94q4.messages/0089.html>)
Seriously, if you want to give a history lesson, at least get your
facts right.
:ar
Jelks Cabaniss
> While CSS and HTML have vastly different intentions and syntax,
> the underlying data conveyance needs are basicly the same. It
> would have been better design practice to create CSS syntax from
> the parsing space already in the browser, i.e <label name=value>
> as opposed to label { name:value}. By all means we could have
> extended the current element parsing structure to emcompass the
> additional needs of CSS.
It sounds like you want FONT, or maybe FONT++. You can certainly continue
to use the Netscapisms incorporated in the 4.0 Transitional DTD -- nobody's
going to stop you. Personally though, I'd call it "tag soup".
CSS serves an *entirely* different purpose than "tags" in markup.
> That simple syntactical design blunder is THE single most
> responsible reason for poor implementation in the market.
>
> Anyone got a beef with that statement? ;)
Umm, yes. I'd rephrase it:
The tags-as-layout design blunder is THE single most
responsible reason for poor implementation in the market.
/Jelks
Tor Iver Wilhelmsen
uttered:
>This would have made life easier for both browser makers as well as those
>having to
>create content with the new standard.
No, as Arjun Ray has pointed out, CSS is hardly "new". Also, it _does_
serve an entirely different purpose: namely as a metasystem on top of
HTML. Using HTML-like syntax would only serve as confusion.
Not to mention that CSS syntax is far easier to parse than HTML.
Perhaps one should go the other way, and introduce
html {
head {
title { "My nice document" }
}
body {
p { text-align: justify; This text will be justified. }
}
}
But then you would be halfway to LaTeX. :-)
(What's next, will you complain that C preprocessor directives don't
follow C's statement syntax?)
--
"I had to upgrade the memory of my 8088 from to 256K to 640K just to play [Demon's Winter]."
- gmad...@usa.net
Tor Iver Wilhelmsen http://www.pvv.org/%7etoriver/
Jan Roland Eriksson
[...]
>No wonder Marc A took such offense
>at Peter Flynn's intemperate reaction:
><URL:http://www.acl.lanl.gov/HTML_WG/html-wg-94q4.messages/0091.html>
>(The first paragraph of which is actually a quote of
><URL:http://www.acl.lanl.gov/HTML_WG/html-wg-94q4.messages/0089.html>)
Wow, and me who has always looked upon PF
as a very nice and polite guy ;-)
--
Jan Roland Eriksson <r...@css.nu>
Mark Fuller
ar...@nmds.com (Arjun Ray) writes:
>On Fri, 17 Jul 1998 23:37:17 GMT,
>"James M. Cape" <jc...@jcinteractive.com> wrote:
>
>| Don't forget that the original layout engine was made quite a
>| while back.
>
>How far back? Early 1995, when they had to work out how to implement
>tables? Summer 1994, leading up to the 0.9 beta?
>
>| Stylesheets weren't around then,
>
>They most certainly were. Only the programmers in question had a habit
>of not paying attention.
apologize for Netscape, but it's understandable a commercial
company wouldn't jump at a working draft 2-3 years prior to it
becoming a standard. This is especially true in light of the
HTML 3.0 debacle of that approximate period.
Mark
Sue Jordan
>
> In article <360500bf....@news.newsguy.com>
> ar...@nmds.com (Arjun Ray) writes:
> >On Fri, 17 Jul 1998 23:37:17 GMT,
> >"James M. Cape" <jc...@jcinteractive.com> wrote:
> >
> >| Don't forget that the original layout engine was made quite a
> >| while back.
> >
> >How far back? Early 1995, when they had to work out how to implement
> >tables? Summer 1994, leading up to the 0.9 beta?
> >
> >| Stylesheets weren't around then,
> >
> >They most certainly were. Only the programmers in question had a habit
> >of not paying attention.
>
> CSS1 wasn't finalized until December 1996. Far be it from me to
> apologize for Netscape, but it's understandable a commercial
> company wouldn't jump at a working draft 2-3 years prior to it
> becoming a standard.
But they found sufficient time to throw together the JSSS proposal in
August '96 <URL:http://www.w3.org/Submission/1996/1/WD-jsss-960822>.
Instead of munging a proprietary stylesheet implementation, complete with
the ubiquitous <LAYER>, some real work might have been put into a proposal
that was already on the standards track.
> This is especially true in light of the
> HTML 3.0 debacle of that approximate period.
Perhaps there was hope that the fate that befell HTML 3.0 would befall
CSS1, leaving JSSS ready to fill the breech? Pfui.
Sue
[BTW, who are you _really_, and what have you done with Mark ;-)
Mark Fuller
Sue Jordan <SJA...@worldnet.att.net> writes:
>
>Mark Fuller wrote:
>>
>> In article <360500bf....@news.newsguy.com>
>> ar...@nmds.com (Arjun Ray) writes:
>> >On Fri, 17 Jul 1998 23:37:17 GMT,
>> >"James M. Cape" <jc...@jcinteractive.com> wrote:
>> >
>> >| Don't forget that the original layout engine was made quite a
>> >| while back.
>> >
>> >How far back? Early 1995, when they had to work out how to implement
>> >tables? Summer 1994, leading up to the 0.9 beta?
>> >
>> >| Stylesheets weren't around then,
>> >
>> >They most certainly were. Only the programmers in question had a habit
>> >of not paying attention.
>>
>> CSS1 wasn't finalized until December 1996. Far be it from me to
>> apologize for Netscape, but it's understandable a commercial
>> company wouldn't jump at a working draft 2-3 years prior to it
>> becoming a standard.
>
>But they found sufficient time to throw together the JSSS proposal in
>August '96 <URL:http://www.w3.org/Submission/1996/1/WD-jsss-960822>.
>
>Instead of munging a proprietary stylesheet implementation, complete with
>the ubiquitous <LAYER>, some real work might have been put into a proposal
>that was already on the standards track.
"summer 94" and "early 95" timeframe. Sure, you get up to q3 '96 and
you have a valid complaint about non-adoption of what became a standard
four months later. But projecting that back two years doesn't seem
fair.
Mark
Christian Weisgerber
> While CSS and HTML have vastly different intentions and syntax, the
> underlying data conveyance needs are basicly the same. It would have been
> better design practice to
> create CSS syntax from the parsing space already in the browser, i.e <label
> name=value>
> as opposed to label { name:value}. By all means we could have extended the
> current
> element parsing structure to emcompass the additional needs of CSS.
(You might consider wrapping your lines in a way that produces readable
text.)
Where does this obsession with CSS's syntax come from? I'd estimate that
writing the parser for the style sheet is just a minute fraction of the
work involved in really supporting CSS. It's rather negligible, really,
especially if your browser is already as bloated as Netscape is.
--
Christian "naddy" Weisgerber na...@mips.rhein-neckar.de
See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
Arjun Ray
ACU...@email.mot.com (Mark Fuller) wrote:
| In article <360500bf....@news.newsguy.com>
| ar...@nmds.com (Arjun Ray) writes:
| >
| >how to implement tables? Summer 1994, leading up to the 0.9 beta?
| >
| >| Stylesheets weren't around then,
| >
| >They most certainly were. Only the programmers in question had a habit
| >of not paying attention.
|
| CSS1 wasn't finalized until December 1996.
You've missed the forest for the trees. CSS1 specifically is relevant
only in that it's *a* spec. In the ciwah thread 'XML & CSS' a few days
ago, I offered archived evidence that the *concept* of stylesheets for
HTML browsers goes back to at least mid 93 (a proposal by Rob Raisch),
and at any rate, the concept has been integral to SGML based systems
from the beginning. I wrote:
: But the salient fact is that not only the concept of stylesheets but
: also the question of suitable syntax had been raised and discussed, at
: least once, a year before a certain browser came out. The relevant
: historical question, therefore, is why that browser -- one full year
: later -- had *nothing at all* in the way of processable stylesheets.
The issue raised by Thilo was precisely this: why is attaching
stylesheet information (never mind the specific form) so inherently
difficult for Netscape?
As it was, Netscape didn't come around to the *concept* of stylesheets
until their JSSS proposal of Summer 96: not just CSS1 but *any*
stylesheet spec had remained essentially alien to their processing
paradigm for *years*.
The reasons for this are no particularly mystery, only people still
want to peddle excuses.
| Far be it from me to apologize for Netscape, but it's understandable
| a commercial company wouldn't jump at a working draft 2-3 years prior
| to it becoming a standard.
Then, may we therefore dismiss any and all claims of Netscape being a
"leader" as barefaced lies? Will you challenge the next journo who
trots out such totemic guff?
| This is especially true in light of the HTML 3.0 debacle of that
| approximate period.
Approximate says it all, doesn't it? We'll just fudge that to mean "Oh
sometime in 1995". The historical record shows that the revision of
the HTML+ spec of Nov 93 was dubbed HTML 3.0 at the Geneva conference
in May 94. That was before the coding of the first Netscape browser
had even begun. The background of Peter Flynn's message was precisely
that: why did 0.9beta not only have so *little* of what had been
*previously* agreed upon as the "to do spec" for HTML? Why did it have
a clear preference for tag salad instead?
The commercial company pressed its own "concept". You can see the
effects, today. Hindsight? Baloney. This was *predicted*. Sheesh.
:ar
Arjun Ray
ACU...@email.mot.com (Mark Fuller) wrote:
| In article <6paka1$p...@bgtnsc03.worldnet.att.net>
| Sue Jordan <SJA...@worldnet.att.net> writes:
| >Instead of munging a proprietary stylesheet implementation, complete
| >with the ubiquitous <LAYER>, some real work might have been put into
| >a proposal that was already on the standards track.
CSS is a recommendation of a consortium. I know of no standards body
to have ratified it, or even asked to consider it.
| I was only addressing the claim that stylesheets existed in the
| "summer 94" and "early 95" timeframe.
They did. But they weren't of the CSS type. ViolaWWW had "proof of
concept" in 1993. The fact of the matter is that Netscape was against
the very idea of stylesheets for at least two years of its existence.
Essentially, they were adherents of a different "philosophy".
| Sure, you get up to q3 '96 and you have a valid complaint about
| non-adoption of what became a standard four months later.
The proximate reason for non-adoption is no big secret: the Netscape
codebase simply wasn't up to it.
| But projecting that back two years doesn't seem fair.
The preoccupation with CSS unfairly pre-empts the question of why
stylesheets of *some* form didn't get popularised in 1994. Or to put
the question another way, anticipating the media's frenzied leap onto
the Netscape bandwagon: why didn't Netscape have *any* stylesheet
capability for so long?
Oops. That must be an "unfair" question.
:ar
Arjun Ray
na...@mips.rhein-neckar.de (Christian Weisgerber) wrote:
| Where does this obsession with CSS's syntax come from?
From the lamnetable circumstance that it doesn't look like tag soup,
therefore isn't amenable to parsing as if it were tag soup, and
therefore inhibits its "integration" into a tag-soup paradigm.
| I'd estimate that writing the parser for the style sheet is just a
| minute fraction of the work involved in really supporting CSS. It's
| rather negligible, really,
Almost trivial, in fact. The real work, as you say, is in doing
something useful with the information parsed out.
| especially if your browser is already as bloated as Netscape is.
Shhh! There are sacred cows lurking...
:ar
..
Jelks Cabaniss wrote:
> .. <drc...@smtp.alink.net> wrote:
>
> > While CSS and HTML have vastly different intentions and syntax,
> > the underlying data conveyance needs are basicly the same. It
> > would have been better design practice to create CSS syntax from
> > the parsing space already in the browser, i.e <label name=value>
> > as opposed to label { name:value}. By all means we could have
> > extended the current element parsing structure to emcompass the
> > additional needs of CSS.
>
> It sounds like you want FONT, or maybe FONT++. You can certainly continue
> to use the Netscapisms incorporated in the 4.0 Transitional DTD -- nobody's
> going to stop you. Personally though, I'd call it "tag soup".
The difference between CSS and HTML syntax needs is extreamly slim.Why would
you call it tag soup to use an exisiting parser to interpret CSS?
> CSS serves an *entirely* different purpose than "tags" in markup.
syntax and purpose are two different things. Is your claim that HTML with minor
exntensioncould not convey the data in CSS? If you believe this , plese prove
it.
> > That simple syntactical design blunder is THE single most
> > responsible reason for poor implementation in the market.
> >
> > Anyone got a beef with that statement? ;)
>
> Umm, yes. I'd rephrase it:
>
> The tags-as-layout design blunder is THE single most
> responsible reason for poor implementation in the market.
Prove it!. The syntax has much impact on the size of programs and efficiancybut
there is nothing about HTML in general that with a little extension could not
convey everything in the concept of CSS, and do so with as much punch as the
basterdized CSS syntax.
PROVE ME WRONG!!!!!
> /Jelks
..
> On Thu, 23 Jul 1998 20:06:31 -0700, ".." <drc...@smtp.alink.net>
> uttered:
>
> >This would have made life easier for both browser makers as well as those
> >having to
> >create content with the new standard.
>
> No, as Arjun Ray has pointed out, CSS is hardly "new". Also, it _does_
> serve an entirely different purpose: namely as a metasystem on top of
> HTML. Using HTML-like syntax would only serve as confusion.
emm I don't believe for a moment that carrying the CSS concept onthe back of an extended HTML
syntax would confuse anyone anymore
than the CSS syntax itself , and of course it's inconsistant naming conventions
> Not to mention that CSS syntax is far easier to parse than HTML.
> Perhaps one should go the other way, and introduce
I respect your attempt to amuse me. Exactly how is parsing a new syntax easier than parsingan
existingly parsed syntax?
> html {
> head {
> title { "My nice document" }
> }
> body {
> p { text-align: justify; This text will be justified. }
> }
> }
>
> But then you would be halfway to LaTeX. :-)
> (What's next, will you complain that C preprocessor directives don't
> follow C's statement syntax?)
No , as at the level of C language content creation , we have surpassed the skill set of
mostcontent creators. The CSS syntax has no valid reason that anyone has presented
for even exisiting. Only the CSS concept has validity.
> --
> "I had to upgrade the memory of my 8088 from to 256K to 640K just to play [Demon's Winter]."
> - gmad...@usa.net
>
> Tor Iver Wilhelmsen http://www.pvv.org/%7etoriver/
--
..
> In article <35B7FA37...@smtp.alink.net>, .. <drc...@drclue.net> wrote:
>
> > While CSS and HTML have vastly different intentions and syntax, the
> > underlying data conveyance needs are basicly the same. It would have been
> > better design practice to
> > create CSS syntax from the parsing space already in the browser, i.e <label
> > name=value>
> > as opposed to label { name:value}. By all means we could have extended the
> > current
> > element parsing structure to emcompass the additional needs of CSS.
>
> (You might consider wrapping your lines in a way that produces readable
> text.)
Sounds like you were board and had no actuall position here , and decided tobloat
several million user's news readers with a block of nothing, wasting eveyones
time.
> Where does this obsession with CSS's syntax come from?
From good protocol design practice , developed over twenty years of
experiance.Where does your position come from ?
> I'd estimate that
> writing the parser for the style sheet is just a minute fraction of the
> work involved in really supporting CSS.
Every part of a problem merits skillfull consideration , and demands as a matter
of basicdesign skill that you re-use whatever syntax and protocol that could be
realisticly
leveraged
> It's rather negligible, really,
> especially if your browser is already as bloated as Netscape is.
Well it sounds like your enviting me to a browser debate , in which you've
declareda particular product to be seperior. If your foolish enough to decry a
superior product
in the browser arena , you deserve a good thrasing.
Perhaps on the otherhand with closer examination of your views , you might
realise that each of the two major browsers is totaly shit in one way or another
, and that those browsers have very little to do with the quality of the
basterdized CSS syntax
Arjun Ray
| It amazes me how quickly the browser maker is blamed for something
| that is equally the fault of the standards committee.
It amazes me how quickly nonexistent "committees" get invoked to
whitewash the failures of a particular browser maker.
| While CSS and HTML have vastly different intentions and syntax, the
| underlying data conveyance needs are basicly the same.
You can repeat this all you like, it still doesn't have a shred of
truth in it. It's much more likely that you've failed to grasp the
"data conveyance needs" involved.
A HTML document is the linearized representation of a hierarchical
structure of elements containing other elements and/or text. As such,
it's a *descriptive* specification of a tree-like data structure.
A CSS document is a *prescriptive* specification for the processing of
such tree-like structures, with actions based on contextual selection
of appropriate "nodes". Such contextual selection is the key to all
tree-transformation languages: CSS happens to be one of the simplest
kind, where not much more than "node annotation" occurs.
In general, the "action" part of the classic pattern-action structure
doesn't really matter much (it only serves to classify the language
according to its Turing (in)completeness); much more relevant is the
sophistication of the "pattern" part. That's why the CSS syntax of
'property: value' happening to map relatively neatly most of the time
to the 'name="value"' syntax of HTML is a red herring. Specifying a
tree-oriented *conditional* ('descendant of', 'sibling of', 'ancestor
of') is very poorly served by analogous "tags".
| It would have been better design practice to create CSS syntax from the
| parsing space already in the browser, i.e <label name=value> as opposed
| to label { name:value}.
Have you seen the original XSL draft? Have you seen the discussions on
the XSL-List at Mulberrytech? If you think that this simple-minded
analogy is all there is to CSS, you have some homework to do.
| By all means we could have extended the current element parsing
| structure to emcompass the additional needs of CSS.
Yeah, right. "Element parsing structure" indeed. It took the specimens
involved over three years to get quote-balancing right, and lo! it
must have been "extensible" all the while.
| This would have made life easier for both browser makers
Why don't you study the Mozilla source code and write a report on
this?
| The creation of standards has some unspoken rules of creation , one of
| which is that one should leverage those exisiting standards in the
| space/context in which the new one will be parsed.
The parsing of standards?? Rather than offer such gibberish, could you
offer a credible reference where your "unspoken rules" are explained
in plain English? Thanks.
:ar
Arjun Ray
Hmm. Is this what you mean?
:ar
HOW SOME SPECS LIVE FOREVER (Anon.)
The US Standard railroad gauge (distance between the rails)
is 4 feet, 8.5 inches. That's an exceedingly odd number.
Why was that gauge used? Because that's the way they built
them in England, and the US railroads were built by English
expatriates.
Why did the English people build them like that? Because the
first rail lines were built by the same people who built the
pre-railroad tramways, and that's the gauge they used.
Why did "they" use that gauge then? Because the people who built
the tramways used the same jigs and tools that they used for
building wagons, which used that wheel spacing.
OK! Why did the wagons use that odd wheel spacing? Well, if
they tried to use any other spacing the wagons would break on
some of the old, long distance roads, because that's the spacing
of the old wheel ruts.
So who built these old rutted roads? The first long distance
roads in Europe were built by Imperial Rome for the benefit of
their legions. The roads have been used ever since.
And the ruts? The initial ruts, which everyone else had to match
for fear of destroying their wagons, were first made by Roman
war chariots. Since the chariots were made for or by Imperial Rome
they were all alike in the matter of wheel spacing.
Thus, we have the answer to the original questions. The U.S.
standard railroad gauge of 4 feet, 8.5 inches derives from the
original specification for an Imperial Roman army war chariot.
So, the next time you are handed a specificaton and wonder
what horse's ass came up with it, you may be exactly right,
because the Imperial Roman Chariots were made to be just wide
enough to accommodate the back-ends of two war horses.
:ar
James M. Cape
>
> On Fri, 24 Jul 98 12:49:46 MST,
> ACU...@email.mot.com (Mark Fuller) wrote:
>
> | Sure, you get up to q3 '96 and you have a valid complaint about
> | non-adoption of what became a standard four months later.
>
> The proximate reason for non-adoption is no big secret: the Netscape
> codebase simply wasn't up to it.
...which is what I said to begin with. The "need" to keep up with
Microsoft's browser releases forced them to screw with the
numbering (NS 3.0 was supposed to be 2.1, 2.5 or something along
those lines), and not introduce a new engine when they should
have (4.0), but rather to simply hack in sub-par "support". Of
course, all this is water under the bridge, as 5.0 should have
quite extensive support for stylesheets.
Tor Iver Wilhelmsen
uttered:
>I respect your attempt to amuse me. Exactly how is parsing a new syntax easier than parsingan
>existingly parsed syntax?
Simple: It would require parsing, whereas for instance Netscape does
not parse HTML, but does something on each tag it encounters - which
is something different.
>No , as at the level of C language content creation , we have surpassed the skill set of
>mostcontent creators. The CSS syntax has no valid reason that anyone has presented
>for even exisiting. Only the CSS concept has validity.
The CSS syntax is well suited for its task. Can you come up with a
"HTML-like" alternative, or is it all just hot air?
Arjun Ray
<jc...@jcinteractive.com> wrote:
| Arjun Ray wrote:
| > The proximate reason for non-adoption is no big secret: the
| > Nestcape codebase simply wasn't up to it.
|
| ...which is what I said to begin with.
Um, no. You tried to "explain" it, with the usual round of
semi-plausible excuses. The fact of the matter is that the Netscape
programmers were clueless, aggressively so.
I'm sorry, but I'm allergic to apologetics.
:ar
..
Tor Iver Wilhelmsen wrote:
> On Fri, 24 Jul 1998 23:36:48 -0700, ".." <drc...@smtp.alink.net>
> uttered:
>
> >I respect your attempt to amuse me. Exactly how is parsing a new syntax easier than parsingan
> >existingly parsed syntax?
>
> Simple: It would require parsing, whereas for instance Netscape does
> not parse HTML, but does something on each tag it encounters - which
> is something different.
>
> >No , as at the level of C language content creation , we have surpassed the skill set of
> >mostcontent creators. The CSS syntax has no valid reason that anyone has presented
> >for even exisiting. Only the CSS concept has validity.
>
> The CSS syntax is well suited for its task. Can you come up with a
> "HTML-like" alternative, or is it all just hot air?
Although I did not spend but 10-15 minutes roughing out some general stuff, I could see
something like the following flavorings, with a little more added of course.
<STYLE ...>
<BODY margin="1em"
font.family="serif"
line.height="1.1"
bgcolor="white"
color="black" >
<H1, H2, H3, H4, H5, H6, P, UL, OL, DIR, MENU, DIV,
DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, HR
display="block">
<B, STRONG, I, EM, CITE, VAR, TT, CODE, KBD, SAMP,
IMG, SPAN
display="inline">
<LI display="list-item">
<H1, H2, H3, H4
margin.top="1em"
margin.bottom="1em">
<H5, H6 margin-top="1em">
<H1 text.align="center">
<H1, H2, H4, H6 font.weight="bold">
<H3, H5 font.style="italic">
<H1 font.size="xx-large">
<H2 font.size="x-large" >
<H3 font.size="large" >
<B, STRONG font-weight="bolder"> <!-- relative to the parent -->
<I, CITE, EM, VAR, ADDRESS, BLOCKQUOTE font.style= "italic">
<PRE, TT, CODE, KBD, SAMP font-family="monospace">
<PRE white-space="pre">
<ADDRESS margin.left="3em">
<BLOCKQUOTE margin.left="3em" margin.right="3em">
<UL, DIR list.style="disc">
<OL list.style="decimal">
<MENU margin="0"> <!-- tight formatting -->
<LI margin.left="3em">
<DT margin.bottom="0">
<DD margin.top="0" margin.left="3em">
<HR "border.top="solid"> <!-- 'border-bottom' could also have been used -->
<A link="blue" vlink.color="red" alink="lime">
<IMG border="2px" border.line=solid link.color="blue" vlink=red active=lime>
</STYLE>
> --
> "I had to upgrade the memory of my 8088 from to 256K to 640K just to play [Demon's Winter]."
> - gmad...@usa.net
>
> Tor Iver Wilhelmsen http://www.pvv.org/%7etoriver/
--
Arjun Ray
".." <drc...@smtp.alink.net> wrote:
| Jelks Cabaniss wrote:
| > CSS serves an *entirely* different purpose than "tags" in markup.
|
| syntax and purpose are two different things. Is your claim that HTML
| with minor exntension could not convey the data in CSS? If you believe
| this , plese prove it.
Your request for proof is absurd. You've left "extension" undefined,
so the qualifying "minor" is moot. *What* impossibility did you want
demonstrated?
In fact, it's you who believes that "with minor extension" something
you call HTML can "convey the data in CSS". Why don't *you* prove it?
| there is nothing about HTML in general that with a little extension
| could not convey everything in the concept of CSS
Define
(a) "the concept of CSS", as you understand it.
(b) "a little extension", as you understand it.
Perhaps you think "HTML syntax" was concocted sui generis at NCSA (or
Mountain View), so "extension" actually means adding "operators" of
one kind or another, and there's nothing to disallow inventing such
"extensions" right and left. Unfortunately, the only known formal
definition of HTML is as a SGML application, which inter alia happens
to *fix* the lexical specification. Not to mention that large portions
of that specification -- defined in an international standard since
1986 -- have yet to be supported in the soi-disant parsers you're so
eager to "leverage". ("We're so k3wl, we've implemented such a small
subset that now we hafta *extend* it!")
Of course, you could take issue with this and argue that the normative
reference to SGML should be abandoned. In that case, however, you'll
first have to provide a formal specification for alternate syntax
before you can propose to "extend" it. (You *do* know what writing a
specification involves, I hope?)
But before you concoct your "little extensions", it behooves you to
consider prior art in the area. At a minimum, this will clarify the
"concept of CSS" for you, that is, what your "little extensions" will
have to be for.
The rubric is tree transformation. There are already quite a few
processors available; not surprisingly, some are full programming
languages as we would understand the term. For instance, Omnimark[1]
and Balise[2]. The international standard in this case happens to be
DSSSL[3], implemented in a program such as Jade[4]. Study the syntax
of each and you'll find that one reminds you of Basic, another of C,
and a third of Lisp. No tags. Oops, none of them were from developers
who had any idea of what they were doing, right? Dr. Clue knows
better.
[1] <URL:http://www.exoterica.com/>
[2] <URL:http://www.balise.berger-levrault.fr/>
[3] <URL:http://www.sil.org/sgml/dsssl.html>
[4] <URL:http://www.jclark.com/>
OK, a full programming language is overkill. Consider, then, a
specialized tool such as MetaMorphosis[5]. Finally, something that
looks like tags! With a whole buncha "extensions", too. Hooray!
[5] <URL:http://www.ovidius.com/>
Look more closely, though, and it becomes clear that this is *not*
"tags with extensions". In fact, the angle brackets are a small part
of a larger comprehensive syntax that has *nothing* to do with the
Reference Concrete Syntax of SGML (which, unfortunately for you, *is*
the syntax of HTML until you come up with a formal specification
saying otherwise.) The MetaMorphosis processor actually reads ESIS
files for data input.
But what is all that extra syntax for? From the Metamorphosis pages:
The MetaMorphosis language contains embedded a query language for
accessing nodes in the tree. Queries can be absolute (taking the
root of the tree as the origin) or relative to the current element.
Relative queries can be specified accessing at least the following
information with respect to a node:
- its parent
- any ancestor
- its children
- any descendant
- its left and right siblings
- its original in the source tree from which it was copied
- its attributes
- its absolute position within its parent
- its position within its parent relative to other elements with the
same gid
- its PCDATA content a numerical key which uniquely identifies the
node in the tree
Any combination of the above can be used to form a complex query.
That's right: where an "action" applies is a matter of specifying a
*query*. The extra syntax is about conditionals in a tree navigation
environment.
That, BTW, is the "concept of CSS". CSS doesn't aspire (as yet) to a
comprehensive set of tree location primitives, but still the *hard*
part of the "concept" is precisely the set of primitives it tries to
deal with, because inheritance and the cascade depend critically on
such contextual selection.
Compared with MetaMorphosis, CSS is about annotations only. In fact,
the annotations are the *trivial* part of the syntax. It doesn't
matter whether one has to say 'foo : bar ;' or 'foo="bar"'. Actually,
compiler experience shows that explicitly delimited syntaxes (such as
terminated statements within explicit blocks) are *easier* to write
parsers for [Hint: LL(1) as opposed to LR(1).]
Since contextual selection is the meat of CSS, it's worth noting that
the actual syntax used is of limited power. But it gets the job done
with little fuss. Contrariwise, even to achieve this much power with
"just tags" takes us to the verbosity of FOSI specs, or even XSL, with
no particular gain in parsing.
This point is important, and often lost in discussions about syntax.
The more minimal the explicit syntax (with DSSSL at the extreme), the
greater the reliance on *special* constructions (such as "reserved
words" or "built-in functions") that have to be acted upon before the
*parsing* process can be considered complete.
If, on the other hand, you think that it's just a matter of putting
angle brackets at strategic points, then you haven't evne begun to
grasp what CSS (or any stylesheet language) is about. Worse, if just
those angle brackets aren't enough, and you find that you need other
syntactic constructs, be they words or punctuation, then you'll have
to demonstrate also why such extra newfangled machinery is superior to
specs and implementations (not to mention free source code) that
already exist.
Simply your claim isn't good enough.
:ar
Arjun Ray
".." <drc...@smtp.alink.net> wrote:
| Tor Iver Wilhelmsen wrote:
| > On Fri, 24 Jul 1998 23:36:48 -0700, ".." <drc...@smtp.alink.net>
| > uttered:
| > >The CSS syntax has no valid reason that anyone has presented
| > >for even exisiting. Only the CSS concept has validity.
The CSS syntax seems to have been aimed at ease of use: it has minimal
embroidery in that respect. As a matter of fact, certain constructions
important in tree transformations are probably impossible to describe;
but languages that do allow that (DSSSL, MetaMorphosis, etc.) are
arguably for experts only, and at any rate, CSS is far from being a
*comprehensive* stylesheet language.
| > The CSS syntax is well suited for its task. Can you come up with
| > a "HTML-like" alternative, or is it all just hot air?
|
| Although I did not spend but 10-15 minutes roughing out some general
| stuff,
Eh? You mean that you *haven't* thought this through? You *haven't*
researched prior art? Your categorical critiques of CSS syntax aren't
more than some mishmash of hunch and bias?
| I could see something like the following flavorings, with a little
| more added of course.
How much more? And why any at all?
| [...]
| <H1, H2, H3, H4
| margin.top="1em"
| margin.bottom="1em">
| [...]
We'll take just this one, as it appears to exemplify the idea. In
pseudo-Perl, we have, roughly:
s/([^{]){/<$1/g ; # Move a { "after" to a < "before"
s/:([^;}])/="$1"/g ; # rewrite : and add quotes
s/;//g ; # nuke semi-colons
s/}/>/g ; # rewrite } as >
All this, apparently, so that we can use a parser that groks '<' and
'='?
Well, you missed the hard part. First, how do you propose to *parse*
something like 'H1, H2, H3, H4' in a *position* where this favorite
"parsing technology" of yours expects a *single* name? Worse, what
about context specifications involving ancestors
<UL UL LI, OL OL LI, ...>
--------^
Consider the fact that from a tokenization point of view, you won't
know what the second 'UL' is until you reach the marked point (use a
fixed-pitch font to see this, please), and what you have is a parser
that has to implement *substantially* more lookahead than anything the
Mozilla codebase eve remotely approaches today. And this is "easier"??
Instead of "roughing out" examples, try writing a BNF for
(a) what you think a tag parser handles today.
(b) what your proposed syntax would involve to cover all the
context selections CSS *requires*
and then show us why your "extensions" are "little". Thanks.
:ar
Tor Iver Wilhelmsen
><H1, H2, H3, H4
> margin.top="1em"
> margin.bottom="1em">
Even though it may _seem_ easier, since you're using approx. the same
tokens in "your" CSS that the HTML parser uses, the context is
entirely different and would need to be rewritten anyway: This H1 is
_not_ an element name, but the first in a list of elements; outside of
STYLE, it would be an element name again.
If anything, I would claim the parser would be _more_ complex than
having a separate set of tokens for CSS, as is the situation today.
Thilo Pfennig
> CSS1 wasn't finalized until December 1996. Far be it from me to
> apologize for Netscape, but it's understandable a commercial
> company wouldn't jump at a working draft 2-3 years prior to it
> becoming a standard. This is especially true in light of the
> HTML 3.0 debacle of that approximate period.
Hi Mark,
not "jump at it", but realize, what will happen. I commented the
statement, that Netscape did something wrong, because they did not know
about upcoming standards. There was no need to implement it at the time,
NS started, but they could have the coming standard in mind for new
releases. But I think they really wanted back to stupid HTML with <I>
and <B> and some more proprietary tags. I think everybody at this time
thought that standards could be ignored in the future and that the way
was to bring the own software to be the only one in browser market.
This did not work and caused Netscape in Microsoft a lot of trouble.
Microsoft also could not control all the internet and MSNetwork was not
accepted by the users.
What I see is, that open standards like CSS (or eben USB,MIME,...)
only have a chance if companies are not succesfull in becoming a
monoplists and setting their proprietary standards as worldwide
quasi-standards (like Apples Quicktime and Realaudio's audio-standards).
Standards made, what now is defined as the internet. Companies thought
they could just sit uppon the internet-wave and selling their products
there! But because many companies think so, the business is getting more
and more expensive. Only fulfilled standards guarantee some kind of
acceptance by the customers, if the solution which is brought to the
public is not unique.
It seems to me that the economy is working more and more together on
standards. If somebody have told be about Microsoft being the only ones
implementing style-sheets mostly correct some years ago, I would have
laught! :-)
We also saw standards which did not get to the majority of users (like
the X.400 mail-addressing). Standards which are not giving respect to
the users needs or the factor time are beeing ignored, even if they
would have some benefit for users.
Thilo Pfennig
> | the tag-soup browser idea seemed fine, and its treating the tags as
> | commands seemed like a good decision at the time.
>
> Decision? Try concept, or understanding. They *believed* tags were
> commands.
We should remember that the WWW and browsers where (and are) totally
hyped. And many sofware-companies including Netscape just thaugth about
how to bring some more new hype into the thing! Compatibility and
conformation to standards which only come to mind in a long term. I have
seen many internet apps, which did non-conform stuff. Many of them now
switch to a more conform presentation. One bad habbit we still see is
HTML in Mail&News (default @ microsoft-products). :( I did not look at
it firmly, but I think in the meantime, HTML is been correctly announced
via MIME in articles?
BTW: How about CSS in Mail?
Daniel Glazman
: <H1, H2, H3, H4, H5, H6, P, UL, OL, DIR, MENU, DIV,
: DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, HR
: display="block">
Yuk !!! Immediate problems :
1) this only gives an equivalent to element type selectors. What about
combinators and selection on the structural context of the target element ?
2) how do you select on a attribute or a class ?
...
W3C selectors describe a structure. CSS rules use these selectors as
conditions opening on a declarative set of properties. Selectors are
the simplest and the most concise description of a structure I've ever
seen. Compare CSS and the styles part of XSL if you want...
</Daniel> <----- this is not the end of a style declaration
..
Daniel Glazman wrote:
> drc...@smtp.alink.net wrote:
>
> : <H1, H2, H3, H4, H5, H6, P, UL, OL, DIR, MENU, DIV,
> : DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, HR
> : display="block">
>
> Yuk !!! Immediate problems :
>
> 1) this only gives an equivalent to element type selectors. What about
> combinators and selection on the structural context of the target element ?
> 2) how do you select on a attribute or a class ?
> ...
<LI.EM.A.text.vlink=#CC0000>
<CLASS NAME=Moose><LI.EM.A.text.vlink=#CC0000></CLASS>
<ID NAME=Elk CLASS=Moose>
<BODY.bgcolor=#000000>
<BR.A.text.vlink=.Moose.LI.EM.A.text.vlink></ID>
> W3C selectors describe a structure. CSS rules use these selectors as
> conditions opening on a declarative set of properties. Selectors are
> the simplest and the most concise description of a structure I've ever
> seen. Compare CSS and the styles part of XSL if you want...
>
> </Daniel> <----- this is not the end of a style declaration
--
Daniel Glazman
> > combinators and selection on the structural context of the target element ?
> > 2) how do you select on a attribute or a class ?
> > ...
>
> <LI.EM.A.text.vlink=#CC0000>
>
> <CLASS NAME=Moose><LI.EM.A.text.vlink=#CC0000></CLASS>
>
> <ID NAME=Elk CLASS=Moose>
> <BODY.bgcolor=#000000>
> <BR.A.text.vlink=.Moose.LI.EM.A.text.vlink></ID>
Oh my goodness ! This is worst that I imagined it could be.
I suggest you take a look at the old Netscape submission to W3C "JSSS"
october 1996.
Oh, BTW, nobody but Netscape never implemented it.
</Daniel>
Jan Roland Eriksson
<Daniel....@der.edf.fr> wrote:
>> > 1) this only gives an equivalent to element type selectors. What about
>> > combinators and selection on the structural context of the target element ?
>> > 2) how do you select on a attribute or a class ?
>> <LI.EM.A.text.vlink=#CC0000>
>> <CLASS NAME=Moose><LI.EM.A.text.vlink=#CC0000></CLASS>
>> <ID NAME=Elk CLASS=Moose>
>> <BODY.bgcolor=#000000>
>> <BR.A.text.vlink=.Moose.LI.EM.A.text.vlink></ID>
>Oh my goodness ! This is worst that I imagined it could be.
>I suggest you take a look at the old Netscape submission to W3C "JSSS"
>october 1996.
It can be found here...
<URL:http://www.w3.org/Submission/1996/1/WD-jsss-960822>
--
Jan Rland Eriksson <r...@css.nu>
..
but the point being conveyed is what you keep dodging with these cheap responces
You seem to think there is something magical about the sequence
label { name:value } vs. <label name=value>
Wheras I see nothing more than institutionalized stupidity, and politics
Daniel Glazman wrote:
> > > 1) this only gives an equivalent to element type selectors. What about
> > > combinators and selection on the structural context of the target element ?
> > > 2) how do you select on a attribute or a class ?
> > > ...
> >
> > <LI.EM.A.text.vlink=#CC0000>
> >
> > <CLASS NAME=Moose><LI.EM.A.text.vlink=#CC0000></CLASS>
> >
> > <ID NAME=Elk CLASS=Moose>
> > <BODY.bgcolor=#000000>
> > <BR.A.text.vlink=.Moose.LI.EM.A.text.vlink></ID>
>
> Oh my goodness ! This is worst that I imagined it could be.
>
> I suggest you take a look at the old Netscape submission to W3C "JSSS"
> october 1996.
>
> Oh, BTW, nobody but Netscape never implemented it.
>
> </Daniel>
--
Daniel Glazman
> It's certainly not going to be pretty in ten minutes of thought, and a easy target,
> but the point being conveyed is what you keep dodging with these cheap responces
>
> You seem to think there is something magical about the sequence
>
> label { name:value } vs. <label name=value>
>
> Wheras I see nothing more than institutionalized stupidity, and politics
First of all, as a member of the CSS WG which standardized CSS,
I don't appreciate being insulted, even by someone who wants
to reinvent the wheel. The only stupidity here is yours. The million of
visitors of your HTML guide does not allow you to be impolite.
Browser vendors participate to the CSS WG, and, believe me, they are happy
with CSS syntax. They are so happy with CSS that they will apply it to XML.
Netscape is so happy with CSS syntax that their last submission to the W3C
about Action Sheets is based on CSS syntax.
So when I read the following lines :
> Everytime I see this complaint regarding CSS support , It amazes me how
> quickly the browser maker is blamed for something that is equally the fault
> of the standards committee.
my very first opinion is that you should update your information database
before posting this kind of comment. The browser maker **is** in the
standards committee and the browser maker voted the standard in the
normal W3C process.
Second, please use the appropriate vocabulary :
not "label { name : value }"
but "selectors { property : values }"
and "at-rule { property : values }"
and "at-rule { descriptor : values }"
your proposal covers a very small third of these three possibilities.
Third, what you are trying to promote is just ugly in comparison with CSS.
If you want to apply styles with a *ML formalism, use XSL [1].
Last, yes there is something magical but not in "selectors {property:values}"
but in the selectors. You seem to be too far away from industrial concerns
to see it.
[1] http://www.w3.org/Style/XSL/
</Daniel>
Tor Iver Wilhelmsen
uttered:
>You seem to think there is something magical about the sequence
>
>label { name:value } vs. <label name=value>
>
>Wheras I see nothing more than institutionalized stupidity, and politics
I just realized:
You have never ever, in your entire life, tried to write a parser for
anything, have you? You wouldn't know a shift/reduce from a
reduce/reduce conflict if one of them bit you in the ass.