13120 2011-07-02 11:06:02 +0000 Delegate support to quirks-mode - make it have zero effect in no-quirks and almost-standards 2011-08-04 05:04:05 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC All RESOLVED WONTFIX http://dev.w3.org/html5/spec/text-level-semantics#the-wbr-element P2 normal --- 9350 9711 10342 13098 1 xn--mlform-iua ian ayg mike public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 50586 0 xn--mlform-iua 2011-07-02 11:06:02 +0000 REQUEST: should be made obsolete, in favour of the zero with space character (zwsp). JUSTIFICATON: According to the spec, the usecase for is "something which, for effect, is written as one long word". However: (1) The usecase is extremely narrow. (2) 's benefits over the zero width space character are unclear. It can be styled, and it apparently isn't copied to the clipboard. It can also be said to be easier to type. But if these effects are so important, why don't we also create similar elements for the other whitespace/invisible characters of Unicode? Other whitespace/invisble characters can also be difficult to type, so why does this character need element representation? (3) In praxis, authors do not have a clear picture of what the usecase for is. For example, Aryeh in a comment seemd to think the usecase is to avoid that long words make a table stretch (plus the extra benefit over the zero width character hat is not copied to the clipboard): http://www.w3.org/Bugs/Public/show_bug.cgi?id=13098#c8 Other authors, again (like myself) have seemed to think has something to do with hyphenation. (4) The zwsp should be used seldomly and concsiously. The fact that it is difficult to type, is a feature! (Though, OTOH, there are _several_ named character references for it which makes it easy enough to type!) But the fact that (which conceptually represents the zwsp character) is valid, will make authors use is it much more often than the use case permits. Why? Because its validity "favors" the zero width space character over the other invisble/whitespace Unicode characters that do not have an HTML element to represent their effect. (5) Authors in reality need something else: When a line break happens in the middle of a word because the word contains a element, the result is something which visually looks like two words. While this is in line with as HTML5 specifies it, what most authors using *really* want/need, is a <shy> element which would make the word become *hyphenated* at the point where <shy> is located. So, if remains valid, we should create a lot more white space elements as well. (6) Internet Explorer version 8 and 9 has removed support for - they now only support it in Quirks-Mode. Opera still does not support it. In contrast, the zero width character is supported by both Webkit; Firefox, Opera and IE - in standards mode as well. (7) Keeping this element conforming only distracts authors and vendors attention from more important things. (For instance, some web browsers, like Konquerer and some text browsers, have support for but do not have support for the zwsp character.) (8) Even if we make it obsolete, conforming HTML5 parsers are still required to support it. Thus, it is pretty risk free. In fact, wasn't even mentioned in HTML4, so the fact that it gets obsolete status, can in fact be seen as a form of recognition ... (9) Currently (in HTML5/XHTML1.x), the is non-conforming. And since the benefits of are so unclear while its drawbacks are so clear, it makes no sense to spend time advocating its validity. 50587 1 xn--mlform-iua 2011-07-02 11:09:23 +0000 (In reply to comment #0) Typo: > (9) Currently (in HTML5/XHTML1.x), Sorry. Meant **(in HTML4/XHTML1.x)**. > the is non-conforming. And since the > benefits of are so unclear while its drawbacks are so clear, it makes no > sense to spend time advocating its validity. 50593 2 xn--mlform-iua 2011-07-02 11:57:04 +0000 (In reply to comment #0) JUSTIFICATION continued: 10) FUD: Keeping valid only serves to sustain FUD about how well browsers support the Zero Width Space character (zwsp). For example, pointing to the lackign support for zwsp in very legacy IE6, Wikipedia gives the impression that is better supported than the Zero Width Space character: [link] ]] In HTML pages this space can be used as a potential line-break in long words as a replacement for the non-standard tag. However, the zero-width space is not supported in all web browsers, most notably Internet Explorer version 6 and below[1]. [[ [link] http://en.wikipedia.org/w/index.php?title=Zero-width_space&oldid=435186349 The reality is of course the opposite: Zero Width Space character is *better* supported than . [11] Too many options: HTML5 includes 5 named character references for the zwsp character. Thus authors have enough options. The option only serves to create confusion about the benefits of the character versus the element. [12] If "simple to type" is an argument then &zwsp; can be made a valid named character references, as requested in Bug 1310. 50594 3 xn--mlform-iua 2011-07-02 11:58:49 +0000 (In reply to comment #2) > (In reply to comment #0) Typo: > [12] If "simple to type" is an argument then &zwsp; can be made a valid named > character references, as requested in Bug 1310. Sorry, meant Bug 13108. 50596 4 xn--mlform-iua 2011-07-02 13:13:00 +0000 (In reply to comment #2) > (In reply to comment #0) > 10) FUD: Keeping valid only serves to sustain FUD about how well browsers > support the Zero Width Space character (zwsp). [...] IE6, Wikipedia The IE6 bug actually only occurs in combination with certains fonts that are lacking the zwsp characters: http://dunae.ca/2009/better-web-typography-with-spaces-and-hyphens/ I am not able to reproduce this bug - may be because the fonts have improved? It is anyway purely an aficionado bug in a irrelevant web browser. (Aficionados will be able to fix it - probably like this: .) 50597 5 xn--mlform-iua 2011-07-02 13:28:05 +0000 Test cases: http://malform.no/testing/html5/wbrzerowidthspace.html 50618 6 ayg 2011-07-03 17:16:10 +0000 Use-cases were presented by Maciej in bug 9350, where he pointed out that its behavior does not match zwsp or any construct specifiable using CSS. Specifically, it overrides white-space: """ The wbr element is expected to override the 'white-space' property and always provide a line-breaking opportunity. """ http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1 *** This bug has been marked as a duplicate of bug 10342 *** 50632 7 xn--mlform-iua 2011-07-04 05:56:55 +0000 (In reply to comment #6) > Use-cases were presented by Maciej in bug 9350, Bug 9350 has been reopened. > where he pointed out that its > behavior does not match zwsp or any construct specifiable using CSS. > Specifically, it overrides white-space: > > """ > The wbr element is expected to override the 'white-space' property and always > provide a line-breaking opportunity. > """ These argumetns have been questioned in 8th comment of Bug 9350: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9350#c8 > http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1 > > *** This bug has been marked as a duplicate of bug 10342 *** Obsoletation isn't enough. Parser support for should be delegated to quirks-mode. Thus, this bug has been renamed to: "Delagate support to quirks-mode - make it have zero effect in no-quirks and almost-standards". JUSTIFICATION for delagating it to quirks-mode: * is conceptually very unclear and misunderstood. There is no unique usecase. * no single browser implements it in sane way - they all differ See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9711#c2 * IE has already delagated support to Quirks-Mode only. * Making have zero effect in standards mode is pretty risk free: Due to the fact that no browser really implements in full, the text levels effects (that is: the effects on searching, selection, doubleclicking, clipboard copying) are in some cases zero and in other cases close to zero. For more arguments, see my comments in the bugs that I have made this bug dependent on. 50743 8 ayg 2011-07-06 19:53:11 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Quirks mode is evil -- it makes the platform significantly more confusing and complicated, both for authors and implementers. We want to keep the differences between quirks and standards to an absolute minimum. The only grounds for standardizing quirks are if they have to be quirks for web compat, or (theoretically) if the behavior is extremely horrible but we can't get rid of it completely but we could get away with making it a quirk. In this case, if we don't want support for , we can remove support entirely. As you point out, compat is not an insurmountable issue here, since browsers don't consistently support it anyway. Thus we should get rid of it if we don't want it, and keep it in all modes if we do. Making it quirks-only is the worst of all worlds. 52766 9 mike 2011-08-04 05:04:05 +0000 mass-moved component to LC1