ISSUE-172: forever drop the <rb> element
========================================

SUMMARY

The <rb> element adds nothing, has no use cases that are not already
handled, and would be expensive to add.


RATIONALE

The <rb> element is unnecessary.

  The element has no use cases that are not already handled by HTML as
  it stands today. For example, one use case sometimes posited is that
  it is necessary to style the base of a ruby span, e.g. to make ruby
  text be blue. However, this is easy to do already with a <span>
  element, the same as is done everywhere else in HTML.

  The element has no use cases that are actually real. For example,
  one use case sometimes posited is that it is necessary to style the
  base of a ruby span, but in practice this is almost never done,
  certainly it is not done frequently enough that it deserves a
  dedicated element. Evidence of this is discussed in depth in the
  bug, for instance:

    http://www.w3.org/Bugs/Public/show_bug.cgi?id=10830#c53

  Semantically, the <rb> element does not add anything: the "base"
  part of the ruby can be trivially inferred from context as being
  anything that's a child of the <ruby> but not a child of the <rp> or
  <rt> elements. This is already defined in the spec.


The <rb> element makes authoring harder for authors who use it and
then want to make minor changes.

  Suppose an author wanted to style a ruby base after all, e.g. to
  highlight it. What if they then wanted to change their markup so
  that only a part of the ruby base was highlighted, e.g. excluding
  punctuation? The <rb> element would need to be changed to a <span>
  anyway, so that it could surround just the non-punctuation parts.


The <rb> element is not supported by legacy UAs.

  The <rb> element is treated like an unknown element by legacy UAs.
  For example, the following:

     <ruby>
       <rb> Base
       <rt> Text
     </ruby>

  ...results in the same DOM structure as the following:

     <ruby>
       <rx> Base
       <rt> Text
     </ruby>

  ...in IE9, Opera, Chrome, Firefox, and Safari.

  Similarly, the following:

     <ruby>
       <rb> Base1
       <rt> Text1
       <rb> Base2
       <rt> Text2
     </ruby>

  ...results in a DOM structure that has the second <rb> _inside_ the
  first <rt>.


Adding <rb> support to browsers is expensive.

  To support this new element would require changes in the parser.
  Changes to the parser are high-risk, as the parser is used with
  every page load.


Adding <rb> introduces new error conditions that make authoring harder.

  If we add an <rb> element, we have to define what all of the
  following cases mean:

    - two <rb> elements as adjacent sublings
    - an <rb> element as an adjacent sibling to non-whitespace text
    - an <rb> element outside a <ruby> element

  These are all error conditions that cannot occur if the element is
  simply never valid: the element would simply have no meaning in all
  cases if it was not valid.


DETAILS

No change.


IMPACT

Positive effects (relative to the alternative proposal)
* Simpler for authors.
* Simpler for implementors.
* Supports all the use cases.

Negative effects (relative to the alternative proposal)
* Minor short-term inconvenience for authors using existing
  ruby-supporting templates with the old syntax who wish to conform to
  the new syntax. This would not be time-sensitive, however, since
  anything with <rb> that already works in browsers (i.e. is already
  working around the lack of browser support) would keep working.

Conformance classes changes
* None.

Risks
* None: this is what browsers have always implemented.