[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. @thiemowmde whatever your reasons, I like the structure you propose :)TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Izno added a comment. In T147307#2741800, @daniel wrote: In T147307#2739272, @Izno wrote: Why wouldn't you always output an HTML list at that point? Because we usually want inline rendering, not a block level element. Inline rendering is a trivial CSS fix (and can be varied based on classing on parent elements). My read of HTML5 seems to indicate it would be semantic to place it within a or a element, so I don't see an issue there. And I agree with thiemowmde at Sounds more like the disagreement is what the purpose of the new feature is, who will use it given his statement at It's a convenience feature to be used in infobox templates. Since I do not know that I would expect an infobox template to take inline content rather than block content of this sort. And I happen to agree with This output should never be parsed. in that it should not be designed to be parsed (what the clients will do, will do).TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, IznoCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. Sounds more like the disagreement is what the purpose of the new feature is, who will use it, for what and how. To me your arguments sound like you are outputting XML or JSON. Sure, as a consumer of an XML stream I would not like it if some nodes are sometimes not there. But this is not relevant here. This output should never be parsed. It's a convenience feature to be used in infobox templates. Anything that "just looks wrong" from a users perspective will be rejected and not used by the communities. Any "just looking wrong" is true for commas that separate empty elements, thumbnails separated by commas, and lists that aren't lists. We did have a lengthy discussion about div vs span because of this issue. As already said above a private chat is of no value. Who is "we"? What issue? What arguments did you shared? Which arguments did you considered more relevant than others? Which arguments did you missed?TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. In T147307#2741801, @thiemowmde wrote: I am the "poor soul" writing CSS. I can assure you, there is no problem with wrapping things that are lists in a tag that represents a list, and not doing this with things that are not a list. Well, I guess that's the crux of the disagreement, then: I think it is a list even if there is only one element, and it should be made obvious that it is a list. In particular, callers should never rely on it not being a list, even if it is commonly a single value. I don't understand why you say that. In the discussions I was involved in nobody ever said it would be a good idea to give any guarantees about inline vs. block elements. It's guaranteed to be a DOM element. That's all. We did have a lengthy discussion about div vs span because of this issue. IIRC we decided to actually guarantee an inline element there. It's rather important for the caller to know whether they will get an inline or block element.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. (Note: I edited my comment above.) If you were the poor soul writing a CSS rule for styling values in a statement list, you would hate any special casing here. I am the "poor soul" writing CSS. I can assure you, there is no problem with wrapping things that are lists in a tag that represents a list, and not doing this with things that are not a list. the caller would not know whether to expect a block level element, or an inline element. I don't understand why you say that. In the discussions I was involved in nobody ever said it would be a good idea to give any guarantees about inline vs. block elements. It's guaranteed to be a DOM element. That's all.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. In T147307#2739272, @Izno wrote: Why wouldn't you always output an HTML list at that point? Because we usually want inline rendering, not a block level element.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. @thiemowmde wrote If the output is a single DOM element anyway, there is no need to do this. Consistency. If you were the poor soul writing a CSS rule for styling values in a statement list, you would hate any special casing here. The contrary: It will cause unnecessary confusion if a single statement is wrapped in something that claims to be a list, but is none. I think it causes confusion otherwise. This becomes very obvious the moment we support other list renderings. An with a single element is bad. Instead the element itself should be returned, not wrapped in anything. It's even worse then: If we support rendering, and we skip it for a single value, the caller would not know whether to expect a block level element, or an inline element. Your example actually makes me more convinced that we should not have a special case for single values.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. On IRC @daniel and I decided that we actually want to wrap the whole list of values in another span even if it has only one element. As argued in the comments in https://gerrit.wikimedia.org/r/317127 I disagree: The one and only guarantee we want to give is that the output is always a single DOM element (or nothing). Therefore we must wrap multiple elements in an other span. Otherwise some outputs would be "2001, 2002". This would have multiple issues that can all be avoided by wrapping it in something like …. If the output is a single DOM element anyway, there is no need to do this. The contrary: It will cause unnecessary confusion if a single statement is wrapped in something that claims to be a list, but is none. This becomes very obvious the moment we support other list renderings. An with a single element is bad. Instead the element itself should be returned, not wrapped in anything.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
gerritbot added a comment.
Change 317127 merged by jenkins-bot:
Always wrap output of the {{#statements|…}} function in a
https://gerrit.wikimedia.org/r/317127TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Izno added a comment. In T147307#2739238, @hoo wrote: On IRC @daniel and I decided that we actually want to wrap the whole list of values in another span even if it has only one element. That would make
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
hoo added a comment. On IRC @daniel and I decided that we actually want to wrap the whole list of values in another span even if it has only one element. That would make
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. I agree: empty output should not be wrapped, but stay empty. Logically, this is really NULL, not a string. We only use a string in such cases because of technical restrictions.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
gerritbot added a comment.
Change 317127 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Always wrap output of the {{#statements|…}} function in a
https://gerrit.wikimedia.org/r/317127TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. As discussed, I fully support the idea of data attributes, microformats and such. But: We must drop the EscapingSnakFormatter in the DataAccessSnakFormatterFactory anyway, and create one that understands these semantics. We will rethink lots of things anyway when we do this. I believe this new formatter must still ignore empty values, and never output empty elements. There is nothing the user can do with it, if it does not have a label. Note that the main purpose of the output this new code produces is to be meaningful to the user. Being machine readable is a bonus. Currently this is required, otherwise we would render weird stuff like "A, , C, ". An option would be to check for '' when joining the list with commas, but I do not like the idea of code that tries to detect empty HTML elements. Let's say we give users the option to output an HTML list. Rendering an with an empty can not be done, I believe (possibly as an option, but not by default). So where would the empty span go instead? After the list? I find this weird. Better not output it. TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. This is what I have in mind: 2015 2015, 2016 A single value is wrapped in a span, and can have additional attributes. Two values must be wrapped in individual spans, otherwise it would not be possible to have value-specific attributes. The outer span is only necessary to fulfill the guarantee to always return single DOM element. The outer span could even have a specific class name. Or be a list. But I would not do anything like this in the first iteration. Just spans, please. Make this as trivial as possible. I would also avoid commas, if possible.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Izno added a comment. In the list case, it should ideally be, with appropriate CSS: 20162017 I suppose you could leave the spans in and produce something like this, but this is unnecessary HTML: 20162017 I suppose you could always output a list of one in the "one claim" case and then you don't need the spans. (The CSS needs a little help for that, but it's possible.)TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, IznoCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
hoo added a comment. For completeness, here's my comment on the snakFormatter factory patch: Note: This implements T147307 by wrapping each individual parsed Snak in a . Wrapping comma separated lists in s is the responsibility of whatever class creates the comma separated list. So that implements wrapping each Snak in a , but not wrapping the entire list in a .TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
hoo added a comment. I was just about to implement this… what about 2016? Do we want to be consistent here and have one span for the value and one for the whole thing (2016) or just one span (2016).TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Lydia_Pintscher added a comment. Discussed with @thiemowmde. 2015, 2016 seems correct and consistent.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, Lydia_PintscherCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
hoo added a comment. In T147307#2705797, @thiemowmde wrote: Rather than talking about a element I would phrase the guarantee we give as follows: "Guaranteed to be a single HTML element node, possibly containing text and other HTML nodes." This gives us the freedom to choose whatever element is appropriate per value type. Monolingual strings become …, but item references become . So if we have a trivial value like a year, that would become 2015. But if we have two primitive values here, would it become 2015, 2016`?TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Izno added a comment. Where another HTML element doesn't suffice, then yes, wrapping in spans would be a good idea. However, for which DataTypes would the element not work?TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
