After developing the attributes blocs for Stylo I came out with an implementation which follows in part the draft proposal from @mb21 and the specifications stated in my previous message (which this message replace).
All examples below, which are loosely inspired from the @mb21 draft proposal, will apply the following CSS and I show the final rendering in Stylo:
This proposal follows the draft proposal on many points but simplifies it on others and add three new capabilities:
Possibility to add attributes blocs before bloc.
Attributes aggregation of all attributes blocs pertaining to a bloc.
Inline attributes blocs are applied to the inline element defined before them, if there is no such element, they apply to the bloc in which they are defined: the enclosing bloc.
There is also some difference with my last proposal: instead of allowing attributes blocs after only for terminating blocs, I followed the simpler rule of allowing an attributes bloc one the line below any bloc, like the draft proposal is suggesting.
On the simplifications side,
no requirement for the attributes blocs to follow the bloc indentation to apply to them, unless normal parsing implies such necessity e.g. a list of paragraphs
also removed, is the necessity to have spacing (or no spacing) between the attributes blocs and the elements. The three rules below cover all cases without the need of such rules.
no line feed are allowed inside attributes blocs. This last rule could have become a problem as more attributes are added to an element, but since aggregation is supported they can just be added separately, like here:
So, here are the modified/new rules:
if an attributes bloc is one line below a non-attributes bloc, it is always assigned to this bloc (the one before). One line below in this definition, means there is no blank lines between the end of the non-attributes bloc before and the attributes bloc, otherwise we get unintuitive results with list continuation where a list is terminated by the attr-bloc a couple of lines below but is still considered on the line below because of lazy list continuation.
if an attributes block is placed before (see definition of before and after below*), it is assigned to the first non-attributes bloc element after
otherwise, it is assigned to the first element on the left on the same line, unless this element is an attributes bloc, in which case it should apply to the first bloc it is contained in.
*An attributes bloc can be defined inline e.g. inside a paragraph, or as a bloc, at the root or inside another bloc. _ Before _ or _ after _ refers to the relative position of an attributes bloc relatively to another bloc level element under the same bloc or the root. The notion is quite intuitive in fact:
Attributes bloc after:
Attributes bloc before:
To be considered a bloc, the attributes bloc must not be followed by anything else than whitespaces:
One of the goal of this way of specifying attributes is to keep the same parsing as we would have without attributes bloc handling. In this case putting the attributes bloc after the closing header sequence would result in the attributes to be applied to the whole content including the closing header sequence as it becomes part of the content because it is not closing the header content. So this would probably be unexpected:
Following these rules, we don’t care if there is spaces between the attributes bloc and the horizontal rule:
In my implementation, a line feed inside an attributes bloc invalidate it, the same as blank lines inside it:
fenced code block
As in the draft proposal, an attributes bloc can be put in place of the usual params or “info string” and become “syntactic sugar for classes”.
But attributes can be put before or after as with any other bloc element:
Replacing the params:
In the reference links case, there is no need for spaces before the attributes bloc:
In the previous example, only the first attributes are propagated since it is the active reference (because it is the first one).
For now, in Stylo, the attributes propagation to the referencing links and images is applied. I am still not sure about this feature though. For me it agravates the problem on non-locality of the information and adds the necessity to look at the reference to know the attributes applied to the link or images. It is acceptable but not an ideal situation.
As usual, attributes are supported before, inline and after:
Inline blocs, apply to the previous inline element unless, this previous inline element is itself an attributes bloc:
If the previous element is an attribute bloc then the attributes apply to the enclosing bloc:
There is no need for the attribute blocks to be indented exactly as much as the first line of the paragraph: if it is on the line below it applies to it:
No need for the attributes bloc to be indented as the block quote to apply to it, since it is on the line below at the same level, it is sufficient:
The same rules apply inside a bloc quote, :
Bloc indentation does not change anything:
But as we can see, depending on where the attributes belong they apply to different blocs (remember that red has higher priority than blue in the CSS style):
Attributes blocs that are not directly under a bloc are applied to the following one:
The same goes for lists inside another bloc, here a blockquote:
To get red color applied to the list, we need to put attributes bloc directly under it:
We can apply different attributes to the lists
Pink class attribute is put on top:
The attributes can be put before for the list too:
The spaces don’t matter: