no -webkit- prefix

[philipwalton]

no -webkit- prefix

[philipwalton]

I'm using autoprefixer to add the prefixing. You can find the code here.

[christhomas]

well not everybody wants or can use the tools you use to fill in the huge gaps between your barebones, non functional skeletons you host on your webpages to the real world.

so you should stop using this tool and put all the appropriate styles in the code

if you truly want to explain flexbox to people, then you are not doing a good job by effectively lying to them by hiding the extra REQUIRED complexity about how many styles they will truly need to make this work in the real world.

[philipwalton]

The examples I use will work (as they're shown) in any spec-compliant browser. If people want to see how I've implemented cross-browser fixes, they can view the source, which I link to on every page.

As for vendor prefixes, I'm not forcing anyone to use any tool. By not adding the prefixes, developers are free to choose whatever tool they want. If I did add prefixes, it would actually be less helpful because it would prevent using certain auto-prefixing tools, and as those prefixes become obsolete in the future, people who just copy-and-pasted the code would no longer know if/why they were needed.

[christhomas]

Which completely ignores the point about "real world" development.

Additionally, what a hideously complex way to show people how flexbox works, I should be able to simply open a html file and see it working and yet, I've got to run ruby tools on the code before it's even viewable.

You have turned a very simple exercise in teaching people the benefits of flexbox, into a full on development process complete with learning how to use bower, ruby tools and other trinkets, JUST so I can see a single demonstration of your work in a single html file.

well done, I've never seen something so simple, turned into something so complex.

[Hiswe]

@christhomas I really don't understand your point of view.

Taking care of prefixes isn't a thing front-ends dev should consider. We should only take care of browser supports & finding the easier solution working with that constrain.
Let do the computer do this fastidious work for us. There are a lot of easy solutions to prefix like compass for sass, nib for stylus, autoprefixer (existing for every build tools, even as a plugin for sublime) and some more.

Having a clean CSS code is better for understanding, maintaining and so on.

[waldyrious]

Copying a comment I added to #37 by mistake:

Let me add a voice in support of keeping the simplicity. Having not used flexbbox before, I for one would have backed off if the examples looked too complex and "dirty". I believe the elegance of the simple approach (look how easy things are with flexbox) is what can draw a lot of people toward trying flexbox and then adapting it to their needs.

At the very least, I'd ask that the browser-compatibility code be greyed out, so that the actual flexbox code stands out, or maybe for there to be a checkbox to turn it on/off.

[sethjgore]

@Hiswe +1

Browser prefixes are for computers, not for us. Autoprefixing keeps the complexity of disparity between browsers out of our eyes.

@christhomas, “real world” development…

1. should and does use things like autoprefixing. Nothing keeps my professional client projects more sane that way.

2. is not insulting & disparaging the creator of said project…

3. is built on healthy suggestions & actual pull requests… if you want to change how this project is built: fork it, make it simpler as you want it to be and then recommend a pull request.

Insulting the creator of this work isn’t how open source & free things should be run nor is that acceptable in the “real world development”.

@_sethjgore
I run Grmmr (http://green-bridge.org) & create useful things (http://sjgore.com).
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, December 18, 2014 at 10:37 PM, Hiswe wrote:

@christhomas (https://github.com/christhomas) I really don't understand your point of view.
Taking care of prefixes isn't a thing front-ends dev should consider. We should only take care of browser supports & finding the easier solution working with that constrain.
Let do the computer do this fastidious work for us. There are a lot of easy solutions to prefix like compass for sass, nib for stylus, autoprefixer (https://github.com/postcss/autoprefixer) (existing for every build tools, even as a plugin for sublime) and some more.
Having a clean CSS code is better for understanding, maintaining and so on.

—
Reply to this email directly or view it on GitHub (#17 (comment)).

[christhomas]

@Hiswe

taking care of prefixes is a front end developer problem and it's absolutely something you know know intimately and that they exist, know how to use them and know what the probable risks and benefits of using them are.

if you hide all that behind a tool, you're putting the intelligence into the tool and not teaching the developer how to do things, so when something goes wrong, he neither has the knowledge, or the required skills to fix things

autoprefixing just means nobody learns how to do it in the real world and perhaps nobody realises there is a tool to do it and therefore they produce a bad quality product, learning how to do it yourself with no tools means that if you want you can use a tool, but if you don't have or want, you can do it yourself.

hiding the complexity of these issues from the developer just means there are less well informed developers in the world.

@sethjgore

real world development isn't some church band where we all sit around in circles and sing songs and hug each other, if I want to criticise somebody because of their bad judgement I will do it and it has nothing to do with open source or as you wrongly stated FREE SOFTWARE (free stuff?)

if you don't want people to criticise you, then make better decisions, but don't be under any illusion that free software or open source has any notion that we should be civil to people, like I said, this isn't a church band singing about jesus, make silly decisions, expect to get pulled up those decisions.

re: 3) i'm already doing so, but I'm not going to contribute to the github, a flexbox minisite doesn't need a github, neither does it need ruby tools to build it, what it needs is a few simple html files and a download zip for some example test files, doing a github to show something so basic just goes to show what is wrong with todays modern website development, it's like all you newbies have built a palace made of gold with shimmering towers made of good intentions, where to do anything simple I need tools for everything, without realising those tools are largely unnecessary and make a simple problem or process complex without any benefits what-so-ever, but this is a new-world-ideaology which I dislike a lot and comment against a lot.

real world web development for REAL programmers goes like this

1. create directory
2. create index.html
3. write html and create any necessary support files

if anybody suggests I need ruby tools to do web development, I'm going to laugh at them, don't want me to laugh at you? make better decisions.

[sethjgore]

@christopherthomas

interesting view regarding simplifying social entropy to schools of churchy jeering, i’m not going to discuss ideologies and social entropy of decisions here, although.

because it’s just internet banter…a waste of our time. that’s fine.

now to talk about “modern web development”.

i agree that:
it is being a torpedo launcher instead of a simple pen & paper.

i agree that:
to show them how with far smaller # of tools we can accomplish more.

i agree that:
we need as little abstraction as possible.

I believe that:
our whole OS are too much by themselves even.

that being said…@Hiswe + @christopherthomas autoprefixing should be a thing that’s built in the browser. unfortunately it is not. that and few other things are the main reason why we keep on using all of these mountains of files we call “processes”. these things should be built in the browser.

1. if it was easier to publish a site directly on the internet - github (imagine if your os could just do that)
2. to actually be able to pull packages into javascript/css - sass (simple @import commands directly on html)
3. errors show up quickly without aid - karma, jasmine, etc
4. these errors are fixed by the machine - none (?)
5. to visually render your pages with full authority that text-rendering (code) has - livereload, …. etc
6. any other “processes” that we are still struggling with?

i would, then, be convinced.

i do want a world where a quick + sweet:

‘’''“mkdir foldername | cd foldername | touch index.html5 | open in browser + serve”’’''

is the best way to web development.

@_sethjgore
I run Grmmr (http://green-bridge.org) & create useful things (http://sjgore.com).
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Friday, December 19, 2014 at 7:32 AM, Christopher Thomas wrote:

@Hiswe (https://github.com/Hiswe)
taking care of prefixes is a front end developer problem and it's absolutely something you know know intimately and that they exist, know how to use them and know what the probable risks and benefits of using them are.
if you hide all that behind a tool, you're putting the intelligence into the tool and not teaching the developer how to do things, so when something goes wrong, he neither has the knowledge, or the required skills to fix things
autoprefixing just means nobody learns how to do it in the real world and perhaps nobody realises there is a tool to do it and therefore they produce a bad quality product, learning how to do it yourself with no tools means that if you want you can use a tool, but if you don't have or want, you can do it yourself.
hiding the complexity of these issues from the developer just means there are less well informed developers in the world.
@sethjgore (https://github.com/sethjgore)
real world development isn't some church band where we all sit around in circles and sing songs and hug each other, if I want to criticise somebody because of their bad judgement I will do it and it has nothing to do with open source or as you wrongly stated FREE SOFTWARE (free stuff?)
if you don't want people to criticise you, then make better decisions, but don't be under any illusion that free software or open source has any notion that we should be civil to people, like I said, this isn't a church band singing about jesus, make silly decisions, expect to get pulled up those decisions.
re: 3) i'm already doing so, but I'm not going to contribute to the github, a flexbox minisite doesn't need a github, neither does it need ruby tools to build it, what it needs is a few simple html files and a download zip for some example test files, doing a github to show something so basic just goes to show what is wrong with todays modern website development, it's like all you newbies have built a palace made of gold with shimmering towers made of good intentions, where to do anything simple I need tools for everything, without realising those tools are largely unnecessary and make a simple problem or process complex without any benefits what-so-ever, but this is a new-world-ideaology which I dislike a lot and comment against a lot.
real world web development for REAL programmers goes like this

1. create directory
2. create index.html
3. write html and create any necessary support files
   if anybody suggests I need ruby tools to do web development, I'm going to laugh at them, don't want me to laugh at you? make better decisions.

—
Reply to this email directly or view it on GitHub (#17 (comment)).

[christhomas]

@sethjgore

right, so it seems that as opposed to having diametrically opposed viewpoints, we do agree on a lot of things, which instantly changes the game and estimations.

the problem with autoprefixing as I see it is this, if you write the standard compliant code and autoprefix the necessary css styles, then you could in fact by enabling bugs because certain prefixes don't work together well, by hiding the learning required and the development and implementation of those prefixes from people underneath a tool we risk raising a class of developers who don't know, who think that grunt will fix it for them and if that was 100% the case then cool! no problem, but it's not.

even teaching people to use SASS or LESS, great tools, but you should use them AFTER you know how to do it yourself, clicking on buttons is one of the reasons why we have so many incompetent system admins who used windows server instead of linux for example and because they always had a gui, never knew what was happening beneath.

in the context of this project, all of these tools are not instructive, nor useful within the context of what this project is trying to do, but by attaching reams of baggage to what should be a simple github of example files, a dozen other files which are largely useless or non-instructive, the github is largely useless by itself, I just google another source, why should anybody have to say that, why was it not obvious? because now we've taught that class of developer who can't do anything without a tool, he is nothing but a tool user and without them, maybe can't do it by hand.

the purpose of the github is to illustrate flexbox, but instead of that, it's wrapped up in layers of complexity that get in the way of actually learning flexbox because of the bad decisions made by the creator.

in the website it says (paraphrased) to view the full source, click this link, well ok, so I did and I didnt view the full source, I viewed part of it, because in order to view the full source, I need to git clone the repo, run tools on the code and even the example files online, were minified so the resulting css code is largely unreadable.

THAT is what I'm railing against, the creator had such a good idea and obviously is very talented, but failed to achieve his mission so badly and got so wound up in stuff which is not part of the core mission, that it's hard to understand why somebody points this out, he refuses and closes the bug.

.../slow clap......well done......