- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Oct 2014 16:39:57 -0400
- To: www-style@w3.org
Line Grid
---------
- RESOLVED: publish WD of line-grid
CSS UI
------
- RESOLVED: add 'caret-color' to css3-ui
- A desire to color the background/foreground of selected text
lead to a conversation about bringing ::selection back and
potential issues with exposing security-sensitive items (such
as spell-check)
- RESOLVED: Add ::selection to Pseudo-elements 4
- RESOLVED: Outline corners follow border-radius (no additional
outline-radius property needed)
Geometry Working Draft
----------------------
- RESOLVED: Publish working draft for geometry interfaces
z-index and SVG
---------------
- RESOLVED: The root SVG element automatically creates a stacking
context, as does <foreignObject>.
- RESOLVED: SVG elements honor z-index automatically (like flex
items), without requiring 'position'
Prioritizing image(color)
-------------------------
- image() function is undergoing edits for Level 3
randomize()
-----------
- RESOLVED: Not pursuing randomness at this time.
Animation and calc() of Keywords
--------------------------------
- There is generally high interest in animating to/from keyword
values, but that means the keywords must be acceptable within
calc(), which presents behavioral complications for many keywords
- Krit will investigate implementer interest and draft up a
preliminary whitelist of keywords that could be included in
calc().
- The question of why calc() doesn't have min/max functions was
re-answered.
==== FULL MINUTES BELOW ======
Scribe: Bert
Line Grid
---------
<astearns> http://dev.w3.org/csswg/css-line-grid/#change-log
astearns: Mainly I took things out.
astearns: I think we should publish with these changes I just
linked above.
Several: No objection to publishing
fantasai: What about the value names for navigation?
astearns: I'm happy to discuss the names, but maybe not hold up
publication.
fantasai: Yes, we renamed to start/end elsewhere. We should do
something similar here.
RESOLVED: publish WD of line-grid
<fantasai> old draft:
http://www.w3.org/TR/2014/WD-css-line-grid-1-20140403/#box-snap
<fantasai> none of the values are in common except none
CSS UI: caret-color
-------------------
andreyr: We have been using webkit for the terminal.
andreyr: We'd like to control the color of the caret.
fantasai: There is interest in coloring the caret.
fantasai: There should be something like 'cursor-color'.
glazou: And what if you set color on a cursor defined as an image?
dbaron: Caret and cursor are not the same
andreyr: Yes, I mean the caret.
andreyr: Orange is great.
TabAtkins: 'caret-color' is fine.
andreyr: We have a patch for chromium.
hober: In the existing css3-UI thread,
hober: Tantek has the notes for this in the planning page, but
there hasn't been any edits to any documents
hober: Lea raised something. Tantek has some notes for it in UI
planning page.
hober: So, where would this live?
hober: Where would this go?
fantasai: css3-ui (which is bit of a mess right now...)
<Clilley> how is caret different to cursor: text?
Clilley: How is the caret different from the text cursor?
TabAtkins: The cursor is the I-beam.
TabAtkins: The caret is the editable point in the text.
fantasai: It's the one that blinks :-)
hober: If you have text in several colors, caret should reflect
that as it moves along the text.
hober: 'invert' is suboptimal for that. Take the case with
compositing.
hober: I'm not enthusiastic about implementing 'invert'
TabAtkins: 'invert' still fails on gray, anyway.
hober: Yes, something with invert only after a threshold...
hober: And the case of two authors, author of content and author
of content-editable thing, one doesn't know the color of
the other.
RESOLVED: add 'caret-color' to css3-ui
CSS UI: styling selections
--------------------------
andreyr: I'd also like to set foreground/background of selected
text.
glazou: We proposed ::selection for that.
fantasai: We all want it, we had it at some point.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
dbaron: I did half of the required analysis. Most engines have
some sort of selection feature.
dbaron: I listed five requirements and three solutions. But I
didn't do enough testing.
dbaron: I think that not all implementations meet the five
requirements.
dbaron: A useful next step would be to test what implementors do.
fantasai: And andreyr wanted to propose equivalent selections for
highlighted spelling errors.
dbaron: Different DOM selections can maybe be associated with
particular styles.
TabAtkins: A style without the need to put in a SPAN.
hober: A DOM range.
Scribe: fantasai
glazou: Is this related to what we discussed earlier about
selecting non-elements?
fantasai: No, it's different,
dbaron: This is an extension of ::selection, where you could
associate a DOM range with a name, and select (in the same
way as ::selection) based on that DOM range
dbaron: Want to create it using ranges, then create styles for
this.
dbaron: The styling would work the same as ::selection, so it's a
limited set of things.
hober: I love this idea.
glazou: Me too.
TabAtkins: If we ever explicitly expose browser spell check, it
could need to be restricted even further.
TabAtkins: That's because of concerns with regard to exposing user
dictionaries.
dbaron: It would expose user's language and also user's dictionary.
Andrey: The problem is that color of underline is hard-coded and
we want to change that
dbaron: Once we solve for ::selection, we will be most of the way
through solving for multiple selection. Though there's a
few more issues.
hober: I imagined that I wrote an email for a similar thing, but I
might not have actually written it...
hober: It was a proposal for creating identified DOM ranges and
syntax to select it
* glazou loves it
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=256773
fantasai: Andrey's immediate problem is changing the color of
squiggly underlines; can we do anything about that?
<fantasai> ::spelling-error { text-decoration-color: orange; }
fantasai: Would that be something that we can do?
hober: You shouldn't be able to discover this style by checking.
zcorpan: There's spelling errors, and also spelling suggestions.
plinss: An extension mechanism should also be able to handle
spelling and grammar check, etc.
TabAtkins: Things that are security-sensitive need to be built in.
TabAtkins: If they're using information not available to the page,
you can't build into the page.
TabAtkins: That's why I said spell check; if we want customization
of it, it has to be built-in.
hober: Or you build your own.
dbaron: Gecko currently has 9 different types of internal
selections.
<dbaron> (FWIW, Gecko has 9 different types of custom selection,
listed at
http://hg.mozilla.org/mozilla-central/file/2255d7d187b2/content/base/public/nsISelectionController.idl#l23
TabAtkins: Wasn't there talk of exposing find to the page?
TabAtkins: Ignoring url secondary (we don't know what it is),
doesn't seem like any others need to be security-
sensitive.
fantasai: IME stuff might also expose user dictionaries.
fantasai: Aren't there 2 finds? One you're on currently, and
others on the page?
glazou: Should we resolve to add ::selection back? Who's going to
work on it?
hober: Which spec should this be in?
fantasai: Pseudo-elements Level 4
fantasai: Should probably have L4 just be this and the L3 pseudos.
Do fancy extra stuff in L5.
dbaron: I'm happy for adding an issue to the spec.
Rossen: Stuff is happening in WebApps for selection
<Rossen> http://w3c.github.io/editing-explainer/
hober: Editing Task Force.
Rossen: Efforts in that direction are toward defining most of the
things that we actually want, from what I'm hearing.
Rossen: Not sure how much overlap there is.
Rossen: Would be good to sync up with them.
Rossen: Wouldn't expect us to define ::selection
fantasai: We don't define what is selected, but define how the
styling works.
RESOLVED: Add ::selection to Pseudo-elements 4
glazou: So who is working on this?
glazou counts astearns, fantasai, andreyr
CSS UI: outline-radius
----------------------
<andreyr> https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-outline-radius
andreyr: Mozilla has it implemented, no one else does.
dbaron: We agreed at some point that we didn't want this property,
just wanted outline to follow border-radius
dbaron: The spec says that's what should happen.
dbaron: We have a bug on dropping outline-radius and implementing
what the spec says, but haven't gotten around to it.
krit: The default implementation uses outline of the operating
system.
krit: It might not be able to allow border-radius.
krit: So this would only be for styled outlines, e.g. said it
should be solid red.
krit: Focus-ring and outlines are basically the same thing.
<fantasai> http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines
Rossen: We don't have such limitations in Windows, but I can't
speak for others...
fantasai: CSS3 UI doesn't say anything about border-radius.
fantasai: So if we want that behavior, we need to add it to the
spec.
fantasai: I agree that makes more sense.
dbaron: Definitely we discussed this before. I brought up
outline-radius, and people said it should just follow
border-radius
fantasai: So do implementors agree they want to do this?
fantasai: Make inner outline radius match border-radius?
Rossen: Trying to think if there's fragmented inlines, I'm unsure
what should happen in that case... but I do want to match
border-radius.
krit: Might need to account for
http://dev.w3.org/csswg/css-ui/#outline-properties
krit: Outline-offset
hober: I agree we should do this. If there's a problem, bring it up
dbaron: If anyone does this for Gecko, we will have to go through
our existing uses of outline-radius, and will find out if
there's reasons for wanting something different.
krit: Might possibly want rounded outline for square border-radius.
hober: Maybe need some text with regard to default outline
matching system conventions, which may or may not match
border-radius?
fantasai: In cases where outline is just outside border, it should
match the border.
fantasai: For buttons, e.g., focus outline is around just the text
sometimes, not the button shape, in that case could say
whatever that thing is that is surrounded, it has a
border-radius.
andreyr: Mozilla had it. I was hoping that others would implement.
fantasai: Now you can just say that "your behavior is wrong,
here's a patch"
fantasai: Mozilla wants to drop outline-radius and just follow
border-radius
<dbaron> Is outline-radius expansion the same as box-shadow spread
expansion?
gregwhitworth: Do we have any author feedback on this?
ACTION: glazou Ask authors for feedback on this
<trackbot> Created ACTION-635
RESOLVED: Outline corners follow border-radius (no additional
outline-radius property needed)
[lunch break]
Geometry Working Draft
----------------------
Scribe: andreyr
<krit> http://dev.w3.org/fxtf/geometry/
krit: First up, geometry working draft
krit: The main feedback was there shouldn't be interfaces which
are described as magic
krit: The feedback was to create constructors.
krit: Read-only interfaces have constructors now.
krit: Any objections?
krit: Comments?
dbaron: I worry it might be confusing where some properties are
writable and some are not
dbaron: Did the original proposal have these?
krit: The spec has not really changed.
krit: We would like to have a working draft.
krit: It's intended to have constructor defined in the spec.
RESOLVED: Publish working draft for geometry interfaces
Stacking context within SVG
---------------------------
krit: We would like to have feedback making SVG elements embedded.
<TabAtkins> :not(svg|*) > svg { stacking-context: new !important; }
<zcorpan> :not(svg|*) > svg|svg { stacking-context: new
!important; }
Scribe: fantasai
[discussion of display property applied to SVG, problem with
backwards compatibility due to people applying random other
display values and it having no effect]
Bert: z-index applies then, don't need to set position: absolute?
TabAtkins: Correct.
[Discussion is that SVG automatically creates stacking context.
Also that SVG allows z-index without requiring position:
relative.]
[Clilley asks about foreignObject]
* fantasai missed the answer
Clilley: <foreignObject> should also create a stacking context,
and shouldn't intermix with other SVG things
RESOLVED: The root SVG element automatically creates a stacking
context, as does <foreignObject>.
RESOLVED: SVG elements honor z-index automatically (like flex
items), without requiring 'position'
Rossen: Grid automatically creates a stacking context for grid
items.
fantasai: I thought that was a pseudo-stacking context.
fantasai: For SVG elements, it should be full stacking context.
Think grid/flexbox is pseudo-stacking.
<fantasai> http://dev.w3.org/csswg/css-flexbox/#painting
Rossen: With regards to performance concerns of stacking context
in SVG...
Rossen: People might use that a lot. It might result in creating
too many stacking contexts.
krit: We have CSS properties that create a stacking context. Some
of them, like transforms, are used very commonly in SVG.
krit: So we resolved that properties like transform don't create
stacking context unless 3D.
Rossen: Should we do the same thing with z-index?
...
Rossen: Then we're good.
Prioritizing image(color)
-------------------------
krit: image() function
krit: We had lots of discussion with regard to image() function,
syntax thereof, responsive images, etc.
TabAtkins: We have that already.
fantasai: What's in Images 3 is a superset of that at the moment.
We're going to strip it down.
randomize()
-----------
Tab leads discussion on selecting random values from a list.
fantasai: Is that like cycle(), except non-deterministic?
[Tab writes on the board]
[We discover that the board doesn't erase.]
[Tab finds another board]
[Which also doesn't erase]
[We find some paper, which doesn't erase, but there are multiple
sheets]
TabAtkins writes:
@random foo
red, blue
random-color();
TabAtkins: This is a random generator. It'll first try to exhaust
its list. Then it'll generate from the generator.
TabAtkins: If I write el { color: random(foo); }
TabAtkins: Do I get a brand new color for every single element? Or
a color that changes over time?
TabAtkins: Need to specify when the randomness is applied.
TabAtkins: Options we consider so far are per-element or per-rule.
dauwhe: Why do we want to do this?
hober: My use case is that I want to make a really ugly web page.
krit: It's for abspos, want randomly-positioned items.
Rossen: If the only use case is sprites, one line of JS is a good
enough solution.
TabAtkins: If we are going to do random, should be something like
this, and need to be able to say when randomness is
applied.
Rossen: What about interoperability testing?
TabAtkins: Dunno, we might want to be able to specify seed.
florian: Is this stable across page loads?
fantasai: I think I'm with Rossen, this should be solved with JS
for now.
hober: It's already possible to make really ugly webpages, so my
use case is already solved without this.
plinss: Is this solve-able right now in JS?
TabAtkins: Yes.
TabAtkins: For per-element, alter .style of the elements; for
per-rule, alter the rule in the style sheet.
krit: So what's feedback?
various: Need more use cases to justify something this complicated
for something so simple to do in JS
RESOLVED: Not pursuing randomness at this time.
plinss: We will pursue it at some random future date.
Animation and calc() of Keywords
--------------------------------
* krit <shape-radius> closest-side/furthest-side and calc()
krit: Got request for shape-radius to have half of farthest-side/
closest-side keyword
krit: Would like something like calc(farthest-side/2)
krit: And would like to be able to animate that.
astearns: Can we do keywords in calc()?
TabAtkins: Not yet. But rejecting the white space change request
at last F2F makes it easier to do.
TabAtkins: These become lengths.
fantasai: So does auto keyword for width.
fantasai: But the lengths aren't the computed values.
TabAtkins: Can't do a transition on it, but could you do a calc on
it.
fantasai, dbaron: If you can do a calc() on it, then you can do a
transition on it.
fantasai: We know we want to do this. We've discussed it before.
We deferred it from css3-values because it's complicated
implementation-wise.
fantasai: Right now, you can implement calc() as a tuple of
absolute length and percentage.
fantasai: If you allow keywords, which have to be maintained as
keywords, you need to store calc() as an expression.
TabAtkins: So is the implementation work feasible? Because that is
what is stopping us.
krit: Expanding data structure should be straightforward
dbaron: The data structure is the easy part.
dbaron: You have to also modify other things to handle, e.g. all
things that handle input of 'auto' to handle input of
'auto' with calc()
fantasai: Have to consider, e.g. for height of 'auto', have margin
collapsing, but non-auto have no margin collapsing, what
do you do with calc involving auto?
TabAtkins: Might be hard for auto.
plinss: Do we want a whitelist or blacklist?
Rossen: Probably want a whitelist
fantasai: Whitelist isn't per-keyword, it's per keyword-property
combination.
fantasai: Going to have to modify propdef table again. Though I
suspect animate-ability, computed value, and calc()-
ability are closely related and could be compressed down.
fantasai: So, what action do we give krit?
TabAtkins: Make sure implementations are willing to do this.
fantasai: And maybe come up with the whitelist.
TabAtkins: I want to also see if we can come up with generalizable
rules.
TabAtkins: Would Firefox be interested in doing this, if we
whitelist some keywords?
dbaron: Yes, just depends on prioritization.
fantasai: There was also min()/max(), which had complications. Are
those complications related?
dbaron: No, it's different.
dbaron: For example, if you have a div that has a 200px-wide image
inside it, and has margin-left: 50%
dbaron: The div's parent might, depending on other things, have an
intrinsic width of 400px depending on other things
dbaron: You say this div needs to be 50% + 200px wide, so the
total has to be 400px.
dbaron: That inversion of logic depends on being able to say that
"this element has a length of 200px+50%".
dbaron: Once you have a min or a max that has a length on one side
and a percentage on the other.
dbaron: Then you can't do that.
dbaron: This happens most often in table layout, though there are
a few other cases.
dbaron: I think this was the issue that made me give up on min/max
dbaron: The percentage and length thing, you can use a length and
a percentage where, essentially, if you have something
that is 50% plus 200px,
dbaron: If you graph the percentage basis against the result.
dbaron: This is some monotonic line.
dbaron [draws graph of basis (x) time result (y) line goes from
200px at zero upwards]
dbaron: With min/max you can have any continuous and piecewise-
linear line
[draws a zigzag]
dbaron: You might find more than one solution, or none.
dbaron: Maybe we need to go back and define table layout and what
you do here.
dbaron: Or maybe not, just say we don't care...
dbaron: I think that was the main issue with min/max
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html
[quick look at css3-values to see if any other issues for
discussion, no not really]
Received on Monday, 13 October 2014 20:40:25 UTC