See also: IRC log
http://www.w3.org/International/track/actions/open
<fantasai> aphillip: Working through list of satisfied items in CSS3 Text
<fantasai> aphillip: Not quite done
action-315?
<trackbot> action-315 -- Addison Phillips to Close satisifed items in css-text -- due 2014-07-03 -- OPEN
<trackbot> http://www.w3.org/International/track/actions/315
action-320?
<trackbot> action-320 -- John Klensin to Send link to "hamza above" id to public list -- due 2014-07-24 -- OPEN
<trackbot> http://www.w3.org/International/track/actions/320
close action-320
<trackbot> Closed action-320.
close action-321
<trackbot> Closed action-321.
close action-322
<trackbot> Closed action-322.
action-319?
<trackbot> action-319 -- Koji Ishii to Report back on korean justification when response received -- due 2014-07-17 -- OPEN
<trackbot> http://www.w3.org/International/track/actions/319
fantasai: publish new draft of
css-ruby
... anon box generation
... whitespace handling now defined
... bidi now defined
... sent mail about it
... on html side, koji filed items about too aggressive auto
closing
<fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26424
<fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26426
https://www.w3.org/International/wiki/Review_radar
<r12a> http://www.w3.org/International/track/
<fantasai> r12a: We used to have ad-hoc and .prev and .monitor and then the real one, and we rolled all those together
<fantasai> r12a: There's a small problem, which we actually foresaw at the time
<fantasai> r12a: Now, you can't necessarily tell, at a glance, which has already been sent to the WG and which is waiting approval
<r12a> http://www.w3.org/International/track/products/46
<fantasai> r12a: which is actually being tracked, vs. which is a real comment sent to the WG
<fantasai> r12a: What I've started doing is, wher eyou can see at the end of the title I put a circled t, means we're just tracking this
<fantasai> r12a: circled p is pending expedition to the WG
<fantasai> r12a: my proposal is that in the instructions for how to raise an issue that we tell people to put these little things on at the ppropriate time, or remove them when you're notifying the WG
<r12a> http://www.w3.org/International/reviews/review-instructions
<fantasai> aphillip: Since we want to invite the unverse at large to make comments, shouldn't those be unmarked, and you and I add notations for the other states?
<fantasai> r12a: Well, I hope they follow instructions. It would save us a lot of grief, and if they follow those instructions, would be simple enough
<fantasai> r12a: I did consider that, but thought it would be easier in the long run if our comments to another WG didn't have these things
<fantasai> aphillip: Didn't want to send Unicode chars to other groups? :)
<fantasai> r12a: Yeah. Also then people might forget them, it gets confusing, etc.
<fantasai> fantasai: You could make them non-Unicode. Put in brackets
<fantasai> r12a: Considered that, but this is cooler.
<fantasai> aphillip: Any other opinions?
<fantasai> [not really]
<dclarke> Seems fine, but might be bettter as prefix
<scribe> ACTION: richard: modify instrucitons for reviews to include the new markings [recorded in http://www.w3.org/2014/07/24-i18n-minutes.html#action01]
<trackbot> Created ACTION-323 - Modify instrucitons for reviews to include the new markings [on Richard Ishida - due 2014-07-31].
<matial> prefices are easier to spot
<fantasai> r12a: thought about that too, but concluded that easier to manage at the end - however that's why I went for circles, they are easy enough to spot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859
<fantasai> aphillip: Basically, this is about Ian proposes to add a new piece of markup for indicating the locale of elements in forms
<fantasai> aphillip: ought to be aligned with JS, BCP47
<fantasai> aphillip: We already have an attribute that does that
<fantasai> aphillip: so some ocntention between using lang vs not using lang
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679
<fantasai> r12a: seems to be some of ppl on the bug are talking about situations an dmixing them
<fantasai> r12a: where you have data being inserted into a page
<fantasai> r12a: fairly obvious that if you do that, and then insert date sample, which is dynamic thing, that you ought to format it according to language of the text into which you're inserting it
<fantasai> r12a: that's a different scenario than having an input field in the text, and you are gathering info from the user
<fantasai> r12a: if you're gathering info with an input field, seems more plausible that you'll want to consider who is the user is than the language of the text
<fantasai> r12a: not sure if, if you think further, perhaps you want to use the format of the text
<fantasai> r12a: bigger problem is, if you're asking ppl to type in a numeric date, causing yourself a problem in any case
<fantasai> r12a: argument is that currently system settings used to identify the locale
<fantasai> r12a: we're asking for the lang attribute. This will cause inconsistencies
<fantasai> aphillip: Most browsers are like Mozilla. Get a text box. Can type anything into it. type=date is just a suggestion
<fantasai> aphillip: But Chrome has implemented fancy types
<fantasai> aphillip: Because HTML doesn't define anything, the page author has no control over how a date is displayed
<fantasai> aphillip: When field is empty, Chrome shows MM/DD/YY or whatever
<fantasai> aphillip: but if you put a value in the field, all you see is the value
<fantasai> aphillip: the value is transposed into the correct locale
http://www.inter-locale.com/test/DateDemo.html
<fantasai> aphillip: There are 2 entry fields, enter US date or UK date
<fantasai> aphillip: Tagged with different lang values. But show same ordering for me
<dclarke> mine says 01/02/2014
<dclarke> on chrome
<fantasai> fantasai: These are UI controls. Should be in the UI language, lfollow OS convention
<fantasai> r12a: What if you're travelling? can't figure out what the strange ideographic characters are
<fantasai> aphillip: no way to have german calendar on a german page
<fantasai> aphillip: People work aorund this by creating complicated javascript controls
<fantasai> r12a: problem is more, how does the browser know what you mean if you are using numeric input?
<fantasai> r12a: if you type in 01/02/14
<fantasai> r12a: browser has to know what you mean
<fantasai> r12a: if you look at the output , the stored value, it's stored in ISO format
<fantasai> r12a: No matter what the settings are, en-US or en-GB, user could type something stupid
<fantasai> r12a: so a pull-down date widget is the best way to do this
<fantasai> r12a: or something that splits out day/month/year
<fantasai> r12a: like for credit cards
<fantasai> r12a: shouldn't be asking people to write numeric dates
<fantasai> aphillip: Chrome is constraining these, different from historical way
<fantasai> fantasai: That's the whole point of the new types. Browsers that don't do this havent' got around to implementing it yet
<fantasai> r12a: the main point is not how you enter the date, but rather how the browser interprets that, you don't know how the browser is interpreting it
<fantasai> fantasai: That browser should drop down the widget while you're typing it in
<fantasai> fantasai: so you can see how it's interpreting the typing
<fantasai> aphillip: [...]
<fantasai> aphillip: can't see the prompt once you fill it in
<fantasai> [could use non-numeric dates]
<fantasai> aphillip: Hear that browser should match the user's locale
<fantasai> aphillip: but sometimes you as an author want to control the complete experience
<dclarke> I agree with Fantasai,
<fantasai> fantasai: If you have multiple pages, some written in US and some in UK, they'll have inconsitent interfaces. As a user this is not helpful. Won't know what's going on.
<fantasai> fantasai: Should match my locale, my settings. That way I always know what's going on.
<fantasai> fantasai: If you have linguistic info, maybe adapt to the page's language
<fantasai> fantasai: but numeric stuff should match the locale. If I like 24h clocks, I should get them on all my time widgets, not get am/pm because I happen to be booking in a different country
<fantasai> aphillip: Sounds like we have different opinions
<r12a> r12a: my inclination is to think that a user control is more related to the user than to the text content language
<r12a> ... however information later inserted into the page should be in the format related to the language
<fantasai> aphillip: If we don't give any way to control these things, then the only way to get a specific presentation is to not use the built-in controls and write it myself
<fantasai> aphillip: Should provide a way to control for content authors who care about it
<fantasai> r12a: I'm not 100% convinced either way
<fantasai> r12a: why is this the same as the JS stuff?
<fantasai> r12a: for JS, you want to take info taken from user, and then insert into document. Want it to look like the rest of the page content
<fantasai> r12a: but in terms of gathering the data from the user, don't see that strong convention
<fantasai> r12a: If guy is reading Tibetan, probably speaks and reads Tibetan, and is happy because system is all in Tibetan
<fantasai> r12a: Case where you run into problems is the Internet café, where you are not necessarily Tibetan
<fantasai> r12a: but in that case, you know what's going on, you're carefull and less likely to make silly mistakes
<fantasai> r12a: You shouldn't be doing numeric data in the first place. Regardless of whether we match system or page, can mess up without noticing
<fantasai> fantasai: I think if the month were not numeric, e.g. 13 Oct 2014, wouldn't have this problem
<dclarke> or rendering it as a 3 field split
<fantasai> that's less likely to look nice. People wnat things to look nice...
<dclarke> then the month field only goes up to 12
<dclarke> etc
<fantasai> aphillip: Not getting anywhere here
https://www.w3.org/International/wiki/HTML5TimeZone
<fantasai> aphillip: Put two proposals.
<fantasai> aphillip: Think second is dead on arrival
<fantasai> aphillip: are we ready to move forward with this and make a proposal?
<fantasai> r12a: Think this needs more time for review
<scribe> ACTION: addison: give wg action to read the time zone proposal for action next week [recorded in http://www.w3.org/2014/07/24-i18n-minutes.html#action02]
<trackbot> Created ACTION-324 - Give wg action to read the time zone proposal for action next week [on Addison Phillips - due 2014-07-31].
<fantasai> fantasai: Example is a date without a time. Why is there a timezone? Binding it to midnight means that when it shows up in my calendar, it shows up as the previous date (because I'm in SF)
<fantasai> aphillip: go read the note about time info
<fantasai> aphillip: issue here is anyway that we have timezone offsets or nothing, and we need real timezones
<fantasai> [discussion of floating vs non-floating times]
<fantasai> HTML defines time without timezone as floating time, but if you pull it into JS, it gets tied to midnight UTC
<fantasai> aphillip: ^
<fantasai> aphillip: So this is a real problem
http://www.w3.org/International/track/products/25
<fantasai> aphillip: Work on open bugs, or look at received comments?
issue-374?
<trackbot> issue-374 -- Encoding false statement -- open
<trackbot> http://www.w3.org/International/track/issues/374
http://lists.w3.org/Archives/Public/www-international/2014AprJun/0284.html
<fantasai> aphillip: spec states that it renders the IANA registry obsolete
<fantasai> aphillip: Anne accepted some slightly modified text, but probably won't make a real difference
<fantasai> r12a: perhaps should make it clearer what we're referring to
http://encoding.spec.whatwg.org/
http://encoding.spec.whatwg.org/#preface
Historically encodings and their specifications (if any) were kept track of by the IANA Character Sets registry. This specification renders that registry obsolete.
<fantasai> r12a: 2nd sentence is what is causing the problem
<fantasai> r12a: to my mind, the way to solve this is to scope that statement a bit better
<fantasai> r12a: Could say that ths spec renders that registry obsolete for the Open Web Platform
<fantasai> r12a: still worrying, cuz don't know what OWP the boundaries of OWP are exactly, and I suspect that some people working on the OWP may still need to refer to the IANA spec for a whle at least
<fantasai> r12a: Another possibility, obsoletes that registry for all implementations that use this specification.
<fantasai> aphillip: I think obsolete or replaces isn't really even necessary
<fantasai> aphillip: you don't have to look over there if you're looking here
<fantasai> r12a: Can't use word "obsolete", because you can't obsolete a spec you don't own
<fantasai> r12a: and some ppl will use IANA spec, so can't make a universal statement
<fantasai> r12a: so agree not to use obsolete
<fantasai> fantasai: Replaces seems fine
<fantasai> aphillip: replaces for what?
<fantasai> fantasai: for impl using this spec (as r12a suggested) is fine
<fantasai> aphillip: Then recommend that this spec be used for anyone using the OWP
<fantasai> aphillip: If writing a W3C spec, should reference this spec instead of IANA
<fantasai> r12a: should put that in charmod
<fantasai> aphillip: yes
<fantasai> aphillip: Need to update Charmod for various reasons
<fantasai> fantasai: Don't think it's a problem for a spec to say what it thinks it ought to be used for. Not that shouldn't update charmod as well
<fantasai> r12a: That is a field of land mines
<fantasai> r12a: XML ppl will be very unhappy
<fantasai> r12a: so just a whole lot simpler to just be self-referential
<fantasai> aphillip: If you refer to this spec, then this becomes the definition of encodings and the limit of what encodings are acceptable
<fantasai> aphillip: so we're in agreement with this issue
<fantasai> aphillip: so that suggests filing a bug against Encoding
<fantasai> aphillip: Do we want to write proposed replacement text?
<fantasai> r12a: useful to go to anne with a suggestion, but also useful to talk with anne about this
<fantasai> [discussion of calendaring]
<fantasai> [and bug-filing logistics]
<fantasai> aphillip: I think all of these are going to end up with bugs
<scribe> ACTION: addison: propose text for the 'false statement' issue [recorded in http://www.w3.org/2014/07/24-i18n-minutes.html#action03]
<trackbot> Created ACTION-325 - Propose text for the 'false statement' issue [on Addison Phillips - due 2014-07-31].
issue-355?
<trackbot> issue-355 -- Supporting files referenced rather than copied -- open
<trackbot> http://www.w3.org/International/track/issues/355
accepted
issue-369?
<trackbot> issue-369 -- IANA transition -- open
<trackbot> http://www.w3.org/International/track/issues/369
not actionable?
close issue-369
<trackbot> Closed issue-369.
issue-371?
<trackbot> issue-371 -- Choice of encoding details -- open
<trackbot> http://www.w3.org/International/track/issues/371
richard: anne asked martin for
test results
... should encourage him to provide to anne
issue-372?
<trackbot> issue-372 -- Arithmetic Right Shift -- open
<trackbot> http://www.w3.org/International/track/issues/372
richard: looks like anne will do something about it
file a bug against
issue-373?
<trackbot> issue-373 -- Changes of deployment -- open
<trackbot> http://www.w3.org/International/track/issues/373
richard: "not accept" and close
since based on browser implementations
... ?
addison: nothing actionable in
this item?
... accept but not file a bug? response is "noted"
<matial> Bye
<scribe> ScribeNick: fantasai
<aphillip> Scribe: Elika