Fix certain improper rendering of forms
#560
Злито
marek-lach
злито 39 комітів з fix-webkit-specific-rendering-of-forms
до master
5 роки тому
Рецензенти
Попросити рецензію
Немає рецензентів
Мітки
Очистити мітки
Related to the REST API
Code running on the server
Stuff related to Federation
Related to the front-end
Translations, and related code
More about project management or code than the project itself
The building, or installation process of Plume
Something isn't working
We need to talk
New feature or request
This is a new feature
Compatibility with different browsers, readers and OS
Related to an external package that Plume uses
UI/UX related issues and PRs
Good for newcomers
Extra attention is needed
Issues affecting only mobile UX
How elements're rendered out for the end user
Something else needs to be fixed first
This issue or pull request already exists
This PR is not complete yet
Issues concern a limited number of instances
This doesn't seem right
Need to be discussed by the community (on Loomio)
This PR is ready to be reviewed
Proposed ideas worth considering
This is issue has been created after a vote on Loomio
This will not be worked on
Застосувати мітки
A: API
Related to the REST API
A: Backend
Code running on the server
A: Federation
Stuff related to Federation
A: Front-End
Related to the front-end
A: I18N
Translations, and related code
A: Meta
More about project management or code than the project itself
A: Security
Build
The building, or installation process of Plume
C: Bug
Something isn't working
C: Discussion
We need to talk
C: Enhancement
New feature or request
C: Feature
This is a new feature
Compatibility
Compatibility with different browsers, readers and OS
Dependency
Related to an external package that Plume uses
Design
UI/UX related issues and PRs
Documentation
Good first issue
Good for newcomers
Help welcome
Extra attention is needed
Mobile
Issues affecting only mobile UX
Rendering
How elements're rendered out for the end user
S: Blocked
Something else needs to be fixed first
S: Duplicate
This issue or pull request already exists
S: Incomplete
This PR is not complete yet
S: Instance specific
Issues concern a limited number of instances
S: Invalid
This doesn't seem right
S: Needs Voting/Discussion
Need to be discussed by the community (on Loomio)
S: Ready for review
This PR is ready to be reviewed
Suggestion
Proposed ideas worth considering
S: Voted on Loomio
This is issue has been created after a vote on Loomio
S: Wontfix
This will not be worked on
Без мітки
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
Етап
Призначити етап
Очистити етап
Немає елементів
Етап відсутній
Виконавці
Призначити користувачів
Прибрати виконавців
Немає виконавця
1 учасників
Сповіщення
Дата завершення
Термін дії не дійсний або знаходиться за межами допустимого діапазону. Будь ласка використовуйте формат 'yyyy-mm-dd'.
Термін виконання не встановлений.
Залежності
No dependencies set.
Reference: Plume/Plume#560
Посилання в новій задачі
Тут ще немає жодного змісту.
Видалити гілку 'fix-webkit-specific-rendering-of-forms'
Видалення гілки НЕЗВОРОТНЕ. Дію не можна скасувати. Продовжити?
Ні
Так
Attempt at fixing the jumbled styling of the search form in Apple's Safari, which is not present in Blink browsers like Opera, or Chrome:
It appears I forgot about that one in my PR some months back which addressed how forms in Safari were displayed (maybe search wasn't even there then...?).
Safari does seem a bit like the new Internet Explorer these days, unfortunately.
This is otherwise a rather small and safe PR for merging, since it has practically no reason to break anything anywhere else.
I don't think this issue has anything to do with
display: flex
. Safari should support it normally. I think it is more that it tries to apply a "native" style to search fields by default (<input type="search">
), and that a CSS rule to prevent that should be added here:But I tested your changes, and it doesn't seem to break anything with Firefox, so it is still safe to merge if you want.
I also merged master into this branch, so it should be available at https://pr-560.joinplu.me soon, if you want to test in Safari.
I actually do think you are correct, but just in case that didn't sufficiently fix the issue with the search bar (or any other input/submit form), I didn't want to do 2 separate PRs with basically the same objective in the near future.
So I basically just put everything in relation to Safari into this one PR and hopefully that would be sufficient for anything Apple may decide to break with how Safari displays things for the forseeable future :-)
@ -6,7 +6,7 @@
@:base(ctx, i18n!(ctx.1, "Search"), {}, {}, {
Why don't you add it to the stylesheet directly?
Codecov Report
@ -6,7 +6,7 @@
@:base(ctx, i18n!(ctx.1, "Search"), {}, {}, {
Where do you mean, I am not too sure...sorry. In the
.css
files I have adressed every form andinput
field that I felt like it needed to be adressed. I have reformatted the line you higlighted, so it should be all fine now, I guess? :-)The appearence of the search bar is now properly fixed:
@ -6,7 +6,7 @@
@:base(ctx, i18n!(ctx.1, "Search"), {}, {}, {
(sorry for the late reply)
You actually forgot this one: https://github.com/Plume-org/Plume/pull/560/files#diff-339bac14a232fb01418ef93c2cb5e1ecR6
I think if you add
appearence: none
here, you could remove all the inline styles and have them all in one place.@BaptisteGelez This PR is ready to be merged, I think, once the build tests suceed.
Sorry, I still have some remarks/questions.
Also, I'm not sure all the
-webkit-flex
are necessary, as Webkit have been supportingflex
for quite a long time now I think (I tested with GNOME Web, that uses a not-so-recent version of Webkit, and everything seems to be displayed correctly without these prefixed rules).What does it do?
@ -131,3 +140,4 @@
-webkit-appearance: none;
}
.button + .button {
I think using the unprefixed
appearence
(if it works) would be better, because Safari may drop support for the prefixed version one day, as they are mostly used when the property is in "beta".I would prefer to avoid adding inline styles if possible, and to keep them as much as possible in the stylesheets. For instance, you can probably add this rule to
#plume-editor { ... }
in_article.scss
@ -131,3 +140,4 @@
-webkit-appearance: none;
}
.button + .button {
Right. As you say, it's best to make these changes to be as universal, and platform agnostic as possible in the long-term.
I have now ammended the commits.
@ -6,7 +6,7 @@
@:base(ctx, i18n!(ctx.1, "Search"), {}, {}, {
Unfortunately, in some cases, like with imput forms and buttons, there just has to be the
-webkit
prefix present, otherwise the buttons are disorted when it's justappearance: none;
, and so the desired effect is not achievable otherwise it seems like...Checkboxes are also rendered poorly without
-webkit-appearance: checkbox;
I did try to keep the platform specific prefix only to an absolutely necessary minimum though.
@BaptisteGelez So I finally tested the compiled version on the live instance both in desktop Safari for OSX and in mobile Safari for iOS and it looks nice!
Even things like native shortcuts work (notice the little
x
at the end, also autocorrect is automatically applied too) in the searchbar now, which was not the case before. That is honestly an even better result than I had originally hoped for.I think this PR is now really ready :-)
By the way, I tested in Firefox too and everything is there just as it was before, so nothing's broken:
Looks good! Thank you for you work and your patience!
Рецензенти
33619abdfb
.Крок 1:
У репозиторії вашого проєкту перевірте нову гілку і протестуйте зміни.Крок 2:
Об'єднати зміни і оновити на Forgejo.