- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Apr 2015 19:04:23 -0400
- To: www-style@w3.org
CSS Houdini F2F
---------------
- Anyone planning on or interested in attending the CSS Houdini
F2F in conjunction with the August F2F was asked to please
contribute to the email thread planning dates, available here:
http://lists.w3.org/Archives/Public/public-houdini/2015Apr/0018.html
Selectors Profile Bikeshed
--------------------------
- RESOLVED: Rename 'fast' and 'slow' profiles to 'static' and
'dynamic'
Selectors 4 Matching Algorithm
------------------------------
- For now, conversation will continue on the mailing list to allow
more space to explain the complex algorithm and its
relationship with the work being done on CSS Scoping.
Copying text-transform'd Text
-----------------------------
- There was some disagreement as to if all text-transforms should
be removed from a plain-text copy/paste or if there are some
worth maintaining.
- People also disagreed on what behavior would be viewed as a bug
by users.
- fantasai will reach out to the editing taskforce to get their
feedback and use that to inform how the existing spec should
be written and if there's a need to create a spec to just
address copy/paste issues
CSS UI 4
--------
- There was disagreement on the approach to and need for adopting
user-select
- The 'auto' and 'none' values for the appearance property were
agreed upon, but there was a lot of resistance to the 'button'
value.
- For now, Florian will move the 'button' value to a note
describing how the appearance property could later be
extended if desired.
- RESOLVED: Accept 'auto' and 'none', do research on the rest.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Sanja Bonic
Bert Bos
Bo Campbell
Adenilson Cavalcanti
Tantek Çelik
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Edward O'Connor
Florian Rivoal
Simon Sapin
Alan Stearns
Ian Vollick
Greg Whitworth
Regrets:
Dave Cramer
Daniel Glazman
Simon Pieters
Michael Miller
Anton Prowse
Mike Sherov
Lea Verou
Scribe: dael
CSS Houdini F2F
===============
plinss: Let's start.
plinss: Since Zakim isn't keeping track, if everyone could type
into IRC something, present, or so that we can get
attendance.
TabAtkins: I'm not on IRC, but on the phone.
plinss: Anything to add?
Rossen: I have one about next CSS Houdini F2F.
plinss: Let's do that.
Rossen: So there's a mail thread about organizing the meeting
before or after the Paris F2F for Houdini. This is
something we agreed on at the February F2F.
<gregwhitworth>
http://lists.w3.org/Archives/Public/public-houdini/2015Apr/0018.html
Rossen: This is an FYI if you can go and do your +1 or don't care.
If we have critical mass we'll try and get together. Most
like after the F2F in Paris which is currently Tues-Thurs,
25-27 Aug. So most likely we'll spill into Fri and Sat.
That's an FYI.
Rossen: We'll do details on the mailing list and hopefully Mozilla
can host us for a day or two.
<tantek> +0 for after. (0 only because I'm not critical for this)
Selectors Profile Bikeshed
==========================
TabAtkins: Everyone seems fine with 'dynamic' and 'static' and I'm
happy with the rename.
<fantasai> +1
<astearns> +1 to static/dynamic
plinss: The proposal is to rename 'fast' and 'slow' to 'static'
and 'dynamic'. Any problems with that?
tantek: That sounds like an improvement.
RESOLVED: Rename 'fast' and 'slow' profiles to 'static' and
'dynamic'
plinss: We heard from MS that they're still working on item two.
Florian: A quick note, I sent a pull request to change what we've
already agreed to. It would be nice to hear back.
tantek: Okay, thank you.
Rossen: Once we have news we'll discuss.
Selectors 4 Matching Algorithm
==============================
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Mar/0432.html
<fantasai> I don't even understand why we have this algorithm in
the spec
dbaron: So, selectors, there's new prose in selectors 4 that tries
to define a matching algorithm. I wasn't that happy
because it essentially defines it in left to right
matching which isn't how selectors are implemented. There
might be things easy one direction and hard the other in
both directions, so I think it's better to have the spec
match the implementation. There's also risk of introducing
subtle mistakes.
dbaron: If there's an algorithm, and I think why TabAtkins wrote
it is to make it clearer how it works...
TabAtkins: That was the inspiration.
TabAtkins: It was written to clear up and tighten up prose around
matching when I was writing CSS Scope. As soon as you
have tree crossing you have to do something interesting
with the selector. The reason why left to right is
that's seems to match better what authors thought. Also
it makes the tree crossing easier because the left edge
is what matches. The right edge might be a different
tree. It seemed to be written left to right,
TabAtkins: but once we tree cross it gets a lot more complex. I
can chop it up or I can write it more universally and
have a check at the end, but those don't match
implementation. I think implementation-wise, ours finds
a lower tree and moves it in and then does a tree trick
at the end. I don't know if that's the right way.
TabAtkins: I would appreciate guidance about what is reasonable,
that was just simplest.
fantasai: I think if you evaluate a selector against a single
element in a tree because that's kinda the way the rest
of the spec talks about selectors.
TabAtkins: That's the problem, though. Which element? You have a
selector in some high context matching a nested context.
If you're going left to right you have to match against
the right side that's in a higher context.
dbaron: I don't understand what the tree crossing thing is given
the difference you described.
TabAtkins: What I'm referring to?
dbaron: No, the behavior you're trying to define. I don't know how
productive this will be on the telecon.
TabAtkins: I responded on the thread, so we can hash out there. I
said it in an e-mail and there wasn't a response, but
we can continue there.
plinss: So back to e-mail
Copying text-transform'd Text
=============================
fantasai: We have mostly interoperability on not copying the
transformation. There's some stylistic changes where it
doesn't make sense to keep if you copy plain text. So I
was going to clarify that in the spec text.
fantasai: The ones that don't do this is Safari and Chrome.
<dbaron> I think most authors will consider that a bug.
<dbaron> certainly users
Florian: I generally agree what we should copy/paste is the
original, but we might want to be careful saying if you
copy in rich text you may preserve.
fantasai: Do you preserve as a style by changing the character
codes, or is it if it happens to be a CSS style you keep
it.
Florian: I'm agreeing with plain text, but I think that if the
rich text you're pasting into can preserve it we should,
but if it can't you don't. I don't think we can define
how rich text works, so just say you can do it if you
can, but if you're pasting plain text don't do it.
fantasai: I think that the data store, whatever is the original
format, it should stay in that.
dbaron: I think users will tend to consider not copying what you
see as a bug.
Rossen: I agree.
fantasai: If authors intend those things to be capital letters or
whatever it should be in the data store.
fantasai: If I have something that I want to have as a heading and
have text-transforms to do fancy things, copying it out
should give you the same thing as was there originally.
<fantasai> Copying out a heading with text-transform vs. heading
with small-caps should give the same result.
tantek: Has anyone done user testing?
Florian: I think this also depends on what text-transform you're
using. There is a text-transform in Japanese that changes
small kana to big ones. It's only appropriate for text
typeset as Ruby. If you paste as plain text and preserve
the transform, the result is simply incorrect.
plinss: I think we have a few cases where it makes sense to
preserve the original text on the DOM and a few cases
where it makes sense to preserve the transformed style.
Florian: And as fantasai said if they want something to stay, they
should put it in the DOM
plinss: So say the text must be available in plain formatting but
they may preserve for rich text.
tantek: And this is one case of a broader set of problems. If you
copy a list do you get the bullets and if you do do you
get whatever characters are specified.
<ChrisL> agree that copy/paste is wildly underspecified
fantasai: This is a formatting thing, not generated content. We
should be able to get both results. If we make this
behave as if you change the DOM you can't get both
behaviors. The second things is it's a decision between
small caps and all caps, it should be a stylistic choice.
You should not have to worry if it will copy/paste
tantek: I don't think authors worry about if it will copy/paste.
fantasai: I don't think they'll think about it, but it shouldn't
have an unexpected side effect.
Florian: I think either could be considered unexpected.
tantek: It's because we don't have a copy/paste spec.
Florian: I agree with you, tantek, but fantasai pointed out that
generated content is different than the DOM and if you
take her suggestion authors can get the behavior, that
seems to mean we're getting an answer. I think it is a
problem not to have the spec, but we should try to solve
this case if we have a solution.
tantek: As we solve these individual cases and we're dealing with
trade-offs here, I think we should use 'should' wording
rather than 'must'. That's my suggestion for this general
area.
hober: Another thing that comes to mind to me is selection, coying
and editing move together code-wise.
hober: The people that hack on webkit are the people to talk to
about this and aren't typically on CSS meetings. Maybe we
should talk to the editing task force to see if they would
chime in.
tantek: That's an excellent idea.
fantasai: If someone would give me the email I can do that.
tantek: Would someone be willing to start a copy/paste taskforce?
plinss: I don't think we need a taskforce, but possibly a spec.
tantek: No, not a taskforce, a spec.
plinss: Let's ping the editing task force and maybe we need us a
spec that defines this based on what we hear back. Does
anyone have contact info?
Florian: It should be on the editing spec.
tantek: Which WG is it part of?
hober: webapps
<fantasai> My general position is that copy/paste of plaintext
shouldn't be affected by any CSS formatting except
'display' and 'content'.
ACTION: fantasai to ping the editing taskforce
<trackbot> Created ACTION-680
* fantasai still needs contact info to complete that action...
* plinss fantasai: public-editing-tf@w3.org
<tantek> aside: e.g. in CSS3-UI text-overflow we say *should*
http://dev.w3.org/csswg/css-ui-3/#text-overflow
<tantek> "Selecting the ellipsis should select the ellipsed text."
<fantasai> tantek, yeah but that's a "what is selected when I
click here" question, not a "what is the content when I
paste it out".
<tantek> fantasai - sure, hence aside.
<fantasai> tantek, Would you consider the implementation correct
if it copied out the ellipsis itself?
<fantasai> tantek, that's the level of questioning here
<tantek> no, because I believe the "should"
CSS UI 4
========
user-select
-----------
Florian: This was introduced in the precursor to CSS UI. It was
dropped and it wasn't spec'ed, but browsers implemented
it differently and people use it.
Florian: I put together a draft spec, I'm not trying to invent
new values, but to spec how browsers work when they
agree, and to get them to converge on something
reasonable when they don't.
Florian: There is a spec, I'd like feedback, this doesn't match
any particular implementation, but it is based on the
current implementations.
Florian: There's nothing particular for the call, but I'm asking
for review, unless someone has feedback now.
tantek: When I initially wrote user-select, the goal was to
capture a bunch of the UI behaviors that native HTML
provides and to be able to create a basis to create things
like check box.
[Gap in minutes due to connectivity issues. Basic gist of what was
said with some comments when possible:
- tantek continued giving a historical prospective on
user-select and said that the group needed to decide between
taking a very small, limited approach and going for a
broader property. He believed that the proposal leaned more
toward the broad approach.
- Florian responded that what he spec'ed was somewhat broader
than what is implemented by any browser, but only to the
extend that it covers the superset of the implemented behaviors.
It is not as far reaching as the early proposals that also
handled selection from drop-downs in addition to text selection.
- Florian said there was some user feedback being worried that
this could be abused as a copy protection system, so he
tried to make the spec clear about this not being appropriate.
- tantek also pointed out that it would be good to put in
information about items being copy/paste friendly for a11y
reasons and Florian agreed that some text in regards to that
should be added, and invited Tantek to provide it.
* fantasai is of the opinion that this property shouldn't exist in
CSS, should be some kind of thing at the behavior level
(HTML/DOM/etc.)
* fantasai it doesn't seem to be about style
Florian: This is indeed not really about style, and is more of a
behavioral property. However it doesn't belong in DOM,
as it is not tightly coupled to the content. CSS UI
as a module has been home to various non-stylistic
properties that belonged to CSS in the sense that they
use CSS mechanisms (selectors, cascading...), and are
not tightly coupled to the content.
- tantek believed that Fantasai's point is a commonly raised
issue about CSS-UI, but all of CSS UI was meant to
function in a broader context. He offered to put a note
in level 3 explaining this.
* fantasai doesn't think this comment applies to all of CSS3-UI
* fantasai thinks this comment only applies to ime-mode and user-
select
<ChrisL> prefer to see that in css ui 4, to not slow down 3
Florian: Yes, that's where it is.
<bradk> User select is about style when you create a purely
decorative pseudo element that shouldn't be interfering
with what can be clicked.
<fantasai> bradk, it doesn't control pointer events, just
selection
<bradk> You're right. I was thinking off pointer events
Appearance Property
-------------------
Florian: This is somewhat similar to user-select, in the sense
that this is a proposal inspired by implementations,
which has a much more limited scope that the earlier
spec version.
Florian: Rather than try to establish an exhaustive list of
all the possible values needed to describe all form
controls, which has proven unmanageable given the wide
differences between implementations and in practice
is only ever useful in the UA style sheet for most
values, I'm relying on an auto value for that, and
the main use case it to use the none value to turn
that off and be able to use CSS to style the control.
Florian: A side use case is that while it's true that not all
values are useful, some of them are. So, I have for
now just one value, letting you get the button.
Florian: We can expand the list, but I think we shouldn't try to
get everything. We need to limit to what authors want and
what we can define.
Rossen: I wanted to ask you, having dealt with appearance lately,
the main thing we see on the web is speaking to why this
came about. We have a closed and not perfect controls
model in all native controls.
Rossen: The way people could tap into the controls and try to
restyle a button or something. I don't now if you're
proposing to tone it down or to take it to the next step
which is formalize it further. If we're deigning a
controls model, there's enough from a component model, we
should try to align with those in the future.
Florian: Should I reply, or let dbaron go?
dbaron: Go ahead.
Florian: My intent is not to try and provide everything that could
be used to style anything. There are quite a few values
on the webkit side that correspond to pseudo elements
where the appearance isn't standard but people might try
and get the search icon to appear in places where you
can't search.
Florian: In general I'm trying to tone down the property. However,
there are a handful of values for simple controls, but
are very useful to have. Button is a good example of that.
I don't think we should try and add complex form control
control where you want to get the behavior. The
way I've spec'ed it, you don't change the behavior.
Florian: Styling something as a button doesn't make it acquire
the state pseudo classes that only a button has. And as
soon as you get to complex controls, composed of different
sub-elements, that is a different story. For that you
should use web components or something. I'm trying
to make this exclusively about appearance.
<fantasai> florian++
<fantasai> http://dev.w3.org/csswg/css-ui-4/#appearance-switching
<fantasai> appearance: auto | none | button
<tantek> I think 'appearance' should be relegated to a UA-only
property. Not for authors nor users.
<fantasai> auto UAs may render form controls using native controls
of the host operating system or with a look and feel
not otherwise expressible in CSS.
<fantasai> </q>
dbaron: I'm not a big fan of auto being a complex list of things
you expect UAs to implement, especially when those can be
a list of CSS values.
Florian: I think they cannot be. The actually long list is very
different between browsers. There are a few base values,
but most are not the same and will only be useful in a UA
style sheet.
dbaron: I guess I need to look at the conformance requirements for
auto closely. I'm concerned about doing a lot of work that
doesn't address use cases.
Florian: That wasn't the intent. Auto means do the right think
based on what the host language says for that element.
hober: You use 'auto' because you need to be able to override
'none'.
dbaron: One other point about things like buttons, appearance
implies state changes in relation to things like hover. If
you say appearance button you get different styles.
Florian: I think that's okay. :hover and :active are states that
exist for any element, so they apply to the auto
appearance as well. But if you have something like a
checkbox appearance and apply it to a <div>, the <div>
doesn't gain the ability to be checked. Active and hover
are fine, but things don't acquire new states if you
style them with a different appearance.
tantek: Given the experience with appearance, the same comment
about user-select doesn't apply. The effects we were
trying to do are complex enough that there wasn't a simple
declarative solution. I don't think this property at this
point should be recommendation for authors. I know there
is some legacy that in worth investigating.
<bradk> Toggling is useful.
tantek: I don't think we should put 'button'. I don't think we
should have something there that you can use this for. I
think they're complex enough where if someone wants to
turn a <div> or even a link into a button, I don't think a
single declarative property is the way to do it. We should
guide people to web components.
tantek: This is a legacy property. Yes, there's some usage on the
web, but we shouldn't direct authors there.
Florian: I think 'auto' vs 'none' isn't a legacy problem. I think
it's reasonable that your markup would use HTML form
elements and you don't want them to look like a form. As
for button and similar values, I'm a bit more on the
fence. I don't want the whole list like the earlier. I
think if it's possible to have a sensible model; I think
it's possible to work out.
tantek: I used to believe that, but not any more based on
experience.
fantasai: I think you're going to have to run some searches for
web compat because there are values out there. We may
need to put something in and deprecate it.
Florian: That's quite possible. Microsoft has implemented
-webkit-appearance in IE and it supports button.
plinss: I think tantek's point is valid. Maybe we need to put it
in and deprecate.
Florian: We can define and recommend away.
Rossen: If you define it you encourage use of this. And I'm siding
with tantek where we should move away from this and give
ways to better construct web components that would allow
people to do what they want to do. Talking from
implementation experience, very recently, I'm not a huge
fan of the appearance stuff.
Rossen: We can continue on the ML.
Florian: As to the web component point, I think it's a much better
answer to complex controls, but I don't see how it would
make it look like a native button.
Rossen: Use a button if you want a button.
dbaron: What you do with web component is you put a button in the
component.
Florian: If what you has has the semantic of the link, why not use
a link?
Florian: I strongly think auto and none are necessary. I can see
the concerns about other values and hear that we might
want to remove button. If people would read my exact
language, I'd appreciate it.
plinss: I don't hear objections to 'auto' and 'none' so let's move
forward with that. We need research on button.
Florian: I understand the concern. Please read the spec.
fantasai: Let's resolve on having 'auto' and 'none' and possibly
adding a few other values and someone should take an
action to do web compat research because we might not
have a choice.
RESOLVED: Accept 'auto' and 'none', do research on the rest.
plinss: Who is going to do the research.
Florian: It would be interesting to hear from Microsoft since
they've implemented with the webkit prefix.
Rossen: I think I gave you our feedback.
Florian: In terms of if it's possible. I heard as to if you think
it's a good idea, but I'm not sure if I heard if it
breaks the web to have the button value.
Rossen: Anything implemented is done so the web works.
Florian: And you have implemented more values than there is in the
spec.
plinss: So who will take an action to do the research.
Florian: I don't have the resources to do the type of research that
looks at a large corpus of websites. I have looked at
blogs and github and stackoverflow, but that's about what
I can do.
plinss: Anyone else willing to take the research?
tantek: Why don't we leave it out pending someone coming forward
with the research. Then we leave it open for someone to
say we need it.
fantasai: Then we should have the implementors say they'll drop it.
Rossen: I'd be happy with that.
Florian: I put button in there to make sure that I designed the
property in a way that made it possible add it if we
needed it. I would like people to review my spec language.
plinss: I think the way you did it is reasonable.
Rossen: Is your expectation with this that we'll implement a
non-prefixed appearance property? The only reason we added
it so the web can work. I don't see what you're gaining.
I'd be surprised if I saw other implementors rush to
implement.
dbaron: I think if we're not going to implement the property
unprefixed we have to implement the webkit prefix. I
think it's better to do unprefixed with 'none' and
'auto'.
dbaron: If we can get people into a not prefixed state, it would
be better.
<tantek> dbaron +1 - only un-prefixed just none and auto
Rossen: I agree with that.
<fantasai> +1 to dbaron
<tantek> even one other value 'button' implies a direction we do
not want to take
<tantek> even if that means dropping the mechanism for other
values
Florian: I want to make 'none' work and have other values we're
comfortable with... 'none' means we need 'auto'. I have
'button' to make sure it worked.
plinss: We have resolution for 'auto' and 'none'. We don't have
anyone to do research that we need the rest, so I agree
with tantek to leave them out until someone says we need
them.
Florian: I'm okay with taking out button, but I think that people
should review how I wrote button because I don't want to
lose it and find we need it.
<fantasai> Call dropped. My position is that if values are
necessary for Web compat, then they should be in the
spec for the unprefixed property
<fantasai> They can be deprecated, but they should be there.
<fantasai> I'm unwilling to drop 'button' from the spec at the
moment
<fantasai> I would agree to do it if all the browsers came and
said they would drop support.
dbaron: Can you take the button text and make it a note as to we
might need to add other things and here's an example of
how we'd do it.
Florian: There's some spec text assuming you have more than 2
values.
plinss: In general I like your approach and agree if there's more
values this is how they should behave and maybe that
can turn into a this property doesn't effect XYZ and I
think you're on the right track.
Florian: I can certainly look into seeing if I can cleanly turn it
into a note, but I'd rather not drop entirely.
plinss: Put a big issue in it for now and we have a path to move
forward.
<fantasai> +1 to leaving in spec, adding issue
<tantek> +1 to moving everything 'button' related to an
informative note section (including mechanism for it) as
a transition to dropping it
plinss: What brings us past the end of the hour. Thank you
everyone and I'll see you next week except I won't be
here, I'm at a TAG F2F.
<Florian> Tantek, fantasai: I'll put in a issue now, and look into
whether I can separate things more cleanly so that we
can turn the related prose into a note or possibly drop
it, without causing forward compat problems.
<Florian> I have clearly heard everyone's feedback that button is
not warmly welcome, but I would still appreciate
feedback to the question "If research shows we have to
have it, would this be a reasonable way to spec how it
should work?".
<tantek> Florian - I don't think people want to bother with that
level of conditional analysis - that's the problem.
<tantek> would rather just punt on it until someone brings it up
later
<Florian> tantek: I don't want to spec a property that cannot be
sanely extended in a way we may later find necessary. My
research shows that there is demand and usage of this
value, and I wanted to make sure we could have it if we
had to. The only way I know how to do that is by adding
it and seeing if the spec makes sense. To me, it does.
<tantek> The other way is to punt on it and worry about extending
it later.
<tantek> We do that in CSS all the time
<tantek> CSS is fundamentally designed to "extend it later"
<tantek> no need to pre-worry about "sanely extended later"
Received on Wednesday, 15 April 2015 23:04:51 UTC