corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: svn commit: r1649986 - /incubator/corinthia/www/index.html
Date Wed, 07 Jan 2015 16:57:35 GMT
On 7 January 2015 at 17:44, Dennis E. Hamilton <dennis.hamilton@acm.org>
wrote:

> I apologize for the line-ending issue.  I knew about it and then forgot
> to see if my current SVN configuration needs to be changed.  It does.
>
>  -- replies inline to --
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Wednesday, January 7, 2015 04:15
> To: dev@corinthia.incubator.apache.org
> Subject: Re: svn commit: r1649986 - /incubator/corinthia/www/index.html
>
> On 07/01/2015 jan i wrote:
>
> > - 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).
>
> <orcmid>
>   Yes, the footer is apparently copy-pasted to all pages.  I fixed only
>   the main page because I wanted to see it working properly and I hoped
>   someone could tell me a better way to do it.
>

Have some of you ever seen what CMS systems does (look at AOO pages), the
CMS system does exactly copy/paste of the template to all pages. Using
templates in CMS is nice when you are  in editor mode, but when you look at
the HTML it is copy/paste, and awful to maintain.

Luckily foundation offer a "real" template, where it is NOT copied onto
every page, but the backdraw is that there are more include statements
which gives a longer load time. I happen to know that dorte is
experimenting with this, but from what I have seen it does not pay off,
when you have 5-6 pages.


> </orcmid>
>
> > - 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 Foundation.
> - Missing that, inline styles are an acceptable trade-off.
>
> <orcmid>
>   I had no intention of changing foundation files.  By right way I meant
>   finding out whatever foundation provides that will handle this case.
>   I could not find a clue by scanning through those mind-numbing CSS
>   Files so I did something different that did not touch the foundation
> files.
>   I also notice that our site does not follow the foundation
> recommendation to
>   have an app.cs file for site-specific customizations so I assume there
> are
>   none.
>
That is because at this point of time there are no app specific style sheets


> </orcmid>
>
> > 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.
>
> <orcmid>
>   It appears to be the case that line-height adjustment has no effect
>   on small form factors, and I have no idea why.
>
I know....and I assume you saw that before you committed the change, when
you tested the file.

But having seen it does not have the wanted effect, having read my
explanation why it breaks the design, I hope you will follow my polite
request.

Please remark I am not pushing here, the choice is yours and yours alone!
If you agree with my assessment then it should be reverted, if not you
should leave it in.

rgds
jan i.


>
> 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.
>
>

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