[10:13:24] Let me recap this to make sure I understand the question correctly: [10:13:25] >Has anyone already requested a feature that would allow Wikifunctions to show HTML output in two ways: [10:13:26] - As raw HTML code (the text with tags, like

Hello

) [10:13:28] - As rendered HTML (how a browser would display it — e.g., showing “Hello” formatted) (preview) [10:13:29] I think we left it out of scope before because of various reasons: [10:13:31] • Security concerns (XSS) – Rendering arbitrary HTML inside the Wikifunctions UI requires strict sanitization and possibly sandboxing. [10:13:32] • Need for sandboxing – A safe preview often requires a sandboxed iframe. Setting that up correctly (CSP, sandbox attributes, event isolation) adds implementation complexity. [10:13:34] • CSS isolation and maintenance – Either we use a minimal generic styling (safe but not representative), or we try to approximate wiki styling. The latter is tricky: wiki CSS varies by skin, wiki, and extensions, and changes over time, so keeping a preview in sync would be a challenge. [10:13:35] Apart from that also the risk of previews that are visually misleading because they might not be equal. [10:13:37] • User experience/design considerations – Deciding how the toggle works (raw vs. rendered), how prominent it is, and what expectations users should have about its accuracy needs design input. [10:13:38] Because of this, we previously left a full previewer out of scope. [10:13:40] A basic first version could still be possible — for example, a toggle in Wikifunctions with a very minimal, safe HTML rendering — but the limitations and design implications would need to be clarified. [10:13:41] I think it’s super useful! Feel free to file a phab task. (Otherwise I can do it later today and add some context) I don’t think we actually made a follow up ticket for this yet. [10:13:43] Sorry for the long answer:) [10:45:46] I’ve done this with Z29587 but I’m leaving that disconnected until T406425 is resolved. (re @Al: Maybe we should just turn Z28154 into a simple Z851 wrapper, with the error-parameter list typed for string arguments?) [11:55:02] Thanks for the length of the answer. These all sound like appropriate concerns and good design considerations. They may quite reasonably put limits on the accuracy of the render, but IMO that shouldn't push it out of scope. Even a basic safe render would very much improve the user experience, because otherwise we just have to stare at the text and imagine the [11:55:02] rendering, or go off [11:55:02] to a sandbox to run it separately. Another issue that you have not mentioned which may crop up is when the HTML fragment is so fragmentary that tags are not properly paired. I'd appreciate if you can file the phab task, because you have a much better understanding of all the dependencies. (re @Daphne: Let me recap this to make sure I understand the question correctly: [11:55:04] >Has anyone already requested a feature that would allow Wi...) [12:16:28] @vrandecic I wonder if the adjective argument of Z29591 should be a lexeme (ref) instead of an item (ref). What item would be used for "rocky"? [12:17:32] Also when I previously thought about adjectives, I considered that we should supply a list not a single adjective, because they quite reasonably stack. (re @u99of9: @vrandecic I wonder if the adjective argument of Z29591 should be a lexeme (ref) instead of an item (ref). What item would be us...) [12:24:11] True, although the order may vary by language and (as in French) the position relative to the qualified noun may vary according to the adjective(s) used. (re @u99of9: Also when I previously thought about adjectives, I considered that we should supply a list not a single adjective, because they ...) [12:26:27] Yes, I hope to get Z19499 working for English. (re @Al: True, although the order may vary by language and (as in French) the position relative to the qualified noun may vary according ...) [13:12:08] fragments should always be balanced, or else they shouldn't be fragments (re @u99of9: Thanks for the length of the answer. These all sound like appropriate concerns and good design considerations. They may quite re...) [13:12:41] oh, the idea with the list is need! (re @u99of9: Also when I previously thought about adjectives, I considered that we should supply a list not a single adjective, because they ...) [13:14:32] Yes… it’s also intuitively recursive, in that it fits within a general scheme for qualifying the head of a noun phrase. In English, we might slot in a noun used attributively before the head and a determiner before the modifying sequence: “all those three nice little new square blue Italian ceramic dinner plates”. It’s an implausible utterance but a useful example, perh [13:14:32] [13:14:32] aps (extending Z19501). (re @u99of9: Yes, I hope to get Z19499 working for English. I've long thought that this would be a cool function to show off.) [13:14:50] Okay, I don't really know the rules. Will there be a validator to help? (re @vrandecic: fragments should always be balanced, or else they shouldn't be fragments) [13:18:34] In your example is "dinner" the noun used attributively? If so, that seems to count as "purpose"? But I take the point that a noun can substitute in. (re @Al: Yes… it’s also intuitively recursive, in that it fits within a general scheme for qualifying the head of a noun phrase. In Engli...) [13:20:53] once we have validators working, yes, but that's not on our immediate plan (re @u99of9: Okay, I don't really know the rules. Will there be a validator to help?) [13:21:41] but a lexeme is inherently language specific? (re @u99of9: @vrandecic I wonder if the adjective argument of Z29591 should be a lexeme (ref) instead of an item (ref). What item would be us...) [13:22:13] I found many adjectives also have an item for this sense. I don't know if that's correct, but it is frequent [13:23:44] Yes to both. But I don’t think we allow nouns to be used attributively except immediately before the qualified noun. (re @u99of9: In your example is "dinner" the noun used attributively? If so, that seems to count as "purpose"? But I take the point that a no...) [13:29:24] …although they can be used to modify the modifier, like “sky-blue” or “brand new”. (re @Al: Yes to both. But I don’t think we allow nouns to be used attributively except immediately before the qualified noun.) [13:31:24] True, but I imagine they map/translate more specifically to other languages when used directly than when going via an item. Even the item you found, "largeness" could be big, large, huge, etc. (re @vrandecic: but a lexeme is inherently language specific?) [13:34:56] Anyway, it doesn't hurt to aim for the item version, and then compose a specific lexeme version when available. (re @u99of9: True, but I imagine they map/translate more specifically to other languages when used directly than when going via an item. Even...) [14:24:21] @u99of9 T410509 was added by James [17:23:57] I would like to duplicate this Zid. Do we have a working user script to accomplish that yet? [17:23:58] I tried adapting the Wikidata one a few weeks ago but failed to finish [17:29:15] see [[User:So9q/Gadget-duplicate.js]] [17:29:16] If I remember correctly I got it to create a new Zid but it didn't contain the information and thus is incomplete. [17:38:54] Look for the answer last time you asked this question in this chat :) (re @Npriskorn: I would like to duplicate this Zid. Do we have a working user script to accomplish that yet? [17:38:55] I tried adapting the Wikidata one a...)