Remove webkit-specific border radius from CSS

+++ b/modules/contextual/contextual.cssundefined
@@ -52,8 +52,7 @@ div.contextual-links-active a.contextual-links-trigger {
@@ -68,10 +67,7 @@ div.contextual-links-wrapper ul.contextual-links {

@@ -68,10 +67,7 @@ div.contextual-links-wrapper ul.contextual-links {
   top: 18px;
   white-space: nowrap;
   -moz-border-radius: 4px 0 4px 4px; /* LTR */
-  -webkit-border-bottom-left-radius: 4px;
-  -webkit-border-bottom-right-radius: 4px;
-  -webkit-border-top-right-radius: 0; /* LTR */
-  -webkit-border-top-left-radius: 4px; /* LTR */
+  -webkit-border-radius: 4px 0 4px 4px; /* LTR */

Should this be moved to contextual.ltr.css?

+++ b/modules/shortcut/shortcut-rtl.cssundefined
@@ -31,8 +31,7 @@ div.add-or-remove-shortcuts a span.text {
diff --git a/modules/shortcut/shortcut.css b/modules/shortcut/shortcut.css

diff --git a/modules/shortcut/shortcut.css b/modules/shortcut/shortcut.css
index 3afcb94..379816e 100644

index 3afcb94..379816e 100644
--- a/modules/shortcut/shortcut.css

--- a/modules/shortcut/shortcut.css
+++ b/modules/shortcut/shortcut.cssundefined

+++ b/modules/shortcut/shortcut.cssundefined
+++ b/modules/shortcut/shortcut.cssundefined
@@ -90,8 +90,7 @@ div.add-or-remove-shortcuts a:hover span.text {

@@ -90,8 +90,7 @@ div.add-or-remove-shortcuts a:hover span.text {
   padding-right: 6px; /* LTR */
   cursor: pointer;
   -moz-border-radius: 0 5px 5px 0; /* LTR */
-  -webkit-border-top-right-radius: 5px; /* LTR */
-  -webkit-border-bottom-right-radius: 5px; /* LTR */

Same here? shortcut.ltr.css?.... Otherwise, I'd say this is RTBC!

3 days to next Drupal core point release.

lol, whoa... I read that as RTL for some reason :-) .

catch@catch-laptop:~/www/8-commits$ diffstat webkit-shorthand.patch
 modules/contextual/contextual-rtl.css |    3 +--
 modules/contextual/contextual.css     |    8 ++------
 modules/shortcut/shortcut-rtl.css     |    3 +--
 modules/shortcut/shortcut.css         |    3 +--
 themes/bartik/css/style.css           |    5 +----
 themes/garland/style.css              |    5 +----
 themes/seven/style.css                |    8 ++------
 7 files changed, 9 insertions(+), 26 deletions(-)

This is wonderful.

However which actual browsers does this drop support for (for those of us who look at terminals all day)?

Side note, it'd be good to have a nice chart somewhere for which browsers we do and don't support - especially now that IE6 is dropped and hopefully more on the block as time goes on.

WebKit, http://www.webkit.org/, is an engine used by other web browser applications; e.g., Safari.

Can we clarify which actual browsers/versions are no longer supported by this change?

Ok lets clarify this because I think I'm missing something...

You should look at: http://caniuse.com/#search=border-radius

-webkit as a prefix for desktop browser is ancient history alrdy. Chrome uses the "normal" border-radius version since version 5. I'm on 17 now...

Safari uses the "normal" border-radius syntax since version 5, nobody uses safari 4 anymore.

Sooo the only reason why we should have -webkit in core is for those damn ipads (version 1), iphones (3gs) and a few android users. You're saying these systems use a deprecated webkit version and we should use the shorthand version that doesn't work on ipad 1. So whats the point of changing those lines to a shorthand version if no browser will use it... (if both webkit-border-radius and border-radius are available webkit will choose the border-radius one)
If we drop the support for those browser we should just remove all the webkit stuff...

The -moz prefix is used by firefox 3.6 and below. That browser has a market share of 6 procent, in march it was almost 24%. When drupal 8 gets released this number will be low. The only people still using firefox 3.6 are hordcore firefox users that hate the rapid release approach started with version 4.

One of the good thing about apple products is that most everyone wants the latest and greatest versions. I don't think we'll have to care about the iPad 1, iPhone 3GS, or Android 2.1 by the time Drupal 8 comes out.

...so the compatibility question can be solidly answered prior to release only.

True, but.....

Should we expend effort to support browsers that a tiny minority use? Which would take more effort, to push a patch through that rips the band-aid of browser specific CSS properties or endeavor to continue support with all future patches that touch on CSS?

Theres no doubt that its a complete waste of space & time & good use of the frontend developers time to keep supporting the browser specific border-radius for browsers where we allready have cut out ie8 crowd for a couple of iphones can have a round corner. (ok ill stop the ranting)

The 1 place where we really use this browser specifix element are in the contextual module which btw also have a -khtml just to add to the fun ;)
if it should be anywhere then it should be moved out of the contextual module and into bartik.

working on the specific issue for d8 here #1216978: Clean up the CSS for Contextual module

the webkit 4 is dead - after the last ios5 update the ipad 1. is now running safari5

keeping round corners for iphone3 for an admin users contextual menus, is imho a edge case & we would kill the suport in a second if it was ie6 that had the same behaviour.

in the case of -webbkit-border-radius the vendor specific dont apply anymore for safari (yeah) so we can remove the -webkit- for border-radius now completely :)

#1344520: Drop support for safari4 in core
#1216978: Clean up the CSS for Contextual module

To me, it sounds like we need to develop a Legacy Browsers Support module that provides the site builder the option to support a whitelist of older browsers.

That way we can we can shove all of this non standard compliant css into that module and push forward in core towards an accurate as the specification version of our css.

I volunteer to manage this Legacy Browsers module. I might even be able to get my company's QA department and Front end developers to help me properly support all the crazy edge cases for browsers out there.

Thoughts?

well safari4 is dead n gone after the last ios5 update :)
if we should do such a thing it should be to touch on ie8 actually, cause the big jump is gonna be there

ie7 is just waiting to die its gasping over in the corner, so it will be dead any day now ;)

I don't see a particular need to postpone this.

Agree, -webkit-border-radius is no longer in popular use and would be just code bloat to include it at this stage. And, since older browsers that don't support the border-radius rule, they will gracefully degrade to square edges.

In addition to this, there should be a standard guideline/rule for when to remove browser specific markup from core.

#19: remove_webkit_round_radius.patch queued for re-testing.

Patch redone for git clone d8 as of 1 hour ago

Method: git clone d8x, applied old patch, manually deleted webkit-border-.*radius lines in 2 bartik files, style.css and preview.css

Re-rolled manually with @frob & @jackc as part of LBC contribute meetup: http://groups.drupal.org/node/205643#comment-681798

• Pulled latest version of 8.x
• Identified code to be removed: grep -rin "webkit.*radius" *
• created patch

#28 reviewed and tested by community.

The diff between droplet's patch and mine (comments 26 and 27) is mine includes a remove for the file dashboard.css.

Correction, misreading the diff arrows. It's is mine without the dashboard.css remove. I withdraw my patch.

Droplet, we have been looking to talk with you, looking in IRC, etc. We are in freenode #ladrupal

@droplet , first, wish you were on IRC -- we wanted to chat with you about this so we didn't duplicate effort.

However, we didn't include 3rd party stylesheets.
We did use:

core/themes/seven/jquery.ui.theme.css

but that is a themefile. no?

However, were split on wether to remove from simpletest ... and came down on the side if its removed, there's no reason for simpletest.

I just re-rolled patch without simpletest. still differences with @droplet #26.

I did a lot of research on this in the past and we can safely remove this in D8.
#33 is correct about the seven jquery theme file in seven.

RTBC++

I agree that we can move forward with this. It is a nice clean-up and it can/will increase momentum on front-end development. Committed to 8.x.