[CSSWG] Minutes Seoul F2F 2014-05-19 Part V: Counter Styles, CSS Formatting for Books, Font Load Events, Future F2F Meetings, CSS Syntax - Unpaired Surrogates, MQ Listener

Counter Styles

  - RESOLVED: Add "speak this as a word" value to @counter-style speak-as.
  - RESOLVED: Change @counter-style's speak-as descriptor values to
       bullets, numbers, words, and spell-out.
  - RESOLVED: Process pad before negative (so that we get -02, -01,
       00, 01, 02)
  - RESOLVED: The spacing between a list item and its content
       should be done as space characters in the suffix.
  - RESOLVED: Change the name of 'override' to 'extends'
  - RESOLVED: Publish a 6 week last call of counter styles

CSS for Formatting Books

  - Slides available here: http://nadita.com/murakami/presen201405/#%281%29

Font Load Events to LC

  - RESOLVED: Publish LC for font loading, with change/note about SetClass dep

Future F2F Meetings

  - The next F2F will be 8 September to 10 September somewhere in
       Europe with the site TBA.
  - The meeting after TPAC will be in early February with a lot of
       possible site suggestions include a few options in the US and

CSS Syntax - unpaired surrogates

  - The potential issue of unpaired surrogates coming in from JS
       will be left with no change.

MQ Listener

  - RESOLVED: Make MQ lists and EventTarget for the change event and
       alias the existing listener to addEventListener and


Agenda:  http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

Counter Styles

  glazou: Let's resume
  TabAtkins: Alright.
  TabAtkins: Counter styles. There are 3 issues that I don't know
             how to resolve.
  TabAtkins: The fourth is in line with what we did in animations.
  dbaron: There's a reply to one of your messages so there might be
          a 5th.
  TabAtkins: He's just saying I need to define range-auto. I will do

  TabAtkins: First issue
  <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014May/0146.html
  TabAtkins: How do we read out counter styles in interesting
  TabAtkins: There's speak-as, which lets you say to read the
             numeric value, read as a bullet, or read alphabetical
  TabAtkins: There's some where it might be good to read as a word.
  TabAtkins: An example was a text on Tolkien and you were doing your
             lists with numbering in quenyan you'd want them read
             out in that language.
  <clilley> http://en.wikipedia.org/wiki/Quenya
  TabAtkins: The question is should we add speaking out counter
             styles as words, using whatever engines that you have
             for speech?
  TabAtkins: So that something like  system: fixed; symbols:
             "first", "second"... will be read as first, second, etc.
  TabAtkins: So should we address this or we can just say no change
             and let it just be called numeric?
  TabAtkins: I'm fine with adding a value, but wanted to avoid

  hober: It seems easy to get internalization wrong. I made a cool
         set of styles and say you can read as 1, 2, etc. and someone
         uses them in a different language it would be read as first,
  TabAtkins: But that's the right way to do it.
  dbaron: The normal case is speak-as numeric, though, that says 1, 2
  TabAtkins: It ignores what the symbol is. This would let it
             literally read the word.
  hober: And if you have a symbol?
  TabAtkins: It would do whatever your reader does.
  dbaron: And I think alphabetic should be something like spelled
  TabAtkins: Yeah. I'm fine with changing that.

  fantasai: So this is the alternate proposal?
  TabAtkins: Yes. The way this would be done, it allows the
             alternate proposal in a slightly more complex way.
  dbaron: Speak-as can refer to a different counter style.
  TabAtkins: So if you have a list of symbols where you want them
             named as something, you would use speak-as that.

  TabAtkins: So does anyone object to me adding this?

  TabAtkins: So, names. We have a value called alphabetic that reads
             letter by letter.
  TabAtkins: It's not a clear name and I'd be fine with naming it
             something like spelled-out
  TabAtkins: So we'd also need a name for this like speak-out-as.

  fantasai: Spell-out is already defined for CSS Speech's 'speak-as' property.
  TabAtkins: Great.
  fantasai: That spells the text one letter at a time.
  TabAtkins: So that would be speak-as: spell-out
  fantasai: And I would use read-aloud.
  TabAtkins: That's less clear.
  fantasai: We have an auto value.
  TabAtkins: I like speak-as: words.
  dbaron: The auto does things dependent on the system of the
          counter style.
  TabAtkins: I like spell-out and words.
  TabAtkins: Bullet and numeric are the other existing values.
  fantasai: Do we have a clearer word than bullet?
  TabAtkins: If someone can come up with one.
  dbaron: Bullet is fine to me.
  fantasai: Okay.

  TabAtkins: So does anyone object to bullet, number, spell-out and
  dauwhe: Is there digits?
  TabAtkins: That would be spell-out, I guess.
  fantasai: The speak-as property applies to general text so 'spell-out digits'
            would pronounce as a number.
  fantasai: In this case it's a strange thing.
  dbaron: So 'speak-as: digits' in speech does do normal for everything
          but a number and reads digits for a number.
  TabAtkins: So I'm happy for these four values and will handle in
             the specific alts using the secondary style.

  fantasai: I'm thinking about words. Should it be read-words?
  TabAtkins: Well, these are nouns and don't need individual parts
             of speech.
  fantasai: Well, maybe we should pick a part of speech for all of

  dauwhe: Have you gotten accessibility input?
  TabAtkins: Yes.
  dauwhe: Has Daniel Weck commented on this?

  TabAtkins: Keeping to one kind of speech is probably good.
  dbaron: A property called speak-as seems to need a noun.
  fantasai: Speak-as and spell-out exist.
  dbaron: So spell-out is the exception.
  TabAtkins: Speak-as bullets, numbers, characters, words.
  fantasai: I think characters would want to be 'spell-out' for consistency.

  TabAtkins: I want to change this to numbers since numeric was the
             old way.
  TabAtkins: We need a better name to just say it's a list item.
  TabAtkins: So let's resolve we should add a "speak this as a word"
  RESOLVED: Add a "speak this as a word" value.

  TabAtkins: For now, as a tentative resolution, change the keywords
             to bullets, numbers, words and spell-out
  fantasai: We could use cues?
  TabAtkins: I don't think that works out of context.
  zcorpan: But there's only one bullet or list topic
  TabAtkins: There's only one number.
  zcorpan: So why plural?
  TabAtkins: Dunno. We can de-pluralize.
  zcorpan: It applies to one.
  TabAtkins: And all things generated by the counter style.
  zcorpan: So I guess plural.

  TabAtkins: So that ones done. I'll edit that in.
  fantasai: You can ask James Craig if he's got a better idea for a
            name than bullets.
  RESOLVED: Change @counter-style's speak-as descriptor values to
            bullets, numbers, words, and spell-out.

  TabAtkins: The third topic is easier.
  TabAtkins: I accidentally made a contradiction. I have two
             descriptions that modify the length of a value. Pad
             adds and negative adds.
  TabAtkins: Question is which goes first?
  TabAtkins: So you have pad: 2 "0" and negative: "-".
             Is it -2 or -02?
  TabAtkins: It's implemented both ways so we can decide. The spec
             says both, by accident.
  TabAtkins: So which do people like better?
  TabAtkins: Because alignment it looks like this [whiteboard]
  TabAtkins: So do people prefer 1st or 2nd on whiteboard.
  TabAtkins: Okay, second one is the choice.

  RESOLVED: Process pad before negative (so that we get -02, -01,
            00, 01, 02)

  TabAtkins: Last one which is second.
  TabAtkins: How to handle the spacing between a bullet and its text.
  fantasai: Isn't that out of scope?
  dbaron: There's a problem which is why we need to deal with it.
  TabAtkins: It's counter styles or lists.

  TabAtkins: So there's some space. Where is it from? Margin on the
             list item, spaces on the suffix, magic?
  TabAtkins: Browsers do both.
  dbaron: Firefox does margin based, but drops for CJK counter styles
  TabAtkins: For CJK you don't want to have a space.
  fantasai: And in English if you're copying you want that to stay.

  hober: So the good part about embedded is that it lets you do both.
  TabAtkins: I need to alter the definitions so that it says that
             but that's okay.
  TabAtkins: So there's a desire to have this happen with magic, but
             I don't like the approach.
  dbaron: The problem is I suspect the margin might be inter-operable
  TabAtkins: We use space.
  dauwhe: And it's an ordinary space?
  TabAtkins: Yes.
  dauwhe: I'm worried because justification can change the width.
  TabAtkins: Outside markers are outside of that context.
  TabAtkins: I'm okay with altering to say there's a space in the

  fantasai: If you have outside markers then do you want that space
  TabAtkins: Yes.
  fantasai: But if you have a CJK outside marker...
  TabAtkins: You take away the space. From what I understand you
             want the same behavior for outside and inside.
  fantasai: If that's the case this is the right decision.
  TabAtkins: So if you have an outside list item, do you want the
             marker on the end or do you want space here, koji or
  fantasai: Okay. In that case we're good.

  <dbaron> http://dbaron.org/css/test/2014/bullet
  dbaron: Here's the test case I was playing with.
  dbaron: Though I should maybe try with Chinese characters.
  TabAtkins: Well, we scale, but its true if we use a space or em
             value. The only way to tell is to inspect code or find
             a font with a significantly different space.
  TabAtkins: Is your approval going to hang on this case?
  dbaron: I don't think so. I'm okay with the space in list styles.

  TabAtkins: We were discussing if CJK wants the same inside and
  TabAtkins: So provisionally we say the spacing between a list item
             and its content should be done as space characters in
             the suffix.
  fantasai: Can you send a patch to internationalization?
  TabAtkins: Yes.

  RESOLVED: The spacing between a list item and its content should
            be done as space characters in the suffix.
  ACTION TabAtkins: Send a patch to i18n for their counter-styles spec.

  TabAtkins: Final issue is that one of the system values is
             system: override which lets you point to another style
             and say do what that does, but I'm overriding some of
             the descriptors
  TabAtkins: So I can say system override: decimal; negative: "(" ")"
  TabAtkins: So this is do whatever decimal does but do this for

  TabAtkins: So fantasai doesn't think this is the right word.
  fantasai: We're not overriding the specified counter style,
            we're creating a new one that's a variant of it.
  dbaron: So do you want to use 'inherit'?
  fantasai: It's close.
  TabAtkins: I'd object to that.
  TabAtkins: It's similar, but we just disallowed inherit everywhere.
  dbaron: Do you have another idea?
  fantasai: I think it would be clear for authors, they don't have a
            very strict understanding of CSS inheritance.
  dbaron: Except maybe we don't want to confuse them.
  TabAtkins: So what should we actually use?
  TabAtkins: How about extends?
  TabAtkins: I like that better than inherit.
  glazou: Extended
  dbaron: It's a bit different.
  TabAtkins: It being a verb is good.
  dbaron: Having it be part of the system descriptor works well.
  TabAtkins: Already I have that an override cannot do symbols.
  fantasai: Unless someone has something better I'm satisfied with
  TabAtkins: I'm okay with this.

  dbaron: One issue with extends is that it makes it sound like it
  TabAtkins: It's the same semantic as JS.
  dbaron: Not everyone is familiar with it.
  fantasai: So we have inherit, extends, or override. Any other
  andrey: Copy
  fantasai: Okay, copy.
  TabAtkins: Any other suggestions?
  TabAtkins: So let's poll on answers.
  fantasai: We'll deal with pluralization after.

  Straw poll:
  <fantasai> 1. inherit
  <fantasai> 2. extend
  <fantasai> 3. override
  <fantasai> 4. copy
  clilley_: Abstain
  fantasai: Anything but override
  glazou: Anything but 4
  dbaron: I think anything but 4.
  andrey: 2
  astearns: 2
  Rossen_: Anything but 3 or 4.
  plinss: 2
  TabAtkins: 2
  dauwhe_: 2
  TabAtkins: Okay. 2 wins.

  fantasai: Is it plural?
  TabAtkins: JS uses extends.
  TabAtkins: So is extends okay?
  fantasai: What are the other values? In the system?
  dbaron: Fixed, numeric, alphabetic
  <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/#descdef-system
  fantasai: So extends <ident> is consistent, grammatically.

  RESOLVED: Change the name of the override to extends

  TabAtkins: So. Cool. That's all counter styles
  TabAtkins: It's been in LC for a year because we keep getting new
             issues from zcorpan.
  TabAtkins: I suspect we're near the end.
  TabAtkins: So do we issue a new LC once I make these changes?
  dbaron: That's reasonable.

  dbaron: There's a chance of feedback once the implementation lands.
  dbaron: Since that replaces existing numbering with code based on
          this spec and thus people will notice if it does something
  TabAtkins: Any objection to a new LC of counter styles? I propose
             a 6 week period to give maximum time to find issues.
  fantasai: So say that for the purposes shipping this counts as CR?
  TabAtkins: They're shipping anyway
  dbaron: Was it in CR?
  TabAtkins: It never made it there.
  fantasai: We resolved to publish and before we did we got lots of
            issues from Xidorn.
  TabAtkins: So, I'm not hearing objections to going to last call?
  fantasai: You could do a shorter period.
  TabAtkins: I'm happy with longer.

  RESOLVED: Publish a 6 week last call of counter styles

  astearns: Bert asked to call in for text.
  fantasai: SteveZ wanted not today for text.
  dbaron: It's now midnight in CA so 1pm-3pm is likely okay for CA.
  astearns: What about Bert?
  dbaron: There may not be a time for overlap.

  [pause to sort out schedule]

CSS Formatting for Books

  glazou: We're going to have a talk from AH about CSS3 formatting
          for books.
  <clilley> http://nadita.com/murakami/presen201405/#%281%29

  [presentation is slides above, no minutes]

  * liam very pleased to hear positive welcome to Antenna House
  <TabAtkins> +1

  glazou: So we have an hour. What can we do?
  [brief water break]

Font Load Events to LC

  glazou: Let's start again
  glazou: Since it's been a hard day we propose selectors 4, font
          load and discuss sept f2f and then maybe media queries
  fantasai: I think I need to go over it (selectors 4)
  TabAtkins: There's still edits to selectors that need to be made.

  TabAtkins: I propose we move font load to LC
  TabAtkins: It's in the ED spec and two browsers are shipping.
  plinss: Aren't there polyfills?
  TabAtkins: Yes.
  dbaron: Have you gotten rid of the web idl SetClass dependency?
  TabAtkins: I haven't removed it yet but I plan to.
  glenn: Shouldn't that be before LC?
  TabAtkins: Yes, but we can do that in the future.
  dbaron: If you're planning...I guess that's okay, but put a note
          in the spec that you're planning to change it?
  TabAtkins: I can do that.

  TabAtkins: So that's it. I'll put in a set and deal with it that
             way for now.
  TabAtkins: With the change or the note that it'll change during
             LC, is that acceptable?
  dbaron: Yes.
  glazou: So any objections to publishing?

  RESOLVED: Publish LC for font loading, with change/note about SetClass dep

  glazou: How long?
  TabAtkins: Standard is fine.
  glazou: So 6 weeks?
  glazou: clilley will do the publication.
  TabAtkins: Great.

  clilley: Is it ready now?
  TabAtkins: Let me add that note. It will be ready in five minutes.
  clilley: That's close enough to now.
  clilley: It's been published before, right?
  TabAtkins: Yeah. It's been out.


  This discussion to set the agenda held no technical details.
       Please see the IRC log for full minutes.

Future F2F Meetings

  plinss: So next F2F?
  glazou: Okay.
  glazou: Did we have something...?
  dbaron: We had tentative dates of 8 sept to 10.
  glazou: We had proposals for location, Paris, Brighton, and Sophia.
          I think it will be hard to find a room in Brighton
  glazou: So 8 to 10 sept is a Monday to Wednesday
  glazou: So we stick to Sophia?
  glazou: Any objections?

  hober: There isn't a concrete option, is there? It's somewhere
         that we know works, versus something more amorphous?
  glazou: The more concrete second option is Paris
  clilley: Who would host?
  glazou: I'm not sure.

  plinss: As a side note, CSS conference is Berlin on 12 Sept.
  TabAtkins: Is anyone here speaking there?
  plinss: There's an open call for speakers.
  clilley: So you can get from any of those locations to Berlin easily.
  plinss: And JS conference is the two days right after.
  glazou: Call for speakers is open until 1 July
  glenn: Can you get Zürich, TabAtkins?
  TabAtkins: I know Zürich would be big enough. I don't see a
             problem, but would have to check dates.
  glazou: So do we stick to Sophia until Zürich is more concrete?
  TabAtkins: Yep. So ping tantek.

  plinss: We're firm on dates?
  glazou: Yes.
  krit: Is there a problem with Sophia?
  TabAtkins: It's a little harder to get to.
  TabAtkins: So we're doing 8 to 10 Sept, somewhere in Europe.

  glazou: Next is TPAC in Santa Clara
  TabAtkins: We've been non-US a lot, so we can maybe do US.
  astearns: Except the last meeting.
  krit: I wouldn't mind doing Seattle more.
  <dauwh> eventually we should meet in the Eastern US

  dbaron: Do we know where 2015 TPAC is?
  glazou: Paris.
  plinss: not Lyon?
  glazou: I don't think so.
  dbaron: You sure that's not the AC meeting?
  glazou: Oh, it was.
  plh: 2015 is under discussion. There's the idea of doing Japan and
       it's going to become a funding question.
  plh: If we can find funds we'll go to Japan.
  glazou: So.
  dbaron: It's likely not urgent.
  glazou: It's good to say something like February in US.
  TabAtkins: I want to do summer in US. specifically Seattle.
  glenn: I could maybe do Boulder for skiers
  glazou: So let's give some time to collect possibilities.
  glazou: So let's wait a bit
  <liam> hmm, xml prague is in february

  glazou: TPAC is in early November this year?
  plh: No, it overlaps Halloween.
  <myakura> TPAC 2014 (a W3C event) takes place 27 Oct to 31 Oct
            2014 in Santa Clara, California.
  glazou: So beginning of February will be good.

  glazou: Could Bloomburg host in NYC?
  andrea: I can see. We're tight on space, usually, though.
  dauwhe: I could eventually look at NYC. We're moving in October
          and may have better spaces.
  plh: NYC in Feb? Might as well do Boston.
  <liam> [we had a F2F in Ottawa in Jan/Feb once, hosted by Adobe,
         and had -50 and an ice storm]
  Rossen: How about Australia in February?
  clilley: I've been to one end of Jan/Feb.
  TabAtkins: It's like a Texas august.
  shans: I don't think we could get the same space.
  Rossen: We could get SVG in Feb.
  glazou: We can investigate that too.
  shans: Sure.

  plinss: Tentative dates?
  glazou: Beginning Feb.
  clilley: If we're investigating Australia, we should make sure
           we're co-located with SVG.

  glazou: Okay. Is that all for F2F?
  plinss: So go to MQ?
  TabAtkins: Can we do syntax quick?

CSS Syntax - unpaired surrogates

  TabAtkins: So the CSS parser handles unpaired surrogates fine, it
             turns them into replacement characters
  TabAtkins: Some JS calls aren't using the CSS parser. CSS doesn't
             explicitly handle encoding.
  <SimonSapin> Not the parser, the character encodings just never
               emit surrogates.
  <SimonSapin> Note that surrogates are forbidden in UTF-8

  TabAtkins: So if you can query selector unpaired get passed in. So
             do we want to force processing of those?
  clilley: Yes.
  TabAtkins: The risk is it's totally possible to set a class name
             with an unpaired from JS.
  TabAtkins: There's a chance that people may be depending on that.
  clilley: Then they should reap what the sow.

  dbaron: I'm more worried about extra processing passes and/or
          duplicating things that exist. What about web idl?
  TabAtkins: I don't think it has anything to say.
  <SimonSapin> dbaron, I think WebIDL has a [EnsureUTF16] thing, or
  dbaron: I'd like to hear what Boris and heycam have to say.
  TabAtkins: Boris brought up the maybe people are querying issue.

  zcorpan: It's not clear to me what the value in banning is.
  TabAtkins: I'm in theory okay with it. CSS just handles it.
  zcorpan: Seems it's an extra performance cost.
  TabAtkins: I find that acceptable.
  TabAtkins: There's nothing spec wise that would make that
  TabAtkins: It's just a matter of do we keep CSS Unicode clean.
  TabAtkins: If you're fine with normally clean and JS can screw
             things up that's fine.
  TabAtkins: I'm fine with no change, especially because I'd want to
             handle this on the DOM side.

  dbaron: I feel funny about a solution that's this specific.
  dbaron: I'd like to know what the general pattern is.
  TabAtkins: It's likely that we can't change much about the DOM
             and that will mostly let you do unpaired surrogates
  dbaron: CSS parsing is performance sensitive.
  TabAtkins: Yes. So. I don't know.

  TabAtkins: Sounds like no change is preferable. Should we go with
  zcorpan: I have a note in CSSOM to clarify what characters are,
           since it doesn't say if it includes surrogates.

  <Ms2ger> What does "JS can screw things up" mean?
  <TabAtkins> Ms2ger: Insert unpaired surrogates

  dbaron: [mentions SimonSapin comment]
  zcorpan: But that's only for things that go over the network. Not
           things like the DOM
  zcorpan: I think.
  TabAtkins: Okay. Using UTF16 does the replacement and it doesn't
             give guidance in spec about when to use it.
  TabAtkins: So if we do change, WebIDL has a mechanism. There
             wouldn't be weird prose.
  TabAtkins: But I'm going resolve no change.
  glazou: That probably doesn't need a resolution.

  <SimonSapin> wait, was was the result of the discussion on
  <astearns> SimonSapin: no change
  <SimonSapin> thanks astearns
  <SimonSapin> astearns, no change because perf?

glazou: What else?
TabAtkins: There's MQ listener
glazou: What did we decide for font load?
TabAtkins: Publish LC.
glazou: So we do MQ now and than finish

MQ Listener

  TabAtkins: So from the conference call a few weeks ago we had a
             question about how to handle some minor details in the
             semantics in events for this custom mechanism.
  TabAtkins: That was concerning timing and calls to the listener.
  TabAtkins: Blink is in favor of this because we have a pile of
             custom code and it gets missed in bug fixes.
  TabAtkins: There were concerns from dbaron about the semantics
  dbaron: I don't remember them.

  hober: If there's aliasing that can be done in a way so that the
         existing MQ interface continues to work, then that's great.
  hober: This is shipping in multiple implementations so I don't
         want to mess it up.
  TabAtkins: It's odd cases that would change. Nothing normal would

  TabAtkins: I'm looking up dbaron's comments.

  zcorpan: There would be a simple change because the object would
           inherit from EventTarget and support addEventListener
           and onchange.
  hober: If you're using this interface and it wouldn't change that,
         it's fine.

  TabAtkins: Okay. You (dbaron) had some concerns but said you were
             fine with it.
  dbaron: There was a thread about this in 2012 and 2014.
  <dbaron> http://www.w3.org/mid/20120615033942.GA27405@crum.dbaron.org
  <dbaron> but I don't see any objections I raised

  TabAtkins: Elliott, one of our impl, is in favor.
  TabAtkins: We all fire in different orders, so if anyone is
             depending on order, they're already breaking.
  dbaron: The plan is to make the MQ list the event target.
  TabAtkins: Yes.
  TabAtkins: Non-bubbling events fired at the MQ list.

  TabAtkins: So objections to making the switch and what should we
             call the event?
  TabAtkins: Someone suggested change which is fine.
  glazou: All the other events have a descriptive name, but change
  hober: Match-change or something.
  dbaron: Something to say it's not true or false?
  zcorpan: I don't see why it needs to be descriptive.
  dbaron: The pattern is it's fired on the object and you look at
          that to determine true/false
  TabAtkins: An event is fired in both matched and unmatched cases.
  TabAtkins: uuuuhhh...anything other than match-change.

  glazou: Go for change.
  TabAtkins: Cool. Go for change
  hober: I want to make sure resolution is clear we're adding API

  TabAtkins: Make MQ lists and EventTarget for the change event and
             alias the existing listener to addEventListener and
  TabAtkins: Any objections to that?
  hober: I don't object, I'm concerned about compat impact.

  RESOLVED: Make MQ lists and EventTarget for the change event and
            alias the existing listener to addEventListener and

  glazou: Next item.
  TabAtkins: Isn't the next item stop?
  glazou: Yes.

  [End of Day - Return tomorrow 9am Seoul time]

Received on Sunday, 8 June 2014 23:43:25 UTC