[webkit-dev] Fwd: IDNA, IRI, HTML5 coordination
Hi, I just thought that we want to keep our eyes on what's being done on these fronts and give feedback if necessary. Jungshik -- Forwarded message -- From: Larry Masinter masin...@adobe.com Date: 2009/9/16 Subject: IDNA, IRI, HTML5 coordination To: public-...@w3.org public-...@w3.org Goal: bring together and coordinate the definitions of what is used for resource identification in the web and elsewhere (IRIs as the evolution of URL, URI, IRI, HREF, Web Address, etc.) within W3C, IETF and their specifications. See design goals below. Goal of this message: lay out the concerned groups, start discussion of process for coordination. I've bcc'd everyone except the public-...@w3.org mailing list, archive http://lists.w3.org/Archives/Public/public-iri/ as the list proposed for discussion: My suggestion for how to get all of these groups to coordinate is to start an IETF working group with a charter to bring these specifications into alignment. I can't think of any other process which can accomplish the goal. PLEASE, PLEASE: if you're going to post an opinion, please at least cc public-...@w3.org and try to keep discussion there. PLEASE: Separate 'process' issues (should there be a working group? Who else needs to be involved? What's the timing and when?) from technical issues. Thanks, Larry = (Incomplete) list of specifications, groups, chairs, editors: HTTP: [HTTPBIS-URI] HTTP URI scheme def in HTTPBIS draft: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2 [HTTP-RFChttp://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-9.2%0A[HTTP-RFC] current HTTP URI scheme definition in RFC 2616 http://tools.ietf.org/html/rfc2616#section-3.2.2 [HTTPBIS-WG http://tools.ietf.org/html/rfc2616#section-3.2.2%0A[HTTPBIS-WG] IETF HTTPBIS working group charter: http://tools.ietf.org/wg/httpbis/charters http://www.ietf.org/dyn/wg/charter/httpbis-charter.html mailing list: ietf-http...@w3.org, archives http://lists.w3.org/Archives/Public/ietf-http-wg/ chair: Mark Nottingham m...@mnot.net editors: Roy Fielding field...@gbiv.com, Julian Reschke julian.resc...@greenbytes.de, (others) IDNA: [IDNABIS-*] definitions, policies, standards for how Internationalized Domain Names should be handled in Internet applications http://tools.ietf.org/html/draft-ietf-idnabis-defs/ [IDNABIS-WG] IETF IDNABIS working group charter: http://www.ietf.org/dyn/wg/charter/idnabis-charter.html chair: Vint Cerf v...@google.com editor: John C Klensin klen...@jck.com IRI: [IRIBIS-6] Revision under preparation: http://tools.ietf.org/html/draft-duerst-iri-bis-06 [IRIBIS-LMMhttp://tools.ietf.org/html/draft-duerst-iri-bis-06%0A[IRIBIS-LMM] (Experimental draft attempting to satisfy IDNABIS and HTML requirements) http://larry.masinter.net/iribis-hack.html ( http://tools.ietf.org/rfcdiff?url1=draft-duerst-iri-bis.txturl2=http://larry.masinter.net/iribis-hack.txt ) discussion on: public-...@w3.org (among others) (other)editors: Martin Dürst due...@it.aoyama.ac.jp Michel SUIGNARD mic...@suignard.com Mailto URI: [MAILTO-RFC] Mailto: URI scheme Current: http://tools.ietf.org/html/rfc2368 [MAILTO-BIS http://tools.ietf.org/html/rfc2368%0A[MAILTO-BIS] In preparation http://tools.ietf.org/html/draft-duerst-mailto-bis-06 (other) editors (including) Martin Dürst (due...@it.aoyama.ac.jp) discussion on: u...@w3.org URI: [URI-RFC] URI spec http://tools.ietf.org/html/rfc3986 mailing list: u...@w3.org (other) editors: Roy Fielding field...@gbiv.com, Tim Berners-Lee ti...@w3.org [URIREG-RFC] URI guidelines: policies and procedures for registering new URI schemes http://tools.ietf.org/html/rfc4395 editors: Tony Hansen t...@att.com mailing list for URI review: uri-rev...@ietf.org HTML5: [HTML5-CURRENT] HTML5 definition of URLs http://dev.w3.org/html5/spec/Overview.html#urls [WEBADDRESS] Attempt to split out Web Address component: http://www.w3.org/html/wg/href/draft [HTML-WG http://www.w3.org/html/wg/href/draft%0A[HTML-WG] W3C Working Group charter: http://www.w3.org/html/wg/ URL/IRI issue: http://www.w3.org/html/wg/tracker/issues/56 chairs: Paul Cotton paul.cot...@microsoft.com Maciej Stachowiak m...@apple.com Sam Ruby ru...@intertwingly.net editor: Ian Hickson i...@hixie.ch Other interested groups: IETF Applications area mailing list: apps-disc...@ietf.org area directors: Lisa Dusseault lisa.dussea...@gmail.com; Alexey Melnikov alexey.melni...@isode.com W3C TAG (architectural issue around URIs in W3C specs) mailing list: www-...@w3.org archive http://lists.w3.org/Archives/Public/www-tag/ issue: http://www.w3.org/2001/tag/group/track/issues/27 chair: Noah Mendelsohn noah_mendels...@us.ibm.com [WHATWG] http://www.whatwg.org/ (Have I missed any
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
Thank you all for the comments. I'll write to whatwg and public-html about adding it to window.navigator (yes, I meant navigator :-)) ). 2009/7/22 Alexey Proskuryakov a...@webkit.org: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? Thank you for the reference. It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html. Most of pages (Netscape directory server?) referred to there are not available any more. http://gun.teipir.gr/ds/csearch is still up and fails in Chrome, Firefox 3, and IE 8 because they all send Accept-Language with q-values. The page I got back from the server in Firefox and Chrome is 'funny': 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en A-L sent was ko,en-us;q=0.8,zh;q=0.5,en;q=0.3 (IE8 'fails' to load the page, too, but it just shows an HTTP error message). There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. https://bugs.webkit.org/show_bug.cgi?id=3510#c2 has a reference to Outlook Webaccess, but that's about 'ru-ru' vs 'ru'. There's a bug report against Chrome about an 'opposite' case. We used to send languages without a q-value (which means everything gets q=1.0). See http://crbug.com/3970 Safari should just work for this case, though because the page in question works when only a single language is sent with no q-value. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. Yes, I agree. Safari takes the languages from system configuration. Aha.. right. I forgot that when I wrote the first email in the thread. Jungshik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
Hi,
I proposed exposing the values of the Accept-Langauge list via
window.navigation.acceptLanguages at
https://bugs.webkit.org/show_bug.cgi?id=27555
This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know what others her think about it.
Currently, the UI language of a browser is exposed with
window.navigation.language. This can be used by a 'web application' /
widget / browser extension to 'behave differently' per the UI
language.
A lot of web servers also take into account the value of
Accept-Language HTTP header field when determining the UI language of
their web apps or the language of contents to serve when multiple
language versions exist. Moreover, most browsers (Safari, Chrome,
Firefox, IE, and so forth) allow users to add, delete, move up and
down a language to the prioritized list of languages they understand
Some web apps/widgets/browser extensions can also benefit from knowing
the ordered list of languages in Accept-Language.
One particular use case Chrome has in mind is to determine the target
language of translation without a user-intervention. If the source
language is A and the A-L list has {B, C, D}, the target language can
be determined by walking through the list and picking up the first
language for which the translation from A is available. If 'A' is in
the A-L list, perhaps the translation service should not be called. (
See http://crbug.com/14574 )
There might be other cases of 'multi-lingual' applications where the
knowledge of the A-L list can be helpful.
It can be exposed by adding either of the two below to window.navigation
readonly attribute DOMStringList acceptLanguages // a list of
language codes
readonly attribute DOMString acceptLanguages // a comma separated
language codes
Unlike in the Accept-Language http header field, a language in the
list will not have a q-factor associated with it. Instead, they're
sorted in the descending order of the priority.
Any opinion would be welcome.
Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oops. I meant reply-to-all but just replied to Darin. 2009/3/6 Jungshik Shin (신정식, 申政湜) js...@chromium.org 2009/3/6 Darin Adler da...@apple.com On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. Sorry for all the confusion. I mentioned the following on IRC and in the bug, but perhaps, I was not clear enough. What happened was that test results are correct, but actual test files (html files) that were svn-copied to a new location were NOT revised in the new place. (my patch has new html files, but during the landing, svn-apply did not work as intended and svn-copied files without actual changes went int). As a result, there's a mismatch between the expected result and what's supposed to be new test files (that ARE actually just the copies of the original tests). So, we can do any of the following (I'm also replying to Darin's question here). 1. What Dave suggested on IRC. 1a. Revise the original CSS 2.1 tests in place and remove what's added recently. (this will be done by landing the latest patch in bug 23482) 1b. Same end result as 1a: - roll out what's added recently right away without waiting for Dave's r+. - once Dave gives me a nod for in-place modification of the original tests, make that change. 2. Leave the original tests alone and just update 'new' test html files in fast/block/float to match expected results. If we do 1a/1b, I'm willing to talk to Ian once more about our changes and talk him into revising CSS 2.1 suite the same way. I already asked him in the bugzilla, but he may have missed it. #2 was what was agreed upon and what my second latest patch does, but yesterday, Dave said that it's better to revise the original tests in place. So, I made the latest patch (3rd patch in the bug) and asked him for review. Jungshik I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
