Looking forward or backward? #36
Comments
|
Its also worth mentioning that old IE are not all the same: IE7 - who is still supporting this? I am sorry but if you do - you are too much of a special case, everybody else should not be suffering because of you IE8 - handles graceful degradation pretty well (needs html5shim), although combination with mobile-first approach is not very straightforward IE9 - is still not too old, supports media queries and things like round corners, canvas, etc. - never had much problems with it PS Is from HTML5 boilerplate dating back to 2010, seriously how long are we gonna be dragging this thing along? Also, no-js? :) Sorry, but this is funny. You do realize that no major browsers these days even have an option to disable javascript anymore? Mozilla got rid of it about 3 years ago and I think Chrome never had it in the first place. The only way for users who don't mess with developer tools to disable javascript nowadays is to use a browser plugin. PPS sorry about the long comments and a somewhat 'ranty' tone, I do get carried away a bit sometimes, hopefully it all makes sense |
|
Hi @YemSalat, thank you very much for your comments. I know what you mean about the tone but don't worry, I welcome the good intention and your insights 👍 I completely agree with you in letting go the old IE browsers. As you can see in commit 2f35154 I started removing old browsers support on june, but didn't complete it. And as you have seen there are some vestigial remainings from bones that I've not yet finished removing. Those are not my design decisions and I'm happy to discuss what's is or isn't longer necessary in that regard and clean the headers as much as possible, while maintaining some sort of sensible versatility. So mi intention is to NOT put the enphasis in supporting old browsers, but to support the current standards and best practices. That being said I also like to be somewhat conservative in the defaults. About rems. I chose that unit as the default one, some time ago, after reading a lot on the subject and having to make a choice, but I'm still open to discussion on that regard. I don't believe there's a clear winner. Do you have an opinion on the matter? The support of older browsers in that regard was coming from using "gulp-pixrem" in the build chain (search for remPixelFallback in gulpfile.js), which optionally duplicates the rem rules with pixel values when that kind of compatibility is wanted. And I agree too that the no-js thing can also be removed, because well... we are talking about WordPress here and and 99,99% of the users will have javascript as you said. I guess I left it in also because my dear brother always likes to browse with elinks or with firefox with noscript, and I had the naive hope in the back of my mind of supporting that. But really no, I concur that is one sure thing to remove. |
|
I am 'on the fence' about using rem (apart from font-sizes), I only used it in a handful of projects so far and I agree that it can be very useful sometimes.
|
|
I've removed the IE conditional styles. But after thinkin a little bit more, I prefer to leave in the I've created a new issue for discussing the default CSS units in #37 |
|
That is actually another thing that I wanted to bring up - Modernizr. Modernizr has two purposes:
99% of wordpress websites that I see have Modernizr included, yet I never see them actually using it for anything. Maybe its the name? And people think that by merely including it in your code - your website somehow becomes more 'modern'? PS Don't get me wrong, I love Modernizr and have used it in some of my own projects for feature detection, I just don;t think that it is required on the majority of Wordpress-based sites. |
|
PPS if I am not convincing enough, maybe Chris Coyer from CSS tricks will make you change your mind - https://css-tricks.com/video-screencasts/126-using-modernizr/ :)
PPPS sorry, I just realized that I am commenting on a closed issue, please feel free to move it wherever you see as more appropriate |
|
The big feature of Modernizr is its feature detection 1. It is true that probably in't required in the majority of Wordpress-based sites. But it is a useful tool for advanced usage, like doing a WP app, using something from a phone. Because it allows you to do more advanced things. I'd like Médula to be both useful for rapid application developers and for beginners too. I think that is perfectly possible to balance those aspects, and that the key must be in simplicity. I like simplicity, and I also think that a starter theme must have easy access to tools for common need, this is important enough to have a line that one can uncomment, with a short description and a link to the https://modernizr.com/docs#features. It also makes it the beginners that want to play with it too. And at the same the theme would be making a stance in simplicity by not having that feature enabled. Simplicity makes it simpler for simple people, like you and me, when we want to be simple, and it makes only a small difference for advanced users that already know where they kind find the tools they like, so we can put the most likely tool for the job, like you and me when we suddenly decide we want to use that feature for a project we started two months ago, specially in this case when it's the only tool that does a good job. P.S.1 As you can see in commit 532c38c I fixed modernizr, just including a small ammount of the test I though could be useful most of the time. And it doesn't include html5shiv. One must include it separately, like any other test, adding them to the line in bower. P.S.2 I believe it'd nice to leave it configured in bower by default too. But I'm not sure about that. What do you think? |
|
Sorry, did not notice this comment until now. Regarding Modernizr - I think its best to leave it commented out for now, and make it available through a generator later. For example when generating a new theme - it would ask "Do you need modernizr?" - and then those lines will be included. |
|
I havent thought about using a generator before. I want to maintain a balance between simplicity and versatility. Maybe a generator can be a good idea if it's done well. Let me think about it. I've opened a new issue for this in #39 |
I think a decision needs to be made whether the theme is going to be future-oriented or have a strong browser backwards compatibility. I think its too hard to do both at the same time.
For example:
h1, h2, h3, h4, h5, h6,
.h1, .h2, .h3, .h4, .h5, .h6 {
margin: 2rem 0 1rem;
...
And:
<html class="no-js">
OK, now lets think for a moment. If we are gonna be using rem units in our css, that means that we'll need to override every single rule that uses them for IE7/8 with units that they support (both of them obviously don't support rems)
So are we really helping anybody by adding weird markup to our templates?
The thing is - people who need to support IE7/8 - are not gonna be using rem because for them it is much easier to use the same units that are supported across all browsers instead of maintaining a separate stylesheet for IE.
And people who want to use rem - probably don't care much about old IE. So why should they be getting all those extra bytes of useless stuff with every page load?
In my opinion the IE7/8/9 specific stuff has to go. Its kinda funny how we, as a developer community always keep complaining how older technology doesn't allow us to use the web to its full potential, yet we do everything we can to not let old browsers die out.
The text was updated successfully, but these errors were encountered: