[Bug 13120] New: Obsolete <wbr>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13120

           Summary: Obsolete <wbr>
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://dev.w3.org/html5/spec/text-level-semantics#the-
                    wbr-element
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


REQUEST: <wbr> should be made obsolete, in favour of the zero with space
character (zwsp). 

JUSTIFICATON: According to the spec, the usecase for <wbr> is  "something
which, for effect, is written as one long word". However:

(1) The <wbr> usecase is extremely narrow. 

(2) <wbr>'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
<wbr> 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 <wbr> 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 <wbr> 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 <wbr> (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 <wbr> element,  the result is
something which visually looks like two words. While this is in line with <wbr>
as HTML5 specifies it, what most authors using <wbr> *really* want/need, is a
<shy> element which would make the word become *hyphenated* at the point where
<shy> is located. So, if <wbr> remains valid, we should create a lot more white
space elements as well.

(6) Internet Explorer version 8 and 9 has removed support for <wbr> - 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 <wbr> 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, <wbr> 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 <wbr> is non-conforming. And since the
benefits of <wbr> are so unclear while its drawbacks are so clear, it makes no
sense to spend time advocating its validity.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 2 July 2011 11:06:04 UTC