W3C home > Mailing lists > Public > www-style@w3.org > March 2005

Re: IDs, Classes : could CSS usefully use a third (abstract) concept ?

From: Orion Adrian <orion.adrian@gmail.com>
Date: Mon, 21 Mar 2005 10:14:00 -0500
Message-ID: <abd6c801050321071475cb9df6@mail.gmail.com>
To: www-style@w3.org

How about for readability then.

color: *primary-color;
color: *accent-color;

is a lot easier to read then

color: #6688CC;
color: #4499BB;

in several places. Constants have existed for a long time in places
that don't have scripting. Mathematics has said that it's easier to
write g (for the earth's gravitational constant) than 32 (or 9.~)
everywhere you need it. What's wrong with authors creating semantic
constructs to make their lives easier. I'm not asking for anything
complicated - I'm simply asking for something to improve the authoring
experience. Readability and the ability to organize your CSS are
things that do have to be considered and saying that authoring tools
should do this for you simply provides a kind of vendor lock-in. If
that's the case why bother with the standards... I'll just use MS
everything and make my life easier. Code portability is certainly a
bigger target now than interoperability when one provider has 85+% of
the market.

Orion Adrian

On Sat, 12 Mar 2005 00:12:53 +0100, Laurens Holst
<lholst@students.cs.uu.nl> wrote:
> Ben Curtis wrote:
> >> Also a syntax like @define could allow great interaction with imported
> >> stylesheets. If the format were strict such that the  CSS document
> >> would have to be structured  as
> >>
> >>  - @definitions
> >>  - @imports
> >>  - css rules
> >
> > It is worth noting that this functionality, being client-side, offers
> > abilities that are impossible or highly convoluted server-side.
> > Therefore, @define or similar syntax serves a valuable and practical
> > purpose.
> >
> > Some example uses that would be exceedingly difficult server-side:
> >
> > 1. An XML-syndicated content provider supplies an accompanying embedded
> > stylesheet that handles layout, sourced from their server and adjusted
> > on occasion to take into account new content styles. The content is
> > included in an XHTML web page on the client, and the author of this
> > webpage would like the syndicated content to match his page's color and
> > style schemes. She could compose her own stylesheet, but delivering it
> > to override the embedded stylesheet so that her styles take effect
> > through the cascade is difficult without making everything !important.
> > She could have the server parse the embedded stylesheet and change it,
> > but then as the publisher changes things so must she. Or, with @define,
> > the publisher could use defined values and the page author supply those
> > values once.
> For this and 2. as well goes: How is the publisher agreeing with the
> client on a fixed set of @defined names different from them agreeing on
> a fixed set of class names? I can answer that question myself: it is not.
> As far as !important goes, just place your own stylesheet after the
> publisher's one and the cascade will make the last definition take
> precedence. Besides, what if the publisher specifies a default set of
> @defines. Use @define xxx yyy !important? -_-;;
> I really don't see the big use in defines. If you need to apply the same
> colour to different elements, say a level 1 heading, a div containing
> navigation, and a date, then just do:
> h1, #nav, .date {
>     background-color: #AAF;
>     color: white;
> }
> The only difference compared to @define is the place where you have your
> selectors. In this case, they are placed at the definition of the colour
> property, where in the case of @define they are elsewhere, with a
> reference to the @define.
> On one hand one might argue that the current CSS way is annoying when
> you want to group related stuff together in your CSS file, however on
> the other hand I think it is also convenient to be able to directly see
> which elements the colour applies to, and it really isn't unlogical.
> Both work equally well however. So, is this slight difference in
> notation worth adding a new redundant mechanism to CSS which will still
> take years before it is available in all mainstream browsers?
> ~Grauw
> --
> Ushiko-san! Kimi wa doushite, Ushiko-san!!
Received on Monday, 21 March 2005 15:14:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:17 UTC