sydb
commented
1 year ago Extraordinarily successful Stylesheets Group meeting of 2023-03-02 made excellent progress in branch stylesheets_group_on_592.
Closed sydb closed 8 months ago
sydb
commented
1 year ago Extraordinarily successful Stylesheets Group meeting of 2023-03-02 made excellent progress in branch stylesheets_group_on_592.
joeytakeda
commented
1 year ago In experimenting with getting the CSS for this working, I've added another commit https://github.com/TEIC/Stylesheets/commit/ee3397283496897cf02b64d4ce454f36cb4acb68 that does two things:
common/tag_docs.xsl producing a list that looked like this (indentation added for legibility):<li class="attRefItem">
<a class="link_odd" title="provides attributes that can be
used to classify or subclassify elements
in any way." href="ref-att.typed.html">att.typed</a>
<ul>
<li>
<span class="unusedattribute">type</span>
</li>
</ul>
<ul>
<li>@subtype</li>
</ul>
</li>Two things were wrong here: the first error was that where were two <ul>s with 1 <li> each rather than 1 <ul> with two <li>s; the second error (which I'd argue was a bug that preceded this work) was that the @subtype attribute was not processed like the rest of the attributes (no <span class="attribute"> surrounding it). So my changes fix so that the output list item for an attribute class with an overridden member looks like so (indentation added for legibility):
<li class="attRefItem">
<a class="link_odd"
title="provides attributes that can be used to classify
or subclassify elements in any way."
href="ref-att.typed.html">att.typed</a>
<ul class="classSpecAttDefs">
<li>
<span class="unusedattribute">type</span>
</li>
<li>
<span class="attribute">@subtype</span>
</li>
</ul>
</li>odds/guidelines.xsl defines that the XHTML output should be indented, which introduces additional whitespace (new lines, tabs) in the new attList <ul>, which end up becoming normalized into a single space when the <ul> is made into an inline element and introduces unwanted whitespace in the browser. E.g. this indented list<ul>
<li>Foo</li>
<li>Bar<ul>
<li>Baz</li>
</ul></li>
</ul>is interpreted as:
<ul> <li>Foo</li> <li>Bar<ul> <li>Baz</li> </ul> </li> </ul>When you then try to use a pseudo-element on the <ul>, the whitespace that precedes the first <li> remains:
ul:before{
content: "(";
display:inline;
}
ul:after{
content: ")";
display:inline;<ul> <li>Foo</li> <li>Bar<ul> <li>Baz</li> </ul> </li> </ul>
<!-- ( Foo Bar( Baz ) ) -->I mentioned this to @sydb who made the good point that, while the additional space
may be aesthetically OK (and in fact aligns with what he proposed in the OP), the space can't work since "the browser will think it is OK to split a line either immediately after an open paren or immediately before a close paren." Suppressing_ indentation for all ul and li elements fixes that, such that spacing could then be added for inline views in CSS directly
ul:before{
content: " (";
display:inline;
}
li + li:before{
content: " ";
}
ul:after{
content: ") ";
display:inline;<ul><li>Foo</li><li>Bar</li><li>Baz</li></ul></li></ul>
<!--(Foo Bar (Baz))-->The tl;dr — and fun consequence — of the very long comment above is that I've made a Codepen that shows:
a) The different views (per @sydb 's initial suggestions), which you can select using the tools at the top b) The ways that indentation of the list affect said views
There's a lot of stuff there (for debugging purposes mostly), but the most interesting things to look at are the bottom two (titlePage and moduleSpec examples) — titlePage has an overridden attribute; moduleSpec has three levels of attribute class nesting (thanks @sydb for finding that!).
ebeshero
commented
1 year ago @joeytakeda Thanks for the Codepen--that made it a lot easier to review! Some thoughts:
I'm finding myself liking the Vertical Compressed version. I think by comparison with the non-compressed lists, it requires less scrolling on a page for the reader to absorb the information, and it works well with the sub-nested portions.
The numbered lists are also informative of how many attributes are available. (But is that information useful to our readers? Somehow the numbers seem a little distracting.)
lb42
commented
1 year ago Fwiw i really dont like the numbers. They suggest the attributes are ordered, which they arent
joeytakeda
commented
1 year ago Thanks @ebeshero & @lb42 — in my haste, I forgot to note that those numbered lists were really just for debugging purposes (I added numbers to confirm that the lists were nested properly); I've now made that a bit clearer in the codepen demo.
sydb
commented
1 year ago Whoo-hoo! By George, I think we (may have) done it. Wow. Nicely done, @joeytakeda!
@ebeshero — Current recommendation is to replace “current” with “proposed” as soon as it is thoroughly tested (hopefully well before next release), and then think through how should this be presented, and how to give user a choice, etc. For that stage, I am kinda with you, Vertical Compressed looks quite good. (That said, there is still an argument for adding more info in one or more views.)
joeytakeda
commented
10 months ago Per F2F Sept. 3: Council decides to do vertical compressed only and this should be implemented in CSS. Moving this to GO for me to implement.
joeytakeda
commented
9 months ago I have now updated the CSS (for HTML renderings of ODDs generally) for the vertical, compressed attList. And since we want this change to be included in the Guidelines, I have issued another ticket (https://github.com/TEIC/TEI/issues/2489) to make the equivalent CSS change there too.
Here's what it looks like so far:
The attribute lists generated by these Stylesheets are confusing. Even if we keep the current formatting, the punctuation is wrong. But I think we can do better on the formatting. @raffazizzi points out that MEI does a better job. (I think he is right.)
Note that the examples below do not wrap, so you may want to copy them and paste them somewhere else for viewing.
current
same, without that funny line break
same, with corrected (IMHO) punctuation
hierarchical, vertical, arrangement
compressed hierarchical, vertical, arrangement
I like MEI’s multiple-views approach. In particular I like the idea of presenting the compressed vertical, hierarchical list allowing the user to “expand” it to the vertical, hierarchical arrangement (with added info). That said, we should at least correct the punctuation.