Re: is anyone interested in XHTML?

> Even if all you did was replace every <FONT> tag in your documents by a
> handful of *inline* style sheet rules/properties in a STYLE element in the
> HEAD, documents would shrink by up to / around 30% and become a lot more
> maintainable.

  I will not argue either of these numbers, they seem reasonable.  I will
point out that smaller doesn't mean less complex though.  My concern is...

> However, that is a minor point - your next point is much more significant
(and
> of more relevance presently):
>
> >  The
> > necessity to do one task in two places actually makes the job much
harder,
> > and the advantages of reuse are not really important to them.
>
> I strongly agree.

  This is my concern.

> I believe that any new "mechanisms" that are developed in HTML or CSS to
> "attach" functionality of one sort or another, *must* allow for an inline
way
> of doing so, in addition to placing the functionality in a separate file
or
> even separate element in the same file.

  As I noted much of this problem is the fault of the tools.  Personally I
believe that if you decide to do things by hand then the complexity you are
exposed to is your "own fault".  However as it stands today the tools don't
hide much of this complexity, which makes XHTML/CSS a non-starter (for now).

> Unfortunately, there appears to be a trend developing in various recent
> proposals which sacrifice this kind of inline simplicity in deference to
some
> altar of purity.

  Exactly.  Essentially 90% or more of the replies to my previous thread
were "no, this goes against current philosophy".

> Note that I think it is a good idea moving forward to enable and encourage
> separation of varying mechanisms (such as markup and styling as done via
> HTML's LINK attribute and external CSS style sheets).

  I agree.

> But I think it is just as critical *in addition* to continue to allow
inline
> mechanisms (such as the <STYLE> element and the STYLE= attribute) for many
> reasons, including certainly for ease of development/authoring.

  Here too.

  I think the key issue here is to...

a) make a default stylesheet. Yes, that's right, a single stylesheet that
every tool/browser/etc. uses
b) styles applied by the user are _local_ overrides.  IE, if you change some
text to red it should add a local SPAN and put the style _inline_ on that
span
c) every time you change a style the tool should look to see if that style
is applied in other places too.  So if you then apply red to some other text
too, it should automagically generate a "red text" style cascaded off item
(a) and put that in a project stylesheet for you.

  That would...

1) give you the "direct" manipulation with clearly "commented" style coding
I think people really want (ie, I don't think people want to look in another
file for style info, no matter what the benefit)
2) still maintains all the good points of putting styles elsewhere.

  I'm sure this isn't a perfect solution, but you get the idea.  As it
stands today's tools make you do 100% of this stuff yourself, or you use the
standard HTML tags.

Maury

Received on Friday, 18 February 2000 01:53:24 UTC