<scribe> ScribeNick: fantasai

plinss: Any other items for the agenda?

szilles: WD status for regions?

plinss: Kyoto F2F, need agenda items
... Add them earlier so people have time to review and prepare

http://wiki.csswg.org/planning/japan-2011

plinss: Bert sent a message that we're missing reviews for CSS2.1

TabAtkins_: Is there a way to see who has sent in a review?

<plinss> https://www.w3.org/2002/09/wbs/33280/css21pr/results

plinss: MS, Mozilla, Opera, and Apple have responded

?: Adobe?

(Nokia and Opera are the others who have responded so far)

plinss: Chris is missing, can't talk about charter
... Is Bert here to talk about website?
... Nope.
... Next is spec annotation system
... Just wanted to get some quick input, discussed on email
... Do we want to add this to CSS2.1? Do we want to use moving forward?

TabAtkins_: Would def like to use for specs I edit

szilles: +1

<sylvaing> +1 as well

arronei: Would like for 2.1 and any in the future if possible

plinss: Any objection to adding to CSs2.1?

RESOLUTION: Use spec annotation system for CSS2.1 and future specs

CJK longhand styles

<plinss> http://lists.w3.org/Archives/Public/www-style/2011Apr/0764.html

TabAtkins_: Some ppl objected to complexity in lists
... The only complex parts I could potentially remove are the special styles like CJK ones
... They were defined up to 10^16, which is way more than any impl can do
... If I limit range to 10^4 I can represent Japanese and Korean styles as additive style
... And Chinese becomes much simpler
... I think 10,000 is a reasonable limit here.
... I wanted to know if anyone wants CJK longhand styles to go beyond

arronei: I think your limit is reasonable, but I don't think it should be a hard limit.
... If a UA wants to go beyond then it should be able to do that.

TabAtkins_: When you exceed the range, you drop to a fallback style
... In this case, drops to cjk-decimal

bradk: Can't we say that if the UA supports the larger numbers, then they should do it in the more sophisticated way?

TabAtkins_: If I'm not specifying it
... I either specify a larger range or a shorter range

sylvaing: So once the fallback comes, can you get the proper numbers by more rules?
... by specifying ... [????]

TabAtkins_: theoretically
... Officially, I could go up to 10^5 and still have all the same benefits, it's just 10^6 Japanese and Korean can't be additive, and Chinese gets more complex

sylvaing: I would rather have the spec be clear

TabAtkins_: There are other number systems already in the spec that have similar problems.
... Hebrew, ex, has ways of expressing numbers beyond the range in the spec right now.

sylvaing: The use case isn't representing all numbers

TabAtkins_: I could potentially go through and identify all the types of lists that have longer representations than I've defined
... Like circled decimal type, only has 50 Unicode chars. You could always synthesize more
... But I don't want to make things vague.
... Going through and explaining how to extend them would be more complexity than people want

bradk: You were talking about putting those in an appendix

TabAtkins_: The definitions are part of the spec in an appendix for ua stylesheet

bradk: If you wanted to go beyond 10,000 you could still recommend what the UA puts in its style sheet

TabAtkins_: If I carve out an exception for CJK longhand
... That's inconsistent
... We do know how to do it correctly, but nobody wanted to do that.

fantasai: Not true. Webkit implements it (though buggy) and Mozilla implements it correctly up to its internal counter limit

bradk: Even if there were some exceptions for e.g. cjk-longhand, I think there'd be some value to have an exception for UAs that want beyond 10,000
... Some UAs in todays world have a problem going beyond such large numbers, but at some point other UAs won't mind

TabAtkins_: So at that point we'll require larger limits

?: ... that don't want those limits

TabAtkins_: Hardware limits always override anything the spec says

1) Define cjk counter styles up to 10^16 (full definition)

2) Define them up to 10,000 (artificially limited to simplify)

3) Allow both behaviors

TabAtkins_: Note, the full definition is up to 10^68, but usually beyond that you switch to scientific notation

fantasai: But we have a definition for up to 10^16 that we're pretty sure is correct

TabAtkins_: Everybody does counters up to 2^30, some go up to 2^31
... That's like 10^12
... There are only two complex styles left. Ethiopic-numeric and cjk longhand

sylvaing: It's complex for no use case, why would you have such a long list?

TabAtkins_: Most styles defined to infinity, note

bradk: Web is a big place. I'm not sure there aren't lists that go beyond 10,000 or that start at 10,000 and go to 20,000

TabAtkins_: There are other types defined up to infinity
... If I define the CJK styles out more fully, I'll want to define the other styles more fully
... to be more consistent

Arno: 10,000 seems like a reasonable artificial limit especially if we define the fallback for what happens if we go beyond that

plinss: I do think 10,000 items in the list is a reasonable limit, but I'm concerned about lists that don't counting at 1

sylvaing: Maybe the use case is someone who has a paged view of a database
... You start at 12,000 one a particular page

TabAtkins_: Printouts like that are the only really strong use case for lists that start at large numbers, and you won't use cjk longhand for that

glazou: Use case is email. You can have thousands of email in a list

TabAtkins_: are you going to use CJK numbers for that?

glazou: why not

TabAtkins_: Note that 10,000 and beyond will have a lot of characters, you have around two chars per digit

glazou: 10,000 is fairly common. 100,000 is more reasonable.

TabAtkins_: I can go to 100,000 and keep things simple as they are

glazou: I think that drastically reduces the risk of problems in the future

sylvaing: ... the use case for high numbers is when you start at a very high number
... e.g. a paginated view of database results

TabAtkins_: Is it use case enough that we define how to work those things?

<dsinger> as I said before, we can define conformance out to some reasonable finite limit. well, we have to.

<dsinger> and then if the definition of how to go higher is referenced or provided, UAs are welcome to knock themselves out

fantasai: So we could spend the rest of the call talking about databases, or we could resolve on what to do

1) Define cjk counter up to 10^16 (full definition that we have ready to go, more than counter hardware limits in place now)

2) Definte them up to 10,000

3) Definte them up to 100,000

4) Put both definitions in the spec, allow UA to implement either, and mark full definition at-risk to see what ppl implement in CR

arronei: I still think that UAs /may/ support up to 100,000 but may support numbers higher and leave it undefined

TabAtkins_: You do have to define it because it's complex and ppl /will/ get it wrong

fantasai: And we have the correct definitions already

TabAtkins_: I don't want ppl to get fallback in one UA, correct result in another UA, and wrong result in another UA because they got it wrong

<dsinger> UAs are always at liberty to exceed requirements. you don't even have to say it

glazou: You can always add a note that CSSWG might define beyond the limit later
... Put the definition to 100,000, allow UAs to go beyond, and add the note

<dsinger> I just think it might be safer to define what they should do beyond the conformance limit, if they want to. it can be purely informative text

fantasai: We have tnhe definition, if we're allowing UAs to go beyond the limit, I don't see any reason not to put the definition in the spec

TabAtkins_: I prefer 3, can live with 1

<dsinger> as I say, you can't prohibit people from doing more than is required

5) Define up to 100,000, allow UA to go beyond it, but DONT put a definition in for beyond 100,000

6) Definte up 100,000 allow UA to go beyond it, put an informative definition in for byeond 100,000

We'll put a note for all of them

dweck: My knowldge is limited. Abstain

sylvaing: I think 6 works for me

<dsinger> (1) is a testing nightmare, isn't it?

arno: Go with 3, but live with 6

smfr: 6

<smfr> let's give Tab more work :)

koji: I prefer 6

arronei: 6

césar: not sure

Bert: no opinion

glazou: 6

bradk: 6

plinss: I prefer 4, could live with 6

<dsinger> dave defers to smfr (he's always right): 6

<fantasai_> hober: I prefer 6, but happy for tab to do less work as 3

<fantasai_> szilles: prefer 3, live with 6

<fantasai_> johnjan: prefers 6, very against 2

<fantasai_> fantasai: same as plinss

<fantasai_> RESOLVED: Define up to 100,000 with fallback to cjk-decimal beyond, allow UAs to implement longhand beyond that limit, put definition in informative appendix

RESOLVED http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0245.html

not, noresolved

<fantasai_> fantasai summarizes email

<fantasai_> TabAtkins_: I'm going to want them defined because I need them in FlexBox for similar reasons

fantasai summarizes issues

<fantasai_> plinss: I'd like to see these width values advance as quickly as possible

<fantasai_> plinss: My concern is that UAs that don't want to support vertical mode

<fantasai_> fantasai_: We can make it explicit that you can implement the module in parts, maybe make profiles

<fantasai_> plinss: Is that the best place to put it?

<fantasai_> fantasai: I think so

<fantasai_> [...] Bert: torn between elika and peter, would be hard to split it out

<fantasai_> szilles: We should get it in and get it reviewed

<fantasai_> arronei: put it in values and units?

<fantasai_> fantasai: no, it's very tied to layout

<fantasai_> fantasai: I have to define the concepts in writing modes anyway, I can just say 'btw, here are keywords for this'

<fantasai_> fantasai: Can make a new section for it

<fantasai_> fantasai: right now it's an appendix, could even leave it in the appendix

<fantasai_> szilles: normative appendix sounds good to me

<fantasai_> plinss: and all parts Tab would refer to are in that appendix?

<fantasai_> fantasai: yeah

<fantasai_> fantasai: if you really want to split it out later, let's do it as an editorial change in CR

<szilles> +1 for a normative appendix in Writing Modes

<fantasai_> arronei: make sure it's normative

<fantasai_> arron: I would prefer a separate spec, but not against making it a normative appendix

<fantasai_> szilles: I agree that it really belongs in the Box Module, but it needs to be in something that's progressing faster than the box module.

<fantasai_> szilles: By making it an appendix, it makes it clearer that this is a separable piece that can/might be used elsewhere

<fantasai_> arronei: Maybe add a note that this might be moved to e.g. future version of box module

<fantasai_> RESOLVED: Add these keywords as an appendix, add note that they might be moved

<fantasai_> szilles: Would like to give 1-week notice of request to publish WD of Regions.

<fantasai_> szilles: Exclusions still needs more work.

<fantasai_> szilles: hyatt posted some issues to www-style

<fantasai_> plinss: OK

<fantasai_> Meeting closed.

RRSAgent: pointer

RRSAgent: make logs public

RRSAgent: make minutes

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/in full//
Succeeded: s/?/Arno/
Found ScribeNick: fantasai
Inferring Scribes: fantasai
Default Present: plinss, +1.650.214.aaaa, TabAtkins, arronei, danielweck, +1.206.324.aabb, +1.408.536.aacc, arno, smfr, [Microsoft], kojiishi, johnjan, sylvaing, bradk, +050134aadd, +1.415.920.aaee, Cathy_Chan, +1.408.536.aaff, +34.92.38.aagg, Bert, glazou, cesar, hober
Present: plinss +1.650.214.aaaa TabAtkins arronei danielweck +1.206.324.aabb +1.408.536.aacc arno smfr [Microsoft] kojiishi johnjan sylvaing bradk +050134aadd +1.415.920.aaee Cathy_Chan +1.408.536.aaff +34.92.38.aagg Bert glazou cesar hober

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 11 May 2011
Guessing minutes URL: http://www.w3.org/2011/05/11-css-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.