harryalffa wrote:

See also:

Render self-referring interwiki links as bold
https://bugzilla.wikimedia.org/show_bug.cgi?id=5126

Make links to self-redirects being easy distinguishable
https://bugzilla.wikimedia.org/show_bug.cgi?id=16562

see http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.4.1

also http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.4.2
2.4.2 Consider universal accessibility to the Web

I.e., all I know is it sounds like someone is planning to cheat us text browser users.
I.e., requiring CSS to see what is going on.

harryalffa wrote:

As you rightly assume, I do not, and never have used a text browser. If a text browser doesn't show bold fonts, then it will show text within the <strong> tag as not-bold, if it does show bold fonts then <strong> text will show as bold. If a text browser doesn't parse CSS then it will show text within a <span> tag with a CSS command of {font-weight: bold;} as not bold. The actual text will still display.

Nothing will be hidden from text browsers.

See
http://www.w3.org/TR/html401/

These are the sections you indicate

2.4 Authoring documents with HTML 4

We recommend that authors and implementors observe the following general principles when working with HTML 4.
2.4.1 Separate structure and presentation

HTML has its roots in SGML which has always been a language for the specification of structural markup. As HTML matures, more and more of its presentational elements and attributes are being replaced by other mechanisms, in particular style sheets. Experience has shown that separating the structure of a document from its presentational aspects reduces the cost of serving a wide range of platforms, media, etc., and facilitates document revisions.
2.4.2 Consider universal accessibility to the Web

To make the Web more accessible to everyone, notably those with disabilities, authors should consider how their documents may be rendered on a variety of platforms: speech-based browsers, braille-readers, etc. We do not recommend that authors limit their creativity, only that they consider alternate renderings in their design. HTML offers a number of mechanisms to this end (e.g., the alt attribute, the accesskey attribute, etc.)

Furthermore, authors should keep in mind that their documents may be reaching a far-off audience with different computer configurations. In order for documents to be interpreted correctly, authors should include in their documents information about the natural language and direction of the text, how the document is encoded, and other issues related to internationalization.

None of this suggests not using CSS.

