New ProcessWire admin theme on dev branch

[Martijn Geerts]

content-box vs. border-box;

Looks like the Netscape vs Explorer war in the old days.

Wished Paul Irish never told anything about box-sizing ( or had waited for the death of IE7. )

[diogo]

Not serious, and I still think it's worth it:

 

Adjustments for Third Party Content

Any third party widgets add content directly into the page may need extra attention. Any widgets inside an iframe (like Disqus’s new theme) are naturally insulated from the parent page’s layout styles. If you need to make adjustments to the third party content you can apply box-sizing: content-box; to the widget and its descendants. This may not be trivial as form controls in particular are border-box by default, so you’ll also have to account for that.

 

So, it's a matter of giving box-sizing: content-box; to the divs where there will be likely third party content.

[Martijn Geerts]

The first time I experienced issues with box-sizing was when jquery was at 1.8.3. Took me a long time to discover why fancybox 1.32 was messed up.

For me (still have to support IE7) it's just annoying. The most CSS frameworks rely on the "lazy" border-box and js plugins will follow. (Maybe some already do) 

We as devs have to be aware of box rendering, make exceptions use polyfils (or drop the support  for IE7). What looks easy at first side, is just giving overhead.

[diogo]

Martijn, sometimes it'd not about being easy or difficult. You can't mix percentages with pixels, and if borders measured in pixels count for the calculation of a total that is measured in percentage, things will break and there's no other solution either than removing the borders from the equation. That's what was happening with the admin theme in all browsers before that rule was added. Again, it's a matter of balancing the choices and make informed decisions.

[Martijn Geerts]

You can't mix percentages with pixels.( yes you can, working with negative margins and position absolute. ) But thats an other story.

For PW, border-box is the way to go I agree. it's a closed environment and IE7 is left out.

[diogo]

 yes you can, working with negative margins and position absolute.

If you know how many elements will have border and exactly what thickness will be the border of each... and you will be replacing a "clean" solution by a complex one. As I said, it's a matter of balancing everything and be aware of what you win or loose with each method. Any informed choice is a good choice

[renobird]

Wished Paul Irish never told anything about box-sizing ( or had waited for the death of IE7. )

I'm actually really glad he did that, and that it has caught on. My development is significantly faster now. IE7 usage is extremely low, and using things like box-sizing only serve to set the final coffin nail deeper.

Sorry to hear you are still having to support browsers that old Martijn. What kind of usage percentages are you seeing?

[Martijn Geerts]

Actually the end user percentages are very low. The problem is in our office.  Marketing, sales and all other departments work in a intra network with XP IE8.  So the render engine of IE7 is used to render. 

[Manol]

Maybe already asked, but I get this error using chrome-xampp, do you know how to fix it?

I'm new to github and not sure how to get latest version of the template. thanks.

[iNoize]

I'm using Windows 7 64 bit with Chrome, IE and Firefox for testing.

My problem is, that 14px Arimo Bold looks quite ugly. Letter e looks the worst.

The following screenshot is taken from Firefox but I get similar results with Chrome and IE on Win 7.

I don't know if this distortion is only caused by my Windows PC, so maybe someone could confirm this.

BTW, this screenshot shows processwire with the german language pack.

If you have to many fonts installed on your PC or some double fonts then Chrome causes this error. 

[ryan]

The problem seems * box-sizing: border-box and the 100% width height of image. When I turn off the box-sizing the image stretches itself back to normal size. I don't think it's a good idea to use * for stuff.

It sounds like there are various issues turning up as a result of this box sizing, though the only one that strikes me as a big concern is the image stretching Soma is seeing. What do you guys recommend as a fix for this? I originally added the box sizing per the recommendations here. Happy to change anything that needs changing, but not clear on what to change. 

Ryan: noticed that font-awesome has just changed the naming convention from icon-iconname to fa-iconname. Should we keep using icon-iconname, require new one or support both?

Feasibly we could switch to a different icon set in the future, and the icon-iconname format strikes me as more portable? The fa-iconname format seems to be branded specific to Font Awesome.

Maybe already asked, but I get this error using chrome-xampp, do you know how to fix it?

I'm new to github and not sure how to get latest version of the template. thanks.

