- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Jun 2014 19:42:57 -0400
- To: www-style@w3.org
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
Australia.
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
removeEventListener
==== FULL MINUTES BELOW ======
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
that.
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
manners?
TabAtkins: There's speak-as, which lets you say to read the
numeric value, read as a bullet, or read alphabetical
values.
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
objections.
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,
second...
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
out?
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?
[silence]
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
words?
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
these.
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"
value.
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
suffix.
fantasai: If you have outside markers then do you want that space
there?
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
others?
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
outside.
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
negative.
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
extends.
TabAtkins: I'm okay with this.
dbaron: One issue with extends is that it makes it sound like it
adds.
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
ideas?
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
different.
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
participation
<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.
Agenda
------
This discussion to set the agenda held no technical details.
Please see the IRC log for full minutes.
http://krijnhoetmer.nl/irc-logs/css/20140519#l-1802
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.
http://www.w3.org/wiki/TPAC2014
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
something.
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
problematic.
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
that?
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
surrogates?
<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
changes.
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
change.
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
http://www.w3.org/mid/20140416171058.GA31844@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
isn't.
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
removeEventListener.
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
removeEventListener
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