- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 17:24:21 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Events and Fragmentation
------------------------
- RESOLVED: Work on pointer-events: elements-from-point solution that will
walk the elementsFromPoint chain instead of the ancestor chain
(problem is passing events from content to fragmentation container)
- Issue raised against Selectors 4 wrt whether ::pseudo:pseudo combinations
are invalid or match nothing.
Shapes
------
- RESOLVED: Move contours from rendered content to next level
- Discussed using same-origin restrictions for shapes.
- RESOLVED: Close the float/exclusion harmonizing issue.
Exclusion wrapping context does not include floats.
====== Full minutes below ======
Events and Fragmentation
========================
Scribe: fantasai
stearns: Events in fragmented flows, comes up in regions, but also issue
in other types of fragmentation...
stearns has drawn some boxes:
There is a big box, which represents the thing that contains the fragmentainers.
Inside are two fragmentainers, FC1 and FC2
stearns: These could be regions, pages, column boxes, whatever
stearns: Crucial thing is that fragmented flow has an article (draws box A),
stearns: which contains a paragraph (box P), and there's a break at some
point in the paragraph
stearns: Issue is when you click in one of the fragments of the P
stearns: The fragmentainer never hears about it
stearns: The event goes out from P to A to the outer box, skips FC boxes
SimonSapin: Are the two FC boxes generated from the same element?
dbaron: In overflow fragments, yes, but not in Regions.
dino: You said it doesn't matter, but is FC1 or FC2 regions, or columns...
is A a child of that?
stearns: In overflow fragments A would not be a child of either container,
would be a child of outer box.
dbaron: In overflow fragments not that distinction, just the one level.
stearns: If I said :nth-fragment(2):hover, I want that fragment container
to respond to hovering over this part of the paragraph, and not
respond to hovering over the other part of the paragraph
Bert: Could have :hover on the outer box.
stearns: I want the container to change.
<Bert> (DIV:hover::slot(fc2) {... highlight... }.)
stearns: Only when it's hovered inside, not when the other fragment is
hovered inside.
stearns: And in Regions these can be different elements.
<Bert> (Forget what I just said.)
dino: In A have one region element you're flowing into. Events don't get
seen by region element
stearns: No
dino: you can't write a rule that says ::region:hover
stearns: right, and I want to
dino: me too
stearns: Regions has an API that allows you to determine which region
got clicked.
stearns: Doesn't work for hover but works for click events
stearns: That workaround only works for events, doesn't work for :hover
styling
stearns: But that workaround also doesn't work for fragmented elements
<stearns> http://wiki.csswg.org/spec/css3-regions/user-event-handling
stearns: There are two proposals for handling this
stearns: First is for fragmented flows in general
stearns: When you have event bubbling in a fragmentation context
stearns: Event goes up through the chain as normal to the fragmentation root
stearns: The thing that contains the content that is fragmented
stearns: At that point, the fragment container is inserted in the bubbling
stearns: And the bubbling continues with whatever contains the fragment
container, up through the hierarchy.
dbaron: Are you talking about event bubbling because you want to change
:hover, or because you want to change what event handlers get?
stearns: Yes. Both.
jdovey: Issue on columns as well.
stearns: Once we get to point of having addressable columns, can be done
for columns
stearns: If you want to know what page an event was on, would have page
inserted in event/style loop
stearns: I'm actually not sure whether bubbling for CSS :hover is actually
defined anywhere
stearns: I assume it does the same
dbaron: It's not really bubbling, but it's defined
http://dev.w3.org/csswg/selectors4/#the-hover-pseudo
"The parent of an element that is :hover is also in that state. "
stearns: One way to solve this, is, in a fragmentation context, insert
the fragmentainer at the appropriate spot
stearns: One more thing in the appropriate spot
dino: If it's a region, then does it bounce back to the ancestor chain
or go up the region's ancestors?
stearns: Goes up the region's ancestors
This essentially circumvents the element's own ancestor chain.
TabAtkins: Problem you're describing is virtually identical to problem
with Shadow DOM and events
TabAtkins: Shadow DOM can rearrange content in a similar way
TabAtkins: Regions is slightly more general issue, but can be safely
generalized under this as well
TabAtkins: Don't know precise details of what we do, but if you want
details will have to ask Dmitry, who just went home
stearns: Shadow DOM describes it as DOM manipulation
stearns: Follow reordered DOM hierarchy
TabAtkins: After reordering and following up
TabAtkins: Things that aren't in the Shadow DOM have no way of telling
that the event passed through the Shadow DOM.
stearns: That's very important to shadow DOM, not so important here.
TabAtkins: Could break things if you add pseudos you didn't expect.
stearns: It will continue to multicol element, just one added stop.
... regions ...
fantasai: In case of regions, you might wind up not hitting your ancestors,
because going up region's ancestor chain now.
fantasai: Whereas other cases, you always walk up all your ancestors,
just might make extra stops along the way
stearns: If you go through email thread linked from wiki
stearns: Went through number of iterations trying to figure out how to
preserve event bubbling chain.
stearns: or dealing with this somehow
stearns: everything got way too messy
stearns: Once you've put content into this fragmented flow, makes more
sense to me for events to follow region's ancestor chain.
fantasai: Depends on what you're trying to do
fantasai: Depends on how much you're scrambling the tree, and how much
you are handling events locally vs. talking to things higher
in the document tree.
dino: Think it's very confusing to go up region chain
dino: If you wrote selector parent-element > child-content
dino: Expect that selector to apply
dino: wrote parent-element:hover > child-content to work
dino: But break that expectation
stearns: ...
stearns: But named flow, taking boxes from parent, putting them over here
stearns: these boxes should be ones responding to user events because
you made that disassociation
dbaron: I find it really weird to have events not follow the DOM
dbaron: They're a DOM structure
dbaron: And I think separation of content and presentation makes it really
weird for box-tree structure to mess with DOM structure
stearns: Have a response to hover styling?
dbaron: I think hover styling is separate from events
TabAtkins: Can be easier to handle :hover going two directions up the
tree, than events going up the tree
TabAtkins: Could do complicated thing now with pseudo-classes, rather
than events
dean: what happens with elementFromPoint()?
dbaron: it depends if there's content at that point in the region --
you get the most deeply nested thing
dino: Want to understand why :hover and events could be different
dbaron: :hover is a CSS concept
dino: Based on mouse events
dbaron: That's changed over time. It happens to be true now.
plinss: We have whole dichotomy of things like mouse events, that deal
with geometry of presentation
plinss: These fire at the DOM tree, kindof broken
dbaron: We could have another type of mouse event that doesn't bubble,
but that you fire at everything in that geometry.
dbaron: We do sortof have that for mousover and mouseout
Rossen: Going through iterations, another idea for adding region as a
separate target
* fantasai likes Rossen's idea best
stearns: Another solution is to add a mode to pointer-events property
stearns: So you could say for e.g. relpos'd box, events will follow box tree
stearns: Other mode, other solution is to have this switch, where for
certain elements that you choose, you have the event just run
through the visual layers
TabAtkins: element with fragment parent, goes to fragment parent rather
than real parent?
stearns: Goes to whatever's displayed underneath it, which in fragment
case would be fragmentainer
dino: One option is following DOM tree
dino: second is following box tree
dino: Third is following painting order
stearns: Second solution is not doing the middle event
stearns: Right now pointer-events can be normal, they go up the DOM tree
stearns: Can say pointer-events: none;, which ignores pointer events
stearns: Switch would trigger just painting order
stearns: You'd get the relpos box and whatever is underneath it
TabAtkins: So third one is elementsFromPoint() and walk that list
plinss: Where are you setting this switch?
The target of the element will decide on the path of the event
dino: If you did something like this, set it on ancestor, does ???
dino: Doing propagation based on painting order is quite complicated,
because implementations might forget exactly the order for perf
reasons
some concerns about implementation all around
TabAtkins: We have elementsFromPoint() already, regardless need to be
able to get at that list
stearns: For pointer-events: none, still need to have that info as well;
that requires one answer, this case needs the whole stack
TabAtkins: For the case that should hop through the fragment order,
should that just be a generic box order movement?
TabAtkins: Anything else outside fragmentation would also affect that
stearns writes out options
1) Fragment container insertion
2) Painting order switch
stearns: for #1, issue of where to put the fragmentation container in
the order
stearns: Painting order switch is more general, works for other positioning
things as well, also works for any type of fragment container
TabAtkins: Do have to define that the event path includes fragment containers
TabAtkins: So can't lean on that concept entirely
fantasai: We don't have those yet
TabAtkins: So, suggesting go with paint order one for now, possibly also
introduce box tree
plinss: what's diff between paint order and box tree?
TabAtkins: paint order just go through layers under that point
TabAtkins: box tree would jump from element to its containing block,
not hit things underneath it necessarily
Rossen: ...
Rossen; Final transformed position, thus actual behind element is the
furthermost ?
Rossen: Subtle difference, but makes a difference once you factor in
transforms
Rossen: and relpos I guess
TabAtkins: Fine with leaving out box-tree
asking about who implements elementsFromPoint()
krit: Suggested couple months ago, not sure that anyone implements it
dbaron: Don't see it in CSSOM or CSSOM View specs
...
stearns: So if I'm reading the room correctly, people leaning towards
pointer-event switch
<Bert> (Other issue: If '::foo' is a region, then '::foo:hover' would
be the expected synntax to select it in hover state... but that
syntax is not allowed by css3-selectors.)
Bert raises issue against Selectors 4
::first-line:hover e.g. makes sense, and would work
::first-line:nth-child() doesn't make sense
fantasai points out that each pseudo-element has to define what it accepts
Bert points out that we need to define which selectors are invalid
(cause selector to be thrown out) and which simply don't match anything
* glazou would say that ::first-line:nth-child() is not a problem since
a visual line has no children so it selects nothing… we don't
need to make it invalid
</aside>
dbaron: This is pretty scary, don't think we should make a change without
checking with WebAPI folks
RESOLVED: Work on pointer-events: elements-from-point solution that will
walk the elementsFromPoint chain instead of the ancestor chain
Shapes
------
stearns: One of the issues...
stearns: Shapes specification
stearns: Whether we should allow shapes from rendered content
stearns: Think we should, but would like to push it to level 2
<plinss> http://www.w3.org/mid/CDD64C22.3AD08%25stearns@adobe.com
stearns: CSS Shapes atm defines getting shape from an image, and from
shapes from basic shape syntax, and I think that is sufficient
for first level
stearns: already pushed off SVG elements. Would like to push off rendered
content for now.
dbaron: what is it?
<Rossen> http://lists.w3.org/Archives/Public/www-style/2013May/0389.html
stearns: E.g. you have an A rendered large, or repeated background, etc.
stearns: I think it's useful thing to do, but very complicated
Rossen: Think original motivation for that was around time when we were
proposing shapes to begin with. One of the use cases was a type
of article that becomes a shape
Rossen: extracting shape from rendered text
Rossen: drop-cap, with tight-wrap around it
Rossen: That was original motivation. Agree it's advanced feature for
current level of spec
Rossen: If we want to move spec quicker and have big bang for our money
Rossen: Having simpler shapes, easy to define
Rossen: That would hold implementations for quite some time.
fantasai: Makes sense to me. I would prioritize SVG shapes over this feature.
TabAtkins: me too
stearns: Any objections to moving this over?
plinss: Images?
stearns: No, they stay. That's biggest ask aside from SVG
dino: At what resolution do you derive the shape?
...
stearns: We'll solve that as we get to it
...
dino: You might have an image that's displayed 100x100 but it's 10000x10000
image, as you zoom you see more pixels, shape might change and suddenly
impact layout
TabAtkins: other changes due to not aligning to pixel boundaries too
dino: Need to define exactly the operation you use, masking whatever
stearns: agree
liam: Could get almost effect of text-wrapping around A, by making path
in SVG and wrapping around it
stearns: could make polygon with basic shape syntax
stearns: Aren't guaranteed to get the glyph you're expecting, though
stearns: Other issue, in spec, that says ...
krit: ???
RESOLVED: Move contours from rendered content to next level
stearns: Issue on spec on shapes from images
stearns: Security concern of being able to determine contours of alpha
channel of image
TabAtkins: Could extract cross-domain info
TabAtkins: Reasonably efficient attack, too
plinss: Imagine image you're putting in page is bar graph of your account
balances of your bank
Same-origin or CORS
TabAtkins: Work with Anne, he'll tell you what to do correctly.
<dbaron> annevk is working on http://fetch.spec.whatwg.org/ which makes
these things easier to define
Scribe: TabAtkins
krit: Same-origin may not protect you if open redirectors are used.
TabAtkins: That is always a concern for *everything* that's SOR.
dino: I'm not sure SOR is enough.
dino: [describes an attack that scribe didn't understand]
stearns: You're assuming that a site is wrapping content around a secure
image.
dino: I'll describe the scenario better in the mail list.
krit: For SVG images, that's one of the reasons SVG images aren't allowed
to reference images from another domain.
TabAtkins: The SVG issue is different. That's about being able to detect
when an image is viewed, by including an external ref in that
image.
krit: It's a different attack, but same scenario.
[please describe the attack better]
stearns: New topic. The idea is that we should add floats to exclusions,
so we have one way of wrapping things around each other.
stearns: I propose we don't. Floats work within the wrapping context,
and are their own crazy thing.
TabAtkins: Does that mean we lose the "exclusions can auto-avoid eac
other" switch?
stearns: No, this is unrelated.
Rossen: The two things are kind of disjoint...
stearns: No, they're disjoint. They work differently - it's defined in
the spec.
Rossen: Inline content at the same level as the float will avoid both
floats and exclusions, but exclusions penetrate much higher.
Rossen: So they really are disjoint in terms of geometry, and in the
stack they have different behavior.
Rossen: So keeping them separate is way easier. From an impl point of
view, I approached keeping them together with floats, but it
started becoming a mess quickly.
Bert: Is this just an impl issue?
stearns: No, spec issue. The spec says how to construct the wrapping
context.
stearns: The spec defines that floats create areas that content avoid.
stearns: Question is to keep that, or to try and fully harmonize floats
with exclusions so they act identically (rather than just similarly).
Rossen: It will hypothetically allow you to have an impl with just exclusions,
no floats.
Bert: If you can explain how they'd behave differently, it would be
appreciated.
stearns: In the wrapping behavior, they behave the same, for a single
float and a single exclusion.
RESOLVED: Close the float/exclusion harmonizing issue.
Exclusion wrapping context does not include floats.
Meeting closed for the day.
Received on Wednesday, 3 July 2013 00:24:49 UTC