corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: svn commit: r1649986 - /incubator/corinthia/www/index.html
Date Wed, 07 Jan 2015 12:54:23 GMT
I think that given the early state of the project website we should be focusing on the content
and set of pages we present, not fiddling with layout. This is simply bikeshedding, which
I’m seeing a lot more than I’d hoped for so far in the mailing lists.

How about we concentrate on important things like:

- Writing an ODF filter
- Instructions on how to build and work with the existing codebase (including coding style,
workflow, and architecture discussion)
- A detailed set of goals we hope to achieve with the project (the proposal is a start, but
nowhere near what we ultimately need)
- Based on the detailed set of goals, figure out what functionality we want to expose from
the API

My vote is to to have Dorte take responsibility of the design aspects (it’s certainly not
my area of expertise), and for us to concentrate on the content and mission of the project.
Arguments over font sizes and line endings seem like the least important aspects of the project
I could imagine.

Dr Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

> On 7 Jan 2015, at 7:15 pm, Andrea Pescetti <> wrote:
> On 07/01/2015 jan i wrote:
>> Having now studied your patch, I have 3 questions:
> I suggest to set Reply-To for the commits list to dev and assume that people who subscribe
to commits read dev and that all mails to commits are automatically originated.
>> - Is it on purpose you changed all lines in the file....that is kind of
>> very brutal.
> This is just due to broken line ending detection.
shows it correctly, it's one line.
>> - Why only change one file, this effect is on all pages.
> This is correct, but maybe the problem is with repeating the same footer across all pages
by copy-paste. Anyway yes, it's surely better to enforce consistency of the footer if we have
no technology to include it automatically (but at the very least I expect that SSI is enabled).
>> - What is the urgency, that needed a "brute force fix" instead of doing it
>> correct
> Actually this is kind of the right way to do it. I mean:
> - Changing the Foundation files is a no-go. You want to be able to update to a newer
version of the framework. So what Dennis thought to be the "right way" is not the right way
at all: Foundation files are to be considered read-only.
> - Overriding default settings with a custom CSS file loaded after the default ones is
what you should do and what I recommend as a good practice, even though I never played with
> - Missing that, inline styles are an acceptable trade-off.
>> It breaks the responsive design.
> No it doesn't, since it does not make changes that are relevant for the box model. This
is true of this particular case only, of course.
> By the way, I started fixing it yesterday but then saw Dorte's mail and stopped. Anyway,
if you modify line 83 at the link above from
> <div class="row">
> to
> <div class="row columns">
> you solve the margin problem Dennis was unhappy with. But I didn't have time to check
whether this is semantically the best solution.
> Regards,
>  Andrea.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message