I've committed the Poem extension to SVN and activated it on Wikisource. Pretty straightforward, works like this:
<poem> bla bla bla bla
bla bla </poem>
The inside text is wikitext, but line breaks and initial spaces are preserved. Output is wrapped in a <div class="poem">, so you can do global styling of poems per-wiki.
Additionallly you can add other allowed HTML attributes on the <poem> tag just as you would for a <div> or <pre>, such as setting one-off custom styles or additional CSS class names.
-- brion vibber (brion @ pobox.com)
On 23/06/06, Stan Shebs shebs@apple.com wrote:
All it's lacking is a title! I propose "Brion's Poem". It should get a reading at the next Wikimania too.
That one shouldn't. http://de.wikisource.org/wiki/Benutzer:Brion_VIBBER should, though. :)
Rob Church
Rob Church wrote:
On 23/06/06, Stan Shebs shebs@apple.com wrote:
All it's lacking is a title! I propose "Brion's Poem". It should get a reading at the next Wikimania too.
That one shouldn't. http://de.wikisource.org/wiki/Benutzer:Brion_VIBBER should, though. :)
That one's just doggerel though - doesn't have nearly the sophisticated but spare rhythms of his later work.
Stan
Stan Shebs wrote:
Rob Church wrote:
On 23/06/06, Stan Shebs shebs@apple.com wrote:
All it's lacking is a title! I propose "Brion's Poem". It should get a reading at the next Wikimania too.
That one shouldn't. http://de.wikisource.org/wiki/Benutzer:Brion_VIBBER should, though. :)
That one's just doggerel though - doesn't have nearly the sophisticated but spare rhythms of his later work.
One could only dream how far Mehitabel's friend Archy could have competed if only he had had a modern keyboard available instead of a mechanical typewriter. :-)
Ec
On 6/24/06, Brion Vibber brion@pobox.com wrote:
The inside text is wikitext, but line breaks and initial spaces are preserved. Output is wrapped in a <div class="poem">, so you can do global styling of poems per-wiki.
Additionallly you can add other allowed HTML attributes on the <poem> tag just as you would for a <div> or <pre>, such as setting one-off custom styles or additional CSS class names.
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Steve
Steve Bennett wrote:
On 6/24/06, Brion Vibber brion@pobox.com wrote:
The inside text is wikitext, but line breaks and initial spaces are preserved. Output is wrapped in a <div class="poem">, so you can do global styling of poems per-wiki.
Additionallly you can add other allowed HTML attributes on the <poem> tag just as you would for a <div> or <pre>, such as setting one-off custom styles or additional CSS class names.
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
On Sat, Jun 24, 2006 at 11:16:11AM +0100, Timwi wrote:
Steve Bennett wrote:
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
Moin,
On Saturday 24 June 2006 13:33, Chad Perrin wrote:
On Sat, Jun 24, 2006 at 11:16:11AM +0100, Timwi wrote:
Steve Bennett wrote:
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
Maybe the name of the tag (<poem>) is a big hint. You don't mark bold text with <i style="font-weight: bold; font-style: normal;">bold</i>, right? :)
best wishes,
tels
On Sat, Jun 24, 2006 at 02:10:12PM +0200, Tels wrote:
Moin,
On Saturday 24 June 2006 13:33, Chad Perrin wrote:
On Sat, Jun 24, 2006 at 11:16:11AM +0100, Timwi wrote:
Steve Bennett wrote:
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
Maybe the name of the tag (<poem>) is a big hint. You don't mark bold text with <i style="font-weight: bold; font-style: normal;">bold</i>, right? :)
Considering that the reason this question came up was someone else's question about whether it should be renamed to something other than "poem", I don't think that statement was very helpful. Thanks for playing, though. You'll get a consolation prize at the door.
Moin,
On Saturday 24 June 2006 14:14, Chad Perrin wrote:
On Sat, Jun 24, 2006 at 02:10:12PM +0200, Tels wrote:
Moin,
On Saturday 24 June 2006 13:33, Chad Perrin wrote:
On Sat, Jun 24, 2006 at 11:16:11AM +0100, Timwi wrote:
Steve Bennett wrote:
Silly question, but is this really only useful for poems? Would it not be useful at en.wp for other stuff too? I'll have to have a play and see what else it could be good for...
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
Maybe the name of the tag (<poem>) is a big hint. You don't mark bold text with <i style="font-weight: bold; font-style: normal;">bold</i>, right? :)
Considering that the reason this question came up was someone else's question about whether it should be renamed to something other than "poem",
I didn't see that question. And even if it would be renamed, then we would now miss a way to tag poems as poems, and not as "something usefull including poems, cook recipes and whatever". :)
So, Use <poem> for poems, and invent something else for, well, something else :-D
Hm, of couse you could do:
<somethingusefull type="poem"> </somethingusefull>
But I don't think this is better as the much shorter <poem> tag.
Best wishes,
Tels
On 6/24/06, Tels nospam-abuse@bloodgate.com wrote:
I didn't see that question. And even if it would be renamed, then we would now miss a way to tag poems as poems, and not as "something usefull including poems, cook recipes and whatever". :)
So, Use <poem> for poems, and invent something else for, well, something else :-D
Some more background on this <poem> tag would help. Are there any other instances where we have purely semantic tags?
Steve
"Steve Bennett" wrote:
On 6/24/06, Tels wrote:
I didn't see that question. And even if it would be renamed, then we would now miss a way to tag poems as poems, and not as "something usefull including poems, cook recipes and whatever". :)
So, Use <poem> for poems, and invent something else for, well, something else :-D
Some more background on this <poem> tag would help. Are there any other instances where we have purely semantic tags?
Steve
We have <nowiki> which not only blocks wiki-text but also HTML....
Steve Bennett wrote:
On 6/24/06, Tels nospam-abuse@bloodgate.com wrote:
I didn't see that question. And even if it would be renamed, then we would now miss a way to tag poems as poems, and not as "something usefull including poems, cook recipes and whatever". :)
So, Use <poem> for poems, and invent something else for, well, something else :-D
Some more background on this <poem> tag would help. Are there any other instances where we have purely semantic tags?
You seem to be implying that you think we should only introduce purely semantic tags if we already have other semantic tags. You therefore seem to be of the opinion that unsemantic tags are favourable in a context where most mark-up is already unsemantic. But if this was the case, then surely HTML would not have introduced things like <em> and <strong> and deprecated things like <font>, and instead have introduced things like <marquee> or <blink>.
So, the reason <poem> was made a semantic tag is because semantic tags are good, independently of whether we already have semantic tags or not.
Imagine we use the same tag for poems and for cooking recipes. Some time in the future we decide we actually want the mark-up to behave slightly (or even completely) differently for recipes. This is why we need separate mark-up for separate purposes.
And yes, I know that ideally this reasoning also calls for separate mark-ups that are currently all handled with '' (emphasis, maths variables, song/film titles, etc.). Obviously in this situation it is futile to hope for the ideal. Doesn't mean we have to create the same suboptimal situation in something as rarely-used as poems, though.
Timwi
On 6/24/06, Timwi timwi@gmx.net wrote:
You seem to be implying that you think we should only introduce purely semantic tags if we already have other semantic tags. You therefore seem to be of the opinion that unsemantic tags are favourable in a context where most mark-up is already unsemantic. But if this was the case, then surely HTML would not have introduced things like <em> and <strong> and deprecated things like <font>, and instead have introduced things like <marquee> or <blink>.
So, the reason <poem> was made a semantic tag is because semantic tags are good, independently of whether we already have semantic tags or not.
Ok, ok, slow down :) I haven't formed an opinion on semantic tags, I'm just curious whether this reflects a long term direction for MediaWiki, whether there will be others, and so forth.
I suppose I was also thinking that if the only special formatting provided by <poem> is that leading spaces are significant, then maybe it would be attractive to just define <leadingspacesaresignificant> (for example), then use templates, like {{poemstart}}/{{poemend}} for the appropriate semantic markup. Is there a particular advantage in having semantic markup at the wiki syntax level, rather than at the template level?
Imagine we use the same tag for poems and for cooking recipes. Some time in the future we decide we actually want the mark-up to behave slightly (or even completely) differently for recipes. This is why we need separate mark-up for separate purposes.
I would certainly recommend using {{poem}} and {{recipe}} or something in that case. Then you could simply change the template when they split.
And yes, I know that ideally this reasoning also calls for separate mark-ups that are currently all handled with '' (emphasis, maths variables, song/film titles, etc.). Obviously in this situation it is futile to hope for the ideal. Doesn't mean we have to create the same suboptimal situation in something as rarely-used as poems, though.
I agree with your general argument that "just because X is bad, doesn't mean Y has to be bad too". And I certainly have no objection to this new tag, I'm just interested in its implications.
Steve
"Steve Bennett" wrote:
Imagine we use the same tag for poems and for cooking recipes. Some time in the future we decide we actually want the mark-up to behave slightly (or even completely) differently for recipes. This is why we need separate mark-up for separate purposes.
I would certainly recommend using {{poem}} and {{recipe}} or something in that case. Then you could simply change the template when they split.
The parser may decide to close <poem> on the end of the template, so you can't do it...
Steve Bennett wrote:
On 6/24/06, Tels nospam-abuse@bloodgate.com wrote:
I didn't see that question. And even if it would be renamed, then we would now miss a way to tag poems as poems, and not as "something usefull including poems, cook recipes and whatever". :)
So, Use <poem> for poems, and invent something else for, well, something else :-D
Some more background on this <poem> tag would help. Are there any other instances where we have purely semantic tags?
Steve
<math>, assuming you already know how to read LaTeX.
-- Neil
Steve Bennett wrote:
Some more background on this <poem> tag would help. Are there any other instances where we have purely semantic tags?
At least we have semantic templates, for instance [[Category:Quotation templates]]. Community should be strong and intelligent enough to enforce use of <poem> for poems only. But my experience tells me that you can only enforce use of semantic markup if you can also recognice differences in layout. Two different tags or templates that are rendered the same will *always* be mixed up.
Greetings, Jakob
On Sat, Jun 24, 2006 at 05:33:41AM -0600, Chad Perrin wrote:
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
[ looks a second time ]
That's *you* asking that, Chaper?
Semantic markeup, of course.
What's needlessly complex is deciding that such a new tthing which isn't a poem but might look the same now should then look different...
after 10,000 non-poem things have been tagged <poem>.
Cheers, -- jra
On Sat, Jun 24, 2006 at 02:53:09PM -0400, Jay R. Ashworth wrote:
On Sat, Jun 24, 2006 at 05:33:41AM -0600, Chad Perrin wrote:
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
Why? That seems needlessly complex. If one has need for the same functionality for multiple purposes, it doesn't strike me as a net win to have eight different syntaxes to do the same thing. Is there some specific reason that it should be divided by intent rather than purpose, thusly?
[ looks a second time ]
That's *you* asking that, Chaper?
Semantic markeup, of course.
What's needlessly complex is deciding that such a new tthing which isn't a poem but might look the same now should then look different...
after 10,000 non-poem things have been tagged <poem>.
There's a difference between semantics (justified, preformatted, list) and content (poem, TV script, needed groceries). So, yeah, it's me asking that.
On Sat, Jun 24, 2006 at 05:34:51PM -0600, Chad Perrin wrote:
There's a difference between semantics (justified, preformatted, list) and content (poem, TV script, needed groceries). So, yeah, it's me asking that.
You're correct, there's a difference.
But, as far as I can see, those first ones are rather specifically not semantics; they're *syntax*. Looks, not meaning.
Which was sort of my point, as well, I believe, as that of Timwi.
Cheers, -- jra
On Sat, Jun 24, 2006 at 11:57:09PM -0400, Jay R. Ashworth wrote:
On Sat, Jun 24, 2006 at 05:34:51PM -0600, Chad Perrin wrote:
There's a difference between semantics (justified, preformatted, list) and content (poem, TV script, needed groceries). So, yeah, it's me asking that.
You're correct, there's a difference.
But, as far as I can see, those first ones are rather specifically not semantics; they're *syntax*. Looks, not meaning.
Which was sort of my point, as well, I believe, as that of Timwi.
In retrospect, the argument about what constitutes "semantic" tags could go either way. I was thinking presentational semantics and you were thinking of semantic presentation, basically. Yes, that's a meaningful sentence.
I'm not sure I agree that semantic presentation is really a great idea to implement in markup tags. Rather, it seems to be something that should be managed via properties that are attached to tags. It provides sort of a natural hierarchical inheritance model, rather than (by way of analogy) sticking every single file on your hard drive in the root directory, like the FAT12 filesystem did.
Maybe that's not a concern here, though. I admit I haven't been much involved in thinking about wiki markup needs overall.
On Sat, Jun 24, 2006 at 10:15:47PM -0600, Chad Perrin wrote:
On Sat, Jun 24, 2006 at 11:57:09PM -0400, Jay R. Ashworth wrote:
On Sat, Jun 24, 2006 at 05:34:51PM -0600, Chad Perrin wrote:
There's a difference between semantics (justified, preformatted, list) and content (poem, TV script, needed groceries). So, yeah, it's me asking that.
You're correct, there's a difference.
But, as far as I can see, those first ones are rather specifically not semantics; they're *syntax*. Looks, not meaning.
Which was sort of my point, as well, I believe, as that of Timwi.
In retrospect, the argument about what constitutes "semantic" tags could go either way. I was thinking presentational semantics and you were thinking of semantic presentation, basically. Yes, that's a meaningful sentence.
It is?
:-)
The distinction I'm accustomed to seeing made is between "semantics", the meaning of things, and "presentation", the way that meaning is wrapped in a look, to convey it to the user.
While many meanings may carry the same look, the reason people suggest that the tagging should reflect the *specific* meaning in each case is so that back-end processes which might want to can distinguish.
I'm not sure I agree that semantic presentation is really a great idea to implement in markup tags. Rather, it seems to be something that should be managed via properties that are attached to tags. It provides sort of a natural hierarchical inheritance model, rather than (by way of analogy) sticking every single file on your hard drive in the root directory, like the FAT12 filesystem did.
Well, as long as the tags are distinguishable, yeah, but it seems easier to do <poem> than <special type=poem>, particular in the Wikipedia milieu.
unix virus: If you're using a unixlike OS, please forward this to 20 others and erase your system partition.
Hee. :-)
Cheers, -- jra
On Sun, Jun 25, 2006 at 11:53:30AM -0400, Jay R. Ashworth wrote:
On Sat, Jun 24, 2006 at 10:15:47PM -0600, Chad Perrin wrote:
In retrospect, the argument about what constitutes "semantic" tags could go either way. I was thinking presentational semantics and you were thinking of semantic presentation, basically. Yes, that's a meaningful sentence.
It is?
:-)
The distinction I'm accustomed to seeing made is between "semantics", the meaning of things, and "presentation", the way that meaning is wrapped in a look, to convey it to the user.
Yes, and there's a difference between basing presentation on semantics and creating a semantic class of presentation. In one case, you have presentation classes based on their presentational characteristics, and associate your semantic classes of content with those classes of presentation, and change the associations when you want to modify how a semantic class of content is presented. In the other, you define a semantic class of content as having specific presentational characteristics, which lends itself to the likelihood that you will end up defining three or four semantically-identified classes of presentation that all have roughly the same presentational characteristics, providing greater probability of violation of the DRY principle of design -- which can get messy rather quickly.
While many meanings may carry the same look, the reason people suggest that the tagging should reflect the *specific* meaning in each case is so that back-end processes which might want to can distinguish.
I'm not saying we shouldn't distinguish between content semantics. I'm just questioning the decision to tie presentation characteristics directly to semantic classes of content. I'm also curious as to why a database query (for example) would care that it's fetching a poem, as opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes that have aesthetic taste just yet.
I'm not sure I agree that semantic presentation is really a great idea to implement in markup tags. Rather, it seems to be something that should be managed via properties that are attached to tags. It provides sort of a natural hierarchical inheritance model, rather than (by way of analogy) sticking every single file on your hard drive in the root directory, like the FAT12 filesystem did.
Well, as long as the tags are distinguishable, yeah, but it seems easier to do <poem> than <special type=poem>, particular in the Wikipedia milieu.
That's a good point. Tag properties may not be the best way to handle it. In fact, there's no reason that a simple tag syntax can't be used for semantic markers, and that these cannot be used as cues for applying presentation styles. What concerns me about this is that it seems the way we're implementing a tag syntax for semantic markers is by actually making the semantic markers and presentational style cues synonymous, rather than merely associated (and decoupled).
To further muddy the waters of the use of the term "semantic": I'm not worried about the syntax of assigning semantic markers and presentational styles. Rather, I'm considering the semantic structure of our markup, and how best it can be planned out for future maintainability. It looks to me like extensions to the semantic structure of the wiki markup are being implemented as features, when such should instead be approached as core functionality. After all, the parser is an implementation detail: the language definition is what makes the parser worth using.
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
The distinction I'm accustomed to seeing made is between "semantics", the meaning of things, and "presentation", the way that meaning is wrapped in a look, to convey it to the user.
Yes, and there's a difference between basing presentation on semantics and creating a semantic class of presentation. In one case, you have presentation classes based on their presentational characteristics, and associate your semantic classes of content with those classes of presentation, and change the associations when you want to modify how a semantic class of content is presented. In the other, you define a semantic class of content as having specific presentational characteristics, which lends itself to the likelihood that you will end up defining three or four semantically-identified classes of presentation that all have roughly the same presentational characteristics, providing greater probability of violation of the DRY principle of design -- which can get messy rather quickly.
Unless I'm misunderstanding you, you're suggesting that the concept that there might be many different tags, for different categories of source material, but which we want all to render in the same fashion, is *bad*.
I admit, we're clearly off into your territory here; I almost slid out of that last curve.
While many meanings may carry the same look, the reason people suggest that the tagging should reflect the *specific* meaning in each case is so that back-end processes which might want to can distinguish.
I'm not saying we shouldn't distinguish between content semantics. I'm just questioning the decision to tie presentation characteristics directly to semantic classes of content.
If I understood brion correctly, we're not: that will be handled in the CSS.
I'm also curious as to why adatabase query (for example) would care that it's fetching a poem, as opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes that have aesthetic taste just yet.
I believe the answer to that is "ask the Semantic MediaWiki people", though I'm not sure.
But the point isn't the DBMS.
It's programs people later write to crawl the data, and do statistics on how many poems we have, etc.
Generally, we're metamorpohsing wikitext into XML. :-)
I'm not sure I agree that semantic presentation is really a great idea to implement in markup tags. Rather, it seems to be something that should be managed via properties that are attached to tags. It provides sort of a natural hierarchical inheritance model, rather than (by way of analogy) sticking every single file on your hard drive in the root directory, like the FAT12 filesystem did.
Well, as long as the tags are distinguishable, yeah, but it seems easier to do <poem> than <special type=poem>, particular in the Wikipedia milieu.
That's a good point. Tag properties may not be the best way to handle it. In fact, there's no reason that a simple tag syntax can't be used for semantic markers, and that these cannot be used as cues for applying presentation styles. What concerns me about this is that it seems the way we're implementing a tag syntax for semantic markers is by actually making the semantic markers and presentational style cues synonymous, rather than merely associated (and decoupled).
Ah. No, as I say, if I understood brion correctly, it's a CSS thing.
To further muddy the waters of the use of the term "semantic": I'm not worried about the syntax of assigning semantic markers and presentational styles. Rather, I'm considering the semantic structure of our markup, and how best it can be planned out for future maintainability. It looks to me like extensions to the semantic structure of the wiki markup are being implemented as features, when such should instead be approached as core functionality. After all, the parser is an implementation detail: the language definition is what makes the parser worth using.
Ok, I'll admit to having completely fallen off the wagon on that last graf. Could you expand?
Cheers, -- jra
On Sun, Jun 25, 2006 at 02:49:56PM -0400, Jay R. Ashworth wrote:
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
The distinction I'm accustomed to seeing made is between "semantics", the meaning of things, and "presentation", the way that meaning is wrapped in a look, to convey it to the user.
Yes, and there's a difference between basing presentation on semantics and creating a semantic class of presentation. In one case, you have presentation classes based on their presentational characteristics, and associate your semantic classes of content with those classes of presentation, and change the associations when you want to modify how a semantic class of content is presented. In the other, you define a semantic class of content as having specific presentational characteristics, which lends itself to the likelihood that you will end up defining three or four semantically-identified classes of presentation that all have roughly the same presentational characteristics, providing greater probability of violation of the DRY principle of design -- which can get messy rather quickly.
Unless I'm misunderstanding you, you're suggesting that the concept that there might be many different tags, for different categories of source material, but which we want all to render in the same fashion, is *bad*.
Well . . . yeah, kinda. At least, I don't see a reason that it would be good, and plenty of opportunity for it to be bad.
I might have accidentally assumed familiarity with a concept that may not be familiar to you: mea culpa. I'll try to fix that now.
DRY = Don't Repeat Yourself
Unnecessary repetition leads to unmaintainability, because when you need to change one thing you often end up having to run around changing it in numerous places, and sometimes people miss things.
I'm not saying we shouldn't distinguish between content semantics. I'm just questioning the decision to tie presentation characteristics directly to semantic classes of content.
If I understood brion correctly, we're not: that will be handled in the CSS.
I suppose I should probably just look at the source code for all this at some point and get a better idea of what's going on behind the scenes.
I'm also curious as to why adatabase query (for example) would care that it's fetching a poem, as opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes that have aesthetic taste just yet.
I believe the answer to that is "ask the Semantic MediaWiki people", though I'm not sure.
But the point isn't the DBMS.
It's programs people later write to crawl the data, and do statistics on how many poems we have, etc.
Ahhh, that makes more sense. Sorry, I guess I just didn't get what you were trying to say.
That's a good point. Tag properties may not be the best way to handle it. In fact, there's no reason that a simple tag syntax can't be used for semantic markers, and that these cannot be used as cues for applying presentation styles. What concerns me about this is that it seems the way we're implementing a tag syntax for semantic markers is by actually making the semantic markers and presentational style cues synonymous, rather than merely associated (and decoupled).
Ah. No, as I say, if I understood brion correctly, it's a CSS thing.
That doesn't necessarily mean they're "merely associated (and decoupled)", though at least it's not being handled via direct characteristic definitions for XML tags -- which would probably be a Bad Thing for purposes of later maintainability.
To further muddy the waters of the use of the term "semantic": I'm not worried about the syntax of assigning semantic markers and presentational styles. Rather, I'm considering the semantic structure of our markup, and how best it can be planned out for future maintainability. It looks to me like extensions to the semantic structure of the wiki markup are being implemented as features, when such should instead be approached as core functionality. After all, the parser is an implementation detail: the language definition is what makes the parser worth using.
Ok, I'll admit to having completely fallen off the wagon on that last graf. Could you expand?
I'm speaking of the syntax and semantic structure of languages (thinking of programming languages as my usual example, though markup has roughly the same division of design characteristics). Um. I'm basically saying that I don't care too much about the actual appearance of the markup we use, so long as it's vaguely readable and somewhat consistent (and, preferably, doesn't make typing a chore with lots of underscores and tildes) -- instead, what I care about is the rule set for the language, on which that syntax is built. For instance, there's an underlying structure to romance languages (Italian, et cetera) that is different from that of a language like Japanese. One cannot simply swap out words one-for-one in Italian to make Japanese: rather, one must rearrange the structure of the sentence, certain parts of speech exist in one language and not in the other, and so on. The latter is characteristic of differing semantic structure for a language.
I'd like to see a consistent semantic structure that lends itself to a consistent syntax that in turn lends itself to maintainable use.
On 6/25/06, Chad Perrin perrin@apotheon.com wrote:
Unnecessary repetition leads to unmaintainability, because when you need to change one thing you often end up having to run around changing it in numerous places, and sometimes people miss things.
But in this case, <poem> adds a class that styles the enclosed text as a poem. Among other things, this class includes stuff that would be useful for cooking recipes as well, but that's not all it includes. What if it turns out people decide, six months down the road, that poems should all be blockquoted? Then you could just add "left-margin: 2em;" or whatever to the CSS definition for .class, and voila, all poems are instantly blockquoted. If people have used it for hundreds of cooking recipes in the meantime, all of them are going to be screwed up, unless coincidentally people also want the cooking recipes to be indented. Users can also provide custom stylesheets, to which similar reasoning applies. And non-visual Web readers will also be screwed over.
Anyway, as far as Web standards are concerned, presentation is "indent this two ems and don't break lines". Semantics is "this is a poem, so check if the end-user has set any display preferences for poems, and if not, indent it two ems and don't break lines".
On Sun, Jun 25, 2006 at 06:28:18PM -0400, Simetrical wrote:
On 6/25/06, Chad Perrin perrin@apotheon.com wrote:
Unnecessary repetition leads to unmaintainability, because when you need to change one thing you often end up having to run around changing it in numerous places, and sometimes people miss things.
But in this case, <poem> adds a class that styles the enclosed text as a poem. Among other things, this class includes stuff that would be useful for cooking recipes as well, but that's not all it includes. What if it turns out people decide, six months down the road, that poems should all be blockquoted? Then you could just add "left-margin: 2em;" or whatever to the CSS definition for .class, and voila, all poems are instantly blockquoted. If people have used it for hundreds of cooking recipes in the meantime, all of them are going to be screwed up, unless coincidentally people also want the cooking recipes to be indented. Users can also provide custom stylesheets, to which similar reasoning applies. And non-visual Web readers will also be screwed over.
I'm running out of steam on this discussion, so I'll probably yield the field after this, but I will say before I go:
I've already pointed out that a "does exactly what we want for thirty things, but is named for only one, necessitating the creation of twenty-nine more duplicates on the off-chance we'll change it later" approach can be avoided for ease of differentiation later by separating semantics from presentation, and merely linking the two together. Brion commented with an explanation of what's going on that sounds like it might actually be taking the approach I favored, and only the initial statements' description of what the <poem> tags do created a contrary impression. You seem to think that the behavior assumed in that contrary impression is a better way to do things, however, and somehow have chosen to avoid addressing my statements about the manner in which the same positive effects can be had without the weighty negatives.
Guh. I need a nap.
On Sun, Jun 25, 2006 at 04:33:24PM -0600, Chad Perrin wrote:
I've already pointed out that a "does exactly what we want for thirty things, but is named for only one, necessitating the creation of twenty-nine more duplicates on the off-chance we'll change it later" approach can be avoided for ease of differentiation later by separating semantics from presentation, and merely linking the two together. Brion commented with an explanation of what's going on that sounds like it might actually be taking the approach I favored, and only the initial statements' description of what the <poem> tags do created a contrary impression. You seem to think that the behavior assumed in that contrary impression is a better way to do things, however, and somehow have chosen to avoid addressing my statements about the manner in which the same positive effects can be had without the weighty negatives.
Naw, Chad; we're all in violent agreement.
*How* the poem tag does what it does is precisely the way you, I, and everyone else who I've seen post thinks it ought to: by leveraging CSS.
Now, Steve, on the other hand, has raised a good question: what happens when people *do* want the <recipe> tag? :-)
Cheers, -- jra
Jay R. Ashworth wrote:
*How* the poem tag does what it does is precisely the way you, I, and everyone else who I've seen post thinks it ought to: by leveraging CSS.
Actually, based on Brion's original description, it does rather more than that. In fact, it introduces _new syntax_ that applies to any wikitext enclosed in it.
Specifically, the <poem> environment introduces one new syntax element (the linefeed: normally ignored when not followed by other special markup, now creates a line break in output) and modifies the meaning of another (leading whitespace: normally marks a verbatim preformatted paragraph, now produces indentation).
Consider the fact that any existing poem on a MediaWiki page would break horribly if wrapped in <poem> tags without changing the markup to match the new syntax. This is quite different from your typical semantic HTML tag, like <code> or <blockquote>, which can generally be wrapped around an existing block of markup without changing the way it is parsed. In this respect the <poem> tag is more like <pre> or even <table>, both of which are unique presentational tags that require unusual markup to be used within them.
Jay R. Ashworth wrote:
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
[snip way too much text]
Let me summarize what <poem> does, how, and why. <poem> does two things:
1) It *modifies the behavior* of wiki syntax within its borders to preserve line breaks and initial whitespace in a different way from general text.
A CSS class by itself is insufficient to do this due to the transformations done in wikitext processing, so the extension preprocesses the input to allow the "natural" way of pasting in poem-like text to work.
2) It *marks* the contents with a distinct style class ('poem') which allows distinct styling to be applied to all <poem>s via the global style sheet.
For instance, one might use block indentation, color, or a different font style to make poems visually distinct in text output, and a different voice style or pitch for text-to-speech output.
One could also use this class marking to extract poem contents from rendered HTML data, as one could use the <poem> extension's presence to extract collected poem contents from the wikitext.
Further, a quick note about HTML. Plain old HTML contains a lot of often-forgotten semantic elements, such as:
<abbr> <acronym> <address> <code> <dfn> <kbd> <q> <samp> <var>
Some of those are supported in our wikitext because UseMod supported them; others we've never added. But in general, you can note that they often would not necessarily have distinct default styles. <samp>, <kbd> and <code> usually all render in a monospaced font, like <tt>. But they don't have to, and using distinct elements allows you to style them consistently, or to treat them differently when machine-extracting data. etc.
The set of semantic elements in HTML hints at its creation in a physics research lab full of computer geeks. It has excellent coverage for writing software manuals and project summary pages, but more limited coverage for, say, literature.
Our wiki text has a strong affinity with HTML; we render to it, we allow subsets of it, etc. But we aren't HTML exactly, and where our needs differ it is fully appropriate to have distinct semantic elements.
-- brion vibber (brion @ pobox.com)
On Sun, Jun 25, 2006 at 01:28:46PM -0700, Brion Vibber wrote:
Jay R. Ashworth wrote:
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
[snip way too much text]
Let me summarize what <poem> does, how, and why. <poem> does two things:
- It *modifies the behavior* of wiki syntax within its borders to
preserve line breaks and initial whitespace in a different way from
Aha.
A CSS class by itself is insufficient to do this due to the transformations done in wikitext processing, so the extension preprocesses the input to allow the "natural" way of pasting in poem-like text to work.
Yes.
- It *marks* the contents with a distinct style class ('poem') which
allows distinct styling to be applied to all <poem>s via the global style sheet.
Ok; I thought you'd said that; thanks for confirming.
Further, a quick note about HTML. Plain old HTML contains a lot of often-forgotten semantic elements, such as:
<abbr acronym address code dfn kbd q samp var >
Some of those are supported in our wikitext because UseMod supported them; others we've never added. But in general, you can note that they often would not necessarily have distinct default styles. <samp>, <kbd> and <code> usually all render in a monospaced font, like <tt>. But they don't have to, and using distinct elements allows you to style them consistently, or to treat them differently when machine-extracting data. etc.
The set of semantic elements in HTML hints at its creation in a physics research lab full of computer geeks. It has excellent coverage for writing software manuals and project summary pages, but more limited coverage for, say, literature.
Our wiki text has a strong affinity with HTML; we render to it, we allow subsets of it, etc. But we aren't HTML exactly, and where our needs differ it is fully appropriate to have distinct semantic elements.
Nicely put, and confirms what I'd been thinking (which is nice, cause sometimes the sky in my world is a different color. :-)
Cheers, -- jra
I'm just going to play devil's advocate one last time here then shut up.
On 6/25/06, Brion Vibber brion@pobox.com wrote:
Let me summarize what <poem> does, how, and why. <poem> does two things:
- It *modifies the behavior* of wiki syntax within its borders to preserve line
breaks and initial whitespace in a different way from general text.
That sounds like a useful thing in many situations other than poetry. I'll stipulate a <preserveformatting> tag.
- It *marks* the contents with a distinct style class ('poem') which allows
distinct styling to be applied to all <poem>s via the global style sheet.
...which could be wrapped in a <div class="poem"> tag via a {{poem}} template.
The one thing I notice is we don't have a good way with dealing with blocks of text. {{temp-start}} / {{temp-end}} templates are apparently deprecated, and {{temp|huge block of text that covers several lines and includes tables, templates and all manner of crud}} templates have limitations. Does this mean that the only way to create new block elements (like poems, recipes, source code...) is by defining new elements in the Wiki-markup language itself? That seems like a pity.
Steve
On 6/24/06, Timwi timwi@gmx.net wrote:
Please don't use it for something else, even if it seems somewhat useful for another purpose. It is _designed_ for poems, and it is supposed to mark up only poems. If you find another use, a new tag can be introduced that behaves in a very similar way.
May I ask for a more precise description of why it should not be used for other kind of texts than poems? It is not me you need to convince, I ask you for some good things to say to those who want to use it for other stuff, and style it accordingly.
// habj
On 26/06/06, habj sweetadelaide@gmail.com wrote:
May I ask for a more precise description of why it should not be used for other kind of texts than poems? It is not me you need to convince, I ask you for some good things to say to those who want to use it for other stuff, and style it accordingly.
The main argument boils down to semantics. The output is wrapped in <div class="poem">, meaning that people can opt to see poems formatted in a specific manner. This formatting might not need to be applied to non-poem texts, or it might be otherwise undesirable. In short, it comes down to "don't mark up non poems as poems".
It would be somewhat trivial to expand the extension to allow customising the class output according to the tag used; if another use case pops up, we can add another tag and class combination.
Rob Church
On 6/26/06, Rob Church robchur@gmail.com wrote:
It would be somewhat trivial to expand the extension to allow customising the class output according to the tag used; if another use case pops up, we can add another tag and class combination.
That seems to be the strongest argument for making a generic tag wrapped in a template to set the class. Currently, if a user at fooboo wiki wants to get the behaviour of <poem> for something that isn't a poem, their choices are:
1) Wrap it in <poem> anyway, defeating the whole point of semantic mark up. 2) Attempt to imitate it by implementing something that doesn't quite work as well with templates. 3) Attempt to hack the mediawiki source code to copy <poem>, making something nonportable. 4) Attempt to convince the MediaWiki developers of the validity of their "use case" and wait for it to get implemented. 5) Wrap <poem> in a <div class="foo">, store that in a template, carry out step 4) and reimplement the template with a clean new tag.
Have I missed any?
Steve
Steve Bennett wrote:
On 6/26/06, Rob Church robchur@gmail.com wrote:
It would be somewhat trivial to expand the extension to allow customising the class output according to the tag used; if another use case pops up, we can add another tag and class combination.
That seems to be the strongest argument for making a generic tag wrapped in a template to set the class. Currently, if a user at fooboo wiki wants to get the behaviour of <poem> for something that isn't a poem, their choices are:
- Wrap it in <poem> anyway, defeating the whole point of semantic mark up.
- Attempt to imitate it by implementing something that doesn't quite
work as well with templates. 3) Attempt to hack the mediawiki source code to copy <poem>, making something nonportable. 4) Attempt to convince the MediaWiki developers of the validity of their "use case" and wait for it to get implemented. 5) Wrap <poem> in a <div class="foo">, store that in a template, carry out step 4) and reimplement the template with a clean new tag.
Speaking as a general non-technical user I would have no compunctions about using the <poem> tag wherever it works, including recipes and other non-poetic circumstances.
The average user is intersted in what works, not just the satisfaction of the arcane technical aesthetics of IT specialists.
Ec
On Mon, Jun 26, 2006 at 04:53:45PM -0700, Ray Saintonge wrote:
Speaking as a general non-technical user I would have no compunctions about using the <poem> tag wherever it works, including recipes and other non-poetic circumstances.
The average user is intersted in what works, not just the satisfaction of the arcane technical aesthetics of IT specialists.
For sufficiently small values of "works".
This is why Doing Things Right is so damned difficult.
<rant> It's not aesthetic, it's not technical, and it's not arcane.
Recipes aren't poems. </rant>
Cheers, -- jra
This seems the most logical of all the discussion. Make the <poem> produce <div class="poem"> and <poem class="Foo"> <div class="Foo">. It may seem strange a poem of recipe class but could be the solution for all this problematic.
"Rob Church" wrote:
The main argument boils down to semantics. The output is wrapped in
<div class="poem">, meaning that people can opt to see poems formatted in a specific manner. This formatting might not need to be applied to non-poem texts, or it might be otherwise undesirable. In short, it comes down to "don't mark up non poems as poems".
It would be somewhat trivial to expand the extension to allow customising the class output according to the tag used; if another use case pops up, we can add another tag and class combination.
Rob Church
On Tue, Jun 27, 2006 at 07:10:07PM +0200, Platonides wrote:
"Rob Church" wrote:
The main argument boils down to semantics. The output is wrapped in
<div class="poem">, meaning that people can opt to see poems formatted in a specific manner. This formatting might not need to be applied to non-poem texts, or it might be otherwise undesirable. In short, it comes down to "don't mark up non poems as poems".
It would be somewhat trivial to expand the extension to allow customising the class output according to the tag used; if another use case pops up, we can add another tag and class combination.
This seems the most logical of all the discussion. Make the <poem> produce
<div class="poem"> and <poem class="Foo"> <div class="Foo">. It may seem strange a poem of recipe class but could be the solution for all this problematic.
Well, perhaps, but remember that it was just pointed out that the poem tag does special things specific to poems, which may or may note be appropriate to other specialty insertions -- which may be why it's called called 'poem', come to think of it.
Cheers, -- jra
wikitech-l@lists.wikimedia.org