- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Dec 2014 10:33:22 -0500
- To: www-style@w3.org
Brief Introduction to API Taskforce
-----------------------------------
- Rossen introduced the creation of a taskforce to tackle some of
the lower level layout primitives and exposing the
programmability model of layout and styling to script.
- The group will meet in person just prior to the Sydney F2F in
February to finalize details of the charter, meeting schedule,
and exact scope of what the taskforce will try to achieve.
- Anyone interested in this work is invited to join the mailing
list and follow on the wiki (available here: wiki.extf.org)
Transitions
-----------
- Everyone in the group was actioned to review the edits dbaron
made on the spec and give feedback.
:lang() issues
--------------
- RESOLVED: Keep allowing *-identifier when it's not digits and
recommend a string when it is.
- RESOLVED: Allow strings as argument to :lang()
Fixed layout
------------
- Everyone agreed that an errata should be created to better
explain how space is distributed among columns. dbaron will
write up Gecko's behavior for the mailing list and SimonSapin
will use that to create some tests and find interoperability
for the errata explanation.
- This discussion transitioned to the difficulties in republishing
a document in REC and the lack of tests for the CSS2.1 errata.
There was a desire to make sure that changes like this are
clear to those looking at the spec.
- RESOLVED: Add a new link at the top of CSS2.1 linking to the
Editor's Draft
CSS3 UI
-------
- RESOLVED: To the extent that the outline follows the border
edge, it should follow the border-radius curve (issue 56)
- RESOLVED: Implementors may directly manipulate width and height
elements on the style attr being changed and change "resize
factor" to "resize function" to address fantasai's concern
(issues 47 and 53)
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
David Baron
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Chris Lilley
Peter Linss
Mike Miller
Edward O'Connor
Anton Prowse
Liam Quin
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Bert Bos
Simon Pieters
Lea Verou
Scribe: dael
glazou: Let's get started
glazou: I saw that Bo posted an extra item on the ML. Any other
extras?
sylvaing: I have issues on Animations and the behavior of the key
argument.
glazou: The delete and insertion rules?
sylvaing: Yep.
<dbaron> glazou, I'd like to briefly point out an email I sent
about transitions
<glazou> dbaron: ok ; do that after the current item ?
Brief intro for API taskforce
------------------------------
Rossen: I can do my best. Is TabAtkins on the phone?
glazou: He's not, apparently.
Rossen: Okay. I don't even know what to call it anymore. There's a
taskforce which was formed just a few days ago and it's
something we've been talking about and trying to get up
and running.
Rossen: The idea and purpose is to tackle some of the lower level
layout primitives and exposing the programmability model
of layout and styling to script.
<glazou> the TF’s mailing-list is public-wtf@w3.org
Rossen: Why did we form a TF? If you read one of TabAtkins's e-
mail in response to the original thread, he had a really
good summary. Basically half the people in the WG are
interested in layout and half are not. We want to have a
focused group that deals with that alone and nothing else,
similar to the FXTF and how the deal with effects.
Rossen: The group as it stands is most represented with impl. We
have people from Mozilla, Google, Microsoft, Adobe, and I
believe we may have people from Apple join. We're trying
to set up a first meeting in Sydney.
<glazou> and even DISRUPTIVE INNOVATIONS !
Rossen: Oh, and HP and Disruptive Innovations.
<glazou> :)
<Florian> invited experts as well
<bkardell> I have joined - jQuery
* bradk can't read "WHATTF" as anything other than "WTF?"
<glazou> bradk: That’s why smfr suggested to change it
<astearns> is there anyone from TAG besides Peter who are
interested?
<bkardell> tag is interested, they wanted it set up
Rossen: So we'll try and set up a meeting right before the Sydney
F2F on Sat and Sun, I believe that's 7 and 8 Feb.
Rossen: shans will arrange and host the meeting, I'm assuming in a
similar or same location.
Rossen: That's pretty much what we have for now. We're hoping
during the initial meeting we'll clarify the charter of
the group, so don't hold me to what exactly we'll do.
We'll set up the charter at the F2F. Prior to that we're
hoping the bikeshedding of the taskforce name will be done
with.
Rossen: The wtf name I don't think was ever meant to stick for a
long time.
Rossen: It turned a bunch of heads. I got a bunch of emails about
people who were passionate about being serious. I am too,
so don't hate me for it.
<ChrisL> just let me know what the eventual name will be, and i
will create the new list
<Rossen> wiki.wctf.org
Rossen: We'd love to have people join the list. It is public.
plinss and I set up mercurial and extf and if it sticks
that's what we'll use to solidify proposals and start
creating spec.
<Rossen> wiki.extf.org
Rossen: And the wiki is this (above) and up and everyone in CSS
should be cleared for access and to contribute.
Rossen: That's the overall intro. Any questions or name proposals?
<dauwhe> Could shans forward the original meeting notes from Santa
Clara to the new list?
glazou: dauwhe has a good question on IRC. shans should forward
the meeting notes from the end of TPAC to the list.
Rossen: Yes, once the wiki is up and running, there are some
initial documents we'll use to introduce people to what
we're doing and the problem space as well as meeting notes.
At Sydney we'll figure out the telecon schedule and so
forth. The initial meeting will be administrative and
chartering details.
ChrisL: I would suggest waiting to forward the notes until the
mailing list exits. As soon as you have a name you've
settled on let me know.
Rossen: I will and thank you ChrisL for being so patient with this.
glazou: Okay. Any questions?
glazou: Thank you Rossen.
Rossen: I hope to see as many of you as possible in Sydney.
Transitions
-----------
<dbaron> http://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html
dbaron: I wanted to point out I sent an e-mail to www-style
yesterday about edits to Transitions spec. I'd appreciate
review of the edits and the spec in general because
hopefully we can take this to the new process, maybe in
January.
glazou: Let's do an action to the group. How much time is needed?
dbaron: I don't know if it's on everyone. Some of these are
technical.
Rossen: Is this the write-up that you did...in a couple of F2F you
mentioned that the position model is broken and you would
rewrite. Is this it?
dbaron: No. That was in the last WD. This fixes one of the things
that was missing from that. The edits I did then didn't
explain how transitions get canceled.
Rossen: Maybe now is a good time for an overall review of the
whole model.
smfr: Are there any tests that describe the behavior?
dbaron: I don't think so. That would be useful as well.
ACTION: everyone to review the document and give feedback
:lang() issues
--------------
glazou: smfr will you be discussing this?
smfr: I don't have the background, sorry.
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0046.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0130.html
glazou: Let's take the first one. That's about parsing the
argument of :lang(). In Selectors 4 when there's a * to do
matching.
glazou: The second message is similar but about how we tokenize
the value of :lang(). So when we want to make *-number we
can't because -number isn't a token.
ChrisL: I think TabAtkins sent a message recently about making
that a string is the best way forward. When we originally
spec'ed it, it was an easy thing. We can't tell what the
future will be so we need to make it a string.
fantasai: We can't make it a string. We can allow it in addition
to tokens.
ChrisL: Yeah, sure.
fantasai: One of the things Webkit folks were asking is why not
allow escaped asterisks.
glazou: This is ugly.
fantasai: There's no reason to disallow, so why not allow? We
might also want to allow strings as a less ugly option.
The only time you need a * is in the front since in the
middle is like not putting it there. The front is only a
problem when the subtag is a number.
fantasai: The only time it's an actual problem is when you're
doing *-number. You can solve that with a string or
escaping the *.
glazou: I prefer the string.
fantasai: I imagine the corner case is rare.
glazou: But as ChrisL said we don't control this. This comes from
another committee and we don't know what they'll do in the
future. We should assume it's possible to happen in the
future. It's not a complete edge case.
* tantek dislikes escaping path.
glazou: I'm really in favor of allowing a string and now going
down the escaping path. What do others thinks?
fantasai: If we allow string, we should allow both.
glazou: Absolutely, but then we can say if you have * somewhere it
has to be a string. This is new in Selectors 4.
<TabAtkins> Whoops, forgot about the call. I agree with glazou,
btw.
<ChrisL> +1 to fantasai allowing * at start
fantasai: I think I would prefer for allowing the * in the
beginning unquoted. That makes a minimal change for
targeting a subtag, but allow a free range at the
beginning. I don't mind having a string required for
other situations. I want the common place to be as easy
as it was previously.
<bkardell> I think a string makes sense, it's still pretty easy,
right?
<bkardell> +1
<TabAtkins> Better to make it a consistent "string if you use *"
than an inconsistent "just type it, but if it doesn't
work [due to arcane parsing things] then use a string"
fantasai: For usability I'd like to allow the star. I'm fine with
allowing the string for future weirdness and an
alternative to escaping.
<TabAtkins> fantasai: One of Ben's emails was precisely about a
problem with an initial *.
SimonSapin: An escaped is star is already a valid ident in :lang
pseudo-class. We shouldn't dis-allow it. Escaping
works.
florian: That makes sense to me. Escaping is allowed.
glazou: Do we agree on the strategy here?
florian: I do.
glazou: fantasai?
fantasai: Yes? I think TabAtkins isn't sure.
<TabAtkins> calling in now, one sec
glazou: [reads TabAtkins comments]
glazou: One of Ben's e-mails is about the problem with the initial
star.
<TabAtkins> The two problems Ben brought up:
<TabAtkins> 1. *-1996 is a valid code via the RFC, but invalid per
CSS parsing.
<TabAtkins> 2. foo-*-bar is valid in the RFC.
fantasai: I think that's weird and arcane and pretty much no one
will run into it.
glazou: When the problem is plausible it always happens.
glazou: So, let's keep allowing *-identifier when it's not digits
and recommend a string when it is.
RESOLVED: Keep allowing *-identifier when it's not digits and
recommend a string when it is.
RESOLVED: Allow strings as argument to :lang()
fantasai: I'll make the edits.
<TabAtkins> fantasai: I recommend making the edits so that string
is recommended, but then laying out cases when you can
omit the quotes. Better than trying to say "you don't
need quotes, but if you find that it doesn't work, use
quotes".
<fantasai> TabAtkins, yes, makes sense. Well, I would recommend
unquoted for anything that's not involving *, because
that is backwards-compatible and strings are not.
<fantasai> TabAtkins, but for cases with * I agree.
<TabAtkins> fantasai: Yeah, sure.
<ChrisL> action: chris to extend the zakim bridge allocation
<trackbot> Created ACTION-663
Fixed layout
------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Nov/0580.html
SimonSapin: The part of fixed layout that is spec'ed in CSS2.1 has
one of the sentence. When all columns have the
specified width and the table has a specified width,
if the table is larger, the extra space should be
distributed between the columns. The spec doesn't say
how, but it turns out webcompat depends on it being
proportional to the width of the columns.
SimonSapin: It seems like the spec needs to say this so we should
add an errata.
Florian: There was an extra comment on the mailing list about
needing exceptions.
dbaron: And you have to consider if it has percentage width as
well. What Gecko does is it distributes extra space...if
there's a non-0 width in column with a specified length,
it distributes among them with nothing to the column that
have percentage. Otherwise it distributes to those with
percentage width.
Florian: Do we have interop on when there's col-span somewhere?
dbaron: I don't think it interacts, well, maybe you are looking at
cell width. I'm not sure if this is looking at cell widths
or only...fixed only looks at the first row. It may skip
those with col-span.
SimonSapin: It does distribute to those with col-span.
glazou: So do we have an answer to the question?
SimonSapin: We need to change something. It's unclear as to what
the exact behavior should be. dbaron can you write on
the mailing list what the Gecko behavior is?
Florian: And we want to make sure other browsers do the same?
SimonSapin: I can try to do that.
glazou: plh are you on the call?
plh: I am.
glazou: You want to mention something about CSS2 errata?
plh: It would be nice to leave the spec as it is online. I brought
this to the group and we were lacking tests. I'm not saying
we should stop everything, but it would be great to update
the TR version of CSS 2.
glazou: Comments?
glazou: SimonSapin will you create an errata based on the changes
you want from your tests?
SimonSapin: I'll do more tests to find interop and then propose an
errata.
fantasai: While you do that, can you submit a test?
SimonSapin: I can do that.
tantek: What is the status of the lighter-weight TR process?
fantasai: The process for updating REC is worse in the new version
of the process.
plh: There has been discussion on the process list. There is a
high bar to update REC and there's been a discussion about
lowering that bar.
<ChrisL> we published a CR under new process recently. actually it
was the first one
tantek: I thought it was further than that. Allowing a group to
update a TR page without the heavy lifting.
fantasai: That's not about what W3C process we're on. For 2.1
we're stuck on process issues. We can't publish
substantiative changes unless they pass CR and we have a
bunch of items without tests or implementation reports.
So for passing the current version of 2.1 we need all
the reports to publish, or re-publish.
tantek: That's a long list of dependencies. I understand the need
to not update the TR CSS2.1 immediately, but this long
list of dependencies seems like a bad problem. Can we
publish as an ED?
fantasai: It is.
tantek: Can we slap a warning on the top of CSS2.1? Why not do
that?
plh: Because no one has asked. I don't think that we've done it
before...
fantasai: We have. We put something at the top of CSS2 saying look
at 2.1
tantek: So I'm saying put something at the top of 2.1 that links
to the ED.
fantasai: I'm in favor.
glazou: I am if we say there's extra ongoing work.
tantek: Saying we have substantial changes in process.
liam: The usual is to put it in errata rather than link to an
unstable doc.
tantek: I object to hiding it the the errata.
glazou: We should put it in the real document.
tantek: This is a warning at the top.
glazou: So we have a proposal to put a new link at the top of
CSS2.1. Support?
<Florian> +1
<SimonSapin> +1
<tantek> +1
<dbaron> in favor
<astearns> +1
<antonp> +1
<gregwhitworth> +1
<fantasai> +1
<smfr> +1
<dauwhe> +1
fantasai: I'm in favor. Someone mentioned a link to both the
errata and the ED and that's good.
<SimonSapin> we already have an errata and a link to it
<tantek> we already have a link to the errata - no need to
duplicate that
glazou: Any objections?
<liam> -1 but not objecting
<KeshavP> +1
<tantek> this is ONLY for linking to the editor's draft
<SteveZ> +1
<ChrisL> so this is an in-place edit on CSS 2.1 Rec?
* fantasai is pretty sure nobody can see the errata link unless
they know it's there, so thinks having it in the
warning is probably a good thing
<ChrisL> errata must already be there for a rec
tantek: We have a link to the errata, so I don't think we should
confuse it.
glazou: Yeah, fine.
RESOLVED: Add a new link at the top of CSS2.1 linking to the
Editor's Draft
<tantek> "There are substantial changes in progress"
* plh wonders who got the action to update CSS2.1
<glazou> plh: good question BTW
<SimonSapin> plh, nobody yet, I think
<glazou> am stram gram :-)
* plh nominates Chris or Bert to do the update :)
<tantek> glazou - who put the warning at the top of 2.0?
<glazou> tantek: ChrisL or Bert?
<glazou> oh wait you said 2.0
<glazou> no idea
<tantek> glazou any volunteers to update 2.1 with the warning?
<glazou> hey that was EONS ago
<glazou> tantek: plh and I recommend ChrisL or Bert
<SimonSapin> Can we make the warning fixedpos, like
http://dev.w3.org/csswg/css-box/ ?
CSS3 UI
-------
glazou: You have 20 minutes. Choose well.
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Dec/0145.html
Florian: Let's start with this.
Florian: We have a resolution about rounded outline. We had a
short discussion that raised issues, didn't answer them,
and then concluded that if you have a rounded border, the
outline should be rounded as well. I agree this is what
you'd normally want, but due to the vague definition, I'm
not sure what it means.
Florian: We have interop on not doing that. Every browser keeps
square corners. I'm not sure if there's a webcompat issue
with switching.
Florian: Options are 1) do nothing 2) do the same explicitly
saying you may, but not how 3) we do it with a must,
probably don't say how, and test the obvious case.
Florian: I would prefer an explicit may to allow experimentation
and spec it completely in level 4. I have ideas on how
we'd attempt a full spec, but it's not a one-liner
fantasai: The definition wouldn't be that difficult. To the extent
that the outline follows the border edge, it must follow
the rounding.
Florian: Not always. If the children overflow, some browsers
include the overflowing bit in the outline. Also, the
spec doesn't say if you transform the outline when you
transform the elements.
fantasai: You can say to the extent that you follow the border
edge. So when it does, you follow the curve. Where it
doesn't follow the border edge it's left undefined.
Florian: That sounds like something we can spec. If we spec as a
'must', no one passes.
Rossen: I think we can easily push it to level 4. I don't see us
rushing to implement this given everything else on the
table.
Rossen: On the priority level, this will be low for us. I'd be
surprised if others rush to impl rounded corners. I'd be
okay with this going to level 4.
tantek: This feature started from the really good outline and
focus of WebTV. It did round the corners and provide a
nice rounded implementation. We knew this was non-trivial
to implement which is why it's loose in the spec. I don't
expect every implementor can do that, we need to allow a
broad range of fidelity. I'm okay with adding some more
'may' to the existing spec with known best practices but
it's premature to agree one spec'ing this on any future
level.
* Rossen agrees with tantek
<fantasai> tantek +1
tantek: I find it disturbing that the rounded-ness disappears at
times, but I don't know how to say it's broken without
breaking other implementations. I'm okay with 'may'
statements, but not saying how to do it.
Florian: So we have fantasai's proposed sentence with a 'may' in
it for level 3.
tantek: fantasai can you put your sentence in IRC?
Florian: That the extent that the outline follows the border, the
outline should be rounded just like the border, I think.
<fantasai> "To the extent that the outline follows the border
edge, it should follow the border-radius curve."
Florian: I don't know about if we should use 'should' vs 'may',
but not 'must'.
tantek: So 'should' vs 'may' is are we sure that it's desirable
behavior.
fantasai: We're sure it's desirable, but not sure about webcompat.
tantek: If we're sure, we should use 'should'.
Florian: That's why we resolved before on 'must', but that's a bit
impossible.
RESOLVED: To the extent that the outline follows the border edge,
it should follow the border-radius curve
<tantek> Florian said he would edit the CSS3-UI issue
<astearns> tantek: issue 56?
<Florian> tantek: rounded outlines was
https://wiki.csswg.org/spec/css3-ui#issue-56
<tantek> thanks Florian
glazou: 10 more minutes
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Dec/0063.html
Florian: Next one, resize. It is spec'ed in terms of a resize
factor. They do it by updating a style attr and they're
interoperable. Regardless of if the spec behavior is
good, we should drop it in terms of what's implemented.
fantasai: I'm not sure if what's in the spec is ideal, but I'm not
sure on what's impl either. So if you resize a form
element to make it bigger and it was, say, fill to
viewport, and then you resize your window to make it
significantly narrower or wider, the form element will
no longer attempts to fit in your new layout.
fantasai: In which case the UA may want to do something smart. I
don't know what's right, though I think what's in the
spec shouldn't be what's there. It should be close to
what's impl or more similar.
Rossen: So if the resize-able element is relative to a containing
block and the containing block is resized, do you resize
the element again. You can decide which is the desirable
behavior and you can re-spec by saying either it remains
fixed or resizes on the next containing block resize.
glazou: We see that when you resize a table in an editor. When
nothing is fixed length, you resize a field and then a
container, you have that problem.
Rossen: I think that half the time you want to resize and half the
time you don't. Perhaps we're missing an additional
behavior which will further define what happens during
resize. It'll be up the the author to set the expected
behavior for if it will be resize as fixed or relative.
fantasai: That makes sense. We should explore that in the next
level. For this level we may have the spec what's there
and say the UA may reset the size when it feel like it.
glazou: I can agree to that.
tantek: That's a lot wording to restate what we have. The current
language was chosen to cover all these variants.
tantek: That was the most expedient way to implement and it's not
a coincidence that they arrived there.
Florian: I'm not sure they're equivalent.
tantek: I said covered by. The language is very deliberate to
cover the existing behavior and something in the future
where the UA does something more intelligent in the future
depending on how the item was laid out etc. I don't think
the impl know what's optimal.
tantek: Right now we don't have widespread use of Flexbox, but I
think we will in the future and detailed language will
make an obstacle in the future.
dbaron: So, I don't think what implementations are doing is
conformant to what the spec says.
fantasai: I agree. Interacting with the cascade is not an internal
detail.
dbaron: The spec is clear that it's after width, so these are
different.
tantek: I would be okay with expanding what the spec allows to
explicitly allow the style attr manipulation.
Florian: So I'd like to ask if the impl are ever willing to change.
If they're not, we shouldn't spend time discussing the
change. But if they're willing to change we can spend
time deciding where this should be in the future. I don't
have an opinion on which is better, I just want spec and
impl to match.
dbaron: I think there's a difference between willing to change and
willing to put in the energy to make the change happen.
What's in the spec is more work, probably substantially.
tantek: That's why I'm saying the spec language should be
broadened to allow what impl are doing now and allows
better approaches in the future.
Florian: I'm not sure how you do that given the infraction to the
cascade.
tantek: We add a sentence saying something like impl may directly
manipulate width and hight elements on the style attr
being changed.
tantek: That's my proposal.
glazou: Florian what do you think?
Florian: I'm willing to go with tantek. If impl are willing to go
with what is in the spec, why not, but if impl won't
change there's no point in specing something they won't
use. I don't see much willingness to impl the other one.
fantasai: I think someone that isn't on the core impl team will
find a need for a better approach and will put pressure
for the changes. If we think it's a better route we
should leave it open. If we think we'd like to go there
if we have the resources, we should leave it in the spec.
fantasai: The current language talks about a resize factor and
that's multiplicative. Right now it's a fixed size. I
think we might want to change it to information.
fantasai: Might want to be additive rather than multiplicative.
tantek: How about a resize transform?
fantasai: Sure.
tantek: That reasoning makes sense. That allows implementors to do
anything.
Florian: I'm not sure about the word transform because people
might think it's the transform property.
glazou: We have to wrap up.
<tantek> proposal: change "resize factor" to "resize transform"
to address fantasai's concern
Florian: If we allow the current in the spec, I'm good with that.
I'm not sure it's obvious that the rest is useful, but
sure.
fantasai: An alternative to tantek's language is to say
information which is more vague.
tantek: Or function.
<fantasai> I like function
<fantasai> let's use function
Florian: So we won't have tests for this?
tantek: Nothing more than we have now.
<fantasai> f(x) = x + 20px
<fantasai> f(x) = 278px
<fantasai> f(x) = x * 1.5
Florian: I'm not sure how you test if we can say this way or that
way with one way not defined.
<tantek> proposal: change "resize factor" to "resize function" to
address fantasai's concern
glazou: So can we continue offline or resolve?
tantek: I want a resolution on what I typed.
<tantek> both proposals
Florian: Was it your line plus the earlier? As long as you can do
it with a style attr, I'm good.
RESOLVED: Implementors may directly manipulate width and height
elements on the style attr being changed and change
"resize factor" to "resize function" to address
fantasai's concern
glazou: alright, bye!
<tantek> that was for CSS3-UI issues 47 and 53
Received on Thursday, 11 December 2014 15:33:51 UTC