- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:20:58 -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
---------
- RESOLVED: We are going to create keywords for unicode ranges
(Issue #4573: Add ISO 15924 script codes to
unicode-range)
- The group will reach out to clreq to determine if kaiti should map
to cursive.
- Need to document some criteria for what typographic conventions
merit a separate generic font family. One proposed "sufficient
but not necessary" criteria was, do typographers in typical
publications use distinctions between different these groups of
fonts for semantic purposes?
CSS Color
---------
- RESOLVED: Move serialization [of <color> component values] into
color-4 (Issue #982: Overlap between the definition of
resolving color values and serializing <color> component
values)
- RESOLVED: color() functions, if they have a choice between
percentage and number, they should use number (Issue
#480: Serializing color() values)
- RESOLVED: The `color(lab ...)` function, like the rest of the
color() values, are in the 0-1 (or 0% - 100%) range. And
they serialize the same as other color() values (as a
0-1 number) (Issue #480)
<dialog> Positioning
--------------------
- RESOLVED: Define dialog positioning in CSS terms, probably in
css-position, with aim of replacing HTML's one-off
description (Issue #4645: <dialog> positioning)
- RESOLVED: Define dialog in terms of top layer and a snapshotted
abspos position and alignment property for centering
(Issue #4645)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Scribe: stantonm
CSS Fonts
=========
Add ISO 15924 script codes to unicode-range
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4573
myles: unicode-range takes bunch of code-points
myles: Bad for a couple reasons, lots of numbers and not clear what
they mean
myles: also when adding some like emoji, you can list all unicode
points - but it changes over time
myles: Proposal to add keyword that lets the browsers define the
code points
florian: What are the keywords?
myles: Issue says use keywords from ISO
hober: We shouldn't define these things, reference something in
unicode
myles: Different languages use some common code points
myles: keywords shouldn't be a partition, there will be overlaps
myles: Space character will be in most of them
fantasai: Two factors, script extensions list - some of characters
are assigned to common script because they belong to more
than one (but a limited set) of scripts.
fantasai: we should be looking up script extensions, which tracks
these
fantasai: Other case is super common things - numbers, space, etc
fantasai: A lot of things assigned to common script
fantasai: probably makes sense to include common by default, but
have opt out
myles: We should resolve that we would like keywords, but not
resolve on the actual keywords
fantasai: We should rely on ISO
faceless2: Rely on existing registry
astearns: Should we have everything in the registry
heycam: Do the names in the registry match normal css conventions?
TabAtkins: Looks like no?
fantasai: Should be a list of keywords 4 chars long
<faceless2> https://www.unicode.org/Public/12.1.0/ucd/Scripts.txt
<faceless2> example values : "Hebrew", "Devanagari", "Common"
<astearns> `Zsye 993: Emoji`
TabAtkins: If we're confident they are 4 letters, we can take
directly
fantasai: Think that should be fine, they need to maintain ASCII
compat
myles: We may get it wrong, can we tentatively resolve to try
something out first
florian: Go with 4 letter name of long name? or not deciding
faceless2: Where did four letter name come from?
florian: Long name has hyphens, 4 letter is defined somewhere else
<dbaron> The 4 letter script codes are always letters and come from
ISO15924: https://tools.ietf.org/html/rfc5646#section-2.2.3
TabAtkins: Casing shouldn't be important
astearns: Leave it to the fonts editors to define what keywords we
pull, don't need to resolve on that now
myles: I'll also contact unicode
jfkthame: Should there also be exclusion values?
hober: If you could exclude a range, you could exclude common range
myles: Be careful we don't turn this into a full language
chris: Even if you do a good job, when unicode adds new values you
may unintentionally exclude things
chris: shift burden of defining onto external body
RESOLVED: We are going to create keywords for unicode ranges
<dbaron> also see https://unicode.org/iso15924/iso15924-codes.html
<dbaron> "Zsye" is for Emoji, I think :-/
<dbaron> I think that's a little unfortunate.
The Cursive = Chinese Kaiti equivalent
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4606
chris: First had these thoughts in CSS2, said cursive matched
Cyrillic
chris: How similar is kaiti to cursive?
chris: Would like to see more comments from people who read Chinese
myles: Can we ask i18n?
chris: We should reference clreq
fantasai: Usage of kaiti is similar to how English uses italics, not
really cursive
fantasai: Switching to cursive Latin font in middle of kaiti feels
inappropriate
heycam: See kaiti in children's books
fantasai: Something like comic sans
fantasai: not fully connected writing
florian: Mapping English words like cursive doesn't always make
sense in other language
florian: inconsistent mapping
chris: We don't provide typography for free, better to use
font-family name
chris: If you want something specific say something specific
fantasai: High-level switching can be nice, distinguish paragraphs
fantasai: Think we do need some kind of syntax
florian: Should not map all keywords we have to other language
florian: How far do we need to go? not sure
astearns: We should ask clreq for this issue
florian: What do we want to ask
astearns: Do we need a keyword for kaiti, or can it map to existing
keywords
chris: Authors followed spec in good faith, browser implementors may
need to back things out if we change
myles: Valuable for us to have criteria on when to add new generic
font keywords
astearns: Open page on wiki for requirements of new keywords
dbaron: It's useful to have that in the spec, fine to have
non-normative explaining why the spec is this way
hober: It lets people know how to change it if they see it in spec
astearns: Put in wiki as scratch space
<astearns> some variable fonts are both serif *and* san-serif
dbaron: Can we extract metadata from fonts to help derive these
keywords
myles: Most existing generic font families fail that test
jfkthame: In theory PANOSE should work, but in practice usually not
there
myles: Some criteria for naming, needs to map to more than just one
font file
myles: useful for installed fonts, OS's need to have installed fonts
that match
myles: Other criteria is that at least two OS support a font for
that generic
chris: Not always helpful in underrepresented languages
astearns: But we already resolved to do work on that front
fantasai: So then it's "with appropriate language pack installed"
<fantasai> for some appropriate definition of language pack
myles: Computers don't know, browser dev needs to manually type in
list
fantasai: Threshold should be whether typographers in typical
publications are using distinctions between different
groups of fonts for semantic purposes
fantasai: example is italic vs normal vs bold in latin
[e.g. normal paragraph text vs emphasis vs code]
fantasai: sans-serif, serif, monospace makes a semantic distinction
dbaron: Does serif/sans-serif meet that criteria
hober: Good to come up with criteria, stuck with the ones we already
have
hober: new criteria should just work going forward, may not fit
existing perfectly
fantasai: There are stylistic distinctions sometimes, but can also
be semantic in many others
florian: Criteria is useful for prioritizing, but hard to say yes/no
fantasai: If we meet the criteria, should add; if we don't, we may
add
<fantasai> it's a sufficient but not necessary criteria
CSS Color
=========
<color> serialization
-------------------
github: https://github.com/w3c/csswg-drafts/issues/982
chris: CSS object model has not clear text about how to construct
these color strings
chris: color-4 should obsolete that part of the model
chris: Do people agree? or do we think it needs serialization
chris: Even if you have rgb with percentage, some bits get thrown
away
chris: Should it be in color-4 or OM
emilio: As long as its well defined I don't care
TabAtkins: Prefer color spec
leaverou: Remove it from CSS OM and just point to color-4
florian: Agree, color-4 now has appropriate information to represent
that spec
RESOLVED: Move serialization into color-4
fantasai: Before we remove from OM should we publish it
TabAtkins: Publish both after the move
Serializing color() values
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/480
chris: Dean raised how does the color function get serialized
chris: What's a good serialization, for all the new ones they need
to be floats
chris: any problems with that in OM
TabAtkins: If it's not int it will serialize property, as long as
data model underneath is number
chris: For color you can use 0-1, or 0-100%
chris: 0-1 was simpler
emilio: Consistent with alpha
RESOLVED: color() functions, if they have a choice between
percentage and number, they should use number
chris: Lightness is a percent, how do we handle that specific one
TabAtkins: Percentage and number equivalence is defined as 0-1
equals 0-100%
TabAtkins: so we can't just accept number
TabAtkins: In the color function, just follow the rules - which is
0-1
fantasai: Agree with tab
florian: For match function we take 0-100?
christ: Eventually caved to just take percent
TabAtkins: Could be this one color space takes 0-400, so doesn't
matter
chris: Some people use equipment that gives back L in 0 to 100 range
and no percent
fantasai: Adding the percent sign makes sense
TabAtkins: Don't do the weird thing with lab and percentages (?)
chris: Did it for rgb, so we argued it might make sense for lab
chris: It's longer so not being used as much
<AmeliaBR> We already have RGB functions where percentages map to
0-255 in integers. Because that's the convention for that
data type. If integer 0-100 is the convention for lab.
<AmeliaBR> ... maybe makes sense to follow.
<fantasai> in the color() function?
<AmeliaBR> Ummm… I don't know which syntaxes are allowed there.
<TabAtkins> Proposed Resolution: the `color(lab ...)` function, like
the rest of the color() values, are in the 0-1 (or 0% -
100%) range. And they serialize the same as other
color() values (as a 0-1 number).
RESOLVED: The `color(lab ...)` function, like the rest of the
color() values, are in the 0-1 (or 0% - 100%) range. And
they serialize the same as other color() values (as a 0-1
number).
<break>
<dialog> Positioning
====================
scribe: fantasai
github: https://github.com/w3c/csswg-drafts/issues/4645
TabAtkins: Dialog layout description, two modes
TabAtkins: 2nd one is a very long run-on sentence that's weird and
not described in CSS
TabAtkins: Behavior is useful, but unfortunate not in CSS
TabAtkins: So a few things to do
TabAtkins: First question, is this worth trying to put into CSS?
TabAtkins: Next, quick description of what it is and what might be
involved, to get an idea of how it would work
TabAtkins: Thoughts on whether to describe in CSS, or treat as a
special one-off case in HTML
<AmeliaBR> Define in CSS please!
florian: In general, think it's better to do in CSS
florian: but if extremely complicated * low value, maybe not
smfr: Authors might want to use the same type of positioning for
their own fake dialogs
smfr: so better to have in CSS
* tantek has mixed feelings about this
<AmeliaBR> Defining in CSS also makes it easier to modify / override
with CSS (e.g., by media queries, interactions with other
CSS).
TabAtkins: Aim to get a resolution to add this to CSS, does anyone
object to me putting this into some spec, probably
css-position?
TabAtkins: I'm taking the silence as assent
tantek: Any security considerations wrt lowering barriers to making
fake dialogs?
TabAtkins: Can do in JS already
TabAtkins: So can we take a resolution to that?
RESOLVED: Define dialog positioning in CSS terms, probably in
css-position, with aim of replacing HTML's one-off
description
fantasai: ...
TabAtkins: ...
emilio: It's a stateful position, because you don't want to
reposition the dialog when you scroll or relayout
TabAtkins: Here's the basic description-
TabAtkins: Ignoring stacking context aspect
TabAtkins: except for positioning bit
TabAtkins: it's basically abspos
TabAtkins: where we figure out the offset to apply when it first
comes into existence
TabAtkins: such that it's safe-centered into viewport
TabAtkins: From that point on, it's just abspos -- you scroll the
page, it scrolls off
TabAtkins: If you dismiss the dialog and regenerate, it will
recalculate its position
TabAtkins: Interesting question is when do we clock this point in
time?
TabAtkins: Answer should be when animation starts
iank: Another way to define is in the DOM layer
iank: for the DIALOG element it could query what the layout is and
set the top directly via CSS
TabAtkins: Essentially built-in JS
iank: We do this for other things
iank: It's not great, but might be simpler
<tantek> is it not fixedpos? huh
<TabAtkins> nope, it scrolls if you scroll the page
[so you can see content below the fold, if it's a long dialog]
Scribe: heycam
emilio: My objection wrt when boxes are created is that engines
create boxes at different times
emilio: When you change the display value, Blink will reposition,
because it destroys the box and loses the state
TabAtkins: If you go from not having boxes to having boxes, you
reposition. Having boxes to having boxes, you don't
reposition
TabAtkins: Ian's description was also quite good, smfr what do you
think?
fantasai: To describe Ian's suggestion, at the point the dialog is
launched, the UA sets the top/bottom/left/right properties
to match edges of the viewport and absposes the dialog
fantasai: and then, we use the alignment properties to center it
within that area
fantasai: You don't have to calculate the centering
fantasai: just use the inset properties to bring the abspos area to
match the current viewport area when the dialog is
launched
smfr: Sounds like you're snapshotting the layout viewport
fantasai: You're assigning abspos inset properties so that you're
creating a box that overlaps exactly the fixedpos
containing block
smfr: Wondering if it should be defined in terms of the layout
viewport somehow
TabAtkins: The HTML spec does require recalculating the position if
the viewport changes size
TabAtkins: Guess that's still possible, it's just a ResizeObserver
on the window
smfr: Another question is if the user zooms. Same behavior as fixpos?
fantasai: As abspos, if the user wants to zoom in to see the dialog
they should be able to
TabAtkins: Don't want fixpos magic. abspos with magic setting at a
particular time
fantasai: I think that this works and is simpler than creating a new
magic model with timing implications
fantasai: Question I have is, if you have a dialog that's inside one
of these containing block trapping elements, how do you
get this element to escape and become contained by the
containing block
TabAtkins: That's answered by top-layer
TabAtkins: In this mode it's always kicked into that
TabAtkins: Do need to specify top layer rendering
fantasai: Putting something there changes stacking context and
containing block?
TabAtkins: Yes
TabAtkins: abspos containing block becomes the root
fantasai: How does that interact with transforms or contain layout?
TabAtkins: Layout containment should still be fine with escaping
TabAtkins: and transforms ,it changes its parent
TabAtkins: It's no longer transformed
iank: Yes. it's weird
fantasai: So it sounds like what we're doing is defining a way to
put something into the top layer, out of the box tree,
into this parallel box tree (list) where the containing
block is the size of the entire page
TabAtkins: I think that's the right thing
TabAtkins: Think it's the whole page
heycam: Interactions with full screen? they'll both be in the top
layer
TabAtkins: We'll need to deal with that
TabAtkins: separate but intersecting topics
smfr: Top layers will stack up
smfr: if you have full screen and dialog
fantasai: What's the stacking order?
smfr: Whichever's created first
smfr: but we need to define that
fantasai: It's not as much of a mess as fieldset/legend... :)
iank: Painting wise this is more interesting
smfr: Part of me wonders if we need to maintain compat with dialog
layout. Is this sensible behavior in HTML? Or should we define
something different
smfr: Think only Chrome has shipped
TabAtkins: I've used dialogs in personal projects and enjoyed it
iank: Are we the only ones shipping it?
TabAtkins: I think so
iank: I would be up for potentially investigating what compat risk
there is if there's a more sane model that we think we can ship
iank: The compat thing will be the question
iank: Simon what caused you to start investigating this?
smfr: I was just looking at how the implementation would work in
WebKit
smfr: and I dug into the Blink code and found a function deep down
smfr: in block layout
smfr: Didn't want to do the same thing
RESOLVED: Define dialog in terms of top layer and a snapshotted
abspos position and alignment property for centering
smfr: Can we also resolve on specifying top layer behavior in CSS
somewhere?
smfr: It needs to live along with paint order and z-index
smfr: wherever CSS 2.2 Appendix E will go
fantasai: probably CSS Position?
smfr: or a new spec
smfr: I feel like a paint order spec is probably necessary
dbaron: I think we need a spec for a bunch of rendering stuff,
including common terminology
dbaron: If you remember the big table of horrible test cases for
stacking contexts, etc., we need a spec to cover that
fantasai: So new spec for the painting order
dbaron: CSS Rendering Model or CSS Painting Model?
<tantek> perhaps that could include hit-testing which is directly
related to stacking order etc.
<tantek> more than just painting, the stacking order affects
hit-testing
Received on Wednesday, 19 February 2020 00:21:39 UTC