Re: __TOC__

> I've just committed a new magic word __TOC__ that inserts the toc at the
> place it is found. This implies __FORCETOC__.

Thank you! Now I can stop trying to come up with headings for
paragraphs that don't need them, just to make the ToC come after the
lead-in; it's led to some awfully odd and forced headings... :D

--

-- 
Rowan Collins BSc
[IMSoP]

Re: Re: Pocket Internet Explorer and other handheld devices

> It is pretty bad in many respects. For example, it seems to ignore the
> "display" attribute, so "display: block" and especially "display: none"
> don't have an effect; as a consequence, every external link has their
> URL next to it, which is pretty bad *especially* on a small-screen
> device. 

Actually, I think hiding things using CSS is probably a rather bad
idea anyway - I know it's kind of cool that it's possible, and it's
certainly an elegant solution where available, but invisibility is one
attribute that really doesn't 'degrade elegantly' if unavailable.

I was thinking of pointing this out somewhere before, if it hasn't
been already, since text-based browsers (for instance) have the same
problem. It looks especially ugly for footnote-style links ("[1]" et
al) and links typed in the form "[http://example.com
http://example.com]" - although the latter are broken at the moment
anyway. :-/

I'm not sure what a better solution would be, but maybe some
JavaScript voodoo to add them or uncomment them. In general, I dislike
relying on JavaScript even more than I dislike relying on CSS, but I
accept that this option is never going to be viable server-side, and
presumably people wanted it.

--

-- 
Rowan Collins BSc
[IMSoP]

Re: __TOC__

Rowan Collins wrote:

>>I've just committed a new magic word __TOC__ that inserts the toc at the
>>place it is found. This implies __FORCETOC__.
> 
> Thank you! Now I can stop trying to come up with headings for
> paragraphs that don't need them, just to make the ToC come after the
> lead-in; it's led to some awfully odd and forced headings... :D

Are you saying you're going to have unheaded text after the TOC? I 
strongly disagree to that; that is very bad/unprofessional page layout.

Re: Pocket Internet Explorer and other handheld devices

Rowan Collins wrote:

> Actually, I think hiding things using CSS is probably a rather bad
> idea anyway

Although your reasons seem sound, your stance raises the question: Does 
that mean you reject the idea of using the same HTML for different 
layouts? Thing is, that is the whole purpose of CSS.

Re: Antispam and antivirus ?

Yann Forget wrote:

> I think we should have some filtrer for the mailing lists against spams and 
> virus.

How come I never see spam or viruses here?

Is it because friendly gmane folk manually delete them from the server? 
If that is so, I can only recommend strongly everyone use gmane's NNTP 
interface too! :) If, however, gmane have automated spam filtering 
mechanisms installed, it means legitimate messages may sometimes not 
show up. Worrying...

Timwi

Re: Re: Pocket Internet Explorer and other handheld devices

Rowan Collins wrote:
> Actually, I think hiding things using CSS is probably a rather bad
> idea anyway - I know it's kind of cool that it's possible, and it's
> certainly an elegant solution where available, but invisibility is one
> attribute that really doesn't 'degrade elegantly' if unavailable.

Actually, that's exactly an instance of elegant degradation. In 
plaintext you get the full information: brief link text plus the URL. 
With CSS on the web page, we can hide the URL since you'll see it when 
hovering over the link anyway.

> I was thinking of pointing this out somewhere before, if it hasn't
> been already, since text-based browsers (for instance) have the same
> problem. It looks especially ugly for footnote-style links ("[1]" et
> al)

We ought to be producing actual footnotes for footnote-style links, but 
iirc we don't yet.

> and links typed in the form "[http://example.com
> http://example.com]" - although the latter are broken at the moment
> anyway. :-/

That should never even happen -- you'd write just http://example.com.

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list

Re: Pocket Internet Explorer and other handheld devices

Brion Vibber wrote:

>> and links typed in the form "[http://example.com
>> http://example.com]" - although the latter are broken at the moment
>> anyway. :-/
> 
> That should never even happen -- you'd write just http://example.com.

People use the [http://example.com http://example.com] syntax because 
our parser is not intelligent enough to ignore punctuation marks after 
the URL; most commonly the problem occurs with parentheses.

Personally, though, I would very much prefer if every link had a 
sensible link text. While I admit the URL is better than "click here", I 
still think it's pretty lame, and you can *always* find something better.

Timwi

Thumbnails

After discussion with some people (especially Tannin) on the 
en.wikipedia, I propose a few changes (more like additions) to the 
thumbnail function.

Here's the "main proposal":

    [[image:bla.jpg|thumb|some text]] generates a normal thumbnail
    [[image:bla.jpg|thumb=bla_small.jpg|some text]] uses "bla_small.jpg" 
as the thumbnail

This associates the manually created thumbnail with the larger image in 
a machine-readable fashion. It should only be used if the manual 
thumbnail is of significant better quality than the automatic one, or if 
the manual thumbnail shows an alternate view (e.g., only a part) of the 
larger image.

Additionally, the automatic thumbnail generation should be improved:
* Add a little sharpening, at least to photos (.jpg/.jpeg).
* Apparently, automatically generated thumbnails look nicer when they 
are recaled by an exact even number. For example, for a 640x480 image, a 
thumbnail of 200px is requested, generate one with a width of 213px 
instead, as this is a factor of 33.3%, or 1/3. I propose to use a 
variation of up to 10% from the requested width.

If there is no special reason *not* to do this, implementation can start 
soon. At least the "main proposal" should be easy enough to code.

Magnus

Re: Re: __TOC__

> > Thank you! Now I can stop trying to come up with headings for
> > paragraphs that don't need them, just to make the ToC come after the
> > lead-in; it's led to some awfully odd and forced headings... :D
> 
> Are you saying you're going to have unheaded text after the TOC? I
> strongly disagree to that; that is very bad/unprofessional page layout.

Well, I'm not going to go round actively taking headers out, but some
of the articles I've edited have had sections at the beginning which
really defied description - one of them ended up called "Generality",
which really isn't very nice; but, if the ToC sitting in the middle of
unheadered text looks even worse, I shan't use it.

--

-- 
Rowan Collins BSc
[IMSoP]

Re: Re: Pocket Internet Explorer and other handheld devices

> People use the [http://example.com http://example.com] syntax because
> our parser is not intelligent enough to ignore punctuation marks after
> the URL; most commonly the problem occurs with parentheses.

Yes, and I'm 99% sure there used to be a style-guide suggesting people
use this rather than assuming the software would always autolink
plaintext URLs. It seems to have gone now (or I can't find it), and
perhaps it dated to when the software was in the process of being
rewritten or something.

> Personally, though, I would very much prefer if every link had a
> sensible link text. While I admit the URL is better than "click here", I
> still think it's pretty lame, and you can *always* find something better.

Yes, there are a few instances where it's valid - like, in order to
construct a sentence which tells the user what the address is for
future reference, and turns that address into a link at the same time
in case they want to go there right now; but mostly, it's just links
waiting for a decent description.

It's bug #974082, BTW.

> Actually, that's exactly an instance of elegant degradation. In
> plaintext you get the full information: brief link text plus the URL.
> With CSS on the web page, we can hide the URL since you'll see it when
> hovering over the link anyway.

I see your point, but this is information that neither Wikipedia, nor
any other website I can think of, traditionally shows *at all* [even
Slashdot only puts the domain]. People are usually quite happy to let