Home » forums » Site Discussion

HTML guidelines

Is it generally ok to post content with character entity references (like ⇒ for ⇒)? I mean how many people won't be able to read that?

Also, I remember seeing discussion on using "style" tag, but without any conclusion. Could we standardize some style classes by inclusion of their definitions in LtU CSS file(s)? I think we need classes for at least quoting previous comments (italic?) and for excerpts (blue italic? should we break tradition to make it different in color from default links?).

By Andris Birkmanis at 2004-08-02 13:24 | Site Discussion | previous forum topic | next forum topic | other blogs | 7187 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

proper html elements instead of classes

I'd vote for using blockquote elements for both quotes and excerpts. Ehud seems to do this already on his frontpage items.

For quoting inline there is the q element, although it's not styled italic yet.

Character entities look OK here on both Firefox and IE.

By Sjoerd Visscher at Mon, 2004-08-02 13:50 | login or register to post comments

User stylesheet

For quoting inline there is the q element, although it's not styled italic yet.

You can change this in your user stylesheet. Not sure how you do this in Mozilla, but in Safari there's an option in the Advanced preferences to specify a user stylesheet. I have mine quite heavily customized. The relevant CSS is:

q { font-style: italic; }

Character entities should be fine. Whether a client has a font which can display the given character is another issue. Is there a set of character entities which clients are required to be able to display? The ⇒ entity displays fine in Safari for me.

By Neil Madden at Mon, 2004-08-02 14:18 | login or register to post comments

Re: HTML guidelines

Is it generally ok to post content with character entity references (like ⇒ for ⇒)? I mean how many people won't be able to read that?

I'd say if you need it, use it, and hopefully anyone who can't see it will say so.

Also, I remember seeing discussion on using "style" tag, but without any conclusion. Could we standardize some style classes by inclusion of their definitions in LtU CSS file(s)?

The LtU CSS files will do this very soon.

