An outsider's notes on the use of CSS (long) - (was: Problems with 'position:fixed' using forms in IE 5.2 Mac)
dan donaldson
IE5.2 on Mac OS X, use of position:fixed breaks forms on IE5. What about
other browsers?
Without a solution to this sort of problem I encountered, my clients will
say that CSS is definitely a not ready for prime time technology. Not
because it fails on this or that test, but because as a standards-based
system without an effective method of enforcing compliance, it leaves them
far too exposed to future unknowns - other things that it ought to do, but
never seems to quite do.
Especially ironic is that I can easily achieve the goal I have using frames
of all god-forsaken solutions. If it isn't obvious that a lame approach like
frames is the most obvious place to demonstrate the advantages of CSS - by
supplying compatible browsers that actually achieve the goal of eliminating
the unwieldy two-documents-just-to-have-fixed-navigation syndrome, but in
the meantime, finessing typographic control of font weights, well... Come
on.
Brings to mind the old motto: "in theory, theory and practice are the same.
In practice, they are different".
My client would save a great deal of money and time if they could use this
technology - and, they would spend a good deal of money and time to get to
the point where they can use it - enterprise-wide browser upgrades,
retraining etc.. But try telling them that a simple thing, and one of the
real (theoretical) bonuses of the use of CSS - the ability to build highly
productive interfaces on pages by fixing the location of form elements that
the user will interact with - is going to require a kludge, a fix, and a lot
of crossing of fingers, and what do you think they will say? And this is in
a situation where the project is essentially an intranet deployment, and so
browser control can be to some extent achieved. For public sites, the idea
that 'only' twenty percent of the viewing public is going to be shut out is
anathema.
I know, I know - why should we live with antiquated technology that was done
badly to start with. Well, not many people have sold their cars and bought
Segway's yet, either. And no city planners are de-allocating budgets for
road and traffic light maintenance, just because a technology exists and has
been demonstrated to work that might - one day - replace the car. 'But how
do they expect the car ever to be replaced if they (urban planners and
managers) don't take the first step?' comes the reply. This simply ignores
two basic rules of economics: a.) people use what they have, and b.) change
represents cost.
The optimistic webstandards.org redirect, recently mentioned on this list
(http://www.webstandards.org/upgrade/) suggests that since all these
smashing browsers are free, there could be no problem to simply upgrade. But
change is a cost, and to not take this into account is naïve. When the
change suggested doesn't come close to guaranteeing that a given
implementation of CSS will - or even might - work, the cost benefit is
indeterminate, and most responsible managers would assume a negative, since
the cost is known and the benefit is not. The reality is that compliance is
a huge issue, and CSS has not yet matured - as far as I can see from the
consultant's chair - to the point where I can recommend it.
Personally, and from a business point of view, the expenditure of money and
time - will there be less of either or both - is the only real selling point
for most of my clients. Technology per se is never a selling point - you
will never see an ad saying 'Come to XYZ.com - now with CSS2!' - especially
using web technology, because it's so hard to maintain a technological edge.
Everyone uses the same technology. So the underling technology rarely
carries weight. The way technology is used to support an approach to
branding or to ease of use does carry weight, since these are the things
that people actually sell. This is not, apparently universally understood in
the web design community. What you will see is 'Come to XYZ.com - now even
easier to use!', but again, not 'Come to XYZ.com - now even easier to use
except for 20 percent of you all, where it will be harder or impossible!'.
Clients hate for people to have surprises.
Brings to mind Holiday Inn's motto: "No Surprises". You may hate it, but it
works.
I hope this won't spark a flame war here, but as someone whose obligation it
is to assess this technology (css) and others for clients, I am quite
surprised at the disregard that this sort of problem gets in the css
community. I'm not referring to the lack of replies, but to the dismissive
air that objections are sometimes dealt with. I wonder if, sitting in a
board room with decision makers who are trying to figure out how to commit
an X-million dollar web budget, the attitude would be quite so cavalier.
This is not to ignore those posters who take the broader view. But those
whose restrictive, almost puritanical zeal for separation of content and
structure should know that this is not an argument that easily survives in
the decision making context. Board members are rarely theoretical, and
shareholders never are.
Clients are sophisticated enough to understand that saving time and money
can also take the form of an improved user experience (less marketing and
support), and will grasp the argument that building a site where the holy
grail of separation of structure from content is worthwhile - although from
their point of view, CSS does not offer this at all. They argue - correctly
- that the only real divisions that exist are the division of roles among
employees. And if, to make documents useable, authors have to learn lots of
new skills - XML/XHTML/CSS etc to facilitate the 'separation' of content and
structure - well, they'll say that the supposed benefits of separating
content and structure disappear if they don't allow specialization and role
definition. If authors need to know a form of markup, this will incorporate
large costs in retraining and rediting archived material. In other words, if
an author's job has to become the markup editor's job, to them, it's no
different from any other place where I or anyone else suggests that authors
become their own editors. Yet, to re-edit a document, the author has to
either take on the marked-up document in raw form, or work in a WYSIWYG
environment - which is (to a degree understandably) sniffed at by many in
this group. I understand exactly what is wrong with Dreamweaver et al from a
data separation point of view, but from a business case point of view, it
allowed many companies to deal inexpensively with the problem of documents
that needed to be re-edited. CSS as it is currently conceived doesn't do
that - does it?
Brings to mind the old motto: "The editor who authors his own work has a
fool for a writer." This motto has the commutative property.
OK. Would love to get your perspective on this. And if there's a solution to
my problem, that's good too. No flames, I hope. I mean this constructively,
and I hope you'll reply in kind.
omnivore
Bill Statler
wrote:
> ... my clients will
>say that CSS is definitely a not ready for prime time technology. ...
> ... [A] simple thing ... is going to require a kludge, a fix, and a lot
>of crossing of fingers.... For public sites, the idea
>that 'only' twenty percent of the viewing public is going to be shut out is
>anathema. ...
> ... [S]ince all these
>smashing browsers are free, there could be no problem to simply upgrade. But
>change is a cost, and to not take this into account is naīve. ...
Well said. Let me add some "outsider's notes" from a different
perspective (not a professional web designer; a little experience
designing my personal pages; now trying to learn the "right" way to do
it).
I've been using Netscape 4 for years on my "antique" 233 MHz WinNT4
system. I have a 26.4 kbps modem connection, thanks to
Flintstones-era phone lines. Here is the cost of my "free" upgrade to
Netscape 6.2:
* A download that took several hours and several restarts.
* An installation that automatically grabbed the settings and
bookmarks from an old Mozilla installation, even though I had
uninstalled that program.
* Software that takes a VERY long time to start up, compared to
Netscape 4.
* If I surf with image-loading turned off (very desirable at 26.4
kbps), there is no "Load Images" button such as Netscape 4 had. So I
leave images on, and using the Web is much slower than before.
And there are other bugs and unimplemented features -- but my point is
not to flame about Netscape 6.2. What I'm saying is that, as someone
who has been using personal computers for 20 years, I found this
"free" upgrade to be a pain in the butt, and costly in terms of time
and annoyance. I wouldn't expect an upgrade involving MSIE or any
other browser to be any easier.
So how about the millions of people who just bought their first PC
within the last year or two? How many of them will be willing to
tackle a browser upgrade on their own? If their favorite online
shopping or banking site suddenly stops working with their old
browser, will they say "Oh, it's my own fault for not upgrading!" --
or will they just conclude "This web site is broken" and go somewhere
else?
> ... I am quite
>surprised at the disregard that this sort of problem gets in the css
>community. ... [T]hose
>whose restrictive, almost puritanical zeal for separation of content and
>structure should know that this is not an argument that easily survives in
>the decision making context. Board members are rarely theoretical, and
>shareholders never are.
There is an attitude that has been expressed by several people in this
newsgroup and in c.i.w.a.h that I consider very short-sighted. It
goes like this: "Our job as web designers is only to comply with The
Law as it is given to us by W3C. Once we have done that, our job is
finished, and any complaints about the result should be directed at
the users who haven't upgraded their browsers, or the browser
manufacturers who write non-compliant software." This is not
realistic.
Here's a simple example of what's wrong with "W3C fundamentalism".
Suppose I want to highlight the word "Warning!" on my web page. I
could do:
span.red {color: #cc0000; stress: 80}
and then
<span class="red">Warning!</span>
and "Warning!" would be red for everyone with a browser that
understands HTML4 and CSS1 (if they have a color monitor and aren't
colorblind). And it would even be audibly emphasized for the three
people on the planet using a CSS2-aware aural browser.
OR, I could do:
code {color: #cc0000; stress: 80}
and
<code>Warning!</code>
and the CSS will work just the same, but even people with really,
really OLD browsers will see the word "Warning!" emphasized in some
way, typically with a fixed-width font. And the fundamentalists will
all have heart failure, because "Warning!" is NOT valid computer code,
and some future XML-aware browser might try to, I don't know, compile
it or something.
I know that this particular issue has already been discussed to death
here and in c.i.w.a.h, but let me just make a suggestion that seems
sensible.
The fundamentalist definition of <code>: "This text *IS* computer
code."
The liberal definition of <code>: "This text should be presented in a
manner suitable for the presentation of computer code, and distinct
from normal text."
I can see where the fundamentalist definition is appropriate for XML
(and therefore, I suppose, for XHTML as well). But HTML is used as a
tool for presenting information, and the liberal definition is much
more suitable. (Obviously, this can be extended to other tags.)
It doesn't make sense to me to take the standards of XML (where tags
are supposed to actually MEAN something, and where the rules for
displaying information MUST be provided separately) and retroactively
apply them to HTML, a language that has included <b> and <i> and <tt>
and <sup> and <sub> since very early versions, and is clearly designed
for the presentation of information. Yes, you can eliminate every
<table> from your document, and use CSS to position everything, and
maybe the latest version of one browser will be able to display it.
But why?
> ... if, to make documents useable, authors have to learn lots of
>new skills - XML/XHTML/CSS etc to facilitate the 'separation' of content and
>structure - well, they'll say that the supposed benefits of separating
>content and structure disappear if they don't allow specialization and role
>definition. If authors need to know a form of markup, this will incorporate
>large costs in retraining and rediting archived material. ...
This reminds me of an earlier change in role definition. Busy
executives used to dictate letters and memos to their secretaries, who
would then type them. Imagine telling an executive of 25 years ago
that he would have to learn to type, so that he could write letters
himself on his computer.
But at least the executive has a working, reliable WYSIWYG interface
for his word-processor software. If such a thing existed for web
design, we probably wouldn't be having this discussion.
=-=-= Bill Statler =-=-=
Eric Gisin
IE 5/6 are smaller than NS 6, and more standards compliant than NN 4. Opera
5/6 are much smaller than both.
I've got 44K connections, and I've download IE 4/5/6, Op 5/6, Mozilla and
around 100MB of other stuff per month.
"Bill Statler" <wsta...@oneworld.owt.com> wrote in message
news:3c1fa952....@news.newsguy.com...
Jukka K. Korpela
>> OR, I could do:
>> code {color: #cc0000; stress: 80} and <code>Warning!</code>
>> and the CSS will work just the same, but even people with
>> really, really OLD browsers will see the word "Warning!" emphasized in
>> some way,
>
> What's wrong with "em" for emphasizing something?
Nothing, of course, but for warnings, "strong" might be more adequate.
In any case, an author should select the markup so that it corresponds to
the logical role of the text, or at least doesn't conflict much with it.
The text "Warning!" can hardly be regarded as computer code. Moreover, an
author should note that different browsers may use different default
presentations for elements. Typically, for example, "em" is displayed
italics and "strong" is in bold face. But it could be something different,
like different colors. This is why coloring things in CSS is more
problematic than one might expect. If you use #cc0000 for something,
without worrying about other colors, it might happen that a browser uses
#cc0000 or some color near to it as the default color of some elements, say
quotations. (A bad choice, but this is just an example.) Then the user sees
such elements and the CSS-colored elements in the same or similar color and
gets confused.
Note that "code" does not need to be presented differently from normal
text. When monospace font is used (which is to some browsers all that they
can use), there's probably no distinction between "code" and normal text.
And in speech presentation, there probably is no distinction either
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Ian Davey
>Why Netscape, since you posted from a MS Windows machine?
>
>IE 5/6 are smaller than NS 6,
>
Then why are the downloads bigger?
ian.
Berislav Lopac
> executives used to dictate letters and memos to their secretaries, who
> would then type them. Imagine telling an executive of 25 years ago
> that he would have to learn to type, so that he could write letters
> himself on his computer.
It's still common, especially in Europe, to receive an email with no text
and with an attachment consisting of a MSWord .doc file, complete with logo,
header and everything else on the sender's company's letterhead stationery,
and the actual message just a couple of short sentences in the middle. Guess
who didn't make the role definition change you are talking about.
Berislav
dan donaldson
Xns917C54C425B3...@193.229.0.31, "Jukka K. Korpela"
<jkor...@cs.tut.fi> wrote:
> In any case, an author should select the markup so that it corresponds to
> the logical role of the text, or at least doesn't conflict much with it.
Here is an interesting example of the problem I was pointing out.
Authors are not the people on whom you would rely to markup their own work.
It violates the validation of peer review, and it imposes an unreasonable
burden on the author. The idea that someone has to know a technology like
CSS/HTML/XHTML to express what they know about, say, stock options or
cardiac care or garden care is not a good one.
I will argue that while, in some sense, CSS,XML and their ilk can achieve
separation of content and structure, they can only do so by imposing a
division between expression and knowledge. In other words, someone with
knowledge cannot express themselves in this medium without either becoming
expert in an abstruse technology (CSS), or with the aid of someone who is
knowledgeable in this technology.
This puts a priority and a value not on the best knowledge, but the best
combination of knowledge and this technology. I can safely assume that
neither my stock broker nor my cardiologist are moonlighting as markup
wizards. In fact, I expect them to be devoting their time to further mastery
of their expertise, not some subset of web technology.
So for them to express what they know in this medium, they have to submit
their knowledge to a process that imposes a second level of meaning upon it.
A markup editor will have to make decisions as to what the meanings of
various elements in the text they have been provided are. Whether they can
be effective in communicating what they have done to the original author is
not something contained within the CSS specification, so far as I know.
You can argue that the classic paper-based publication process also imposes
a need for editorial and layout editors to process manuscript text. But the
role of an editor in this case is to a.) facilitate peer validation of the
text by other experts (not usually the editor), and b.) impose order -
primarily visual order. With metadata markup, a very dangerous thing happens
- the editorial process imposes not just order, but meaning on a text, and
the generation of that meaning is the responsibility of people without
expertise in the field the text addresses.
Tim Berners-Lee was very clear that his objective was to produce a markup
language that would not impose unreasonable cost of learning and mastery on
users. <H></H> tags both carried visual and informational order: they
suggested a hierarchy of importance and allowed a practical subdivision of
knowledge, which is not the same thing as the imposition of meaning. Any
researcher could grasp this concept and apply it in twenty minutes. At the
same time, it was well within the powers of the commercial and open source
communities of developers to create compliant devices - browsers - to
express the information contained in this markup.
My orginal argument/observation was really, 'that's nice, but it doesn't
work, and the people I talk to don't care about it if you can't show it to
them working.' In this sense, CSS is the last great holdout of the Internet
Bubble Mentality: absolute vapourware with the assumption that investors are
not going to ask too many questions, and certainly not expect to see a
working example, never mind a positive cost-benefit before ponying up the
dough.
But at a more theoretical level, here's what I think the problem is:
Implied in the idea of metadata is that a.) before researchers can have
access to information a increased amount of time will pass than would have
happened with appearance-based markup, which in turn is a greater gap than
plain-text (ie purely authorial) documents; b.) the process that they will
be subjected to will be inherently unreliable, introducing a second level of
error as inexpert markup editors impose meaning on expert texts; c.) an
individual author can only deal with this problem partially, and that by
learning an abstruse, changing technology, thus diverting them from their
primary expertise; d.) in any case, this technology has no compliant device
(ie browsers) to use the information; e.) neither is there any immediate
prospect of a compliant device appearing, as the body charged with
developing standards has no power to enforce compliance, and does not offer
certification that would aid its adoption in the marketplace.
Phew!
This, realistically, is why CSS strikes me as a not-ready-for-primetime
technology, and a boondoggle.
dan
petermcc
> This reminds me of an earlier change in role definition. Busy
> executives used to dictate letters and memos to their secretaries, who
> would then type them. Imagine telling an executive of 25 years ago
> that he would have to learn to type, so that he could write letters
> himself on his computer.
Fifteen years ago, we were telling male execs just that - and it was the
execs that we were talking to because this was "computers" for which a Y
chromosome was obviously required, unlike the typewriter that could be
worked by a woman.
Incidentally, it was the typewriter that saw the introduction of the notion
that secretarial tasks were women's tasks - until then, the business of
writing was such that it required a man to do it properly. The introduction
of the typewriter meant that even a woman could write a business letter
since it only required the pressing of the correct buttons, as long as a man
had told her what to write. Prior to that, secretaries were almost
exclusively male. But it's arrogant of me to assume that you didn't know
that already - soz.
Anyhow, back to the original point: we told our executive trainee
word-processor users that PC stood for personal computer and it was called a
personal computer because you, personally, used it and that, by doing so,
they were taking part in what was being spoken of as the "computer
revolution". They nodded sagely and, with masculinity satisfied that they
were personally taking part in the computer revolution - an obviously male
activity - they buckled down to learning how to write letters.
Interestingly, the measure of success that they adopted for themselves was
their ability to produce a letter that was almost as good as one that their
secretaries could have produced in half the time on equipment costing a
tenth of the price of a computer. Still, the longest journey starts with a
single step...
As I am using plain text, I have not been able to format the appropriate
sections in an ironic typeface. I trust that my sentiments are still
apparent.
PeterMcC
Jerry Muelver
<d...@omnivore.ca> wrote:
>On 19/12/01 1:21 AM, in article
>Xns917C54C425B3...@193.229.0.31, "Jukka K. Korpela"
><jkor...@cs.tut.fi> wrote:
>
>> In any case, an author should select the markup so that it corresponds to
>> the logical role of the text, or at least doesn't conflict much with it.
>
>Here is an interesting example of the problem I was pointing out.
>
. . .
Dan, permission to copy and repost at allmyfaqs.com? And the
thread-top article, too?
---- jerry
dan donaldson
"Jerry Muelver" <je...@allmfaqs.com> wrote:
Sure.
Alan J. Flavell
> Authors are not the people on whom you would rely to markup their own work.
[...]
> This, realistically, is why CSS strikes me as a not-ready-for-primetime
> technology,
You raise a number of interesting discussion points; but on a key
issue of structure, I have to say that I find your presentation either
confusing or confused, if not both.
The separation of markup and presentation is quite consistent with the
idea that the content author will know what the structure of their
material is, and be able (whether directly or indirectly) to mark
it up accordingly.
You said, inter alia:
> someone with knowledge cannot express themselves in this medium
> without either becoming expert in an abstruse technology (CSS), or
> with the aid of someone who is knowledgeable in this technology.
The stylesheet(s) could well come in from another source. The content
author isn't (necessarily) being asked to design stylesheets - any
more than a Latex author would be asked to design a style file, or the
average MS Word user would be asked to design their own style
template. Or, for that matter, a book author designing their own
book typography.
best regards.
Tantek Celik
available for MacOS 8 & 9 in addition to MacOS X) with the Tasman
presentation engine. Just a 5.4MB download from here:
http://www.microsoft.com/mac/download/ie/ie51.asp
Building on the solid support for W3C standards in Tasman which shipped in
IE5/Mac (CSS-1, HTML4, PNG 1.0, ECMA 262, DOM 1.0 HTML), this release
consists primarily of bug fixes and performance improvements.
It is probably of interest to this group that we have made numerous CSS
fixes and improvements (mostly esoteric), for example:
- improved/stricter keyword parsing [1]
- case sensitive treatment of class and ID [2]
- application of CSS style sheets to XML [3]
- CSS character escapes [4]
- CSS2 Universal Selector '*' [5]
- CSS2 Child Selector '>' (nondeterministic matching) [6]
- CSS2 Adjacent Sibling Selector '+' (nondeterministic matching) [7]
- Specificity of non-CSS presentational hints [8]
- font-weight values [9]
- CDO/CDC parsing in inline style sheets [10]
- styling of <hr>, <br> elements [11]
- collapsing empty HTML <p> elements as display:none [12]
- ignoring invalid @imports [13]
Aside from these improvements, a few interesting user interface improvements
have been made such as the ability to drag and drop arbitrary images and
hyperlinks (and hyperlinked images) to the button bar.
Regards,
Tantek Çelik tan...@cs.stanford.edu
Development Lead, Tasman Presentation Engine tan...@microsoft.com
[1]
http://www.people.fas.harvard.edu/~dbaron/css/test/sec040102
[2]
http://www.people.fas.harvard.edu/~dbaron/css/test/casesens
[3]
http://www.people.fas.harvard.edu/~dbaron/css/test/xmltypesel
[4]
http://www.people.fas.harvard.edu/~dbaron/css/test/parsing3
[5]
http://www.people.fas.harvard.edu/~dbaron/css/test/univsel
[6] note the last test: "(this test is harder than the others!)."
http://www.people.fas.harvard.edu/~dbaron/css/test/childsel
[7] note the last test: "This should be maroon"
http://www.people.fas.harvard.edu/~dbaron/css/test/sibsel
[8]
http://www.people.fas.harvard.edu/~dbaron/css/test/noncss1
[9]
http://www.people.fas.harvard.edu/~dbaron/css/test/sec150203c
[10]
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/cdocdc.html
[11]
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/hrbrstyles.html
[12]
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/collapse.html
[13]
<http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/extra/importafterimpor
t.html>
Jerry Muelver
Thanks. http://allmyfaqs.com/faq.pl?Dan_Donaldson
We'll have a special section for articles, some day.
---- jerry
--
Eric Gisin
So why does an 8MB download consume 20MB+ when running?
"Ian Davey" <ida...@my-deja.com> wrote in message
news:3C20A1F2...@my-deja.com...
Bob Osola
news:B843B341.7DC%d...@omnivore.ca:
> Yet, to re-edit a
> document, the author has to either take on the marked-up document in
> raw form, or work in a WYSIWYG environment - which is (to a degree
> understandably) sniffed at by many in this group.
You are missing out the model of sites with database-driven content. I am
about to do such a site for an enlightened customer where all the textual
content will be held in a MySQL database. A basic CSS file controls the
appearance. Some simple PHP scripts pull the whole together to present not
only the site which end users will see, but also a passworded section
where my client can (using simple forms) add to or amend the content of
his site as he wishes. Much easier than obliging him to learn HTML or how
to use a WYSIWYG/FTP tool. This kind of architecture was *much* more
difficult and unwieldy before CSS. Further; the inclusion of CSS was
actually a big selling point for this customer - he loved the notion of a
one-stop shop to alter the appearance of the whole site. And even NN4, for
all its foibles, can make reasonable use of CSS - provided you don't push
the envelope.
However, I agree that it is very difficult (in the business world) to go
the whole hog in terms of avoiding deprecated tags and similar non-PC
tactics. For example, most of the purists here go ballistic at the notion
of suggesting font sizes in any way. But the facts are that 90% of users
browse with IE, and the default font size is poorly chosen for that
browser. *Every* customer on whom I optimistically try an unadorned
Verdana page says "Can you make the font smaller?". So a typical real-
world compromise is to use 'font-size: small;' or similar CSS trick and
simply not mention it in this group :-) But such compromises do not
seriously undermine the basic usefulness of CSS in terms of saving
development time and hence money - something which all customers can
understand.
The anti WYSIWYG tool sentiments you refer to are largely intellectual
snobbery IMO. Most of the high-end ones (including Dreamweaver) now allow
you to include CSS very easily. Properly set up, they can offer very rapid
prototyping with not a <font> tag in sight. Combine such a tool with a
good WYSIWYG CSS tool, and you can cut out much of the donkey work of the
write/preview/amend/validate cycle, saving even more time and money. Add
in a decent text editor for your server-side code, and you're really
cooking.
I agree that the rise of XML, CSS etc has resulted in site development
becoming more difficult, but these new technologies allow you to do so
much more. Every other area of working with IT requires constant updating
of knowledge; why should site authoring be any different?
--
Regds, Bob Osola
dan donaldson
Xns917D399A9F87bo...@194.168.222.19, "Bob Osola"
<bobo...@NOSPAMntlworld.com> wrote:
I agree with the statement that using CSS in database driven sites is very
useful and have used it this way myself. But how do you deal with cases of
formatting within the body of text edited by the author? How, for instance
do you cause the headings, lists and other elements the author might have
included to be represented so that the author can deal with them?
I've built catalogue systems where each product could have an arbitrary
number of tables of data associated with them, so that you can present
tabular data of properties like weight, thickness, density, whatever. But
these are pretty difficult to get right, and even harder for the user/author
to learn to use. What I learned from this is that the further we put the
author from the final expression of their content, the higher the costs will
be, which makes CSS one of the most expensive web technologies. Whether CSS
can recoup these kinds of investments in reduced costs to represent material
in varied media is a moot point, and primarily because we can't really
quantify it until a browser is in wide use that actually implements the CSS
specs in a reliable way.
I understand Alan Flavell's points - the separation of presentation and
markup is one thing, but as markup infiltrates a document it imposes
meaning, by suggesting what distinctions are to be made within a text. The
point is that these distinctions may exist (or they may not), but the
present situation makes it difficult for an author to confirm that the
markup editor has done the right things in the right places, even more so
when the editor and author have no common language to discuss it with, and
no device to confirm visually what has been done in a reliable way. I agree
that authors know the structure of their own work, but markup that uses
external, general stylesheets means that the author's way of describing that
structure must conform to an existing standardized set of possibilities. How
do we guarantee that it will? What are the results if it does not?
But what it really comes down to for me is just that it doesn't actually
work...
dan
dan donaldson
Pine.LNX.4.30.011219...@lxplus023.cern.ch, "Alan J.
Flavell" <fla...@mail.cern.ch> wrote:
>
> The stylesheet(s) could well come in from another source. The content
> author isn't (necessarily) being asked to design stylesheets - any
> more than a Latex author would be asked to design a style file, or the
> average MS Word user would be asked to design their own style
> template. Or, for that matter, a book author designing their own
> book typography.
>
> best regards.
Good points. But isn't one problem with a system that separates markup from
presentation precisely that the author doesn't know from the tag itself how
the material it contains will be presented? Consider one author writing for
twenty different online publications. Would she have to master the
stylesheet conventions of each publication? Clearly, the author is intended
to leave the building and let the markup editor do his thing, but what if
that process imposes structures and meanings on the author's text that the
author disagrees with?
Not many authors in the book publishing trade say 'I don't really mind if
the edition in the US has six inch margins and three columns per page, while
the UK one is in red on blue paper with five line drop caps. But by
separating tags from presentation, the author must accept that the
presentation of their text is no longer something that they can usefully
approve or control, or even set limits on. They can do this in
appearance-based markup to a useful degree. In print, a Penguin follows the
rules laid down by Jan Tischold, and it is a good bet that less than one
tenth of one percent of the tens of millions of Penguin readers have ever
noticed anything in a Penguin but the quality of the reading. That's how
good the book design is. Good book designers know that their craft has
failed when it is noticed (I recommend Robert Bringhurst's book on this to
anyone who hasn't read it, and of course http://www.textism.com).
CSS seems to me to be very easy to steer into the realm of virtuoso type
design a la David Carson, that at its worst denigrates content and even
readability, assuming that the author's job is to type, and theirs is to
present, and each is an 'artist' in their own way. But that is a rant and I
will step back before I go too far.
dan
Spooky Guy Next Door
(je...@allmfaqs.com) posted the following...
*rubs hands together, laughing evilly*
--
The ideas expressed in the above post are my own, with the possible
exception of the one involving a scarecrow and a stick of butter.
blog - http://www.cyberfuddle.com/infinitebabble/
cyberfuddle - http://www.cyberfuddle.com/
learn HTML - http://smiley.vh.mewl.net/markhtml/
Berislav Lopac
"dan donaldson" <d...@omnivore.ca> wrote in message
news:B846BC25.892%d...@omnivore.ca...
> On 19/12/01 1:27 PM, in article
> Pine.LNX.4.30.011219...@lxplus023.cern.ch, "Alan J.
> Flavell" <fla...@mail.cern.ch> wrote:
>
> >
> > The stylesheet(s) could well come in from another source. The content
> > author isn't (necessarily) being asked to design stylesheets - any
> > more than a Latex author would be asked to design a style file, or the
> > average MS Word user would be asked to design their own style
> > template. Or, for that matter, a book author designing their own
> > book typography.
> >
> > best regards.
>
> Good points. But isn't one problem with a system that separates markup
from
> presentation precisely that the author doesn't know from the tag itself
how
> the material it contains will be presented? Consider one author writing
for
> twenty different online publications. Would she have to master the
> stylesheet conventions of each publication? Clearly, the author is
intended
> to leave the building and let the markup editor do his thing, but what if
> that process imposes structures and meanings on the author's text that the
> author disagrees with?
I see where you're going. The author must be able to mark parts of his work
according to their structural roles (i.e. headers, paragraphs, quoted texts
etc.). Actually, the existing HTML standard is perfect, as it does exactly
that: you don't purely define the content, but you mark it logically, and
you don't care about the presentation, as it will differ depending on the
browser.
This way the author has the power to markup his work structurally; which is
all he needs, because if he defines appearance any more it would go beyond
his role as an author and into the publisher's role. And it's up to the
publishers to define their presentation style(s) to condone to the author's
structure without imposing limitations and forced directions.
In other words, a publisher should define its stylesheet conventions to
condone primarily to the standard HTML structure, with additional styles
only as an expansion, while the author should clearly markup his work do
define its structure. This way HTML + CSS become a perfect combination for
trasferring authorial work to presentation, at least online.
Berislav
Urban Fredriksson
dan donaldson <d...@omnivore.ca> wrote:
> Clearly, the author is intended
>to leave the building and let the markup editor do his thing, but what if
>that process imposes structures and meanings on the author's text that the
>author disagrees with?
Can it normally do that? Even if you turn in a handwritten
manuscript you have to communicate with someone about how
you can see a piece of text is a heading, quote, definition
or whatever. Otherwise it's just a mass of text to the
markup editor so no structure can be added, isn't it?
And today it's quite normal in word processors to use
named styles for different parts of the text. One can of
course use totally illogical names for them, but I don't
think most people do. If there are such named styles I
don't think it's much of a problem for the markup
editor to do a translation to HTML+CSS.
>Not many authors in the book publishing trade say 'I don't really mind if
>the edition in the US has six inch margins and three columns per page, while
>the UK one is in red on blue paper with five line drop caps.
I don't think most authors, for most kinds of books, really have
a choice other than choosing publishers.
--
Urban Fredriksson
Recent and featured photos: http://www.canit.se/%7Egriffon/diverse/pix/recent/
Latest update 2001-12-19
Urban Fredriksson
Bill Statler <wsta...@owt.com> wrote:
>OR, I could do:
> code {color: #cc0000; stress: 80}
>and
> <code>Warning!</code>
But why? Isn't
strong.warning {color: red; background: white;}
and
<strong class="warning">Warning!</strong>
much more reasonable?
--
Urban Fredriksson http://www.canit.se/%7Egriffon/
Beyond each corner new directions lie in wait.
-- Stanislaw Lec
Ian Davey
>Right, Mozilla was 8MB and IE6 for Win2K was 12MB.
>
>So why does an 8MB download consume 20MB+ when running?
>
I don't see what relevance that has to download time on a slow modem.
You can't really tell IE's memory usage to compare though, as a lot of
it is hidden within the OS services.
ian.
Eric Jarvis
> On 19/12/01 1:27 PM, in article
> Pine.LNX.4.30.011219...@lxplus023.cern.ch, "Alan J.
> Flavell" <fla...@mail.cern.ch> wrote:
>
> >
> > The stylesheet(s) could well come in from another source. The content
> > author isn't (necessarily) being asked to design stylesheets - any
> > more than a Latex author would be asked to design a style file, or the
> > average MS Word user would be asked to design their own style
> > template. Or, for that matter, a book author designing their own
> > book typography.
> >
> > best regards.
>
> Good points. But isn't one problem with a system that separates markup from
> presentation precisely that the author doesn't know from the tag itself how
> the material it contains will be presented? Consider one author writing for
> twenty different online publications. Would she have to master the
> stylesheet conventions of each publication? Clearly, the author is intended
> to leave the building and let the markup editor do his thing, but what if
> that process imposes structures and meanings on the author's text that the
> author disagrees with?
>
but this is exactly where css wins out...all the author does is mark up
<p class="reference"> or <span class="warning">...that clearly shows what
they intend from the style...there is no need to think about the
visualisation of the style, simply the concept
--
eric
"if at first you don't succeed,
then try again with it switched on"
dan donaldson
MPG.168be50ae...@News.dial.pipex.com, "Eric Jarvis"
<nos...@last.dircon.co.uk> wrote:
Really? If each author inserts arbitrarily named style class names, what
would the stylesheet management problem on that site be like, I wonder?
One interesting thing about linked stylesheets is that the stylesheet itself
doesn't tell you what documents are using it. So if I am working with an
author who has defined the need for a class that happens to have the same
name as another class in another document somewhere else, how am I going to
know how to deal with that problem? If I can't reliably track which
documents use an identically named class, how am I going to know what the
consequences would be of changing the definition for that class? This is
very similar to problems in changing functions in programming, and that's a
very unpleasant thing, when you break other folks' code to 'improve' the
language - in ways those other folks won't benefit from.
The only conclusion one can come to is that the intention of stylesheets is
that an independent markup editor will impose a style convention on a series
of documents written by others, and by so doing will eliminate any
possibility of the author having useful control over the presentation of
their work. Add to the problem of inexpert markup editors structuring expert
texts the problem of knowing all the locations a given class is used.
Going back to business mode, it seems to me that whenever you start piling
expertise onto employees, you a.) increase costs and b.) increase the
company's susceptibility to disruption (when the critical employee is ill,
quits, is fired_. Not a popular notion. If you can't implement CSS
structures in a reasonably straightforward way, without this emphasis on
editor knowledge/expertise, you are sooner or later going to have a problem
with costs.
As an example, I worked with a legal publishing firm that was converting a
huge body of law documents to XML. But to do so they had to find people with
law degrees (no chance anyone else was going to understand this stuff) AND
computer science degrees (no chance anyone else was boring enough to write a
DTD). How much do you think a hire of that sort costs? And it should be
said, that the project was perpetually enmired in delays, slowdowns, changes
of tack as the real complexity of adding structure to documents by other
authors emerged. A nightmare.
Think I may have to drop this thread soon, but you guys are getting me
thinking. It's interesting, and good to have a civil discussion.
dan
dan donaldson
<gri...@canit.se> wrote:
> In article <B846BC25.892%d...@omnivore.ca>,
> dan donaldson <d...@omnivore.ca> wrote:
>
>> Clearly, the author is intended
>> to leave the building and let the markup editor do his thing, but what if
>> that process imposes structures and meanings on the author's text that the
>> author disagrees with?
>
> Can it normally do that? Even if you turn in a handwritten
> manuscript you have to communicate with someone about how
> you can see a piece of text is a heading, quote, definition
> or whatever. Otherwise it's just a mass of text to the
> markup editor so no structure can be added, isn't it?
>
> And today it's quite normal in word processors to use
> named styles for different parts of the text. One can of
> course use totally illogical names for them, but I don't
> think most people do. If there are such named styles I
> don't think it's much of a problem for the markup
> editor to do a translation to HTML+CSS.
I agree, but the point is that as a book moves through galleys the author
gets their input into the appearance. Most authors are smart enough to know
that someone whose entire occupation is designing books will probably have
something useful to contribute to the discussion of how the book will
appear. But the point is, that once on the press, the author, as happy or
unhappy as they may be with the final design, doesn't have to worry about
the book mutating into something in Lord of the Rings script with purple
pages.
On the other hand, HTML does provide a point where author and editor can
work out their ideas and settle on a particular appearance that after that
is (at least on that browser) in conformity with their agreed compromise.
Not so with CSS, where an arbitrary change to a definition can have any
arbitrary effect on the author's text.
>
>> Not many authors in the book publishing trade say 'I don't really mind if
>> the edition in the US has six inch margins and three columns per page, while
>> the UK one is in red on blue paper with five line drop caps.
>
> I don't think most authors, for most kinds of books, really have
> a choice other than choosing publishers.
See above - true, there are limitations. And in fact, not so very long ago,
many print houses might only have had ten faces that they set a book in. So
if you didn't like Caslon or New Baskerville, you weren't going to be happy.
But at least the choices had the benefit of a long tradition that had
defined good practice, and that as all typographic craft should, had as its
intention the clear exposition of the content. What guarantee can CSS
provide that work will be readable? Doesn't an author at least have the
right to place the condition that his work, which he has allowed a publisher
to publish be readable?
One could easily argue that CSS is based on the assumption that the authors
are secondary to publishers. This is not an assumption that has proved to be
productive of the best thought in the past...
dan
Eric Jarvis
I'm completely lost by this point in your argument...and I think we must
be thinking about the process in completely different terms...we may even
have completely different ideas about what a web site is
why is there a problem with purely conceptual mark up...surely
<class="warning"> explains exactly what is intended...I might style it as
bright red and bold...I might, in other circumstances, style it bright
yellow...but I will style it so that it stands out as a warning even
without ANY further clarification
if there are specific visual styles associated with the subject of the
site then it might be necessary for the author to say "all warnings in my
field have traditionally been marked in lilac"...but they don't have to
give precise style details in general as long as they give a style name
that fits the concept required, or add an explanation of the style names
to the document
the only additional mark up they need to really know is <div> and <span>
and some idea of why they are different
the technical complexity is only in preparing the stylesheet...as long as
the mark up doesn't attempt to be visual...any attempt to do that is
getting away from the whole idea of css...mark up is about
concepts...styling is where the visual stuff happens...it is only done
after the mark up...simple, surely?
>
> Going back to business mode, it seems to me that whenever you start piling
> expertise onto employees, you a.) increase costs and b.) increase the
> company's susceptibility to disruption (when the critical employee is ill,
> quits, is fired_. Not a popular notion. If you can't implement CSS
> structures in a reasonably straightforward way, without this emphasis on
> editor knowledge/expertise, you are sooner or later going to have a problem
> with costs.
>
> As an example, I worked with a legal publishing firm that was converting a
> huge body of law documents to XML. But to do so they had to find people with
> law degrees (no chance anyone else was going to understand this stuff) AND
> computer science degrees (no chance anyone else was boring enough to write a
> DTD). How much do you think a hire of that sort costs? And it should be
> said, that the project was perpetually enmired in delays, slowdowns, changes
> of tack as the real complexity of adding structure to documents by other
> authors emerged. A nightmare.
>
in that case I think they went about the whole thing the wrong way
>
> Think I may have to drop this thread soon, but you guys are getting me
> thinking. It's interesting, and good to have a civil discussion.
>
sometimes it's good to get down to the basics of what we are doing
Thomas Lotze
>
> One interesting thing about linked stylesheets is that the stylesheet itself
> doesn't tell you what documents are using it. So if I am working with an
> author who has defined the need for a class that happens to have the same
> name as another class in another document somewhere else, how am I going to
> know how to deal with that problem? If I can't reliably track which
> documents use an identically named class, how am I going to know what the
> consequences would be of changing the definition for that class? This is
> very similar to problems in changing functions in programming, and that's a
> very unpleasant thing, when you break other folks' code to 'improve' the
> language - in ways those other folks won't benefit from.
Of course you can't, as a stylesheet author, say 'oh, I
think I'll use the class "warning" to represent a
reference from now on". But that's not what is going to
happen: There are HTML tags with a certain meaning, and
classes can be defined to have a certain, well-defined
meaning: an element of class "warning" will always
contain a warning of sorts, never anything else, and
all warnings will be contained in a "warning" class.
So there needs to be some set of classes suitable for
the needs of all authors, authors have to be told what
the classes are named, and then they can use them
without trouble. If a stylesheet author chooses to
display warnings in green type instead of red, it'll
affect all warnings, and only warnings, if authors keep
to the conventions.
If an author thinks he needs some special presentation,
there are two possibilities: He actually doesn't because
it's not him who defines the presentation, and there
exists already a way to represent his material in a
meaningful and consistent way. Or he really has material
with a meaning for which no defined style is acceptable,
then a new one will have to be defined. This does however
not interfere with existing stuff, it's only an
independent addition.
Cheers,
Thomas
- who wonders how you manage to turn the obvious
advantages of separating style from content into
disadvantages -
--
Thomas Lotze - thomas.lotze *at* gmx.net
dan donaldson
Lotze" <p...@tpi.uni-jena.de> wrote:
I have far fewer misgivings about the separation of style from content than
I have about the separation of structure and content (see below).
I was responding to a suggestion that authors define what the style classes
be for their documents. This struck me as impracticable - you seem to
concur.
But, if an author is at all involved with the markup process (another
suggestion that I don't think a good or realistic one) they would have to
know the class definitions for the particular publication they are dealing
with. Since an author may deal with dozens of publications, this, in my
opinion, is an unreasonable burden.
Another possibility is that the author NOT involve themselves in the markup
process. This means that markup editors will have the responsibility of
deciding what structure a document has. Eric has confirmed my discomfort
with this possibility when he characterizes stylesheets thusly:
> the technical complexity is only in preparing the stylesheet...as long as
> the mark up doesn't attempt to be visual...any attempt to do that is
> getting away from the whole idea of css...mark up is about
> concepts...styling is where the visual stuff happens...it is only done
> after the mark up...simple, surely?
In other words, a style sheet based structure imposes conceptual structure
on a document - true? So, I return to my original observation that when you
have an inexpert markup editor responsible for defining the structure of an
expert document, you have a layer of meaning imposed on the work. And this
is, I think, a potentially dangerous thing. If you have editors with
considerable expertise, you raise editorial costs dramatically and you need
to define the cost benefit for that.
Say, then, the author will provide their own conceptual structure, using
tags of their own invention without any particular idea of how they will be
presented. The markup editor will 'translate' the author's tags to the
conventions that are in use where they are. So one possibility is that the
markup editor will decide that areas that the author has tagged 'warning',
'caution','alert' and 'attention' are all going to be the equivalent of his
publisher's 'look out' tag. When he runs his handy dandy search and replace
on the author's text, is he doing something different from modifying some
other aspect of the author's work? Is authorial intention going to go out
the window because we want to control font-weights?
If the author has seen fit to make conceptual distinctions within his text,
is it reasonable for an editor to blur or obliterate those distinctions? It
seems to me that exactly to the degree that CSS markup tends to the
conceptual, the more difficult it is to deal with issues of authorial
intention at this level. Do we, for example, have an obligation to express
in presentation all distinctions made by an author? If he bothered to make
them, why would we not? But if we pursue this line, how are we going to
manage the problem of multiple authors with multiple conceptual structures
which may be divergent or even incompatible? If we make the decision to
present author 1's 'warning' tag in blue bold 12 point Helvetica, how do we
square that with author 2's 'warning' tag? If we present them the same way,
are we implying that a warning in author 2's work has the same conceptual
relationship to his document as a whole as a warning in author 1 has to
hers?
These are theoretical points, but I can certainly provide examples of these
sorts of situations arising. In the pharmaceutical industry, for example,
where compendia and pharamacopaea publications have to deal with
'mission-critical' documents with prononunced and important conceptual
structure, and where the finished publication has to deal with hundreds, if
not thousands of authors.
Less theoretically, I would refer you back to my original argument, that
there is no device that this stuff actually works on, and there is no
mechanism in place for enforcing compliance with CSS standards, not even a
certification program that could provide pressure in the market for a
reliable instantiation of the techology.
dan
Eric Jarvis
>
> If the author has seen fit to make conceptual distinctions within his text,
> is it reasonable for an editor to blur or obliterate those distinctions? It
> seems to me that exactly to the degree that CSS markup tends to the
> conceptual, the more difficult it is to deal with issues of authorial
> intention at this level. Do we, for example, have an obligation to express
> in presentation all distinctions made by an author? If he bothered to make
> them, why would we not? But if we pursue this line, how are we going to
> manage the problem of multiple authors with multiple conceptual structures
> which may be divergent or even incompatible? If we make the decision to
> present author 1's 'warning' tag in blue bold 12 point Helvetica, how do we
> square that with author 2's 'warning' tag? If we present them the same way,
> are we implying that a warning in author 2's work has the same conceptual
> relationship to his document as a whole as a warning in author 1 has to
> hers?
>
I think I understand where you a re coming from...and you need to totally
rethink your concept of what a web page is
the web IS NOT VISUAL...it isn't a book...<div class="contactinfo"> is a
piece of conceptual mark up...it is a section of a web document
designated to contain contact information...however it is
experienced...with a visual browser, with a text to speech browser, or
whatever...the web exists on this level...what you see through your copy
of Internet Explorer (or whatever) is only a derivation of that
it is then up to the style designer to do their best to be true to the
author's intentions...and if they don't it won't mean ripping the
document apart to change their mistakes...it will simply mean hiring a
new "stylist" to create a style sheet that reflects the author's
intention
I see it as very much like the relationship between a playwright and a
director...the playwright will set stage directions...the director must
make those work with the dialogue as the writer intended
Jan Roland Eriksson
wrote:
>...Clearly, the author is intended to leave the building and let
>the markup editor do his thing,...
(in traditional typesetting, that is not how it works)
>...but what if that process imposes structures and meanings on
>the author's text that the author disagrees with?
I wrote something about this at one time, it's at the end of this one,
under subtitle "Author style sheets are required"...
(sorry for the long URL, Google should really give us an easier way to
reference their archive :)
>...In print, a Penguin follows the rules laid down by Jan Tischold,
>and it is a good bet that less than one tenth of one percent of the
>tens of millions of Penguin readers have ever noticed anything in a
>Penguin but the quality of the reading. That's how good the book
>design is...
JT was once employed as a book designer for Penguin and stated that
"The best of typography can not be seen", meaning that only a correct
black/white/presentation balance on a book page allows us to keep on
reading without getting mentally tired in the process.
Penguin typesetting has mastered the concept for sure.
Still, JT did not specify "dictatorial" rules on how a typesetter
should do his work, he laid down a framework for them to work within.
An analogy might be to look at the "framework" of SGML and how it can
be used to define semantically specific applications of it.
>Good book designers know that their craft has failed when
>it is noticed.
True.
>(I recommend Robert Bringhurst's book on this to anyone who
>hasn't read it...
I can second that (as well as JT's own books on the subject)...
>...and of course http://www.textism.com).
Can't say I agree with the www presentation of that even if the
content is good enough. Non adjustable font-sizes, bleeh...
(long live Operas min font-size config option, or just turn author CSS
off for a better experience on just this site :)
--
Rex .. <r...@css.nu> .. <http://css.nu/>
Jan Roland Eriksson
wrote:
[...]
>One interesting thing about linked stylesheets is that the stylesheet itself
>doesn't tell you what documents are using it. So if I am working with an
>author who has defined the need for a class that happens to have the same
>name as another class in another document somewhere else, how am I going to
>know how to deal with that problem?
This has been a problem since day one of CSS when both the CLASS
attribute and the ID was allowed to appear as selectors, and if I dare
say so; the CASCADE in CSS it self creates problems too.
ID should not have been allowed as a selector at all in the first
place, it has another well defined role to play together with the
IDREF attribute.
CLASS came into HTML as an attribute defined to allow for an expansion
of element semantics, but was never restricted to some standardized
groups of values valid for various elements, but instead defined to be
of type CDATA (anything goes, almost :)
The basic "wrong" in using CLASS and ID as selectors is that we end up
suggesting presentation based on semantics instead of context.
This will probably be taken care of as clients evolve into better
support for "contextual selectors". I still use quite a lot of
CLASS'es in my style sheets but I do try to move over to "contextual
selection" as soon as I do find usable support for it.
CSS'ers in general often seem to forget that we need well structured
and detailed markup first (i.e. a well established context), before
there is much use in suggesting presentation for content, and HTML is
not the correct tool for "detailed" markup sorry to say (nor is "make
up your own tags as you go" that seems to be the major fad in XML).
>If I can't reliably track which documents use an identically named
>class...
You can't...
>...how am I going to know what the consequences would be of
>changing the definition for that class?
You can't...
>The only conclusion one can come to is that the intention of stylesheets is
>that an independent markup editor will impose a style convention on a series
>of documents written by others, and by so doing will eliminate any
>possibility of the author having useful control over the presentation of
>their work.
And on top of that you have to face the fact that users may have their
own style sheets cascaded into the chain too, it's a mess; right?
(or maybe just a reflection of the old and well established internet
anarchy :)
dan donaldson
MPG.168c30c5d...@News.dial.pipex.com, "Eric Jarvis"
<nos...@last.dircon.co.uk> wrote:
>> them, why would we not? But if we pursue this line, how are we going to
>> manage the problem of multiple authors with multiple conceptual structures
>> which may be divergent or even incompatible? If we make the decision to
>> present author 1's 'warning' tag in blue bold 12 point Helvetica, how do we
>> square that with author 2's 'warning' tag? If we present them the same way,
>> are we implying that a warning in author 2's work has the same conceptual
>> relationship to his document as a whole as a warning in author 1 has to
>> hers?
>>
>
> I think I understand where you a re coming from...and you need to totally
> rethink your concept of what a web page is
>
> the web IS NOT VISUAL...it isn't a book...<div class="contactinfo"> is a
> piece of conceptual mark up...it is a section of a web document
> designated to contain contact information...however it is
> experienced...with a visual browser, with a text to speech browser, or
> whatever...the web exists on this level...what you see through your copy
> of Internet Explorer (or whatever) is only a derivation of that
I swore I wouldn't follow the thread - but then, I created this tangle.
Thanks for the time taken to think it through.
But I'd like top know how you might address the issue I raised. Givens: you
are a markup editor dealing with an author-tagged document using strictly
'conceptual' tags, without any assumptions made about presentation explicit
in what the author has written (and lets assume he's dead but still able to
come back from the grave to haunt you if you get it wrong...)
If the author has three distinct classes that seem (to you) to correspond to
an existing class ('warning','caution','alert'), would you change the class
names in the document to conform to the existing stylesheet, or would you
instantiate classes that have the author's names but simply cascade or
reiterate the existing class? Or would you do something else? If you could
see no apparent reason for the different applications would you assume that
the author was making a useful distinction and preserve it, or that he was
not, and homogenize it? What would be your criteria?
If you chose to preserve author-specific tags in the document, how would you
deal with multiple classes with identical names generated by multiple
authors? What mechanisms would you suggest or employ to manage, lets say,
200 separately defined 'caution' classes from 250 different authors?
Would you feel that it was safe to assume that class='caution' in author 1
should be treated identically with class='alert' in author 2? If you had a
class intended to deal with warnings in the site's stylesheet, would it be
reasonable to map both or either author classes to your class 'warning'
defined in your standard stylesheet? And if so, would you think that the
consequences of these two classes having the same presentation to be a
trivial or non-trivial issue?
I would like to know, because this seems to me an important test of a
conceptual approach to stylesheets - essentially, where the tagging lines up
as elements of authorial intention, and the amount of weight given to that.
dan
Jan Roland Eriksson
<nos...@last.dircon.co.uk> wrote:
[...]
>the web IS NOT VISUAL...it isn't a book...
No argument there...
> <div class="contactinfo">
>is a piece of conceptual mark up...it is a section of a
>web document designated to contain contact information...
But here for sure.
Simply put; in lack of a formal definition of the attribute value
"contactinfo", that can be translated into any one of this worlds
spoken languages, "contactinfo" is "data without meaning", it's just a
series of arbitrary characters.
It seems to me that you have just fallen into the same "make up your
markup as you go" trap that just about every new XML'er does.
On top of it all we might want to have some way to let machines verify
our correct syntactical use of said attribute value.
(X)HTML does not allow for that because...
1) CLASS attribute values are defined as CDATA...
2) ...which eliminates the possibility to create standardized
groups of semantically defined CLASS attribute values
for (X)HTML elements.
In another comment to Dan I posted this URL, maybe you want to find
some time to read it too?
Ben M
> On 19/12/01 1:21 AM, in article
> Xns917C54C425B3...@193.229.0.31, "Jukka K. Korpela"
> <jkor...@cs.tut.fi> wrote:
>
> > In any case, an author should select the markup so that it corresponds
to
> > the logical role of the text, or at least doesn't conflict much with it.
>
> Here is an interesting example of the problem I was pointing out.
>
work.
> burden on the author. The idea that someone has to know a technology like
> CSS/HTML/XHTML to express what they know about, say, stock options or
> cardiac care or garden care is not a good one.
>
> I will argue that while, in some sense, CSS,XML and their ilk can achieve
> separation of content and structure, they can only do so by imposing a
> division between expression and knowledge. In other words, someone with
> knowledge cannot express themselves in this medium without either becoming
> knowledgeable in this technology.
From my point of view I use Microsoft Word XP to write a lot of reports etc
for university.
These are all saved in the native word format and printed off etc. However I
also publish them to my website.
How do I convert these documents from one format to another? Save as
Filtered HTML.
Using Microsoft Word XP and making sure the settings are ok (A little
fiddling with the HTML publishing options, but this isn't really neccesary).
I write my documents with a simple rule I use the Style or format pulldown
menu (the one next to the font selection) to style my documents. The save as
filtered HTML optioned removes most of the gunk word normally leaves in the
file. Cutting and pasting the body of this newly created document into my
standard HTML template is quite simple (a 15 second job, including opening
the files). Save this and I've got a fully working web page. Because I use
included menus on my site, one modification to these and the newly uploaded
document is available to all my visitors.
So what does this mean, why am I going on about? Well the facilities CSS
offers me, style and content seperated, mean that I can use a standard word
processing package to write my document. A simple save option followed by a
cut and paste inserts the document into my website. But not just as HTML, as
HTML styled with my site wide stylesheet, instant uniformity (the ultimate
corporate dream!)
That's not the end of it though, automation of this problem, converting from
batches of word documents to filtered HTML is probably available from some
utility or other (There are a lot of these around as I found out when I had
to convert several thousand Lotus documents to Microsoft Officen atwork!)
Even the cutting and pasting could be automated, I've done plenty of work in
this area with XML documents, doing the same thing using the HTML DOM isn't
to difficult, a little javascript in a .hta document could automate this
part quite easily.
> This puts a priority and a value not on the best knowledge, but the best
> combination of knowledge and this technology. I can safely assume that
> neither my stock broker nor my cardiologist are moonlighting as markup
> wizards. In fact, I expect them to be devoting their time to further
mastery
> of their expertise, not some subset of web technology.
>
> So for them to express what they know in this medium, they have to submit
> their knowledge to a process that imposes a second level of meaning upon
it.
> A markup editor will have to make decisions as to what the meanings of
> various elements in the text they have been provided are. Whether they can
> be effective in communicating what they have done to the original author
is
> not something contained within the CSS specification, so far as I know.
With the simple and automatable process described above whatever meaning
they imposed on their text in a standard word processor would be replicated
in the newly styled HTML document, and IMHO a little easier than importing
the original document into a purpose built HTML editor.
> You can argue that the classic paper-based publication process also
imposes
> a need for editorial and layout editors to process manuscript text. But
the
> role of an editor in this case is to a.) facilitate peer validation of the
> text by other experts (not usually the editor), and b.) impose order -
> primarily visual order. With metadata markup, a very dangerous thing
happens
> - the editorial process imposes not just order, but meaning on a text, and
> the generation of that meaning is the responsibility of people without
> expertise in the field the text addresses.
>
> Tim Berners-Lee was very clear that his objective was to produce a markup
> language that would not impose unreasonable cost of learning and mastery
on
> users. <H></H> tags both carried visual and informational order: they
> suggested a hierarchy of importance and allowed a practical subdivision of
> knowledge, which is not the same thing as the imposition of meaning. Any
> researcher could grasp this concept and apply it in twenty minutes. At the
> same time, it was well within the powers of the commercial and open source
> communities of developers to create compliant devices - browsers - to
> express the information contained in this markup.
>
> My orginal argument/observation was really, 'that's nice, but it doesn't
> work, and the people I talk to don't care about it if you can't show it to
> them working.' In this sense, CSS is the last great holdout of the
Internet
> Bubble Mentality: absolute vapourware with the assumption that investors
are
> not going to ask too many questions, and certainly not expect to see a
> working example, never mind a positive cost-benefit before ponying up the
> dough.
>
> But at a more theoretical level, here's what I think the problem is:
>
> Implied in the idea of metadata is that a.) before researchers can have
> access to information a increased amount of time will pass than would have
> happened with appearance-based markup, which in turn is a greater gap than
> plain-text (ie purely authorial) documents; b.) the process that they will
> be subjected to will be inherently unreliable, introducing a second level
of
> error as inexpert markup editors impose meaning on expert texts; c.) an
> individual author can only deal with this problem partially, and that by
> learning an abstruse, changing technology, thus diverting them from their
> primary expertise; d.) in any case, this technology has no compliant
device
> (ie browsers) to use the information; e.) neither is there any immediate
> prospect of a compliant device appearing, as the body charged with
> developing standards has no power to enforce compliance, and does not
offer
> certification that would aid its adoption in the marketplace.
>
> Phew!
>
> This, realistically, is why CSS strikes me as a not-ready-for-primetime
> technology, and a boondoggle.
>
> dan
Hey what can I say I'm a university student untainted by the gloomy
realities of the corporate world, but separation of content and style which
can be provided by CSS is a real benefit to me personally. Yes I know HTML
and CSS quite well but to move my word documents to HTML requires two
actions, save as filtered HTML and inserting it between two tags called
start content and end content.
Anyway points in CSS favour
1. I can change the layout, colour and entire style of my site by changing
the text in three style sheets (one of which is for print layout). Corporate
rebranding anyone?
2. Using the process outlined above I can convert all my reports into HTML
documents which conforms (type, font size, colour etc) with the rest of my
website. Each document = approx 1 minute tops.
3. The underlying code is structured logically thus it is more accessible.
3.1. Accessibility isn't just an issue for people with disabilities, e.g.
bad sight etc, it's an issue for people with none standard browsing devices
e.g. PDA's and mobile phones.
If your interested in every user having exactly the same experience then
stick with acrobat's pdf files, if your interested in your site looking
good, but also accessible to the widest audience/ customer base now and in
the future (anyone who thinks all those NN 4.x work arounds aren't going to
cause problems sometime is kidding themselves).
Ben Meadowcroft
http://www.benmeadowcroft.com
Andy Dingley
>This, realistically, is why CSS strikes me as a not-ready-for-primetime
>technology, and a boondoggle.
I disagree entirely.
CSS is easy. It's _far_ easier than the old ways of doing non-trivial
layout (stretchy GIFs ?!). Simple CSS is even easier, and although
complex CSS is still difficult, it's not unreasonable to expect this.
If you're using pre-built stylesheets (which is what M$'s broken and
incomplete "themes" notion could have been) then it's absolutely
trivial to author content for a CSS environment. You can have such
themes built by bringing a trained design geek on board for a while,
or you can buy them ready-made (as we used to, 10 years ago, doing DTP
with Ventura).
Secondly, you're too late to describe CSS as "not ready". Two years
ago you had a point. Now we're at a state where the CSS question has
reduced to whether supporting the last few non-CSS users is worth the
effort.
--
Smert' Spamionam
Rijk van Geijtenbeek
wrote:
><URL:http://groups.google.com/groups?q=decode+and+recognize&hl=en&rnum=1&selm=gbksat4allprkepjv69nv93ckqoqecgr41%404ax.com>
>
>(sorry for the long URL, Google should really give us an easier way to
>reference their archive :)
Like this one?
http://groups.google.com/groups?selm=gbksat4allprkepjv69nv93ckqoqecgr41%404ax.com
:)
I clicked 'Original format', then stripped &output=gplain from the url.
--
If Microsoft invented plumbing, legions | Rijk van Geijtenbeek
of hackers would smugly discuss the |
benefits of washing in a stream. | http://rijk.op.het.net/
- Michael Kanellos | mailto:ri...@iname.com
dan donaldson
"Andy Dingley" <din...@codesmiths.com> wrote:
> Secondly, you're too late to describe CSS as "not ready". Two years
> ago you had a point. Now we're at a state where the CSS question has
> reduced to whether supporting the last few non-CSS users is worth the
> effort.
My clients pay me to tell them if things work. If they do, sometimes, if
there is an economic reason to do so, they adopt these things. If there is
no economic rationale, they don't. In the case of CSS, the cost benefit is
not clear, and seems to be likely to raise costs in many areas, although it
solves some short-term problems.
No browser effectively supports CSS in anything close to its full
definition. If we think of a site as a collection of CSS features, the
audience for the site is the intersection set of installed browsers that
support not CSS, but support that set of CSS features. Where they do not, I
incur costs in support, lost revenue and perception in the marketplace.
Alternative approaches not using CSS often reach 100 percent browser
support. Only if I rely on features that CSS alone provides can my audience
be larger than if I use non-CSS approaches. Many of these CSS features have
poor support, and there may be no intersection set for a particular pair of
CSS-only features. Many CSS practices required better trained, more costly
staff but don't provide my clients with quantifiable cost benefits.
No mechanism exists to force browsers to support CSS in a reliable way. No
timetable exists for the emergence of a fully or mostly CSS capable browser
that will become dominant in the market (Opera, are you listening?). Nothing
compels the CSS definitions not to change, causing further confusion among
browser creators and further fragmentation of the installed base.
Using CSS for a new project with an indeterminate feature set, the cost is
indeterminate, the benefit indefinite and the audience potentially small.
Using non-CSS approaches, the cost is predictable, the benefit can be
readily estimated and the audience is large. How would you expect a
responsible manager to proceed?
The question is not really 'does CSS work?', it's 'can I be reasonably
confident that having committed my client to a CSS approach, I/they won't be
blindsided by an apparently simple thing that just plain doesn't work?'
The answer is no. When the answer is yes, CSS will be ready for prime time.
dan
Jukka K. Korpela
> There are HTML tags with a certain meaning, and
> classes can be defined to have a certain, well-defined
> meaning: an element of class "warning" will always
> contain a warning of sorts, never anything else, and
> all warnings will be contained in a "warning" class.
So you're saying that class names could be used as a markup language. Who's
going to define it? And what's the point of using <span
class="warning">...</span> when you could just as well define syntax and
semantics for <warning>...</warning>?
Besides, what authors are already doing is class="red" and class=
"font_16pt" and things like that. If you aimed at standardized class names,
they should have been defined years ago.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Eric Jarvis
you have to start from the premise that the author has a reason for using
the separate classes...and if they are repeated then you can be entirely
confident in that...for a subtle distinction one would hope for an
explanatory note...and follow it if it's there...but there are dictionary
definitions to help too...so I would consider it safe to say that a
"warning" is intended to last over time and so the content of it must be
driven home to the reader (so nice large bold text in a clearly legible
colour so that the "warning" as a whole stands out and sticks in your
mind, maybe even a background colour or a box around the text)...a
"caution" is not as severe but again exists over time (so higlighting by
bold text or use of a strong and readable colour, maybe some sort of
subtle "boxing" of the caution)...an "alert" is a one off and needs to
grab attention right now (bright colours I suspect)
>
> If you chose to preserve author-specific tags in the document, how would you
> deal with multiple classes with identical names generated by multiple
> authors? What mechanisms would you suggest or employ to manage, lets say,
> 200 separately defined 'caution' classes from 250 different authors?
a style sheet for each author quite probably...but mostly one would be
able to transfer the bulk of it intact
> Would you feel that it was safe to assume that class='caution' in author 1
> should be treated identically with class='alert' in author 2? If you had a
> class intended to deal with warnings in the site's stylesheet, would it be
> reasonable to map both or either author classes to your class 'warning'
> defined in your standard stylesheet? And if so, would you think that the
> consequences of these two classes having the same presentation to be a
> trivial or non-trivial issue?
this depends on the situation...if it's a set of documents from different
authors within a single site with a single design, then you have to
homogenise the presentation...if it's different sites then you perhaps
should for accessibilities sake...but it becomes a trade off between that
and fitting the author's intention exactly
it gets more complicated when you work in multiple languages...what
constitutes a suitable presentation for a warning in English may not do
so in Greek...but that is an entirely different puzzle that I'm still
trying to decipher
> I would like to know, because this seems to me an important test of a
> conceptual approach to stylesheets - essentially, where the tagging lines up
> as elements of authorial intention, and the amount of weight given to that.
>
I've been treating it very much as I treat directing a play...for a first
production with a living author then it involves consultation...for a
retread of something by someone no longer contactable then you have to
trust your own judgement
I have a set of reasonable assumptions of how an audience might respond
and a set of values and expectation that I expect them to largely
share...for theatre I use those to decide how to interpret a play...on
the web I use the same things to decide how to present a web page
Thomas Lotze
>
> So you're saying that class names could be used as a markup language. Who's
> going to define it?
As it seemed to me the OP was talking about managing
documents for one common project, I was thinking about
the situation where you have a lot of authors on the
one hand, someone who is responsible for presentation,
and - this is the point - they know each other. So,
before starting their writing, the authors would have
to read an authoring guideline written by the
presentation guy (as they have to do if writing books
for some publisher, for instance). This guideline would
define the classes used in this particular multi-author
project.
> And what's the point of using <span
> class="warning">...</span> when you could just as well define syntax and
> semantics for <warning>...</warning>?
If you're dealing with HTML/CSS, you can't define
<warning> tags, but you can define your own
project-wide classes. For tags, you have to stick with
the HTML specification.
> If you aimed at standardized class names,
> they should have been defined years ago.
If you're thinking about standardization on a global
level, then you're partly right. Partly, because if
one started such a standardization now, it would be
useful for future projects, if not for existing ones.
Just the same as with a new HTML spec or whatever.
However, I was thinking about project-wide standards.
Cheers, Thomas
Thomas Lotze
>
> If the author has three distinct classes that seem (to you) to correspond to
> an existing class ('warning','caution','alert'), would you change the class
> names in the document to conform to the existing stylesheet,
Never. Provided the author indeed used strictly conceptual
markup, his files would be read-only for me. That's
authorial intention, and as a presentation guy, I'm not
expert enough to fiddle with the author's work.
> or would you
> instantiate classes that have the author's names but simply cascade or
> reiterate the existing class?
No, but...
> Or would you do something else?
write guidelines the authors for this particular project
have to read before they start writing, and have to
adhere to.
> If you could
> see no apparent reason for the different applications would you assume that
> the author was making a useful distinction and preserve it, or that he was
> not, and homogenize it? What would be your criteria?
As said, I wouldn't do anything about the author's text,
assuming he sticks to the guideline. If he doesn't, I
would ask him to fix this, or otherwise explain to me
his special needs so I can do something about them.
> If you chose to preserve author-specific tags in the document, how would you
> deal with multiple classes with identical names generated by multiple
> authors?
With an authoring guideline, this problem wouldn't arise.
Cheers, Thomas
Rijk van Geijtenbeek
wrote:
[..]
>The question is not really 'does CSS work?', it's 'can I be reasonably
>confident that having committed my client to a CSS approach, I/they won't be
>blindsided by an apparently simple thing that just plain doesn't work?'
>
>The answer is no. When the answer is yes, CSS will be ready for prime time.
Nonsense. With the same argument, you could say that HTML is not ready
for prime time. Support for many elements is miserable, the spec keeps
changing (work on XHTML 2 will start shortly), browser treat the same
markup in different ways etc. What do you mean with 'the css approach'?
It is not an 'all or nothing' question.
Using CSS to replace color, alignment and font attributes has been
working in >95% of browsers for a long time now, and makes maintaining a
consistent look and feel on large websites much easier (and so cheaper).
Using CSS to fine tune margins and paddings can be used with care, and
offers much more control on the layout than tricks with spacer gifs and
non breaking spaces. It takes some effort to understand the intricacies
of Netscape 4, but once that hurdle is passed it is easy to build and
maintain.
Using CSS to replace tables for positioning blocks is becoming useful,
but it is still a major headache with various problems in MSIE 4-6 and
almost impossible to get to work in Netscape 4.
Henri Sivonen
<d...@omnivore.ca> wrote:
> No browser effectively supports CSS in anything close to its full
> definition.
What's the full definition? CSS1? CSS2? CSS3?
Moz/N6, Opera 5/6, Mac IE 5 and Windows IE 6 come very close to the CSS1
definition.
--
Henri Sivonen
hen...@clinet.fi
http://www.hut.fi/u/hsivonen/
dan donaldson
"Rijk van Geijtenbeek" <ri...@iname.com> wrote:
>> The question is not really 'does CSS work?', it's 'can I be reasonably
>> confident that having committed my client to a CSS approach, I/they won't be
>> blindsided by an apparently simple thing that just plain doesn't work?'
>>
>> The answer is no. When the answer is yes, CSS will be ready for prime time.
>
> Nonsense. With the same argument, you could say that HTML is not ready
> for prime time. Support for many elements is miserable, the spec keeps
> changing (work on XHTML 2 will start shortly), browser treat the same
> markup in different ways etc. What do you mean with 'the css approach'?
> It is not an 'all or nothing' question.
>
If HTML is ready for primetime, why do we need CSS? The argument for both
technologies is identical: if you are prepared to live with its quirks, it
does a splendid job. For some things HTML is crappy at, CSS is better. The
reverse is also true. In certain situations this includes the use of
<center> tags.
> Using CSS to replace color, alignment and font attributes has been
> working in >95% of browsers for a long time now, and makes maintaining a
> consistent look and feel on large websites much easier (and so cheaper).
I understand from what you write that it isn't all or nothing. I agree. I
use CSS for some things, but I consider a lot of these trivial or even
problem-creating in themselves. But I haven't seen any compelling, large
scale business case for reduced costs with CSS. If you know of one, let me
know. If you donšt then how do you account for higher staff training costs,
the need to re-edit old documents, the loss of traffic to non-css browsers
and the increasing complexity when dealing with custom stylesheets for
multiple authors? These are very real costs in many organizations.
The larger promise of CSS is not fulfilled. I doubt anyone would say it was.
So most CSS advocates are really not interested in CSS as a spec anyway, but
just the subset that they use. Kind of like being unconcerned if Photoshop
crashes your computer when you use certain tools, and rationalizing it with
the statement that 'I don't need to use those tools to get the job done'.
The bigger question is, if no mechanism (economic, regulatory, etc.)
guarantees that the features I do need will continue to work, should I be
making a significant investment in this approach? The argument that 'we're
doing it this way because there's no other way to do it has proved not to be
a very good bet in capitalist societies. Americans once made crappy cars.
Visit Flint Michigan some time.
The problem is that more and more sites use the quasi-functional parts of
CSS, and ignore or avoid the others, so the incentive for browser
programmers to add support for a complete feature set vanishes. On the other
hand, this installed base of quasi-functional CSS based sites acts as a
point of market resistance for anyone who comes up with a better system -
one that might solve some of the authorial problems we've been discussing,
as well as do simple things like provide robust font embedding and so on.
No-one will back a technology that competes with an established one where a
clearly defined advantage isn't gained in short order. CSS advocates
experience this every day in their arguments with people like me who are
skeptical.
In any event, if I as a user donšt visit the tiny percentage of sites that
use the more 'unreliable' CSS - often the very things that made CSS sound
useful in the first place - then a new browser with support for this more
complete feature set will not offer me an advantage. So I won't adopt that
new browser, unless for some other reason unrelated to CSS, like for
instance, I get a new computer. This in turn will lead to further
fragmentation of the browser installed base. This will get worse - much
worse - as standards like XHTML emerge.
Commercial technologies exist because they are intended to give their owners
an advantage in the market. This situation will never arise in CSS because
browser programmers know already that a perfect implementation would not
make them a penny, and would cost them a lot. And, because both users and
shareholders donšt care how the page was done. They care that it looks ok
and is readable, and so are a lot happier with frames and center tags that
work, than CSS that doesn't.
dan
Alan J. Flavell
> If HTML is ready for primetime, why do we need CSS?
To suggest presentation(s) for the logical structures marked up in
HTML, of course.
> The argument for both technologies is identical:
Complementary.
Don't confuse the temporary mess of quasi-presentational HTML that was
HTML3.2 with anything that makes long-term sense in a WWW context.