- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Jan 2014 20:33:49 -0500
- To: www-style@w3.org
January F2F
-----------
- Everyone was reminded to add topics for discussion to the wiki.
May F2F
-------
- Glazou confirmed that the May F2F will be in Seoul and hosted by
Samsung with the help of the W3C office.
- He requested that working group members post their availability
on the doodle he sent around so that dates can be
finalized, hopefully at the January F2F.
Selectors 4 :has()
------------------
- SimonSapin's proposal to add a :has() pseudo-class to Selectors
4 was discussed.
- The group differed on if the use of ! was confusing since it
means "not" in boolean programming. A poll will be set up
to gather more data on people's opinions.
Page Transitions
----------------
- Glazou requested that a discussion of page transitions in CSS be
added to the charter since he was hearing user demand for
them in web-based apps.
- RESOLVED: Add page transitions to the charter.
CSS 2.2
-------
- Bert reminded the group that tests still need to be written for
some errata changes coming out of 2.1 before 2.2 can be
published.
- Some people have signed up for tests and Bert suggested that the
upcoming Test The Web Forward would be a good time for more
tests to be written.
- Those that have signed up to create tests were also asked to
make a list of the tests that were invalidated due to the
published errata.
Fieldset Rendering
------------------
- The e-mail from Robert O'Callahan regarding the interoperability
problems with fieldset was discussed with the group
debating on if the solution would require a new spec, or if
it could be clarified within existing specs.
- RESOLVED: Create a new spec for form control rendering with
Rossen_ as an editor.
<ol reversed>
-------------
- The group agreed that they wanted to offer reverse lists, but as
the editor wasn't on the call, resolution was deferred until
the F2F.
====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins (IRC only)
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Bruno de Oliveira Abinader
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Peter Linss
Anton Prowse
Matt Rakow
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Steve Zilles
Regrets:
Mihai Balan
Chris Lilley
Florian Rivoal
Lea Verou
ScribeNick: dael
plinss: Let's get started.
plinss: Anything to add to the agenda?
plinss: F2F is coming quickly, please add topics to the wiki.
plinss: I'd like to make progress on transforms, transitions, and
animations.
May F2F
-------
glazou: As I said, I pinged Samsung in Korea about hosting.
glazou: I have confirmation that we can host in Seoul with help of
W3C office.
glazou: I posted a doodle for dates to the private mailing list
and not everyone has answered.
glazou: I'd like availability replies from everyone so we can pick
dates.
glazou: Right now 19-21 May is the most available.
glazou: That's a Monday-Wednesday.
plinss: Do we want to give time for people respond on to the
doodle, or should we do a resolution on dates now?
glazou: We can do more time. Korean new year is soon, so it's not
a problem if we give them a few days to decide.
glazou: If that's okay by everyone, unless someone needs a choice
now.
glenn: I'd prefer we don't overlap with BlinkOn as well, so a
different week would be good.
plinss: Okay.
glazou: I forgot to mention that immigration requires passports be
valid for, I think, 6 months after.
glazou: You'll want to check that soon to make sure you don't have
problems.
* glazou will find the exact info about that
* glazou CONFIRMED : Korean immigration requires passports to be
valid 6 months after RETURN DATE
Selectors 4 :has()
------------------
SimonSapin: So, as I explained on the mailing list I'd like to
propose adding a :has() pseudo-class
SimonSapin: I think there are equivalents in other systems where
if you express with one you can use the other one.
SimonSapin: I think this is faster and is the same for ??? and
this.
SimonSapin: The pseudo-class has utility where we can fix issues
with indicators.
SimonSapin: The ! has more issues then we have with it :has()
SimonSapin: Any comments or opinions?
bkardell: I believe it was originally has() and then morphed to !.
bkardell: I think that was lack of an ability to agree on a child
for has().
<astearns> +1 to :has over overloading !
bert: I don't think the parenthesis are good, you'd have nested
brackets in parenthesis.
bert: It makes it unreadable.
bert: I like the use of the single ! since it means emphasis.
bert: I'd like it better if you could underline the subject
selector.
* glazou and Bert agree AT LAST :-)
* BradK is not a big fan of the functional notation inside
selectors.
SimonSapin: I agree ! means emphasis, but in a boolean context it
doesn't work.
glazou: I don't think it's a problem.
glazou: I discussed with web authors a while ago and they don't
deal with boolean.
glazou: They liked the ! as a selector.
<sgalineau> I have the completely opposite experience.
bkardell: I had the opposite experience. I don't know if there's a
way to collect information, but I wish we could.
bkardell: I've run it past 50-75 people and they all think it
means not.
<sgalineau> +1 to bkardell
<TabAtkins> Speaking from a lot of jQ experience, :has() is *very*
easy to use and really easy to read.
<bkardell> +TabAtkins comment re: it exists in the most popular
library and is widely used for a long time now.
<TabAtkins> ! also has some funky issues with regards to exactly
what selector *arguments* it's allowed in.
<TabAtkins> We need to allow it in :matches(), but shadow DOM's
:host() selector doesn't make any sense.
glazou: I agree with Bert's comment about ()
glazou: It excludes the part, it is the subject at the end of the
chain instead of the beginning.
SimonSapin: () is inside nesting, but we've had that before and
its been fine.
SimonSapin: About being at the end, it's what we've always had so
far.
glazou: You didn't understand.
glazou: If you had a chain of selectors inside a big selector, i.e.
<glazou> !p.class:hover vs. p.class:hovr:has(..)
glazou: I prefer the first one.
SimonSapin: I don't see a difference
* sgalineau finds the latter easier to read.
<sgalineau> No controversy here.
glazou: When you read it it works.
glazou: I'm only giving my opinion here.
<smfr> ! looks like "not" to me.
* antonp reads ! as "not" too
bkardell: I see people find the latter one easier, that's the has()
one, correct?
<bkardell> My question was which sgalineau was indicating.
<sgalineau> bkardell, I prefer :has()
<glazou> I think we already had that exact discussion about ! long
ago and made a decision
plinss: I'm hearing people on both sides, no clear consensus.
plinss: How do we move forward?
plinss: Straw poll, public poll?
bkardell: I think public is more useful.
bkardell: The constituency needs to know who says what.
* Bert has a hard time believing that a significant number of
users of CSS associates ! with not. You must be a
programmer to be able have that funny association.
<glazou> Bert +1
<sgalineau> The ! is too ambiguous for too many people.
<TabAtkins> Bert:A lot of CSS users are at least light programmers.
<TabAtkins> But I can definitely set up a poll.
<sgalineau> Bert, I don't know a single web professional who only
writes CSS and does zero programming in some
scripting language.
glazou: Saying ! as a subject selector denotes a negation, we've
never had the problem with !important.
dbaron: We have that problem with !important all the time.
glazou: I've never heard that.
smfr: It does happen all the time.
bkardell: I've had that experience as well.
plinss: Looks like Tab was offering to set up a poll.
[Strange noise interruption]
plinss: Where were we?
plinss: I think Tab was offering to set up a poll on the selector
bit.
plinss: Let's do that, get more data, and come back.
Page Transitions
----------------
glazou: I posted a question on www-style and some of you have
contributed to that thread.
glazou: I think it's time to consider these transitions.
glazou: A few reasons this is needed. Mostly it's because some
industries want to move to web based apps and want to do
some things with those apps.
glazou: One thing users require is nice transitions, though.
glazou: Industry said they can't move to web based apps without
page transitions.
glazou: Users will react negatively without it so it's needed.
glazou: I'm not saying we have to do this now or that it's CSS,
but the discussion should be in our next charter
glazou: I'd like the WG to agree on the fact that this
conversation is in scope for next charter.
* smfr notes http://msdn.microsoft.com/en-us/library/ms532847(v=vs.85).aspx#Interpage_Transition
tantek: I agree this is in our scope and I think I can dig up a
1999 proposal for transitions.
tantek: It may be numbers based, but I'm happy to publish publicly
to further conversation.
glazou: We have things from you, Microsoft, animations, SVG, photo
effects... I'm sure we can aggregate these proposals in a
secure manner.
glazou: I think now is the right time to discuss it.
glazou: We have user requests, basically.
tantek: Seconded.
glazou: Any other opinions?
* sgalineau wonders if there is anything that wasn't proposed in
the 90s or done in DXImageTransform.
<bkardell> seems logical that it be in the charter esp. if that
doesn't commit that a CSS solution *must* come about.
bert: Just a question; is this related to the Opera proposal of
directional navigation?
glazou: No. I suggested this independently and don't know what
you're talking about.
bert: It's a simple transition, next page can be left, right etc.
glazou: It's not that. It's fading between source and destination.
glazou: It's a visual fade from one page to the next.
glazou: How do you do it? If you build a GPs app for autos, you
want things, transitions, to be really cool.
glazou: The industry won't use web-based apps if they're not cool.
SimonSapin: That's interesting, but I'd like to see proposals on
what a page is;
SimonSapin: Is it new URL, or page generated by the page-break-
after property?
glazou: That's what we need to discuss, but we can't do that
officially without it being in the charter.
* leif I'm not aware of any Opera proposal, and ftr directional
navigation is about navigating within a page, not
positioning pages visually in relation to each other
tantek: There's things we can reference like hypercard, there's
transitions between card like swipe left, right, etc.
tantek: This is more than 20 years old
<BradK> html:next { transition: flip-left; }
<dauwhe> ebook readers often use transition effects between
"pages" (used in the "paginated" sense).
glazou: Any objections, or can we add that to charter?
<BradK> +1 to page transitions
<bkardell> +1
glazou: I hear no objections.
bert: I can see lots of problems, but I'm not objecting to talking
about it.
glazou: I'd like to be able to just talk about it in the charter.
RESOLVED: Add page transitions to the charter.
plinss: Can we go another step, does anyone want to work on this?
glazou: I do
tantek: I can at least dig up my old draft, I think it was in
member space, which will make it harder to find.
tantek: But I can dig it up and I can just publish it to the
public lists.
tantek: It's not going to be modern, but it will help with
historical context
plinss: I'm sure it'll be a useful reference.
plinss: Whatever we do should tie into shader.
glazou: Since this is a charter edit, as soon as we start
discussing it we should study the security aspects.
plinss: Security will be fun.
<glazou> Security IG will help
CSS 2.2
-------
bert: Some time ago we discussed publishing an update for CSS 2.2
and we discovered we need new tests due to changes from
errata.
bert: People asked me to make a wiki and people signed up to make
tests, but some of the errata don't have sign ups.
<plinss> http://wiki.csswg.org/spec/css2.2
bert: This is a request for people to again look at the wiki page.
bert: If there's any topic you can write a test about, please do.
bert: We wanted to publish an update months ago, but we're still
waiting on tests.
* Ms2ger would help out if tests were in web-platform-tests.
bert: I have some people signed up; Arron, ChrisL, SimonSapin.
bert: If any of those people are here, do you have tests?
SimonSapin: I don't have tests yet, but I'm going to work on them.
bert: Another idea I had was some tests could be written at TTWF
bert: If people going would keep that it mind, it's a good
opportunity to write the tests of CSS 2.2
bert: Any ideas how to get more tests?
* Ms2ger doubts anybody at testtwf has the expertise to write
those tests
plinss: Typically at TTWF there's an opportunity for people to
solicit tests.
plinss: I won't be there, but will someone be there to make this
pitch?
plinss: Anyone going to TTWF?
<rhauck_> This will be the first one I'm missing, sorry :(
bert: I'm going.
dauwhe: I'm going to be there.
plinss: Can either of you help?
dauwhe: I'm new and the plan was to ask for GCPM tests, but I'll
do what I can.
plinss: My other question is there a list of tests that were
invalidated?
bert: Not that I know of.
bert: I don't think anyone has done that analysis.
bert: There was an expectation that tests have changed, but no one
found out which ones.
plinss: Can someone do that analysis?
plinss: Anyone?
bert: Maybe those that said they'd write tests can look at
existing tests in same area?
plinss: That's a reasonable proposition.
plinss: Anything else on CSS 2.2?
bert: I don't think so. We just need those tests and I think we're
ready.
SimonSapin: I think the errata for character encodings is
incomplete, so I'll try and submit those tests
plinss: Okay.
Fieldset Rendering
------------------
plinss: It looks like this is under-speced and there's lots of
variance between browsers.
plinss: So do we want to spec it, are we okay with it as is, if we
do spec where would it go?
dbaron: Seems like this issues is bigger than fieldsets, though it
may make sense to start there.
dbaron: We may be the right people to work on it, for all that
it's between HTML and CSS. I don't know.
<tantek> Is this just for legacy? I mean, do any real world web
pages actually depend on fieldset rendering?
<tantek> My understanding is that the rendering is unpredictable
enough that any actually "designed" web page doesn't
bother with fieldset rendering because it is so
ugly/unstylable.
plinss: Anyone else?
Rossen_: I think part of the point, as far as it comes to styling
it, it goes to us.
Rossen_: Overflow, border styling should certainly come to us.
Rossen_: I'm not sure if the rest should be CSS or HTML.
plinss: I think there's overall coordination, but there are
definitely styling issues.
Rossen_: I was playing with different implementations and I can
see the frustration of some implementations not honoring
overflow: auto.
Rossen_: How is the legend positioned, is it to box or to content?
Rossen_: All these style issues we can spec.
Rossen_: I can see how we can do extensions to overflow, but my
opinion is CSS should be like the rest and if it supports
scrolling, it should always do it.
Rossen_: But these are things we should discuss.
Rossen_: Are we prepared to discuss these issues now, or does it
need more mailing list time?
<BradK> Is there a shadow DOM for fieldset and label?
tantek: Is this legacy, or is this actually used?
Rossen_: My assumption is this is referring to ...you said legacy
control?
Rossen_: The reference in the e-mail is to WHATWG information, so
I'm assuming this is current
<bkardell> Seems like this could use more info/discussion on the
list if folks are unclear about legacy/unused etc.
plinss: It's part of HTML5 so people are still using it.
tantek: What I'm asking about is fieldset rendering and my
understanding is people turn of the rendering because it's
ugly.
tantek: Is this to fix that or for an actual feature?
Rossen_: My understanding is there is frustration over a lack of
interoperability.
plinss: I'm not sure we can spec legacy and I'm not sure we need
new features, but we need to spec how this behaves.
plinss: Other question is who wants to work on it, where should it
live?
Rossen_: My q is what is "this"?
plinss: I guess there's 2 approaches. Look at all bits of fieldset
and make sure they're addressed or start a new spec
plinss: I'm not sure the right approach, but there's definitely an
issue here.
plinss: Thoughts?
dbaron: I think there will need to be a new spec unless it all
goes on HTML5.
dbaron: I don't know.
* krit so much complexity in CSS :)
Rossen_: This is why I was curious if it was planning or component
since component shouldn't be us.
Rossen_: As far as the style Rob was frustrated at, I can see
border having spec for fieldset handling and also
handling for overflow
Rossen_: We can put that in CSS. The rest, I don't see how we can
do it.
Rossen_: What is the component unless we go into what HTML is
trying to do with position and size.
Rossen_: We'll either define component model or won't. If we're
doing component model, let's do it more holistically then
fieldset.
<BradK> Define its structure internally as shadow DOM, then define
a default style sheet for it once 'appearance' is turned
off.
bkardell: That would spec fieldset?
bkardell: Part of the goal would be answering it more broadly?
Fieldset would be one use case of the component?
Rossen_: Right. If you go after the component and this would be a
part of it, this would be easy. I'm not sure we're the
right WG to do it.
dbaron: I'm not sure this is component model stuff?
Rossen_: What would it be?
dbaron: Fieldset is a thing that exists and you spec what is there
and how style effects it. If people want to implement as a
component model that's fine,
dbaron: But they don't have to.
Rossen_: For one this the legend is always in a fieldset. That's
already semi-component.
dbaron: You just said it in prose.
Rossen_: What do you mean?
dbaron: What I'm talking about is spec like what you just said.
plinss: So dbaron made a proposal for a spec of form rendering. My
concern is if we do a piecemeal approach we'll still have
interop issues.
Rossen_: I'd be happy with that as a spec.
plinss: Other opinions?
Rossen_: Is this something you want to work on dbaron?
dbaron: Not especially.
plinss: If we're going to create a new spec, who will edit?
Rossen_: I can volunteer to work on it.
plinss: Anyone else?
plinss: Any objections to the new spec?
RESOLVED: Create a new spec for form control rendering with
Rossen_ as an editor.
plinss: I imaging Rossen_ wouldn't mind other people stepping up
to help.
<tantek> Aside: regarding page transitions, I think this is the
prior art I was thinking of:
https://www.w3.org/Style/Group/2003/progrend.html
<tantek> Regarding page transitions prior art in HyperCard, the
"visual effect" command, documented with various options
(e.g. dissolve, iris open, scroll left, wipe left, etc.)
http://www.jaedworks.com/hypercard/HT-Masters/visual-effects.html
<tantek> And that should complete my actions for page transitions
from this telcon. :)
<ol reversed>
-------------
plinss: Tab made some edits, but I was concerned this had behavior
that couldn't be addressed in counters or are people ok
with that?
SimonSapin: There's one part that can't be addressed, but I think
it's okay because it's only a problem inside the UN
Countries
dbaron: I think we'll want lists to function within counters.
SimonSapin: I think CSS defines that,
SimonSapin: That's why I wanted the edit.
plinss: If we can't do a reverse list we're not complete. We need
to expand the model to address that.
dbaron: Probably. We should also consider being able to set a
counter without creating a new scope.
dbaron: I think we had an agreement about making some new
additions a few years ago.
plinss: TabAtkins isn't on the call today, unfortunately.
SimonSapin: I think we have counter-set
dbaron: We do have them? Okay.
SimonSapin: Yes.
plinss: I guess my question is do we want to work on reverse-
lists? Do we want to be able to do that?
plinss: Any objections?
SimonSapin: I think what we have is fine unless we want to expose
the selection behavior without using HTML.
plinss: That's what I'm leaning toward. I'd like to be able to
explain everything in the model we have.
plinss: We don't have the people we need on the call to move
forward, but anyone have objections to that?
<glazou> not me
plinss: I'll take that as no objections. Maybe we'll discuss at
the F2F when people are together.
plinss: That's the end of the agenda and the top of the hour.
plinss: Thanks everyone and safe travels. We'll see you Monday 9am.
plinss: Bye.
[After Call IRC Conversation]
<TabAtkins> dbaron: Setting a counter without creating a new scope
was defined a year ago, in Counter Styles, with the
counter-set property.
<dbaron> TabAtkins, ok, so we did add counter-set :-)
<dbaron> TabAtkins, I didn't realize the counter styles draft had
things other than counter styles in it.
<TabAtkins> It defines counters, in general.
<TabAtkins> Which are separable from lists.
<SimonSapin> TabAtkins: isn't it in Lists rather than Counter
Styles?
<TabAtkins> Whoops, yes it is.
<TabAtkins> Forget my justification from a second ago.
<TabAtkins> The counter-manipulating properties are in Lists.
Received on Thursday, 23 January 2014 01:34:18 UTC