Tribeless Nomad (tribelessnomad) wrote in lj_userdoc,
Tribeless Nomad
tribelessnomad
lj_userdoc

Inline markup

We've finally had a good discussion about inline HTML. Now we can start fixing the documentation accordingly.

I want it to be policy, for now, that the site's documentation will not recommend the use of CSS in LiveJournal posts. We can consider loosening the rule, if someone meets my challenge to prove that there are advantages to replacing troublesome FONT tags by inline CSS declarations. As far as I know, any such replacement just creates new problems, without fixing the old ones.

I'm talking specifically about inline CSS in journal entries and comments. Suggesting the use of CSS in styles and overrides is sometimes acceptable.

So, let's get started:

FAQ #72 has been drawing criticism lately for giving bad advice. As a partial replacement, I've posted a draft of a new Guide called "Text in Journal Entries".

The new Guide is only one of several planned documents explaining HTML usage. There will be more Guides dealing with other aspects of HTML in journal entries. There will also be an Allowed HTML Reference which describes each permitted HTML element in a systematic way. And somewhere, probably in the introductory part of the Reference, we should have a quick explanation of the general principles of HTML.

Contributions such as the following would be timely and very welcome here:
  • discussion of whether punctuation and other special characters should be explained in a separate Guide. If so, how should the two Guides be titled?
  • a rewrite of FAQ #72. The list of allowed tags should be updated. The bold/italics sections should be replaced by a link to the new Guide. Users should not be told that tags can be nested in the wrong order. I'm sure that lots of other changes are also desirable, and that's where the rewriting comes in, so please don't just make the changes I listed here.

  • improvements to the new Guide. What did I miss out, obfuscate, or get wrong?
  • research (or just dump your knowledge). Here's an easy question: why, exactly, is <strike> deprecated? It's not just because it's a presentational element; some other presentational elements remain un-deprecated. Maybe it's because strikethrough isn't supported by as much software as italic and bold type? The W3C probably had a good reason, but I'd like to know what it was before I start saying that the element should be avoided.
  • more research. For a much harder question, see my challenge to CSS advocates.
Comments on best HTML/CSS usage should ideally be added to the discussion already underway, where the main issues have already been addressed.
Subscribe
  • Post a new comment

    Error

    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 7 comments