Best news of the...... (can't remember)
Really excited about it...
of course, if the design Team needs some total copyleft photos... just ask for them

@MATsxm On the subject of copyright images... can https://unsplash.com/ be used (CC0) ?

CC0 is compatible with GPL

@ciar4n @wilsonge it is but it is nearly a question without answers as legal requirements may vary according to the copyright in the country of the photographer, which is very often forgotten.
but... let's say "yes"

But when a photographers upload their photo to a site, they are agreeing to the license stated by the site. And the site specifically says

you can copy, modify, distribute and use the photos for free, including commercial purposes, without asking permission from or providing attribution to the photographer or Unsplash

Either way, it's no big issue, it's only a banner. I'm sure the design team can come up with something that fits the bill

I'm sure @MATsxm can take a lovely photo for us that he can donate to the project ;)

But when a photographers upload their photo to a site, they are agreeing to the license stated by the site.

not totally true as for example, in french law there are what we call "public domain" laws to which individuals may not derogate, even with an agreement between the parties (for example, the duration of the right of use of a photo that MUST be mentionned in france)

Hmm fair enough. You best set off for the beach then :P

Not saying this is true of unsplash but it is definitely true that some sites that are offering images with a copyright status that we can use do not actually have the permission of the photographers. Thats why we chose images from wikipedia previously as there is a documented and public record of the image status

Just use NASA's photos. The name Aurora also seems to fit the bill

@C-Lodder why are you changing code mirror with this PR? :-) Just out of curiosity

@yvesh that's the grunt script, we have to come up with a better solution here ;)

@yvesh - cause I ran grunt. This runs uglifyJS which minifies codemirror JS files, but the output of the .min` differes each time.

all the extra files included by grunt really make things hard to review. surely there is a setting that does not generate new minified js if nothing has changed

@brianteeman we are looking into this. It's do do with the variable names changing each time the files are minified. There's an option to prevent variable names from being minified, however this needs to be done in a separate PR and merged before I can apply it to this PR.

There are several a11y issues with the icons but they can be addressed in phase2

@brianteeman - yes, a11y will be done afterwards once the entire template is finished. I'd preferably like to get a beta of this merged so it's just there with the rest of core for people to use and test on the fly

my suggestion for chrome / module sizing is a variant of what we currently have..
Select 'bootstrap" chrome, select columns ( both currently exist ) & finally select column size which behaves completely differently from bs2 or bs3 ( https://v4-alpha.getbootstrap.com/layout/grid/#grid-options )
You'll also note the column names are different then before.

About the mentioned module positions, e.g. sidebar-left—they might still be a good idea (for things independent of html[dir]), but, for the sake of rtl-languages, I think the default wording for sidebars should be e.g. sidebar-start and sidebar-end? (In CSS, text-align-start and text-align-end are a thing now.)

As module positions are mainly exposed to developers/implementors, I think this would actually prevent confusion (rather than add to it).

@born2webdesign i agree that the positions should have semantic meaning and I already commented on that earlier today regarding an ID but in this case an RTL language would not change anything. An RTL template is not a mirror of an LTR template so right is still right etc

@brianteeman True, RTL doesn't have to be a mirror of LTR—that's why I agree there could also be *-left and *-right. But a sidebar menu, e.g., should probably change sides when switching from RTL to LTR—thus an additional *-start and *-end would be helpful.

In an admin template the ui should indeed be reversed/mirrored so you would be 100% correct there but we are talking about a frontend template here so left would still be left

I was talking about the frontend, as well. See my example from above—it is not uncommon for a module to be displayed on the left in ltr and on the right in rtl. And with distinct positions (sidebar-left and sidebar-start) we could have (e.g.) .sidebar-left {float:left} but .sidebar-start {float:left} [dir="rtl"] .sidebar-start {float:right}

in that scenario the correct way would be using the module assignment option already available. as this is a frontend template you can always create the positions and css as you want in your own template

you can always create the positions and css as you want in your own template

Sure, but if we are introducing sensible module positions, it would be nice to harmonise those with my own template's positions. You are of course right if you are saying I could assign a translated module to the "opposite" module position …

I could just use sidebar-a and sidebar-b. Some of the top Joomla and WP template providers use these naming conventions

My previous concern (changing sides (or not) for ltr-rtl) is mostly taken care of by assigning modules to the appropriate positions (as brought up by Brian).
But changing templates without having to reassign all modules might be nice, too (sidebar-a on the left in the old template, on the right in the new one)—then again, if we moved the old template's sidebar to the new template's header … To work around that we would have to stick with super generic names … perhaps sidebar-a, sidebar-b and similar are a good compromise? I'm not sure.

But changing templates without having to reassign all modules might be nice,

Yes it would be nice but sadly template developers like to reinvent the wheel.

It's not reinventing the wheel at all. It's using proper naming conventions that SHOULD have been done in the first place, rather that position-7 which could be anywhere.

The new positions mean the user no longer needs to get a template preview open to know where to assign modules.

If the user has Protostar as their default template, then we can simply migrate the module positions over to the Aurora positions, so the the upgrade from 3.x to 4.0 is smooth.

I was referring to 3pd template developers not core. ;)

The reason that template positions have a "translation" was so that position-7 would never change in the code but the developer could give it a meaningful name in their own template - no one used it though

Maybe we should stick with the generic but flexible position names but promote their translations more/make them more prominent?
Really, the current system seems very well-thought-out to me—thinking about it again ;)—and @brianteeman you are right, I hardly ever used the names/translations, rather invented my own positions. So, if we could fix this behaviour (reinventing positions) by exposing those names more/pushing for their use, perhaps that would make the current system perfect?!

Really not sure what more we can do to encourage their use. Remember they also allow a position to be called left and gauche (french) so that in itself should be a reason to use them as it means the position is easy to understand in languages other than english

First, we could give them even more descriptive names ("Left Sidebar", "Left Content" instead of just "Left").
Then, in the promotion, instead of "Here are the all-new positions for Aurora: …." it could be "Here are the new position names for Aurora: … "Left Sidebar" (position-8) … Remember, you can give the same positions new names (and translations) in your template so, after changing your template, you shouldn't ever have to reassign positions for existing modules!".

I have read a little the story.
brianteeman, do not do the error to force to add old BS2 in a new template. It's the best way to have conflict as in Joomla3 and before.
I load boostrap in Joomla 3 using JHtml::_('bootstrap.framework') and overide always in front for eg. in MYTEMPLATE/js/ui and MYTEMPLATE/css/ui to overide medias, if alyout need changes, then this should be overide too, but i think that you should simply force all component to use Jquery+boostrap 4 or nothing in admin or we have 4 year problems as mootools in Joomla 3.
Is same as doing it compatible php4 , jquery 1.6 ...