It looks like you've got a new /site/templates-admin/ without a corresponding new /wire/ directory. Click on the "download ZIP" button on this page. Take the /wire/ directory and replace with your existing /wire/ directory. Then take the /site-default/templates-admin/ directory and replace your /site/templates-admin/ directory with it. 

If you have to many fonts installed on your PC or some double fonts then Chrome causes this error. 

Can anyone with a PC and chrome confirm that the fonts are displaying correctly now that we've switched to self-hosted Arimo? It sounds like the easiest way to tell is whether the letter "e" looks like the screenshot in the post above this. 

Does anyone have any ideas on how to fix the submit buttons that aren't registering half the time?

[Manfred62]

Can anyone with a PC and chrome confirm that the fonts are displaying correctly now that we've switched to self-hosted Arimo? It sounds like the easiest way to tell is whether the letter "e" looks like the screenshot in the post above this.

the difference is minimal on Win 7, 64bit. First is Firefox, second is Chrome (both actual versions). Safari 5.1.7 on Win 7 looks the same like Chrome.

[ryan]

Thanks for testing it Manfred62.

I'd say it still looks pretty bad (can't tell there's been any improvement at all). Is something just wrong with this font (Arimo) regardless of whether it's from Google Fonts or self hosted? The regular text looks mostly similar to how it does in OS X, but the bold looks like a different font entirely. This is what it looks like here (Chrome in OS X).

[Craig]

Using the latest dev branch, it still renders badly on Windows in Chrome and FF (but FF being the better of the two), particularly the bold sections.

If the CSS is changed so that the SVG file is referenced before the others (I think this was mentioned/linked to earlier in this thread) then Chrome handles it a bit better; but with the side effect of the text not quite as clear as it should be.

See the screenshot attached. On the left is the "Edit" page with the SVG font reference at the top in the CSS, and on the right is the same page, but with all of the webfont references removed from the top of the CSS - falling back to the default system fonts.

In my opinion, there's nothing wrong with Arial, Helvetica, Sans-serif

CSS example:

@font-face {
  font-family: 'Arimo';
  src: url("fonts/Arimo-Regular.eot");
  src:
  	url("fonts/Arimo-Regular.svg#Arimo") format("svg"),
  	url("fonts/Arimo-Regular.eot?#iefix") format("embedded-opentype"),
  	url("fonts/Arimo-Regular.woff") format("woff"),
  	url("fonts/Arimo-Regular.ttf") format("truetype");
  font-weight: normal;
  font-style: normal; }

[Manfred62]

In my opinion, there's nothing wrong with Arial, Helvetica, Sans-serif

I agree.

But maybe Ryan could give Fira a try? Looks nice on all browsers and was already mentioned in this thread.

If Fira is no option, we should stay with 'Arial, Helvetica, sans-serif' as a safe solution.

[diogo]

In my opinion, there's nothing wrong with Arial, Helvetica, Sans-serif

Hm, I have to say, as a designer, it's not that easy to digest this sentence. Not that there is something wrong with those typefaces (with Helvetica at least), but because that thought just throws any design choices in the garbage, not to speak in all the effort that is being put on making typography be finally possible in the web... isn't it a bit like telling a developer "i don't care if it's semantic, just make things appear on screen".

[Craig]

Hm, I have to say, as a designer, it's not that easy to digest this sentence. Not that there is something wrong with those typefaces (with Helvetica at least), but because that thought just throws any design choices in the garbage, not to speak in all the effort that is being put on making typography be finally possible in the web... isn't it a bit like telling a developer "i don't care if it's semantic, just make things appear on screen".

If I'd have said Comic Sans, then I would agree with the last part

I do see your point of view, and I am not a designer per-se. But I often take a more functional approach, rather than purely aesthetics. The Arial, Helvetica, sans-serif font stack works, and has done for a long time and in many designs and situations. Its use case here - in the control panel - (in my opinion) is not one of the situations that demands or calls for a webfont just because. 

[diogo]

I was worried that I might have been rough with what I wrote, but it wasn't my intention. I'm glad you took it how I intended

Anyway, It's not only an aesthetics matter, it's also functional if you think that Helvetica was created for printing and Arial is not more than a bad copy of it. There are many fonts (even free) that were created especially for screen, and some of them by really good type designers , For example Fira, that was mentioned before, was designed by Erik Spiekermann (Yaaay, I wrote his name right without looking ). Truth is that the traditional font stacks exist because of a technical limitation that doesn't exist any more, can you imagine if it would be the same with printing? Imagine if all the posters and magazines would be written in the same fonts (boring...), and last but not least, imagine that all online code editors and code in blog posts would be in Courier New 

