14 May
2012
14 May
'12
8:58 a.m.
Hi all
I think it is pretty obvious that all themes will share quite big load
of CSS. Originally I though about extracting these bits to Theme class
methods, but now I think it would make things even harder to maintain.
What I feel would be better to create core CSS file, which would be
always included and theme authors will just override/extend it.
This way, we can make changes in core without breaking older themes too
much - maybe some things will not look 100% intergrated, but at least
the layout won't be broken.
Currently original and pmahomme themes share about 2500 lines, they
differ in 1000/500 (pmahomme/original) lines.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
14 May
14 May
9:11 a.m.
On 14/05/12 12:58, Michal Čihař wrote:
Hi all
I think it is pretty obvious that all themes will share quite big load
of CSS. Originally I though about extracting these bits to Theme class
methods, but now I think it would make things even harder to maintain.
What I feel would be better to create core CSS file, which would be
always included and theme authors will just override/extend it.
This way, we can make changes in core without breaking older themes too
much - maybe some things will not look 100% intergrated, but at least
the layout won't be broken.
Currently original and pmahomme themes share about 2500 lines, they
differ in 1000/500 (pmahomme/original) lines.
I mentioned a few days ago that I'm already working on this, thought I
didn't get into details, so here's my plan.
I will merge theme_left with theme_right first (we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
Thoughts?
Bye,
Rouslan
9:42 a.m.
Hi
Dne Mon, 14 May 2012 13:11:16 +0100
Rouslan Placella <rouslan(a)placella.com> napsal(a):
I mentioned a few days ago that I'm already
working on this, thought I
didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after
sending mine :-).
I will merge theme_left with theme_right first
(we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
I think this is really good approach.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
18 May
18 May
7:21 p.m.
On 14/05/12 13:42, Michal Čihař wrote:
Hi
Dne Mon, 14 May 2012 13:11:16 +0100
Rouslan Placella<rouslan(a)placella.com> napsal(a):
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common
CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file,
it will necessary to add the name of the new CSS file (without any
extensions) to the $css_files array in the Theme class so that it can be
picked up and proceesed by PMA.
Bye,
Rouslan
[0]: https://github.com/phpmyadmin/phpmyadmin/pull/67
I mentioned a few days ago that I'm already
working on this, thought I
didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after
sending mine :-).
I will merge theme_left with theme_right first
(we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
I think this is really good approach. 
19 May
19 May
1:44 p.m.
Hi,
2012/5/19 Rouslan Placella <rouslan(a)placella.com>om>:
On 14/05/12 13:42, Michal Čihař wrote:
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC
and on the demo server), but I don't know if this was caused by your
commit.
Kind regards,
Dieter
Hi
Dne Mon, 14 May 2012 13:11:16 +0100
Rouslan Placella<rouslan(a)placella.com> napsal(a):
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common
CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file,
it will necessary to add the name of the new CSS file (without any
extensions) to the $css_files array in the Theme class so that it can be
picked up and proceesed by PMA.
Bye,
Rouslan
[0]: https://github.com/phpmyadmin/phpmyadmin/pull/67 I mentioned a few days ago that I'm already
working on this, thought I
didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after
sending mine :-).
I will merge theme_left with theme_right first
(we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
I think this is really good approach.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Kind regards,
Dieter Adriaenssens
2:03 p.m.
On 19/05/12 17:44, Dieter Adriaenssens wrote:
Hi,
2012/5/19 Rouslan Placella<rouslan(a)placella.com>om>:
Yes, it's clearly caused by my last commit in that branch.
That said, I'm not sure how to fix it right now.
Bye,
Rouslan
On 14/05/12 13:42, Michal Čihař wrote:
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC
and on the demo server), but I don't know if this was caused by your
commit. Hi
Dne Mon, 14 May 2012 13:11:16 +0100
Rouslan Placella<rouslan(a)placella.com> napsal(a):
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common
CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file,
it will necessary to add the name of the new CSS file (without any
extensions) to the $css_files array in the Theme class so that it can be
picked up and proceesed by PMA.
Bye,
Rouslan
[0]: https://github.com/phpmyadmin/phpmyadmin/pull/67 I mentioned a few days ago that I'm already
working on this, thought I
didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after
sending mine :-).
I will merge theme_left with theme_right first
(we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
I think this is really good approach.
2:19 p.m.
On 19/05/12 17:44, Dieter Adriaenssens wrote:
Hi,
2012/5/19 Rouslan Placella<rouslan(a)placella.com>om>:
Fixed in git now.
Bye,
Rouslan
On 14/05/12 13:42, Michal Čihař wrote:
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC
and on the demo server), but I don't know if this was caused by your
commit. Hi
Dne Mon, 14 May 2012 13:11:16 +0100
Rouslan Placella<rouslan(a)placella.com> napsal(a):
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common
CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file,
it will necessary to add the name of the new CSS file (without any
extensions) to the $css_files array in the Theme class so that it can be
picked up and proceesed by PMA.
Bye,
Rouslan
[0]: https://github.com/phpmyadmin/phpmyadmin/pull/67 I mentioned a few days ago that I'm already
working on this, thought I
didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after
sending mine :-).
I will merge theme_left with theme_right first
(we'll only have one
frame in 4.0). Then split the resulting file into smaller files, e.g.:
common.css, pmd.css, gis.css, rte.css, etc...
The idea here is to make the css files more managable, right now it
looks to me like everyone just appends new stuff at the bottom of our
huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single
file by the Theme class at run time and sent to the browser along with a
cache header.
As far as the code duplication goes, the idea is to make all of the new,
smaller, css files overridable. So only the default theme will include
all the css files and if another theme is selected and it, for example,
only has a common.css file, all the other files will be included from
the default theme.
I think that this approach will both minimise code duplication and
improve the maintainability of CSS files.
I think this is really good approach.
4494
days inactive
4499
days old
6 comments
3 participants
participants (3)
-
Dieter Adriaenssens -
Michal Čihař -
Rouslan Placella