support for <q></q>?

[maniqui]

Now that it's more widely supported, it could be a nice addition.
Here are a few ideas (well, "ideas", in some cases, I just looked for some unused symbols) for the syntax:

Double double quotes:

And then she said: ""That's what he said"", and everyone had a laugh.

Double single quotes: 

And then she said: ''That's what he said'' and everyone had a laugh.

Double tildes:

And then she said: ~~That's what he said~~ and everyone had a laugh.

Double pipes:

And then she said: ||That's what he said|| and everyone had a laugh. 

[eliph]

+1

This could solve issue #10. Textile generates the tags, and the user can specify language specific quotation marks in the CSS, like so:

<style type="text/css">
html[lang="de"] q { quotes: "»" "«" }
q:lang(de) { quotes: "»" "«" }
</style>

[netcarver]

For now, if you want to experiment with this (not a viable longer-term solution, just to whet your appetite), simply change the glyphs assigned to the open and close double quotes to be and respectively...

@define('txt_quote_double_open',  '<q>');
@define('txt_quote_double_close', '</q>');

You can then play around with the CSS to define language mappings and try out different rules for different languages...

p[de]. Here is "some" text.

p[fr]. Here it is "again."

etc, etc.

I don't see this as a particularly good solution to #10 though as it doesn't address the use of language specific alternate quotes that should be mapped to single open and closes. It also ignores rules about what glyphs to use to indicate things like possession.

[netcarver]

Of all the possible solutions I think backticks are probably the safest unused characters in textile if we did adopt the use of q tags. If this were the case then...

`Here is a quote`

...would become...

<q>Here is a quote</q>

and the browser renders the quotes according to the CSS.

Backticks also look like you are actually quoting something in the source text.

[wion]

Whew. Six years. Okay, here it goes... And pardon my ignorance. I'm not a dev. I only look at this from the surface, so may not see the obvious inhibitors.

Regarding this request for q support, which I like the idea of, and considering the challenge of deciding upon what syntax to use, and also considering textile support for the cite element (i.e. ??source cited??) might be in the running for the element least needing textile support, then why not use the syntax currently reserved for the cite element for the q element instead?

Consider this Moz text example:

In <cite>2001: A Space Odyssey</cite>, Dave asks HAL to open the pod bay door and HAL answers: <q cite="https://www.imdb.com/title/tt0062622/quotes/qt0396921">I'm sorry, Dave. I'm afraid I can't do that.</q>

Note this represents use of the q element's cite="" attribute too.

So, with Textile, instead of this:

In ??2001: A Space Odyssey??, Dave asks HAL to open the pod bay door and HAL answers: <q cite="https://www.imdb.com/title/tt0062622/quotes/qt0396921">I'm sorry, Dave. I'm afraid I can't do that.</q>

Which is nearly pointless, because you could just as easily us __2001: A Space Odyssey__, which is even better than adding the italics in via CSS (cite {font-style:italic;) because not all sources may be the kind of name or title that should be italicized (e.g. blog articles, journal articles, etc are not).

So, recycling the ?? syntax for q, we might have this:

In <cite>2001: A Space Odyssey</cite>, Dave asks HAL to open the pod bay door and HAL answers: ??(https://www.imdb.com/title/tt0062622/quotes/qt0396921)I'm sorry, Dave. I'm afraid I can't do that.??

Note how the URL is incorporated to account for the cite="" attribute value. I make the assumption in this case, perhaps erroneously, that the leading http can be used to know that a cite="" attribute is needed, much like a # informs needing id="".

But an author could just as easily opt to not provide the URL too, or to provide it in an alternate (and more intuitive) way:

In <cite>2001: A Space Odyssey</cite>, Dave asks HAL to open the pod bay door and
"HAL answers":https://www.imdb.com/title/tt0062622/quotes/qt0396921, ??I'm sorry, Dave. I'm afraid I can't do that.??

All and all, this is as much about the tactic the author takes in writing as much as satisfying some old-school HTML 4 invention, and in this light, the value seems to fall on the q element more than the cite element.

And, if you're a heavy footnotes/endnotes user, like I am, the cite element is irrelevant because you're using the numbers referencing system. The q element I use all the time for those inline quotations, or for inline quotations in the endnote annotations too. Much more valuable.

[wion]

I guess there is the issue of backwards compatibility, and, as I just read now after the fact, the Textile contributor guidelines states all changes must be backwards compatible, so...

Maybe this just stays on indefinite hold, because, honestly, <q> is not that many extra chars.

[wion]

cc @bloatware :)

[bloatware]

As I get it, cite is more than just italics:

The cite element represents a reference to a creative work. It must include the title of the work or the name of the author (person, people or organization) or an URL reference, or a reference in abbreviated form as per the conventions used for the addition of citation metadata.

So recycling ?? for q looks problematic for legacy reasons. I'm fine with backticks, though, but my voice is just a voice.

[philwareham]

Agree that legacy syntax should not be changed in function. So backticks would be my preference too, as long as it doesn’t break anything.

[maniqui]

What about using double double-quotes or double single-quotes wrapping the text?

…

On Sat, 20 Oct 2018, 18:57 Phil Wareham, ***@***.***> wrote: Agree that legacy syntax should not be changed in function. So backticks would be my preference too, as long as it doesn’t break anything. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUXfwFqX7w46GuilyPJTD9CxlFiWuLxks5um5w4gaJpZM4AGlOr> .

[bloatware]

What about using double double-quotes or double single-quotes wrapping the text?

It's fine from "writer" pov, but a bit risky in txp context. Something like this could be broken:

Form 'hello': 
Hello, '<txp:yield />'!
...
Used like:
<txp::hello escape="textile" />

[wion]

Again, I think the q element is one that may not be worth messing with. The HTML is already short and simple and well-embedded in most heads at this point, certainly is mine. I'd probably not use Textile for this even if it existed because I'd never remember what it was and be confused by it anyway. Sometimes HTML is just better. This might be one of those times.

As I get it, cite is more than just italics

Yes, the italics thing wasn't really what I was trying to emphasize. Rather I don't think many people use the cite element at all anyway, certainly not as much as they could, based on those examples.

But, most important here is guarding the legacy, so... q is a moot request as far as it concerns me. ;)