- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Nov 2013 07:20:30 -0500
- 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
pseudo-elements.
=====FULL MINUTES BELOW======
Present:
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
content.
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
reflow?
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
them.
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
nodes.
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
information.
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
confusing...
<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
elements,
SimonSapin: And the one mechanism for going around this is
pseudo-elements.
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
pseudo-elments)
zcorpan: If we can return Elements and PseudoElements, then might as
well return Elements and PseudoElements and Attributes as
well.
<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
complexity.
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
Selectors.
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
attributes?
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
that.
<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
node-like
<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
elements)
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
things.
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
'content'
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
pseudo-element.
<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
speaker.
* 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
SelectorsAPI.
<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
pseudo-elements.
[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.
[break]
Received on Wednesday, 20 November 2013 12:20:58 UTC