[diogo]

It sounds like there are various issues turning up as a result of this box sizing, though the only one that strikes me as a big concern is the image stretching Soma is seeing. What do you guys recommend as a fix for this? I originally added the box sizing per the recommendations here. Happy to change anything that needs changing, but not clear on what to change. 

That rule was added to correct the input fields funky behaviour because of the borders, so maybe the best things is to apply the border-box only to them. 

input, textarea {
  -moz-box-sizing: border-box;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
}

We could go a bit further and apply it to all the direct children of .InputfieldContent. I think I prefer this option.

.InputfieldContent > * {
  -moz-box-sizing: border-box;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
}

[wayne]

the difference is minimal on Win 7, 64bit. First is Firefox, second is Chrome (both actual versions). Safari 5.1.7 on Win 7 looks the same like Chrome.

pw-arimo-fx.jpg pw-arimo-chrome.jpg

Your second screenshot shows the same distorted "e" in "Seiten" I get with my Firefox and Chrome.

I don't know why your Firefox renders it differently compared to mine.

However one thing that messes this up is definitely Window's ClearType.

Turn it off and particular the Arimo font looks partly better but also partly worse (in Windows Chrome browser).

By no means turn off ClearType permanently. But this proves that there is an annoying flaw in Window's own smoothing algorithm.

I couldn't find any solution yet.

Some people suggest using FontSquirrel's webfont generator but the results still look quite ugly.

EDIT:

Ok, I found out that the different rendering in Manfred's Firefox is the result of hardware acceleration.

My acceleration option is turned off because of some graphics card bugs, but If you turn it on Firefox uses DirectWrite for font rendering.

DirectWrite + ClearType does a bit better job than GDI + ClearType.

[ryan]

Craig, thanks for your tests. Both of your screenshots looked pretty decent for Windows. So it sounds like the one on the right is Arial? Arimo looks pretty good on the left (at least compared to the earlier Windows screenshots), but relative to Arial, it looks a rather fuzzy. I would choose sharp and boring (Arial) in this case, as I think the usability of the type is much more important than the distinctiveness of it for this application. On the Mac, this really isn't an issue, as Arimo renders just as sharply as Arial. Do all web fonts render a little fuzzy on Windows? If so, then I think we have to just stick with Arial on Windows and limit our Arimo usage to Mac. Though if we can solve it by using a different face (Fira?) then I'm good with that too, so long as the face still portrays the same anonymity that Arial and Arimo do. 

[ryan]

Tried out Fira, but it definitely screams Firefox. A nice font, but I can't look at it without thinking of the Mozilla lizard or whatever it is. A little hard on the eyes too, at least on my screen (I'm seeing lots of lizard tails). It seems like webfont technology on the PC side isn't quite there yet to the point where we should rely on it, though let me know if there's any other fonts you think we should try. 

That rule was added to correct the input fields funky behaviour because of the borders, so maybe the best things is to apply the border-box only to them. 

We could go a bit further and apply it to all the direct children of .InputfieldContent. I think I prefer this option.

Thanks Diogo! I will go ahead and add this. 

[diogo]

Tried out Fira, but it definitely screams Firefox

I agree

Here are six more suggestions:

http://www.fontsquirrel.com/fonts/asap (I like this one)

http://www.fontsquirrel.com/fonts/lato

http://www.fontsquirrel.com/fonts/CartoGothic-Std

http://www.fontsquirrel.com/fonts/cabin

http://www.fontsquirrel.com/fonts/Liberation-Sans (closer to Arial, from Red Hat)

[landitus]

I would like to suggest Lato or Source sans pro, from google fonts: http://www.google.com/fonts/specimen/Source+Sans+Pro

[DaveP]

Re the Arimo bold problem - is it not that the browser is creating a faux bold from the regular weight? If I am using Arimo, I use Google's CSS code to link to fonts.googleapis.com  and specify both regular and bold weights, so as to get a 'proper' bold. (Which renders perfectly at http://www.google.com/fonts#UsePlace:use/Collection:Arimo for example.)