Re: what happens if first-line contains markup?

Lauren Wood writes:
 > > From: Chris Lilley <Chris.Lilley@sophia.inria.fr>
 > > 
 > > Lauren Wood writes:
 > > 
 > >  > It should be made clear in the draft that this applies to
 > >  > attributes other than ALIGN, and that, as Chris Wilson said, 
 > >  > if someone uses <I STYLE='font-style:none'> that it ends up 
 > >  > in plain text. 

 > > Why? It seems simple. Some text was put in an I element. The suggested 
 > > default rendering of I elements is italic text, if the user agent
 > > supports it. If someone puts a style attribute on an element, they are
 > > not going to be surprised if the style changes, are thay?
 > My answer to this one: when I told some randomly-chosen computer-type
 > people (who know HTML) that this was how it worked, they were
 > surprised.

What other knowledge did your sample have? Given where you work, I
would expect them to understand the difference between structure and
presentation fairly well. I am surprised they were surprised, if you
see what I mean. 

 > Readers could also be surprised that things that were emphasised when
 > they have style sheets turned off, are no longer emphasised when they
 > are turned on. 

This could apply to anything using a stylesheet. Readers could be
surprised that everything is not in Times anymore. They could be
surprised that a heading got bigger, or smaller; or (with a
less-than-useful stylesheet) that P's come out larger than H1's.

We already know that there are people out there who are surprised that
other people have a different window size than they do; that other
people set their fonts to different sizes; that people on different
platforms see different colors for the same GIF, that not everyone
sees links in blue, and so on. I put all these things down to
unfamiliarity with cross-platform, paperless authoring (and to a large
part, with invalid assumptions being carried over from paper-based
authoring). In other words, I see this as a general education issue.

 > I believe it to be a good idea to spell out everything in
 > a spec that might surprise people. The technical support department of
 > the company I work for spends a lot of time explaining these sorts of
 > details to users, and it would be thus be extremely helpful to have a
 > definite line or example in the spec to be able to point them to.

Having worked in my previous job as a technical author, I am certainly
not going to disagree with this. Unexpected or surprising items should
certainly be well documented and explicitly called out to readers.

Where we differ is in what we consider surprising. If someone puts a
style attribute on an element to alter it's presentation, my assertion
is that the author is not going to be surprised when the presentation
of that element alters.

 > It  would also help implementors.

That is a different problem, and I agree that if there is something
which might be hard to implement with, erm, certain choices of parser
technology, then the spec should hilight that. Making something be
italic or not does not seem hard to implement, so this particular
example does not illuminate the ease-of-implementation issue. Do you
have other examples (besides italics and besides block|inline) which
you feel might be tricky to implement?

One other thing comes out of your posting, which is potentially
valuable; a need for guidelines for stylesheet design. One rule of
thumb springs to mind: a page designed with stylesheets should be
usable by a non-stylesheet-enabled browser.

For example, putting all the body text in an H1 and using a stylesheet
to make it smaller is a bad idea. Putting everything in P's and using
stylesheets as the sole form of structure is also bad design. (We are
already seeing similar pages appear where the only tags used are FONT
and BR).

From your example, using an I as a container for some other purpose
unrelated to typographic emphasis might well be bad design. Then
again, a browser which has a limited choice of font weights and styles
but had color capability might well use subtle color shifts rather
than italic and bold faces to render I and B.

Chris Lilley, W3C                          [ http://www.w3.org/ ]
http://www.w3.org/people/chris/                       INRIA/W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 93 65 79 87            06902 Sophia Antipolis Cedex, France