- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Nov 2014 18:01:30 -0500
- To: www-style@w3.org
Re-naming flex-basis: auto
---------------------------
- RESOLVED: Accept fantasai's proposal for flex-basis: auto changes
(auto means main-size and add a keyword for automatic sizing)
Unicode-range syntax
---------------------
- It was quickly agreed that the text could move to the Fonts spec.
- There was disagreement between jdaggett and TabAtkins as to if
this additional normative text was necessary for the spec,
however, implementors stated that they did want the text
available to them. A compromise was reached where it would be
in an appendix so that regular authors wouldn't normally
encounter it.
- RESOLVED: Move the <urange> definition to an appendix in the
Fonts spec.
CSS3-UI
-------
- RESOLVED: Drop pseudo classes from CSS3-UI in favor of
Selectors 4
- RESOLVED: For clarity, all future pseudo-classes should be in a
Selectors module
- RESOLVED: Drop XFORMS related pseudo-elements.
- A tracking of the moved and removed pseudo-elements and pseudo-
classes is available here:
https://wiki.csswg.org/spec/css4-ui#more-selectors
- RESOLVED: Drop content: icon and the icon property
- RESOLVED: pull nav-index from level 3 and put it on a wiki
- Tantek requested that individuals add the URLs for discussions
related to nav-index here:
https://wiki.csswg.org/spec/css3-ui?&#issue-25
- There wasn't time to discuss the text-overflow issue, so
discussion will continue on the mailing list.
Box-Tree API
------------
- RESOLVED: Create a taskforce to work on box-tree API and
extensible CSS APIs
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
John Daggett
Simon Fraser
Sylvain Galineau
Daniel Glazman
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Mike Miller
Simon Pieters
Anton Prowse
Florian Rivoal
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Adenilson Cavalcanti
Bruno de Oliveira Abinader
Dirk Schulze
Mike Sherov
Ian Vollick
Lea Verou
Scribe: dael
plinss: Let's get started. Anything to add to the agenda?
Florian: TabAtkins raised something about :has-focus. I'd like it
added.
plinss: Okay. No problem.
Re-naming flex-basis: auto
---------------------------
<smfr> http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html
plinss: Who wants to talk on this one?
* fantasai proposes rossen lead
TabAtkins: It's fantasai that wants to talk and she's not here yet.
I'm not ready to talk on this yet.
dael: [reads fantasai IRC comment]
Rossen: I wasn't ready to talk either, but since it's there let's
talk.
plinss: We can defer.
Rossen: I still haven't seen a mass response from developers on
this. I did see leaverou say a week or so ago that she
chatted with fantasai and gave her feedback.
Rossen: That's just one sample.
Rossen: If at all possible I'll keep pushing to change to the
first option rather than the second which breaks
compatibility and I believe is more confusing. That was
the issue.
Rossen: Where are we, like I said, I'm still waiting on feedback
on it. If someone wants to add something we can discuss,
otherwise we can defer.
fantasai: I think leaverou's feedback was why not content size. I
asked other implementors and they posted these:
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0040.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0041.html
<fantasai> third author -
http://lists.w3.org/Archives/Public/www-style/2014Nov/0055.html
fantasai: Someone else posted...let me find that.
fantasai: A little bug seems like...it seems like it doesn't
change backwards compatibility. The Mozilla bug was
leaning toward not changing to main-size.
dbaron: We've had the change that's been in the spec in nightly,
but we pulled from beta given the set of regressions it
caused. There's a decent compatibility risk, we've had
things show up.
dbaron: At this point my memory is a bit muddled between which
changes caused what regressions.
fantasai: What I've heard is Microsoft and Mozilla are worried
about compatibility. Author side liked the other option,
they don't like dealing with backwards compatibility
problems and content as a keyword makes more sense.
We're used to 'auto' computing to something. That's the
feedback from dev I've pinged, I haven't heard feedback
supporting the first.
fantasai: Given that, I'd propose where auto means main-size and
add a keyword saying 'I want automatic sizing' with
content or content-size as the keyword.
plinss: So we have a proposal. Opinions?
TabAtkins: I like this less, but I won't fight it. It's fine.
plinss: dbaron?
dbaron: I'm fine with...I'm not into the issue that much, but if
people think it's less of a backwards compatibility issue,
I'm in favor.
fantasai: It definitely will. It doesn't change meaning, just
creates new syntax for something you previously couldn't
access directly.
plinss: Objections?
Rossen: I don't want to break backwards compatibility.
RESOLVED: Accept fantasai proposal for flex-basis: auto changes
(auto means main-size and add a keyword for automatic
sizing)
Unicode-range syntax
---------------------
<jdaggett> basic problem, CSS 2.1 defined UNICODE-RANGE token
<jdaggett> 2.1 tokenization:
http://www.w3.org/TR/CSS21/syndata.html#tokenization
<jdaggett> UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
<jdaggett> unicode-range descriptor of @font-face rule uses this
<jdaggett> sometimes interferes with other syntax in places
outside @font-face rules
<jdaggett> like selectors: u+a { color: green } will get tossed by
the parser
jdaggett: The basic problem is in CSS2.1 the unicode-range token
was defined. I put in the tokenization syntax above.
jdaggett: The descriptor exists. The problem is sometimes this
interferes with other grammar like selectors.
jdaggett: I put a test case with the problem (below). It fails in
Chrome and Firefox.
<jdaggett> testcase:
http://people.mozilla.org/~jdaggett/unicoderangetokenization.html
jdaggett: The basic resolution was to dump the unicode-range token
and replace with something like An+B syntax.
<jdaggett> telcon discussion in july:
http://lists.w3.org/Archives/Public/www-style/2014Jul/0051.html
<jdaggett> The resolution was to dump UNICODE-RANGE token, replace
with production "something like An+B"
<jdaggett> quick review unicode-range descriptor syntax
<jdaggett> list of comma-delimited <urange> values
<jdaggett> ex: unicode-range: u+f2e, u+100-1f3, u+2??
<jdaggett> three basic types - single codepoint, range, wildcard
<jdaggett> defined in CSS3 Fonts:
http://dev.w3.org/csswg/css-fonts/#urange-value
<jdaggett> TabAtkins wants to define <urange> in Syntax:
dev.w3.org/csswg/css-syntax/#urange-syntax
<jdaggett> seems like a verbose explanation of the same thing
jdaggett: Basically there's 3 types. There's single codepoint,
range, and wildcard. It's currently defined in CSS3
Fonts, but TabAtkins wants to define the <urange>
production in syntax spec. I put in the URL to existing
and proposed above
<jdaggett> and the grammar simply lists a bunch of possible token
sequences
<jdaggett> <urange> =
<jdaggett> u '+' <ident-token> '?'* |
<jdaggett> u <dimension-token> '?'* |
<jdaggett> u <number-token> '?'* |
<jdaggett> u <number-token> <dimension-token> |
<jdaggett> u <number-token> <number-token> |
<jdaggett> u '+' '?'+
<jdaggett> but the algorithm is simply saying "take this jumble of
tokens and reinterpret them as a sequence of..."
<jdaggett> ends up being different (and incorrect) version of
existing definition
<jdaggett> and it's totally out of context since the Fonts spec
explains what these ranges represent
<jdaggett> and how they are used
jdaggett: In the new description you have something like this
(above)
jdaggett: It ends up being different and not entirely correct. I
think it's out of place too since you need information
from Font spec, too. It's also just not in the spec
where this thing is described how it's used.
jdaggett: Resolving to remove the unicode-range token is fine, but
this new syntax and algorithm doesn't make a lot of
sense to me. It's really hard to read and implementors
have to look at both Syntax and Font specs to use it
correctly. Since it's only used for the unicode-range
descriptor, we don't need it spread across specs.
jdaggett: I'd suggest, in the process of removing the
unicode-range token, we redefine <urange> to link to
this and avoid linking to syntax spec.
* fantasai thought we already removed the token?
<ChrisL> agree it makes sense for all the spec of urange to be in
css3 fonts
TabAtkins: There's several issues here. The location of the
<urange>, I don't care where it's defined. I put it in
syntax because it's a spec I edit and it's a weird
complex thing that I put with a bunch of other weird
complex things, but if you want it in Fonts, fine.
Don't care.
TabAtkins: If you want it in fonts, that's fine. Not an issue.
TabAtkins: You also said it's incorrect, but you haven't pointed
out where. I ported the definition of the old parsing
and modified it in a few small places. It should be as
correct and match the old unicode-range. We don't
accept wider or narrower then the old version.
TabAtkins: The definition itself is ugly, I agree. This is what
happens when you mix syntaxes.
jdaggett: It's not necessary.
TabAtkins: It is. You can't use the existing Font spec that
defines roughly how it looks because it doesn't map
into a string of tokens properly. It's ugly and
terrible and that's why it says this isn't for authors
to read and I have a note to read other bits and that
this bit is just for implementors.
<fantasai> You could put it into an appendix
jdaggett: You're not giving precise mapping. If you look at the
algorithm it just says reinterpret as these other things.
The grammar is so complex because the syntax is hairy
and we can't it capture easily. What you wrote is what
an implementor will get from the existing test and this
doesn't add clarity.
TabAtkins: The token definitions I've pulled out are non-obvious,
but they are what an implementor needs to recognize.
Asserting we don't need to write that is wrong. We
absolutely need to write that or each implementor will
need to recognize those independently.
<zcorpan> I agree with TabAtkins on the above.
jdaggett: What's my objection is that the grammar is useless. The
algorithm isn't whats used, it's saying reinterpret as
hex digits.
TabAtkins: That's what we need when we remove the old version.
<ChrisL> So why was the special token removed? Why not have an
opaque blob for that one thing?
<dbaron> ChrisL, because it matched things that it wasn't supposed
to match, like some selectors
<ChrisL> thanks, dbaron
<dbaron> ChrisL, we were having trouble telling authors why u+i
was a valid selector and u+a was not
<zcorpan> ChrisL e.g. u+a {}
<ChrisL> got it
dbaron: I think we need to say how a token stream needs to be
interpreted. I think part of the controversy was TabAtkins
making changes about what's valid and invalid.
TabAtkins: Which I dropped back from. I found it easier to do
explicit parsing that matches the old text. It matches
everything it did before. Nothing that didn't match
before matches now.
jdaggett: dbaron, why do you think the algorithm is necessary?
jdaggett: The production will be longer than it is now.
dbaron: It will, yes.
TabAtkins: If we were doing this today we wouldn't use this syntax.
We would use something more compatible. We're stuck
with it. It's fine. It's nice and usable. However
describing it in syntax now that we've removed the
token, it's messy, but that's for implementors to deal
with.
TabAtkins: Developers doesn't have to worry about the messy, they
get a nice simple way.
<jdaggett> u+2f3f? is not captured with the current syntax
Florian: One question. Even though it's hard, can you have the new
syntax be separate? Is this approach useful or redundant?
TabAtkins: Depends on how much work you're willing to do.
dbaron: And how precise the other text is.
Florian: So having two definitions that say the same thing, is
that useful? Maybe making one an informative note
explaining the other.
TabAtkins: The pretty author text, that's the informative. The
normative is the algorithm.
fantasai: We might want it in an appendix, also.
TabAtkins: That's reasonable.
<dbaron> I think the complexity of expressing this makes me wonder
if we should instead keep the token and teach selectors
how to handle unicode-range tokens as selectors.
jdaggett: It's basically useless information. I think we need to
allow for variations in number of tokens, blah blah blah.
TabAtkins: That's captured by dimension with optional ? clause.
jdaggett: That's 2F3. How's that captured.
TabAtkins: It's a valid dimension.
<zcorpan_> u+2f2f? -> IDENT(u) DIMENSION(+2, f2f) DELIM(?)
jdaggett: This isn't helping anything. An implementor is thinking
the algorithm and what are the set of tokens I'm getting
and I'll reinterpret as a string. The algorithm captures
existing syntax.
<SimonSapin> As an implementer: yes, making this weird messy
grammar explicit is useful
TabAtkins: That's the point. The point is to describe the syntax
in terms of CSS language. I think you're imagining that
implementors can just image the underlying pieces. If
unicode is defined as a higher level, I need to define
it in terms of tokens.
TabAtkins: You're arguing for us to reintroduce the unicode-range
token. That's what we don't want because it's a complex
structure that's interfering. So we're left with this
messy one.
jdaggett: You're describing what the spec could describe by saying
instead of unicode-range, there's this, this, and this.
You've described it and the extra description doesn't
help anyone.
TabAtkins: Except implementors who want to be interoperable.
Florian: I think at this point TabAtkins and jdaggett's positions
are clear. I think we need to hear from other people.
SimonSapin: As an implementor it helps to have the token explained.
jdaggett: Why?
SimonSapin: It's what I need to implement.
dbaron: If we remove the token, we need this. However, I'm having
second thoughts on removing this. We need to leave it and
teach selectors how to deal.
ChrisL: How would you do that?
TabAtkins: The selectors would need to interpret some types of
urange as one type selector plus another type selector.
That's not for all uranges.
TabAtkins: If we need the ugliness somewhere, I'd rather isolate
it into the one place it needs to be. Since I have to
write a proper parse of Selectors, I dread having to
deal with this.
plinss: I agree.
dbaron: One of the things that is level breaking about TabAtkins
proposal is it requires remembering textilization of
unicode tokens.
TabAtkins: That's already required for hex colors.
dbaron: I don't remember having to do that.
<zcorpan> dbaron gecko isn't interoperable with IE on hex colors
in quirks mode. quirks spec sides with IE currently
<zcorpan_> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
http://w3c-test.org/quirks-mode/hashless-hex-color.html
TabAtkins: The quirks spec has a funky thing. It needs to spec a
hex color without the hex in front. So to do that you
need numbers and idents so you don't drop the leading
zeros.
Florian: There's a comment saying Gecko isn't compatible with IE
on this.
TabAtkins: I think we are compatible with IE last I remember.
<zcorpan_> 123 = #112233 in IE/spec, but #000123 in gecko/blink
plinss: So we have disagreement as to if this needs to be there,
but several implementors want it there. I think we have
agreement this should be in font spec as an appendix. Can
folks live with that?
jdaggett: I'm fine with an appendix.
plinss: Objections?
jdaggett: With the caveat where I think this can be simplified.
RESOLVED: Move this definition to an appendix in the Fonts spec
<zcorpan> dbaron i guess the quirk spec could be changed though
<TabAtkins> Ah, so we're compat with Gecko. Interesting.
<TabAtkins> But I tend to suspect that quirks compat leans heavier
toward the IE result.
<zcorpan> TabAtkins possibly but clearly we can get away with not
matching IE here
<TabAtkins> zcorpan, sure. We don't *need* numeric representation
if dbaron is okay with allowing U+00000000000002 being
valid and equivalent to U+0002.
<TabAtkins> Oh, well, I suppose I'd need to record some more flags
from scinot numbers.
<TabAtkins> Right now I translate them directly into numbers. If
we drop the representation, I'll need to record that
they were scinot and what power they had.
<zcorpan> TabAtkins dbaron maybe we should explore killing
representation of tokens if having the representation is
bad
<TabAtkins> zcorpan: I know that our implementor switching us to
the Syntax spec wanted to avoid using representation,
for memory reasons. It would be nice to avoid.
<SimonSapin> TabAtkins, +1 to dropping number representation if
possible
CSS3-UI
-------
Florian: A bunch of small issues, but maybe not too small. The
first was discussed at TPAC, but not resolved. Drop the
definition of pseudo classes because they're better
defined in Selectors.
Florian: There's also pseudo-elements. I have two separate points,
first one is pseudo-classes are in Selectors 4 and are
either identical or have clarified language.
Florian: We kind of agreed, but didn't record a resolution. Maybe
its been resolved already, but I don't think so.
plinss: Objections?
<andreyr> no objection
tantek: No objections. I think this does need different review
from the normal element tree for reasons like the
valid/invalid experience we had. No objections to moving
them to Selectors 4, I want to figure out how we get more
and earlier review to fix them.
tantek: I guess that's more of a request for input instead of a
proposal.
tantek: My comment also applies for moving the pseudo-elements to
the pseudo-elements spec. So that same comment/request
applies.
Florian: So can we resolve on pseudo-classes and move on?
plinss: Objections?
RESOLVED: Move pseudo-classes from CSS3-UI to Selectors 4.
tantek: And this is just for existing ones?
plinss: I think in general pseudo-classes should be in some level
of selectors.
<fantasai> http://dev.w3.org/csswg/selectors4/
fantasai: New ones have been dropped into selectors 4. We just
never removed those.
tantek: So I'd like that recorded as well.
Florian: I'm having a hard time hearing, but I think I'm okay with
what I've heard.
RESOLVED: For clarity, all future pseudo-classes should be in a
Selectors module
tantek: Should we do the same with pseudo elements, and move them
to the pseudo element spec as well?
Florian: For pseudo-elements, I'd agree with tantek's suggestion
if we were to keep them at all, but I suggest we drop
them entirely since they only apply to XFORMS.
<ChrisL> xforms is not really relevant anymore
Florian: Bert was tasked with...we lost tantek
* Florian waits for tantek to get back online
glazou: I don't think there's a single XFORM with a pseudo-element
<Bert> (I checked the most likely implementations and did not find
pseudo-element support.)
<Bert> (Except for XSmiles, which is not maintained.)
plinss: I'm not clear is tantek is trying to get back.
Florian: So Bert reported it hasn't been used since 2008.
<ChrisL> drop it
Florian: I contacted betterFORMS which had been suggested on the
list as an XForms implementation potentially using these
pseudo elements. They don't use them, nor do they know
anyone who does. They covert XForms into HTML and style
that. So with no known implementations, I suggest we drop
them instead of moving them.
glazou: I agree with that.
plinss: Anyone want to keep 'em?
<Florian> Tantek?
RESOLVED: Drop XFORMS related pseudo-elements.
Florian: Unfortunate that we lost tantek
plinss: We'll revisit if he objects.
Florian: Similarly the icon value and property don't have
implementors and there's no interest. So I suggest we
drop them.
plinss: Push to level 4 or drop entirely?
Florian: I think drop, but I can push if there's interest. So far
I've found no interest.
plinss: implementors? Anyone want to implement this?
Florian: I asked on the list and Google and Microsoft were no if I
remember correctly.
Florian: Yes, TabAtkins and gregwhitworth say no plan. No other
comments.
dauwhe: These were in Generated Content and had no interest either
<ChrisL> drop
smfr: I don't think webkit has interest.
plinss: So drop entirely?
Florian: We can pull back if someone becomes interested.
<smfr> drop
dauwhe: I'd say drop
<andreyr> drop
glazou: drop
RESOLVED: Drop content: icon and the icon property
Florian: Last drop request is the nav-index.
Florian: Directional nav properties are fine, but the index has
problems. This has a bit of interest, so I'd suggest move
it to level 4, but I think it would hold back CSS3-UI
dbaron: We had various discussions with WAI about this. I don't
know if they'd be upset about moving to 4, but we should
get the results of that discussion in somewhere.
ChrisL: Florian, you mentioned some interest?
Florian: I vaguely remember that the same people with interest in
directional nav had interest, but I don't remember
exactly who.
<ChrisL> that argues for moving to level 4 rather than dropping,
then
<tantek> I've been tracking "future" / "postponed" UI related
pseudo-classes and pseudo-elements here
https://wiki.csswg.org/spec/css4-ui#more-selectors
<tantek> gah
<tantek> is my IRC getting through at least?
<tantek> ???
* smfr tantek yes
* Bert sees Tantek on IRC
<dbaron> tantek, just got 4 lines at once
<tantek> It's in the CSS3-UI issues page folks
<tantek> Could someone please check that instead of wondering
where it is?
<tantek> Search https://wiki.csswg.org/spec/css3-ui for nav-index
<tantek> It links to various discussions and things,
<tantek> since searching email fails.
glazou: In terms of TV, people are more interested in direction
then index. If it's implemented it's not used and I'm not
sure if it's implemented everywhere.
fantasai: I remember some discussion about nav-index and the
problem was it's global to the page with no hierarchy.
If we can we should try and fix that. It seems that
would be better in 4.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0364.html
<fantasai> glazou's email that was this investigation^
glazou: The problem is the use case. Last time I read about that
it said this is useless because people are using the arrow
keys on the remote.
glazou: I think we ping these people to find out if it's used. If
it's unused we should drop it and it's worthless to invest
time. People have implemented the direction nav, but not
the others.
fantasai: And we're not talking about dropping direction.
glazou: I don't think anything but direction is used.
Florian: People still discuss it, so I don't want to drop
completely, but we can push to 4 and discuss again when
we try and stabilize that. If it's clear no one wants it
we can drop immediately. I'm fine with either.
<fantasai> minutes from last nav-index discussion with a11y folks:
http://lists.w3.org/Archives/Public/www-style/2011Nov/0712.html
fantasai: I'd like to push to level 4 with an issue about the
things brought up at the last a11y disucssion.
Florian: tantek you're back?
tantek: Yes.
Florian: So, the question is, do we drop nav-index now, or move it
to level 4, or stabilize it now. No one seems in favor of
stabilizing it now
tantek: I haven't seem implementors interested. The potential
opportunity is to fix it and make it better then tabindex
because it doesn't have backward compatibility problems.
And the folks with directional nav stylesheets could use
it in the same stylesheet. If that's interesting enough I
think we can put it into level 4. If there's no interest,
we can drop.
tantek: I'll move the text to a wiki and let it evolve passively.
tantek: So does anyone in the group, especially those with the
directional properties, have interest?
<ChrisL> (it seems not)
<tantek> for reference: https://wiki.csswg.org/spec/css3-ui?&#issue-25
<tantek> please add more URLs there
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg440
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg441
glazou: The implementors I dealt with during my time at Samsung
had no interest in nav-index.
Florian: I don't remember for Opera. I don't think they have
stated not being interested, but they haven't expressed
interest loudly either.
tantek: That's important data. I'd also like to hear from
TabAtkins who looked at tabindex. Is it worthwhile?
TabAtkins: I don't think so. I think we should fix HTML and then
CSS.
tantek: Okay, so I'd rather it move to W3C wiki with other
semi-abandoned properties so if anyone else wants to get
it later, it's good.
<Bert> q+ to suggest asking WAI PF for a joint telcon or at least
advice
stevez: It seems to me that at the protocol group someone talked
about the nav-index so check with him to see if there's
interest. The question is if they thought it would fix
tabindex.
fantasai: I linked the F2F discussion. They brought up a lot of
problems, I'm not sure how much it was "I want this"
tantek: fantasai, can you add your urls to this wiki page?
dbaron: I also linked to the follow-up threads.
<tantek> Please add your URLs about nav-index here:
https://wiki.csswg.org/spec/css3-ui?&#issue-25
<tantek> dbaron and fantasai ^^^
<dbaron> tantek, there's also a separate
https://wiki.csswg.org/ideas/nav-index
Florian: There seems to be consensus on moving this to a wiki.
plinss: sounds reasonable.
tantek: If you care about it, put it on the wiki
RESOLVED: pull nav-index from level 3 and put it on a wiki
Florian: One more. There is a clarification that we need on
text-overflow. The prose seems to be contracting itself
when the property is used with a single value and you are
scrolling the thing that's being ellipsed.
Florian: The text appears to be contradicting as to if it applies
to both sides or just on the end side. Implementations do
end side only. If you have double value it's fine.
tantek: This isn't a one minute issue. I believe there was
discussion on this with fantasai two years ago we got this
to work with Gecko. If the spec has prose problems, I'm
going to go with Gecko.
tantek: At the time our tests showed no other implementors, IE,
Webkit, or Presto were even trying to do something
interesting.
Florian: Presto does the same as Gecko for the single value, and
does not support double value. Others don't do anything
interesting indeed.
Rossen: This isn't one minute. It's a good topic.
Florian: I agree. We can't do this now.
tantek: Continue offline.
<tantek> we didn't get to :has-focus either - on that topic please
review *all* the new CSS UI related selectors being
considered/implemented:
https://wiki.csswg.org/spec/css4-ui#more-selectors
Box-Tree API
------------
plinss: One quick topic myself. We've had some discussions about
creating a taskforce for the box-tree API. I don't think
we have a resolution for it.
plinss: Objections?
<ChrisL> +1
<dauwhe> +1
<sgalineau> +1
RESOLVED: Create a taskforce to work on box-tree API and
extensible CSS APIs
tantek: I want to point out we didn't get to :has-focus. There's a
whole bunch of CSS Selectors being implemented. I dropped
a link above, give it a look.
plinss: That's it for the week, thanks everyone.
Received on Thursday, 20 November 2014 23:01:59 UTC