generated from complexitycollapse/default-template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtodo.html
257 lines (152 loc) · 38.9 KB
/
todo.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
<html data-theme="dark blue"><head>
<meta charset="UTF-8">
<!-- https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<link rel="stylesheet" href="file:///./window/index.css">
<title>Commonplace Todo</title>
</head>
<body>
<div class="container">
<div class="left-pane" style="flex: 0 0 438px;">
<div class="controls">
<div class="todo-buttons">
<button id="add-todo" class="todo-button">Add Todo</button>
<button id="add-sub-todo" class="todo-button">Add Sub-Todo</button>
<button id="delete-todo" class="todo-button">Delete</button>
<button id="collapse-all" class="todo-button">Collapse All</button>
</div>
<input id="todo-filter" placeholder="Filter todos...">
</div>
<ul id="main-list" class="todo-list">
<li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Grid</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Figure out what actually needs to be supported</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Figure out how to map that to Commonplace</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Figure out where the code changes will be required</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Make the code changes</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Make a test file with these changes</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="And the asscociated test files"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Remove the old way of doing it</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes="This is the first attempt at creating apps that embed the commonplace code.
They will probably live outside the Commonplace repo"><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">First Apps</span><span class="todo-count">0/5</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="Like editor.js.
Really a small demonstration of the whole thing that can be embedded in other things."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Simple editor</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Todo app just like this! But using Xanadu features to...
Have a proper notes editor.
Link todos in multiple places
Transclude todos across multiple todo lists
Have links between todos
Virtual content (todos defined by a filter)
-------------
This may be a bit ambitious, as it requires custom editing defined by Commonplace, and lists, and templating.
However, it's a good target to aim for."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Todo</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Converts markdown to Commonplace and displays it. A nice way to create simple Commonplace pages.
Maybe could be made into a lib later, as it sounds generally useful.
------
Heading # H1
## H2
### H3
Bold **bold text**
Italic *italicized text*
Blockquote > blockquote
Ordered List 1. First item
2. Second item
3. Third item
Unordered List - First item
- Second item
- Third item
Code `code`
Horizontal Rule ---
Link [title](https://www.example.com)
Image 
"><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Markdown app</span><span class="todo-count">2/10</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="Flat files, like the current example files, may be fine.
That's no good for editing though."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Need some kind of temporary storage</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Do whatever's required to make it embeddable.</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Add it to local node_modules</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Figure out how to embed Commonplace</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Parse markdown to JSON</span><span class="todo-count">2/3</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">String encoding</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">The basic stuff</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="" data-prev="1"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Nest</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Generate commonplace files</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="#levels
"><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Add Sections and nested headings to Commonplace</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Add horizontal rules to Commonplace</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="See Zim.
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Rewrite how lists work in Commonplace</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Set up repo and project structure</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Get al list of all markdown stuff worth supporting</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes="Create a website that shows off Commonplace.
Will have something like a blog (requires templating?)
Maybe like a wiki? That would imply some kind of editor.
Should be hostable before the docuverse has been created."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Wiki/blog homepage</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="An extension of markdown that can be used to create Commonplace pages.
A lovely idea but it surely won't work with versioning. How do you make modifications that transclude the old content? Auto-diff? Too crude.
Basic transclusion itself should be supported."><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Placedown</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="The types that will be used are generally hard-coded. But what if you want to bring in your own types (e.g. your own level types)?
Should be able to define symbols for links to make this possible.
But even more interestingly - could have special link types whose purpose is to extend the placedown app. These could customise it for specific situations.
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Customising the syntax</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li></ul></li><li class="todo-item" data-notes="Could be a a type of pointer.
CSS has variables, which are useful for defining themes. That's a good inspiration.
Can variables be dynamically changed? That would certainly be a powerful feature.
Variables could also be placed in the UI to give the page more interactivity.
CSS allows you to define sets of values of variables (themes) and which one is used depends on an attribute of your choice. Thus semantic attributes are bound to presentation."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Variables</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Required Changes</span><span class="todo-count">0/4</span></div><ul class="todo-list nested-list"><li class="todo-item" data-notes="See Zim for how lists should work"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Lists</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="SECTIONS HAVE NOW BEEN RENAMED TO LEVELS! This is a more neutral term.
Need sections as it's the best way to make heading levels work. Headings should be associated with sections.
Also need to resolve the problem of different heading styles at different nesting levels. Could use a trick similar to CSS s > s > s > h to target a heading in a nested section. Or could use different section types and have associated headings styles.
More generally, nested sections need to be formatted differently. It makes sense for markup rules to be scoped to sections. However, you don't want to repeat the markup rules in every section, so nested Edls are not the solution (that's for solving the repeated content problem). Instead, markup rules should be scoped somehow. This scoping should work with nesting of sections. Should it be possible to nest in other things too?
The concept required here is that of a "level", with some rule determining how levels are calculated. Then every markup rule can be scoped to that level. The key is NOT to hard-code levels, and even better to make them semantic.
DAISY has non-semantic levels 1-6. You mark the level of each part of the text by tagging it, and also use a class to say what kind of level it is (e.g. "chapter"). There is no restriction on what the classes are.
So... scope should refer to some semantic class (anything "within" that class as defined by the normal inheritance rules is in that scope). Markup rules use the most specific class available (i.e. the closest nesting). Not everything is hierarchical though and some things may overlap rather than be nested in others. In that case use the normal markup conflict resolution rules (i.e. link priority).
What if there's no semantic meaning by which levels can be distinguished, so they are all just "sections". Then a depth parameter can be supplied."><div class="todo-headline"><button class="collapse-button">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Levels</span><span class="todo-count">0/2</span></div><ul class="todo-list nested-list"><li class="todo-item" data-notes="A "level" is any layer of structure in a document. Every Edl type, for example, defines a level. So does every sequence type. Levels are also defined by classes as opposed to types.
Markup rules may be scoped to levels by adding a "level" end, which points to a class. Such a rule only applies to an object if it is NESTED within that level. Lower level scopes (i.e. closest nesting to the desired element) have preference over higher level scopes. Note that the object defining the level itself is outside of the scope. Only the contents are part of the scope.
Sometimes scopes of the same kind can be nested within each other. In that case as well as the level, a depth end can be specified, indicating the level of nesting to which the rule applies. Note that depth is relative to the POSITION OF THE MARKUP LINK! Effectively, the markup link is unaware of levels in parent edls. This makes edls nestable without modification.
Oops... I implemented this the wrong way around! I did it counting up from the bottom, not counting down from the top!
In general, markup links do not consider scopes higher than themselves. So what is true for depth is true for all scope. This is necessary so that embedding doesn't break everything.
Note that levels are transitive. A rule scoped to a level applies in all contained levels, although it may be overwritten by markup at a more specific level.
Levels aren't always well-nested. For example, pages are a kind of level that often doesn't nest with sections. In this case the scope matches if it matches the intersection of all criteria, and the distance is therefore the minimum distance of all of the criteria considered separately.
A rule can name multiple levels, in which case all must apply (this is useful for when there are multiple hierarchies)."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Levels Proposal</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item selected" data-notes="Currently a level can be scoped to a class. Should it also be scopable to a named target? This would allow a particular edl to be the scope. That's not super-useful. What about targeting a particular sequence? More useful, altough sequences can have many instances in the same document (not an issue).
So yes, an interesting idea."><div class="todo-headline"><button class="collapse-button invisible">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Targeted levels</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list"></ul></li></ul></li><li class="todo-item" data-notes="Some information always needs to be downloaded when interpreting a link. Currently, we use the type of the pointer (it will have the specifiesContent property) to determine what needs to be resolved. This is just a hack though.
Better would be to have the link type describe what needs to be downloaded, or have this inferred somehow. For example, Commonplace understands markup links, therefore it knows what it needs to download to interpret them.
Do as part of #InterpreterRefactor"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Content Specifying Pointers</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Currently if a markup rule targets an object directly, the rule always applies. Is that right? If you specify other criteria such as class, then shouldn't it only apply if it meets those criteria too?
The opposing argument is that you want a single rule to target something PLUS some specific object. But that's mere convenience, while the other option allows interesting functionality (such as when a class may be added/removed by user actions).
Worth looking at CSS modules and other advanced CSS solutions to see the kind of thing they support when an ID is targeted."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Markup Rules for Targeted Objects</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Instead, there needs to be a formal system for requesting additional content required for interpreting the document.
Also, there are cases (see clipTypes var in document-model-link) where we treat the contents of an end as a list. This is nonsense. If a list can be specified then multiple ends should be used, rather than multiple pointers in a single end."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Remove getContent</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Design</span><span class="todo-count">0/2</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="Collapsable sections. Expanding spider diagrams etc.
It's clearly something very useful, but how does it work?
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Changing the visibility of things</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="The current way of doing things is a simplification. It needs to be changed.
Link types need to describe: type name, description, documentation, the structure of the link, associated semantic classes, whether the link defines a sequence or other structural element, content specifying ends.
Name and description are simple.
The structure should define the valid ends and the kinds of things they can point to. That's quite tricky due to ordering, so maybe a string written in some language is necessary. Otherwise, a whole warren of nested links is required, which I don't fancy. However, it would have interesting consequences.
Need to indicate which end denotes the class, which ends are content specifying (i.e. required) (or is that inferred?), which ends denote sequences.
Also, whether an end is an endset or an endlist.
"><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Link Metalanguage</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="An "end" link describes an end. It specifies:
- name
- set or list
- classes endowed
- sequences endowed
- something about the kind of thing pointed to (link, text, edl, image etc. so pointer types?)
- if it points to text, the "type" that the text should parse to (string, integer, fixed options etc.)
Is this overcomplicated? How will this information even be used? Well, endlist/endset is relevant for determining if the correct thing is pointed to, otherwise the link will not be placed on the content. Class and sequence endowment are required. The typing stuff may be better handled by defining the attributes, then they can check whether the link is valid and otherwise ignore the values.
A "record" link defines a repeating sequence of ends. So it just has pointers to the ends. I suppose records can be nested although that's perhaps not necessary for now.
What's the value of this? Can't we just interpret the links in code as required? Yes.
So the rest of this isn't required. The link type can just have a list of ends. (one end per end)
Need to specify if the type is valid on a link or edl? Again, it just won't work if you put it in the wrong place. However, need to define what happens when the type is used for an Edl (for example, does the Edl get the class?) This will probably be very similar to an end definition."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">End Description language</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Currently the class type is identical with the link type that defines it. This isn't appropriate because link types may need to evolve over time as new kinds of metalink possibilities are created. Also, there may be more than one way to endow a class, or a link may want to endow multiple classes.
So a class should itself be a link. It needs a name, description and documentation link. It probably needs nothing else.
There should be links that define hierarchical relationships between classes (i.e. the Venn diagram of classes). These don't need to be part of the type, but can be imported as separate links as necessary. The creator therefore gets to create the hierarchy they need.
"><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Classes</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="Currently there is a "defines semantic class" type that is used to indicate that a link places a class on some target. But there isn't a "has class" link that indicates a link itself has a class. Is this required?
Yes. Example: paragraph links should all be part of the paragraph class. You don't want to put a "has paragraph class" link on every paragraph link! "defines semantic class" is only good for putting arbitrary classes on things (such as marking text as emphasised). It doesn't allow them to be systematic.
#hasClass"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Having vs. endowing classes</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li></ul></li><li class="todo-item" data-notes="Think of Commonplace as structured like this:
There is the data model, currently defined in core. This defines what a Commonplace document is. Things like the PartRespository etc. don't need to be here.
Then there is the interpreter. This is currently in document-model. This is a very important, independent component that can generate information about Commonplace documents. The box model should be seen as part of this (rather than a separate step in the pipeline) and perhaps should be renamed to the structure, or visual tree, or something similar (it isn't the entire structure because there are potentially multiple hierarchies in a document. In fact perhaps the data model should have a "structures" property). The document model should be presented in multiple ways, such as in the document model browser.
Then there's the storage system. This handles all database, networking and fetching parts (although the interpreter determines what needs to be fetched. In fact that could be a property of the model).
Then there's the UI. This renders the document in various ways, including rendering the document model.
------
As a matter of principle, the storage system should be independent of the kind of data being stored, and the interpreter should be independent of the UI and storage system. That's probably possible for the networking aspects, but not the database aspects, which will need to understand the data format.
Not yet understood: what understands the complex processes behind editing and publishing?"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">New Structure</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Things to Eventually Do</span><span class="todo-count">0/1</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">EPUB converter</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="DTB = digital talking book.
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">DAISY DTB converter</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Open questions</span><span class="todo-count">0/2</span></div><ul class="todo-list nested-list"><li class="todo-item" data-notes="Currently a markup rule can target a type or a class. But perhaps only classes should be targetable?
Why?
Firstly, it's simpler.
Secondly, types should be considered ephemeral. New types are created all the time, possibly to mark only small distinctions from previous types (such as adding new features or updating the documentation to a new link). What matters is what the link metalanguage says about the type. So if the metalanguage says that a type endows a class, that's something substantial.
But aren't types like HTML tags and classes like CSS classes? Well.. exactly! Nobody uses anything except DIV these days. Yes, there are all kinds of semantic tags like section and emphasis, but why can't they be classes? Aren't classes also semantic?
This would also resolve an issue with levels. What exactly does a level denote? Is it something with a particular type or with a particular class? Classes are surely the right thing. Thus something can be classes as a section, and then you scope to that.
DAISY distinguishes classes from elements, but the elements are very vague. Nevertheless, they are semantic too, so DAISY has a distinction between tags and classes, with the classes refining the tags. So that seems a little duplicative. I think it has the distinction because the tags define the STRUCTURE of the document and the classes then add additional semantic information to structural elements. This might be captured in Cpla by the fact that types define other things than classes, such as sequences, and possibly even restrictions on what an end can point to."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Should markup rules target types?</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="Suppose something is contained in a sequence. Should there be links scoped to the SEQUENCE? Content markup on the sequence is already scoped to the sequence, but what about other things?
Could use an "inject" link to inject a bunch of links into an Edl or a sequence (or group more generally). These links are then scoped to the target. This allows the markup content idea to be generalised to all kinds of other things.
Yes, I like this idea."><div class="todo-headline"><button class="collapse-button invisible">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Radical new scoping idea</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">TODO</span><span class="todo-count">0/3</span></div><ul class="todo-list nested-list"><li class="todo-item" data-notes=""has class" is a metalink type. If it is added to a type then all instances of that type have the class.
"has class" is distinct from the existing "defines semantic class" metalink type, which is used to say that a link ENDOWS the class on something else, rather than having it itself. See the #hasClass tag for discussion.
Implementation notes:
Can this be achieved just by modifying the getClasses and hasClass functions? Is it worth elevating those to some kind of decorator that gives those methods to each kind of object?
Once does, go back and add this to well-known objects.
#hasClass
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Has Class</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="See Levels Proposal"><div class="todo-headline"><button class="collapse-button">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Markup Levels</span><span class="todo-count">5/6</span></div><ul class="todo-list nested-list"><li class="todo-item" data-notes="Depth shouldn't be counted by counting up from the bottom, but by counting down from wherever the rule resides.
Also, don't count levels that are higher than the link itself. What does "higher" mean? It means outside the Edl where it is defined, but in future the links may also be scoped to a group or sequence."><div class="todo-headline"><button class="collapse-button invisible">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Reverse the way depth is counted.</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list"></ul></li><li class="todo-item" data-notes="A scoped markup rule in a child Edl shouldn't consider scopes in any parent Edl, only scopes up to and including the Edl it is defined in. This is so that nesting edls inside others doesn't break the markup rules."><div class="todo-headline"><button class="collapse-button invisible">-</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Limit scoped rules so that they don't count scopes outside their container</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list"></ul></li><li class="todo-item completed" data-notes="" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Check levels against classes</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="Default depth is 1." data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Handle depths</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="When there are multiple hierarches and multiple level scopes specified, what should happen? Does each level scope refer to a different hierarchy? (Yes)" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Multiple hierarchies</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="Closer levels (i.e. lower in the hierarchy) have preference over other levels.
But how does the level scope interact with the other rules, such as class? Answer: scope is of lower priority than specificity. So use scope as a tie-break when the specificities are the same.
" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Priority</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="to level.class
" data-prev="1"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Rename level.level accessor</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li><li class="todo-item" data-notes=""><div class="todo-headline"><button class="collapse-button">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Containers</span><span class="todo-count">1/2</span></div><ul class="todo-list nested-list collapsed"><li class="todo-item" data-notes="Currently the containers for an object are its parent edl and any sequences it is part of.
To support the new lists proposal, this isn't enough. There also needs to be non-sequence containers. Note that containers can't just be "any incoming links" as broken sequences don't count as a container.
Either add a new metalink to indicate that a link can contain things (through the specified ends) or have links in general work as containers, but draw a distinction between incoming links that are operable and those that aren't. (I think I prefer the first)
Previously, other kinds of containers were called "groups". Is that a good name?
"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Non-Sequence Containers</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item" data-notes="It should be possible to find all hierarchies in a document, with the document model having a "hierarchies" or "structure" property listing them all.
But what is a hierarchy/structure? Is it any group/container of any kind? Is it any ROOT of a hierarchy of containers (i.e. a container that's not in another container?)
I think it's probably best to indicate that something is a structure of the document. There could even be a "document" link that contains all the relevant structures the document contains.
The edl hierarchy does not count as such a structure by default, but may form a structure if required (e.g. if there are chapter edls)."><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Get all document hierarchies</span><span class="todo-count invisible"></span></div><ul class="todo-list nested-list collapsed"></ul></li><li class="todo-item completed" data-notes="" data-prev="0"><div class="todo-headline"><button class="collapse-button invisible">+</button><input type="checkbox" class="todo-checkbox"><span class="todo-text">Add getContainers to each object</span><span class="todo-count invisible">0/0</span></div><ul class="todo-list nested-list collapsed"></ul></li></ul></li></ul></li></ul>
</div>
<div class="divider"></div>
<div class="right-pane">
<input id="todo-title" placeholder="Edit a todo here...">
<textarea id="notes" placeholder="Select a todo to view or edit its notes..."></textarea>
</div>
</div>
<script type="module" src="file:///./window/window.js"></script>
</body></html>