triple-underscore / triple-underscore.github.io Goto Github PK

In https://triple-underscore.github.io/RFC7231-ja.html#section-8.1.3

Table says "POST" as Yes(safe) / Yes(Idempotent)
but Original RFC says No for both.

Sanitizer API is a security related new API which calling for consensus on FPWD now. It says that Chrome / Firefox working on implement it.
So I believe it's wonderful for JP folks to see your translate here. Thanks !

https://html.spec.whatwg.org/multipage/scripting.html#the-script-element

Classic scripts and JavaScript module scripts can be embedded inline, or be imported from an external file using the src attribute, which if specified gives the URL of the external script resource to use. If src is specified, it must be a valid non-empty URL potentially surrounded by spaces.
The contents of inline script elements, or the external script resource, must conform with the requirements of the JavaScript specification's Script or Module productions, for classic scripts and JavaScript module scripts respectively. [JAVASCRIPT]
The contents of the external script resource for CSS module scripts must conform to the requirements of the CSS specification. [CSS]
When used to include data blocks,

https://triple-underscore.github.io/HTML-scripting-ja.html#the-script-element

［ 古典スクリプト, JavaScript モジュールスクリプト ］どちらも、 インラインに埋め込むことも， src 属性を指定して 外部ファイルから取り込むこともできる。 この src 属性値は、 利用する外部スクリプトリソースの URL を与える — その値は、前後空白可の妥当かつ空でない URL でなければならない。
［ インラインな script 要素 ／ 外部スクリプトリソース ］の内容は、［ 古典スクリプトの場合は JavaScript 仕様 [JAVASCRIPT] の Script 生成規則／ JavaScript モジュールスクリプトの場合は 同仕様の Module 生成規則 ］による要件に適合しなければならない。
script 要素を，データブロックを含ませるために利用する場合：

両者を比較してみると、「The contents of the external script resource for CSS module scripts must.....」の訳が抜けているような気がするので、ご確認を。

Hi Team

CBOR is the generic serialize format which referred by lots of specs now. (ex. WebAuthnN, Trust Token, etc etc etc)
It'd be happy for JP devs if your translations are published.

Thanks
Jack

https://triple-underscore.github.io/HTML-form-elements-ja.html#placeholder-label-option のselect要素の仮入力ラベル選択肢を決定するアルゴリズムですが、第4段で

IF［ O の値 ＝ 空文字列 ］ RETURN ε

となっているのは

IF［ O の値 ≠ 空文字列 ］ RETURN ε

が正しいのではないでしょうか。

I noticed you have a great set of translations of WHATWG standards. Would you mind if they were linked from the English version? E.g., https://notifications.spec.whatwg.org/ points to a Simplified Chinese translation. It would be great for https://url.spec.whatwg.org/, https://dom.spec.whatwg.org/, etc. to point to their Japanese translation I think. What do you think?

https://triple-underscore.github.io/mediaqueries4-ja.html#media-conditions

primaryの訳が、 主 になるところが 首 になっているようです。

- または 首ポインタ指示装置が hover 能力を有さない
+ または 主ポインタ指示装置が hover 能力を有さない

ここ以外の箇所でも、同じようにprimaryの訳が主になるところが首になっているようですが、これらは誤字でしょうか？

In section 3.1, there's the sentence: "If the user agent can service a request out of a local cache, that request MUST NOT result in a network request."

There are a couple issues here:

1. "request" is not defined. I assume the spec should take this from the fetch standard in addition to "network request", but it does not.
2. More concerningly is the "MUST NOT result in a network request" - this seems to imply the spec is incompatible with the stale-while-revalidate spec. I don't think the spec should be making claims about when a network request should or should not be made. That's really the job of the fetch spec. Also, more generally when a "network request" should or should not be made doesn't seem like it should be part of the spec - that should really be the job of the fetch spec, no? That avoids inconsistencies between the two specs.
3. Also, section 3.1 claims "there MUST be separate network requests for each request in the redirect chain" - this certainly is not the case of how fetch works today, as some requests in a redirect chain might be cached, and some not. This again seems like it really should defer to the fetch spec.
4. "A request MUST NOT result in a network request if the user agent is known to be offline (i.e., when navigator.onLine returns false)." - is this saying localhost requests should fail when navigator.onLine returns false? Again, this seems to be intruding on the fetch standard's territory. A browser can't even know if a given domain name is local or remote without doing DNS resolution first.

Hi, IETF published new RFC for Oblivious HTTP
https://www.rfc-editor.org/rfc/rfc9458.html

It's very important standard for make internet secure and safe for privacy.
It'd be nice if you publish translation of this spec for Japanese engineer.

Thanks
Jxck

下記の両者を比較すると、翻訳の方では、oncontextlostとoncontextrestoredが漏れているのでご確認をお願いします。

https://triple-underscore.github.io/HTML-dom-ja.html#global-attributes
「次に挙げるイベントハンドラ内容属性は、どの HTML 要素上に指定してもよい：」のリスト

https://html.spec.whatwg.org/multipage/dom.html#global-attributes:event-handler-content-attributes
「The following event handler content attributes may be specified on any HTML element:」のリスト

「6.1. 相対単位」の ch が

要素のフォントにおける半角グリフの代表的な文字送り幅 — 文字 “0” （ U+0030 ZERO ）のグリフで表現される。

となっていますが，原文は

typical character advance of a narrow glyph in the element’s font, as represented by the “0” (ZERO, U+0030) glyph

です。
「a narrow glyph」の訳として「半角グリフ」は妥当でないように思います。

「ASCII 16 進数字（大文字）」と「ASCII 英大文字」、「ASCII 英小文字」の範囲が原文と異なっていました。
https://triple-underscore.github.io/infra-ja.html#code-points

ASCII 16 進数字（大文字）
- { ASCII 数字, U+0061 (A) 〜 U+0066 (F) } 
+ { ASCII 数字, U+0041 (A) 〜 U+0046 (F) } 

ASCII 英大文字
- { U+0041 (A) 〜 U+0046 (Z) }
+ { U+0041 (A) 〜 U+005A (Z) }

ASCII 英小文字
- { U+0061 (a) 〜 U+0066 (Z) }
+ { U+0061 (a) 〜 U+007A (z) }

最後の「ASCII 英小文字」は Z → z の誤りもあります。
ご確認お願いします。

Hi team

It's so great to have translate of the BCP56bis. It's a Best Current Practice of using HTTP for developer who use HTTP not for developer who build HTTP implementation by mnot.

• Building Protocols with HTTP

It would help developer working on web service.

Thanks
Jxck