> It was my mistake here, not to make the meaning of word clear in the context.
> Second attempt, is this clear now? ;)
Yes.
> > I think it's more important to recognize the similarity with font attributes,
> > just like HTML does with the <span> property, and thus reduce complexity.
>
> In the case of Country (or Name) do you think that it should be implemented
> as a font attribute (or similar) or as an inset?
As a font attribute. We do not need to support proper nesting of these attributes,
beyond what is possible with this hierarchy:
1. Default hardcoded setting
2. Document setting
3. Paragraph environment setting
4. Paragraph override setting
4. Character override setting
Furthermore, we will probably allow "character styles" at some point, and if those
are allowed to be arranged in a hierarchy, I see absolutely no reason why we should
use insets for such attributes.
> Important also to this model is the possibility to have insets inside other
> insets.
Yes, for some purposes, this is important. However, I don't think this is important
for country, name, number or other of the attributes that we have discussed in
this context.
I still think the best solution is a character level properties/attribute gadget.
The reason is that we do not need proper nesting for these things. The kind of
nesting that would be nice to have, is better implemented in terms of character
styles.
I can appreciate why you ponder this issue, because it's only natural to extend
the SGML model to the LyX document structure. In HTML, such attributes are often
modelled as a tag. Consider <b> and <em>. Granted, those nest, so why shouldn't
we do the same in LyX?
However, notice that there is a second form of specifying these things in HTML:
As attributes to other tags. I consider this the "correct" modelling of the
issue. These things are attributes to other things, and they are not tags in
their own right - they are attributes on hosting environment. And those
attributes don't nest in themselves. This point is made clear by the absence
of a <lang> tag in HTML. What you do instead is to set the language as an
attribute on a container tag.
So, these things are attributes, and not tags that need to be modelled as
a nesting inset.
Now you might argue that it is possible to nest these attributes in HTML.
Yes, it is possible to use <span> and <div> to form a nesting attribute
set, because <span> and <dib> are without other effects.
However, I don't believe there is a real need for this kind of nesting.
In LyX, we should stick to the attribute part for the first round.
If you insist, we can provide a nesting inset *later* that will allow proper
nesting of these font attributes. I see no reason to introduce this complexity
at the first round - it corresponds to the situation where HTML only had
<b>-style tags for setting font attributes.
Do you see what I mean?
If you put on one pair of glasses, these things are attributes.
If you put on another pair of glasses, these things are insets.
I think we should use the glasses that give us the least trouble,
and that is without a doubt the attribute glasses.
Greets,
Asger
