Attribute references

[Joshua Cook]

On Mon, 10 Jan 2005 18:42:29 +0000, european bob <bob at wolfwall.com> wrote:
> On Mon, 2005-01-10 at 13:09 -0500, Joshua Cook wrote:
> First, I disagree that you can separate content from presentation, or
> that in fact you actually want to most of the time.

Sounds like you've never visted the CSS Zen Garden.  What if your
document will be displayed, unmodified, on a normal computer monitor
and a small handheld screen?  What will the handheld user see when you
document contains an image with width="480" and height="360"?  Would
it not be better to serve this user an alternate CSS file with more
reasonable dimensions for their screen?

> I don't like your CSS idea, I'm afraid. Specifying image dimensions in
> CSS is bad, for a number of reasons:
> 
>       * unless you have per-page CSS files, you bloat your site CSS with
>         information for *every* page and (in a naive implementation)
>         make id site-unique, not page unique

There's nothing wrong with per-page CSS in complex cases where content
varies greatly from page to page.  But in most cases where a page
contains many images, e.g. photo galleries, a class or two for the
image elements is most appropriate.  See _More Eric Meyer on CSS_,
Project 2 "Styling a Photo Collection" for an example.

>       * if you have control of the document, but not the CSS, you're
>         stuffed

Maybe, if there were any such case, but I cannot think of any
circumstance where you couldn't link your document to some additional
CSS, unless you're talking about an application that filters out
markup elements from user input.

>       * it requires non-CSS browsers to parse CSS (including: text
>         browsers, who are simple, and automatons such as web robots) to
>         understand the semantic of the page.

Not true.  Many text-only browsers do support some CSS, but this is
irrelevant, since they generally will not display inline images.  As
for robots, why would they need the dimensions of an image to
understand its semantics?  That's what the alt, title and longdesc
attributes are for.  The HTML spec states that the height and width
attributes are implied, meaning that it is up to the user agent to
determine their values if not supplied.

> 
> And there are other good attributes which would be of interest (rel/rev,
> for example). Limiting things to id/class isn't really even in the
> interest of maintain strict semantic virginity.
> 
> --bob.

I've yet to see anyone really making use of the potential of rel/rev attributes.

To be clear, I'm talking about limiting syntax sugar.  I do think it
should be possible to add any valid attribute to an element, but when
we are deciding which syntactical sugar to add to Markdown, I
definitely think that we should be limiting it to the most common
cases.  My point is that id and class attributes are universally
applicable to nearly every HTML element, and therefore, are good
candidates for some shorthand.  The height and width attributes are
limited to elements like object and img, and furthermore, are
deprecated in the current HTML spec, as you have pointed out in a
later message.

The "#foo" and ".bar" syntax in CSS selectors is also shorthand, by
the way.  The full syntax would be [id=foo] and [class=bar].

Joshua