- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 2 Dec 2018 06:25:01 -0500
- 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.
=========================================
CSS Fonts 4
-----------
- The initial inclination was to solve issue #1744 (Adding lang as a
font-face descriptor) using existing mechanisms like :lang() and
not add a new descriptor. This will be noted in the issue in
order to garner feedback from the proposers.
Logical Properties
------------------
- The group discussed issue #1282 (Flow-relative syntax for
`margin`-like shorthands) in hopes of reaching a conclusion
while consulting with the i18n working group. Ideas floated
include:
- The new syntax should be in the regular value space.
- No one was a fan of using a bang syntax.
- There was discussion around prefixing or postfixing an 'l' to
the existing properties (aka lmargin and marginl) but there
was concern that it would break sort order and look like
it's related to something it's not.
- Another suggestion was to use separators such as 'margin: 1em
/ 2em / 3em / 4em',
- Matching or aligning with Grid needs to be kept in mind as a
part of this decision.
- Ultimately the group couldn't reach a decision during this
meeting. There was general consensus that the intended direction
is property-name or value-level setting and discussion will
continue on github.
Environment Variables
---------------------
- There is a lot of interest in this spec and a desire to get it to
FPWD soon
- Need to solidify list of variables before FPWD
- user-defined variables shouldn't block FPWD
- Variables that are vendor specific was a point of contention
- General consensus is that variables should be brought to the
group to see if there is interest in exposing it across the
web. If there is no interest then the variable can become a
vendor prefixed variable.
- This is supported by the resolution on issue #2820 which
states “UA vendors MUST NOT expose built-in env() features
to the web without going through that process”
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule
Scribe: emilio
CSS Fonts 4
===========
Adding lang as a font-face descriptor
-------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1744
myles: This issue is about the desire of making a font only used by
elements that are on a particular language
myles: So that each element with a particular language gets the
right font attached to it
myles: My particular feeling is that this is the latest step in a
long sequence of changes to add more styling capabilities to
@font-face
myles: Selectors already do that, in font-face we already have a
bunch of other descriptor, and this moves into the model of
adding more styling to font-face
myles: I don't want to implement all of CSS in @font-face, there are
examples on the issue on how to do it using style rules
<gregwhitworth> +1 to myles
addison: If you were to put this in there's a bunch of interesting
problems you need to specify, like how the lang tags match
and stuff
addison: ???
addison: If you name a language for a font-face, you don't render it
anywhere else? How do you enforce that?
emilio: Isn't there a `:lang` selector you could use for that?
drott: That's the example of the issue, yeah
drott: I share myles' concerns and conflicting semantics between
`:lang` an this
drott: I think the intent is using the font in a more fine-grained
way than unicode-range and such, and I think the example also
covers this, you can use css variables to use it as the same
font, but not sure if I missed any part of the use case
addison: I think the idea is to affect how font-fallback works.
addison: That's pretty common for CJK
myles: We already have facilities to do this with CSS
astearns: Looks like preference is to use existing mechanisms for
that, and not use descriptors, we should put the minutes
in the issue and let people comment
florian: Does a note / suggestion in the spec about how to solve
this problem seem useful?
astearns: We should probably wait for more info from the proposers
here
r12a: While seeking further info, one thing to ask is how would you
treat with multiple languages for a single font
astearns: Can that be handled by selectors?
Logical Properties
==================
Flow-relative syntax for `margin`-like shorthands
-------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1282
fantasai: Currently css assigns values in shorthands to the physical
longhands
fantasai: It seems useful to make logical shorthands similarly
convenient, which is useful for i18n
fantasai: but we don't have a proposal for which kind of syntax we
want to have for this
fantasai: One's relative keyword, other is a bang keyword, others is
a different property
<dbaron> I would be pretty strongly against a ! syntax for something
that's part of the property (i.e., not changing cascading).
fantasai: One of the main restrictions is try to keep it
sufficiently easy to type
fantasai: Nothing on the thread seems to have stuck
fantasai: Can we come up with some idea?
fantasai: Other proposals were like global mode switches, etc
fantasai: We could do some or multiple
fantasai: [enumerates other solutions from the thread]
addison: One of the challenges is when you go to make a rtl page
layout you need to edit your stylesheet to flip your
margins, ideally it'd be default
TabAtkins: Something in the value space is maybe the best, like
keywords
TabAtksins: I'd be against punctuation, no precedent and hard to
google, plus not compatible with CSSOM
TabAtksins: Similarly for the bang
TabAtksins: Nor mode switches, dbaron argued against it,
serialization is also harder that way
<dbaron> +1 to tab saying it should be in the regular value space
<astearns> +1 to dbaron's +1 on regular value space
fantasai: Typing "relative" is too long
myles: Will the bang keyword be applicable on every property?
fantasai: Only to some
myles: So part of the grammar of the specific properties, right?
fantasai: Yes
myles: It'd be cool if it works with variables
fantasai: That'd be terrifying
TabAtkins: You should be able to drop a whole relative margin value
in a variable
TabAtkins: And you *cannot* put bang values into variables.
scribe: myles
emilio: Expanding shorthand into multiple longhands depending on
syntax, like overflow, is not something that any other
property has right now. So it's going to require specifying
how you serialize when you have all of the 8 logical and
physical margins. If you want the solution that people will
implement fast, the best option is different properties.
Then, all the machinery is there already.
fantasai: How do we come up with a systematic way of coming up with
a new property that is consistent, short, easy?
emilio: Yes
TabAtkins: We do "margin-se"
emilio: Or "logical-margin"
fantasai: It's way too long. Some people will write all of their
stylesheets logically all of the time, and will stop
using physical properties for the most part. The syntax
needs to be ergonomic enough that it's practical for this.
<jensimmons> It might be faster to implement, but if we hate the
choice 10 years from now, it’s not a good idea
florian: Will we push back against tab here about punctuation?
~padding ~margin?
TabAtkins: If its property names, my objection is different. The
only thing is that would not be an ident anymore.
florian: Can we fix it?
TabAtkins: Potentially but its a syntax change. It would be better
for it to fit in the syntax.
florian: If somebody is using a property that uses idents, this
would break.
TabAtkins: We try to not change syntax
florian: This may warrant an exception
TabAtkins: Yes. I think we can come up with a prefix in alphanumeric
that's short
scribe: emilio
astearns: Do we have anything more on that?
r12a: I agree with that fantasai and TabAtkins that it needs to be
easy to type, I'd suggest `lmargin`
r12a: I think `logical` is a much better word than `relative`
<myles> +1 to not using "relative"
<cbiesinger> +1 for not using relative
<TabAtkins> I think `l` as a prefix works okay. I think we can
reasonably prefix any word with that.
<fantasai> I don't like prefixing with alphanumeric because it's
less obvious what's going on and it won't sort correctly.
<TabAtkins> *post*fixing with `l`?
<fantasai> we use prefixes for the real name of the property, and
prefix relationships are about shorthands
<fantasai> postfixing makes it look like a different longhand of the
physical shorthand
iank_: Any of the bang syntax will probably have very funky
interactions with CSSOM
iank_: setProperty has a different argument for `!important` and such
dbaron: So I think we all don't like the various bang things. I
guess I'm not 100% convinced we want different property
names, I think having it in the value would be slightly
nicer even if we need to sort out a bunch of CSSOM issues,
though it might depend on whether we find appropriate names
for the properties
dbaron: Different properties is probably faster
<dbaron> I guess another option is using a delimiter within the
'margin' value like 1em / 2em / 3em / 4em.
jensimmons: Some of the things suggested where the good syntax is
the old thing that nobody uses 10 years from now
jensimmons: So even if might be more efficient or easier to
implement we should pick a name that is a good name
heycam: I feel like all of the syntax proposed so far is going to be
a bit different and awkward, so I'm not sure the goal of
finding a clean word is feasible
jensimmons: I think lmargin is a bit more awkward than relative on
the value
jensimmons: Some of them feels smoother than others
fantasai: Can you give us your opinion on the different proposals?
jensimmons: I think -new is better than a new name, and keyword is
better than a bang, but I can look at the list as we go
jensimmons: how does it look in 10 years is something to look into
jensimmons: Sticking a random letter in front of iframe hasn't
seemed to hinder its adoption, it seems most people
colloquially speak of iframes instead of frames
Note: iframe stands for “inline frame”
fantasai: Prefixing breaks the sort order, margin-something feels
like a longhand analogous to margin-left or such
fantasai: I'm a little skeptical about prefixing / suffixing. Has the
issue of making it relate to properties it doesn't seem to
relate
cbiesinger: I think lmargin and such are a huge concern, we have
some other messy margin
majidvp: I think mode switch is the easiest. Is the concern about
serialization really a problem? When do you have the
problem?
florian: We have some of that problem with box-sizing and such
dbaron: I think we consider box-sizing a design mistake
<jensimmons> imargin = international margin
<cbiesinger> @mode "logical"; at the top?
<fantasai> cbiesinger, yes that's one option
<fantasai> cbiesinger, the other is a block like @media
<cbiesinger> block seems worse to me
<fantasai> cbiesinger, yeah I agree
<fantasai> cbiesinger, even if we have a mode switch, we might
want to have a way to put a specific declaration into the
other mode, though
<cbiesinger> fantasai, maybe but your escape hatch is margin-left
<jensimmons> What Rachel just said makes me think that `margin: 10px
5px 15px 25px relative;` is more of a “equal” to
`margin` today… changing to a different property infers
that it’s a different thing
r12a: dbaron proposed separators instead, maybe we should consider
that?
rachelandrew: From the POV of teaching this a keyword means that you
can look at your code and know what I'm using here,
seems to infer the intent best
dbaron: I suggested using separators, assuming we do want to move
everyone to that, so that you can do something like `margin:
1em / 2em / 3em / 4em`
dbaron: It's somewhat obscure so it makes the distinction less
obvious, but if it becomes the way to do it it may not be a
problem
fantasai: We use slashes on some places already, so not sure we
could switch consistently everywhere
dbaron: It doesn't need to be a slash, there are probably a number
of symbols we haven't used yet
<cbiesinger> +1 for dbaron's suggestion
dbaron: The other reason it sort of makes sense to me is that the
delimiter indicates a different relationship between the
different values
myles: Looks like if you don't use slashes code work and it'd look
just wrong in RTL
TabAtkins: Since the direction is different it at least sometimes
will look wrong
<jensimmons> also, should we go the other way — to match Grid — ….
???? Crazy. but also....
<fantasai> yes, jensimmons, we will go the other way to match Grid
<fantasai> Grid is using the direction we picked out for logical
4-value syntaxes in general, we just never solved this
particular syntax issue to have them :)
<fantasai> It's interesting to note that the grid-area shorthand
already uses slashes (and is logical)
r12a: So you still have to deal with serialization and such
dbaron: Yeah, that was emilio's concern, we need to solve that if we
handle margins
emilio: You also need to handle compressing and serializing when you
specify all the 8 margins
dbaron: You could condense those to two occurrences to the margin
shorthand, but it's a bunch of CSSOM work
dbaron: That's the 'this will take longer to get done'
<rachelandrew> there is an example of individual properties here for
padding: https://codepen.io/rachelandrew/pen/OQrorW
<rachelandrew> from
https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/
emilio: Note that you also need to figure out how that interacts
with the other sub-shorthands like margin-block /
margin-inline
TabAtkins: Yeah I think finding something using property names would
be maybe the better idea
fantasai: I think you still need a switch to change to physical in
specific cases, and whatever solution we choose needs to
be workable for that
scribe: fantasai
myles: Mode switch at the top of the file, many CSS authors don't
know CSS that well and just copy-paste, so mode switches
would end up being problematic for them
myles: It's harder for authors to understand mode-switches, and
they'll just get it wrong
Bert: Said earlier that it might be a problem if margin expands to
different properties based on whether there's a keyword or
not. Is that true? Wouldn't it expand to all of them all the
time.
florian: Depending on the values, they are propagated to different
values, but always expand out to the same set of longhands
(all of them)
dbaron: At the specified value it is, but at the computed value
level, the two sets of properties compute the same values
dbaron: The way we've added logical properties, they are distinct
properties at the specified value level and they both exist
in the object model
Bert: If you set margin-start, it goes to margin-start
Bert: If you set 'margin, does it also set margin-start or only go
to margin-top
dbaron: We're trying to find a syntax that sets the margin-start
property
Bert: Is it necessary?
florian: ...
florian: We don't have a logical shorthand. If we want logical to be
the default way to write style sheets, we need that.
astearns: Short answer is no the shorthand doesn't expand to all 8
dbaron: Having the shorthand somehow set margin-top so that it sets
the logical thing, could be doable, but would have some very
confusing results
florian: I didn't understand that
Bert: Problem is that the 'margin' property doesn't reset the
logical margins. Can that be changed?
Bert: Like font resets font-size-adjust even though it's not
mentioned
fremy: I'm not sure why it doesn't set it
fremy: These values would never be used
fremy: It doesn't matter if margin resets them or doesn't
fremy: If the order in which you reset them is such that you have
the logical ones after the other ones its fine.
dbaron: That would be one solution to part of the object model
issues.
dbaron: Others around serialization
fremy: Somewhere we have to find principles of doing this, and need
algorithm for this
fremy: I didn't find it yet
dbaron: Might be in a GH issue somewhere
dbaron: Probably don't want to dig too far into CSSOM issues right
now
astearns: This was a good background on all solutions we could
consider, but doesn't sound like we'll resolve today
TabAtkins: Sounds like we're interested in a declaration-based syntax
<TabAtkins> More specific than declaration-level. Property-name or
value-level. (So not declaration glyphs, or ! values,
etc.)
fantasai: I think whether or not we use a mode switch, we will need
per-declaration syntax. Style sheets written logically
will sometimes need to use physical coordinates, e.g.
positioning around images etc.
fantasai: Whether the shorthand resets 4 or 8 of the longhands is
actually still an open issue.
<fantasai> fremy, were you thinking of
https://github.com/w3c/csswg-drafts/issues/3030?
[break for lunch]
Environment Variables
=====================
<astearns> https://drafts.csswg.org/css-env-1/
<astearns> https://github.com/w3c/csswg-drafts/labels/css-env-1
Rossen: This was mostly a status question
Rossen: Where are we, why not FPWD?
Rossen: We have ppl shipping some of it so what is happening
TabAtkins: Quick bit of history, environment variables spec is
something I put together after dino put together a PR on
variables and then didn't respond to feedback
TabAtkins: If Safari is shipping, need a spec asap
TabAtkins: We've been thinking of shipping as well since then, so
our implementers brought up more issues
TabAtkins: We have a lot of issues here
TabAtkins: I haven't been working on this lately, probably why not
FPWD
TabAtkins: If we want to fast track I can prioritize
Rossen: Anything blocking FPWD?
TabAtkins: There's one important issue to resolve on
TabAtkins: List of variables must be vetted
Rossen: It's a pretty short list
TabAtkins: I think Safari is shipping additional variables beyond
that set, is this true?
smfr: probably?
TabAtkins: Big feature to add is user-defined variables, but doesn't
need to block FPWD
Rossen: What is overall thinking about this?
Rossen: Will enable variables supported by platform
Rossen: How do we see such a spec getting to a stable version?
Rossen: That list of variables will increase
fantasai: We have an answer
fantasai: We already decided that any variable that gets added needs
to go through the standards process
fantasai: It's not just a registry that lists things, we need
to define behavior as well
fantasai: so the regular standardization process is appropriate
<myles_> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/ConstantPropertyMap.cpp#L53
TabAtkins: On that note, issue 2820 is specifically about if you are
producing additional variables
TabAtkins: Need to put a MUST NOT ship non-standard variables into
the spec
smfr: We feel the need for an extension point where we can put
things that we don't think should be standardized because
they're only applicable to our platform
smfr: Custom apple things that are exposed in CSS
smfr: Like Apple system fonts
smfr: webkit named image
smfr: special appearance for apple pay buttons
smfr: special color filter for doing inverted color messages
smfr: system colors we expose
smfr: These are all -apple-prefixed
smfr: Then some that are fullscreen
smfr: So I feel we need an extension point that we can add new stuff
that's vendor-specific
fantasai: If it is going to be exposed to the web, then it should
not be specific to safari
Rossen: It could be specific to that particular platform
Rossen: So something available to Mac or Linux not available to
Windows
florian: Inverting screen colors is not apple-specific, not iOS
specific, not Safari-specific
florian: Having a pay button
florian: Many things you listed in their current form are
apple-specific, but
florian: Many should be done in a vendor neutral way
florian: e.g. should be able to have a pay button in Chrome as well
as Safari
fantasai: We want people to design for the web platform, not to a
particular browser on a particular platform
smfr: We have a fancy recipe for a backdrop filter that Apple
designed for its content, and expose to people who want to use
it to look like Apple
florian: If something needs to works on all browsers, it should not
be vendor-specific
florian: If it should not work in all browsers, it should not be on
the Web.
astearns: Consider these sorts of things you're talking about as a
type of user-defined variable?
TabAtkins: They're still ua-defined, they won't be --
TabAtkins: IIRC, when we were discussing how CSS doesn't want to use
prefixes
TabAtkins: If it's actually a platform-specific thing, not just
experimental, then prefixes are appropriate to expose
florian: Yes, but if something is only used for e.g. UI of iTunes,
it should be prefixed *and* not exposed to the Web
florian: If you expose to the Web, it's not vendor-specific
TabAtkins: Anything exposed to iphone will be rendered by webkit
TabAtkins: You write the web page to have special code when you're
browsing with Safari
florian: iTunes UI is an application, it's not like you're going to
read its UI with Firefox
florian: But if you have a website, then other browsers will read
that page or try
florian: Websites should be cross-platform
TabAtkins: ...
florian: iPhone has rounded corners, we should have iphone-specific
thing for handling rounded corners ... but rounded corners
are not iPhone specific
florian: We shouldn't have an apple-specific feature for it
florian: Having these things is not an Apple-specific thing, so it
should be designed as a cross-platform standard feature
florian: None of the examples given here are things that should only
belong to one vendor
[discussion of high contrast and microsoft-specific stuff]
gregwhitworth: I feel like we're talking past each other
gregwhitworth: Everyone likes standards, wants things to work great
gregwhitworth: There's a bunch of stuff listed here
gregwhitworth: e.g. high contrast, system colors, people want these
things
gregwhitworth: These types of things, here's where interest, we
should start to standardize on these variables
gregwhitworth: High contrast in variables, can present what we're
doing
gregwhitworth: Can standardize them
gregwhitworth: but have to ship at some point
gregwhitworth: Where there's no alignment, then that's an avenue for
authors to access ios specific aspects
florian: If I understand what you're proposing agree,
florian: Bring things to the WG, if others might want to implement,
then we work on standardize
florian: but if it's clear that it's not of general interest, then
ship as vendor-specific
florian: That's fine
florian: But don't agree with "just ship whatever you want", may or
may not be candidate for standardization, get stuck with
web compat
hober: We've got product schedules and secrecy requirements
florian: Sometimes you're constrained by business constraints,
that's one thing. But we are discussing best practices here.
dbaron: Have to think about what happens when web pages start using
these things
dbaron: Have trouble finding cases where if one of these
browser-specific features becomes widely used, other
browsers aren't going to have to implement it.
dbaron: use example of inset-radius, let's suppose
hypothetically, that we knew for sure that Apple was the
only vendor that was going to ship a phone that wasn't
rectangular
dbaron: Even in that case, we need to know that this feature exist
and that other browsers need to return zero
dbaron: Or maybe sites depend on it being 10px, and we have to
report 10px
<heycam> dbaron++ ; authors aren't always going to provide fallback
values in env()
dbaron: But either way we need a spec about them, so we know what to
do about them.
<fantasai> dbaron++
<florian> +1 to dbaron
TabAtkins: That's compelling, I agree.
Rossen: So let me try to close the discussion.
Rossen: Clearly I believe there is interest in this spec, by more
than a few of us
Rossen: I want to see this spec get to FPWD
Rossen: Sooner
Rossen: We will work on details, but getting to FPWD should happen
Rossen: Let's move on.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0025.html
<fantasai> RESOLVED: Accept proposal in the issue. “UA vendors MUST
NOT expose built-in env() features to the web without
going through that process” (Issue #2820)
fantasai: We resolved on this in Sydney very explicitly. That goes
in the spec.
Received on Sunday, 2 December 2018 11:26:05 UTC