See also: IRC log
close ACTION-46
<trackbot> ACTION-46 Dump charmod-norm and add disclaimer paragraph, dates, etc. so that we can publish an interim working draft closed
close ACTION-45
<trackbot> ACTION-45 Publish qa-personal-names for wide review closed
reopen ACTION-46
<trackbot> ACTION-46 Dump charmod-norm and add disclaimer paragraph, dates, etc. so that we can publish an interim working draft re-opened
so close on action 56
Change 512 to 1024 in the charset declaration article
Figure out how to keep alive open bugs for the html5 LC
<scribe> ACTION: richard: send addison pisa conference materials as draft for IUC presentation [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action01]
<trackbot> Created ACTION-60 - Send addison pisa conference materials as draft for IUC presentation [on Richard Ishida - due 2011-08-03].
http://lists.w3.org/Archives/Public/public-i18n-core/2011JulSep/0022.html
http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/
<scribe> ACTION: addison: raise MediaResources issues in tracker and forward to relevant WG [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action02]
<trackbot> Created ACTION-61 - Raise MediaResources issues in tracker and forward to relevant WG [on Addison Phillips - due 2011-08-03].
richard: polyglot
...
<r12a> http://www.w3.org/International/track/products/4
<r12a> http://www.w3.org/International/track/issues/58
<r12a> ISSUE-58
since UTF-16 is no longer allowed in polyglot documents, should close
close ISSUE-58
<trackbot> ISSUE-58 In-document declarations always useful closed
http://www.w3.org/International/track/issues/60
ISSUE-60
<r12a> ISSUE-60: Omit the either/or list
<trackbot> ISSUE-60 Omit the either/or list notes added
rewritten, so no longer issue
close ISSUE-60
<trackbot> ISSUE-60 Omit the either/or list closed
Mention lang and xml:lang
ISSUE-61
richard: done now. <meta> content language now non-conforming
close ISSUE-61
<trackbot> ISSUE-61 Mention lang and xml:lang closed
Case requirements
ISSUE-62
richard: done, considerably rewritten
close ISSUE-62
<trackbot> ISSUE-62 Case requirements closed
richard: went through the bidi
list
... three remaining ones
http://www.w3.org/International/track/products/5
ISSUE-26
Please add support for rb
ISSUE-29
ruby code samples
addison: added to prep?
richard: no, reopened
ISSUE-30
Allow utf-16 meta encoding declarations
richard: on-going
... resolved "wontfix" by hixie
... good idea to reopen
addison: UTF-16 allowed in HTML documents but can't declare it
richard: BOM used to declare
addison: reopen it!
richard to open bug
ISSUE-32
rlo and lro attribute values
richard: "punt"
matial: don't see a lot of use for it; nice to have
close it
close ISSUE-32
<trackbot> ISSUE-32 rlo and lro attribute values closed
ISSUE-34
bdo element doesn't leave rendering up to presentation layer
close in favor of new issue
<r12a> http://www.w3.org/International/track/issues/34
close ISSUE-34
<trackbot> ISSUE-34 bdo element doesn't leave rendering up to presentation layer closed
http://www.w3.org/International/track/products/10
http://www.w3.org/International/track/products/12
ISSUE-76
Clarify 'preferred name' for encodings
http://www.w3.org/International/track/issues/76
richard: when ian says "preferred
name" means preferred name in registry if it exists or name at
top of entry
... the former is only 22 items
... link is missing here
comment accepted
ISSUE-76: comment accepted for HTML5 LC
<trackbot> ISSUE-76 Clarify 'preferred name' for encodings notes added
http://www.w3.org/International/track/products/11
ISSUE-72
BOM as preferred encoding declaration
richard: section that says how to
identify encoding
... one option is BOM and it says "preferred"
... later there is a note that says we (our WG) recommends the
<meta> element
... (and I started editing our article recommending against
BOM)
addison: BOM is evil :-)
ISSUE-72: accepted for Polyglot LC
<trackbot> ISSUE-72 BOM as preferred encoding declaration notes added
ISSUE-73
Case sensitivity of lang
richard: lang in list of
attributes that must be lowercase only
... becuase attributes handled case insensitive?
<r12a> http://www.w3.org/International/track/issues/73
addison: language tags themselves are case insensitive
richard: it's xml:lang that matters to xml processors
ISSUE-73: accepted for Polyglot LC
<trackbot> ISSUE-73 Case sensitivity of lang notes added
ISSUE-74
Remove Content-Language meta from polyglot
http://www.w3.org/International/track/issues/74
richard: all this wording about
fallbacks
... so content-language is non-conforming in HTML5 and thus
can't be used in polyglot
... so need to remove from polyglot
... 1. can't use C-L meta in polyglot documents (since
non-conforming)
... 2. therefore remove mention of it from fallback description
because irrelevant
ISSUE-74: accepted for Polyglot LC
<trackbot> ISSUE-74 Remove Content-Language meta from polyglot notes added
ISSUE-75
Section 11 is blank
non-I18N
personal/editorial comment
<r12a> http://www.w3.org/International/track/issues/75
<r12a> ISSUE-137
<r12a> http://www.w3.org/International/track/issues/137
html5 bidi support should be normative
richard: ian to add normative section on bidi rendering
http://www.w3.org/International/track/products/10
ISSUE-77
HTTP and defaulting to UTF-16LE
<r12a> http://www.w3.org/International/track/issues/77
If the HTTP header declares the file to be UTF-16BE, which I believe it can, and in which case a BOM should *not* be used, then I think that this would not be true. If the HTTP header declares the file to be UTF-16, then there must be a BOM, so I assume that this is a recovery mechanism if someone does declare UTF-16 in HTTP but omits the BOM. I'd think that some kind of error message would be in order though.
addison: seems straightforward
ISSUE-77: accepted for HTML5 LC
<trackbot> ISSUE-77 HTTP and defaulting to UTF-16LE notes added
http://www.w3.org/International/track/issues/78
ISSUE-78
The spellcheck attribute currently is limited to user-edited text. It would be useful to have some way of identifying content that should not be spellchecked in an editor or by an automated spellchecking service. It would seem most intuitive to use the same attribute for this, but more carefully distinguish between the case where the user agent is dealing with user editable text and non-user-editable text, if necessary.
addison: so a processing
instruction for editing tools??
... i18n issue? or general?
felix: borderline between ITS and
I18N and general
... think it's important
ISSUE-78: accepted for HTML5 LC
<trackbot> ISSUE-78 Spellcheck should work in editors notes added
ISSUE-79
Multilingual q quote rendering
http://www.w3.org/International/track/issues/79
It would be useful to add a note to this section to remind readers that the default characters used for quotation marks are set in the default stylesheet[1], and will vary depending on the user's locale and language preferences. But that users may need to override the defaults for text in a particular language, and that they can do so using the quotes property in CSS (http://www.w3.org/TR/CSS21/generate.html#quotes-specify).
addison: think this is a good comment
richard: there is a note that
UA's should take language into account
... language of the UA
addison: but that's wrong... should be language of content
gwyneth: does it take into
account spacing (such as french use of NBSP)
... CSS page doesn't indicate spaces
ISSUE-79: accepted for HTML5 LC
<trackbot> ISSUE-79 Multilingual q quote rendering notes added
ISSUE-80
Default rules for the quotes property
http://www.w3.org/International/track/issues/80
<r12a> http://www.w3.org/TR/html5/rendering.html#punctuation-and-decorations
"Rules setting the 'quotes' property appropriately for the locales and languages understood by the user are expected to be present." How are the locales and languages understood by the user determined? Is this related to the Accept-Language settings of the browser? I'm assuming that the requirement here is to provide a single default only per browser installation, rather than to provide defaults for text in various languages (which would be a nice plus). If
ISSUE-80: accepted for HTML5 LC
<trackbot> ISSUE-80 Default rules for the quotes property notes added
ISSUE-80: should apply rules based on the language of document
<trackbot> ISSUE-80 Default rules for the quotes property notes added
quote shapes based on language of document except potentially using browser language or A-L as an ultimate fallback
ISSUE-80: quote shapes based on language of document except potentially using browser language or A-L as an ultimate fallback
<trackbot> ISSUE-80 Default rules for the quotes property notes added
<r12a> http://www.w3.org/International/track/issues/80
ISSUE-81
Strip other line-terminators?
http://www.w3.org/International/track/issues/81
Where it says: -- When a user agent is to strip line breaks from a string, the user agent must remove any U+000A LINE FEED (LF) and U+000D CARRIAGE RETURN (CR) characters from that string. -- Should other line-terminators also be included here?
ISSUE-81: accepted for HTML5 LC
<trackbot> ISSUE-81 Strip other line-terminators? notes added
<r12a> http://www.w3.org/International/track/issues/81
ISSUE-82
Non-ASCII enumerated values
http://www.w3.org/International/track/issues/82
I realize that the set of "enumerated values" in HTML5 consists strictly of ASCII strings. However, there is no syntactical requirement that this be true. Non-ASCII values could be included into an enumerated value set, in which case, the "ACSII case-insensitive" match may be incomplete. Instead of using "ASCII case-insensitive", could Unicode case-folded matching be defined instead? This is stable, well-defined, and a strict superset of the ASCII case?
addison: somewhat pedantic, may not be worth raising?
ISSUE-82: rejected for LC
<trackbot> ISSUE-82 Non-ASCII enumerated values notes added
close ISSUE-82
<trackbot> ISSUE-82 Non-ASCII enumerated values closed
ISSUE-83
Note about why Gregorian only used
http://www.w3.org/International/track/issues/83
The section describes date values using strictly the Gregorian calendar. As long as the values are strictly internal (as a means of representing incremental or floating time values, cf. our note Working With Time Zones), this doesn't represent a barrier to the use of other calendric systems. Please include a note indicating this so that international users understand why Gregorian is used here.
ISSUE-83: accepted for HTML5 LC
<trackbot> ISSUE-83 Note about why Gregorian only used notes added
ISSUE-84
Representing BCE months
http://www.w3.org/International/track/issues/84
The 'months' definition only handles dates from the (proleptic) Gregorian year 0 in the common era going forwards. There is no way to represent BCE dates. Should there be?
month="1903-10"
gwyneth: need an "era"
field?
... need to explain this comment more
ISSUE-84: accepted for HTML5 LC
<trackbot> ISSUE-84 Representing BCE months notes added
ISSUE-85
Health warning about converting date to/from incremental time
The 'date' definition contains no time zone information. It is thus a floating date value and a health warning should be included about converting it to/from incremental time values.
date="2011-06-28T14:34:55.007"
ISSUE-85: accepted for HTML5 LC
<trackbot> ISSUE-85 Health warning about converting date to/from incremental time notes added
ISSUE-86
Option for 1 digit hour
ISSUE-85: mention efforts on JavaScript inclusion of zone info
<trackbot> ISSUE-85 Health warning about converting date to/from incremental time notes added
http://www.w3.org/International/track/issues/86
In parsing a 'time' value, the rule for the hours section is: "Two digits, representing hour, in the range 0 ≤ hour ≤ 23". Should this optionally allow only one digit?
richard: actually tripped over this
time="0:00:00"
ISSUE-86: accepted for HTML5 LC
<trackbot> ISSUE-86 Option for 1 digit hour notes added
ISSUE-86: many users will make this error and the result will be an error rather than a time
<trackbot> ISSUE-86 Option for 1 digit hour notes added
ISSUE-87
Leap seconds
http://www.w3.org/International/track/issues/87
There is a note disallowing the representation of leap seconds. This poses a potential problem for applications sensitive to leap seconds. Should the values be allowed, even if later processing does not deal with it?
<Gwyneth> The International Earth Rotation And Reference Systems Service (IERS) Earth Orientation Center is taking comments on whether to get rid of leap seconds. http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire
datetime="1980-01-01T00:00:60"
ISSUE-87: accepted for HTML5 LC
<trackbot> ISSUE-87 Leap seconds notes added
ISSUE-88
Local/floating date and time
This defines a 'global date and time', which is the same as a 'local date and time', only with a time zone representation. I propose changing the 'local' value to use the term 'floating' (since it is not truly local). The term 'global' could remain. I would also suggest adding a reference to w3.org/TR/timezone (our note) to help users understand when to use which type.
ISSUE-88: accepted for HTML5 LC
<trackbot> ISSUE-88 Local/floating date and time notes added
ISSUE-89
Time zones and local dates and times
<Gwyneth> I need to head out to another meeting. Sorry.
http://www.w3.org/International/track/issues/89
This section defines 'local dates and times', which is a date-and-time value *without* a time zone. This type seems problematic because it does not deal with the time zone problem. Its relationship to either floating or incremental times is completely arbitrary. See also Issue 88.
addison: so have more
understanding... modeling JS Date(). There are use cases like
airline schedules where useful. Question is about giving good
guidance to authors.
... call for a health warning related to time zones?
ISSUE-89: update to call for health warning on use of local dates and times
<trackbot> ISSUE-89 Time zones and local dates and times notes added
ISSUE-89: accepted for HTML5 LC
<trackbot> ISSUE-89 Time zones and local dates and times notes added
ISSUE-91
15 minute time zones
http://www.w3.org/International/track/issues/91
The note on time zone offsets says in part: "...and the minutes component of offsets of actual time zones is always either 00, 30, or 45." Really this is arbitrary and prone to change. The total range of time zones also changes from time to time. I would suggest inserting a "at the time this document was published" caveat such that innocent readers are not caught by surprise by a new 15 mintue time zone offset or by more monkey business surrounding the IDL.
ISSUE-91: accepted for HTML5 LC
<trackbot> ISSUE-91 15 minute time zones notes added
ISSUE-92
Time zone offset vs. time zone
http://www.w3.org/International/track/issues/92
This section gives a number of examples that equate time zone offset with an actual time zone. For example: -- "1979-10-14T12:00:00.001-04:00" One millisecond after noon on October 14th 1979, in the time zone in use on the east coast of the USA during daylight saving time. -- It should be made clear that a zone offset is not the same thing as a time zone. Mention should be made of the need for separate time zone information when working with real date and t
ISSUE-92: accepted for HTML5 LC
<trackbot> ISSUE-92 Time zone offset vs. time zone notes added
ISSUE-93
http://www.w3.org/International/track/issues/93
implicit conversion to incremental time
Rule 9 in the parsing of a valid global date and time is: "Let time be the moment in time at year year, month month, day day, hours hour, minute minute, second second, subtracting timezonehours hours and timezoneminutes minutes. That moment in time is a moment in the UTC time zone.". It is not clear what type 'time' is. It appears to be a field-based time value, but it this intended as an implicit conversion to incremental time?
ISSUE-93: accepted for HTML5 LC
<trackbot> ISSUE-93 Implicit conversion to incremental time? notes added
ISSUE-94
http://www.w3.org/International/track/issues/94
Allowing culturally specific week rules
This section defines 'weeks'. The rules for weeks and week counting are culturally linked, but these rules define week start as always Monday. The rule for determining the "first week" that it includes the first Thursday (again, a culturally variant value). Shouldn't there be provision for allowing culturally specific week rules be applied?
<matial> definitely
ISSUE-94: accepted for HTML5 LC
<trackbot> ISSUE-94 Allowing culturally specific week rules notes added
ISSUE-95
http://www.w3.org/International/track/issues/95
Limitations and defaults for accept-charset
The "accept-charset" field is said to "gives the character encodings that are to be used for the submission". Is this a real limitation on the encodings used? Is there a default value (presumably the page encoding)?
http://www.w3.org/TR/html5/forms.html#the-form-element
present for backward compatibility?
ISSUE-95: accepted for HTML5 LC
<trackbot> ISSUE-95 Limitations and defaults for accept-charset notes added
ISSUE-96
Allowing for EAI
The email address validation scheme quotes ABNF from RFC 5322 and doesn't appear to allow addresses that are IDNA. While EAI is kinda slow moving, shouldn't HTML5 allow for it?
<r12a> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11579
<r12a> Support for internationalized e-mail addresses
ISSUE-96: add this issue to HTML5 bug 11579
<trackbot> ISSUE-96 Allowing for EAI notes added
ISSUE-97
Allowing a page to request a given locale
http://www.w3.org/International/track/issues/97
-- The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates and times according to the conventions of the user's preferred locale. -- Should we encourage the use of the *page's* preferred locale? It would be best if we could provide a way for page authors to create a consistent user experience. Work on the ECMAScript I18N extension may eventually help here, but only
matial: provide authors ability to override user's preferences, but user's preferences should work in absense of an override
ISSUE-97: accepted for HTML5 LC
<trackbot> ISSUE-97 Allowing a page to request a given locale notes added
<scribe> ACTION: addison: write to HTML5 chairs and ask for extension to complete our comments targetting mid-August (??) [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action03]
<trackbot> Created ACTION-62 - Write to HTML5 chairs and ask for extension to complete our comments targetting mid-August (??) [on Addison Phillips - due 2011-08-03].
close ISSUE-128
<trackbot> ISSUE-128 Why is content-language non-conforming? closed
<scribe> ACTION: addison: file accepted as accepted and unreviewed comments as provisional [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action04]
<trackbot> Created ACTION-63 - File accepted as accepted and unreviewed comments as provisional [on Addison Phillips - due 2011-08-03].