grids spacing wrong without Arial on pure-g, pure-g-r

[adapterik]

This was reported on yui3 grids and still exists (http://yuilibrary.com/projects/yui3/ticket/2533215.) The summary is that the letter spacing = -0.31em hack placed on the pure-g[-r] class to make the grid units work well only works (well) if the font family is Arial. It may appear to work for other font families (pure sets the font family for the html tag to sans-serif), but the spacing is not perfect, and it breaks down in certain browsers (atm it fails on FF/Linux for me.) The general solution is ensure that the pure-g and pure-g-r divs get Arial, and that your own content within the pure-u-x-x divs get whatever font you want (so I guess that means resetting back to sans-serif for pure compatibility.) My interrim solution is to add css like this

.pure-g, .pure-g-r {
    font-family: Arial;
}

in my own css file loaded after pure, and also either resetting the font for all the pure-u-x-x

.pure-u-1, .pure-u-1-2, ...
    font-family: sans-serif;
}

or using a container (which I always do anyway) inside the pure-u-x-x which sets the font (and does other as well.)

I think the best solution is to handle the pure-g, and pure-u stuff inside of pure.

[rmasters]

I'm experiencing this issue as well - even without custom fonts - on Google Chrome 27.0.1453.94 m (Windows), pure (all) 0.1.0

An example with tables: http://jsfiddle.net/yQHzr/

[adapterik]

Hi rmasters, What you are seeing is the effect of the "letter-spacing: -.31em" hack. It is supposed to affect just the "pure-u-1" and "pure-u-x-x" unit classes since it is set in "pure-g" and "pure-g-r" grid container classes. Each letter is backed up by 0.31em. The unit classes undo this by setting "letter-spacing: normal", so when you place content in a unit class div you don't see this at all.. Seeing squashed text like that means there is not a valid unit unit class between your content and the grid class. In your case, this is because "pure-u-1-1" is not a valid unit class -- you want to be using "pure-u-1" instead. I used to run into this from time to time during development, and it drove me crazy until I discovered why. It was usually due to malformed html. I think this should be highlighted in the grid documentation.

[ericf]

@msweeney Would you be able to look into this?

[msweeney]

@adapterik Can you provide a pointer to your specific issue? I am unable to reproduce the issue on the ticket you mention when running the jsfiddle frame source standalone.

Here's the source I've plucked from the jsfiddle iframe: https://gist.github.com/msweeney/5686514. Are you seeing the issue here? If not, can you tweak the gist to force it?

[msweeney]

@adapterik NM, I am able to reproduce with verdana.

While the proposed solution is a fine workaround, breaking font inheritance within units is a showstopper for rolling it into grids.

I'll try and come up with a cleaner solution.

[adapterik]

@msweeney Here is a gist demonstrating the issue with Pure: https://gist.github.com/adapterik/a7eace0083987d004682

Without moving off of my chair, I can reproduce the problem on FF 21 / Linux; it is not present on current Chrome / Linux.

Since Pure grids are by and large the same as YUI3 grids, the comments from the bug report I had referenced are relevant.

Can you explain why font inheritance for units is important? I thought that, for one, the best practice for using grids is to provide a content wrapper inside of units, with the purpose of providing font characteristics, padding, gutters, etc.

[msweeney]

@adapterik OK, thanks. Apparently your issue is limited to FF Linux.

Breaking font inheritance is important because generally a page level font is set that inherits to all elements on the page. Forcing users to also set the font for content within units is not the same as the non-inherited properties you mention.

[msweeney]

Currently I can reproduce this issue reliably by using verdana.

I've pushed a branch to my fork that uses ex units rather than em, which resolves the issue, for verdana at least, without negatively impacting sans-serif: https://github.com/msweeney/pure/tree/unit-spacing

@adapterik I'm lacking a Linux test environment. Can you try my branch and see if that resolves your issue?

Or add the following to a style block on your test page (after the grids.css include):

.pure-g {
    letter-spacing: -0.69ex;
}

[adapterik]

@msweeney This does work if the global (on html) font is Verdana, but not universally -- e.g. Courier. I think the best solution would be to address it head-on: The proportion -0.31 is designed to work on a universally available font with specific metrics. If it is applied to any other font the results cannot be ensured. I imagine other universal fonts will have similar predictable metrics, so for some common subset it may be possible to fiddle with the letter spacing to make it mostly work. I wouldn't hazard to guess what would happen in the mobile browser world.