I think we need classes for at least quoting previous comments (italic?) and for excerpts (blue italic?

Yes. The <blockquote> element should be used for block quotes, naturally. For inline quotes, I think we'll use the Q element, although I see it's been deprecated/removed in XHTML 2 (but its replacement isn't yet supported by browsers).

should we break tradition to make it different in color from default links?).

I was thinking of using the fairly standard approach of inserting a vertical bar in the margin of a blockquote, which ought to make such quotes unambiguous, regardless of their color. For inline quotes marked up with Q, I think we'll avoid blue.

By Anton van Straaten at Mon, 2004-08-02 16:37 | login or register to post comments

Blue text

If blockquotes would become blue, links in the quoted text would not longer stand out.

By Sjoerd Visscher at Mon, 2004-08-02 21:13 | login or register to post comments

Good point

We'll use some other color, then, or maybe a different colored background.

By Anton van Straaten at Mon, 2004-08-02 21:32 | login or register to post comments

You are giving me the blues...

I really like the color blue for blockquotes on the home page. These usually don't contain links (they are often paper abstracts), and I find that the blue italics make them stand out. In comments, grey backgound is nicer.

It seems that I have no taste in these manners, so I will accept whatever others think best.

By Ehud Lamm at Tue, 2004-08-03 06:12 | login or register to post comments

Taking away the blues

I also think the blue looks good. Blockquotes could certainly be formatted differently depending on where they appear.

By Anton van Straaten at Tue, 2004-08-03 15:28 | login or register to post comments

Use of XHTML on LtU

Yes. The <blockquote> element should be used for block quotes, naturally. For inline quotes, I think we'll use the Q element, although I see it's been deprecated/removed in XHTML 2 (but its replacement isn't yet supported by browsers).

Until you serve the content as one of the XHTML content types, it doesn't matter how well you adhere to the XHTML DTDs, because browsers will treat your page as a form of Tag Soup anyway. Ian Hickson gives a good explanation of why this is the case, and why browsers can't automatically detect an XHTML document served as text/html.

You would, in fact, be better off serving your page as HTML4.01 Strict, because IE at least understands that. If you're not catering to the lowest common denominator, then you should serve with the correct content type, else you lose more by using XHTML markup than you gain.

(Note the page renders just fine. It's not broken. But there's no need to worry about standards adherence when you're using the wrong content type anyway, and there's no support of the right content type planned for IE - XHTML appears to be a stillborn!)

By bje at Thu, 2004-08-05 04:20 | login or register to post comments

Re: Use of XHTML on LtU

Until you serve the content as one of the XHTML content types, it doesn't matter how well you adhere to the XHTML DTDs, because browsers will treat your page as a form of Tag Soup anyway.
Right. I'm really talking about cheating: in the absence of a translation layer between message source and presented output, I want to select a subset of HTML which "happens" to intersect XHTML, with an emphasis on semantic tags. The goal is to have the source of messages be as meaningful as possible, and not particularly presentation-oriented - the CMS themes and CSS stylesheets can take care of that side.
You would, in fact, be better off serving your page as HTML4.01 Strict, because IE at least understands that. If you're not catering to the lowest common denominator, then you should serve with the correct content type, else you lose more by using XHTML markup than you gain.
What's currently being served is just the Drupal and/or theme default, since as you say, it's not broken. I'm more interested in the source format of the messages - that's what's in the database, and what needs to be maintained long term, as the software changes.
But there's no need to worry about standards adherence when you're using the wrong content type anyway, and there's no support of the right content type planned for IE - XHTML appears to be a stillborn!)

I'm interested in alignment with future standards for semantic markup, because in say five years time, the message source format might not have changed, but the tools serving it could be replaced entirely, as just happened in the transition from Manila.

Underlying my thinking on this is the fact that I've done a conversion of the Manila messages, and run into many of these kinds of issues, which is why that conversion hasn't been published yet.

By Anton van Straaten at Thu, 2004-08-05 05:45 | login or register to post comments

No more ASCII art

An image upload facility would help. I see ASCII art on LtU, like the recent category diagrams. We can do better than that! The discussions about sets just beg for Venn diagrams.

By Mark Evans at Tue, 2004-08-03 05:36 | login or register to post comments

Future enhancement

We're considering some options in that area, but I think it'll be a while yet before anything is done.

By Anton van Straaten at Tue, 2004-08-03 15:31 | login or register to post comments

Why not now

Please explain the hardships involved. LtU may have ideas.

By Mark Evans at Tue, 2004-08-03 21:44 | login or register to post comments

Priorities

It's just a question of priorities. I don't see any reason we should be rushing to install an image upload capability, and the approach we choose to provide that (e.g. Drupal module or something else) will be affected by other plans we're considering.

By Anton van Straaten at Wed, 2004-08-04 00:14 | login or register to post comments

No rush

No one proposed a rush or priority inversion. No one else has the priority list, so how could we? Your answer is too vague for anyone to help with Drupal problems.

It could be done completely outside of Drupal as an FTP drop with username/password as per LtU user accounts. In fact that is probably the best way to do it.

The semantic richness of LtU would be vastly improved by the additional (visual) mode of communication. I keep hearing how we want Q and BLOCKQUOTE to track semantic content, not just formatting. Well, visual communication is orders of magnitude above all that, and rather easily implemented....

...whenever priorities allow, of course.

By Mark Evans at Wed, 2004-08-04 04:25 | login or register to post comments

Re: No rush

Your answer is too vague for anyone to help with Drupal problems.

We're not having any Drupal problems, other than the few minor limitations that have been raised in this forum.

It could be done completely outside of Drupal as an FTP drop with username/password as per LtU user accounts. In fact that is probably the best way to do it.

FTP is not enabled on the server, and there are no plans to enable it.

The semantic richness of LtU would be vastly improved by the additional (visual) mode of communication. I keep hearing how we want Q and BLOCKQUOTE to track semantic content, not just formatting. Well, visual communication is orders of magnitude above all that,

In that vein, I think something like MediaWiki's math markup might be even more useful. But you don't need to convince me that images are a good thing.

and rather easily implemented....

...whenever priorities allow, of course.

Right. The point about "easily implemented" is that there are many ways to add all sorts of features, some more easily than others, but we want them all to operate together coherently. Perhaps instead of priorities, I should have said dependencies: image upload is a little way down the critical path.

By Anton van Straaten at Wed, 2004-08-04 05:05 | login or register to post comments