Ordered list syntax.

Jelks Cabaniss jelks at jelks.nu
Mon Mar 29 03:27:22 EST 2004

John Gruber wrote:
>> A quick clarification, since I see this issue has already been
>> decided on for Markdown.
> I'm not sure which issue you're talking about, but most of the list
> stuff we're talking about here has *not* been decided. Or at least
> not by me. :^)

OK, I misunderstood.  I thought you had decided to use inline CSS and *not*
to do it in explicit markup.  

>> We weren't talking about adding <foo> elements (although that can
>> certainly be done), just adding several attributes from 1.0
>> Transitional to a slightly modified 1.0 Strict DTD.  Then not only
>> is your schema documented, your documents validatable, but browsers
>> do what's expected -- the best of all worlds. 

> I agree that a change like this to the XHTML 1.0 Strict DTD wouldn't
> be that difficult. But it simply doesn't sound very appealing to the
> typical user. 


> If I decide to support list syntax that generates HTML
> which uses attributes that are deprecated in the W3C's Strict DTDs,
> I'll just document it as such and recommend:  
> a.  If you create lists that start at ordinals other than 1, you
>     should specify a Transitional DTD in your markup.
> b.  If you want to validate using a Strict DTD, then you must
>     start your Markdown lists at the first ordinal (`1`, `a`, `A`,
>     etc.)

Yes, that would be the way to do it.  

(Except you'll have to be more restrictive in item 'b' -- you can't even use
alpha-style numbering with Strict unless you call on CSS -- you're stuck
with '1'! :)

>> I (and a number of others) don't care for emitted inline CSS (shades
>> of MS Word!:), but in our granted rather infrequent use of alternate
>> list-style numbering, there's always  fallback to embedded HTML.
> I don't understand this adamant opposition to inline CSS. For
> example, to produce an ordered list using letters, would you be
> opposed to this?
>     <ol style="list-style-type: lower-alpha">
>     <li>First</li>
>     <li>Second</li>
>     </ol>

Yes.  (Though when I say "opposed", it only means I drop to embedded HTML to
override this behavior.  I'm sure there are others who will drop to HTML if
Markdown emits the (currently) Transitional-only attributes.  Whichever way
you go, there's gonna be some grumbling.  :)
> If so, why?

For one, it breaks the pattern.  Everything content-wise can be expressed in
markup -- *except* ordered lists?  That right there reeks of a design flaw.
Also, to understand the semantics of the ordered list (and semantics are
*supposed* to be indicated through markup), you have to drop into the
`style` attribute[s] and parse it/them.

> It produces the same rendered output in a browser as this:
>     <ol type="a">
>     <li>First</li>
>     <li>Second</li>
>     </ol>
> but has the added benefit of validating under Strict DTDs. This is
> exactly how the W3C recommends doing this. 

That it validates as Strict is IMO the *only* advantage.  As you may have
seen in the thread of the W3C mailing list I posted earlier (and I've had
confirmed from other sources off list), members of the HTML Working Group
are now advocating "unrecommending" that.  (Whether that actually happens is
of course another matter, namely one of W3C bureaucracy, politics, and Tim
Berners-Lee signing off on a significant "whoops!" :).

> It's not inline CSS for the purposes of *layout* 
> or *design*.

The problem is that it's exactly that -- and worse!  It's *depending* on CSS
for number rendering!  Take the following document (DOCTYPE-less for
simplicity's sake):

    	<title>List Test</title>
      <ol type="a">
      	<li>test 1</li>
      	<li>test 2</li>

      <ol style="list-style-type: lower-alpha">
      	<li>test using CSS 1</li>
      	<li>test using CSS 2</li>

Both lists "look" identical in IE, Moz, and Opera, right?  

Now look at it in Lynx:

	a.  test 1
	b.  test 2

	1.  test using CSS 1
	2.  test using CSS 2

See the problem?  And this isn't just "a Lynx thing" -- virtually no user
agents *except* GUI browsers (in a limited visual sense) "understand" random
inline CSS.  Intended semantics are hard to retrieve out of inline styles,
especially when CSS isn't designed for such a purpose.

The designers of HTML 4.0 Strict goofed on this one, and it's still causing
all of us trouble six and a half years later.


More information about the Markdown-discuss mailing list