One reason I would even suggest hard coding a font into pure-g and pure-u is that Pure already does this -- not only html, but button, input, select, and textarea all have sans-serif explicitly set. And the css generated by the skin builder includes at least two hard coded font family settings. So it would seem to fit into the "opinionated" nature of Pure to fiddle with the fonts directly. I would think it well within the purview of a web developer using Pure and YUI to have a few lines of CSS to override the font. Really it would just be adding all the pure-u classes the the css statement that already would be present to override html, button, input, etc. That could even be generated by the skin builder if it had a setting for the font.

[msweeney]

@adapterik Thanks for testing and the Courier feedback. At this point I am looking for a solution that is flexible enough for common fonts without the heavy handedness of your proposal.

Normalize applies the font to the HTML, but this (or BODY) is where the global font would be normally be applied, so the "opinion" is really a default. Ditto for the other elements you mention, which will never contain children so the inheritance is a non-issue there. Breaking global font inheritance and forcing developers to set a font-family on grid units goes too far in my opinion.

[adapterik]

@msweeney No problem. I really appreciate you taking the time to address this.

Maybe in addition to whatever solution you come up with there could be documentation on how to solve this problem by hand. It does seem rather inherent to this technique. For comparison, I also use YAML, which uses floats for grid, and it specifies what and why you need specific classes to solve problems with that approach. As it is now, it is not hard to override the pure-g and pure-u css to make this work.

re: my "opinion" slant -- I was really just bouncing off of something I read in the Pure docs or the blog which joked that Pure was gently opinionated. And re: the font applied to HTML et al., it is really just to note that for true global reset of font, you have to know what Pure/normalize are doing already. And this may just be me, but compared to the complexity of the css, html and javascript for a typical website using YUI or Pure grids,the extra code to set the font inside a grid unit doesn't seem so heavy.

Another possible solution would be for Pure and skin builder to produce less files? Global defaults like font, colors, border radius, etc. can be modified locally. No need, really, to set defaults only to override them later.

[msweeney]

@adapterik Sure, no problem.

I agree that a preprocessor would be better for handling defaults and customization in general and think we should move to that model, however we still need to provide robust pre-built solutions.

We should consider using layout techniques other than inline-block when possible (flex, table) and make grids more robust in general.

[rmasters]

@adapterik Thanks for spotting that, it's been driving me mad!

[SiNNuT]

Apparently it is not hard to fall into the trap that causes squashed text because the Grid builder page, that is linked to from purecss.io shows exactly this behaviour :)

https://github.com/yui/gridbuilder/issues/13

[visionmonster]

you can just remove the space in-between the elements that have the class="pure-u-*" on them since it's the line-break that is causing you to need to use the letter-space trickery.

works:

monospace

monospace

doesn't work:

monospace

monospace

here's a fiddle http://jsfiddle.net/visionmonster/9yxNY/

This works in IE10, IE10 in IE7 mode, OSX safari 6, OSX FF21, OSX chrome 28, TouchPad, iOS 6.

I had played around with setting the font-size to 0 on the pure-g div and then setting it to 1rem on the pure-u-* elements like:

.pure-g{ font-size:0; font-size:1em; letter-spacing: normal; word-spacing: -0.43em;
} .pure-g > *{font-size:1rem;}

but this method feels much more fragile; fiddle's here: http://jsfiddle.net/visionmonster/qeKp3/

[adapterik]

Hi @visionmonster, thanks for your input. If only the the font-size: 0 fix worked universally, or rem were support was deeper.

There are several articles and follow up discussion storms on this topic where many possible solutions have been aired to the "remove space between inline-blocks". E.g.

http://www.vanseodesign.com/css/inline-blocks/

Most methods, including the 0 font size, do not work universally. If a method doesn't work across the swath of YUI supported browsers and platforms, it can't be used. However, as your method and YUI's show, there can be ways to selectively apply css hacks. However, it is such a delicate balancing act that introducing changes or a new solution can easily have unintended consequences. (Witness this bug report!)

The docs inside of pure or css grids explains the tweaks pretty well and shows the value of relying on the collective experience accreted in a well-vetted solution:

https://github.com/yui/pure/blob/master/src/grids/css/grids-core.css

I'm quite sure that removing spacing between pure-u-* units would not be favored since a grid is usually interlaced within a fairly complex page. It is so much easier to maintain html if it is indented in a regular fashion and multiple hands touching it would surely break it at some point. I think the spacing solution is more popular with folks doing small sections of inline-block, e.g. menus.

[julienlz]

Hello, it fails for me on Chrome for Android (Nexus 7) with Georgia font, the grid is broken. Same thing at purecss.io on 3 columns.

.pure-g {
    letter-spacing: -0.69ex;
}

this trick don't work, the only thing i can do is detect chrome/android and reset Arial font

if (navigator.userAgent.match(/(Android)/i) && window.chrome) 
$('.pure-g, .pure-g-r').css('font-family','Arial');

[adapterik]

Hi @julienlz, a few things.

The letter-spacing: -0.69ex; hack is not going to be a reliable fix. It will suffer the same problem as the -0.31em one, but the metrics being slightly different, will behave ... slightly differently.

Also, I wouldn't recommend that you spot-fix the problem with browser sniffing like that. For one, browser sniffing is not reliable, and if you discover more cases you'll need to keep adding to it. Secondly, why not just fix the problem for all browsers? And why not fix in css? With js, it is possible that you will get a flash of broken grid before it is fixed.

Finally, I think you should reset the font for the pure-u* as well. In many cases the Arial font may end up being the same as sans-serif and you won't notice the difference. But you'll have problems if you have set a specific font in the web app, or the Arial and sans-serif don't map to the same font.

Good luck and thanks for contributing this -- hopefully it will be fixed soon.

[trnelson]

I think this is the same issue, but I've noticed that with two divs side-by-side (i.e. a pure-u-1-3 and a pure-u-2-3) if I use a Google font, it drops the second div below the first. Assuming this has to do with a width change on the second div of some sort. My CSS is as follows:

@import url(http://fonts.googleapis.com/css?family=Arvo|Sanchez);
body {
    font-family: Sanchez, Georgia, Times New Roman, Serif; /* <----- THIS FONT */
}

[leo-unglaub]

This also affects #119

[ericf]

Here's an interestion solution from @jonathantneal which uses a custom web font: https://github.com/jonathantneal/layout-webfont

[adapterik]

@ericf interesting -- but still carries the fundamental issue that the inner inline-block unit needs to have the font family reset explicitly. Also if Arial or substitutions have stable, cross-browser, cross-platform metrics so that a space is 0.31em, is there a need to introduce another dependency?

[trnelson]

To get around the issue I was able to assign the font-family declaration to the individual containers (as opposed to the full body tag) and that seemed to work in my scenario. In the end I actually ended up using another framework, for completely different reasons. I'm really looking forward to using Pure again soon though!

[jonathantneal]

Came here from @ericf. I'll point out the obvious. If you use inline-block layouts, you'll need to redeclare styles, and there are other caveats.

If you use a custom webfont, or any non-monospace font, or letter-spacing, or word-spacing, then the -.31em solution will create a conflict, and you will need to redeclare the custom font family or letter spacing or word-spacing on children of the layout. IMO, this option is the worst, as it presents the most variables.

If you use a custom webfont, then the layout font solution will create a conflict, and you will need to redeclare the custom font family on children of the layout. Also, most browsers delay loading the web font, which causes an unacceptable, momentary shift in the layout. IMO, this option is almost as bad as the previous solution, but there are less consequences.

If you use a custom fontsize, then the font size 0 solution will create a conflict, and you will need to redeclare the custom font size on children of the layout. I've heard certain Android devices may have an issue with this. IMO, this option is the best, as it presents the least variables.

[tilomitra]

@jonathantneal With the font size 0 solution, how do you recommend resetting the font-size for IE6/7/8? 1rem won't work.

I agree that the font-size solution requires the least variables. I will check to see if this works on Android 4.0+, since that's what Pure supports.

[jonathantneal]

@tilomitra

My work-around for the font size 0 solution is the same for all three solutions I described.

<div class="stack">
    <div class="panel">hello world</div>
</div>

If .stack zeros out the font-size, and .panel is inline-block, then you'll need to redeclare the font-size on .panel. I do this by using multiple selectors to assign the font-size both in and outside of the layout.

.stack { font-size: 0; }
.panel { display: inline-block; }
body, .panel { font-size: 16px; }

[MilesWilford]

I tested this on my Android devices and wanted to contribute what I found. I'll put up full-resolution screenshots.

In Chrome for Android, the grid is entirely dysfunctional:

The problem is identical when tested in the 4.0.3 AOSP Browser.

In the 4.2 Browser, gaps can sometimes show up as well:

What's the advantage of this inline-block and negative text spacing approach over a more typical clearfixed float approach?

[adapterik]

@MilesWilford did you try applying the various css fixes described?

[MilesWilford]

They work to varying degrees of effectiveness, but the underlying problem is still there - the hack to get rid of the displayed whitespace between the inline block elements is still basically running on a magic number. Is there an advantage to this approach versus a more typical float: left in a clearfixed container approach?

[adapterik]

I'm sure someone will have a more definitive answer, but ...

There are certainly advantages in general to using inline-block, such as alignment. The CSS to support Pure grids is very simple and easy to understand. And it could be argued that inline-block is less of an abuse, requires fewer workarounds, for grid-like layout than float does. In my experience inline-block is more useful than float for a variety of applications (menus, button bars, etc.). If the sole argument against inline-block is the space between elements, that can be fixed without any hacks by simply removing the space, like </div><div class='pure-u-1-2'>.

In any case, once a css framework has worked out the kinks, they all seem to work well enough. YUI3/Pure has taken this approach, but there are plenty of others out there. One day there will be true css grid support in all relevant browsers, and we will fondly reminisce about these discussions ...

[msweeney]

@MilesWilford The advantage of inline-block over float is that it avoids the side-effects that come with using float for layouts. Most notably, this allows grid units to be horizontally and vertically aligned.

[Perturbatio]

I'm probably not entirely understanding this issue, but isn't it solved by simply setting the grid letter spacing to a larger negative number? i.e. -2em since the unit letter spacing is reset to normal, it shouldn't matter that this is extremely large, just that it's larger than any likely gap.

[adapterik]

If you set it larger you'll actually get the inline-block units backing up over each other! To remove the space between inline-grid units, the letter spacing needs to be precisely (as possible) the negative of the width of a space, which for Arial is -0.31em.

[renaudleo]

This is indeed a problem, but it can be solved quite easily by setting the font-family to Arial on .pure-g elements and resetting it to your default font-family in the column wrappers (.pure-u-1-2, .pure-u-1-3, etc).

Most likely, you are not using more than a couple of different font families, so it should be quite easy to choose a default font-family to reset to. It's quite harder to do the same with font-size when you're using the font-size: 0 trick. I've been working with both and would never go back to using font-size: 0 again.

So, basically, you would have something like this:

body {
  font-family: OpenSans;
}

.pure-g {
  font-family: Arial;
}

.pure-1-2,
.pure-1-3,
.etc {
  font-family: OpenSans;
}

Obviously, it would be easier resetting your default font-family with a preprocessor, but that doesn't matter very much.

That being said, I think Pure core should include the font-family: Arial rule on .pure-g, since the letter-spacing: -.31em was designed to work with Arial in the first place. It would assure the grid system doesn't break, and enforce people using it to redefine the font they want to use.

Whether or not the font-family: Arial rule is included in the core, a small "Using custom fonts" section in the README would probably go a long way.

[adapterik]

@tilomitra oh why did you advise him to use a letter spacing of -0.61em and not with the solution posted here? His setting the font-family on pure-g, expecting it to be inherited by enclosed content, is not a good thing to do. Other than the specific issue we are batting about here, the advice stemming from yui-grid days is that aesthetic styling should be provided by a container within a unit, leaving the grid container and units to do just their grid work. That has always worked for me.

[tilomitra]

@adapterik Are you referring to the </div><div class='pure-u-1-2'> solution (clearing the HTML space)?

[adapterik]

Hi @tilomitra - good point. I was really referring to the letter-spacing: -0.31; + font-family: Arial solution, but you are correct that removing the textual space between the closing div of one unit and the opening of the next is the absolute most correct way to fix this. Inconvenient, especially if you are used to reformatting your markup (which typically introduces a line break and possibly tabbing or spaces between a closing div and the next opening one.)

Of course, both methods can be used. The letter spacing + font-family solution will ensure that any spaces introduced are handled but removing the space will ensure that any font metric irregularities don't mess up the grid.

[Perturbatio]

Could something be done using white-space? i.e. white-space: nowrap on the grid and white-space: normal on the units?

[renaudleo]

Using white-space: nowrap will only prevent elements that are supposed to be in the same row to break on multiple rows by forcing them to overflow horizontally. But the space between columns will still exist, and will be noticeable, especially if you have a background on your pure-u-* elements.

The problem can also happen the other way around. You could use a smaller font than Arial and end with negative spacing between your columns. Word-wrap won't help here neither.

[tilomitra]

If you guys have been following the PRs on this, you may have known that we decided not to fix this in Pure, because there's not a single solution that works in every scenario. By solving this for some people, we risk making grids harder to use and understand for other folks who aren't having this issue. Refer to https://github.com/yui/pure/pull/147 for the various options that we considered.

Now the good news...

Fortunately, the workaround for this is very simple. We're improving the grid documentation to outline this workaround. Here's the pull request for that: https://github.com/yui/pure-site/pull/149

I'll leave this open for now, but I'll close it once the site is updated with the workaround.

PS: The solution that we are proposing is a font-family fix. If you're using a custom font, and you see the grid breaking (the last column goes to a new line), you need to do 2 things:

• Set a font-family of "arial" on pure-g and pure-g-r.
• Define your custom font within the grid units

Here's what I mean:

/* Putting the font-family to Arial makes sure the
letter and word spacing collapsing works */
.pure-g,
.pure-g-r {
    font-family: "Helvetica", "Arial", sans-serif;
}

/* Declaring the font-family on the children ensures
that the grid doesn't flow to a new line. */
.pure-g [class *= "pure-u"],
.pure-g-r [class *= "pure-u"] {
    font-family: "YOUR_CUSTOM_FONT";
}

[adapterik]

If there is no fix within Pure grids, -- there are simpler workarounds than the documented one. For instance, you can avoid all fiddling with Pure grids altogether if you wrap the entire grid in a div which sets the font-family to Arial and uses a div unside units to wrap content. Something like

<div class="grid-wrapper">
  <div class="pure-g">
    <div class="pure-u-1-2">
      <div class="grid-content">
         hello
      </div>
    </div>
    <div class="pure-u-1-2">
      <div class="grid-content">
         world
      </div>
    </div>
</div>

where css includes

.grid-wrapper {
  font-family: Arial, sans-serif;
}
.grid-content {
  /* Whatever I want */
  font-family: Times, serif;
}

The grid-wrapper class could also be applied to a pure-g[-r] div as well as was discussed in #147. Having it encapsulate the entire grid is a bit more friendly with templating and big pages with nested grids.

In fact, a variant of this could be folded into Pure. The Pure part would just be the grid uberwrapper -- optional if you want to live dangerously. Having it defined in Pure would be great, though, because it would represent a tested best solution for the grid geometry, regardless of what the user does inside of the grid units.

[ericf]

@adapterik I think this might be the right balance of what to add in Pure and what to document on the website. We aren't afraid to tell people who use to Pure that they are still going to write CSS, and this introduction of two additional classnames seems good.

This is my riff on your idea showing both nesting and wrapping vs. using directly on pure-g and pure-u elements:

<div class="pure-g-wrap">
    <div class="pure-g">
        <div class="pure-u-1-2">
            <div class="pure-g-content"></div>
        </div>

        <div class="pure-u-1-2">
            <div class="pure-g-content"></div>
        </div>
    </div>

    <div class="pure-g">
        <div class="pure-u-1-2">
            <div class="pure-g-content"></div>
        </div>

        <div class="pure-u-1-2">
            <div class="pure-g-content"></div>
        </div>
    </div>
</div>

<!-- OR -->

<div class="pure-g-wrap pure-g-r">
    <div class="pure-g-content pure-u-1-3"></div>
    <div class="pure-g-content pure-u-1-3"></div>
    <div class="pure-g-content pure-u-1-3"></div>
</div>

In pure.css:

.pure-g-wrap {
    font-family: Helvetica, Arial, sans-serif;
}

In app.css:

body,
.pure-g-content {
    font-family: "Courier New", Courier, monospace;
}

[msweeney]

Why complicate the workaround with HTML requirements when it can be easily accomplished with CSS?

[ericf]

True…I thought this would be a decent balance between using HTML and CSS. But I guess it is using HTML to fix a CSS issue :-/

[adapterik]

To follow this crazy vein further -- what if the "normalizing" code (which undoes the letter and word spacing hacks of pure-g) were removed from pure-u and friends and placed in to the pure-g-content (call it pure-c for short). This would mean that the grid environment established by pure-g would be inherited by units, and there would be no need for nesting pure-g. There would just be one pure-g enclosing the entire grid, like the suggested wrapper. So things could look like

<div class="pure-g">
  <div class="pure-u-1-2">
    <div class="pure-c"></div>
  </div>
  <div class="pure-u-1-2">
    <div class="pure-c"></div>
  </div>
  <div class="pure-u-1-2">
     <div class="pure-c"></div>
  </div>
</div>

This may be considered bit awkward, having to keep track of when a row is filled to 100%, so pure-u-1 could be used as a row wrapper like pure-g is now. (Or another class pure-r so that the intention is clear).

<div class="pure-g">
  <div class="pure-u-1">
    <div class="pure-u-1-2">
      <div class="pure-c"></div>
    </div>
    <div class="pure-u-1-2">
      <div class="pure-c"></div>
    </div>
  </div>
  <div class="pure-u-1">
    <div class="pure-u-1-2">
       <div class="pure-c"></div>
    </div>
    <div class="pure-u-1-2">
       <div class="pure-c"></div>
    </div>
  </div>
</div>

It would be expected that pure-c would be extended or mixed with another class to establish the font and other formatting.

(Names above chosen for symbolic value, not that they would practically fit into the Pure naming conventions, which might argue for something more like pure-grid, pure-grid-row, pure-grid-col, pure-grid-content and defining widths like pure-grid-col.half or pure-grid-col.third or pure-grid-col.sidebar as defined by the developer. In full glory, then

<div class="pure-grid">
  <div class="pure-grid-row">
    <div class="pure-grid-col half">
      <div class="pure-grid-content"></div>
    </div>
    <div class="pure-grid-col half">
      <div class="pure-grid-content"></div>
    </div>
  </div>
  <div class="pure-grid-row">
    <div class="pure-grid-col content-area">
       <div class="pure-grid-content"></div>
    </div>
    <div class="pure-grid-col sidebar">
       <div class="pure-grid-content"></div>
    </div>
  </div>
</div>

)

[dannyfritz]

For what it's worth my Chromebook Pixel also doesn't display grids correctly.

[dannyfritz]

In order to fix it on Chrome OS I had to throw in another font to the suggested CSS fix. http://jsfiddle.net/SKSBm/2/

.pure-g,
.pure-g-r {
    font-family: "Tinos", "Helvetica", "Arial", sans-serif;
}

It actually seems like it can further be condensed to

.pure-g,
.pure-g-r {
    font-family: serif;
}

[adapterik]

I think it would be best to list the fonts as Arial, Helvetica, Tinos, sans-serif because Arial should be selected on any device it is available on. That is, you don't want to select Helvetica or Tinos over Arial if Arial is available.

In the second comment, didn't you mean sans-serif? On a fresh default browser install, the generic sans-serif will most likely default to the specific fonts mentioned. However, if the user has customized their font mapping, this will no longer be true, and specifiying the font will ensure that the browser uses it, if available.

[dannyfritz]

@adapterik, I was seeing serif as the default in the evergreen browsers I have installed (Opera, Firefox, IE9, Chrome, Chrome OS, and Chrome for Android). Also, putting Arial first on Chrome OS didn't fix it for Chrome OS. Putting just serif did fix it on all browsers I had ready access to though.

Try it out and see what you find. :wink:

[ddelrio1986]

Here is the fix I've been using:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>My Page</title>
        <link rel="stylesheet" href="http://yui.yahooapis.com/pure/0.2.1/pure-min.css">
    </head>
    <body>
        <div class="pure-g-r">
            <div class="pure-u-1-3">Left</div><!--
                See: https://github.com/yui/pure/issues/41
            --><div class="pure-u-1-3">Middle</div><!--
                See: https://github.com/yui/pure/issues/41
            --><div class="pure-u-1-3">Right</div>
        </div>
    </body>
</html>