- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Mar 2014 20:33:10 -0400
- To: www-style@w3.org
Shapes to CR
------------
- RESOLVED: Take Shapes to CR
Namespaces update
-----------------
- RESOLVED: Update namespaces spec
Writing modes: Rename extent/measure to block-size/inline-size?
---------------------------------------------------------------
- RESOLVED: Rename measure and extent to inline-something and
block-something with something TBD ASAP.
- SimonSapin will lead the conversation on the mailing list to
decide what word will replace something.
Lists WD
--------
- RESOLVED: Publish a new WD of Lists
Shadow Styling
--------------
- TabAtkins brought his proposal to the group to resolve the
discrepancy between using combinators and using pseudo
classes in Shadow DOM by creating redundancy.
- There was a lot of disagreement about the value of building
redundancy and about the need to keep to the time-table
requested by Google.
- There was lack of consensus from the working group about a final
solution and therefore none of TabAtkins' proposals were
resolved upon.
:Changed pseudo-class
---------------------
- The group responded favorably to having a pseudo-class to track
user changes, but wished to gather more information about
use cases.
- TabAtkins will head up gathering use cases.
<custom-ident>
--------------
- Some issues with last week's resolution were discussed to
further clarify/refine the restrictions on custom-ident.
- A desire was raised to have a global list of restricted values
as well as a desire to ensure that the solution minimize
opportunity for confusion for authors or spec writers.
=====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Bruno de Oliveira Abinader (IRC only)
Elika Etemad
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Edward O'Connor
Matt Rakow
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Greg Whitworth
Steve Zilles
Regrets:
Chris Lilley
Peter Linss
Anton Prowse
Lea Verou
ScribeNick: dael
glazou: Let's start
glazou: Any extra items?
astearns_: I'd like to take shapes to CR.
Bert: One more, fantasai asked for namespaces to be updated.
glazou: Okay.
glazou: Is that all?
glazou: Since TabAtkins is part of almost all this, lets start
with Shapes.
glazou: fantasai are you there?
[silence]
Shapes to CR
------------
astearns_: I got some feedback from the WG and I changed an
example based on howcome's feedback.
astearns_: He hasn't responded, but that's all the feedback we've
had so we should transition to CR.
glazou: I agree. Other opinions?
leif: I haven't read the feedback. I'm not sure if I'm comfortable
without review.
astearns_: Howcome's feedback was discussed on call last week with
some resolutions. The only part of the feedback
actionable was something to stop using empty divs.
astearns_: I made those changes and the rest of the issues the WG
decided to postpone.
leif: So the feedback was addressed? In that case I'm fine.
astearns_: Any other opinions on the CR transition?
glazou: I guess we can resolve?
RESOLVED: Take Shapes to CR
glazou: Who will do the transition process? Bert?
bert: I guess, yes.
glazou: I'm available for the call.
??: I think we have calls on Monday if we can move for that.
glazou: I'm okay with that.
bert: I'll send the transition request today.
Namespaces update
-----------------
bert: I just wanted to know how we're going to approach it. It was
brought up on the mailing list
fantasai: We can do it on the call. Any objections to updated
namespaces?
glazou: I want to see the dev doc. Give me a second.
<Bert> -> http://dev.w3.org/csswg/css-namespaces/#css-qnames
Namespaces grammar rules.
glazou: There were a lot of issues. We extracted everything we
needed to from the doc, right? Yes. Ok. So I have no
objections.
glenn: I just wanter to verify that the changes don't affect
conformance.
SimonSapin: Correct.
glenn: So there's no need for a PER process in other words?
SimonSapin: I think that's what fantasai was suggesting.
glazou: We lost fantasai.
<Bert> (No need for a PER review, as far as I can see.)
<fantasai> Sorry, I lost connection
<fantasai> trying to get back on
glazou: Any objections about updating the document?
glazou: Okay. Bert?
bert: Ok. If that's the conclusion I'll make sure it get published.
glazou: I hear no objections so I think there's consensus.
RESOLVED: Update namespaces spec
Action bert to update namespaces spec
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-621 - Update namespaces spec [on Bert
Bos - due 2014-03-19].
glazou: TabAtkins are you on call?
glazou: Not yet.
<TabAtkins> I'm here, one sec.
<TabAtkins> Dunno why you can't hear me.
<TabAtkins> Let me re-call.
Writing modes: Rename extent/measure to block-size/inline-size?
---------------------------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0822.html
* fantasai is in favor
SimonSapin: There's 2 items.
SimonSapin: We have in the spec. extent is the height and measure
is width.
SimonSapin: I get them wrong because it's hard to tell which is
which.
SimonSapin: I propose we do inline-size and block-size.
* Bert likes "measure" but doesn't mind inline size either.
glazou: I kinda like it.
glazou: Other comments?
<astearns_> fine by me
rossen: So your proposal is inline-size and block-size?
rossen: My only objection is that size usually is both width and
height.
rossen: So using size is a bit misleading.
rossen: I'd prefer to have one identifier for that.
rossen: If measure and breatdh doesn't work, I'm fine with finding
something better, but size isn't good.
<Bert> (Box uses inline dimension and block dimension, inspired by
XSL's {inline,block}-progression dimension.)
<TabAtkins> We use "size" as a generic term for, well, sizes, all
over the place.
<TabAtkins> It's not exclusive to width/height.
SimonSapin: That was from the mailing list. I agreed that it could
be inline dimension, not just size.
rossen: How about length?
<fantasai> We decided against length because of mixup with <length>
rossen: Inline-measure and block-measure would be good.
TabAtkins: I tried to object in chat. We use size all over as a
generic word.
TabAtkins: It's not width/heigh specific.
Rossen: Generically I agree, but usually it's both.
TabAtkins: Yes, but we use size for all kinds of things. It's not
tied to a fragment width or height.
Rossen: Again, I think we make mistakes, but why keep going with
them?
TabAtkins: I don't think it's a mistake. I think it's good. I
don't want to use measure and length isn't much longer
a word.
<glenn> how about "length"
<glenn> or "dimension"
<SteveZ> How about "block-extent" and "inline-extent"?
<glenn> don't like "size"
<dbaron> I'm in favor of inline-size and block-size as well,
though I'd also be fine with inline-X and block-X for
some other X.
<tantek> bikeshedding on the call FTW!
<fantasai> SteveZ, block-extent & inline-measure? :)
<SteveZ> I like the "block-X" and "inline-X" terminology
glazou: I'm not sure that this is the best use of our time.
glazou: SimonSapin can you continue the conversation over e-mail?
SimonSapin: Yes.
SimonSapin: I think we agree block-something and inline-something,
we just need the something.
TabAtkins: Can we resolve that?
glazou: I'm okay with that.
rossen: What's the resolution for?
TabAtkins: Rename measure and extent to inline-something and block-
something with something TBD ASAP.
glazou: rossen, you okay what that?
rossen: Mostly. I don't see the point of resolving without the
something.
rossen: But if we need a sub resolution, that's okay.
RESOLVED: Rename measure and extent to inline-something and block-
something with something TBD ASAP.
Lists WD
--------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0216.html
TabAtkins: The current list spec on TR is from 2011
TabAtkins: It still has old counterstyles. I just want to update
TR with current ED.
TabAtkins: I don't love it, but it's better then what's there now
so I'd like to get rid of the obsolete one.
fantasai: I think it's good to update even though the draft is
shaky, but we should have notices on what's completely
experimental and may have compat issues.
fantasai: So if we take a week to label, I'm happy to publish.
TabAtkins: We can spend time checking everything and doing
disclaimers.
glazou: We agreed a while ago to have changes from previous
versions.
glazou: There's only changes from CSS2.1.
fantasai: I think this is appropriate because the old version is
so out of date.
fantasai: This is pretty much a rewrite.
glazou: I agree, but we need to say exactly what you said.
glazou: We're not the only ones to read the whole spec.
glazou: Tweek the edits and do the reviews and everything?
fantasai: So we'll aim for next Thursday to publish?
glazou: So is that a decision to publish today or revisit next
week?
TabAtkins: Unless anyone needs to review our changes, I'd like a
resolution and we'll post when it's ready
glazou: Any objections?
RESOLVED: Publish a new WD of Lists
Shadow Styling
--------------
TabAtkins: I'd like to discuss what's I've added as a resolution
to what we've discussed.
TabAtkins: I agreed with fantasai that using a pseudo-class for
the root is good, but shadow root was bad.
TabAtkins: Our compromise is that the shadow pseudo exists, but so
does shadow deep and a shadow combinator.
TabAtkins: Reason for shadow combinator is because we don't think
we'll have the shadow pseudo soon because it's hard to
do pseudo-class and combinator.
TabAtkins: I think redundancy allows a more reasonable timetable.
fantasai: I don't think redundancy makes sense because it's going
to ship.
TabAtkins: We can't want a year to ship. We can do a combinator
not a pseudo-class.
<tantek> "not going to wait a year" <-- is that an extension of
the "ultimatum" ?
* sylvaing_ doesn't really care about anyone's shipping schedule.
fantasai: Rather then hacking CSS to have two things that do the
same thing, hack your parser and put it there.
TabAtkins: That's a bad solution.
fantasai: It doesn't make sense to say we want this, but we're
doing this.
TabAtkins: Shadow combinator isn't bad because what it does is
consistent with shadow-deep.
TabAtkins: Pseudo-class works with the rest of CSS, but not here.
fantasai: Then we should do combinator. Both doesn't make sense.
TabAtkins: I'm fine with doing just combinator. We don't lose power
fantasai: Yes you do
TabAtkins: That's what the :top one is for
glazou: I feel we have to decide something under pressure due to
TabAtkins's employers demands. That's a personal comment.
glazou: As a member I don't care about that agenda. I want it the
right way.
glazou: I don't like the pressure and I don't like any of the
proposed solutions.
TabAtkins: I understand. I don't like this, but we need something
in a reasonable time frame
TabAtkins: We have something that would work and something that
wouldn't.
hober: TabAtkins you could always prefix now and implement later.
TabAtkins: If we implement prefix it'll stick and we can't remove
it later.
TabAtkins: If we do that, we should pick a name and assume that'll
go in a spec later.
rossen: So is the combinator completely out of the question?
TabAtkins: I'm fine with just combinators. I added pseudo-class
for fantasai but I'm fine with any of the solutions in
the draft.
TabAtkins: Pure combinators are fine with me, but I can be flexible
* sylvaing_ thinks Google is welcome to ship whatever it wants.
And the WG is free to disagree and change its mind
later. Life goes on.
* fantasai "I'm flexible as long as I get what I want"
* krit fantasai: "I can be flexible here because it is what I
prefer"
* tantek is leaning towards sylvaing_'s opinion.
<bkardell_> I think pure combinators seems like a better idea...
we can always add pseudo element later. you can't add
combinators later here, they are kinda the thing that
we need.
glazou: So you're asking for the WG to agree to do something.
glazou: I don't think we need more time on this discussion, I
think we need to do an answer.
glazou: Who agrees with TabAtkins? Let you publish this like the
WG agrees with it.
TabAtkins: What does agree with me mean?
glazou: You're asking for a combinator decision.
glazou: You want to WG to agree about the combinator.
TabAtkins: We can do pure combinator or combinator and pseudo-
class combination in the draft.
TabAtkins: But I want a decision.
glazou: So who objects?
<SteveZ> I am unhappy with having a redundant feature.
<sylvaing_> Google's shipping policy shouldn't force a decision on
anything.
<sylvaing_> If there isn't any consensus, there isn't.
fantasai: I don't agree with that.
fantasai: I don't agree with having two things that do the same
thing with no better reason then Google wants to ship.
TabAtkins: Are you okay with just combinators?
fantasai: I think combinator and :top solution is pretty messy.
fantasai: I don't think it's a good solution
TabAtkins: Do you dislike enough to object?
fantasai: I do enough given that the argument in the other
direction is you want to ship.
fantasai: I agree with sylvaing.
glazou: There doesn't seem to be agreement and I'm not ready to
agree to let this go.
TabAtkins: Keep in mind this started in September. It didn't get
much attention, but it's been there for a while
glazou: I was saying that the statement no one is paying attention
to is false.
TabAtkins: I can show the lack of e-mail.
glazou: That's a lack of discussion, not the lack of attention.
<sylvaing_> How long the issue has been open is no grounds to
force a decision either.
TabAtkins: So if someone reviewed and gave no feedback, that's
normally a check.
glazou: That does happen all the time
TabAtkins: It's hard to tell silent consensus from not caring.
<sylvaing_> What part of 'no consensus' is unclear?
<tantek> it IS hard to tell silent consent from silent apathy.
* hober too
<tantek> oh looks like hober also disagrees
TabAtkins: I'd like a resolution.
glazou: So sylvaing, fantasai, and myself don't like to have a
resolution right now.
glazou: I'd like to hear from others. hober too.
<sylvaing_> I don't mind people requesting a decision. I do mind
people demanding them. There is a huge difference.
<glenn> -1
<hober> I agree with sylvaing/fantasai/glazou
<TabAtkins> sylvaing_, I 've been requesting a decision since the
f2f...
<sylvaing_> So what?
* krit TabAtkins you just forgot to mention that you want to ship
immediately at the F2F :P
glazou: I'd like positive or negative, but I want more opinions.
rossen: I would actually prefer to have a solution as well.
rossen: I'd prefer something not forced by time, but I don't think
we're too far from a conclusion.
rossen: Saying we have to ship isn't great, but it will get a
decision sooner or later.
rossen: I'm for making progress and I think the shipping thing can
be permitted.
glazou: We have 4 people that don't want to make a decision, so
there isn't consensus. I'm sorry
TabAtkins: Just be aware that time will force us to decide
something and ship it so no decision is a decision.
glazou: So I can't care a a co-chair.
TabAtkins: We tried to do this publicly so everyone was aware.
glazou: I'm here to make the decision of the WG and the WG opinion
is to not decide now.
<tantek> Google threatening to ship reminds me of MS threatening
to ship years ago.
<sylvaing_> Tantek, yes. Google doing a super good job playing old-
school MSFT.
<hober> "Further, we will take on an active commitment to shepherd
the feature through the standards process, accepting the
burden of possible API changes."
* tantek is grateful for MSFT's evolution.
* tantek is hopeful Google will similarly mature/evolve.
<krit> At least Google is transparent and open when they are
threatening.
bkardell: Can I ask a question of TabAtkins?
bkardell: Could Google get away without :top pseudo-class?
TabAtkins: I think it's needed to content combinator, but I'm not
100% sure.
TabAtkin: We could maybe get away without it.
bkardell: It seems like you need a combinator, and I was wondering
if we could narrow down and avoid controversy.
fantasai: The idea of pseudo-class is you use it to avoid other
combinators.
fantasai: So shadow combinator is the same as the pseudo-class.
fantasai: If you want the :top combinator you avoid using the
pseudo-class.
bkardell: So the shadow deep wouldn't make sense as a pseudo-class.
TabAtkins: Yes.
<fantasai> e.g. A /shadow/ B is equivalent to A::shadow B
<fantasai> and A /shadow/ B:top is equivalent to A::shadow > B
TabAtkins: Well, we can move on.
:Changed pseudo-class
---------------------
TabAtkins: I can't pull up the thread because I don't have easy
internet use.
<SimonSapin> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0217.html
<SimonSapin> Rather,
http://lists.w3.org/Archives/Public/www-style/2014Feb/0511.html
TabAtkins: The explanation is Dean asked for a pseudo-class for
anything touched by the user since the form was done.
TabAtkins: It's not about validity, but if the value was changed.
TabAtkins: Seemed reasonable.
TabAtkins: A use case was to color anything touched when modifying
data so you can see what's changed and you know what
will change with a submit button.
<tantek> Yes we kind of need this,
<tantek> Because existing valid/invalid pseudos are crap for
actual decent UX.
fantasai: Is this checking against initial state on DOM or if you
change something twice?
TabAtkins: I'd think against the DOM.
TabAtkins: Value vs default value.
dbaron: I think we want "has the user touched it" more than is
that value different from default.
<tantek> dbaron++
TabAtkins: Question is what would revoke the user touched it? I
can see where there's a revert button to stop match
change.
dbaron: I would think input reset should.
TabAtkins: I think that clears things, but I'm not sure.
dbaron: Did we agree to add UI invalid?
TabAtkins: Yes.
dbaron: I think this is less important than as the UI invalid is
combined with invalid.
dbaron: I still tend to think we want something where user hasn't
touched it.
dbaron: Feedback would be good from those with use cases.
TabAtkins: I'd be happy to go into more detail with use cases.
fantasai: We might want both.
TabAtkins: Possibly.
TabAtkins: I'll gather more info and bring up later.
<tantek> BTW, re: :changed, I noted (1) that making it user-action
sensitive is more useful (per the usecases), and (2)
concern that :changed would/might mean something
different that the ONCHANGE event. Said this on the phone
but got disconnected.
<custom-ident>
--------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0218.html
SimonSapin: We had the resolution last week.
SimonSapin: It wasn't clear whether that also applied to css-wide
keywords.
SimonSapin: Fantasai made the point that we have different words.
Some names that would be a problem, you couldn't use
them in other properties.
SimonSapin: So maybe we should exclude CSS keywords on both sides.
* dbaron can't quite hear SimonSapin well enough
<TabAtkins> Example: You jlicould maybe write "grid-template-rows:
5px (inherit) 10px", but you couldn't then write "grid-
row-start: inherit;"
SimonSapin: fantasai is that a good explanation?
TabAtkins: I can restate.
TabAtkins: So the resolution we wanted was that you only had to
exclude keywords in same context as you,
TabAtkins: But global keywords, fantasai asked if we should always
exclude.
TabAtkins: Furthermore keywords that are limited in one property
but used in another, if we should still recommend
/require that they would be invalid because they would
be invalid in other context.
TabAtkins: In the example I put above you could use it there, but
not in grid-row-start.
TabAtkins: Should we say that's disallowed, or in some places you
can define against a set of disallowed, even if it's
invalid in a different place?
<dbaron> It seems good to have the same invalidity rules for grid
template line names in all contexts.
dbaron: I think same rules everywhere is better.
TabAtkins: The potential issue is that invalidates a lot.
TabAtkins: For example counter styles has a lot of keywords so you
have to exclude, for example, none.
TabAtkins: There's another half dozen in list-style shorthand,
should they all be excluded as counter style names?
fantasai: Maybe short hand vs long hand difference, though that
changes over time too.
fantasai: What's clear is excluding global words would be better.
TabAtkins: Yes, so anything in top level excludes.
SteveZ: It's easier to exclude all of them. There aren't that many
and it's easier to remember to exclude them all.
TabAtkins: I'm not sure, though.
TabAtkins: When someone tries to make a counter style named
"outside" and it doesn't work, is that confusing?
TabAtkins: I'm not certain.
<dbaron> I'm fine with the shorthand/longhand distinction.
SteveZ: Alternately is the person making it not sure it's valid or
not sure it's invalid?
SteveZ: The nice thing about a simple rules is even if it's
obnoxious, it's easy to apply because you don't need
context.
SteveZ: That's why I advocate for it. There's times when people
don't know how to use something because it's context based.
TabAtkins: That makes sense, but what's simpler?
TabAtkins: At this point we're talking spec author. Maybe we can
resolve that we disallow global and recommend authors
disallow any problem values.
fantasai: It's a little bit looser, but it allows if you have a
value with a required keyword and a custom-ident, that
clearly makes its own linkspace.
fantasai: It won't conflict so there's no need to exclude.
fantasai: So I guess I'm going with more nuanced "context".
TabAtkins: Only reason I'm not happy it doesn't have any default
allowances.
TabAtkins: It allows you to spec any custom-ident, I'd prefer a
list of defaults and allow custom.
fantasai: I think the idea was a general rule, but each spec
explains in a more specific way,
fantasai: Because the rule is a little subject to
misinterpretation or incorrect thinking.
fantasai: But if you could tell in this context, this is excluded.
TabAtkins: I'm aiming for easier spec maintainer. I don't want to
require spec authors to include more.
TabAtkins: People will forget and it'll be missed.
fantasai: Both these versions have a default rule.
fantasai: If you give the authors an easy explanation, that's
better.
fantasai: My rule is about parsing.
glazou: We should wrap up.
TabAtkins: I'm happy with parsing ambiguity.
dbaron: Which one is yours?
TabAtkins: I don't recall, I was trying to remember from last week
minutes.
<fantasai> An identifier that could be interpreted as a pre-
defined keyword in any position or multiplication of
the <custom-ident> component value is excluded, and is
invalid as a <custom-ident> matching to that component
value even in positions where its use would be
technically unambiguous. For example, if a keyword
could be misparsed when specified as the first item of
a ''<custom-ident>+'' list, it is invalid when
specified in any position in that list.
fantasai: [reads the above]
fantasai: I'm happy with clearer wording, but I think that's a
good rule.
dbaron: It's possible that needs a short hand exception.
* dauwhe I'm fine with any rule that could be built into a CSS
validator.
fantasai: Let's do this on the list as a thread, I have to go.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Mar/0127.html
glazou: So I guess this is it for the day. We had one item left,
subgrid, but no time to discuss.
glazou: Thank you everyone, talk to you next week.
Received on Thursday, 13 March 2014 00:33:38 UTC