- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 2 Apr 2014 20:03:38 -0400
- To: www-style@w3.org
Publications requests
---------------------
- RESOLVED: FPWD for will-change.
- RESOLVED: FPWD for CSS-scoping with the short name Scoping.
Follow up on Namespace
----------------------
- RESOLVED: Modification of the validity of an unknown prefix in
selectors and insertion of namespace rules.
Follow up on subgrid
-------------------
- Fantasai expressed that she still believes moving subgrid to
level 2 of grid would create accessibility issues that would
be hard to rectify even after level 2 is released. TabAtkins
stated that he still believes that the inclusion of subgrid
in level 1 will cause too much of a delay to implement
before shipping.
- The discussion will continue on the mailing list with sylvaing
recommending a focus on use-cases instead of general
speculation on what adopters may or may not do.
Animations
----------
- RESOLVED: Use percentage values for key arguments and map
from/to keywords to 0% and 100% respectively.
- RESOLVED: Keytext on setting invalid value should throw an error.
- The various other questions concerning keyframes all revolved
around reaching consensus on how browsers implement the spec.
Sylvaing will solicit feedback from the browsers to
ascertain the best path to compatibility and then move to
solve the other issues.
<custom-ident>
--------------
- It was agreed that global keywords should be excluded as <custom-
ident> values, but there still isn't a clear path on how to
decide what other keywords should be excluded. Discussion
will continue on the mailing list.
q unit
------
- RESOLVED: Add q unit to Values and Units.
====FULL MINUTES BELOW======
Present:
Glenn Adams
David Baron
Bert Bos
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brad Kemper
Philippe Le Hégaret
Peter Linss
Anton Prowse
Matt Rakow
Simon Sapin
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Edward O'Connor
Simon Pieters
Florian Rivoal
Dirk Schulze,
Alan Stearns
Lea Verou
scribenick: dael
glazou: Let's start
glazou: First thing, any extra items?
SimonSapin: I'd like to talk about <custom-ident>
glazou: Anything else?
Publications requests
---------------------
<glazou> http://tabatkins.github.io/specs/css-will-change/
glazou: First is will-change
TabAtkins: We talked about this at the last F2F. It hasn't been
published, it's just on my github.
TabAtkins: I'd like to publish it officially as a FPWD if possible.
Glazou: Did you say ED or FPWD?
TabAtkins: I'd prefer FP, but if I can't get that ED is fine, but
I'd like to just publish if possible.
glazou: What do people think?
* fantasai defers to dbaron ;)
Bert: I still think it's strange and wonder if there's better
approaches, but no objection. It might help solve my issues.
glazou: I still think it's weird, but I'm okay to publish. I'd
like to have this in the charter and reviewed, plh an
update?
plh: We're reordering the list in the charter, but we can add this.
glazou: Other opinions?
glazou: Microsoft, what do you think?
glazou: Ah, dbaron joined. We're discussing will-change from
TabAtkins.
dbaron: I'm in favor.
glazou: Other browser vendors?
gregwhitworth: I'm not too keen, but go ahead and publish. Will-
change just tells the broswer what's coming, right?
TabAtkins: Yes, it tells the browser a layer will change.
gregwhitworth: Go ahead and publish and we can hash it out later.
sylvaing: I think it's weird, but go ahead. People are doing
things to activate the GPU and this is better than that.
glazou: It seems we agree on FPWD, yes?
SimonSapin: Just a question, what does it require?
SimonSapin: Isn't it a hint, rather than dictating anything?
TabAtkins: It'll sometimes create stacking, but any other action
is UI's discretion and purely a hint.
<sylvaing> It seems odd right now but is really no weirder than
setting translateZ to force elements into their own
layer on some browsers.
<gregwhitworth> yeah
glazou: Any objection?
RESOLVED: FPWD for will-change
action plh to add will-change to charter
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-623 - Add will-change to charter [on
Philippe Le Hégaret - due 2014-04-09].
glazou: Next is scoping
TabAtkins: Same deal, krit requested an extra week before FPWD so
we can get extra comments, we haven't had any.
fantasai: Is plh on the call?
fantasai: plh can you approve css-scoping shortname?
glazou: plh? He's probably away.
plh: Yes. yes I can.
fantasai: The goal is to publish tomorrow so I have to submit
right away.
glazou: We have nothing from krit and we left a week.
RESOLVED: FPWD for CSS-scoping with the short name Scoping
Follow up on Namespace
----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0502.html
glazou: The thread www-style ended up discussing behavior of OM
when we insert in a style sheet.
glazou: I understand the comments about reparsing the whole thing.
I would have considered that a mistake 10 years ago, but
didn't detect it.
glazou: I still think we can make an errata to allow name
insertion because it'll be rare and won't impact rendering
engine or webpages.
glazou: I'd like to hear from other vendors and see if we can
start an errata.
TabAtkins: I agree. We can change to not throw away and changing
namespace just makes it not normal.
glazou: Others?
SimonSapin: I think this is fine because we have selector fixed in
OM anyway so probably need to start as text and that's
easy to reparse.
glazou: I'm not sure. Selector text is stored only in case of a
rule you reserved and you're not reserving a rule if
prefix is unknown.
dbaron: So you're saying if prefix is unknown, rule stays.
glazou: Rule stays but selects nothing.
TabAtkins: That single type selector selects nothing, not the
whole thing.
TabAtkins: So you could use it in a not expression and it would
become null?
SimonSapin: Are you proposing rules with invalid selectors show up
in the OM?
glazou: Change the validity rule of selectors with unknown prefix.
They're currently invalid, I say valid and selecting
nothing.
SimonSapin: Okay.
TabAtkins: So will the whole selector match nothing, or just that
simple type selector?
glazou: The case where one thing invalidates a whole group is for
validity.
TabAtkins: What I mean is this :not(unknown|foo)
TabAtkins: That should match nothing, but does that mean the whole
selector matching nothing, or the type selector matches
nothing?
glazou: It should be consistent. So :not should select everything.
TabAtkins: That's fine, I just wanted to be clear
??: We just wanted it to be matches nothing at all.
glazou: It seems there's agreement on what we want if we want
something.
glazou: Is there consensus about writing an errata, which I can do?
glazou: Any objection?
<sylvaing> no objection
glazou: Then I will do it and we'll change the behavior of unknown
prefixes.
TabAtkins: I can make the edits to selectors and name space if
needed.
TabAtkins: Well, where ever it is.
SimonSapin: I think it goes into selectors.
glazou: Not only that.
SimonSapin: Namespace should be invalid for other specs.
SimonSapin: Namespace spec says...
<SimonSapin> CSS qualified names can be used in (for example)
selectors and property values as described in other
modules. Those modules must define handling of
namespace prefixes that have not been properly
declared. Such handling should treat undeclared
namespace prefixes as a parsing error that will cause
the selector or declaration (etc.) to be considered
invalid and, in CSS, ignored.
SimonSapin: This bit talks about other specs and it has a should
for the specs.
glazou: This is a hole in all the specs and everything derives
from a 14 year old spec. We'll have to modify in multiple
locations.
SimonSapin: Okay with updating both.
RESOLVED: Modification of the validity of an unknown prefix in
selectors and insertion of namespace rules
SimonSapin: You say insertion?
glazou: They're currently throwing an exception if there's
anything beyond insertion point?
SimonSapin: So they're only allowed to insert where valid?
glazou: Yes yes.
glazou: We're not saying they're allowed anywhere
* sylvaing wonders if there are other cases where we'd want
selectors to stay valid and match nothing rather than
dropping an entire rule
Follow up on subgrid
-------------------
glazou: Anything to say?
TabAtkins: Is fantasai there?
fantasai: Yes.
glazou: And is she willing to discuss?
fantasai: I maintain position as started before.
glazou: So that was short.
TabAtkins: We brought it up so we can resolve one way or another.
Subgrid into level 1 or move to level 2
fantasai: I'll object if we punt.
SimonSapin: Does it make sense to mark as at-risk?
fantasai: I'm not sure. It's accessibility, not something just
nice to have.
sylvaing: What do you mean accessibility?
fantasai: Let's say you have a form with grid layout and in order
to use it you remove structural elements to make a list,
you've removed the structural stuff and now people can't
understand without the grid.
fantasai: That structure is gone and you had to remove it to use
grid.
sylvaing: You don't need to do it for flex?
fantasai: No. You may need extra spans and divs, but that's adding
extra not removing.
sylvaing: Yes, but that you need to alter your markup doesn't mean
it doesn't have value.
fantasai: If we ship as-is people will strip their markup because
they want grid, not caring about it working for non-
visual consumers.
sylvaing: So you establish grid isn't super-cool, there's still
value.
fantasai: Even where you have something like a front-page, you'll
still have problems. I have examples listed and they're
common cases.
<gregwhitworth> Can you link to the examples?
<gregwhitworth> Of the accessibility problems?
fantasai: This will be worse than what we have today.
fantasai: Today with the layout hacks it's bad, but they don't
strip things.
sylvaing: I'm not sure stripping stuff is the only way.
sylvaing: I've seem things added.
TabAtkins: Point remains it's still complex and if we want to
implement before shipping, it'll slow the feature.
fantasai: But if you don't you'll have a whole class of webauthors
learn without subgrid and they'll just keep doing it.
TabAtkins: People will learn as time goes on and subgrid is easier
so when it's there it'll be used.
glazou: You guys are disagreeing and I don't think we'll solve it
in the next 25 min.
glazou: I suggest we go to e-mail and we move-on.
sylvaing: I think we should stay on use-cases and the before and
after. We shouldn't speculate on what people will do.
Early adopters will adapt.
sylvaing: If we fear people won't pick up a level 2 thing, we fear
the benefits won't be obvious. Let's not speculate,
let's look at use cases.
glazou: Topics still left we have something from sylvaing on
animations and one from SimonSapin. Let's do animations.
Animations
----------
sylvaing: Let me pull them.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25107
sylvaing: This should be the easier one.
sylvaing: So this one is about the format of the string argument
for findRule() and deleteRule()
sylvaing: The spec said it's a number between 0 and 1, but that's
only implemented in IE.
sylvaing: Everyone else never did that. Gecko, webkit, and blink
use percentage.
sylvaing: That's consistent with how you write it and how it's in
the OM so it's more usable.
sylvaing: So I think we should change to Gecko approach. I think
IE can keep it, but everyone should support percentages.
glazou: What about keywords from and to?
sylvaing: They work. I think they match their corresponding values
everywhere.
glazou: I support the change.
dbaron: In Gecko we use the same parsing that we do when they
appears on the style sheet.
sylvaing: So any concern from Microsoft?
MaRakow: Sounds reasonable.
sylvaing: Anyone using IE needs to patch in the numbers, so as
long as you guys support both it'll work.
sylvaing: I think you want to keep the old one and add support.
RESOLVED: Use percentage values for key arguments and map from/to
keywords to 0% and 100% respectively.
sylvaing: That's one.
sylvaing: Next one.
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2014Mar/0497.html
sylvaing: This was also one of glazou's issues. Clarifies keyframe
rules when they get keys.
sylvaing: Spec says if multiple keyframe rules have same keyvalue
the last one is accepted.
sylvaing: In the e-mail what we expect from the prose and the
browsers is what the text says.
sylvaing: Gecko is doing interesting cascading in the rule. It's
doing on a property basis.
dbaron: I feel what Gecko is doing is correct. We discussed this a
few years ago and maybe had a resolution.
sylvaing: I tried to look, but don't remember. Can you elaborate?
dbaron: It's hard for me to switch this into my head.
TabAtkins: One example as to why it's better, if you're doing
several loosely related animations and want to do all
width at one point and all background at a different
and they land on same keyframe, it's nice to keep
separation.
sylvaing: If you want to change the width on the keyframe and you
don't lose the rest, though.
glazou: I understand the usecase, but we have problem with object
model.
glazou: When you find something from keyframe, you get one rule
only.
sylvaing: That's another issue. Some of your questions, you cannot
expect the OM to give you everything. When you look at
browser you get a bunch of text you edit.
sylvaing: We can talk about that with findRule() question.
glazou: I mentioned it since whatever you pick there is an OM
change.
sylvaing: Maybe, but there might be other reasons to change.
sylvaing: So only Gecko does cascade thing right now. Sounds good
to me, but it's a significant change and I'd like to
hear from other vendors.
TabAtkins: I can ask around about compatibility. I'm fine.
glazou: Anyone from Apple on call? I'd like to hear from them.
sylvaing: IE too.
MaRakow: For the OM question, I'd like to think about that more.
sylvaing: I'm less concerned about OM since there's so much compat
issues. It's more that we're changing the concept so
something may break. But there's a lot of breakage so we
could talk to Firefox.
glazou: Okay, so do you want an action to investigate?
action sylvaing investigate the opinions of other browsers
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-624 - Investigate the opinions of other
browsers [on Sylvain Galineau - due 2014-04-09].
sylvaing: I have one question for webkit and blink engines:
everyone agrees about appendRule, but they still have
insertRule for legacy reasons.
sylvaing: If they can fix it, that's awesome.
TabAtkins: I'll ask about compat.
sylvaing: You could add append to the old one.
TabAtkins: We can add. There's nothing wrong with that.
sylvaing: It's more supporting both.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
sylvaing: Next one.
sylvaing: keytext property again. It's handling values in the spec.
sylvaing: It's also not compat. You have keytext for the rule and
when you put something invalid Gecko doesn't do anything,
sylvaing: Blink and IE throw and do not update,
sylvaing: Webkit just applies it.
* TabAtkins Le sigh. I have no idea how the spec ended up so
different from the WK/Blink impl, when they were the
first impl and wrote the spec.
sylvaing: So we have three possibilities and they're all out there.
sylvaing: Honestly, I don't have a strong opinion. Webkit seems
silly, but I understand it.
glazou: I ended up doing the same test and from editor view I'd
prefer throwing.
dbaron: So this interacts with two issues back?
glazou: Yes, you can set invalid and something existing.
dbaron: So sylvaing's e-mail is about the invalid?
sylvaing: Let's keep the issues separate. So bogus values first.
sylvaing: What do we do if you put foobar as a keytext value?
sylvaing: I'm okay with anything, but Gecko doing nothing seems
the worst since you don't know what happens.
dbaron: I didn't throw since the spec didn't say it, but it's a
one line change.
TabAtkins: Related, but should I make counterstyle rules throw?
glazou: For consistency, yes.
glazou: So does anyone object to throwing an error when keytext is
invalid?
sylvaing: That's the most common
<dbaron> throwing sounds fine as long as you say what exception to
throw :-)
* TabAtkins SyntaxError, certainly?
RESOLVED: Keytext on setting invalid value should throw an error
sylvaing: Okay, now you set a keytext to a valid value that
already exists in rule.
sylvaing: What I've seen in browsers is that the rule is updated
in place.
sylvaing: Order is what's specified and not effected.
sylvaing: I guess I want to know what we would do...It's easier if
you're not on Gecko model and you're not cascading.
glazou: I think we have to solve the older issue before that one.
sylvaing: That okay. Sounds like a good F2F topic.
sylvaing: Okay.
glazou: Anything else on animations?
sylvaing: Let me see
sylvaing: One more.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25034
sylvaing: This one about which rule gets found when you have
duplicate keys.
sylvaing: You have 3 20% rules, so which do you pick?
sylvaing: No compat. IE removes the one than it applies
sylvaing: Blink and Webkit do the first one first so they endup
backwards.
sylvaing: Gecko is complex from cascade.
glazou: This also depends on order. We need a model before
instructing the API.
sylvaing: I have one more, but it'll also depend on the discussion.
sylvaing: I'll start a new thread on the ML and ask for specific
compat feedback from browsers
<custom-ident>
--------------
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Mar/0582.html
SimonSapin: A few weeks ago we discussed a change to the values in
the spec.
SimonSapin: We made a change and people disagreed on what the
change should end up being.
SimonSapin: This is about what keyword should be disallowed to be
<custom-ident>s
SimonSapin: Right now CSS-wide keywords are defaults for being
disallowed.
SimonSapin: In addition anything that might be ambiguous is
disallowed.
SimonSapin: After I discussed with fantasai we thought it might be
good to have the same rule for all <custom-ident>.
SimonSapin: It seems like we don't have consensus on what behavior
should be.
fantasai: Makes sense to exclude global keywords. For other cases
such as gridlines where in the definition they're
unambiguous. but in use they're ambiguous. I think the
spec will have to call out explicitly
fantasai: I don't think we can make a universal rule. If there's a
more indirect connection between ambiguous and invalid
such as with grid, I think that will need to say so
fantasai: We may want a note in one spec that other specs should
consider those for invalid values. One thing I'm not
sure of is shorthands.
fantasai: It could be one thing if it is unambiguous in longhand,
but ambiguous in shorthand.
TabAtkins: We can't do much generally anyway because we
occasionally make longhands into a shorthand.
TabAtkins: So if we make something that will automatically walk up
the tree it might not work.
TabAtkins: If you use it in longhand vs using it in shorthand,
different values might be excluded.
TabAtkins: It might be okay to define a counter style in one place
but not somewhere since it conflicts with the keyword.
fantasai: Alternatively, we could have a rule where the shorthand
unless otherwise said you parse from start to end and
try your best so you would prioritize keyword over
<custom-ident>.
fantasai: So style is found first and than we look at <custom-
ident>.
dbaron: There's a bunch with parsing issues like this that we've
solved.
dbaron: One is list style shorthand where two properties take a
none value.
dbaron: So we have to allow two nones. If you're parsing you can't
find a none and decide. You find a none, count the number,
and see if you have more nones than unspecified properties
that can take nones.
dbaron: Similar for animations and transitions except worse.
dbaron: Transition and animation accept arbitrary things and in
Gecko we attempt to parse the other things first. Only if
they haven't already been found.
dbaron: I think you can see it in animation ease-in ease-in
dbaron: The first is timing, second is name and that makes dynamic
changes messy.
dbaron: And I don't know how inter-operable that is; thought the
list-style thing is inter-operable
<sylvaing> What happens with new global keywords?
TabAtkins: Do we just conclude exclude global keywords and discuss
more about ambiguities on the list?
glazou: I think that's a fair conclusion to the discussion.
SimonSapin: If we can't come up with a general rule, we can decide
about line names.
TabAtkins: We can do that on the mailing list, that's fine.
glazou: So we'll continue discussing this.
glazou: Anything else on this SimonSapin?
q unit
------
glazou: So we have 4 minutes. Anything to discuss?
fantasai: The q unit?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Nov/0302.html
fantasai: There's a proposal on the ML about adding a q unit since
that's common in Japanese, but it didn't go anywhere.
fantasai: Since we have to pass through LC for values and units,
do we want to add it?
sylvaing: I don't think there were any major objections except the
usual suspects.
fantasai: So any opinions? I can just add it in.
TabAtkins: I'm fine with adding it.
SimonSapin: I'm fine with adding.
RESOLVED: Add q unit to Values and Units
glazou: Okay. Anything else?
<fantasai> http://dev.w3.org/csswg/css-values/issues-cr-2013
fantasai: We should publish again for values once we resolve the
issues.
glazou: I suggest we close for now. I'll miss the next call, but
I'll talk to you next time.
Received on Thursday, 3 April 2014 00:04:06 UTC