- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Feb 2014 10:49:44 -0500
- To: www-style@w3.org
Writing Modes to CR
-------------------
- RESOLVED: Changed text-combine-horizontal to text-combine-
upright and take it to CR adding the note about
feedback for mixed directions.
Follow up on Selectors subject indicator
---------------------------------------
- RESOLVED: Use :has() as subject selector
Follow up on Shadow DOM
-----------------------
- There was discussion about if Shadow DOM should use pseudo-
element or combinator syntax. Ultimately it was decided to
defer on a resolution for syntax until next week so that
everyone can mull over the implications of the various
options.
- There was also conversation about how to adapt to webapps likely
adding a flag for opt-in/opt-out settings, but TabAtkins
argued that it will be easy to make the adjustments once
webapps finalizes their decision.
Charter Update
--------------
- Plh reported that he thinks the charter should be able to go out
next week.
CSS Syntax
----------
- TabAtkins reported that he's received a lot of feedback on
Syntax since the resolution to take it to CR so he'll edit
the disposition of comments and come back to the group for
another resolution.
Renaming fill-available
-----------------------
- RESOLVED: change fill-available to fill
Namespace
---------
- Fantasai will add text to namespace to allow the use of wildcard
and also investigate getting the TR version updated.
She'll then come back to the group for a resolution.
====FULL MINUTES BELOW======
Present:
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Liam Quin
Matt Rakow
Simon Sapin
Dirk Schultz
Alan Stearns
Lea Verou
Regrets:
Glenn Adams
Mihai Balan
Bruno de Oliveira Abinader
Brad Kemper
Florian Rivoal
Leif Arne Storset
ScribeNick: Dael
plinss: Let's start.
plinss: I saw the note about adding writing modes to the agenda,
anything else?
SimonSapin: I heard some things about transitions that happened
this week.
plinss: It went to CR, no one posted anything.
glazou: I tweeted about it from the official Twitter account.
plinss: Publication is being done by Bert, nothing else for us to
do except work on test suites.
plinss: But transitions are going.
plinss: Anything else to add?
plinss: Bert, we were just talking about the transitions, do you
need anything?
bert: No, everything is in process.
bert: It's not online yet, maybe tomorrow.
Writing Modes to CR
-------------------
plinss: Koji, you wanted to do writing modes.
koji: Yes, I think fantasai and I think we're ready.
plinss: Ok. Any objections to taking it to CR?
* fantasai still wants to rename text-combine-horizontal, though.
plinss: fantasai you had a note on IRC, should that be at risk?
fantasai: Webkit implements -epub-text-combine,
fantasai: MSFT implements -ms-text-combine-horizontal,
fantasai: They're not compatible and don't follow spec, but the
basic use-cases are compatible.
fantasai: My only concern is I don't like the name. -horizontal is
confusing.
fantasai: Glyph horizontal only applies in text.
fantasai: Horizontal only applies to horizontal text and this
applies to vertical in addition to horizontal so it's
inconsistent.
koji: So are you happy to go to CR now?
fantasai: I don't want to hold up the spec
fantasai: I'm just unhappy with that aspect.
plinss: Okay. Any objections?
fantasai: Anyone else have comments on that issue?
plinss: Suggestions for a better name?
fantasai: I think John Daggett once suggested text-combine-upright.
dbaron: I have one other question.
dbaron: Do you think the stuff on mixed directions is solid?
fantasai: Not as much as I would like.
fantasai: I think it's poorly explained and confusing and may be
wrong in some cases
dbaron: I think I'm okay with that as long as we understand that
implementation will lead to changes.
fantasai: That will be helpful.
dbaron: And lead to another LC in CR.
fantasai: I think that will happen, but I haven't gotten anyone to
help review.
dbaron: I think implementation will help since the implementors
will have to review.
fantasai: I agree.
plinss: Any notes in spec about that?
fantasai: About it being unstable? No. I can add some.
plinss: I'm not sure if we want to call it unstable as they won't
implement. Maybe say in a note that we want feedback.
plinss: But that's the point of CR.
dbaron: It might be good to have a note that we're particularly
interested in feedback in that section.
plinss: Any other comments?
fantasai: Anything else on text-combine-horizontal?
[silence]
plinss: Apparently not.
fantasai: If no one cares, lets rename it.
plinss: To text-combine-upright? Fine with me. Any objections?
plinss: I think text-combine-horizontal is better from what you
said.
* Bert likes upright better, too.
RESOLVED: Changed text-combine-horizontal to text-combine-upright
and take it to CR adding the note about feedback from
dbaron.
Follow up on Selectors subject indicator
---------------------------------------
plinss: Let's try and resolve this.
TabAtkins: I have the results written up.
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Feb/0441.html
TabAtkins: So they were extremely clear. In both ! and ^
comparison over 80% liked the combinator
TabAtkins: Most of the reasons were what we had given.
TabAtkins: The most common refrain is people preferred :has()
because it was easier to understand.
TabAtkins: They liked words instead of ASCII.
TabAtkins: I think it's clear we should switch to :has() psuedo-
class.
plinss: Any other thoughts?
fantasai: I can't object to consistent survey results.
TabAtkins: We have over 1,000 responses so it's good size.
dbaron: One thought I had was thinking about how one would
implement and there's one strategy that wouldn't work for
:has() , but I don't know if it would work for anything.
TabAtkins: They should be equivalent.
dbaron: With :has() you can have more than one downward chain.
TabAtkins: You can do it with subject indicators.
fantasai: That's why we banned it originally from :matches()
plinss: To be clear, we're not excluding multiple :has()
TabAtkins: I'd like to not. Theoretically there's no reason. This
will be slow anyway so it will fall into complete, not
fast.
fantasai: Basic syntax, subject indicator doesn't allow branching
of the selector, but :has() does allow it.
fantasai: In the first case you'd have to allow :matches(), but
for :has() you have it from the beginning
dbaron: I think I'm okay.
plinss: I presume we want to exclude nested :has()?
TabAtkins: I'm fine either way.
plinss: I'm not sure what it would mean.
TabAtkins: You're reevaluating based on it's children. Their
usefulness is extremely niche.
TabAtkins: I don't want restrictions, but I'm fine with excluding
if it's glitchy.
bkardell: Does :matches() exclude nesting?
TabAtkins: It does, but we need to fix that. We were planning on
revisiting that based on last F2F discussion.
plinss: Thinking about nested :has(). You can ignore the nested,
but I'm not sure if that's relevant.
plinss: Any objections to adopting :has() as the subject selector?
* Bert No strong objection, but I think '!A > B' looks better than
'A:has(> B)' though...
* glazou is with Bert here but will not object.
* fantasai too
* leaverou same here, agreed with Bert.
RESOLVED: Use :has() as subject selector
TabAtkins: For aliases you can remove psuedo-class and use :has()
for implementation
Follow up on Shadow DOM
-----------------------
plinss: There's lots of talk on www-style. Let's see if we can get
some traction. TabAtkins, do you want to summarize?
TabAtkins: We haven't made any major changes since F2F. We've
shifted syntax of combinators from ASCII to /shadow
TabAtkins: Based on fantasai's suggestion, it's now /shadow/ so
it's more a combinator and avoids odd whitespace rules.
TabAtkins There's 2 issues to resolve:
TabAtkins: Original combinators are the equivalent of /shadow-all/
TabAtkins: I added shadow which only selects children of shadow
roots.
TabAtkins: They wanted the shortest path that wasn't a definitive
combinator.
TabAtkins: However, later there was an objection from Elliott that
using shadow to select children make you more dependent
on other elements, but shadow-all lets you be more
knowledge-free.
TabAtkins: He thought it would make more sense for the shortest
and easiest thing to be less fragile.
TabAtkins: There's an author-concern about it being shorter and a
usability concern about the child selection.
TabAtkins: The preference concern isn't as strong. During matching
it's cheap to move from an arbitrary element to it's
host.
TabAtkins: For matching purposes they're the same, but for
updating purposes, then the child variant does have an
impact.
TabAtkins: I'm not sure how to fix this.
dbaron: Did Boris and Jonas get a chance to respond to Elliott's
response?
<bkardell_> So the concern is related to a change to an element in
the parent document requires reevaluation?
<bkardell_> .foo /shadow/ .bar
fantasai: On a related note, you sent an e-mail about if we should
use pseudo-class or combinator syntax.
fantasai: Based on an e-mail about this it seemed to be a psuedo-
element is better then combinator so you don't have to
select everything. You're in the tree and you don't have
to have it be different for child vs descendant.
fantasai: It's just a straight-up selector.
TabAtkins: One argument against that, we'll still have super-
descendant.
TabAtkins: Even if we change child vs descendant, we'll still have
another combinator. It feels off to have both.
fantasai: One of the pieces is if it's a psuedo-element it would
be strange you can use a child combinator and it would
select descendants.
TabAtkins: I'm not sure what it means and I think at that point
you're using psuedo-elements as combinators.
plinss: I think this is about my proposal. What I said was if you
use pseudo-element to expose, it's a different model to
expose.
TabAtkins: That's another question.
fantasai: What it means is shadow creates an access to one level
down and shadow-all is the combination of all shadow
trees.
fantasai: So it's consistent to use pseudo-element for both.
fantasai: And would be consistent with ::first-child if we allow
selection inside.
TabAtkins: That works regardless of approach.
fantasai: But it's consistent.
fantasai: My conclusion is it's better to use pseudo-element.
plinss: So there's combinator, pseudo-element to pierce shadow
tree or pseudo-element to expose the inside.
TabAtkins: I think the third is a separate issue and dependent on
what webapps does.
TabAtkins: I don't think we should encapsulate when JS does it.
hober: There was consensuses in webapps to add a flag to allow opt-
in/out.
hober: Putting aside the default, I think in CSS we should design
assuming the flag exists.
hober: I think we need to use the flag.
TabAtkins: That's easier to resolve.
TabAtkins: If they have the flag we should shut down completely.
Then we do what plinss has proposed to expose specific
things.
hober: Right now you have /shadow/ etc. Suppose that was
/custom ident/.
hober: And if you wanted to expose the whole tree you could do
that with /shadow/.
hober: If there were particular things to expose you could do that.
hober: I think syntax should be the same for public and private.
TabAtkins: I'd rather not consume the syntax for shadow DOM. We
didn't want to swap syntax just for shadow. I wanted
/foo/ to be how we do combinators.
hober: So /ident/ is how you get at stuff?
TabAtkins: That's a viable way forward assuming we end up in that
world.
hober: I think we will be in that world. Let's assume the flag
will be added. I think it could go either way, but the flag
is the consensus.
TabAtkins: We know what we would do if the flag exists and have
plans, I think that's all we need to do.
bkardell: Any way to add a note in spec that it may only select
what's permitted?
TabAtkins: We'll edit accordingly.
hober: I'm just worried about resolving syntax before webapps
makes a decision.
TabAtkins: All our syntax plans have extensions for only exposing
pieces.
TabAtkins: So original conversation is pseudo vs combinators.
TabAtkins: Since we already have child vs descendant, we shouldn't
reinvent?
fantasai: And there's no reason pseudo-element is inconsistent
with how we use pseudo-elements elsewhere.
fantasai: We don't need a magic combinator and pseudo-element lets
you go into an alt tree.
<glazou> +1
* sgalineau doesn't like confusing what :: means for authors.
TabAtkins: My only problem is pseudo matches nothing. It's a root
of a pretend tree. It seems inelegant.
hober: Maybe we need a new syntax for DocumentFragment where you
can't apply property directly.
TabAtkins: That's what combinator is trying, but it's got the
inelegance of repetition.
fantasai: Does shadow tree always have a root?
TabAtkins: Yes.
<sgalineau> Is the shadow root something you can set properties on?
<sgalineau> It'd be awkward to be unable to set properties on
E::shadow
fantasai: Is it representative of a DocumentFragment thing? One
happens to be style-able and the other isn't?
TabAtkins: You mean first line?
fantasai: Yes.
TabAtkins: The first line is odd, but you can style it. It's a
thing.
fantasai: In the context of CSS you can style. In another
environment you can grab fragment things. In that case
pseudo would represent a fragment.
TabAtkins: Idea: Rather than making named variants, what if we did
the below.
<TabAtkins> /shadow/ /shadow>/
<TabAtkins> ::shadow>
TabAtkins: I don't know if that look weird.
fantasai: It does.
<fantasai> ::shadow > foo
TabAtkins: Weirder then that?
<TabAtkins> /shadow >/
fantasai: No weirder then that. It looks normal
TabAtkins: This can also be taken to all combinators that are
similar.
TabAtkins: And you can do same with pseudo.
TabAtkins: This lets you not create new names for ASCII
combinators without exposing the weird of a non-
existent pseudo element.
TabAtkins: We're almost there.
fantasai: I'm pretty confident that pseudo is the right way to go
fantasai: I don't see any arguments on the other side. They're all
against your previous ASCII combinator.
TabAtkins: My main argument is it doesn't represent anything.
fantasai: Not in CSS. It could be some API that returns either
elements or fragment-y things.
hober: I think this is not just shadow DOM.
hober: They exist elsewhere and we should talk about it.
TabAtkins: That would be similar to :attr where CSS doesn't care,
but specialized things do.
TabAtkins: We could have something that returns shadow root in JS.
hober: You can picture passing this to query selectors.
hober: It's not a pseudo element, it's a pseudo fragment.
hober: I like the pseudo-element-like syntax, but not ::
fantasai: I think the point is to use pseudo element syntax
because it's like one and acts like one in the context
of selectors.
fantasai: If we do regions, you can do ::region and select the
things inside regions, then you want to do ::first-line
fantasai: These are all structurally similar.
fantasai: It's not inconsistent with pseudo elements so we should
use that.
TabAtkins: I want to give this more thought to make sure there's
nothing I'm missing, but I think it sounds good.
TabAtkins: Can we defer until next week?
hober: I'm also for not-resolving.
plinss: That's fine for me.
plinss: Progress of a sort.
plinss: Anything else?
Charter Update
--------------
<glazou> plh, Charter progress ?
<plh> I didn't receive all the internal comments yet. Only
comments are very minor and not worth mentioning here.
<plh> I should be done with this by next call,
<plh> And the charter should go out next week.
<glazou> plh, ok thanks.
CSS Syntax
----------
TabAtkins: I have a process question.
TabAtkins: We resolved to take Syntax to CR, but in the few weeks
since there's been a ton of feedback.
TabAtkins: I've been replying as they come, but does that effect
CR since there's changes between approval and now?
fantasai: You'll have to edit the disposition of comments and get
another resolution.
TabAtkins: I'll void the previous resolution and treat this like a
delayed LC.
Renaming fill-available
-----------------------
fantasai: TabAtkins Did you want to rename still available?
<fantasai> http://dev.w3.org/csswg/css-sizing/#width-height-keywords
TabAtkins: Small issue, I've introduced several new words.
TabAtkins: I've introduced fill-available which basically selects
what's left at 100%.
TabAtkins: Issue is we think this is a long name and instead want
to call it fill.
TabAtkins: If no one objects we'll just do the quick rename.
* dbaron tries to remember what the original name proposal was
<liam> How often will it be used?
fantasai: We'll also looking for a new name for repudiate-floats.
TabAtkins: We're not finishing this with that in there.
* sgalineau repudiate-float is, like, TOTALLY AWESOME
krit: We want to rename fill-available to fill?
fantasai: yes
krit: We use fill elsewhere and there might be issues.
TabAtkins: It's just a keyword and the ones you're talking about
is graphical and this is geometry.
TabAtkins: I think context disambiguates.
krit: I think there's others with geometry.
plinss: Anywhere we'd use a shorthand?
TabAtkins: No
TabAtkins: Don't they use a purpose with min/max?
krit: It increases size.
TabAtkins: This is still be as big as it should be, which is
reasonably close.
krit: I just want to make sure there are no conflicts with
background.
TabAtkins: They won't collide grammatically.
plinss: Do you want a resolution, or is this editorial?
fantasai: We need a resolution.
RESOLVED: change fill-available to fill
Namespace
---------
TabAtkins: Separate question for the namespace spec.
TabAtkins: I've been making edits about attributes selector and it
turns out the grammar is worthless because doesn't
allow wildcard subject.
TabAtkins: The only place it's used is selectors and this part.
TabAtkins: How difficult is it for me to edit the namespace spec
to make it more useful?
fantasai: What's the issue?
TabAtkins: When selectors have a namespace you can have a selector
before or after the bar.
TabAtkins: However the namespace spec doesn't allow wildcard. It
requires ident after the bar.
TabAtkins: So no where can use the namespace selector.
dbaron: Since when does it allow * for the attribute name?
TabAtkins: Pseudo element allows wildcard.
TabAtkins: You need to completely redefine the name of grammar for
pseudo elements.
plinss: It doesn't include the ident after namespace.
TabAtkins: It doesn't include the * after the namespace.
TabAtkins: If you look at namespace grammar, there's only an ident
prefixed with namespace or with ident.
<fantasai> http://www.w3.org/TR/css3-namespace/#css-qnames
plinss: I'm looking at it and I don't see the ident.
fantasai: Ah, you're looking at the ED
fantasai: We never updated the TR version.
<fantasai> http://dev.w3.org/csswg/css-namespaces/
fantasai: I'm happy to add a wildcard thing.
fantasai: I guess we need to publish.
dbaron: So what are we adding?
fantasai: Grammar for other specs to refer to.
dbaron: You're sure that's all?
fantasai: Positive.
<fantasai> wqwname : wqname_prefix? [ ident | '*' ]
<plh> http://www.w3.org/Style/2011/REC-css3-namespace-20110929-errata.html
notes it is empty
plinss: Let me backup, why are there differences?
fantasai: I think we just never updated the TR.
plinss: Okay. The TR is wrong.
Action: fantasai update namespace and figure out what we need to
put it on to TR
<trackbot> Created ACTION-619 - Update namedspaces and figure out
what we need to put it on to tr [on Elika Etemad - due
2014-02-26].
fantasai: It has no conformance implications to anyone anywhere
plh: If I may, I think there's two parts that you'll need to
publish again.
fantasai: Yes, we'd need to publish a new edition.
plinss: So you'll update and come back?
fantasai: Yes.
fantasai: Bert, did you publish the LC for backgrounds and borders?
bert: I don't remember, maybe not?
fantasai: You published the document, I'm wondering about the
announcement.
bert: Probably not then.
<fantasai> Bert, would you like to do that or should I?
bert: Should I or do you want to?
fantasai: I'm happy for you to do it.
plinss: Is that it for the week?
plinss: Sounds like it. Thanks everyone.
Received on Thursday, 20 February 2014 15:50:12 UTC