- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 3 Dec 2014 20:27:29 -0500
- To: www-style@w3.org
Follow up on applying pseudo-classes to labels
-----------------------------------------------
- There were a few people that felt that this would add useful
functionality, but several people weren't convinced that there
were real-world use cases.
- Therefore, Florian will come up with use cases attempting to
create this behavior and anyone else is welcome to also add
cases.
CSS3-UI Issues
--------------
- It was felt that implementors that don't implement 'invert'
shouldn't parse 'invert'.
- RESOLVED: Update the spec to make it more clear what optional
means in the current spec (Issue 42)
- RESOLVED: Authors must not hide outlines on focused elements
unless they provide an alternate highlight mechanism for
focused elements (Issue 43)
- RESOLVED: UAs may support <image> in addition to <uri> and refer
to image production as part of the text. (Issue 44)
- RESOLVED: clamp cursor coordinates individually when invalid.
(Issue 46)
- RESOLVED: Do not address this issue (#49, ability to show a
tooltip with full text when a line is ellipsed) in CSS3-UI
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Mike Miller
Simon Pieters
Anton Prowse
Matt Rakow
Florian Rivoal
Dirk Schulze
Alan Stearns
Steve Zilles
Regrets:
David Baron
Bruno de Oliveira Abinader
Arron Eicholz
Simon Fraser
Simon Sapin
Mike Sherov
Lea Verou
Greg Whitworth
Scribe: dael
plinss: Let's get started. Anything to add to the agenda.
Florian: I mailed a bunch to CSS3 UI stuff to the list in addition
to what we had.
Follow up on applying pseudo-classes to labels
-----------------------------------------------
Florian: We discussed how :hover etc. would apply backwards, but I
forgot I had mentioned that we might want to do a
backwards for pseudo-classes. One way would be to put a
hook to HTML and make it the same as :active. Another
would be to introduce a new psuedo-class selector. A
suggestion was :for.
Florian: So do we want to do this?
<andreyr> yes
tantek: What was the use case?
Florian: I was wondering about it as a parallel. If you have an
input element associated with a label using :for
tantek: So this is a new feature?
Florian: Yes.
<Rossen> what do current impls do?
<fantasai> <label for=foo>Label</label> ... <input name=foo
id=foo type=checkbox>
<fantasai> Florian is proposing propagating the input's state to
the <label>
Florian: The use case is if you have an input element that is
invalid and you want to display it in red, you also may
want to highlight the label that goes with it.
glazou: So you want to reflect all the properties of one element
onto another one.
Florian: You want to be able to style the label based on the style
of the input since you might want to have a similar
affect on both pieces.
tantek: Is anyone doing this with JS? I've never seen the effect
you're talking about.
Rossen: What do current implementors do?
tantek: They don't. This is a new feature.
tantek: I would propose...I want to see one documented example of
someone trying to do this with JS. I've never seen this
and unless there's a use case it should be postponed.
<TabAtkins> I was trying to say that I've done styling of a label
based on valid/invalid before.
<TabAtkins> I did it post-submit, with PHP, but doing it
pre-submit would obviously be good as well.
Rossen: I'm with tantek on this one. If there's no clear use case,
why are we discussing it.
tantek: I don't want a theoretical use case for this.
zcorpan: I agree with that, for what it's worth.
plinss: I think a common use case informs it, but it's not done
with invalid. I've created a form where you want to
highlight the invalid data. That's used all over the place
so there are use cases.
tantek: I've seen highlighting a form field, but I've never seen a
modification of the label in particular. If you've seen
that I'd like a URL to where someone is doing it.
plinss: One would be sheppard.
<tantek> URL?
plinss: I've done it.
plinss: I've seen it in other places too.
plinss: Anyway.
Florian: I dropped and rejoined. While I was away, there was some
back and forth on if useful.
plinss: TabAtkins and I are saying we've done/seen it, but no one
else is sounding supportive.
Florian: So the options are 'this is not important, don't do', 'do
it like :active', or 'define a new pseudo to do it'.
tantek: And another where we don't know if it's important and if
it is, please document a use case on the wiki. Link
somewhere where we can see it's used.
<fantasai> It sounds like it'd be useful, no objection to doing
more research.
<fantasai> Also need to check Web-compatibility
Florian: I think I found an example on an e-mail.
Florian: There's no issue.
tantek: Where does selectors track them?
Florian: I'll check.
<fantasai> tantek, by email, with the [selectors] tag currently
tantek: So, I think we need a use case.
Florian: There are definitely some. I can write them down.
tantek: Yes, write them down.
Florian: Should we go on to next topic?
CSS3-UI Issues
--------------
Florian: Starting with issue 42. There is an 'invert' value for
outline that currently says UAs are allowed to not
support, but it's ambiguous as to what they should do
when they don't. I'd like to clarify what not support
means.
Florian: Some UAs do support 'invert', so we shouldn't remove, but
not supporting should mean don't parse. An alternative is
to parse and compute to currentColor. Things would be
sane, but we can't use the cascade, I'd say just support
or don't and don't parse.
Florian: Currently in the ML, I wrote that Firefox fails to parse
and uses black as the default, Chrome parses but doesn't
render, Safari parses to transparent, IE and Presto do it
correctly.
Rossen: You're proposing if you don't support, don't support it at
parse, if you support, support all the way.
Florian: Yes.
plinss: That makes sense as a default.
Florian: The only difference is that the spec says you can conform
without supporting this.
krit: The chances that Chrome will removing the parsing part isn't
very high.
Florian: Why would they not remove it?
krit: It means any property definition isn't supported if there's
a reverse part.
krit: A reverse keyword wouldn't support parsing anymore.
plinss: They're parsing, but not supporting. They can parse and
support correctly or stop parsing.
Florian: Chrome parses and makes it invisible which is just plain
bad. Safari is halfway decent, but it's not what the user
is asking for.
zcorpan: Do we know what the web compatibility impact is?
Florian: Yeah.
tantek: Are we considering Presto for CR exit? Can it could as one
of two implementations?
plinss: If it's in public release I don't see why it wouldn't.
<ChrisL> it was a fair question re Presto but current rules mean
we allow it
Florian: It's not making active progress, but its been shipped and
still being shipped.
tantek: Okay. It sounds like we have interoperability between IE
and Presto as spec'ed. That argues for keeping it. It
sounds like we need to tighten spec language for if you
don't support.
Florian: I agree. That's what I'd prefer.
plinss: I didn't hear anyone say drop.
tantek: There was some saying that on mailing list.
<Bert> (Make '@supports (outline: invert) {...}' useful.)
fantasai: We might need to mark as optional since I remember some
implementations don't want to.
Florian: Yes, it is optional. What's not clear is what it means by
'don't support it'.
fantasai: Then we need to change the initial value.
Florian: That's taken care of.
tantek: This is UA specific.
Florian: It already says if not 'invert', initial is currentColor.
I don't know if that's good, but it's what people do
currently.
tantek: Is anyone in Blink or Webkit willing to drop or fix their
implementation?
Florian: I hope so because what it is now is terrible.
<TabAtkins> Ours is broke as hell, so yeah, we can fix.
<tantek> Thank you TabAtkins
tantek: So initial value is the only question?
Florian: The spec says that you support it or initial value is
currentColor and that's what proper implementations do.
Chrome and Safari use currentColor as the initial value.
tantek: Then the question is...one possibility is to always change
to currentColor.
Florian: We could.
tantek: We simplify for webdev and implementors so that if it's
not specific it just works that way. If they want invert
they can try explicitly.
plinss: You're breaking our two implementations and one won't be
fixed.
tantek: Presto isn't maintained?
Florian: For spec work, hardly.
Rossen: TabAtkins said they'll fix. Either drop or fix.
Florian: Chrome stated they won't implement 'invert'. Someone on
the mailing list from Apple said they will not invert
colors. That wasn't about the parsing, but they won't
actually invert.
Florian: It plays poorly with composition.
tantek: Halfway supported isn't useful. There shouldn't be parse
and don't support. That's why I want the opinion...I know
TabAtkins said he'd fix, but would this make it easier?
For Rossen do you have backwards compatibility issues to
change initial value to currentColor?
Rossen: Don't know.
<ChrisL> tab, tantek is asking how will this be "fixed" - remove?
implement?
* Bert is reminded of the ugly problem with 'position: fixed' in
IE a long time ago: it was parsed, but didn't work, and
thus provided no easy way to provide a fallback.
Florian: If you do support 'invert', it is better.
tantek: Are there things where we change initial value from one
level to another?
Florian: I don't know.
plinss: I have a vague recollection yes, but I don't remember when.
tantek: I don't remember doing it and it feels like it would be
confusing to webdev.
plinss: I'm not hearing strong consensus about what to do with
initial value, but I hear that browsers that don't support
it shouldn't parse it.
tantek: Sounds reasonable.
krit: If you don't support 'invert'...?
plinss: If you don't support it, then the initial value is
currentColor. The behavior of not parsing if you don't
support it is how CSS should work and if that's not
spec'ed somewhere it should be.
Florian: The spec says you conform if you don't support.
<fantasai> http://www.w3.org/TR/CSS/#partial
<fantasai> It's part of the boilerplate for all specs
tantek: Optional shouldn't be explained in CSS3 UI. Do we have a
definition for that somewhere?
plinss: fantasai pointed out that it's in the boilerplate.
RESOLVED: Update the spec to make it more clear what optional
means in the current spec (Issue 42)
<tantek> CSS3-UI issue 42: define "invert" as optional per
http://www.w3.org/TR/CSS/#partial
<ChrisL> in current spec or in all specs?
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0494.html
Florian: Next topic is here (above).
Florian: It was suggested that it's bad for authors to completely
turn off outlines on focused elements. It's either a
usability or accessibility requirement, depending on how
you look at it. The suggestion is that outlines can't be
invisible on focused elements unless they provide
alternate highlighting.
tantek: I would be okay with a note
Florian: I'm okay with a note, but TabAtkins suggested we could
make it a must level so validators could pick it up. We
do have must/must not sometimes. It seems appropriate,
but a note is a start.
Florian: Other opinions?
* tantek is trying to listen and read
plinss: Anyone?
fantasai: Must seems fine to me. Use the advisement class, not the
note. It should be a conformance criteria. It's not a
non-normative statement.
<ChrisL> advisement means "do not ignore this"
Florian: We should says something. I think it's reasonable to go
as far as must.
tantek: I'm reading the original e-mail and it seems like that's
something we can site and make it specific for outline.
Florian: I went beyond just the width in the original e-mail since
there's a bunch of ways to go invisible. I'd like to say
whatever way you make it invisible you can't do that
without an alternative.
tantek: So authors must not hide outlines on focused elements
unless they provide an alternate highlight mechanism for
focused elements,
plinss: Author or UA?
tantek: Author.
<Florian> Author
Florian: Author.
tantek: If that proposal is good, are there objections?
Florian: I have a very similar proposal text. It's almost the same
sentence.
<Florian> As the outline on elements in the ‘:focus’ state is
depended on by keyboard users for interaction with the
page, authors must not make the outline invisible on
such elements without making sure an alternative
highlighting mechanism is provided.
tantek: And I'd provide examples so then we can put warnings in
validators.
plinss: Objections?
RESOLVED: Authors must not hide outlines on focused elements
unless they provide an alternate highlight mechanism for
focused elements (Issue 43)
<tantek> CSS3-UI issue 43: Add author conformance clause Authors
must not hide outlines on focused elements unless they
provide and alt highlight mechanism for focused elements (
e.g. outline-width:0 or outline-style:none)
Florian: Next one is, the cursor property takes a list of images,
but it's just taking <uri>s. The reasonable thing is to
accept image production, not <uri> so we can get access
to gradients, etc.
Florian: Based on the mailing list everyone agrees this is the
eventual right thing, but it's not agreed on if this
should be in level 3 or 4. There's currently not enough
implementations of the generalized version to pass to REC.
I understand, but I'm worried if we just start with <uri>
people won't do the broader implementation.
Florian: The compromise is say <uri> and in the future we're
expecting to go to <image>.
fantasai: CSS Values and Units, I believe has image production
defined as <uri> We can say if you support image values
level 3 you should support as <image>.
Florian: There's a bunch of browsers that support <image>, but not
on cursor. So if you support <image> you must apply here
won't pass. In that respect I'm sympathetic to the
argument, but I don't want to stop implementing the
fuller option. That's why I say stick with <uri> and say
alternatively you an use <image> if they want.
tantek: In general it's bad form to predict the future. It should
be more like UAs may support <image> in addition to <uri>
We don't need forward predicting, we can just say may.
<TabAtkins> I'm fine with speccing <url> and adding a note saying
that it will be upgraded to <image> in UI 4, and
browsers should feel free to implement fuller <image>
support.
ChrisL: The way to indicate the future is put it in level 4. That
doesn't predict, it's actualized.
Florian: I haven't made level 4 yet.
ChrisL: Dump this in 4 and make it in 4 so people know where it's
going.
tantek: I think we want to have some kind of suggestion in level 3.
Florian: I like tantek's proposal.
krit: I agree with it defined as a may.
<andreyr> +1 for proposal
plinss: I'm okay with a may, but I'd like it to refer to normal
image production. Say it should use image production and
make the image optional.
plinss: I would like it to talk about the image production in
values and units.
tantek: Normatively refer to image production is part of the
property.
plinss: Objections?
RESOLVED: UAs may support <image> in addition to <uri> and refer
to image production as part of the text. (Issue 44)
tantek: Which issue was that?
Florian: 44
<tantek> CSS3-UI issue 44: UAs may support <image> in addition to
<uri> and refer to image production as part of the text. (
link <image> to normative image production in values and
units)
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0501.html
Florian: Next one, again on cursor, you can have a bunch of
images/uri but you can also use the coordinates, but the
spec doesn't have any limits on that. However, there
isn't full interoperability on what to do with invalid
coordinates. You can either plant at the actual cursor or
ignore it if it's a negative. It seems like planting at
the cursor is the better option if the actual value is
out of bounds.
tantek: That's reasonable. That seems uncontroversial. Clamping.
plinss: Different opinions?
Bert: How do you clamp?
Bert: Do you calculate the position by angle, or ...?
Bert: Do you clamp each coordinate individually?
Florian: Individually was what I had in mind.
Florian: I hadn't tested on that. I suspect it's individual but I
don't know.
<TabAtkins> We can test, but individually is likely what's
implemented, and it's sufficiently simple to work fine.
<TabAtkins> This is just handling an error case, anyway.
plinss: Do you know Microsoft's?
Florian: I don't.
plinss: Let's resolve we clamp individually and if you have other
findings we'll revisit.
plinss: Objections?
RESOLVED: clamp cursor coordinates individually when invalid.
(Issue 46)
<tantek> CSS3-UI issue 44: clamp x y cursor hotspot values at edge
of image
Florian: We don't have dbaron right? Then I'd like to skip 48.
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0532.html
Florian: 49. Some browsers, when you have something that's
ellipsed and you hover over it, it will have a tooltip,
but other browsers don't support that. Having the spec
normatively say if you should have support for that would
solve it. I don't care which.
tantek: Any kind of automatic tooltip would get objections from
authors. They don't want random pop-ups. Webkit does this?
Florian: If you hover over text with an ellipsis, Blink, I believe
has it active.
tantek: Over the whole line?
Florian: Yes.
<Florian> http://jsbin.com/quhisipiba/1/watch?output
Florian: I'll check, but I think so. You can test this (above).
Florian: In this example we have two lines of text with ellipsis
and if you hover anywhere you get the toolkit.
Florian: As far as I know this is often complained about by people
trying to create the tooltip for other browsers and end
up with two.
tantek: That sounds like a request for support.
Florian: It's unclear if everyone wants that.
plinss: And how do you detect if the UA is doing that?
Florian: UA sniffing?
tantek: We had generation of tooltips in a previous draft. Do we
have user selectors that attempt to style tooltips?
Florian: I don't think so. There was a lot of discussion, but it
didn't conclude on anything.
tantek: Other thing we can do is...no, never mind.
plinss: I would like to see a way of creating tooltips with a
:hover and then they can override
tantek: I think it was generated content at some point.
Florian: There was a proposal, but then there was disagreement as
to if it's just text, or have a region...
tantek: The obvious thing to do is just text, so that kind of
discussion is annoying.
Florian: So should we tackle the whole discussion to solve this,
or until then should we say which way browsers should
behave?
tantek: I don't want to recommend UA behavior, I'd rather give
authors a hook or control.
Florian: The hook is difficult.
plinss: I understand the concern. I'm loathe to tell browsers not
to put a tooltip or say must without a way to suppress.
tantek: That's a better description of my thoughts, thanks plinss.
Florian: So despite non-ideal interoperability, you want to leave
this?
tantek: There's lots of not-interoperability.
Florian: I'm not objecting to not defining, I just want to be
clear. If we're not addressing this, then we need to be
clear.
tantek: One way to have it is in terms of a11y, when you ellipse
content it's not necessarily viewable or accessible, so we
can encourage UAs to provide a mechanism to access that
content. There's one in the spec if you support copy/paste.
Selecting the ellipsis is the same as selecting everything.
Florian: Even an encouragement isn't enough. We need a way for
authors to turn it off.
Florian: I think I'm fine with undefined for now with somewhere it
saying we want to deal with this eventually.
tantek: I'm not sure that helps.
tantek: Our efforts should go into a fix. If there's a proposal we
can fix it, but else wise we should leave it. If someone
has a proposal, please put it on the wiki.
Florian: We should resolve to not address it in CSS3-UI if we're
going to do that.
RESOLVED: Do not address this issue (#49, ability to show a
tooltip with full text when a line is ellipsed) in
CSS3-UI
plinss: Anything else we can do in 2 min?
Florian: Not from me.
plinss: That's it for the week. Thanks everyone.
Received on Thursday, 4 December 2014 01:27:57 UTC