> It sounds like the best solution for your immediate problem would be a
>> simpler syntax for:
>>
>> <div class="english">
>> some english
>>
>> another para
>> </div>
>>
>
> Sure, but as I already said in another situation: I don't want HTML here.
> For myself it's fine, but I want (have to) give it to others later.
>
That's what I was driving at: evolving a *simpler syntax* for the HTML
shown.
> So, I'm thinking that it would make sense to modify the @@ syntax so that
>> it generates a div or span to carry the specified class.
>>
> That's what I meant for the @@@: Generate a surrounding <div> if there is
> not a single element inside the @@@-block.
>
OK. I took you to mean walking back up to the existing parent.
> *..myListClass
> * ListItem 1
> *.myListItemClass Listitem 2
> *..myOtherListClass ListItem 3
>
> So what if someone types the .. inside a list?
>
I think ideally in that situation we wouldn't recognise the class assignment
>
> What do you think?
>
>
> Question is: Do you want to keep the @@? I think we have 2 situations for
> something which is inside such a block:
>
Sorry I wasn't clear: I'm proposing changing the behaviour of @@ to always
generate a wrapper element. As I said, the present behaviour of @@ is
broken in too many circumstances.
>
> 1. It generates one HTML element
> 2. It generates more than one element
>
> In case 1 there is no problem. Simply apply the class to the one element.
>
> In case 2 stick to what we have: Apply the class to each top element
> generated.
>
> But what now with @@@?
>
> In case 1 it could either apply to the one element, which would make @@@
> in this case be identical to @@
>
Erm, no. Surely the distinction is that @@@ always generates an element,
while @@ does not?
> In case 2 it should create a div around the elements applying the class to
> that div. So @@@ would generate exactly what you proposed to me as a
> workaround.
>
Yes, that's what why I was proposing this behaviour. I think there's a few
misunderstandings in this thread!
> So let's look at examples:
>
> Case 1
> @@.CL
> # A
> # B
> # C
> @@
>
> Case 2
> @@@.CL
> # A
> # B
> # C
> @@@
>
> Case 3
> @@.CL
> A
>
> B
>
> C
> @@
>
> Case 4
> @@@.CL
> A
>
> B
>
> C
> @@@
>
> The generated HTML would be
> Case 1 and 2
> <ol class="CL">
> <li>A</li>
> <li>B</li>
> <li>C</li>
> </ol>
>
> Case 3
> <p class="CL">A</p>
> <p class="CL">B</p>
> <p class="CL">C</p>
>
> Case 4
> <div class="CL">
> <p>A</p>
> <p>B</p>
> <p>C</p>
> </div>
>
> For consistency case 2 could alternatively generate
> <div class="CL">
> <ol>
> <li>A</li>
> <li>B</li>
> <li>C</li>
> </ol>
> </div>
>
> I think I even like the alternative better, because it's really more
> consistent.
>
> What we loose is the ability to apply classes to each list element. But as
> it would always be the same class, I don't think it's too useful anyway.
> After all I think it's not a huge difference writing
>
> ol.CL > li { … }
> ul.CL > li { … }
>
> instead of
> ol > li.CL { … }
> ul > li.CL { … }
>
> The only case where you need a bit more to write is, when you currently
> have
>
> li.CL { … }
>
> you would need to write
>
> ol.CL > li, ul.CL > li { … }
>
> But regarding the HTML source generated, we would save some bytes. Imagine
> a list of 20 items all having class="myFantasticClass". That's 480 bytes
> now and 24 bytes when we change ;)
>
I'm now extremely confused, I'm afraid. The proposal that I am making is
that we change the behaviour of @@ so that it always generates either a DIV
or SPAN to carry the class. We would no longer support the old behaviour of
@@ applying it's classes to whatever elements it contains. There would be
no @@@ under my proposal. I'm separately proposing a new syntax for
applying a class to a list. I don't think that anything we've discussed
affects the existing syntax for applying classes to LI elements.
Best wishes
Jeremy.
>
--
Jeremy Ruston
mailto:[email protected]
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/groups/opt_out.
