- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Aug 2016 21:28:03 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Resolved Value of Logical Properties
------------------------------------
- RESOLVED: Add text to CSS OM and to Logical Properties as
proposed (logical properties take their CSS OM
behaviors from their physical equivalents)
Add <number-optional-number> type
---------------------------------
- Rossen requested a week to review.
user-select: none and selectionchange event
-------------------------------------------
- Florian will reach out to the editing task force for feedback.
Ambiguities in handling url()
-----------------------------
- This topic was deferred to TPAC.
Algorithm of `Element.offsetParent`
-----------------------------------
- This topic was deferred to next week.
Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
- astearns will reach out to the Internationalization group for
feedback.
Value is used value?
--------------------
- Florian will investigate having two user-select properties, one
of which is a shorthand for the other. If that seems to work
he'll also investigate if there's a reason to expose the
longhands to the author.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0066.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Koji Ishii
Brian Kardell
Ian Kilpatrick
Peter Linss
Thierry Michel
Michael Miller
Anton Prowse
François Remy
Florian Rivoal
Geoffrey Sneddon
Jen Simmons
Alan Stearns
Liam Quin
Greg Whitworth
Regrets:
Tantek Çelik
Dael Jackson
Myles Maxfield
Scribe: Liam
Resolved Value of Logical Properties
------------------------------------
astearns: Extra item: weekly reminder to add things to the TPAC
agenda, and register etc
<astearns> https://github.com/w3c/csswg-drafts/issues/384
fantasai: Do we use return the used value or the computed value?
My suggestion would be to keep it equal to the physical,
as if they are aliases to the same property
* glazou tends to agree with fantasai
Rossen: When you have e.g. vertical direction, what would you
return for width vs logical property?
fantasai: For width, if it was specified in percent you'd return
it in pixels. The question is what do you do for
getcomputedStyles for the block size/inline property, in
pixels or computed value? And I'm arguing it should
behave the same, the used or the computed value as
determined by its physical equivalent.
<Florian> +1
Rossen, OK, agreed
astearns: Is this going to go into CSS OM spec? or gets added to
properties?
fantasai: I think a blanket statement in the CSS OM.
Rossen: Perhaps we can add something to the CSS logical properties
spec.
plinss: Are there any examples of properties that would flip,
width vs height based on block direction for example?
fantasai: No, I don't think so.
plinss: The only difference I care about is if you're returning
the used vs computed value, and wondering if that's going
to change based on which physical property the logical one
will resolve to. [but sounds like this is not the case]
RESOLVED: Add text to CSS OM and to Logical Properties as proposed
(logical properties take their CSS OM behaviors from
their physical equivalents)
Add <number-optional-number> type
---------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/385
fantasai: [introduces the issue] e.g SVG has a lot of lists that
continues, we could add a multiplier #
<TabAtkins> Basically, for a *pair* with optional commas, do:
<one> ,? <two>
<TabAtkins> For a list with optional commas, do: <item>+#
<TabAtkins> This is not something we'll ever do for CSS itself;
this is just translating some legacy SVG syntaxes to
CSS properties.
astearns: If what people want to express is already expressible in
the grammar I'm not sure adding more is here we want to
go.
fantasai: [missed] proposal is to add +#
fantasai: In order to be able to express some SVG syntaxes that we
do not propose to use for anything new.
Rossen: Is this request from the SVG WG?
astearns: Yes, filter effects module started the issue; nikos in
favor of adding it.
Rossen: I'd want to go back [and review this request in more
detail] and see if it's worth the complexity.
Rossen: Don't think it's pressing
Rossen: can we move it to next week?
[fantasai, Tab, Ok with this]
user-select: none and selectionchange event
-------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/319
Florian: What happens if you click in a user-select: none area and
there's already selection? What if you drag there? Varies
between UAs today.
Florian: You don't get an event in Firefox and do in Edge and
Safari.
<dbaron> The behavior of unselecting on click seems to make more
sense to me.
<dbaron> (Was that Edge and Safari?)
glazou: I suggest we normalize the behaviors; I tend to think the
Firefox behavior is best in this case.
Florian: No strong feelings, but don't disagree.
dbaron: I often click somewhere else to unselect things.
Florian: If you select text and then click the title bar you do
not unselect
dbaron: The title bar isn't part of the page, try the margin
[I see select-none used on body to try and prevent copying of the
text]
<dbaron> I also couldn't hear the middle of what glazou said
astearns: Does user-select: none means I'm not going to interact
with the selection? If so I expect the deselect behavior.
glazou: Could be a database value that the user can't change;
don't want to change the selection if you click it by
mistake.
Florian: Let's say you are making a mail field with to, cc, etc.,
but the cc label are UI elements and these tend not to be
selectable and when you click them they don't change the
selection.
Florian: If you try to mimic this as a web app you'll probably
want the same behavior.
smfr: I think Chrome, Safari, etc. are emulating behavior on a
mac, if you click on an unselectable it doesn't remove the
selection but drag does, it's for compat with native code.
<dbaron> I think Florian's comment about them being UI elements
was reasonably convincing
Rossen: Has anyone tried reaching out to the editing wg?
Florian: I could.
Rossen: It seems we're trying to define editing behavior in CSS
while the editing group is trying to deal with these
scenarios.
Florian: I'm hearing we need more input, but we do want interop.
Florian: I will take this to the editing wg.
[question about chrome performance not minutes]
astearns: I heard smfr mention Mac native behavior
astearns: but that's only native on one platform,
astearns: Chrome also tries to match native behavior on each
platform, so if mac and windows differ we may want
something different.
Rossen: I think Mac and Windows are here but need to check.
ACTION: Florian to get back to editing tf and do research on
https://github.com/w3c/csswg-drafts/issues/319
<trackbot> Created ACTION-787
Ambiguities in handling url()
-----------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/383
<fantasai> I thought we're deferring url() ambiguities to TPAC
* fantasai is no longer able to speak up, sorry
<fantasai> yeah, TPAC
[moved to TPAC]
Algorithm of `Element.offsetParent`
-----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/409
smfr: Any changes here has compat risks but we may be willing to
change it and see what happens.
Rossen: In our case I'm pretty sure we do say containing block but
I haven't looked recently.
Rossen: So I'm not quite ready about this issue.
<bkardell> +1 to next week
[deferred to next week]
Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/337
<fantasai> This probably needs i18n input
<fantasai> The issue is that punctuation is shared
<fantasai> and we currently assume EAW ambiguous punctuation is
narrow (non-CJK)
<fantasai> when deciding whether to transform newlines to space or
nothing
<fantasai> An earlier draft looked through punctuation to the
first non-punctuation character
astearns: I'll ping Richard about getting an [i18n] opinion on
this one
<fantasai> And the algorithm was simplified. So now we have a
problem.
<fantasai> One way to deal with the issue would be to just pick a
behavior here; other way is to look through punctuation
to non-punctuation character (limiting to 3 chars,
probably).
<fantasai> i18n would need to advise on the first approach; csswg
on the second.
<fantasai> So I guess that's a question for the csswg -- which
approach to take
Value is used value?
--------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/336
Florian: User select is not inherited but auto sort of does
Florian: Microsoft prefers to keep it at computed value time but
Blink doesn't. So proposal is to split user-select into
two values.
Florian: New is user-select-contain: none | contain and is not
inherited; other would be user-select: text | all | none
and inherited
[question about user-select unprefixed from fremy]
Florian: Unprefixed is implemented but I think common in the wild.
Florian: We would have a shorthand and longhand where one was
inherited and the other not, which is unusual.
gregwhitworth: Where did all the other values came from? Seems
like majority of implementations have text and none.
gregwhitworth: I feel like we're overcomplicating this.
gregwhitworth: Why didn't we match what MS already implemented?
Florian: [mentions ugly historical artifact]
Florian: It's close to the MS behavior now
gregwhitworth: Microsoft's position was we didn't want to change
any code but that's the way we're starting to lean.
koji: For blink our storage system doesn't have a mechanism to
have inherited and non-inherited values in a single property
koji: so we'd have to store this for all boxes.
koji: So this will add cost to every single document even if it's
not used.
Florian: I think there was a similar answer from gecko.
gregwhitworth: If the end user scenario is achieved by our
implementation
astearns: Are there other instances with non-inheriting and
inheriting values?
Florian: Technically it's not inheritance.
Florian: The difference between inherit/not doesn't really matter
without the contain value.
dbaron: It does matter if you look at the computed value.
Florian: The OM was never implemented for this property in Gecko I
think.
<dbaron> pretty sure Gecko implements getComputedStyle for all
properties that we implement
Rossen: Ignoring implementation complexity, what makes the most
sense from user perspective?
Florian: I'm biased :) but I think the current spec is more
intuitive, and proposal lets you express the same thing,
with 2 properties rather than one. Some of the new combos
are the same some not,
Florian: which makes me lean to the current spec as being slightly
more intuitive.
koji: I believe we could make 2 properties as Florian said.
Scribe: TabAtkins
astearns: I like the approach of taking this from an author
perspective - what's easier for an author?
astearns: I tend to agree with Florian that a single property
seems easier.
astearns: The complexity just for simplifying how we compute
"auto", if it's not also giving authors something, seems
unneeded to me.
koji: Sounds like we can come up with designs with two properties,
but one shorthand, that make implementation simpler and not
affect author usability?
Florian: If we can do that, in practice the implementation
difficulty you're facing, you can solve it by having the
current property be the shorthand, and the longhand be an
internal property, not exposed to the author.
Florian: That sounds like an action on me to see if the
shorthand/longhand combo can exist, and if it can, if
there's a reason to expose the longhands to the author?
Or is this not where we're headed?
astearns: Sounds promising to me.
* fantasai notes that we're adding an inherited/non-inherited
longhand combo to the 'fill' and 'stroke' properties
Rossen: I'll find you someone who worked on this on our end, I
think that's Matt Rakow. Might want to reach out to him,
he worked extensively on this a few years ago.
Florian: Ok, do you recall if it was easy on your end or if it was
difficult?
Rossen: I recall spending several hours on this, but it was doable.
astearns: I'd also suggest getting some author feedback.
astearns: See if we can discern a preference.
Florian: Probably need to bikeshed it a bit more first; having one
with settled names and one with draft names isn't a fair
question.
ACTION Florian to continue with the shorthand/longhand idea for
user-select
<trackbot> Created ACTION-788
<Bert> Please, remind your AC reps of
https://www.w3.org/2002/09/wbs/33280/css-2016/
Bert: 1 week left to review the charter
astearns: Comment period until the 2nd of September.
Received on Thursday, 25 August 2016 01:29:03 UTC