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

[CSSWG] Minutes TPAC F2F 2013-11-11 Mon I: display: none on Fragmentainers, Selecting Attributes

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Nov 2013 07:20:30 -0500
Message-ID: <CADhPm3vrg1VQ99BXj4XeZ-KW7XTokGAMtME-TJkBMrP9tMAowQ@mail.gmail.com>
To: www-style@w3.org
display: none on Fragmentainers

  - RESOLVED: Regions with display: none do not join the region chain.
  - RESOLVED: Add note to Fragmentation that display: none
              fragmentainers do not participate in fragmentation.

Selecting Attributes

  - Jikra presented his proposed extension to Selectors that would help
         with translation processes.
  - The group discussed if Selectors was the right place for Jikra's
         proposal, including possibly using pseudo-element.
  - RESOLVED: Add ::attr() pseudo-element into a new module for non-CSS


  Rossen Anatassov
  Tab Atkins (by phone)
  David Baron
  Bert Bos
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman (IRC Only)
  Rebecca Hauck
  Israel Hilerio
  Koji Ishii
  Dean Jackson
  Taichi Kawabata
  Jirka Kosek
  Chris Lilley
  Peter Linss
  Larry McLister
  Simon Pieters
  Simon Sapin
  Dirk Schultze
  Leif Arne Storset
  Alan Stearns
  Lea Verou
  Jet Villegas
  Kazutaka Yamamoto
  Steve Zilles

Agenda: http://wiki.csswg.org/planning/tpac-2013#agenda

display: none on Fragmentainers
  ScribeNick: fantasai

  [round of introductions]

  astearns: Overflow fragments container that says that if the fragment
            box has display: none, it doesn't create a box and gets no
  astearns: I think I'm going to add something similar to Regions spec,
            saying that if a region has display: none, it doesn't get
            any fragment of the named flow.
  astearns: Question is, whether it remains a region and is something
            accessible in the named flows JS API, or if we add something
            to the spec saying that it does not become a region if it's
            display: none?
  astearns: I think latter formulation is a little bit more elegant.
  ChrisL: Would that mean if you flipped the value of display it forces

  astearns: If you .. in JS, can see those named flows and perhaps do
            something with them.
  astearns: Problem: if these regions that are not really regions are in
            the API, you have to figure out what info to return for
  astearns: I don't see much value in including them in the region chain
            API, so my preference is to not include them.

  ChrisL: You have a chain of elements, a linked list, it seemed if you
          flip display you need to take it out of the list.
  ChrisL: Is there overhead for that?
  astearns: The same overhead as switching e.g. 'flow-from' property.
  astearns: I propose resolving that regions with display: none do not
            become regions.
  astearns: I have a list of other things in the spec that don't become
            regions, I would put it there.
  astearns: Might consider putting something in the Fragmentation spec
            about general interaction with display.
  <TabAtkins> I support this proposal.
  fantasai: ok

  RESOLVED: Regions with display: none do not join the region chain.
  RESOLVED: Add note to Fragmentation that display: none fragmentainers
            do not participate in fragmentation.

