Re: [RFC/PATCH 2/8] docbook: improve css style

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 24, 2009 at 12:39 PM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
> Felipe Contreras venit, vidit, dixit 24.03.2009 10:06:
>> On Tue, Mar 24, 2009 at 10:29 AM, Michael J Gruber
>> <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Felipe Contreras venit, vidit, dixit 24.03.2009 01:21:
>>>> On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
>>>> <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>>> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>>>>>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@xxxxxxxx> wrote:
>>>>>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>>>>>
>>>>>>>>  tt.literal, code.literal {
>>>>>>>>    color: navy;
>>>>>>>> +  font-size: 1em;
>>>>>>>> +}
>>>>>>>
>>>>>>> Isn't 1em already the default size? Or are you trying to override some
>>>>>>> other size specification elsewhere? It's hard to tell what the goal is
>>>>>>> because your commit message merely says "improve".
>>>>>>
>>>>>> That's correct.
>>>>>>
>>>>>> The problem is that when the user has a different size for the
>>>>>> sans-serif and monospace fonts it looks horrible when they are on the
>>>>>> same paragraph. I thought 1em did the trick, but you are right, it
>>>>>> doesn't.
>>>>>>
>>>>>> It looks like the only way to fix this is to set absolute sizes.
>>>>>>
>>>>>
>>>>> Also, it seems that everything which is not black is blue, except for
>>>>> terms, which are green and slanted. I don't think that looks nice
>>>>> together. How about slanted blue?
>>>>
>>>> What's wrong with having 2 colors?
>>>
>>> I don't mind having 2, they just don't look good together over here, on
>>> my screen and to my eyes...
>>>
>>> Right now we have "plain old asciidoc look" which doesn't look that old
>>> after all. You pointed out a deficiency, and I'm all for fixing it. I
>>> just think that introducing new colors is something that may require a
>>> ground up rethinking of the theme being used: make it informative but
>>> unobtrusive. Also, I'm against over-emphasizing: use slanted or a
>>> specific color, but not both. Unless one color means emphasizing and
>>> slanted means file, for example.
>>
>> Take a look at:
>> http://people.freedesktop.org/~felipec/git/user-manual.html#bisect-merges
>>
>> Do you think slanting Z (and the other characters) is enough to emphasize it?
>>
>
> In that case I actually don't know why to emphasize the commit names at
> all. (And not all are emphasized.) If it's about distinguishing upper
> case letters from commit names, i.e. denoting the latter as variables,
> then slanting them suffices.
>
> I don't wnat to complicate thos or blow this up or anything, but (as I
> pointed out in another thread) we need a style guide first, something like:
>
> - Write commands in backticks.
> - Write arguments (appearing apart from the command) in backticks.
> - Write paths as 'path'.
> - Write quotation in ``quotation''.
> - Write commit names as ?
>
> Then, after having the semantic markup distinction (which we don't have
> right now) <snip/>

That's exactly what my patches are trying to do. Since asciidoc
doesn't have that many distinctions I followed a slightly more general
guideline; if 'foo' is not distinct enough, then do '"foo"'. In some
places I was lazy, so I did 'Z' instead of '"Z"', but again, this is
only RFC.

After a bit more thinking I think some long texts like
remote.<name>.url should also be '"remote.<name>.url"'.

Also, you cannot apply a general rule, like 'all commands should have
backticks'. Some command are meant to be emphasized while others have
been repeated so often that it doesn't make sense. The same applies
with links.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux