- From: Ladd Van Tol <ladd@criticalpath.com>
- Date: Mon, 7 May 2007 11:30:13 -0700
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: www-style@w3.org
On May 7, 2007, at 8:13 AM, Håkon Wium Lie wrote:
> Also sprach Ladd Van Tol:
>
>> 4. Leaders
>>
>> "UAs should attempt to align leader patterns on a page." -- suggested
>> language: "User Agents should attempt to horizontally align
>> corresponding glyphs from the leader pattern between consecutive
>> lines"
>
> I agree that your text is better. For horizontal text, that is.
> Leaders can also be vertical and the GCPM text was carefully written
> to avoid "horizontal" or "vertical".
Aha, I hadn't thought of vertical text. It makes it a little more
obscure, but taking out the word "horizontally" would work, and I
think is better than the original language:
"User Agents should attempt to align corresponding glyphs from the
leader pattern between consecutive lines"
>> 5. Cross-references
>>
>> It would be helpful to provide a mechanism to treat external page
>> links differently. For many document types, it would be desirable to
>> append "(see page nn)" to only internal destination anchors
>> ("#someid"). An elegant mechanism for specifying this in CSS is not
>> immediately obvious.
>
> Right. A class name will do the trick, but it requires manual labor.
>
> A selector for internal links?
>
> a[href^="#"]::after { content: "(see page " target-counter(attr
> (href, url), page) ")" }
>
> However, it wouldn't catch links that are internal but look like they
> are external.
Cool -- I hadn't noticed the new substring matching attribute
selectors in CSS 3 -- they will probably do the trick for my intended
use case. Still, it would be nice if there were a shortcut for this
that also handled the external-appearing internal links.
>> 9.1 Hyphenate properties
>>
>> Should specify allowed format(s) for hyphenation dictionaries -- is
>> this TeX-style dictionaries? Making this UA-dependent would be bad.
>
> Ideally, there would be one common format. In this case, I don't think
> it's realistic to achieve and -- more importantly -- it's not that
> important as hyphenation is a luxury. You can, however, specify a list
> of different resources in different formats.
Since TeX dictionaries have no header, I'm concerned that UAs might
not be able to infer the hyphenation resource format in all cases. I
notice that Prince uses TeX-style dictionaries, but does not allow
for an exception table.
>> 23.2. Index
>>
>> In the example, the dfn tag should read: <dfn class="entry">
>
> In section 23.3, yes. Nice catch.
>
> Did you actually understand section 23? If so, you're among the chosen
> few. Is it useful?
I get the gist of it, and it seems that the prototype container
mechanism could be very powerful.
The spec definitely needs to be more explicit about each property.
For example, in the TOC example, is it necessary to specify
"prototype-insert-position: current"? It seems like current should be
the default, and the make-element property should cause the insertion
of the content.
One question I had was about the treatment of elements within the
prototype container that are not prototype entry elements. Are they
copied for each list item? If so, the TOC example is wrong, as it
will copy the header <h1>Table of contents</h1> in front of every toc-
entry. The same holds for the Glossary example.
A few other comments:
- The Glossary example should show the appropriate make-element syntax.
- The Index example should, I think, quote the leader pattern
- The Index example should show the prototype container
- Is the content specification in make-element the same as the
target-text value from Cross-references?
Received on Monday, 7 May 2007 18:31:09 UTC