W3C home > Mailing lists > Public > www-style@w3.org > November 2014

[CSSWG] Minutes Telecon 2014-11-19

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 20 Nov 2014 18:01:30 -0500
Message-ID: <CADhPm3tfM7ewisaP+WGjjWa_TU35_JFQmdaaobsECytTEJR7hA@mail.gmail.com>
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.


  - 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:
  - 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:
  - 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


  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

  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
  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
  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 -
  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

Unicode-range syntax

  <jdaggett> basic problem, CSS 2.1 defined UNICODE-RANGE token
  <jdaggett> 2.1 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:
  jdaggett: The basic resolution was to dump the unicode-range token
            and replace with something like An+B syntax.

  <jdaggett> telcon discussion in july:
  <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:
  <jdaggett> TabAtkins wants to define <urange> in 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
  <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
  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
  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
  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
  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
  <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


  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
  tantek: My comment also applies for moving the pseudo-elements to
          the pseudo-elements spec. So that same comment/request

  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
  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,

  <tantek> I've been tracking "future" / "postponed" UI related
           pseudo-classes and pseudo-elements here
  <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:
  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
  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

  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
  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:
  <tantek> dbaron and fantasai ^^^
  <dbaron> tantek, there's also a separate

  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
  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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC