W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2012

I18N-ISSUE-158: Bug 13113 - Parsing algorithm should not preclude Complex Ruby [.Adhoc-HTML]

From: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 13 Apr 2012 15:53:48 +0000
Message-Id: <E1SIiom-00072I-DW@tibor.w3.org>
To: public-i18n-core@w3.org
I18N-ISSUE-158: Bug 13113 - Parsing algorithm should not preclude Complex Ruby [.Adhoc-HTML]

http://www.w3.org/International/track/issues/158

Raised by: Richard Ishida
On product: .Adhoc-HTML

Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13113


Raised by: Henri Sivonen 2011-07-01 13:33:34 UTC

Continuing from bug 12935.

I have spent some more time implementing variations and experimenting
with them. I'm now ready to request specific edits.

Please make the following spec edits:

 1) Please add rb, rbc and rtc to the list of elements that get closed
by "generate implied end tags" at
http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#generate-implied-end-tags

 2) Please replace the "in body" entry for 'A start tag whose tag name
is one of: "rp", "rt"' with these three entries:

A start tag whose tag name is one of: "rbc", "rtc"

    If the stack of open elements has a ruby element in scope, then
generate implied end tags.

    Insert an HTML element for the token.

A start tag whose tag name is one of: "rb"

    If the stack of open elements has a ruby element in scope, then
generate implied end tags, except for elements with the name "rbc".

    Insert an HTML element for the token.

A start tag whose tag name is one of: "rt", "rp"

    If the stack of open elements has a ruby element in scope, then
generate implied end tags, except for elements with the name "rtc".

    Insert an HTML element for the token.


Note that the "If the stack of open elements has a ruby element in
scope, then" parts are just copying the current spec text. I don't see
the value of that bit and would be OK with omitting the scope check.

Rationale:

We shouldn't paint ourselves in the corner with the parsing algorithm so
Complex Ruby can't be introduced in the future without causing ungraceful
behavior in browsers implementing an earlier snapshot of the parsing spec.

The changes proposed above assume a design where rp goes as a child of rtc (if
rp is used at all) in the Complex Ruby case. This allows UAs that implement
Simple Ruby be forward-compatible by having
   rp { display: none; }
   rtc > rt { display: inline; }
   rtc > rp { display: inline; }
in the UA style sheet while UAs supporting both Simple and Complex Ruby would
have
   rp { display: none; }
in the UA style sheet without the two other rules.
Received on Friday, 13 April 2012 15:53:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 April 2012 15:53:56 GMT