I can't find anything at the W3C's "Web Accessibility Initiative (WAI)" (http://www.w3.org/WAI/) which suggest CSS is bad.

Google search for CSS within the W3C's WAI:
http://www.google.com/#hl=en&q=CSS+site%3Awww.w3.org%2Fwai&btnG=Google+Search&aq=f&oq=&aqi=&fp=Qmi82AtOO98

Cheers

ayg wrote:

(In reply to comment #0)

Should Mediawiki force this <strong> semantic markup on every wiki, and everywhere
in an article?

I think the CSS class attribute of "selflink" is enough on its own.

If you mean <span class="selflink">, then no, it's not. <strong> conveys the intended semantics of selflinks, i.e., they're meant to be emphasized rather than linked. <span> is semantically neutral and should only be used when no other tag is appropriate.

Maximum flexibility would be achieved if this was rendered in a
<span> tag with a CSS class attribute.

How would this increase flexibility compared to the present situation?

I would also propose changing the class attribute away from "selflink", because
in en.Wikipedia [http://en.wikipedia.org/wiki/User:HarryAlffa/self-links
myself], and a few people previously have tried to advocate use of the ''self
link feature'' since it was introduced, but are all shot down in
flames[...].
It is obvious, from the talk pages, that this is because of ignorance &
confusion of what this feature actually is. So it's use is actually banned in
en.Wikipedia! A lot of the confusion stems from the
<code>class="selflink"</code> attribute, so everyone refers to it as a
''self-link'', and thinks of it as a hyperlink - even the HTML rendering!

I propose that the CSS attribute be renamed to ... anything which doesn't
confuse users.

We will not rename classes that we've used forever just because some people get confused by them. It would break anything that keyed off the existing class names.

I would suggest that people are not confused by the class name, but rather by the fact that they use ''' for bolding and [[]] for links, and think deliberately using [[]] for bold is confusing and/or silly.

I would propose, instead of "selflink", a CSS for first mention of the articles
subject title, then a different CSS class attribute for any other:

• <code><nowiki><span class="firstMention"></nowiki></code>
• <code><nowiki><span class="articleTitle"></nowiki></code>

This is not going to happen without compelling use-cases, which I don't see.

The use should also be pushed in the standard Help files, where they warn not
to use a self-link as a way to bold-face text - another source of the ban on
Wikipedia I suspect.

Proposed changes to help files go on their talk pages, not Bugzilla. We don't have any more ability to change them than anyone else.

It follows the W3C's [http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.4.1
Separate Structure and Presentation] paradigm, by giving semantic CSS instead
of display formatting markup - a win, win!

Self-links are already marked up semantically. Not using <strong> would be less semantic, not more.

This of course would break Wikipedia, but a few small changes in CSS would fix
it, and in so doing the class attribute name-change will encourage its use as
it was intended!

It would break not just the English Wikipedia, but possibly any other one of Wikimedia's hundreds of wikis, and any one of the probably tens or hundreds of thousands of third-party MediaWiki installation. Changing the class name is not happening, period.

Marking WONTFIX.

Harry: Yes, use all the CSS you want. But at the same time leave something (the
<strong>) for us text browser users who can only see the HTML.

You can see what things are like for us, in Firefox using
View>Page Style>No Style.

Can't you alter the effects of <strong> via CSS to whatever effect you
wish, thus it wouldn't bother you if left it in?

Else you guys get to see the difference, but for us it would now look
all the same. Unfair, no?

OK, I see Aryeh has set this straight.

For extra clarity: we already use <strong class="selflink"> , which means CSS using strong.selflink can customize the appearance of a self-link in every way they want. Using a <span> instead makes no difference whatsoever in this regard.

harryalffa wrote:

Aryeh, yes, I meant <span class="selflink">, and yes <strong> conveys the intended semantics. I was suggesting that this intended semantic markup lacks flexibility. What if a Wiki doesn't want ALL self-links to be <strong>? CSS could override the font-weight: bold effect, but it still does leave the semantic markup. Not using it would leave the choice up to individual Wiki's.
I completely agree with you about users confusion, and the class-name selflink adds to it.
Not using <strong> would be less semantic, that is what I was after, to be replaced by CSS.

If this was a clean sheet of paper design proposal for MediaWiki, then my suggestions, MIGHT, be viewed favourably, but, as you indicate, it's a lot of effort to change. The "it's a bit late to change" is probably enough of an argument on it's own. Still, it was good to get intelligent, analytical discussion - unlike Wikipedia in most of my experience! Perhaps you could contribute to the discussion here;
http://en.wikipedia.org/wiki/Wikipedia_talk:Linking

Good talking to you.

Jiidani, you are quite right, CSS could override the bold effect of <strong>, and this is the sensible way to do it. If a way can be found to distinguish between two separate self-links on one page. Something along the lines of a child selector maybe.

Good to hear from you also.

Cheers to all!
And all intelligent, knowledgeable input would help at;
http://en.wikipedia.org/wiki/Wikipedia_talk:Linking

ayg wrote:

(In reply to comment #7)

Aryeh, yes, I meant <span class="selflink">, and yes <strong> conveys the
intended semantics. I was suggesting that this intended semantic markup lacks
flexibility. What if a Wiki doesn't want ALL self-links to be <strong>? CSS
could override the font-weight: bold effect, but it still does leave the
semantic markup. Not using it would leave the choice up to individual Wiki's.

No, it wouldn't. If we used <span> instead of <strong>, then it would be <span> semantics for everyone, not choice by individual wikis.

Not using <strong> would be less semantic, that is what I was after, to be
replaced by CSS.

CSS has absolutely no effect on semantics. By definition and construction, it is a purely presentational language. Semantics can only be encoded in the HTML itself.

Still, it was good to get intelligent, analytical
discussion - unlike Wikipedia in most of my experience! Perhaps you could
contribute to the discussion here;
http://en.wikipedia.org/wiki/Wikipedia_talk:Linking

You identify the reason I'm not going to contribute in the same breath as you ask me to do so, I'm afraid.

harryalffa wrote:

(In reply to comment #8)
You are absolutely correct in what you say about semantics in HTML. Also, of course, correct about CSS presentational language. In using it however, I think there is an emergent (as it were) behaviour where semantics can be conveyed by CSS, using, as you said before I think, the "neutral" <span> tag, plus CSS. At least I find that a convenient way of thinking of it, and as your own use of the phrase, "<span> semantics", shows it is easy to slip into, even if it's just a convenient way to communicate your point in this context, ie. you concede no ground!
The <span> tag is a bit like tofu, it only has flavour if something is added to it; a CSS attribute, or two.
But of course there is no way to directly replace the semantics of the <strong> tag, there is no CSS {font-weight: strong;}, at least if there was, it would be a synonym for bold, and not an instruction to screen-readers to sound strong emphasis. So we should persuade the W3C to change this! Maybe CSS {text-emphasis: strong;} with options of whisper, normal, emphasis & strong. But I digress! Who knows, maybe a working group is looking at something like this.

Thank god it isn't just me who is unimpressed by the intellectual level of the self important on Wikipedia. I was really beginning to wonder if I was the cleverest man in the World! :)
It's also astonishing how dishonest a lot of them are. Absolutely no compunction about completely misrepresenting what you've said, or using a straw man argument equally dishonestly. And those are the guys writing the Policy & Guidelines! Absolutely astonishing. If Jimbo Whales (Wales?) wants a community of very polite lying bastards, rather than forthright bolshy bastards, he's going the right way about it!!

Cheers.

ayg wrote:

(In reply to comment #9)

(In reply to comment #8)
You are absolutely correct in what you say about semantics in HTML. Also, of
course, correct about CSS presentational language. In using it however, I think
there is an emergent (as it were) behaviour where semantics can be conveyed by
CSS, using, as you said before I think, the "neutral" <span> tag, plus CSS.

Authors have always done this. It is not imparting semantics to CSS, it's just ignoring semantics in favor of presentation-only solutions, because presentation is easier to understand and work with than abstract semantics that have no obvious effect on your bottom line. We, on the other hand, try to use semantic markup for the standard reasons.

At
least I find that a convenient way of thinking of it, and as your own use of
the phrase, "<span> semantics"

By "<span> semantics" I meant the semantics of <span> as defined by the relevant standards. Quoting, for instance, the HTML 5 definition (other HTML versions are similar):

"The span element doesn't mean anything on its own"
http://www.w3.org/TR/html5/text-level-semantics.html#the-span-element

I.e., "<span> semantics" are "no special meaning; any difference to the surrounding text cannot be conveyed using HTML". Any text that has meaning that can be conveyed by any HTML element other than <span> does not, by definition, have <span>'s semantics, and should not be marked up using <span>.

So we should persuade the W3C to change this! Maybe CSS
{text-emphasis: strong;} with options of whisper, normal, emphasis & strong.

This completely misunderstands the purposes of HTML and CSS. CSS does not convey semantics and is not meant to. Presentation and semantics are supposed to be separated: semantics in HTML, presentation in CSS. You even quoted something to that effect on this very bug.

That's the theory, anyway. Not everyone buys it, but most MediaWiki developers do, within reason. And certainly the W3C does. You could always propose this on www-style, if you like, but this isn't the place.

harryalffa wrote:

(In reply to comment #10)

(In reply to comment #9)

(In reply to comment #8)

Authors have always done this. It is not imparting semantics to CSS, it's just
ignoring semantics in favor of presentation-only solutions, because
presentation is easier to understand and work with than abstract semantics that
have no obvious effect on your bottom line. We, on the other hand, try to use
semantic markup for the standard reasons.

There is HTML structural semantics and "other" semantics. There still is presentational semantics, mostly deprecated, replaced by CSS. Presentational CSS semantics can impart meaning to the reader, it was this kind of "textual semantics" I meant. CSS "presentational semantics" when read can give nuanced semantics to the text it presents. Sorry for the confusion, I wasn't really expecting your excellent forensic analysis of my text, I've been on en.Wikipedia too long where the language is very imprecise. I wasn't being entirely serious either! So that contributed.

By "<span> semantics" I meant the semantics of <span> as defined by the
relevant standards. Quoting, for instance, the HTML 5 definition (other HTML
versions are similar):

"The span element doesn't mean anything on its own"
http://www.w3.org/TR/html5/text-level-semantics.html#the-span-element

I.e., "<span> semantics" are "no special meaning; any difference to the
surrounding text cannot be conveyed using HTML". Any text that has meaning
that can be conveyed by any HTML element other than <span> does not, by
definition, have <span>'s semantics, and should not be marked up using <span>.

As I said, the <span> tag is a bit like tofu, it only has flavour if something is added to it; a CSS attribute, or two.

This completely misunderstands the purposes of HTML and CSS. CSS does not
convey semantics and is not meant to. Presentation and semantics are supposed
to be separated: semantics in HTML, presentation in CSS. You even quoted
something to that effect on this very bug.

No! :) I completely understand HTML & CSS!! This was a somewhat light-hearted suggestion - imagine Cascading Semantic Sheets! :)

That's the theory, anyway. Not everyone buys it, but most MediaWiki developers
do, within reason. And certainly the W3C does. You could always propose this
on www-style, if you like, but this isn't the place.

www-style?
I buy it! I practice it!

Anyway, back to the original problem.
You could add an id to the <strong> tag for the first mention of an articles title like this; <strong class="selflink" id="firstmention">. Other self-links in the article would still be in strong tags with the class="selflink", but without the id="firstmention", then CSS could be:-
strong.selflink { font-weight: normal; }
strong#firstmention { font-weight: bold; }

But this could only be done for ONE instance, and therefore fails when there is more than one form of the title:-
A '''Matryoshka''' doll or a '''Russian nested doll'''.

The additional id="firstmention" could be given to all self-links in the first paragraph, but you can imagine problems with that.

Is it possible to make this a configurable part of Wikimedia? But then what do you make configurable?

The problem of having different self-links display differently isn't solvable without additional wiki-syntax. Perhaps an extension to the link syntax of this nature:-
A [[Matryoshka doll|:firstmention]], [[Matryoshka doll|Russian nested doll|:firstmention]].

Then add the id="firstmention" to those links. Then CSS could be as above.

What the actual syntax would be ... But it would have to be short and memorable - maybe the first thing after the "[[" in the link syntax - and it would have to have no effect if used in a link which wasn't a self-link.

harryalffa wrote:

Any other ideas?

Adding 'firstmention' or some similar ID to the first usage of the self-link wouldn't be a terrible idea in and of itself, nor would it necessarily be hard to do (an extension to link syntax is useless and confusing IMHO).

However, I'm with Simetrical on the call to WONTFIX changing <strong> -> <span>.

ayg wrote:

(In reply to comment #13)

Adding 'firstmention' or some similar ID to the first usage of the self-link
wouldn't be a terrible idea in and of itself, nor would it necessarily be hard
to do

Sounds like cruft IMO. We have too many classes/id's already, we shouldn't just add a new one every time one guy wants it for some narrow purpose (no offense intended to anyone).

WONTFIX changing <strong> -> <span>.

Indeed, as is plain from the Summary above, this is an anti-accessibility coup attempt that must be stopped.

harryalffa wrote:

Don't know what Cruft is!
No offence taken! I agree that careful consideration should be given to adding more classes/id's - or anything else. I hope to persuade you it would be worth the effort!

I agree that changing the <strong> tag would be problematic. Hence the idea of adding an id="firstmention", as this would not effect anything. Purposeful CSS could then take advantage of it, with no side effects on current CSS presentation.

Narrow purpose? Well ... yes, I suppose it is. It's one idea. Is it a bad one though, or is it a good one?

Here are the advantage for Wikipedia, as I see them, in using self-links;
http://en.wikipedia.org/wiki/User:HarryAlffa/self-links#Advantages

The trouble is on Wikipedia the MoS says don't use them at all, and a bot was used to scour out the use!

Even if Wikipedia were persuaded to use the self-llink feature as is, it has some disadvantages:

• it forces the <strong> tag on the rendered HTML - but there's is no escaping that now!
• because of the <strong> tag, self-links can only be used for a first-mention & variants - the MoS want's that bold, but no others

If these disadvantages were overcome I can see Wikipedia being persuaded to use the self-link feature.

I can see greater efficiency for all if self-links could be used throughout an article with only the MoS indicated ones being emboldened ie. for (each) first mention of the article title (and it's variants). This would all be in the first paragraph - usually!
I can imagine it wouldn't be to difficult to slap an id="firstmention" on all self-links in the first paragraph, and that would usually work, but... It shouldn't be too great a leap in complexity to check for uniqueness in the linked text, and only add the id attribute to first mentions which are truly first mention, but would you do the whole document or just the first paragraph, or perhaps the lead? If you check the whole document, then you may as well not render second-mention self-link texts within a <strong> tag - which would work for Wikipedia, but who knows what Wikis it might break?

Actually, I think I just persuaded myself that checking the whole document, and adding the id attribute to truly first mentions is the best idea. But would this be an excessive processor load for EVERY article, assuming use became universal? Restrict to lead only?

harryalffa wrote:

(In reply to comment #15)

WONTFIX changing <strong> -> <span>.

Indeed, as is plain from the Summary above, this is an anti-accessibility coup
attempt that must be stopped.

Wow! Steady tiger!!

All I (with my meager 1 KB of working memory upstairs here in the
brain) knows is the Summary above is inauspicious for us text browser
users. The rest is over my head (which is currently browsing
http://www.wretch.cc/album/show.php?i=e0456789j&b=23&f=1100870981&p=6
which I'll have you know looks great in text browsers), so I'll butt out here...

harryalffa wrote:

Nobody is now suggesting changing <strong> -> <span>.

Then please change the

Summary: Self-link feature should use only CSS, not HTML strong tag, for greater flexibility

harryalffa wrote:

(In reply to comment #20)

Then please change the

Summary: Self-link feature should use only CSS, not HTML strong tag, for greater flexibility

I did not know that could be done!

Done now!!

id="firstMention" isn't really necessary AFAICT, since you can use
.selflink:first

Remove reading instructions from summary.

OK, I trust you. Stepping off Cc: list.

ayg wrote:

(In reply to comment #22)

id="firstMention" isn't really necessary AFAICT, since you can use
.selflink:first

There is no :first selector. There's only :first-child and :first-of-type, which don't do exactly what you want. .selflink:first-of-type would work unless there's an earlier <strong> in the article, which is unlikely on Wikipedia. But of course, it wouldn't work in any version of IE up to and including 8.

(In reply to comment #14)

(In reply to comment #13)

Adding 'firstmention' or some similar ID to the first usage of the self-link
wouldn't be a terrible idea in and of itself, nor would it necessarily be hard
to do

Sounds like cruft IMO. We have too many classes/id's already, we shouldn't
just add a new one every time one guy wants it for some narrow purpose (no
offense intended to anyone).

I agree, it is cruft. We don't need yet another class/ID tacked on because one person asks for it. Without more voices asking and a compelling use case, I don't see it happening.

(In reply to comment #19)

Nobody is now suggesting changing <strong> -> <span>.

Since the second request is no longer valid either, I'm going to WONTFIX.