LISTSERV mailing list manager LISTSERV 16.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


HTML-WG@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HTML-WG Home

HTML-WG Home

HTML-WG  November 1995

HTML-WG November 1995

Subject:

Re: the STYLE attribute

From:

Glenn Adams <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 10 Nov 95 10:34:41 EST

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (76 lines)




    Date: Fri, 10 Nov 95 07:58:54 EST
    From: Hakon Lie <[log in to unmask]>

    Arguments for:

     - one STYLE attribute is better than ten new visual tags.

Since one can use a single style rule in the style specification (i.e.,
in the STYLE element found in HEAD) to achieve precisely the same results,
this argument is without merit.

You will have to show why it is necessary to have a STYLE attribute
*in addition to* the use of CLASS and IDd rules to achieve the same
results if your argument is to have any force.  So far, I have seen
no argument for this other than perhaps an aid to lazy typists or lax
authoring tool implementors.

     - it will be an introduction to style sheets and lead people to the
       real thing. The same notation can be used in both the attribute and
       the style sheet proper.

Style sheets are the real thing.  Why encourage them to use a wet-nurse?
Another argument against this usage which you failed to mention is that
it is an unsound proposal on its own merit for the following reason:

(1) the STYLE element requires a NOTATION attribute to specify the style
language notation

(2) it should be possible to include multiple STYLE elements, each using
different notations (in order to support the specification of appearance
not only with different style languages but also with different versions
of a style language).

(3) it would therefore be impossible to determine what notation a STYLE
attribute is using without introducing either (a) a convention which used
a prior STYLE element in HEAD to specify a notation which not only applied
to that element but which persists to subsequent elements which employed
a STYLE attribute (clearly this is a hack); or (b) an application
convention that a STYLE attribute always followed a particular notation; or
(c) an additional attribute STYLE-NOTATION that would be concurrently
required with a STYLE attribute (a constraint that an SGML parser could
not validate).

Clearly, there are strong architectural reasons for not using a STYLE
attribute (i.e., it encourages the continued mixing of appearance and content);
there are specific implementation reasons for not using such an attribute
as specified (notational ambiguity); and, finally, the STYLE attribute
as specified is merely syntactic sugar, given that the same information can
be properly represented in the STYLE element using either the CLASS or ID
mechanism.

    I think this is one crucial compromise we have to make if we want to
    see style sheets realized on the web. There is a danger that authors
    never get past the attribute, but we'll have to take that chance.

I think this is nonsense.  You are simply speculating based on a complete
absence of any empirical data.  Let's start by limiting style sheets to
be architecturally sound, and then, if we find users aren't happy with
them, we can introduce compromises only as necessary.  Architecting
a compromise without a clear historical requirement is asking for
trouble and simply will add to the problem rather than help correct
the current problem (i.e., the admixture of content and appearance).

Regards,
Glenn Adams







Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
January 1996
December 1995
November 1995
October 1995
September 1995
August 1995
July 1995
June 1995
May 1995
April 1995
March 1995
February 1995
January 1995
December 1994
November 1994
October 1994
September 1994
August 1994
July 1994

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager