- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2014 21:16:04 -0500
- To: www-style@w3.org
Charter
-------
- Plh reported that we're on track for the charter extension.
New Regions WD
--------------
- RESOLVED: Publish a new WD of Regions
Selectors Poll
--------------
- There was heated debate on the validity of the poll to determine
naming syntax for Selectors as the text of the poll was
changed after about 130 responses to address concerns that
people were responding to the presence of ! instead of the
larger issue. No decision was reached as to if the poll can be
used being mindful of the change in wording or if a new poll
needs to be created.
Shadow DOM
----------
- Naming a combinator for ident was discussed with suggestions
including /ident, #ident, :ident, /ident/, and `ident`. The
group leaned toward /ident/. It was the groups opinion that
this should stay in Shadow DOM and not move into Selectors for
now.
Counter Styles API
------------------
- The group discussed the implications of Xidorn's issue of return
value for an empty string. Initial feelings were toward having
it return initial value. TabAtkins then tested the
implementation in Firefox and Chrome later in the call and
said they were returning empty strings. The discussion will
continue after more people can run tests.
Concept of Baselines
--------------------
- It was decided this issue did not need telecon time.
::first-letter
--------------
- Dbaron will write a proposal for what exactly counts as a first
letter referencing unicode.
Grid Issues
-----------
- TabAtkins indicated he's still working on the issues raised by
SimonSapin
Inline box, atomic inline-level box, and transformable elements
---------------------------------------------------------------
- The group agreed that the test at issue was incorrect because it
assumes fragments apply where they currently don't.
Line box edge
-------------
- Everyone agreed with tantek's proposal.
=====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Dongwoo Joshua Im
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Christopher Palmer
Matt Rakow
Simon Sapin
Dirk Schultz
Alan Stearns
Leif Arne Storset
Regrets:
Mihai Balan
Justin Erenkrantz
Simon Fraser
Brad Kemper
Simon Pieters
Anton Prowse
Florian Rivoal
Lea Verou
Steve Zilles
Scribe: Dael
Extra Items
-----------
glazou: Let's start
glazou: As usual, any extra items?
glazou: The agenda is pretty full, but if you have something we
can retain for next week, that's fine.
glazou: We have an item from tantek.
<tantek> (hopefully quick, had one positive response from
TabAtkins, no objections)
???: Is it worth doing a poll on the call?
glazou: You mean selectors? I suggest we do that.
glazou: I think the poll is invalid because it was changed.
TabAtkins: As I said we know who saw it before the change.
glazou: We're just adding items now, and I responded on the list.
<SimonSapin> (TabAtkins, present it as two polls with separate
results)
glazou: So first extra item is the poll. Any others?
Charter
-------
glazou: Can we have an update on charter extension? Before you
said it would be ready before the F2F.
plh: I think we're on track and don't expect any surprises.
glazou: Any questions?
New Regions WD
--------------
astearns: Just asking for a new WD. It's been 8 months since the
last WD and there's been substantial changes so I'd like
to publish.
Bert: Is this the split we discussed at the F2F?
astearns: Yes.
Bert: Okay
glazou: So you approve?
bert: I do
RESOLVED: Publish a new WD of Regions
glazou: Given that it's a hot topic, let's insert the selector
poll now
Selector Poll
-------------
glazou: So TabAtkins publisher a poll about selectors. In short it
was a question, do you prefer ! as the descriptor or :has.
glazou: The problem is originally it was ! or has but after 130
responses he changed the wording.
glazou: Lots of people rejected !
glazou: I think the new question is different and I don't think
that we can infer anything because of that.
glazou: SimonSapin suggested a new poll with three options, !
:has, or ^
glazou: So I think I reject the results of the poll.
SimonSapin: I agree results are useless but I think TabAtkins
should separate the results of the exit poll.
TabAtkins: I can do first 130 of ! vs. :has and the rest as ^ vs.
:has
glazou: I don't think you can do that.
TabAtkins: I think we have an overwhelming result.
glazou: This just isn't the same question.
TabAtkins: We've had 800 results and most of them picked the same
answer as before.
* sgalineau would love to discuss the issue instead of arguing
about the polling
<SimonSapin> sgalineau +1
<dbaron> So if you polled two separate questions at different
times, just report the results separately?
<SimonSapin> dbaron, this is effectively what happened
glazou: Taking my co-chair hat off, as a standards body we aim at
doing things right and this isn't done right. We don't
change the question in the middle of a vote.
glazou: Even if it's only 10% that disagree with what you say is
final results.
TabAtkins: We're randomly sampling in the first place, so it just
doesn't matter if they're two separate polls.
<astearns> +1 to Tab's position. The results are useful considered
separately. And they both point to the same result.
* sgalineau thinks good polling is actually hard and we're
unlikely to get anywhere near as much as we think from
those things.
* sgalineau "design by committee can't decide...let's do a poll!"
<SimonSapin> TabAtkins, please give numbers for the separate
results on IRC.
bkardell: Since I'm on neither side of the discussion,
bkardell: I think when they put the poll together what they wanted
to gage wasn't if ! is confusing.
bkardell: But they wanted an idea of if they like and indicator or
like a combinator.
bkardell: Overwhelming people picked the combinator.
bkardell: We mixed two questions and I think TabAtkins was trying
to act in good faith to see if we were asking the right
question.
bkardell: TabAtkins was saying we can derive that people want a
combinator and we can do another poll.
glazou: Reading the results, I think people were influenced by the
! and they were rejecting the !
TabAtkins: And that's why the poll was changed to see if that was
an issue.
* TabAtkins is going to leave the call until people stop ignoring
that we're random-sampling this stuff and so it
doesn't matter.
bkardell: Do we have a reason for not doing what TabAtkins Is
suggesting?
???: Is this just avoiding work so we can prove what TabAtkins is
saying or have another statement?
bkardell: I think we can frame that poll with having just three
options and that'll work.
* sgalineau 15mn into a one hour call we're still arguing about
the poll instead of the issue.
glazou: I think it's painful that we can't discuss what a member
did without him leaving.
glazou: I'm going to stop now, but I'm disputing the results which
we're going to specify.
glazou: This is impossible to discuss.
glazou: We don't have an update on Shadow DOM without TabAtkins.
<TabAtkins> I'm still here, I just can't stand listening to people
pretend that a poll is "biased" because they don't
understand population statistics.
glazou: I think saying I don't understand population stats is an
insult.
plh: I don't think that was the point, though.
glazou: I'm saying the sampling isn't valid due to the change.
sgalineau: I think there was an issue and we tried to resolve it.
We can look at the issue and try and resolve the
difference, but I think that we're running in circles
and not making progress.
glazou: TabAtkins for Shadow DOM?
Shadow DOM
----------
TabAtkins: Let me pull the info.
TabAtkins: First I'd like to see if we can finalize a named
combinator.
TabAtkins: I'm assuming that /ident is a decent syntax
TabAtkins: It looks good to me and people in the thread.
* fantasai doesn't like it
fantasai: I don't think that /ident is good because that's usually
punctuation.
TabAtkins: It's usually just a character so I think a syntax in
that pattern isn't a good idea. We have :ident #ident
etc. and they're all a compound selector.
TabAtkins: If we're going to have that, it should have punctuation
at the beginning and end and follow the white space
rules of combinators
<TabAtkins> `foo`
??: I think a few people liked the idea of brackets.
<TabAtkins> /foo/
<fantasai> /ident/
fantasai: We can just use that [above]
<fantasai> /ref somethingorother/
<SimonSapin> is '/ ident' the same as '/ident' ?
<fantasai> no
<TabAtkins> SimonSapin: No, it's not - ". ident" isn't the same as
".ident"
<SimonSapin> ok
<TabAtkins> SimonSapin: Whitespace is significant in selectors.
TabAtkins: I'm fine with that. I like single slash, but 2 is okay
as well.
<astearns> I'm OK with either as well
<fantasai> well, I guess we could define it either way :)
hober: I realize we don't have single style comments in CSS, but I
worry that using something close to C++ is confusing to
authors.
fantasai: It's a single slash followed by another slash, though.
bkardell: We could also use backticks.
<sgalineau> so fantasai would rather have something like /foo/
<sgalineau> ?
TabAtkins: I'm down with that. If the WG would like to resolve
that's fine.
fantasai: I'm still wondering if it should be combinator instead
of a pseudo-class, but I haven't read entire thread.
TabAtkins: Any other syntax suggestions?
TabAtkins: backticks, slashes or pseudo-elements?
* sgalineau caught up with IRC. Is OK with /foo/
<bkardell> I am good with `foo` or /foo/
* fantasai doesn't like backticks, they're too light
* fantasai visually
hober: This isn't strictly combinator syntax.
hober: I'm just wondering do we want to allow for future CSS to
allow author-defined custom items?
TabAtkins: Possibly which makes the ident nice.
hober: I'm not sure quite what exclusion there was but I'd rather
avoid collisions between the WG and arbitrary definitions.
TabAtkins: The way the F2F discussion went was - are technically
allowed in HTML, the main space is ident-.
TabAtkins: In CSS we use _ the same.
TabAtkins: So if your media query has _ it's custom.
hober: I'm fine with that for now.
TabAtkins: This is a little ugly, but it works. We'll avoid
collisions.
TabAtkins: Since there's no additional syntax ideas, feel free to
butt in.
TabAtkins: Are we okay with / on both ends?
TabAtkins: I'd like to resolve on that.
hober: If we want a combinator in the future we can bring it back.
fantasai: I'm not sure if using a combinator rather than pseudo-
class is right, but if we're going with a combinator
this syntax is good.
<TabAtkins> /ref(foo)/ or /ref foo/ or whatever
hober: I'd like to authorize TabAtkins to do what he needs, but
I'm not sure I want to say this is the right thing to do.
hober: Would a watered down resolution to allow you to spec be
okay?
TabAtkins: I spec'ed it. I want to know if the WG is okay with
this direction.
fantasai: Is this in selectors or shadow DOM?
TabAtkins: Putting it in selectors.
fantasai: I'd pref Shadow DOM and let selectors stabilize before
shifting things into it.
bkardell: Is that because you're not settled on named combinators?
<glenn> +1 to what fantasai is saying
fantasai: I'm not objecting per se but I'm not sure if this is the
right idea. Selectors is almost implemented and this
isn't qualified. I'd rather leave it in Shadow DOM so
that it can be discussed more.
fantasai: I don't want to mix this unstable thing with selectors
where we're trying to take unstable things out.
TabAtkins: As long as no one is actively objecting to syntax it
is good enough for me for now.
* fantasai let the shadow dom debate happen in the shadow
dom...inion
TabAtkins: In other words it sounds like we can move on,
glazou: Excellent
Counter Styles API
------------------
TabAtkins: Xidorn brought up interesting CSSOM questions
TabAtkins: If you don't spec a descriptor in the style sheet, what
rule should appear? Null, empty string, or initial
value?
glenn: Any implementation consistency?
TabAtkins: None I've seen. @font-face has it implemented.
dbaron: In many ways this is similar to properties, but there's
no difference between initial value and unset.
dbaron: My feeling is leave it the same as there's not a semantic
difference.
<dbaron> ... as the empty string
fantasai: An interesting question is if you're doing the OM, do
you want to rest, or preserve what the editor put in?
fantasai: If there's no semantic difference it seems like things
that are initial should stay set that way.
TabAtkins: That's a separate but related question. You need to
spec how these things serialize.
TabAtkins: If you omit everything you would omit anything set to
initial value too.
TabAtkins: I think I like having it reflect initial value and on
the serialization side specify you omit the scriptor is
it's they're initial value
TabAtkins: How does that sound?
dbaron: One question is what do they do for @font-face?
TabAtkins: I'm not sure. If we want to move on and come back to me
I can test for 5 min and come back with data.
TabAtkins: So let's do that. I'll come back in a few to tell you
what @font-face does in chrome and Firefox.
glazou: So we can move on?
Concept of Baselines
--------------------
dbaron: I don't think this needs telecon time.
glazou: Okay, good.
::first-letter
--------------
dbaron: We had a long debate about what goes in ::first-letter.
dbaron: The spec is specific when punctuation extends the first
letter, but not what a first letter is.
dbaron: ::first-letter applies to the first letter and also
applies to digits, but doesn't mention anything else.
dbaron: I think Gecko is the only one that does letter or digits
and we occasionally get bugs were people expect it to
apply to symbols.
dbaron: I remember + and $.
dbaron: It would be nice if the spec said what the first letter
applied to.
dbaron: There's one other quirk with this where we reference
character classes we need to say what version of Unicode
we're referencing.
dbaron: Do people think symbols should be a first letter? Is that
a bug in other implementations?
fantasai: I think it's fine. The interesting question is do we
just include the symbol, or the symbol and the next thing
astearns: I would expect only the symbol.
bert: That's not what I would expect.
SimonSapin: Is this based on unicode categories?
dbaron: That would be nice.
hober: So we would blacklist a bunch of categories it doesn't
apply to?
dbaron: That may work, things like white space.
fantasai: There's two levels of general classes in unicode, like
higher and lower level ones.
fantasai: I think we're only interested in doing high level ones.
hober: Suppose unicode decided to add a new top level class. I'd
rather have that included. I don't anticipate them adding
white space.
dbaron: I think if they add a new class, we want the old rules to
apply.
dbaron: Unless someone else wants to, I guess I should write a
proposal?
Rossen_: I think we're all agreeing.
dbaron: Sounds like we're done.
TabAtkins: Can we jump back?
Counter Styles API
------------------
TabAtkins: In both Chrome and Firefox, unspecified descriptors in
@font-face is the empty string.
TabAtkins: I'll find a place to spec that.
dbaron: Sounds good to me, given that it's what we do for
properties.
TabAtkins: Cool.
TabAtkins: Can we get a resolutions?
glazou: Comments?
TabAtkins: For any unspecified descriptors in @ rules that font-
face and counter style, they're in the OM as the empty
string
Rossen_: And this is what they do?
TabAtkins: In Chrome and fireforx.
Rossen_: Can you post that test?
<TabAtkins> <!DOCTYPE html>
<TabAtkins> <style>
<TabAtkins> @font-face {
<TabAtkins> font-family: foo;
<TabAtkins> src: url(foo);
<TabAtkins> }
<TabAtkins> </style>
TabAtkins: I did that and poked around for font weights.
glazou: To be sure, it's when you query the explicit value of a
descriptor?
TabAtkins: That's a good question.
glazou: I don't want to see it affecting a group.
TabAtkins: CSSOM defines that and implementations differ.
TabAtkins: Right now in chrome you see every property that could
apply to any element show up.
TabAtkins: That's likely because we're using the same
implementation.
glazou: Then I have no objections.
rossen: Just a second, I'm getting on my computer to test it.
TabAtkins: Do you want us to wait, or should we move on and you
can report back?
Rossen_: It'll take me two minutes.
glazou: We'll come back when Rossen_ is ready.
Grid Issues
-----------
SimonSapin: The biggest issue is how we define size of grid item
and grid container.
SimonSapin: Did I miss that in the spec, or is it not written?
TabAtkins: I'm not ready to handle the issues. We're working on it
and will answer as we get there.
TabAtkins: We haven't made it there quite yet. Fantasai and I are
working together, but were concentrating on flexbox
earlier.
TabAtkins: As soon as I can I'll do it, but if you want to message
me privately with a time line you're looking at, that's
okay.
SimonSapin: We don't need more time for any grid issues.
Inline box, atomic inline-level box, and transformable elements
---------------------------------------------------------------
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Feb/0356.html
glazou: I saw some mailing list answers on this
TabAtkins: I think he has asking about the earlier decision that
inline-elements are able to be transformed,
TabAtkins: And dbaron had a separate question that was
tangentially related about the spec only applying to
elements related to CSS.
TabAtkins: But that's different than the original question.
dbaron: My question was that the spec isn't saying what we want it
to and we should check that before we nit-pick.
dbaron: So we said it shouldn't apply to transforms.
many: Yes.
??: I think we want to say we can transform a box, not a
collection of elements.
TabAtkins: We only transform fragments that are the sole fragment
created by a box.
TabAtkins: They're the sole fragment by decision not happenstance.
dbaron: Didn't we have a long discussion about how transforms
apply to fragmented blocks at the F2F?
??: We did, but we didn't agree. The agreement was it shouldn't
apply.
* Rossen_ I'm good with the previous resolution
dbaron: Seems bad that it stops applying as soon as you print.
??: That's a good question.
dbaron: I'm okay with not applying to inline, but I'm not okay
that it stops as soon as it fragments.
TabAtkins: Starting with the base question, is the test wrong
because spec says it shouldn't apply to inline?
TabAtkins: In other words, the test is wrong. It currently assumes
that fragments apply to inline.
TabAtkins: Cool. So Gerard is right. We can take this later to
decide what the definition of transformable elements
should be.
TabAtkins: So it sounds like that finishes the issue.
glazou: Okay.
<dbaron> seems like the spec ought to exclude non-replaced inlines
rather than imply that any new formatting primitives (
flexbox, grid, etc.) aren't transformable
glazou: tantek you still there?
Line box edge
-------------
<tantek> http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html
tantek: I made a proposal to change that based on implementations.
tantek: I got one positive reply, but I wanted to run it by the
group before I edited.
???: It sounded good to me.
<fantasai> +1 from me
tantek: Thanks fantasai.
glazou: Other opinions?
fantasai: I think you want to run it by Robert O'Callahan.
tantek: I already pinged him. I want to hear from other
implementors.
tantek: We (firefox) want to match webkit and want to make sure
other implementors find it acceptable.
Rossen_: It will mean a change for us, but I agree auto behavior
makes more sense.
<Bert> +1 from me, too
glazou: Anyone from webkit?
tantek: There's two changes, one webkit already does, one that's a
logical consequence of the change.
tantek: I don't think anyone does the second behavior yet, but it
makes sense.
Rossen_: I think that's fine. We can revisit later.
glazou: No objections? You've got it tantek.
glazou: We've got more time. Anything else?
tantek: Did you do charter?
glazou: Yes. It'll be under review shortly.
tantek: I think the super-group discussion needs to continue.
glazou: Yes, from time to time it's extremely bureaucratic.
glazou: It lacks a bit, but I don't think all existing super-
groups will be in the same category.
glazou: They'll be quite different and I'm not sure the current
prose will work for everything.
tantek: I think glazou is having a positive impact and you should
keep going.
glazou: We needed something different. This isn't working.
glazou: Anything else?
glazou: Thank you and talk to you next week.
Received on Thursday, 13 February 2014 02:16:35 UTC