Layout adjustment for i18n compatibility.

chrome/browser/resources/options/options_page.css

Index: chrome/browser/resources/options/options_page.css
diff --git a/chrome/browser/resources/options/options_page.css b/chrome/browser/resources/options/options_page.css
index 932eded11531571666521a8d0d1879901df1abf6..e8e85e174559cccc094c0b3c3d1c84e955c251ac 100644
--- a/chrome/browser/resources/options/options_page.css
+++ b/chrome/browser/resources/options/options_page.css
@@ -353,6 +353,7 @@ html.hide-menu #mainview {
   min-height: 192px;
 }
 

[Rick Byers, 2011/06/03 15:06:07]

Why the extra newline here and below?

+
 section {
   -webkit-box-orient: horizontal;
   border-bottom: 1px solid #eeeeee;
@@ -361,6 +362,7 @@ section {
   padding-bottom: 20px;
 }
 
+
 div.page section:last-child {
   border-bottom: none;
 }
@@ -777,3 +779,55 @@ html:not([flashPluginSupportsClearSiteData]) .clear-plugin-lso-data-enabled,
 html[flashPluginSupportsClearSiteData] .clear-plugin-lso-data-disabled {
   display: none;
 }
+
+
+/* Display a collection of sections as a table in order to display nicely
+ * in multiple locales.  The left column should expand to accomodate the 

[Rick Byers, 2011/06/03 15:06:07]

Remove trailing whitespace at the end of this line and next (unfortunately
rietveld doesn't highlight this - use git diff to see it).

+ * widest label without introducing excessive whitespace.  Labels in 
+ * languages such as German or Dutch tend to be wider than for English */

[Rick Byers, 2011/06/03 15:06:07]

move */ to a new line like the comments above

+.displaytable {
+  display: table;
+  width:100%;

[Rick Byers, 2011/06/03 15:06:07]

space after :

+}
+
+.displaytable > section {

[Rick Byers, 2011/06/03 15:06:07]

Are all sections now inside a displaytable?  Or are there still some cases where
you haven't put sections inside of tables.  If your goal is to reformat all
options to use your table layout, then I'd find it cleaner if you integrated
these rules into the rules above rather than just append a bunch of rules
qualified on .displaytable.  For one thing, descendent selectors apparently add
a significant perf overhead (I believe our style guide says to minimize the use
of them as a result).  But more generally, the fewer new CSS rules we have to
add the simpler and more understandable the code is.

[kevers1, 2011/06/03 18:45:44]

The pages within 'toplevel-page-container' have been updated to put the sections
inside of 'displaytable'; however, there is still a fair number of pages that
contain sections without the 'displaytable' wrapper.  For now, we need a
specialized rule.

[Rick Byers, 2011/06/04 18:49:45]

I see - thanks.

+  display: table-row;
+}
+
+/* left table column containing section label */
+.displaytable > section > h3 {

[Rick Byers, 2011/06/03 15:06:07]

Again this seems somewhat redundant with the section > h3 rule above.  If you
really do need to handle ".displaytable > section > h3" differently from other
"section >h3" elements, then you should at least try to avoid redundancy.  Eg.,
it looks like font-weight:bold is redundant - it'll pick it up from the above
(more general) rule, so there's hopefully no need to respecify it here.

+  display: table-cell;
+  vertical-align: baseline;
+  font-size: 105%;
+  font-weight: bold;
+  width: 130px;
+  -webkit-box-flex: 1;

[Rick Byers, 2011/06/03 15:06:07]

Does this actually do anything for display: table-cell?  I thought
-webkit-box-flex only applied to display: -webkit-box

+  padding-right: 10px;
+  border-bottom: 1px solid #eeeeee;

[Rick Byers, 2011/06/03 15:06:07]

I'm hoping also that it's not necessary to respecify the border.  If we want to
change the color of this rule some day, there were previously only one or two
places we had to change it, now there are 2 more.  Can you avoid repeating this?

[kevers1, 2011/06/03 18:45:44]

Ideally, the border would be specified on the section; however, border does not
work with 'display: table-row'.

[Rick Byers, 2011/06/04 18:49:45]

Ah, I see - that's too bad.  Then can you at least combine the rules to avoid
the redundancy?  Eg. you should just be able to have two rules with multiple
selectors describing the border for both the table and non-table cases - maybe
something like:

section,
/* Note: borders are ignored on display:table-row, so we need to re-apply to the
table-cell */
.displaytable > section > * {
  border-bottom: 1px solid #eeeeee;
}

div.page section:last-child,
.displaytable > setion:last-child > * {
  border-bottom: none;
}

It's also fine to explicitly list the children of section as you are now if you
want - I'm not sure whether using the universal selector ('*') is better or not
- just seems simpler/shorter to me.

It you want to avoid combining the table and non-table rules for now (since
they'll eventually be merged) then that's OK too - just merge all your rules so
you're only specifying the border one additional time instead of two.

+}
+
+
+.displaytable > section > h3.centerAlign {

[Rick Byers, 2011/06/03 15:06:07]

What does this affect? Perhaps I missed it, but I don't see any elements
anywhere with a class of "centerAlign"

[kevers1, 2011/06/03 18:45:44]

Rule reumoved

+  vertical-align: middle;
+}
+
+
+/* right table column containing settable options */
+.displaytable > section > h3 + div,
+.displaytable > section > h3 + table {
+  display: table-cell;
+  vertical-align: baseline;
+  padding-top: 17px;
+  padding-bottom: 20px;
+  border-bottom: 1px solid #eeeeee;

[Rick Byers, 2011/06/03 15:06:07]

Again - would be better if you can avoid repeating the border.  This wasn't
necessary before, why is it necessary now?  Doing this also forces you to add
the rules below, which would ideally already be covered by the single general
border-bottom: none rule on line 367.

+}
+
+/* do not display a border after the last section in the table */
+.displaytable > section:last-child > h3,
+.displaytable > section:last-child > div  {
+  border-bottom: none;
+}
+

[Rick Byers, 2011/06/03 15:06:07]

Remove 4 trailing new-lines

+
+
+