Selecting Attributes

  Jirka: ITS WG, we have been creating REC which defines set of metadata
         which can be used in HTML and XML documents in order to improve
         automatic l10n and translation processes
  Jirka: In ITS if you, for example suggest some automatic translation,
         you can put attribute saying that <b translate=no>
  Jirka: Which means don't translate this element.
  Jirka: You can also make rules to say which elements should / should
         not be translated.
  Jirka: It's similar to how CSS attaches properties to elements.
  Jirka: In ITS, if you would like such a general approach, you can use
         either XPath or Selectors.
  Jirka: We wanted Selectors because average Web developer knows
         Selectors, but not XPath.
  Jirka: So we added support for language such as Selectors.
  Jirka: But we have a problem that HTML has human-language data in
         attributes instead of elements.
  Jirka: Like title attribute, some people are using data attributes.
  Jirka: Cannot apply these rules to such text, because Selectors cannot
         point at attributes.
  Jirka: So we would like to extend Selectors to allow that.

  Jirka: I sent mail to www-style about this,
  Jirka: But we don't know how to proceed.
  <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Nov/0016.html

  SimonSapin: We could add pseudo-elements that match attributes.
  SimonSapin: There are some issues with this
  SimonSapin: First, styling attributes makes no sense in CSS, so the
              new feature would have to be invalid in CSS.
  SimonSapin: Also Selectors API only returns elements, so we could not
              use feature there either.

  SimonSapin: The intent is to implement ITS with JS using SelectorAPI.
  SimonSapin: So even if we add this to CSS, JS API would have to be
              extended to return attributes.
  <TabAtkins> It doesn't have to be invalid in CSS, just never generate
              a box.
  <TabAtkins> But the SelectorsAPI part is harder, since we want
              .find/.qSA to return an Elements (array subclass that
              contains elements).

  Jirka: The Selectors abstract says it's generic language for selecting
  Jirka: So selecting attributes/nodes/comments is within that scope.
  Jirka: I know of some XML editors that extend Selectors in such ways.
  Jirka: There are other publication use cases that need that
  Jirka: So maybe we need to decide whether Selectors can only apply to
         elements, or if need some extension.
  Jirka: ... whether extending/modifying JS apis can be done
  Jirka: ... splitting Selectors from CSS was a good idea ...

  <kennyluck> using @ both for attribute and @-rule seems highly
  <SimonSapin> kennyluck: could be ::attr(foo)
  <TabAtkins> Problem is the fundamental data model. All common uses of
              Selectors only return elements, and it's hard/odd to make
              the APIs built up around this handle anything else.
  <TabAtkins> And attributes being nodes was always one of the weirder
              parts of old DOM, imo.

  SimonSapin: In my opinion so far, Selectors is really about selecting
  SimonSapin: And the one mechanism for going around this is
  SimonSapin: The issue that needs to be solved for ITS is to find a way
              for JS API to handle more than elements
  <TabAtkins> Oooh, suggestion! We could return PseudoElement!
  <TabAtkins> There's a reason we defined that interface!
  <TabAtkins> I think it would be okay for .find() to return an array of
              Elements and PseudoElements.

  ChrisL: We decided to call it Selectors, not CSS Selectors.
  ChrisL: We decided that so that it could be useful for other things.
  ChrisL: So, SimonSapin is correct -- CSS styles elements, so far the
          only one that can select elements.
  ChrisL: If others are interested in using Selectors for other things,
          we need to extend it for those things
  ChrisL: We're moving from XPath to Selectors W3C-wide, so can't say we
          don't want to handle someone else's use cases while saying
          that it's for everyone not for CSS alone.

  zcorpan: I agree with you that Selectors should be generic, and it
           could make sense to extend it.
  zcorpan: But I also agree with Simon that I would like to see a
           proposal for what the SelectorsAPI should look like with this
           extension in place,
  zcorpan: Before extending Selectors with it.

  Jirka: I was just saying that for ? API, extending selecting is still
         a performance problem or incompatible, you can always introduce
         new types than just Elements.
  fantasai: So Tab has a comment in IRC.

  * Bert thinks we could select an attribute and flow it into a
         region... '::attr(title) {flow: a}'

  [fantasai reads Tab's comments above]

  <kennyluck> I don't think attributes are PseudoElements. What style do
              they have? (ie. remember that getComputedStyle can inspect
  zcorpan: If we can return Elements and PseudoElements, then might as
           well return Elements and PseudoElements and Attributes as
  <TabAtkins> kennyluck: A PseudoElement doesn't *need* to be able to
              generate a box.
  <TabAtkins> zcorpan: We're trying to kill the Attr interface. ^_^
  <zcorpan> TabAtkins: no? we're trying to make it not inherit from
            Node, the object can't be removed
  <TabAtkins> zcorpan: Ah.
  <TabAtkins> zcorpan: Just sticking with PseudoElement is probably good
              anyway - we likely want to allow people to, for example,
              select regions.
  <kennyluck> TabAtkins, just what exactly should getComputedStyle(el,
              "::attr") return? An error or an style that has all
              initial values?
  <TabAtkins> kennyluck: Same as a ::before without a 'content'.
  <astearns> TabAtkins: I agree we need to have PseudoElement - I don't
             know that this is an argument to conflate PseudoElement
             with Attr
  <TabAtkins> astearns: Yeah, sure, it's not necessarily an argument
              for, but I already prefer the pseudo-element syntax for
              grabbing attrs, and it keeps down the set of things we'd
              return from .find.
  <astearns> TabAtkins: sure - having a similar interface to get to them
             makes sense.

  fantasai: Send in a concrete proposal.
  fantasai: Sounds like the next action is for someone to figure out how
            Selectors API should be extended, and then come back with
            that solution and ask Selectors syntax to be extended.
  dbaron: I'm not convinced of use case
  dbaron: There was some concerns with regards to ... about excess
  dbaron: Not clear to me feature that was done this way had to be done
          this way.

  Jirka: ITS v1.0 was xpath only, v2.0 adds selectors but they can't get
         at attributes.
  Jirka: In situations with attributes, it's not possible to use
  Jirka: I consider Selectors just another language on top of document,
         like XPath.
  Jirka: My POV is to just extend Selectors. If some other API doesn't
         support attributes, then doesn't use it.

  <ChrisL> Really, ITS is the only thing that needs access to
  dbaron: Languages aren't designed to do everything.
  dbaron: You're taking a language designed around XPath and trying to
          swap in Selectors.
  dbaron: I'm not convinced we should extend Web platform for this spec
          that you wrote.

  Jirka: If Selectors is positioning itself as universal selection
         language, then...
  dbaron: DOM is moving towards a model that attributes are not
          first-class members of tree like elements are.
  dbaron: Attributes are an API on Elements, they're not a member of
          this tree.
  dbaron: The model that attributes are like nodes is too complex.

  zcorpan: Because of existing content, we can't get rid of Attributes.
           Could maybe make it not inherit from Node, but it still needs
           to exist.
  dbaron: Yes, there's existing things, but we're movement to change

  <TabAtkins> I would like to take the few small steps necessary to kill
              most remaining uses of XPath.
  <hober> we shouldn't be adding new api that treats attributes as being
  <TabAtkins> Right, hober, but having something that says "There's data
              in this attr over here" doesn't seem unreasonable.

  Jirka: I think that there is no reason to not support some part of the
         document because ...
  Jirka: Attribute is simply part of the document, it doesn't matter how
         it is represented, it is still storing data belonging to the
         document. Should be possible to select it
  Jirka: I could go to users and say if you want to select attributes,
         you must use XPath.

  [fantasai reads Tab's comment]

  <Jirka> TabAtkins: With XPath 2.0/3.0 it would be much more
          challenging :-)
  <TabAtkins> Jirka: Sure, but I'm not as concerned about that, as
              there's no browser impls. ^_^
  <ChrisL> Tab, yes but we can't say on the one hand stop xpath and on
           the other hand, we only care about selectors that are good
           for CSS.
  <TabAtkins> ChrisL: Note that I'm not saying that.
  <ChrisL> OK good.

  fantasai: We already have a case where Selectors can select some
            things in one language (pseudo-elements are OK to select in
            CSS) but not in another (SelectorsAPI can only return actual
  fantasai: I don't think it's a stretch to have another language that
            can do things with Selectors that are invalid in other cases
            like SelectorsAPI/CSS

  <TabAtkins> I care about Selectors that are useful for the web. If
              there are reasonable APIs on the web that would like to
              refer to attributes, then having a way to select those
              seems reasonable.
  <ChrisL> This whole issue bout 'is an attr a node' seems orthogonal to
           whether selectors can get at them.
  <TabAtkins> Selectors is *the* tree-traversal/search API on the web.
  <dbaron> I guess I just don't understand why we give ITS this level of
           access to make demands of the CSS WG when we don't give lots
           of people developing things on the Web that level of access
           to the CSS WG.
  <TabAtkins> dbaron: We're giving them no more access than anyone else
              making a request.
  <dbaron> TabAtkins, I don't think we give most people making requests
           big slots on the agenda at a face-to-face.
  <TabAtkins> dbaron: Sure, I've got no comment on that, other than that
              we're taking time to discuss it, and the relevant person
              happens to be around.

  plinss: If we added something to Selectors that allowed selecting
          attributes, but it didn't work in the API, would that be
          workable for you?
  <TabAtkins> plinss: I don't think that's acceptable for the Jirka
  Jirka: For us it will be sufficient just extending Selectors, not also
         changing SelectorsAPI at the same time,
  Jirka: Because in the meantime, there are ways to implement this.
  Jirka: If there are other use cases for SelectorsAPI, it can be
         changed in the future.

  plinss: Does this work for people? Or are people opposed to this?
  zcorpan: My previous comment still applies, but I would be ok with
           adding it to Selectors now if it turns out that in a year or
           something, hasn't been added to Selectors API, then maybe we
           should reverse it.

  ChrisL: It occurs to me that CSS might also have need for styling
          attributes, sometimes text would be in attributes, you want to
          style it.
  <TabAtkins> ChrisL: Perhaps. Today that's done as ::before { content:
              attr(foo); }.

 * sgalineau is concerned there is very limited understanding of the
             target use-cases so we can't really come up with
             alternatives or evaluate them...
  fantasai: You're not styling the attribute, you're styling a
            pseudo-element that has slurped up the attribute's text via

  Bert: If you can use Regions flow to pull in attributes to content,
        you don't need the pseudo-element
  <Bert> we could select an attribute and flow it into a region...
         '::attr(title) {flow: a}'
  <TabAtkins> Bert: That's jumping a bit ahead. You still need to
              describe how it generates a box, ordering, etc.
  <TabAtkins> At that point you're just defining an ordinary
  <TabAtkins> If you can 'flow', you can 'display' without flowing.

  plinss: CSS doesn't need it, at least not now, but is this something
          we should add to Selectors to support the ITS use case?
  plinss: I'm not hearing any clear answers here.
  * TabAtkins Mind if I try talking?
  ChrisL: Sounds like we've stopped objecting, so need a concrete
          document for this.
  fantasai: If we think it's a pseudo-element, it would go in a separate
            document from Selectors
  plinss: thanks

  <dbaron> TabAtkins, jet is holding the microphone up to his laptop's
  * fantasai didn't make that out
  * zcorpan TabAtkins can you type also?
  * fantasai TabAtkins, you need to talk extra extra articulated.

  TabAtkins: I agree with what Chris says
  TabAtkins: I don't have any comments beyond what I typed into IRC
  * TabAtkins Oh man, this is going to be hard.

  fantasai: Jirka did send a proposal, so the question is do we want
            that proposal? Are there other options to discuss?
  fantasai: I didn't read the thread, it would be good to hear a summary
            from someone who did.

  <Bert> (I think, until somebody founds an objection, '::' seems the
         best syntax so far.)
  * ChrisL idly suggests ::: for attributes

  SimonSapin: The initial proposal was with an @sign like in XPath, like
              @foo for foo attribute.
  SimonSapin: That's a bit foreign in Selectors, several people didn't
              like it, may be ambiguous with @rules in CSS syntax.
  SimonSapin: Next proposal was to use pseudo-element syntax,
  SimonSapin: Which make sense because this would have similar
              restrictions to pseudo-elements.
  SimonSapin: e.g. don't have child elements, have to be at the end of
             the selector
  fantasai: Also it's only valid in certain contexts, just like most
            pseudo-elements are only valid in CSS rather than

  <SimonSapin> pseudo-element syntax proposal: ::attr(foo)
  <SimonSapin> or ::attr(ns|foo)
  ChrisL: I like what Simon just typed.
  Bert: Go for it.
  kennyluck: I don't think attributes are pseudo-elements, because they
             never have styles.
  kennyluck: They don't generate a box.
  <TabAtkins> Note that this selects the attribute off of the selected
              nodes, regardless of whether there's such an attribute
              (probably unlike XPath).
  <TabAtkins> The translation of "@foo" is "[foo]::attr(foo)"

  kennyluck: Tab pointed out ::before { content: normal; } doesn't have
             styles but I think we have ::before because it "sometimes"
             have styles.
  kennyluck: I think we should have other syntax
  <TabAtkins> kennyluck: They *might* have styles, if we define how they
              generate a box.
  <kennyluck> @attributes(selector, attrib)
  <TabAtkins> kennyluck: But that's pushed down.
  <TabAtkins> Oh, no, let's not abuse at-rules to hide selectors in.

  * sgalineau what properties do you apply to attributes?
  <SimonSapin> sgalineau, none. This doesn't do anything in CSS.
  <sgalineau> ok, so purely for API selection.

  [fantasai explained that Selector in CSS selects things that can have
            style properties, be they real elements or special
            pseudo-elements but SelectorsAPI only selects actual
            elements, boxes are out-of scope. It would make sense for
            another language to have pseudo-elements that can select
            things relevant to their context, but no pseudo-elements
            that represent boxes]

  SteveZ: Another way of saying is that it's not really pseudo-elements,
          but pseudo-things... broadening the class

  <TabAtkins> Pseudo-elements are already a weird stretched concept,
              which are best understood as a combinator that jumps into
              some other tree.
  <TabAtkins> This explains ::region, ::content, etc.
  * Bert thinks '@attr ATTRNAME SELECTOR {...}' would be valid syntax,
         too, but maybe a bit unexpected...
  <TabAtkins> In this case it'd be jumping into the attribute tree.

  dbaron: If this goes into the Selectors spec, we need to make it *very
          clear* that this can't be used in CSS to style attributes.
  <TabAtkins> dbaron: I'm fine with that, and can make it clear.
  <dbaron> ...but that it's for selector APIs only.

  SimonSapin: Pseudo-elements have already moved out of Selectors module
  fantasai: Yeah, it would be a separate spec.
  Fantasai: We are moving pseudo-elements out of the Selectors spec
            because Selectors is already too large and pseudo-elements
            only apply to CSS anyways.

  Jirka: I'm willing to be editor of this spec.
  plinss: Does anyone want to co-edit?
  <TabAtkins> Daniel and Alan are already the editors of the relevant
              spec. ^_^
  <dbaron> It seems a little odd for it to be a separate spec just for
           the attribute things
  * TabAtkins http://dev.w3.org/csswg/css-pseudo/

  fantasai: This isn't a CSS feature, therefore it shouldn't go with the
            other CSS-only features. So it's clear this doesn't apply to
            CSS at all.
  astearns: Multiple before/after pseudos should be replaced anyway,
            they didn't pass muster.

  plinss: So, draw up a draft, and we'll review it later
  plinss: Anything else on this?

  RESOLVED: Add ::attr() pseudo-element into a new module for non-CSS

  [krit asks about discussing WebVTT pseudos]
  plinss: we'll discuss ::cue after indieui.
  plinss: Please be back promptly at 11, we have a joint meeting.

Received on Wednesday, 20 November 2013 12:20:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC