Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixing small grammatical glitches #12

Merged
merged 1 commit into from
Dec 12, 2017
Merged

Fixing small grammatical glitches #12

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions text/0000-remove-application-wrapper.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,11 @@ export default Ember.Application.extend({
```

However, whatever the root is, the application adds another `<div>` wrapper
that it's not required anymore. It's just a vestigial reminder of some implementation
that it's not required anymore. It's just a vestigial remainder of some implementation
detail of how views worked in Ember 1.x. Some sort of wisdom tooth of the original
rendering system that it serves no purpose today.
rendering system that serves no purpose today.

Furthermore, much like a wisdom tooth, it can gives us problems. In the past this element
Furthermore, much like a wisdom tooth, it can give us problems. In the past, this element
was configurable using the `ApplicationView`, but when views were removed we lost that
ability. Right now we are stuck with a wrapper element we can't remove and we also can't
customize, which is why some apps target the selector `body > .ember-view` to style this
Expand All @@ -47,7 +47,7 @@ container.
## API Surface

The proposed approach is identical to the one proposed in #278, that I reproduce
pristine below in italic:
pristine below in italics:

*We should not expose the flag directly as a public API. Instead, we should
abstract the flag with a "privileged addon" whose only purpose is to enable
Expand Down Expand Up @@ -78,7 +78,7 @@ any class or id they want.
# How We Teach This

This addon will be an opt in, but at some point it will become part of
the default blueprint. This change, rather than introducing a new concept, it *removes*
the default blueprint. This change, rather than introducing a new concept, *removes*
an old one. Users won't have to google what is the way to remove or customize
the implicit application wrapper of the app (to sadly discover that is not
even possible), but instead they will just add a wrapper only if they want,
Expand All @@ -96,4 +96,4 @@ html hierarchy for some reason, and those addons would have to be updated.

# Alternatives

Leave things as they are today.
Leave things as they are today.