- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Jan 2015 06:42:37 -0500
- To: www-style@w3.org
May F2F
-------
- RESOLVED: Meet 18, 19, 20 of May in NYC hosted by Bloomberg
- Everyone received an action to post topics for the meeting in
Sydney.
Pseudo-Elements
---------------
- RESOLVED: Publish with the draft as-is, noting that what's there
for the OM is just some ideas as a starting point for
discussion.
- RESOLVED: keep ::grammar-error and ::spelling-error in the draft
- RESOLVED: Publish FPWD of CSS Pseudo-Elements
- fantasai will put her proposal for having descendants of
p::selection inherit style into the spec.
Flexbox
-------
- Everyone received an action to review the wiki tracking Flexbox
accessibility concerns created by bcampbell in order to
discuss it next week. The wiki is available here:
https://wiki.csswg.org/spec/css3-flexbox/accessibility
CSS3 UI
-------
- RESOLVED: we intend 'auto' to cover behaviors that can't be
described by other styles in the UA style sheet, and
we want to define it more precisely, but we need to
work out on the list what that definition should be
- There didn't seem to be much interest in implementing ::value
and ::choices in the near future from implementors, however
the group will wait on a formal write-up for ::placeholder
before deciding on if ::value and ::choices should be moved to
pseudo-elements.
===== FULL MINUTES BELOW ======
Present:
David Baron
Rik Cabanier
Bo Campbell
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Dael Jackson
Brad Kemper
Vivien Lacourba
Philippe Le Hégaret
Edward O'Connor
Simon Pieters
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Ian Vollick
Steve Zilles
Regrets:
Tab Atkins
Adenilson Cavalcanti
Alex Critchfield
Chris Lilley
Michael Miller
Shinyu Murakami
Keshav Puttaswamy
Greg Whitworth
Scribe: dael
May F2F
-------
glazou: Let's start.
glazou: I'm sorry about the agenda today. As I said, the events in
Paris disrupted the work day. The emotion in tremendous.
glazou: Back to the message I sent before, there were two things
to discuss. The date of the May meeting, we need to
resolve on that. As I said from the outline, the number of
seats on planes is declining in Europe because it's a
vacation week.
glazou: We resolved to have it in NYC between 18-22 May hosted by
Bloomberg, but we don't have exact days. andrey are you on
the call?
glazou: Let's wait on him, but we can say if we have blockers or
preferences on days. I prefer the first three days of the
week.
glazou: Other people?
<astearns> no preference
dauwhe: First 3 days is fine.
glazou: People flying from CA?
dbaron: I'm happy with beginning because it's closer to the AC
meeting.
glazou: No objections if we resolve on first three days? Andrey
said he was booking a room for the whole week
<SteveZ> +1 for first 3 days
<Bert> (Not sure I can come: Also WWW2015 the same week...)
RESOLVED: Meet 18, 19, 20 of May in NYC hosted by Bloomberg
glazou: The 2nd item...oh Bloomberg just connected.
glazou: We suggested to have the main meeting 18, 19 20. Is that
okay?
andrey: Yes.
glazou: Wonderful. Let's consider it closed.
andrey: I'll have room for 30 people. Is that enough?
glazou: I think so. It might limit observers.
glazou: Let's set up the wiki ASAP and we'll see how it goes with
that number.
glazou: We'll need hotel recommendations from you.
andrey: Sure.
glazou: Second thing is an action on everyone, we need agenda
items for Sydney for CSS and Houdini. Please go to the
wiki and add items.
<fantasai> https://wiki.csswg.org/planning/sydney-2015
glazou: Now I'm ready for whatever people want to discuss.
glazou: I think fantasai wanted something and Florian said
something about CSS3 UI.
Florian: I have a bunch on that and one on Selectors, I have a lot
so I don't want to take all the time.
Pseudo-Elements
---------------
fantasai: There's a couple of things. One is the OM section, do we
want FPWD with that in and do we want an issue or note
about the status of that and we're not sure if it's
right. I'd like to know what to do with the OM section.
fantasai: There's one or two more issues.
<BradK> Link?
<fantasai> http://dev.w3.org/csswg/css-pseudo/#cssom
<BradK> Thanks
glazou: The OM section...the OM of CSS I think we're going to
discuss during the Houdini meeting. It seems there's a
concern about the state of what we have now and we want to
revamp it.
astearns: There's already an issue in the section.
glazou: And it's a FPWD anyway, so it's harmless to put it there.
fantasai: So put in the OM section and make it clear it may be
changed.
fantasai: Usually with a WD we think we're going in a direction,
but we're not sure at all.
RESOLVED: Publish with the draft as-is, noting that what's there
is just some ideas as a starting point for discussion.
<fantasai> http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
fantasai: So the ::spelling-error/::grammar-error, did we want it
in the draft, or not? There was no resolution at TPAC.
tantek: I think ::selection should be in the draft, absolutely.
There's been a lot of demand for it.
fantasai: ::selection will be for sure; it's the main reason we're
publishing this draft. Do I include ::spelling-error
/::grammar-error
<andrey_r> I was asking for these to be included.
glazou: In the words of the Mozilla editor there have been a lot
of requests to style spelling different. Grammar I don't
remember as much, it's a lot harder to do, but I think
putting it in the WD will make people think about it.
tantek: I agree.
tantek: I think I'm in favor, I think it's important in an early
version of the draft.
tantek: What about the security concern?
tantek: It's based on what's in the dictionary.
fantasai: There's a section on the security issues that I added at
TPAC.
<fantasai> http://dev.w3.org/csswg/css-pseudo/#highlight-security
fantasai: [reads from spec]
Florian: I'm happy to have that in.
glazou: So any objections against keeping these two
pseudo-elements in the spec?
RESOLVED: keep ::grammar-error and ::spelling-error in the draft
fantasai: The wording in selectors is problematic because it's in
a note. It also is...the wording is slightly different
and we should figure that out on www-style. I'm not sure
the same wording would make sense.
tantek: It sounds like there's a general concern about user info
leakage and that might merit it's own section.
fantasai: They're in two different specs.
tantek: Up to you, then. Your choice.
fantasai: I'll note they should align.
fantasai: Right now I'm using must, for visited it's may.
dbaron: For visit it was backwards compat issues.
tantek: I'm happy with must.
fantasai: And it's more of a security problem.
glazou: Not just the address book, but words specific to your work.
fantasai: Or even some confidential information.
glazou: Anything else on this?
fantasai: I'd like to publish FPWD.
glazou: Fine by me.
tantek: Yes, absolutely.
RESOLVED: Publish FPWD of CSS Pseudo-Elements
glazou: Anything else fantasai?
fantasai: I think that was the only thing. There's another issue
on pseudo-elements since we're here.
fantasai: Let me pull the e-mail.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2015Jan/0053.html
fantasai: If you style p::selection and you have a descendant, the
text inside the descendant doesn't get styled in 3 of 4
rendering engines. I wrote the spec assuming it would
receive the styling because I think that makes the most
sense. There's a test case link.
<fantasai> data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A
<style>%0D%0Ap%3A%3Aselection { background%3A rgba
(0%2C255%2C0%2C0.5)%3B
<fantasai> }%0D%0A<%2Fstyle>%0D%0A<p>Test me <em>and me<%2Fem>.<%2Fp>
fantasai: This would require the browsers to change their
implementations. I'd say hold off until we figure out
exact inheritance, but I want to make sure the WG is
okay to fix it.
<dbaron> I agree we should fix the behavior.
<BradK> Me too
<BradK> But I'm not an implementor
glazou: The only thing I'm concerned with is I'm not sure if it's
consistent on web author expectations. I agree the em in
your e-mail should receive the style of the p in your
e-mail case.
glazou: dbaron agrees we should fix. Other browser vendors?
Google, Apple, Microsoft?
smfr: For Apple I'd have to ask David Hyatt.
glazou: Google? Microsoft?
<zcorpan> there was a reply from rune about what Presto does
http://lists.w3.org/Archives/Public/www-style/2015Jan/0061.html
* sgalineau can't imagine how an author would not consider this a
bug
<tantek> agreed
* leaverou sgalineau yup, this is definitely super confusing for
authors if it doesn’t get fixed
<sgalineau> leaverou: they might just not use the feature as a
result.
<leaverou> sgalineau: nope, they will, but with complicated
selectors to involve every descendant (like
p::selection, p ::selection)
<sgalineau> leaverou: yes, some will go to great lengths. others
will just decide it's not worth the pain.
<leaverou> sgalineau: it’s not that huge of a pain. It's mainly
the confusion for authors that don't know it that
should be a concern.
<sgalineau> leaverou: I'd get frustrated if rearranging my markup
a little broke my selection styling. but then I'm lazy.
<leaverou> sgalineau: yup, I didn’t disagree on that. Unless
someone is aware of the peculiarity, it’s frustrating
and confusing
<tantek> would p ::selection help?
<tantek> is this an examples thing?
<zcorpan> tantek: you would need to do p::selection,
p ::selection {} but it could get messy. suggestion is
to make p::selection {} DWIM
glazou: Is it okay for everyone if fantasai puts her proposal in
the spec and we come back to it later?
glazou: I think her proposal is the one that makes sense.
glazou: Any objections to that?
glazou: Let's do that. Let's change the behavior and make it more
author compliant.
fantasai: I think that's all I have on pseudo-elements. I'll
prepare the FPWD if Bert will help?
Bert: I won't be able to publish next week. Maybe ChrisL is
available.
fantasai: I'll ask around.
* plh can help if needed
glazou: plh can help. Thanks plh.
<dbaron> fantasai, has the spec for ::selection defined the
underlying model, or is it more vague still?
<fantasai> dbaron, it's pretty explicit, but I'm unsure if it's
well-written or correct
Flexbox
-------
glazou: I had Florian has CSS3 UI. Anything else?
bcampbell: I've been doing research on Flexbox still for break.
<bcampbell> https://wiki.csswg.org/spec/css3-flexbox/accessibility
bcampbell: I created a wiki for the arguments. fantasai was nice
enough to talk to me a lot. I've been talking to IBM.
I'd like to start a discussion on the e-mail and come
back to it.
bcampbell: What I wanted to bring up was I was hoping people would
keep it on their radar so we can get the comments
gathered for next week.
glazou: Let's do an action item.
ACTION everyone to review
https://wiki.csswg.org/spec/css3-flexbox/accessibility
glazou: What else, or shall we move to Florian?
tantek: Anyone else having problems with the new repository?
dbaron: Fine for me, too.
tantek: Okay. I'll follow up.
CSS3 UI
-------
Florian: I'll work off of who is here. Is TabAtkins here?
[silence]
<Florian> cursor:auto (ISSUE 48)
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0531.html
Florian: This is from dbaron. It's specifying rather than the
universal "do magic" with auto.
dbaron: The reason auto is needed is that generally browsers want
a pointer over not-text and an I-beam over text. Since
those are often in the same element we need a value that
switches and auto has historically done that interoperably.
dbaron: The original auto was so ill-defined it seems that
everything browsers did with a cursor was under auto.
Rather I think what can be in the UI style sheet should be
there rather than all magic in the auto value. I'd rather
auto is just pointer or I-beam.
glazou: There's a third for auto which is links.
dbaron: That can be in UA style sheet
glazou: Okay, fine.
<dbaron> Gecko only has 'auto' switch between pointer and the text
cursors and does other things in the UA style sheet.
<BradK> User-select:none on text should also prevent the automatic
text cursor
Florian: It makes sense to me and I'm in favor of this. We have to
resolve what it means to switch between vertical and
horizontal. I have some suggestions on this.
fantasai: For switching between vertical and horizontal, that
should be automatic unless we want to add a horizontal
text cursor and vertical text keyword.
Florian: We have both, but auto is switching between those things.
dbaron is proposing that we use auto to switch between
only those two things. So the question is if we should, I
have a suggestion for how.
fantasai: That makes sense to me.
fantasai: What happens if you have a resizable element and you're
on the border? If we only switch between these cursors,
does that mean we don't get a resize cursor?
dbaron: I have to look, but it's possible we should include it.
The case where we've gotten bug reports is authors look at
the spec and auto on a form control should mean the form
control cursor and on a link the link cursor. I think we
should say what switching is a part of auto.
dbaron: I'm probably not going to get an answer for resize in less
then two or three minutes.
<SimonSapin> +1 for specs being explicit
<tantek> I agree with specs explicit however I'm not sure we have
good explicit language to put in yet.
Florian: Maybe the resizing behavior is somewhat independent if
you specify a cursor other than auto you may still and
resize. I'm not sure on this one.
<dbaron> fantasai, I think we have the last two but not
auto-text-cursor
<fantasai> "User agents may automatically display a horizontal
I-beam/cursor (e.g. same as the vertical-text keyword)
for vertical text, or for that matter, any angle of
I-beam/cursor for text that is rendered at any
particular angle. "
fantasai: My concern is we have the resize. There's other things
that could happen like a UA has a button that changes
what you can do to an item and therefore the cursor,
like if you hold control it's a hand.
<tantek> agreed with fantasai concerns
Florian: That should be doable with normal mechanisms overriding.
fantasai: So the CSS cursor changes if you hold the control key?
Florian: A UA that could change through the style sheet. Why not?
<tantek> depends what you're hovering over
<tantek> or if you're dragging
dbaron: I think the question is if the UA has that, do they want
it to not show if the author chooses cursor and I think no
in which case you're selecting a mechanism outside CSS.
<tantek> Isn't that the magic of auto?
fantasai: I'm just not sure if everything a UA wants to do can't
be done through the style sheet. If it's out of scope it
might be completely expressible.
<tantek> yes, that ^^^
dbaron: If there's other things that need to be here we should list
them. I don't think auto should be magic.
smfr: Looking here we may use the hand or the text input as a
pointer.
Florian: If the cursor isn't there do you still show the resize?
smfr: It looks like we don't.
dbaron: I suspect Gecko has some sort of anonymous content that
has a cursor style on it for the resize handle.
tantek: I'm okay with specifying more details on auto, but I don't
feel like we understand. There's some cases that aren't
covered.
<BradK> *:dragging { cursor: hand; }
dbaron: That's fine. We should define what it covers, not imply it
covers everything that's in the UA style sheet. We don't
need to define on the call.
Florian: There's another item where if auto can switch between
vertical and horizontal, there's also the diagonal. Does
it do that?
fantasai: Text says UA can display horizontal for any text that's
rendered at any angle. So the text says you can, so I
don't know why you wouldn't.
Florian: Right, it's just that no one does that right now.
dbaron: I think that's a recent edit to the spec.
tantek: I think that's been there for a while.
tantek: It's been there for a while.
dbaron: Recent in relation to the change in cursor implementation.
<dbaron> ok, it changed between the 2003 LCWD and the 2004 CR.
There were definitely drafts that described vertical-text
and text as both fixed, though (i.e., prior to the 2004
CR)
tantek: I think the point in IRC earlier is that we don't have an
explicit horizontal.
tantek: I think it was added because people were doing it. If you
want to discuss deprecation, that's another discussion.
Florian: dbaron suggested on the list about having a switch. I
don't remember exactly what he said, but if we should
have a switch it should be possibly rounded to 90 degrees.
That's the baseline, what we're after.
Florian: Do we have anything we can resolve on?
Florian: Is there a resolution we want to get out of this?
fantasai: I'm not convinced we need vertical either, but it's
there.
Florian: We could have auto means auto-magic everything or we have
auto may be a lot of things, but we define what they are
and how they work and how to switch and everything else
in the UA style sheet.
tantek: The point of auto is I want to set this back to what it
was before I said anything. So it needs to be what the
author expects.
dbaron: We don't have that for other properties, though we've been
talking about having it. I don't think we want to solve it
with this.
fantasai: We had the 'default' keyword in Cascade to do exactly
that for all properties, but implementors asked us to
remove it.
zcorpan: I agree with dbaron that what can be expressed in the UA
style sheet shouldn't be a part of the auto keyword.
tantek: I'm trying to understand the reasoning. I'm from the
author prospective where I want it like it was before I
touched it.
Florian: This is a general wish for CSS, not a specific one.
tantek: When that's changed we can address this, but we have
interoperability.
dbaron: Interop is a disaster on this.
tantek: Is there a magic other value that UAs use if nothing is
specified for the cursor?
fantasai: You put something in the UA style sheet and if nothing
overrides it, that's what takes effect.
<zcorpan> FYI https://html.spec.whatwg.org/multipage/rendering.html#rendering
already says the UA style sheet should contain :link,
:visited { text-decoration: underline; cursor:
pointer; }
Florian: Though we've uncovered that the rules are more
complicated, I'm hearing a sort of agreement toward
dbaron's side, if others agree with tantek they should
talk.
tantek: I'm saying we should specify, but we don't know what
they're doing.
dbaron: I'm saying I know what we do and Simon knows what Webkit
does and it's not the same thing.
tantek: So you don't want interop?
dbaron: We want to decide what interop should be on.
smfr: To give an example in the webkit code there's interesting
things happening if your cursor is over a link. You can
click the link or click and start editing the link. There's
a setting that applies to that under the author value right
now.
smfr: And in addition to that it's something that's hard to
describe in the UA style sheet.
glazou: We're not going to solve this now.
Florian: Do we want to figure out the rules, or do we want to
leave this as magic? We can decide that and if we want
the rules, we can do that on the list.
<BradK> a:editing { cursor: text; }
glazou: What do implementors think?
zcorpan: I think it's good to try and get closer to
interoperability and align.
tantek: I'm for interop assuming we can do that
tantek: If we spec in this case do this thing, in this case do
this, else magic. If we can shrink the magic slowly, that
would be great. I'd like to see those prop
<gregwhitworth> Can we discuss this at F2F?
<gregwhitworth> Regarding cursor: Auto
Florian: Do we intend auto should be everything, or that the UA
style sheet should be specific where it can and else auto
and we try and define auto.
tantek: I don't think I understand that.
Florian: Do we want the UA style sheet to have a selector that
says cursor: auto, or do we want detailed things in the
style sheet except where we have to decide on auto.
<zcorpan> the latter
smfr: I'm fine with the latter. webkit only has links for the
editing behavior I defined.
<dbaron> I prefer the latter as well.
<tantek> I'll defer to the latter
glazou: So the two Simons are in favor of the latter.
glazou: Objections?
<BradK> If we do the latter, then what happens if the author does
the former?
<zcorpan> BradK - it would make links have a text cursor
<dbaron> proposed resolution: we intend 'auto' to cover behaviors
that can't be described by other styles in the UA style
sheet, and we want to define it more precisely, but we
need to work out on the list what that definition should
be
dbaron: Does that make sense?
Various: Yes
RESOLVED: We intend 'auto' to cover behaviors that can't be
described by other styles in the UA style sheet, and we
want to define it more precisely, but we need to work
out on the list what that definition should be
<Florian> ::value and ::choices (Follow up on ISSUE 65)
<Florian> http://lists.w3.org/Archives/Public/www-style/2015Jan/0046.html
Florian: A while back we decided to drop the pseudo-elements that
were in CSS3 UI. tantek made the edits, but we found two
values. There was some evidence of intent to implement. I
agree that ::value makes sense, I'm not a sure about
::choices, but given there's no implementations I think
they should go in pseudo-elements spec.
Florian: So what do people think, keep, delete, move?
tantek: I'm particularly interested in implementor feedback. If
it's not a priority for other implementors, that's a big
piece of input, but if they will implement this year, we
need that. Shuffling spec we can decide later from that
information.
tantek: This is part of the larger do we want to keep making
controls JavaScript-y or do we want to add smaller stuff
to CSS that authors use for control.
Florian: To me ::values makes sense and ::choices doesn't, but I'm
not an implementor.
tantek: As an author's prospective?
Florian: Yes.
smfr: I don't think webkit has intention to add these soon.
Florian: When we discussed place-holder pseudo classes, we only
added one for when it was shown, I think this was a combo
between value pseudo class and pseudo element did
everything you need.
tantek: I think that was a use case for ::value.
Florian: If we remove ::value, we need ::placeholder.
dbaron: We agreed to add ::placeholder. It hasn't been edited into
pseudo-elements spec.
tantek: I'd like to see a trail for that and see what's going on
there. Do you remember what meeting dbaron?
dbaron: No.
<astearns> Tucson
tantek: If we think it's sufficient and it's written, I think it's
a good interim solution.
Florian: If we have ::value, we don't need ::placeholder, but if
we have ::placeholder, we might still want ::value.
Florian: But back to the earlier question, do people want to
implement? You've got the comments from Mozilla.
tantek: I think it was a refocus on ::placeholder
<dbaron> placeholder resolutions in
http://krijnhoetmer.nl/irc-logs/css/20130206#l-654
<astearns> email link:
http://lists.w3.org/Archives/Public/www-style/2013Feb/0393.html
dbaron: I just put a link to the IRC of the resolution. It was
February 2013.
tantek: I was there and I don't remember this, but okay.
<zcorpan> maybe ::value shouldn't select the placeholder
Florian: What are we lacking to make a decision?
tantek: We're lacking a write up of those two pseudos.
<tantek> we need these written up: :placeholder-shown &
::placeholder
Florian: It's just ::placeholder that isn't.
tantek: Should we action someone to write that up?
glazou: We need to wrap up.
tantek: So I propose we action a pseudo-elements writer to write
up ::placeholder
tantek: I think we should get that out there and follow up
ACTION fantasai write ::placeholder in pseudo spec
<trackbot> Created ACTION-664
<BradK> Is XForms still a thing? Is that the only use case for
'::repeat-item'?
* Florian BradK that's been removed already
<BradK> OK
fantasai: It doesn't sound like there's an immediate need to have
::value and ::choices so we should drop them to
pseudo-elements
tantek: I think we have consensus on one, but not another.
glazou: We're past the hour. Thank you and we'll see you next week.
Received on Thursday, 8 January 2015 11:43:05 UTC