Changed back to normal; my first post at phabricator...

Don’t know all the details and politics, but hope this can be resolved. Can you tell me when do bugs/issues usually get fixed i.e. how much time approximately it takes to resolve one like these?

As far as I know, there are no developers actively working on Cite. That means that unfortunately, this task will join the queue of 103 other tasks in the Cite code waiting to be solved, many of which date back to 2010 and earlier.

A CSS based solution to insert a ZWJ before the refs is

sup.reference::before {
    content: "\200d";
}

The zero-width joiner reads as a question mark for me in the latest versions of both JAWS and NVDA, which are among the most popular screen readers for Windows.

Which admittedly doesn't sound that bad *before* a reference ... but I could still do without it.

Can such a CSS rule excluded for screen readers?

Nope. Screen readers don't follow the CSS rules that have been designed for them.

@Fomafix no, that's not possible. Also It creates a bit of a visual problem with larger sequences of multiple references and situations where the ref id is something like [note-567] should also be evaluated probably.

In T125480#1990256, @Graham87 wrote:

Nope. Screen readers don't follow the CSS rules that have been designed for them.

That is not the answer of my question. Maybe we have a misunderstanding.

I tested with Claws. It does not output any CSS generated content like

sup.reference:before {
	content: "Foo";
}

Does your screen reader include such CSS generated content?

In T125480#1990356, @TheDJ wrote:

Also It creates a bit of a visual problem with larger sequences of multiple references and situations where the ref id is something like [note-567] should also be evaluated probably.

Hmm, I think this aim of this task:

A long sentence up to the end of the line with four references and a veryLongUnwrapableWordAtTheEnd.[1][2][3][4]

wraps the last word together with all references to the next line when it does not fit at the end of the line.

When this is not acceptable then the whole task should be closed as invalid.

What is defined as a "veryLongUnwrapableWordAtTheEnd"? Is it like a recipe which tells you "put some sugar" or "put a bit of sugar" where "a bit" for me could be either 0.0000000001 g or 2,000 kg?

You cannot define a "veryLongUnwrapableWordAtTheEnd" unless you really define a "veryLongUnwrapableWordAtTheEnd" by stating its length; this leads me to either first or second solution below:

• You can APPLY rule relentlessly i.e. ALWAYS for all cases (for which I give my vote because there will always be possibility of "... and a veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryvery...veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryvery...veryveryveryveryveryveryveryveryveryLongUnwrapableWordAtTheEnd." (without references, just a huge word of let’s say infinite length) besides "... and a veryLongUnwrapableWordAtTheEnd.[1][2][3][4]" (with references that you cannot add as much as you want i.e. as much as words can be long), if you get what I want to say and point out).
  
  — NOTE: We can never have more than 5 or maximum 10 or let’s give it a space a bit – 15 – references at the end due to the "Wikipedia:Citation overkill" and here is an example of what cannot be found in an article without sanctions: COMPLETE-OVERKILL EXAMPLE

• You can DEFINE WHAT a "veryLongUnwrapableWordAtTheEnd" IS i.e. define its length to lets say 15 or 20 or 25 or 30 characters, what is a very messy business to deal with, and that I do not support at all.

If we are just chit-chattin’ then nothing will be resolved as in T125480#1989103 @TTO said:

As far as I know, there are no developers actively working on Cite. That means that unfortunately, this task will join the queue of 103 other tasks in the Cite code waiting to be solved, many of which date back to 2010 and earlier.

So, if really no one is going to try to fix this even if he is not a "true cite developer" (if such a person exists), it is just one more task to be added to the queue of still unsolved problems, what is worst solution of all...

In T125480#1991806, @Obsuser wrote:

What is defined as a "veryLongUnwrapableWordAtTheEnd"?

The subjective point at which people will perceive it as 'standing out' compared it's surroundings.

• **You can APPLY rule relentlessly i.e. ALWAYS for all cases

Yes, this is what would be most logical

NOTE: We can never have more than 5 or maximum 10 or let’s give it a space a bit – 15 – references at the end due..

