- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jun 2015 06:30:28 -0400
- To: www-style@w3.org
CSS UI 3 LC Comments
--------------------
- RESOLVED: Add the suggestion that the default stylesheet for
HTML should have "resize: both" for <textarea>
- RESOLVED: Reject issue 95, keep using 'ellipsed'
- Remaining issues are editorial and will be addressed by the
authors. If they encounter any resistance to their changes,
they will bring them back to the group.
- RESOLVED: Take CSS UI 3 to CR
user-select
-----------
- RESOLVED: Don't offer variants of user-select: none proposed
here
(https://lists.w3.org/Archives/Public/www-style/2015Jun/0002.html)
that Florian was actioned to investigate
- RESOLVED: Add Florian's proposed text to user-select: none
regarding its use in template-based editing
- RESOLVED: user-select must not apply to ::first-line or
::first-letter
Media Queries - custom media definition
---------------------------------------
- RESOLVED: Reject custom-media definition change to add brackets
(proposal here:
https://lists.w3.org/Archives/Public/www-style/2015May/0223.html)
sideways-left
-------------
- There was still no resolution on how to handle sideways-left,
but the proposed options will go into the ED of Writing Modes
with an invitation for input on a solution.
===== FULL MINUTES BELOW ======
Present:
Tab Atkins
David Baron
Bo Campbell
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Brad Kemper
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Regrets:
Sanja Bonic
Adenilson Cavalcanti
Simon Fraser
Michael Miller
Hoyjin Song
Greg Whitworth
Steve Zilles
scribe: dael
plinss: Let's get started.
plinss: Anything to add?
Florian: I think koji posted something
plinss: I saw that.
CSS UI 3 LC Comments
====================
Florian: We have one more week in unofficial LC. We've had some
comments. Some of them were non-controversial and I
changed them.
Florian: Here's the ones that need discussion:
<Florian> https://wiki.csswg.org/spec/css3-ui#current-issues
Issue #94: resize: both as default for <textarea>
-------------------------------------------------
Florian: If we start with the first one, #94, timeless is
suggesting that the default HTML stylesheet should have
resize: both as a default. I think all browsers that have
resize: both do it, so I'm fine, but I don't care that
strongly.
Florian: What does the group think?
Florian: IE doesn't implement resize so they don't have it, but
the browsers that do impl have it.
<dbaron> sounds fine to me
TabAtkins: Yeah, it's demonstrated to exist basically, so you
should.
Florian: Anyone form Microsoft here?
[silence]
Florian: I guess not.
Florian: This implementation that for this to work means overflow
is something other than visible, but I think they are. I
haven't seen a text-area: overflow. I believe it's
overflow auto.
TabAtkins: They're auto.
Florian: I'm pretty sure there's scroll in IE.
TabAtkins: It's auto in Chrome.
Florian: I think it's auto everywhere except overflow y-scroll in
IE, but no one has it visible.
Florian: I'm hearing weak agreement.
tantek: That's not informative so we can change at any point.
Florian: No one objects so I suggest we put it in.
RESOLVED: Add the suggestion that the default stylesheet for HTML
should have "resize: both" for <textarea>
Issue #95 - Ellipsed vs. Ellipsized
-----------------------------------
Florian: Next is #95
Florian: Timeless says the word ellipsed as a word isn't in the
dictionary, but I have have found it in some dictionaries,
but ellipsized is only in Android docs. But he still
things go with it because it doesn't mean what we say.
TabAtkins: Yeah, I think it means give it an ellipsis.
Florian: No dictionary has what we want.
tantek: I would reject these grammar/spelling comments unless it's
a very strong case. That's our job as editors to get it
right.
Florian: I agree, but I wanted other opinions.
TabAtkins: I've dealt with this before, but I've just invented a
word using standard English rules.
tantek: I think the wording is fine. I would reject that kind of
request.
Florian: That's my inclination too.
RESOLVED: Reject issue 95, keep using 'ellipsed'
Remaining Issues & Publication
------------------------------
Florian: Issue 96
Florian: He thinks the at-risk section isn't clear enough. He
wanted the section about text-overflow explaining it's
about ellipsis and having direct links to the rest of the
spec
tantek: The ellipsis part of text-overflow isn't at risk.
Florian: I think that isn't the right place to remind people what
it does.
Florian: He also wanted pointers to the exact parts of the spec
and we're pointing to the beginning of the section. I
think it's good enough.
<fantasai> I think this is editorial, doesn't need WG discussion.
tantek: I agree with fantasai that this level of editorial
feedback should just be fixed and not do it on the telecon.
Florian: I just wanted to have agreement to reject, but if you
think it's not needed we can move ahead.
TabAtkins: plinss, do we need WG approval for editorial, or just
non-editorial?
plinss: I'm not sure. We should as ChrisL
<glazou> or Bert
tantek: If it's okay with the WG I'd like to focus on normative in
telecon time.
plinss: I agree.
fantasai: The editorial stuff, if the commentator objects to your
resolution bring it to the WG, otherwise just fix. If
it's terminology, maybe bring it to the WG because we
like to have consistent terminology.
plinss: If the change crosses specs it needs to get out there.
Florian: I brought it up because I wanted to reject, but I'll do
it without group time. The other issues are similar.
tantek: We'll be making other changes before CR anyway. I think we
can take that as editorial prerogative.
Florian: Okay. timeless and I had back and forth, but he was
disagreeing with what I was proposing.
plinss: Let's move on.
tantek: On that note, since we are nearing the end of the LC, I'd
like to try and get group consensus on publishing CR the
Tuesday after next.
tantek: That's the 30th.
fantasai: You can't publish CR. It has to go through a process
with telecons. Once you compile the DoC and can get a
resolution from the WG that they agree with the
resolution of comments, you'll turn it over to the
chairs and they'll get it published later. You can get
it in the pipeline, but it'll get publish a bit later.
CR takes longer.
fantasai: You can get group consensus to publish CR, but not on a
date.
tantek: So the hopes of getting CR through pipeline, I'm asking
for group consensus to publish CR.
plinss: I'm okay, but we need a DoC.
Florian: We have it in the wiki but it needs to be cleaned.
tantek: We don't have the formal red/green format.
TabAtkins: bikeshed makes that easy for you with the issues list
command.
Florian: There's one point we might want to discuss on the telecon.
One of the editorial comments from timeless was a11y.
There was an author note that said they must not remove
outlines on focus level. He wants us to have a lot
stronger of a threat in that. It's editorial, but people
get more touchy about a11y.
fantasai: You might also link to the guidelines and make it
brightly colored.
tantek: On that note, we should make a policy that CSS specs do
not make laws or something :)
Florian: Anyway, move on?
tantek: We want consensus on CR.
plinss: Objections to taking UI to CR?
<glazou> +1
<tantek> +1
<Florian> +1
<dauwhe> +1
RESOLVED: Take CSS UI 3 to CR
tantek: Thanks everyone.
user-select
===========
behavior of user-select:none child of a user-select:<not-none> parent
---------------------------------------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0002.html
Florian: I had an action to try and make some variations around
user-select: none so that if you select the parent you
either would or would not include the none.
Florian: I've been through the bugzilla of Firefox and Webkit and
I don't think we should do this. Firefox has it so that
if you have a child the user-select: none isn't included
and there is no bug asking for it to be the other way,
but webkit has bugs asking for the Firefox way. There's
no evidence people want the webkit way so I don't think
we should provide it. If your browser can't do multi-part
you don't, but if you can you do.
<glazou> fine by me
plinss: Objections?
RESOLVED: Don't offer variants of user-select: none proposed here
(https://lists.w3.org/Archives/Public/www-style/2015Jun/0002.html)
that Florian was actioned to investigate
<dbaron> I think it sounds fine as long as that's not what
-moz-user-select: -moz-none is... but I think I discussed
that with Florian at some point.
Florian: It's not.
Add a note to user-select:none about use in template-based editing
------------------------------------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015May/0306.html
Florian: Next is something else I had an action on.
Florian: It was to put a note saying user-select: none is useful
in templates in an editor setting because you have an
overall editable area with a specific area that's not
editable or deletable like a disclaimer. The way content:
editable typically works is if you have a non-editable
thing you can still delete it. But by having user-select:
none you can't delete. But I really don't think I can say
that in here.
Florian: It looks a bit out of scope. If you still want a note I
have proposed wording, but I'm not convinced we should
have it.
Florian: [reads his proposal from the e-mail (pasted below)]
<Florian> Note: user-select:none on a non-editable descendant of
an editable element means that in addition to not being
editable, that descendant is also not deletable, neither
directly nor by attempting to include it in a broader
selection and then deleting that selection. This matter
for example in template-based editing, where an editable
template may contain sections which must be preserved.
Florian: It can be a note, but I'm wondering if it's out of scope.
TabAtkins: It sounds fine to me, but I don't have an opinion of
out of scope. If we keep it it's fine.
glazou: I was re-reading it and I'd like to keep it.
glazou: If nobody objects of course. It's non-normative anyway.
Florian: What makes me nervous is it's useful if targeted at
people writing the spec, but if they do something else it
could set up the wrong expectation.
glazou: But the people dealing with those in a template
environment will read both specs. I prefer having the note
in one place instead of nowhere.
Florian: Okay.
glazou: If there are objections I'm happy to withdraw, but I think
it's fine to leave it if no one objects.
plinss: Objections?
<BradK> No objection
RESOLVED: Add Florian proposed text to user-select: none regarding
its use in template-based editing
interaction of user-select and ::first-line/::first-letter
----------------------------------------------------------
Florian: Next up is this
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0012.html
Florian: user-select isn't actually inherited, it's pseudo-
inherited and goes through the auto keyword. If the
browser wants to support it and ::first-line we have to
make sure how it works. But I think using it on
::first-line or ::first-letter is wrong. If you're trying
to use this correctly it's through a UI element.
Florian: I'd like to explicitly say it doesn't apply there.
tantek: I think not-applying is the default.
Florian: They have a list that says UAs may apply other stuff.
tantek: You want it to be must not apply.
<glazou> +1
Florian: Yes
tantek: Okay.
TabAtkins: Agreed.
fantasai: Yes.
tantek: I would add ::before/::after
fantasai: I don't think it's the same problem.
tantek: I'd like to force someone to have a use case for it.
tantek: No use case, no feature.
dbaron: I think it's extra work to make them not apply.
tantek: I think it's a compat problem to let them apply by
accident.
fantasai: I don't think anyone is setting user-select on
::before/::after.
dbaron: There's the problem that selection doesn't work with
::before/::after anyway.
plinss: I'm a bit uncomfortable to ::before/::after because it's
different use.
Florian: I'm not sure it's so different. These things aren't
actual content. They could be coming form selection
because they're not part of the content, but I don't care
that strongly.
plinss: I've heard people argue they can't select them.
TabAtkins: They're not selectable because implementor limitations
at the moment. If they're selectable in Chrome they'd
be selectable everywhere in Chrome like normal text.
Florian: I think we have consensus on ::first-line/::first-letter
but not the others.
RESOLVED: user-select must not apply to ::first-line or
::first-letter
Florian: That's it for user-select
Media Queries - custom media definition
=======================================
Florian: We received 2 e-mails from the same person asking for the
same thing on custom media features.
Florian: He thinks it's ambiguous if it's a media type or media
feature and adding parentheses makes it obvious. I don't
really care, but I see where he's coming from. We should
answer, though.
TabAtkins: I'm inclined to say no. Any other customer definitions
in CSS syntax like alias style won't have wrapping
syntax. I think it would be weird to break just for
custom-media.
Florian: I'm okay with rejecting, I wanted to make sure we agreed
to reject.
plinss: Other opinions?
RESOLVED: Reject custom-media definition change to add brackets
(proposal here:
https://lists.w3.org/Archives/Public/www-style/2015May/0223.html)
sideways-left
=============
koji: There are issue with the implementation functioning
interoperably. The idea is to have it move to a property,
sideways-left.
fantasai: I don't think this is a good idea because...we don't
have a problem so long as we have sideways-right and not
sideways or we change the meaning of sideways to mean
sideways-right and have an auto value. There are reasons
to have sideways-left as an inline thing eventually so
it doesn't make sense long term.
koji: What are the reasons?
fantasai: There are uncommon use cases for which is should be
inline
koji: Is the rtl inside cjk?
fantasai: That and...
Florian: Why can you do that on the block level? The rtl inside
cjk? Doesn't that need to be inline?
koji: You can do inline block that does it clearly.
Florian: Inline block brings other things as well.
fantasai: I don't think this is solving a significant problem. If
there's a major problem with having it then we can have
sideways only meaning sideways right and have sideways:
auto do what sideways is doing. I don't want to change
the writing mode in such a way...I don't like mixing it
up.
koji: It's really complicated and we don't want to introduce
complexity. If you don't like adding the value we can add
the new property.
Florian: I'm a bit confused. I thought we agreed at the F2F that
we could keep it the way we had. What's new?
koji: How did we agree?
Florian: We brought up that sideways-right was correctly
implemented by most people but sideways and sideways-left
were not and we might want to rename or get rid of some
of them. After the session we agreed it was fine the way
it was.
koji: What we discussed is that the value of sideways depends on
the value of sideways left. The new question is about
applying sideways inline or at block level, because
doing sideways-left inline is hard.
Florian: Okay. I understand now.
fantasai: I don't think it's intractable, but might be more
difficult, so maybe this gets deferred to next level.
koji: I don't want to leave implementing this in the next level.
Florian: Is sideways-right an issue, or just left?
koji: Right is very clearly defined. Sideways-left requires
additional resources for the baseline and it's really
complicated.
Florian: I'm tempted to say it's at-risk and that's fine, but I'm
not an implementor.
plinss: I'm not hearing consensus.
plinss: Are we rejecting? Think about it?
koji: Rejecting means we have to address other issues and
complexities.
fantasai: I don't think we have any open issues. We just need to
clarify the spec.
koji: dbaron doesn't want to change, why isn't that an issue?
Florian: I think koji is brining up an issue that you raised that
sideways-left is an issue if it can be applied inline.
And fantasai and I were saying it's more complicated, but
also useful and it's at-risk anyway.
dbaron: It feels like there are use cases. It is harder and we're
not doing it now. My issue is that there is a bunch of
other wording in the spec that needs to be adjusted.
fantasai: And that's something I need to fix, but we don't have to
change the values and feature set, it's clarifying the
spec.
koji: How will they understand how floats works?
fantasai: It's not going to be too hard, but I need to sit down
and spend like a month fixing the wording because there
are a lot of areas that aren't precise enough.
koji: Is there anything other than rtl appearing in cjk vertical
flow? If this is really complicated, I don't think that's
worth the complexity.
Florian: Could we try and identify what it is that need fixing and
look at the list and see if it's too small a use case?
fantasai: The one thing here is the float rules are one or two
paragraphs. There are other aspects of the spec that
need cleaning, I don't think this is intractable, but it
does need to be done. As far as, like, there are a
couple of use cases where we could make it s block level
thing and if you want those handled you have to use
inline block,
fantasai: but also it makes the model for the user more
complicated because for things that are similar there is
more than one switch.
fantasai: Right now the effect is localized to inside the line box.
If we make it block-level when we switch we can say you
ignore text orientation or try and integrate it into
writing mode, but that conflates the two switches that
are currently only doing separate things. I'd prefer not
to do that because it makes it less clear cut.
fantasai: If we decide it's too complicated, I'd rather set up
rule on how you ignore values on inline elements.
koji: What we're trying to do for right also requires writing
modes. It sounds inconsistent so I prefer the other way.
fantasai: I don't think authors think in terms of switching
baselines. They think of how their glyph is orientated.
koji: It depends on the people.
<fantasai> I don't think people associate upright typesetting with
a sideways baseline orientation
Florian: If I understand, sideways-left at the inline level is a
problem and -right is not. The natural way to use
sideways-right within a vertical text is in the inline
element,
Florian: instead of relying on mixed orientation. If I understand
correctly I think this should stay an inline level switch.
I think I'd rather not have sideways-left instead of not
having this be an inline level switch.
plinss: I'm not hearing consensus. I'm thinking you go off and do
some spec work to sort things out. Anyone have anything
else to say?
plinss: The next topic is spec publication and we need ChrisL and
Bert, so we have to defer.
plinss: Anything else?
koji: I'm not very comfortable with why we're editing the spec.
plinss: We don't have consensus on if we'll change so we should go
offline.
tantek: Should we capture the options in the spec?
fantasai: The spec is in CR and the options have been there for a
while. People are discovering it's complex as they try
and implement.
<glazou> in CR, adding such prose will not be editorial and will
trigger a re-eval of CR...
tantek: I'm a fan of capturing the issues.
tantek: If we're not making quick progress it's good to mark it in
the spec.
fantasai: The feature is marked as at-risk.
tantek: I mean the issues we've come up with that we're not
resolving.
tantek: Someone outside the group may have insights.
fantasai: One issue is that we need clarification. I will do that.
Koji wants to move one thing to another property to make
it easier to implement.
tantek: For that we should put a note on it that we don't have
consensus and we welcome input.
plinss: I would agree, but we're in CR.
Florian: We can put it in the ED which exists even if we're in CR.
plinss: Is that sufficient or do we republish with that?
tantek: Would it being put in the ED be a good step for you koji?
koji: Okay. I think there have been years without progress.
tantek: That's why I want it in the draft.
Florian: I think I disagree with the proposal, but I support it
being recorded as an issue in the spec.
tantek: I jsut want to move the discussion forward.
plinss: Let's list the issue in the ED
tantek: I'm okay iterating on the CR with that.
plinss: It sounds like we have to publish the CR once there's
edits on it.
fantasai: The CR will have to go through a few iterations.
* dbaron doesn't see how Koji's proposal makes anything any
simpler
<fantasai> dbaron, I think the argument is that it wouldn't have
the varying BFC issue you raised?
plinss: That's the top of the hour. Thanks everyone.
Received on Thursday, 11 June 2015 10:30:56 UTC