Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore the rb and rtc elements and update ruby content model accordingly #6478

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

frivoal
Copy link
Contributor

@frivoal frivoal commented Mar 11, 2021

This pull request un-obsoletes the rb and rtc elements, changes the content model to take them into account, and updates the rendering section accordingly. It does not make any changes to parsing.

As discussed in #1771, the ruby model currently defined in the HTML spec isn't quite enough to support the needs of ruby. The additional rb and rtc elements are needed to properly express the full semantics that need to be there for styling and fallback to work properly. See explanation in fantasai’s blog post (which the CSS Ruby Layout spec and the proposed markup model are both based on) and in the proposed specification text itself.

The model defined here is the same one that had been defined in the old W3C HTML5 specification. The pull request contains two commits: one that imports the W3C spec text, and one that substantially reworks the prose and examples to better explain its semantics. We recommend reviewing the combined result; the commit split is largely to preserve history.

CC @r12a @kojiishii @upsuper


💥 Error: 503 Service Unavailable 💥

PR Preview failed to build. (Last tried on Oct 6, 2021, 12:47 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 HTML Diff Service - The HTML Diff Service is used to create HTML diffs of the spec changes suggested in a pull request.

🔗 Related URL

<html><body><h1>503 Service Unavailable</h1>
No server is available to handle this request.
</body></html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

@frivoal frivoal force-pushed the ruby-ng branch 2 times, most recently from 3f22240 to 77c1733 Compare March 11, 2021 06:52
@frivoal
Copy link
Contributor Author

frivoal commented Mar 11, 2021

The auto-generated previews don't seem to include images. Since they're quite useful for this section of the spec, here's a built copy which includes images: https://html.rivoal.net/multipage/
In particular: https://html.rivoal.net/multipage/text-level-semantics.html#the-ruby-element

@domenic domenic added the do not merge yet Pull request must not be merged per rationale in comment label Mar 11, 2021
source Outdated Show resolved Hide resolved
@xfq
Copy link
Contributor

xfq commented Mar 13, 2021

@domenic domenic added the needs implementer interest Moving the issue forward requires implementers to express interest label Mar 16, 2021
@frivoal
Copy link
Contributor Author

frivoal commented Mar 17, 2021

(edited the original comment to mention support by Amazon, as described in #1771 (comment))

@murata2makoto
Copy link

If this pull request is not merged in the near future and W3C publishes a separate note as well as CSS Ruby, we will have two versions of Open Web Platform. We should strongly avoid that.

@annevk
Copy link
Member

annevk commented May 20, 2021

Wouldn't you say that the version of the web platform users and developers experience is what implementations are shipping and willing to ship, which is the sticking point to getting this landed? It does seem weird that Google and Apple would be on board with CSS Ruby, but not with this...

@domenic
Copy link
Member

domenic commented May 20, 2021

My understanding is that Google and Apple are happy to not formally object to CSS Ruby being worked on by its editors, but they have not made any movement to implement it.

I think the framing in @murata2makoto's comment is needlessly inflammatory. There are at least three versions of the web platform: those implemented by WebKit, Gecko, and Blink respectively. They are not always in sync. And there are different specs covering different aspects of them.

Right now, and for the foreseeable future, the Gecko version of the web platform supports CSS Ruby and rb/rtc. The WebKit/Blink version does not. This is similar to how the Blink version of the web platform supports Web Serial, and the WebKit/Gecko versions do not. This is OK, and happens all the time. It's how we move the web forward.

@murata2makoto
Copy link

murata2makoto commented May 20, 2021

You might think that I am blaming WHATWG, but I am not. I am just saying what is happening is not good. In spite of the twenty-five year history, ruby standardization is unlikely to happen.

@sideshowbarker
Copy link
Contributor

@murata2makoto Recalling the latest statements from Chrome and Safari reps regarding the changes proposed in this PR —

At #1771 (comment) on 2021-03-12, @kojiishi said:

At this moment, we do not have a plan to update ruby support in Chromium more.

At #1771 (comment) on the same day, 2021-03-12, @rniwa said:

I don't think there is much traction / appetite to fix that situation in WebKit / Blink at the moment. I don't think anyone will be opposed if anyone is interested in fixing this bug / behavior in WebKit to rectify that situation if any but the reality is that I don't think there is any active effort to improve the ruby support in WebKit at the moment, or I'm at least not aware of it even if we're interested in improving our support in the long term.

And to be specific about what seems to be getting requested that Chrome and Safari don’t plan to implement:

we don't support multiple rt getting displayed atop the corresponding rb

So even if the HTML editors were to merge this patch immediately, the real problem in practice would remain that Chrome and Safari project reps have clearly stated they have no plans to actually implement it — and the existence of the requested requirements in the HTML spec would no more make the Chrome and Safari projects change their minds about this than the existence of this PR.

So with respect to everyone involved here, I would like to point out that if you want to get the requested requirements implemented in Chrome and Safari, the possible productive ways to actually make that happen do not seem to include repeatedly lobbying the HTML editors to prematurely merge PRs into the HTML spec.

Instead the actual productive ways to make the requested requirements get implemented in Chrome and Safari are to either:

  • figure out how to present a convincing case to the Chrome and Safari projects to reverse their stated positions and actually commit to implement the requested requirements; or else:
  • get some third parties to commit to working on browsers patches for Chrome and Safari, or both, that implement the requested requirements in the Chrome and Safari sources

And I say all that with full agreement that the requested requirements are clearly important and have very compelling use cases — and if it were within my experience and abilities to implement the support for them myself in the Chrome and Safari code, I would stop everything else I’m doing and instead work on implementing browser patches for it myself until I had something that could be landed in the Chrome and Safari code.

But the reality is that I don’t myself have the experience and abilities needed to do that work.

But clearly there are other people around who do have the experience and abilities needed. So if those of you who have been advocating here in this issue tracker for these requirements to be supported would be interested in putting some effort together into finding a way to get someone with the necessary experience and abilities actually working on implementing browser patches for it, I would be very happy to join that effort.

@frivoal frivoal force-pushed the ruby-ng branch 2 times, most recently from dbda7c3 to a77934e Compare July 26, 2021 22:35
source Show resolved Hide resolved
source Show resolved Hide resolved
@litherum
Copy link

litherum commented Oct 6, 2021

I don't think anyone will be opposed if anyone is interested in fixing this bug / behavior in WebKit

present a convincing case to the Chrome and Safari projects to reverse their stated positions

@rniwa is right - I would love to work on improving ruby support in WebKit, but doing so isn't near the top of my to-do list. This is very different than a negative position on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge yet Pull request must not be merged per rationale in comment needs implementer interest Moving the issue forward requires implementers to express interest topic: ruby
Development

Successfully merging this pull request may close these issues.

10 participants