If it's out there, people will complain about it. BTW: that page on mobile widths with this change :)

You can DEFINE WHAT a "veryLongUnwrapableWordAtTheEnd" IS i.e. define its length to lets say 15 or 20 or 25 or 30 characters, what is a very messy business to deal with, and that I do not support at all.

Which we cannot really guarantee, because it's not 'just' the website, it's every view of the content (think mobile app or other alternate views).

If we are just chit-chattin’ then nothing will be resolved as in T125480#1989103 @TTO said:

As far as I know, there are no developers actively working on Cite. That means that unfortunately, this task will join the queue of 103 other tasks in the Cite code waiting to be solved, many of which date back to 2010 and earlier.

So, if really no one is going to try to fix this even if he is not a "true cite developer" (if such a person exists), it is just one more task to be added to the queue of still unsolved problems, what is worst solution of all...

There is a difference between chit-chat and impact analysis. But since it's a cosmetic issue, with a 'low return value' and a 'high risk' factor in an area that is not 'owned' by a developer, it might very well end up on a big pile indeed.

In T125480#1990627, @Fomafix wrote:

I tested with Claws. It does not output any CSS generated content like

sup.reference:before {
	content: "Foo";
}

Does your screen reader include such CSS generated content?

Nope.

But I said it cannot be more than ten references, and this is old version of the page just as an example.

I know that mobile view is going to be influenced and others but as I mentioned: there are really much longer words that are non-wrappable than sequences of references which are not going to contain more than ten references.

In your screenshot even 13–14 references would be shown inside of the boundaries, and if had much longer word ("representationSofStheSbombingSbySthe" let’s say, it would still be space for about four references). These are very generalized views, but I’m sure developers can figure out something.

One idea is that after five references in a row we allow break just to ensure there wont be problems (even six-in-a-row reference sequences are rare but still better to be sure).

Have you ever thought about wiki tables that are much more complex problem as they almost always break right margin and pop out since words in headers simply cannot be broken?

This is a cosmetic issue but I wouldn’t agree it is "with a 'low return value'" since it will affect every single article on every single Wikipedia and every single ugly view of the reference at the beginning of the row will be past. Also, it is not "a 'high risk' factor in an area that is not 'owned' by a developer" since it is a cosmetic issue which cannot be dangerous as some other directly-to-wikimarkup related queues.

One more idea: we might wrap only first reference so others could be allowed to get unwrapped. We might also do this for groups of two (one reference superscript number will always be next to the previous word, two of them too, next two will be grouped for sure, next two will be grouped too etc. but if we are left with let’s say two-two-two-one sequence – than the last one goes to the previous i.e. last group of two to make group of three).

There are many combinations, there are many solutions, there is a bunch of possible ways to solve possible breaking of right margin; there’s just no persons who know how to deal with the problem (I don’t know and have neither capabilities nor rights) and want to deal with it. There are just too many who know how but don’t want to spend time on such cosmetics they consider unimportant, I guess with all due respect...

Archived for year 2344 obviously. :)

In T125480#1992511, @Graham87 wrote:

Does your screen reader include such CSS generated content?

Nope.

Ok, then this CSS rule does not affect screen readers and the solution does not change anything for screen readers.

Since the solution consists just of a CSS rule, every user and every project can install the rule in the common.css/global.css. When it is well tested and does not make any problems then it may included in Cite.

A sequence of references can not accessed by a CSS rule because the selector

sup.references + sup.references { ... }

matches to

Text<ref/><ref/>

but also to

Text<ref/> Text<ref/>

Here a change in Cite would be necessary.

A customizable message as reference joiner would be interesting. Especially for frwiki where this is made manually by [[ https://fr.wikipedia.org/wiki/Mod%C3%A8le:, | {{,}} ]]. This can requested as a separate task.

Can we simply add "&zwj;" (zero width joiner) before every single or every fifth or read post above for more proposals "<ref" (exactly "<ref")?

This would do the job perfectly...

Can someone resolve this?