Bug 138068

Summary: Contenteditable has break-word and -webkit-line-break by default
Product: WebKit Reporter: Greg Whitworth <gwhit>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: bfulgham, gwhit, karl+webkit, rniwa, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
top to bottom: Gecko, Blink, WebKit none

Greg Whitworth
Reported 2014-10-24 23:12:41 PDT
We have had a couple sites submitted to us that aren't working for our users due to an interop issue between IE/FF & Chrome/Safari. It seems that webkit based browsers add break-word and -webkit-line-break to contenteditable containers by default, where as FF/IE treat them as the boxes that they originally were, just editable. I brought this up to the CSS WG and there was agreement that Blink/Webkit should change to match FF/IE's behavior. Here is a fiddle that shows the issue: http://jsfiddle.net/pfe9mj4o/10/ Here is the W3C thread regarding the issue: http://lists.w3.org/Archives/Public/www-style/2014Oct/0408.html If you have any questions or comments feel free to reach out to me. Thank you.
Attachments
top to bottom: Gecko, Blink, WebKit (64.99 KB, image/png)
2022-01-08 16:13 PST, karl 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
karl
Comment 1 2022-01-08 16:12:29 PST
Another possible test data:text/html,<!doctype html><html><div style="border: 1px solid black; width: 5ch;" contenteditable>AAAAAAA</div> This is done here. https://github.com/WebKit/WebKit/blob/14129e759715bb8535b8b7a7512860f79fba2993/Source/WebCore/html/HTMLElement.cpp#L201-L208 case ContentEditableType::True: addPropertyToPresentationalHintStyle(style, CSSPropertyWordWrap, CSSValueBreakWord); addPropertyToPresentationalHintStyle(style, CSSPropertyWebkitNbspMode, CSSValueSpace); addPropertyToPresentationalHintStyle(style, CSSPropertyLineBreak, CSSValueAfterWhiteSpace); #if PLATFORM(IOS_FAMILY) addPropertyToPresentationalHintStyle(style, CSSPropertyWebkitTextSizeAdjust, CSSValueNone); #endif break; It seems to have been there for a long time. moved from Frame.cpp into HTMLElementImpl.cpp https://github.com/WebKit/WebKit/commit/c68912f97deea7782d6c1b6aab872e5d93365de2 It was carried away from on Oct 15, 2004 https://github.com/WebKit/WebKit/commit/9d7af8297974d9263c22f90d43074ebbbe439381#diff-c8205393c9f57e84bfe70e703391bcc951d7d0b9177394c638d35905eed918ccR5493-R5503 In Gecko the [contenteditable] CSS is available in a dedicated CSS https://searchfox.org/mozilla-central/source/layout/style/contenteditable.css https://bugzilla.mozilla.org/show_bug.cgi?id=237964 (June 2007) The discussion on the CSS mailing-list never reached a conclusion. I filed a bug on Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1749163
karl
Comment 2 2022-01-08 16:13:23 PST
Created attachment 448686 [details] top to bottom: Gecko, Blink, WebKit Screenshots showing the issue in the latest version of the browser as of today.
karl
Comment 3 2022-01-08 16:20:26 PST
Google seems to have made attempts at fixing Blink. https://bugs.chromium.org/p/chromium/issues/detail?id=427135
karl
Comment 4 2022-01-08 16:24:59 PST
More recent discussions about this ~2016 https://github.com/w3c/editing/issues/145
Radar WebKit Bug Importer
Comment 5 2022-07-14 13:23:07 PDT
<rdar://problem/97031484>
Note You need to log in before you can comment on or make changes to this bug.