Am Freitag, 22. November 2013 21:54:13 UTC+1 schrieb Jeremy Ruston:
>
> As things stand it wouldn't be possible for a bit of wikitext syntax to
> modify the attributes of parent nodes in the widget render tree.
>
I didn't mean the parent of the @@, but wait…
> 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.
> 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.
> As you note, this still means that we need a decent syntax for applying a
> class to the OL or UL of a list. I'd wondered using double dots, for
> example:
>
> *..myListClass
> * ListItem 1
> *.myListItemClass ListItem 2
>
I like the idea, but what if someone comes up with:
*..myListClass
* ListItem 1
*.myListItemClass Listitem 2
*..myOtherListClass ListItem 3
So what if someone types the .. inside a list?
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:
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 @@
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.
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 ;)
--
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 tiddlywikidev+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywikidev@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/groups/opt_out.
