<Rossen_> trackbot, start meeting
<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
<trackbot> Date: 16 September 2019
<Rossen_> Rossen Atanassov, Microsoft
<astearns> Alan Stearns, Adobe
<oriol> Oriol Brufau, Igalia
<plinss> Peter Linss, Invited Expert
<dbaron> L. David Baron, Mozilla
<stantonm> Stanton Marcum, Amazon
<skk> Hiroshi Sakakibara, Beyond Perspective Solutions(BPS)
<birtles> Brian Birtles, Invited Expert
<heycam> Cameron McCormack, Mozilla
<mstange> Markus Stange, Mozilla
<krit> Dirk Schulze, Adobe
<emilio> Emilio Cobos, Mozilla
<eae> Emil A Eklund, Google
<drott> Dominik Röttsches, Google
<futhark> Rune Lillesveen, Google
<koji> Koji Ishii, Google
<myles> Myles C. Maxfield, Apple
<cbiesinger> Christian Biesinger, Google
<fantasai> Elika Etemad, Invited Expert
<nmccully_> Nat McCully, Adobe
<xfq_> Fuqiao Xue, W3C
<mattwoodrow> Matt Woodrow, Mozilla
<cmp> Chase Phillips, Google
<jihye> Jihye Hong. LGE
<drousso> Devin Rousso, Apple
<fantasai> ScribeNick: fantasai
Rossen_: January is already in
the books
... Jan 22-24 hosted by Igalia
fantasai: Should we resolve on Rego's suggestion to run 10-7pm?
<AmeliaBR> Amelia Bellamy-Royds, invited expert
florian: Reason was local schedules, restaurants don't open until 8/8:30pm
RESOLUTION: Igalia meeting is 10-7
Rossen_: Dates from Apple?
<prushforth> Peter Rushforth, Natural Resources Canada, Invited Expert, Observer
astearns: Tess said she's trying
to reserve April 27-30
... Don't have an update on if she succeeded
Rossen_: Just want to try to sort it out asap, so people who are on tight schedules can finish their scheduling for the spring
skk: Will there be a Houdini meeting?
Rossen_: Not in Spain, in April there will be one
<ekashida> Eugene Kashida, Salesforce, Observer
Rossen_: Possible Summer
locations are Kyoto, France, NYC
... Anyone up for sponsoring F2F meeting?
florian: France is a misunderstanding, can't offer to host in France, but can host in Kyoto but not in July+August
Rossen_: NYC would put two consecutive in USA
astearns: Maybe. April might be in Ireland
Rossen_: So looking at July 20-24 or July 27-31, last two weeks of July
dbaron: That is not the ideal time for Japan, not only because it's warm but also Tokyo Olympics are then
hober: I have dates!
... Did we want to have Houdini, also?
... I have three days confirmed, 4th not confirmed yet
... Booked for Monday 27 April - 29, in Cork, Ireland
Rossen_: Sounds great
RESOLUTION: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020, Houdini afterward (pending booking confirmation)
Rossen_: Back to summer
... Who was offering to host in NYC?
dbaron: Think it was Una (Google)
TabAtkins: We can probably do it
Rossen_: Ok, check about it and let us know
TENTATIVE: End of July 2020 in NYC
Rossen_: Proposed to publish a PR of CSS Contain 1
florian: Afaict, it's
complete
... All tests pass in 2 browsers, except those which depend on
other less-mature specs
... So I think we are ready for PR
... One more note, all tests pass if we don't count the at-risk
feature
<dbaron> https://drafts.csswg.org/css-contain/issues-2019-cr.html
florian: the style containment is
not implemented properly anywhere
... but that's why we marked it at risk
<dbaron> https://drafts.csswg.org/css-contain/implementation-report-2019-09
<dbaron> https://drafts.csswg.org/css-contain/annotated-2019-09-05.html
florian: so my request is to drop it, go to PR, and publish FPWD of Level 2 which just contains that feature
<dbaron> https://github.com/w3c/csswg-drafts/labels/css-contain-1
<dbaron> https://drafts.csswg.org/css-contain-1/
Rossen_: So PR version will have
3.3 dropped for Level 1
... Objections on resolving to publish PR of CSS Contain 1 with
dropped section?
dbaron: Is the state of style containment that implementations are shipping support and not passing tests, or not shipping support?
eae: Combination of both
florian: Chrome ships a buggy one, and Gecko doesn't ship iirc
heycam: We don't recognize the value
smfr: Are the two implementations blink and gecko?
florian: Yes
Rossen_: Hearing no objections,
RESOLUTION: PR of css-contain-1, dropping style containment (at-risk)
florian: For Level 2
... if we add new features, need fpwd, but if not adding a new
feature can go directly to CR
<astearns> explainer: https://github.com/WICG/display-locking/blob/master/explainer-content-size.md
chrishtr: Posted a new
explainer
... content-size is a new CSS property
... If 'contain: size' is specified, content-size is treated as
intrinsic size of contents
... proposing that be able to set intrinsic width/height passed
to intrinsic sizing algorithms
... Reason we believe it's useful is that you can use it when a
subtree is not yet ready or you don't want it to have its own
layout
... can express a placeholder sizing for it
... Allows communicating that placeholder sizing, so that
flex/grid/table/etc can take that into account
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4229
chrishtr: If we've skipped rendering as an optimization, dev can use to communicate placeholder sizing
SimonSapin: Would this property apply without 'contain'?
<Rossen_> a?
chrishtr: When you don't have
'contain: size', no
... Only applies when 'contain: size'. Reason is that 'contain:
size' causes no competing intrinsic size
... 2nd reason is that it fits neatly with render subtree
attribute proposal
florian: Can you expand on the
second point? I'm not faimilar with that
... In isolation proposition makes sense, but not sure why it's
not coupled with a more generic intrinsic size feature
TabAtkins: One reason was that,
as chrishtr said, that means you have competing information. We
don't think that's useful to have two sources of truth
there
... Seems like only time you need to provide a better intrinsic
size is when you're contain sizing already
dbaron: I'm skeptical of
that
... I think there are a bunch of cases, where intrinsic sizing
doesn't provide good results and devs might wnat to provide
it
... Talked about some o those cases in the past
... Some cases devs want to override only in one dimension
TabAtkins: Bad behavior of
intrins scorllers maybe?
... flexboxes blowing up
dbaron: Didn't have that in my head, but sure
TabAtkins: That's intriguing
AmeliaBR: Also cases we've had
where certain modes cause things to collapse down to zero, and
might be better not to
... Lots of cases there might be a demand for it
... Wrt naming, 'content-size' might be interepreted as size of
content-box
... If there is a limitation, tho, should be good reasons for
it
TabAtkins: Yes, happy to come up
with better name
... Cases that fantasai and I identified where boxes get too
big in intrinsic sizing, and currently don't have a way to opt
into better behavior
... In some cases can inflate itnrinsic size, others might be
able to shrink
... good idea
<florian> fantasai: Support florian and dbaron , this should probably be a generic mechanism
<florian> fantasai: the value space would be legacy | auto | <size>
<florian> cbiesinger: what is the diff between legacy and auto
<florian> fantasai: scrollers collapsing to 0 or not
<florian> fantasai: if inside a flex item, there is an overflow:scroll pre element with a very long line, the min-content size is the size of the very long line, that makes the flex item be very large, even though we could just have made it into a scroller
TabAtkins: Semantics are still a bit funky, if you provide a size wouldn't do anything unless you're contain: size
fantasai: Well, I think it would
dbaron: I would also note that there are cases where intrinsic sizing provids sizes that are too small, e.g. in cases with percents
<florian> fantasai: if you specify an explicit size, that takes over and you ignore the content
TabAtkins: Could do that... was wondering if you wanted to max them
AmeliaBR: Doing a max or min
doesn't work if we want to accept both use cases of dealing
with cases where intrinsic size is too big or too small
... Just say if you specify a value, you wanted to override
chrishtr: All these examples that were alluded to but not explicit, please write into issue
fantasai: Based on discussion, this doesn't go into contain, goes into Sizing level 4
<florian> fantasai: based on this discussion, this goes into sizing-4, not contain-2
Rossen_: Anything else on this topic
TabAtkins: Discussion was good
chrishtr: Point Florian raised
about, what are you talking about wrt render subtree
... maybe wait until we talk about that
... but 5min background on render subtree, though it's on the
HTML spec
... package, how they fit together matters, so just want to
mention
Rossen_: we can put that topic next
chrishtr: Just want to give an
overview of what it is, what use csaes are, how it
functions
... so can get some feedback
Rossen_: So content-size, or
whatever we're going to call it, will go to size level 4
... Any objections to add it?
<chrishtr> Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md
TabAtkins: maybe call it intrinsic-size
fantasai: Nobody wants to spell that
TabAtkins: true
fantasai: There was a suggestion
that this be split into width/height not one property for both
dimensions
... Seems to be the proposal is
foo-width/height/inline-size/block-size
iank_: legacy as initial value?
PROPOSAL: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
RESOLUTION: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
florian: We could go CR directly,
but we might want to change things so maybe fpwd is
better
... some suggestions, e.g. single-axis contain, etc.
... might want to add
RESOLUTION: FPWD css-contain-2 being copy of css-contain-1 (including at-risk features)
chrishtr: I posted alink to an explainer earlier
<chrishtr> Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md
<chrishtr> https://github.com/whatwg/html/pull/4862
chrishtr: PR for spec idea
... render-subtree attribute is an attr you can put on any HTML
or SVG element
... Has one or more keywords that are space-separated
<bkardell_> ... or mathml?
chrishtr: ex.
rendersubtree=invisible
... what that means is that it is invisible, but takes up
layout space
... and also is designed so that UA doesn't need to do any
render work for that subtree
... no heuristics to figure out whether needs to render that
subtree
... you load a web page
... bunch of content not on screne atm
... you like that page to load quickly, not have extra layout
cost
... not load external resources
... etc.
... for stuff that's not on screen right now
... common because scrolling is common on web, and large
websites
... what does attriute do when set to invisible?
... First, it applies layout, style, and size containment
... layout containment is good, content below can't escape
layout of the element at the root of the subree
... size containment for imilar reasons
... dont' need to know layout to compute layout of the
page
... so don't need to do layout, don't need to paint it,
... not painted to screen and not hit-testable
... so don't need to do any work as UA to process that DOM
subtree
... is present, but doesn't cause any work
... that's the core value-add of the
'rendersubtree=invisible'
... Other value syou can add
... If you say that rendersubrree is invislbe and activatable,
what that means is that UA is allowed to mutate that attriute
to be empty string
... to render the content
... e.g. wikipedia, stuff below the fold
... wikipedia markes as activatable
... and invisible
... when user or a11y API wants to look at that content
... or user wants to do find-in-page operation
... and UA notices the content is below the fold off-screen
content
browser would be able to cause the content to rnder
chrishtr: which has effect of
causing it to render
... and script can observe the mutation of the attribute
through a mutation observer
... takes some action to help
... or in simplest cases, content is just rendered
... important because lots of UA algorithms not controlled by
authro
... e.g. a11y, anchor link navigation, tabbing between
focusable elements
... scroll-int-view operation, find-in-page
... finally, two additional keywords
... one prevents external resources from being loaded
... image wouldn't be loaded until whole-loads keyword is
removed
... avoids blocking network pipeline for stuff below the
fold
<astearns> ack 'dis
chrishtr: useful for feeds of
info like fb, twitter, also for page with lots of images
off-screen
... This is a lazyloading feature similar to what chromim is
trying to ship
... Finally, web component element upgrades
... if you have custom elements defined in your registry,
... if element was registered, runs create callback
... allows dev script to participate in rendering the custom
elements
... but if elements are off-screen, then cost isn't
desirable
... dev would prefer not to run script until content is
on-screen
... way this fits in with content-size is that if you set the
render subtree attribute to 'invisible'
... has containment
... therefore content-size would take over sizing of unrendered
content
... this way, when content is subsequently rendered via UA
action or dev activation
... layout doesn't jump around
... contain: size is only applied when invisible
... when not invisible, then it will no longer have
'contain-size', automatically uses actual size
... intrinsic size without size containment might be compelling
enough to drop this connection, but that's what we were
thinking
...
... 'display: none' doesn't help for off-screen content because
idoesn't take up layout space
... 'visibility: hidden' doesn't stop layout, and also can be
overridden by descendants, so have to render through the
subtree
Rossen_: 'display: none' + 'contain: size"
chrishtr: display: none box is
gone
... rendersubtree=invisible, the box is still there, only its
contents are gone
... you could have e.g. a spinner erndered in the elemetn, or a
pseudo-element, but don't actually render the subtree
smfr: What's the behavior when element with visible subtree changes to invisible
chrishtr: if you just add
`rendersubtree="invisible"` to element
... it'll apply contain: style layout size
... and not render the contents
... but element itself will still read
... script can still read style, could cause layout
thrashing
smfr: so toggle from visible to
invisible, ...
... does it give you a stale value?
chrishtr: Will do the work to get
you the right value
... doesn't cause it to render, but has to do calculations
smfr: seems a bit magic, like a
hack
... seems like maybe it should be a CSS value, e.g. new keyword
to 'visibility'?
chrishtr: if it was a CSS
property, would be weird if UA overrides it
... but made attriute so UA can remove automatically
smfr: Worried about circularity
about activatable
... e.g. user hits Cmd+F to start a find
... I thin kyou have to bring in the subtree in order to search
it
... because have to check 'display: none'
chrishtr: Don't have to show on scren, but have to compute style
smfr: activatable has side-effect of removing the attriute?
chrishtr: If you try find in
page, UA will do the work necessary to compute the disply: none
part of pipeline
... if it matches query, would activate the subtree
smfr: Worried there are some
things that are not specified that end up affecting the
activation behavior
... Spec says activation depens on UA behaviors, different
browsers iwll have different activation policies if we don't
standardize
chrishtr: explainer lists which
actions cause activation
... scrolling doesn't, JS scrollIntoView does, a11y access
does
Rossen_: We have built up quite a queue
florian: Maybe I missed
something, one part I'm confused about
... what'
... what's the use case for invisible without activation?
... I think author will probably miss some important cases if
it's not activatable
... Also, feels like it's something like a delayed or sync
value for visibility
... you're allowed to delay, but once on screen please
show
... most enefits when combined with contain,
... but conceptually could be separate
... you're allowed to load the assets later
... wouldn't need to override the value, just permission to do
it later
... maybe that covers requiremtn for running scripts?
... rest feels like it could be in CSS somehwere along the
lines that smfr was talking about
... would like to also know why have a version that's not
activatable
chrishtr: Suppose youhave content
that is not fully loaded, don't want to show to user. That's
why you don't want it to be activatable
... wouldn't be visibility: hidden because not performant,
layout subtree still applies
myles: if you wnat to leave space
for it, you can set visibility: hidden for it, will leave
space
... if you do want the pop, can set display: none
florian: would combine visibility hidden with contain, to reduce jank
TabAtkins: will have jumping because the content hasn't loaded either
florian: but would use 'contain'
and 'content-size' as well
... why needs an HTML attribute
TabAtkins: Doesn't allow us to
not do layout
... which is a problem if wanting to load 10,000 nodes worht of
content
florian: so would want 'visibibity: ...', whic would allow delaying
TabAtkins: recall reason chrishtr
just said aobut having invisible but not activatable
... element is in state where it's waiting for stuff to
load
... dont' want to allow activation until finished
AmeliaBR: had same question
... but final comment, might want to consider making
activatable the default
... authors might *think* they know when to activate, but
haven't considered things through very well
... so suggest to make default acticvatable, author has to
explicitly request non-activatable
myles: might be problematic to have elements callback in unpredictable order?
<AmeliaBR> e.g. `inert` version for non-activatable
chrishtr: Can use this feature to
automatically activate content which is below the fold, or not
even actually visible
... e.g. tabbed UI or content hidden behind a ? that can be
opened by the user
... e.g. details element
... still want user to be able to find that content and
navigate to it
... currently, that's not really possible
... e.g. yu have content in anotehr tab of the ui, or
subwidget
... nm, nother reason for activation
heycam: two things: one, want to
echo what smfr said
... I feel like behavior when subtree isn't rendered seems like
CSS kind of feature
... recognize that overriding the style value of some property
doesn't feel great
... but otherwise feels like some new 'display' value, like
'display: placeholder' which only generates frame and not
contents
... Some kind fo solution where it's somehow reflected in CSS
property dispaly would be nice
... 2nd point was about automatic avtivation behavior
... have you consiered solution where you have strict callbacks
for events for these types of activation behaviors?
... so dev can choose to catch events and decide whether to
flip activation
chrishtr: So suggesting that script shoudl be able to observe activation
heycam: wonderign if that's a design that you've considered
chrishtr: did consider that
design
... and prototyped in chromium
... the event fo this, which we calle dactivate event, was in
psec proposal
... but makes sense and is convenient to add
... technically can be implemented with mutation observer, but
might be inconvenient
heycam: one advantage of that
might be that you could then have a new display proeprty value
that does the actual work of that
... and let the author change the value of that property
chrishtr: so tell dev that "i
would liek to activate this, please help me out"
... problem is defautl behavior is not good
heycam: author specifying 'display: placeholder', on you to complete the solution
chrishtr: comments about flipping default activation, should make it easy as possible to adopt feature without unintentionally breaking accessibility
TabAtkins: copy-paste two-line
activation script on every page that uses this feature
... that's not so great
... If they dont' want it to activate, they can use the don't
activate value, and have that work as intended
automatically
... back to display values, while I wouldn't fight too hard if
we decided to add a display subproperty
... but doing none-typed things in 'display' itself is
problematic because lose typing
... this is really bad
chrishtr: want UA to be able to
activate for you
... with recent testing with partners etc, does seem to be a
use case for controlling things with a style sheet
... sometimes convenient to do via CSS
<fremy> @chrishtr: added some notes over here: https://github.com/WICG/display-locking/issues/78
<TabAtkins> aka you can't set "display:flex" on the element without paying a *lot* of attention to specificity, or else you'll accidentally override the hide-contents value
<florian> fantasai: same concern as AmeliaBR about making the activatable version the default
<florian> fantasai: It would also be good to have the attribute map to some css construct, instead of having the HTML do its own magic
chrishtr: Less magical means harder to cleanly spec, and some use cases are lost
myles: see readme and whatwg pull request, how do I comment?
chrishtr: I think the pull request ahs a correspondign issue in whatwg, good place to ask questions
SimonSapin: similar to 'display:
none', but different in that only contents are hidden
... how is this different from 'display: none' on children?
TabAtkins: Text content that are
direct children can't be styled
... but also 'display: none' implies a lot of things
Rossen_: animations, do they run on your subtree?
chrishtr: no
Rossen_: so that's also same as display: none
chrishtr: Subtree boxes do have
CSS boxes
... conceptually are laid out, just don't need to do work
unless forced by script
mattwoodrow: what si additional
contstraint that we get over 'contain: all'
... couldn't UA optimize by not rendering anyway?
chrishtr: it's an explicit
API
... rather than combo of CSS values
TabAtkins: off-screen 'contain',
animations still run
... You will fall down accidentaly perf cliffs
mattwoodrow: so it will block animations?
TabAtkins: among other things, yes
bkardell_: I could be misreading this and not understanding, but sounds like the intent is for the UA to actually change the attribute?
chrishtr: yes
bkardell_: is there a precedent for doing that?
TabAtkins: there's one precedent
bkardell_: think there's been 1000 times that's been suggested, and push to not do that
TabAtkins: one precedent,
details
... for similar reason to details, nice thing about directly
manipulating attribute than a hidden state
... don't need to expose a new way to report actual value
... and don't need to expose to CSS using custom selector
... just use regular attribute selector
... as long as attribute value is easy enough to work with, and
this one will be simple,
... there are usability benefits that come with this for
free
cbiesinger: value attribute of input?
TabAtkins: those don't change
Rossen_: OK, thanks for
introducing topic, chrishtr !
... ppl wanting to participate, please do so at links
provided
<br duration=25min>
<chrishtr> Issue for rendersubtree: https://github.com/whatwg/html/issues/4861
Note: break-out session on rendersubtree Wed at 2:30pm??
<AmeliaBR> https://github.com/w3c/csswg-drafts/issues/4307
sanketj: Want to talk about new
propoal about highligh API
... builds on top of existing css-pseudo-4 spec
... existing spec allows styling native highlights of the
browser: sleection, grammar-error, spelling-error
... can style how you want
... this is useful for editing apps
... implement own selection, spell-check, grammar error
... currently authors use spans
... some problems
... can be complicated, particularly if span across multiple
subtrees
... then adding/removing creats perf problems
... wrt invalidation etc.
... users can add/remove highlight using dom ranges
... since can span multiple subtrees, easy to code
... invalidationis only paint invalidation, due to how
highlight pseudo elements worok in css-pseudo-4
... will overview first, then ask for feedback, also some
issues
... iff ppl support concept, would like to move towards
official spec
... two key pieces: one is cssom piece, one is a sleector
... adding two new types: highlightRangeGroup
... provides a group of ranges to be handled ogether
... similar to find-in-page, range per instance of term
... want to style at once
... so style all together
... highlightsMap takes a name key and group as a value
... introducing a global map per document, contaisn all
user-defined highlights
... way user adds a highlighRangeGroup is calling .set, user
will give a name and use that as key itno teh map
smfr: user meaning author?
sanketj: yes
... two properties on highlightRange which are
interesting
... .style property and .?
... connection from highlightsMap to group is important
... to make it stylable
... can only style stuff in the highlightMap
... to style introduces new pseudo,
::highlight(hlight-name)
... same properties supported as other highlight pseudo
elements
... can also use .style property
... works just like cascade
... inline style wins
... multiple highlight range covering same content
... example
... Here we have two overlapping ranges, some text contained in
both ranges
... each in its own hihlightrangegroup
... one is bg yellow, one is bg orange
HeWenli: what color is the overlap?
sanketj: what is the order?
... we use the timestamp of addign to the map
... if author wants to change that, they can set higher
priority
... default priority is zero
... but can change .priority attribute on the rangegroup
... that is core pieces of the proposal
... want to pause and ask for feedback
Rossen_: already have a queue, so let's go through that
TabAtkins: Question about the
reasoning for having ragnegroup isntead of multigroup, but you
explained with priorities
... wrt that, is priority 0+ or can be negative?
sanketj: can be negative
... want to discuss how priority relates to otehr pseudo
elements
TabAtkins: any ties, then fall
back to timestamp order?
... one more question, is intention that,if took that example
calling foo again, would it ahve a newer timestamp
sanketj: no, timestamp is established when first added to the map
plinss: timestamp order same as iteration order of the map?
sanketj: yes
<TabAtkins> Yeah, so that means even setting "foo" with a *different* highlight group would also not change the timestamp.
florian: first comment, really
like this, many of us have been thinking of doing something
like this for awhile, actually doing it is great
... there already is a similar notion of ? for built-in
highlights
<TabAtkins> (Which totally works for me; phrasing it more explicitly as the map iteration order would make me a little happier.)
florian: not only important to
say which one wins, but what does it mean to win, which can be
different for different things
... so important not to re-invent a new solution for custom
pseudo than for highlights
... and have the resolution be the same mechanism
sanketj: that's one of the issues I wanted to talk about
emilio: few questions, first how
does this interact with shadow DOM and general scoping?
... CSS map is global, but rules that apply...
... global ::highlight speudo that spans shadow tree and part
of light DOm, what si the style of that?
sanketj: good question
... as currently specced, you have a range in ShadowDOM and
some outside, all styled by global map
emilio: do normal css scoping
rules apply?
... global parent group, that will apply to non-shadow-dom
group, but not shadow dom group
... do you explain how different groups intersecting priority,
have to decide
... when you specify some proeprties in some range and not
others, do you still apply properites of the other range?
sanketj: you have one group applying bg color and one applying color, overlapping portion gets both of those
emilio: how do you specify that
florian: we have this problem
already, and it's specified in css-pseudo-4
... because we have same situation with
selection/spelling-error/grammar-err
... whichever we resolve it, must be same for custom ones and
normal ones
emilio: a bit annoy8ng but fine I guess
dauwhe: higher-level question,
Web has been struggling with identifying arbitrary ranges of
text for a long time
... stuff like Web annotations etc.
... does this complement those efforts? is it independent of
them? how does it relate?
BoCupp: I would say that they are
complementary. This doesn't do anything to identify arbitrary
text fragments in a URL to idetnfify a range, etc.
... some places in DOM you can get a range, some cannot
... this is just about applying style over a range
hober: There is a propsal right night for some kind of find-i-page fragment syntax, and would be useful to talk to those people
Rossen_: who has proposal?
<tantek> See Fragmentions for existing work on this too: https://indieweb.org/fragmention
hober: willd rop in minutes
<tantek> deployed on a bunch of sites
atotic: Any restriction on styles you can apply?
sanketj: set of properties youc
an apply to highlight pseudo is same as for other highlight
pseudos
... fairly limited
<AmeliaBR> Text fragment in URL proposal: https://github.com/WICG/ScrollToTextFragment
cbiesinger: Have you considered making priority part of highlight pseudo syntax rather than in JS?
<florian> fantasai: it's more a question of order. For regular element, we have the DOM order, but for pseudos we don't. For the built-in ones, we specificy that order into the spec
<florian> fantasai: but for custom ones, we need to specificy where they fit
<florian> fantasai: this isn't something you want to redo everytime you select something, so it doesn't belong in the selector
heycam: I like the proposal, wanted to be able to do for awhile
<florian> fantasai: we could have a declarative mechanism in addition to JS, but selectors isn't it
heycam: two questions,
... is there a need to style ranges that match multiple
higlihgts at the same time
... rather than just styling all of the individual highlight
speduos
... if you have a comma separated name of highlight
speudos?
sanketj: trying tunderstand
... if you have multiple ranges, would you need to style them
separately if the same content?
heycam: would you need to be able to style, say I want this style when I match both "a" and "b" type of highlight
sanketj: scnearious we're looking
at, they are independent
... one implementing spellcheck, one impelmentign selection ,
etc.
... want both fo those styles to show up
heycam: two styles of text decorations are underlining, maybe you want to style slightly differently if two underlines
BoCupp: so if you have a range
that is overlapping two range groups, e.g. this section is
currently selected and also a found word
... when combination comes together, you want to pick a
different color for that?
... don't have a good scenario for that
heycam: the built-in highlights,
theyr'e not exposed in the JS API, would it be beneficial to
expose those?
... so you could set .style on them, too
sanketj: maybe
<foolip> Are we set for a WPT/CSSWG meeting tomorrow at 9am?
dbaron: I'm also a big fan of
this, we've talked about having a feature like this for
awhile
... some questions
... a little concered about ergonomics of the JS api
... one common thing a user will want to do is create a range
and add it to the set of something
... say the set is called grammar-error
... my reading of what you have in the JS API is that the way
you do that is going to be different depending on whether
you've added a grammar error before
sanketj: in scenario you're
adding a grammar-error
... if you are creating range for grammar errors
... user types something, new grammar error appears
... grammarly made the group and has to keep track of the
name
... they need to keep track of that info
iank_: mentioned someone makeing such a library would ...
dbaron: seems awkward to create
all your global errors up front rather than initialize
... reminds me of various set APIs that have e.g. get APIs that
have "get this object out of the set, and if it doesn't exist
make me one"
... it seems like this API should have that mode
... maybe some other way to structure API
... other thing is that I'm not sure, there's a bunch of new
work in pseudos spec
... unsure if implemented
sanketj: wanted to check status of implementation itnerest of pseudo-spec
dbaron: if those are not
implemented, I'd prioritize interests of getting this
implemented over those
... having generic mechanism work reasonably is more important
than having existing spec work
florian: the thing that makes
them tricky to implement isn't which one exist, but how do they
work?
... we ahve to figure that out for built-in and for
custom
... if we implement custom things and drop built-in grammar and
spelling-error standard, I don't mind
... but definign how the cascade work etc. is still needed
dbaron: yes, but if that work doesn't extend well to an arbitrary list rather than a specific list, then given that at least it's not implemented, we should fix the cascading/etc to work for arbitrary list of classes
chrishtr: wanted task your current thinking wrt performance of DOM mutations
sanketj: open issue on this
... static range is one of the otpions thinking about
... might be useful
... also going to discuss this topic in editing TF later this
week
... any other APIs to make this useful
... if you have static range, do you still need live
ranges?
... I'm not sure
... but would like to not just restrict it to ranges
chrishtr: Appreciate taking it
seriously, ranges have been a significant perf problem
... each API that changes DOM has to check that range is still
correct, it's a problem
skk: We are develoipng viewr for
weak eyesight
... using text-to-speech using ? API
... is it possible to synchronize with speech?
sanketj: Currently, the
accessibility concerns haven't been addressed
... true for all higlights, I think. Don't think have a way to
say spelling error exists here
... so still need to figure out
birtles: priority field feels a
bit like z-index
... are there any alternatives like a relative ordering?
... I'm concerned that an extension hlgihglts ranges in the
page, going to be a highlight war to get higher priority in teh
page
<dbaron> floating point numbers!
sanketj: regardless of option, need to have some kind of recommendation of how priority would interact with application priorities
<TabAtkins> fantasai: I think that setting the prio rleative to the prio of the builtins is easy, you just set it a prio.
<TabAtkins> fantasai: Probably you just set it to 0.
<TabAtkins> fantasai: That doesn't answer brian's question, which is multiple libs competing.
<TabAtkins> fantasai: so how do they coordinate rather than just assigning random numbers?
fantasai: cuz most of them will then try to assign max-int
BoCupp: I don't think you can
coordinate things that are inherently uncoordinated themselves,
there has to be an integrator
... when frameworks brought together in the web app, maybe grab
each one and set its priority to say which is more
important
... extensions like grammarly, go app by app, look at how do I
integrate with each appSpeechSynthesis
... dont' do it blindly, do it after investigating the
app
... today have to figure out how to integrate spans into app
without breaking, this would be much less invasive
birtles: quick example of
relative ordering
... my app does highlights for a short time, so should be above
grammarly's hiighlights
... with priority approach, I might see that grammarly uses
1000, so I use 1001.
... but then grammarly upgrades to 2000
... maybe have an API that give me the highiest available
priority, or priority above this particular name
sanketj: currently best could do is iterate map and get the highest priority
<heycam> maybe a priority name like "transient" would work?
johannes: Grammarly tries to
integrate with other apps, in cases where it cannot, it usually
just breaks the app
... in gmail, can't integrate with it, your email is just
gone
... grammarly is trying to do this for awhile, but it's not
working unless you have central registry
rune: Thinking about cascding and
inheritance
... div::selection, implementations aren't using that style for
span::selection in the div
... concerned there will be too much inheritance
BoCupp: A few questions about
priority and inheritance
... maybe we should go to the issues?
rune: just a general worry
... maybe we should fix that in implementatiosn before adding
lots of new ones?
<Zakim> fantasai, you wanted to reply
sanketj: priority property is
currently just distinguishing stacking order for user-defiend
highlights
... wnat to discuss how that relates to native highlights and
combination of the two
... if we extend to native highlights, two pieces here, what is
default priority for user-defiend highlights relative to native
highlights
... if user wants to customize that, what is mechanism?
... some scenarious useful
... nwhen author is buildign some editing capability, but using
native capabitily for something else
... might impelemtn find-on-page, but use UA's selection
... and want that to show up above their find-on-page
... in other cases might want to show over the UA
selection
... solution I propose is that by default, author-defined goes
below UA-defined
florian: I agree
BoCupp: Is there a need to
interleave with the UA highlights?
... having phase above or below that is probably easiest
<florian> fantasai: the painting rules are already interleaved
<florian> fantasai: background is painted before, text decorations are on top
<florian> fantasai: it's inevitable that things interleave
sanketj: spelling-error and grammar-error, is one group
<florian> fantasai: but if you've got mulitple of them trying to set the same property, the one needs to win
sanketj: selection, find-on-page
different
... let's say user wanted to impelemnt their own spell-check
and use their own styles
... but wanted to use browsers' grammar-error, is there a way
to maintain that stacking order?
... because selection and spelling error are different styles,
then would get both
<florian> fantasai: there might be a way to allow the UA defined ones to be manipulated the same way as the custom ones
<florian> fantasai: if you had the native ones in that same map, using standard names, the author could style them, change their priority...
<florian> fantasai: the author could possibly also replace the range objects
<florian> fantasai: so the author could take over built in ones, instead of duplicating
<heycam> +1 I was just thinking the author may want to use the browser's native styling for grammar etc. with their own range, so it may make sense to expose them in the map to allow that
fantasai: also worth noting that we have spelling-error and grammar-error text decoration styles, so you can duplicate that styling if you want to for other types of highlights
florian: need to be careful about
priorities
... and thining about them
... it's not quite about in front / behind
... because even if you have lowest priority, your foreground
will be over the background of the ghighest priority
... some degree of interleaving is inevitable
... if there is a priority that doesn't allow ?
... not sure bannign it would sovle the impelementation
problem
... backgrounds are behind, shadows, then text
BoCupp: ....
... we reasoned, does anyone need that, what are schenarios?
would you replace grammar/spelling errors?
... fishing for scenarious taht would reuqire a more capable
API
Rossen_: one procedural
recommendation, since running low on time
... hearing quite a bit of support and interest from
CSSWG
... something that has been needed for quite some time
... I suggest that we transition into figuring out where this
work is going to go
... and start transfering text into an actual spec, and star
tracking issues in our GH tracker
... if going back to explainer, where would work need to be
split out?
... there's some selectors and then some actual speudo
explanation
<dbaron> fantasai: I'd say either its own spec or the pseudo elements module.
fantasai: Would suggest ether its own spec, or integrate into css-pseudo
florian: Starting as own thing, amybe merge into pseudo maybe split it
sanketj: also question on
name
... earlier proposal was range-decoration?
<astearns> +1 to OM concerns mixed in the feature, instead of in a separate spec
fantasai: css-highlight-api
<tantek> +1 fantasai
Rossen_: Any objections to adopt as ED, with sanketj as editor?
dbaron: adopt as new ED or
integrate into css-pseudo-4?
... I'd prefer integrating into css-pseudo-4
... would prefer the closely related things be in the same
document
iank_: that said, might be easier to iterate on API if separate
florian: can revisit during FPWD time
Rossen_: so maybe start as separate spec and integrate later?
TabAtkins: an issue into css-pseudo-4 pointing at draft to be integrated later
Rossen_: any co-editor?
florian: propose myself
sanketj: ok!
hober: me too
RESOLUTION: Adopt css-highlight-api as ED with sanketj, florian , and hober as editors; add issue into css-pseudo-4 for where it might be integrated pointing at the ED
<eae> <br type="lunch">
<astearns> starting back up soon
<myles> ScribeNick: myles
emilio: Is this microphone on?
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4239
emilio: The spec sepcifices a few
situations where if a given style chagne happens, you don't
apply any scrolling adjustments in thecontainer. This is done
to avoid manual sticky effects. This is done to prevent them to
breaking.
... even with this heuristic, we have still found either broken
pages that for example, once you scroll to the bottom you can't
scroll back up, or they do things that in the regular cases you
want scroll anchoring to apply, or pages that get burn a bunch
of CPU in infinite scroll event listeners because scrolling
triggers more scrolling listeners. This is possible in both
chrome and firefox.
... What I did to fix it is to never apply any adjustment for
scroll anchoring if you are processing a scroll event listener
for htat node.
... When you fire the scroll event listener, you remember the
target of the event, and if the element matches, you don't
re-fire
... this is mainly to prevent bad scroll events. I'm just
interested in feedback from implementors
<missed> : Chrome implementors are in agreement
emilio: Steve Kobes is no longer working on this
eae: No one is working on it now
chrishtr: What about it are you itnerested in?
<heycam> s/Ian Skobes/Steve Kobes/
emilio: scroll anchoring restores
positions so the offset relative to the scroller is preserved.
There are cases where that's undesirable, or break,s if the
page is doing stuff like scroll effects. So if you change a
static position thing to be below, the anchor node goes up, and
then you need another scroll event, and the page realizes that
the thing is no longer sticking to the viewport, et.c
... Chrome fixed this by, when changing from in-flow to
out-of-flow, don't do the scroll adjustment.
eae: Yes, that's how it works today.
emilio: Even with this heuristic,
pages burn CPU by firing infinite scroll events, which is not
great. Pages that get locked up on scrolling if you get to the
bottom.
... Those cases are not easy to identify generically, because a
particular style change happened. The style didn't change, it's
a case that scrolling wants to fix. The only thing that's
happening is a scroll event listener. Instead of Chrome's
heuristics, it would be simpler to not adjust scroll offsets if
you're doing scroll anchoring if it's happening during a scroll
event listener
eae: We tried that and rejected it, but I don't remember why. Our current behavior is the one that worked the best in the best number of cases.
chrishtr: If something dirties layout that changes scroll offset in a scroll event listener... you want that readback to not take into account anchoring?
emilio: Yes.
eae: That sounds reasonable. If we can't figure out why we can't do that, we should try it agian and see if it's workable
chrishtr: Is the code doing this loop synchronously?
emilio: I know pages in Chrome
that burn CPU because the scroll offset keeps changing
... It changes back and forth, and triggers two scroll
events
eae: We try to detect that and short-circuit if we go back and forth more than a few times, but it may not always work.
atotic: If you have feedbakc, that would be great, because we're using a heuristic now
chrishtr: If layout is dirtied and syncrhonously read back in teh same handler .... what does reading it back have to do with ....
emilio: While the page is measurin gsomething, so if you insert something, measure it, then remove it, that measurement triggers a scrolloffset update. If you measure again, you'd get the opposite scrolloffset update. That needs to update the scroll offset
chrishtr: Are you proposing that forced layouts don't do this?
emilio: I'm proposing that Scroll offsets don't do anchoring
smfr: Is the time that scroll anchoring is applied defined in terms of HTML5 event loop.
emilio: no. This is an issue.
Mostly for this heuristic, if we can remove it, we don't need
that, but the main issue is that it's udnefined when this
calculation occurs. We are aware of this.
... Scroll anchoring runs after updating styles but before
updating layout.
... In order to have hte tree in the state you want it to, you
have to run it every layout
smfr: Scrolls triggered by scroll anchoring fire scroll events?
emilio: yes
smfr: that's necessary?
... yes
emilio: yes
chrishtr: What you're proposing is worth investigating. Chrome can invest engineers to page back in our history here.
eae: If you're impelmenting now, we shoudl revesolve this
astearns: Do we need a resolution? Should we change the spec?
emilio: These heuristics are
still implemented in Chrome and Firefox. I want to remove them
in Firefox.
... I don't see any reason to remove them now.
chrishtr: We need more investigation.
dbaron: You talked about, in a
certain case, not doing scroll anchoring. Are there are reasons
to record but defer the adjustment until later?
... I haven't thought about it that much. It feels like not
doing it sometimes runs the risk of dropping something that you
might have wanted
emilio: That may be another
approach. And then we can move it to the "update the rendering
steps" in HTML5
... The main reason case where you don't want scroll anchroning
adjustments is when you're reacting to scroll events
yourself
atotic: Part of the problem in Chrome is that, by the time we're in layout, we don't know which handler cuased it. If you can make it work in Firefox, maybe it's possible in Chrome. But we don't have anyone working on it
emilio: Yeah, but you can set a flag....
atotic: We'd have to pass the flag around....
emilio: Yeah, it's possible
smfr: High level comment about spec: The spec is unusual because it describes a behavior which is making up for the fact that web developers often make mistakes and cause scroll jank. With specs like this, we need to be careful. We risk a scenario where some UAs implement this, papering over the bad stuff, and authors may only test in UAs that implemented it. In other UAs whcih haven't implemented in it, there's a lot more scroll jank than the other UAs. This
spec increases the disparity between user agents. We need to be careful not to make too many of these in the future
astearns: There are lots of CSS features which are improving the rendering of a page. If a browser doens't implement that feature, that browser will look worse.
smfr: It's invisible to authors. The browser jsut fixes up content. It's easy for authors to create scroll-jank if they don't test in chrome
iank_: there is precidence. Text autosizing behavior is automatic.
astearns: Can we move on?
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4247
emilio: A bit of the issues we've
found with the spec, the spec uses terms, and the terms don't
map to the implementation that wrote teh spec. The spec says
"the anchor is either a block box or text" but what blink does
is "well any thing that is non an inline or an anonymous block
can be an anchor"
... that is not great. I think we've reached agreement with
Steve about better terms for the spec. The spec needs some
love.
... I'm happy to help out to refine the spec.
... Proposal: Changing the definition of anchor node to be
every box but inline boxes and fragmentainers, which are the
only things that fragment across <missed>
... This is what Blink does.
astearns: Any concerns?
iank_: There's some discussion on the github issue?
oriol: Instead of explicitly specifing the inlines, can we use atomic inline from the display specification? We can use terms from that spec for future additions to the spec?
emilio: So right now, the
definition is accurate. That term from the other spec sounds
better.
... Proposal: An anchor node can be every box except a
non-atomic inline box
RESOLUTION: An anchor node only can be every box except a non-atomic inline box
RESOLUTION: An anchor node can be any box except non-atomic inline boxes
astearns: There's going to be a breakout session on Wednesday to talk about JLReq updates
nat: Japan Language Requirements. We're working on an errata and gap analysis that will add new tests so we can more deliberately affect standards for japanese typography including those on the web. 10-11 Wednesday, called Evolving the JLReq. Will be talking about what we are currently doing and what we will be doing in the future.
TabAtkins: Majid pointed out that Waterloo is available for a summer meeting (instead of New York).
Rossen: Near Toronto
TabAtkins: 1 hour drive
Rossen: Thanks for the offer.
smfr: I'd like to build up the understanding of how they should work incrementally. I have some data from real sites that will inform our discussion.
astearns: Projection?
smfr: yes
<emilio> ScribeNick: emilio
<myles> https://github.com/w3c/csswg-drafts/issues/4116
<myles> GitHub: https://github.com/w3c/csswg-drafts/issues/4116
GitHub: https://github.com/w3c/csswg-drafts/issues/4116
myles: I'd like to present a
problem and no suggestions about how to solve it, but I hope to
leave with a sense of whether we're interested in solving
it
... there are images that need to be positioned similarly to
text
... like a math formula with a tall integral sign where most of
the formula should be aligned to the baseline but the presence
of the integral sign the whole image will sit on the
baseline
... so the formula won't align with the text
<fantasai> if we're talking about things like gaiji, which is inline images that should have a baseline and stuff... there was some proposal to add a property to specify a baseline table
<fantasai> we didn't spec it out because it wasn't a high priority
myles: it'd be cool if the math formula could say "my baseline is in the middle of the image", and layout could align it correctly
<fantasai> but it's certainly possible to do
myles: similarly with the apple
pay logo and similar, because of the descender of the y
... a similar case is for symbols like the play button in the
ios music app, which is not fully horizontally centered, but
visually centered
... it's a triangle, so if you mathematically center it
horizontally it would look wrong
... so the layout moves it slightly horizontally
... same for gaiji, which are cjk chars which are not in
unicode and people use them using images
... since they're images they behave wrong
... three of the examples show the need for horizontal
baselines, the other is a vertical baseline
<tantek> There's another fairly common use-case of this, images used for decorative first/initial letters
myles: there are various ways to
do this, one option is using it on the image formats and such
to provide the information
... another option is to add a css properties
... mac has these system assets that contain this
information
<nmccully> unencoded glyphs = gaiji; Chinese poetry typeset for Japanese audiences = kanbun
myles: another option would be to
provide a css function that takes a name to these system
assets, and returns the information
... so at least we could use it for system assets
... I wanted to get an indication of whether this is a problem
worth solving, and if it is what's the solution could look
like
TabAtkins: chrome is fine with that, we have taken a look to the image formats to provide x-height and baseline
<smfr> ack
nmccully: a single baseline is fine, but multiple baselines may be needed for multiple writing systems
<Zakim> tantek, you wanted to note use-case of decorative image first/initial letters and also prior art / related feature CSS cursors which reference the hotspot of the cursor image
tantek: I agree this is worth
solving. Another use case is a decorative image for the
first-letter which has decorations and borders and such
... we have a similar feature / challenge in css-ui with the
cursor property
... cursor has a hotspot. May be something that we could reuse
somehow
TabAtkins: cursors are usually set once, but in this case you need the same information every time you set the image
tantek: I think cursors can also have the same issue. Having the info in the image would be great, but maybe both
TabAtkins: both is fine
stantonm: we have a similar use case for @font-face / images and cjk, where adding a baseline to the font-face rule would be useful
myles: can you link me to it?
stantonm: we also have a use case to get rid of these images and use the font, so we wanted to use @font-face with the images, and for that the baseline would be great, but for the symbols it may not make sense
<fremy> @myles: if you want more details about the CUR format wrapper which can contain a PNG image and specify a hotspot: https://en.wikipedia.org/wiki/ICO_(file_format)#Icon_resource_structure
stantonm: another thing we wanted to see if we can treat images more like a bitmap, to invert in dark mode
myles: mix-blend-mode?
stantonm: haven't looked into impl that much
heycam: I wanted to express
general agreement on the problem being worth solving
... have run into this with svg
<stantonm> creating @font-face from an CJK image (gaiji) - https://github.com/w3c/csswg-drafts/issues/4013
heycam: I think modifying image
formats would be useful, though I'm concerned for compat if we
run into a situation with image-orientation
... where we start reacting to image metadata and breaking
pages
myles: we still need some css integrations to define how these are read or what not
<tantek> FYI CSS UI cursors with optional hotspot x y that can override any built-in hotspot: https://www.w3.org/TR/css-ui-3/#cursor
heycam: using vertical writing mode to getting centering and alignment seems a bit odd
krit: file formats seems nice,
but there are formats which we may not be able to modify
... so we may want a css-only solution as well
chrishtr: what formats have this already, any examples?
myles: nope, 0
... the ui image in iOS apps have this, but it's not a file
format
chrishtr: so in an iOS app you create an image and set this and use it in your layout?
myles: yes
chrishtr: I'm curious about how feasible is it to modify the formats
myles: people think it's a good idea so I'll try and come back if fail
<fantasai> myles, I think we need to make sure whatever we do can handle multiple baselines
fremy: we may not need to change formats, the cursor format is a small wrapper file with some metadata. May be able to use a similar wrapper-format
<fantasai> e.g. alphabetic vs ideographic vs central vs mathematical
chrishtr: you're proposing a new format?
<nmccully> Adobe's SING glyph format was one way to make an image with font metrics : https://web.archive.org/web/20080627183635/http://www.adobe.com/devnet/opentype/gdk/topic.html
fremy: windows cursors do exist
already, and include the hotspot. It already has the hotspot,
but we don't want exactly that
... so we may want that instead
... as changing formats is going to be a pain
myles: only interested in jpeg
and png really, and those do have optional tags
... but yeah, first thing to try is changing those, second the
wrapper format, third css-only solution
<myles> optional tags inside their existing formats
bkardell_: We need to specify
what do we do with these values, and people thought that a css
solution would also be valuable too
... so it seems like we'd get into a situation where there are
multiple sources of truth
myles: image-orientation was like that until not long ago
bkardell_: right, also
aspect-ratio and such
... do you think a property of that sort would be valuable?
myles: I think the way I'd approach is the underline-{offset,thickness} where there is an auto value, then from-font (which would look and the image), then <length>
chrishtr: we discussed something similar about mathml not long ago right?
myles: I think the mathml
proposal was to identify the baseline out of specific elements
inside the formula
... but that doesn't work for non-formula use-cases like the
ones I've provided
chrishtr: that makes sense
cbiesinger: could potentially work for svg
myles: yeah, true
chrishtr: drott mentioned that
fonts can be the wrapper format
... that may be a lot of overhead
myles: I think making icon fonts is an anti-pattern
drott: there are some ergonomic
issues with them
... but my point is that we don't need a new wrapper format,
you could wrap an image in a font file
myles: I'd prefer a new format, there's tons of unrelated stuff that you'd need to create a valid font
Github: https://github.com/w3c/csswg-drafts/issues/4036
rachelandrew: this is an edit
made in #3224 (since the last wd)
... dbaron opened this, issue has a bunch of discussion
... I think it was left reverting the resolution in #3224, but
then we need to resolve what column-fill: auto and height: auto
works
... so we need to decide
... I wanted to sort this so I can publish another wd, and I
wouldn't like to publish something that we may revert
iank_: can you describe what happens right now?
rachelandrew: if we're on a
continuous context we only look at column-fill: auto in ???,
and there were interop issues
... Chrome is doing the new behavior, which is actually the old
one that was commented out on the spec
... dbaron has a nice table on that issue
... the second table
... I think if we print from the browser the behavior should be
the same
dbaron: yeah, I think we
shouldn't get in that situation, because we'd balance the
columns separately because we're printing
... I think at least the last fragment in paginated mode should
behave the same as the only fragment
... I suggested a fix, but florian didn't agree because it was
not what print formatters do
... so I suggested going in the other direction
... I think mstensho was fine with this if we have a clearer
definition of what each combination does
... it'd take me a bit
astearns: so reverting would get us to a better place to improve upon right?
dbaron: I think so if WebKit are fine with changing this
iank_: reverting this leaves less more stuff unspecified right?
rachelandrew: yeah, that's right, but we shouldn't publish something that we might revert
iank_: can we mark it at risk or such?
astearns: it's more of a note "we think this is wrong but we haven't figured out the implications of changing it"
iank_: that seems fine for a WD
astearns: but if we know it's flat wrong it may not be useful
iank_: but is it wrong for sure?
dbaron: I think the inconsistency is pretty wrong
iank_: mstensho didn't agree looks like
dbaron: I don't think he
disagreed
... to be clear the thing mstensho is complaining about is that
`height: auto; column-fill: auto` if we revert this
change
... that combination is already not-defined when you're
printing
... so there's an existing spec gap that needs to be
filled
... but I don't think it's too hard since there is existing
behavior (though we may not like it)
florian: I think consistency
between printing and formatters is important, so it is
consistency between a browser on continuous contexts and
printing
... so we should revert to find a solution that doesn't break
any of both
astearns: iank_ had objections?
iank_: I think reverting is fine
astearns: proposed resolution is reverting the change and leave issues in the draft to define this
rachelandrew: yeah
iank_: may be useful to link to the reverted change
<dbaron> It looks like what Gecko does for the auto height is just to assume one column.
RESOLUTION: revert the change made in #3224, and add spec issues to define this
RESOLUTION: republish the wd of css-multicol
<heycam> ScribeNick: heycam
smfr: thinking about 3d
transforms
... I want to make sure any changes to the spec don't have
unreasonable web compat impacts
... so I wanted to understand how people use 3d transforms on
the web, I did a poll
... analysed these sites that are using real 3d
... not as many sites as I expected
... I've noted the structured
... the set of properties on the node that's doing 3d
stuff
... properties on the node, the child, the grandchild,
etc.
... generally web sites are putting perspective on the root of
the 3d stuff
... not preserve-3d on the root, mostly just perspective
... then they put preserve-3d in the child, sometimes with
transform
... sometimes they have a noop element. not no transform
related styles on it
... sometimes they'll have some intermediate elements, e.g. 3
noop divs, then transform/preserve-3d under that
... sometimes they put just the transform on the leaf nodes.
sometimes preserve-3d and transform on the leaf nodes
... something that came out of this is taht there are a few
sites that have these noop divs that cause bugs in Gecko
... Gecko treats an element in the ancestor chain that doesn't
have transform related prtoperties and something taht triggers
flattening
... it's causing problems on a few sites
florian: are there sties that rely on this happening>
smfr: did not see any
... people combime overflow-scroll and 3d for parallax
effects
... might have to make some exceptions for
overflow-scroll
... this is how people are using 3d transforms.. most important
thing is that noop divs should not cause flattening
... next I want to build up the 3d model from scratch
... I'ver realised there are some porblems with the current
ED
... we'll end up with a combination of thwat's in the current
ED and the preivous WD
[shows transforms-buildup.html]
scribe: let's started with a
simple case. this is a 3d transformed element, in
isolation
... nothing else that is 3d-ish in this content
... the best behavior for this is that the 3d transform here
acts as a painting effect
... it'll be squished by the transformed, but painted in the
regular z-order
... no intersection with its container or anything else
... next question is what happens if there are 2 siblings that
are transforms
... think the right answer is that they should act as a
painting effect, they should not intersect
... I think that's the Gecko model, and maybe Blink, but not
WebKit. willing to change WebKit here
chrishtr: nothing has the preserve3d here
smfr: right, we're still in "painting" transforms
astearns: is this something the current ED is sayin something differetn about?
smfr: the current ED is written
with the notion that you're always in a 3d rendering context,
and doing flattening
... it uses the analgoy of CSS stacking ocntexts and
flatening
... I think a better model is that you only establish a 3d
rendering context when you use the magic properties
... otherwise you paint in the regular z-order
... now let's change the eexample to put perspective on the
container
... originally the notion was persecptve is we're applying
another transform for descendants, a common
viewport/perspective
... looking at the way content is using perspective, think it
makes sense to establish a 3d rendering context
... the 2 siblings would start intersecting with each other
chrishtr: not a behavior any browser has now?
mattwoodrow: WebKit will intersect them (though even without perspective right now)
chrishtr: the perspective proposal is unrelated to current intersecting behavior of WebKIt?
smfr: yes
... when an author says perspective, they're opting in to 3d
stuff, and expecting descendants to depth sort
chrishtr: and currently, in Gecko and Chrome, they don't intersect but the perspectie does adjust teh transform
mattwoodrow: right
... did you have examples on your spreadsheet of examples where
Gecko/Blink are broken?
smfr: most sites had more complex
hierarchies
... nobody had just perspective and transformed chlidren
... so, hard to say
... going back to the example, next set of questions is about
the preserve-3d behavior
... I think the right hting for preserve-3d is to establish or
extend a 3d rendering context
... so in this case, if you put a preserve3d wrapper around the
child -- leaf doesn't have the preserve 3d -- ...
chrishtr: so 2 transformed elements in a single context are sorted with respect to each other
krit: this example would render the same in all browsers now?
smfr: not sure that Gecko will do intersection between the two
krit: the proposal is if you have persecptive set to a value, you'll establish a 3d rendering context?
smfr: yes
chrishtr: support you have an element with perspective. and a child with no transforms. then a grandchild ---
smfr: we'll come to that
... web site data showed that noop divs should not
flatten
... some interesting cases then, things like opacity that
trigger flattening
... creates a stacking context, and a graphical group, it
triggers flattening
mattwoodrow: my biggest concern
with the noop thing is it's hard to describe what hte behavior
is
... the spec wording for how to decide how to establish a new
one or to participate in an "ancestor" ...
smfr: think that should be
written in terms of stacking context ancestors
... WebKit's implementation is based on paint order, not
containing block order
... I think there are some cases where these properties should
trigger a containing block for ease of implementation
... but effectively we certainly work in painting order
mattwoodrow: there are things
liek overflow:scroll
... anything that has a clip ...
chrishtr: setting aside overlfow:scroll, do you think this opacity would need to establish a containing block?
smfr: no?
... another interesting case. things that trigger stacking
contexts but which arent' grouping effects
... for example z-index
... that doesn't create a graphical group, but stacking
contexts are effectively graphical groups, so it should flatten
as well
... it's no-op-ish
... so I think in the model it has to flatten
... then there's the other interesting one, what if you have
overflow:scroll -- doesn't create a stacking context. people
take advantage of this not flattening to create parallax
effects
... not really sure how to describe the clipping effects of
oveflow
mattwoodrow: think we want
different behavior for pereserve-3d and perspective
... for preserve-3d we probably want to flatten. but the
persecptive subset we could do relatively easily
chrishtr: can we go through a quick example of doing parallax with this model?
mattwoodrow: currently in Gecko,
the clip is applied on the outside of the persecptvie
... the perspective gets multipled into the transformed
elements
... but the perspective origin is outside the scrolled
element
... the clip is not in the middle of the transform chain
chrishtr: as long as we can preserve parallax scrolling....
mattwoodrow: spec text could say to look up the DOM to find a preserve3d element, but stop walking if you find overflow:scroll
chrishtr: I think you would want
this to be a containing block and stacking context as
well
... it's neither of those 2 things by default
mattwoodrow: right
smfr: when it has preserve3d around somehow?
chrishtr: walk up the tree, if it's got preserve3d around an overflow:scroll, ...
mattwoodrow: not suggesting overflow:scroll should be a stacking context, but the inner preserve-3d would create a new 3d rendering context
[some discussion about preserve-3d on the overflow:scroll element resulting in the computed style being transform-style:flat]
astearns: sounds like there were some existing sites that expected noop divs ... is there a difference between noop divs and those that have an explicit flattening property?
smfr: noop divs don't flatten
mattwoodrow: I think it's easier to specify if they do flatten
astearns: but not what authors expect?
chrishtr: maybe
smfr: none of these examples totally broke. but you could see the perspective looked different on some elements
chrishtr: definitely think
aligning browser behavior is going to break some content
... should minimize that, but come up with a model that we're
sure is well defined
smfr: that flattening was the
most obvious breakage if we followed the Gecko model straight
away
... I think the last piece is the discussion around how
perserve-3d behaves ...
... on #1950, Tab lists four different behaviors
... don't fully undersatnd if they're the same except for
whether preserve-3d is on the parent or the child
chrishtr: Q1 is, do the children 3d sort before they flatten
<TabAtkins> Q2: do the children sort with the rest of the 3d scene their parent is in, or do they flatten into the parent and then (flat) parent lives in the scene?
chrishtr: and these behaviors are
the 2 core ones we control with preserve-3d or
perspective
... taht's your whole point? how do they behave dfeault and how
do the properties affect this?
TabAtkins: yes
... all 4 combinations seem reasonable, don't know if you want
to expose them all
... case 1 is fully 3d, everything is operating in the same
graph
... case 2 is you run the children's 3d scene, flatten it, the
parent does the 3d scene
<dbaron> One other thought (related to discussions a few minutes back) is that you were talking about walking up the DOM tree, but I'm not sure if you wanted to walk up the DOM tree or the containing block chain.
TabAtkins: #3 is the weird one.
each child does an independent 3d thing in the parent's plane,
but they could overlap with other things
... 4, double flat is simple
smfr: doing all of these with
combinations of properties, with the behavior I described,
except if perspective establishes a 3d rendering context,
authors would not be able to have the transfom effects of
perspectie without also the intersection effect
... but the author could use the perspective transform function
on the leaves to get something similar, but not sharing the
same origin
chrishtr: I think that first part of the sentence is a good reason why perspective should not imply preserve-3d
smfr: so valid to hav eshared
perspective, but siblings not intersecting, which is contrary
to my first point
... ok, so we're back to perspective not making a context
... question is how many of these sites would break
chrishtr: then there's the
question of resolving the intermediate divs
... how we'd spec and implement the corner cases
... if those intermeidate divs would in some cases be
transmitting up the preserve-3d as opposed to flattening
smfr: unless we're willing to go
to the Gecko model of always flattening
... still think that's the most web incompatible change
chrishtr: if it was web compatible would it be objectionable to you?
smfr: no
chrishtr: certaimly the easiest
to reason about in the spec
... we should do some homework tonight on why these sites are
broken in Firefox, see if it's due to this issue or something
else
mattwoodrow: I can do that
chrishtr: and whether it's easy to fix them
smfr: if we say that the root must have perspective and preserve-3d to establish a 3d context, I did not capture dat about whether there are multipel transformed siblings
chrishtr: the intersecting thing?
smfr: yeah
... no authors are using preserve-3d on the element with
perspetive
chrishtr: you would've observed a rendering difference
smfr: these don't have multiple siblings, so wouldn't necessarily see that
chrishtr: nobody's done any
httparchive searches
... would be good to find mor eto sanity check
smfr: the stripe stuff is genuine content, most others are old demos
chrishtr: ancedotally, not sure
how common this kind of content is
... I will volunteer to do an httparchive search tonight
florian: I think the lack of
interop is indeed causing a lack of sites using it
... I did retire a site that used to use 3d
<astearns> github: https://github.com/w3c/csswg-drafts/issues/918
mattwoodrow: current spec says
that backface-visibility only applies to the element it's on,
not descendants
... doesn't say it would create any plane or layer, which Gecko
faithfully implements
... other engines create a plane for all descendants but not
positioned descendants
... which is not something there's any precedent for, seems a
bit crazy. would prefer backface-visibility create a stacking
context
smfr: I think in WebKit it does create a stacking context, not a containing block
mattwoodrow: maybe it is that it doesn't create a containing block
chrishtr: definitely doesn't create a stacking context
smfr: I'd be scared to change hte behavior of backface-visibility...
mattwoodrow: so try to find a descroption of what it actually does. affects itself and non-positioned descendants?
chrishtr: self painting layers reset the backface visibility thing
mattwoodrow: don't know how to describe it for the spec
chrishtr: similar to the set of
things dbaron found that caused "painting as if
positioned"
... in CSS 2.1, positioned elts paint later than regular
elements
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
chrishtr: anything that has an
effect-y thing on it
... this is exactly what is on self painting layers
... so we could define it that way
florian: where else did we run into this?
chrishtr: might have been another
case yes
... but the thing about hte paint order is one that's not
specified properly, is that right?
mattwoodrow: most of hte psecs that create stacking ocntext say that. but they mean create a stacking ocntext and sort it with positioned descendants
chrishtr: overflow:hidden,
backface-visibility, SVG elements and other atomically replaced
elements, ...
... CSS clip probably
... and the rest of them do create stacking contexts
... we should define this, get interop on the table in dbaron's
test, then use it for the backface-visibility definition
dbaron: I don't think there's a
whole lot in there that's not what creating a stacking
context
... CSS clip only applies to things that are positioned
chrishtr: but in terms of the
"painting as if positioned"
... I think overflow:clip is the most common
dbaron: have we added that yet?
chrishtr: I mean overlfow:hidden
and scroll
... on the issue in which this table resides, I mention there's
a silly quirk in Chrome and probably WebKit, not triggering
self painting in some bizarre corner cases of scrolling
smfr: WK does not create self painting layers for overflow:hidden
dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list
mattwoodrow: don't think so
... overflow:hidden isn't a stacking context, can interleave
things inside and outside, so can't go in the positioned
descendants list
smfr: so is everything on the list make stacking context?
mattwoodrow: yes
chrishtr: overflow:hidden does
not create a self painting layer (in Blink)
... if there's overlfow:scroll but is in effect like
overflow:hidden since there's nothing to scroll, then we skip
it
... that's something we could change in Chrome
... in any case, is this a good way to spec it?
mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...]
<dbaron> I think Gecko calls this "pseudo-stacking context"
RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works
dbaron: some of this would be
easier if there's a spec to put this old CSS 2.1 text to evolve
it
... maybe a central painting spec
-- break until 4pm --
<TabAtkins> ScribeNick: TabAtkins
astearns: A number of specs are
using <basic-shape>, which has several functions in
Shapes 1, but not path().
... But path() is being implemented for *some* of the
<basic-shape> properties.
... It's weird to have them linking to a definition in Shapes 2
that's just a diff.
... One option is to flesh out Shapes 2 into an actual spec,
with a proper definition for <basic-shape> including
path()
... Another option is to pull path() back into Shapes 1, which
implies we should implement it for shape-outside
... I don't much care which one we do.
... But would like to resolve on which way to o.
TabAtkins: My preference is
whatever gets all the props using the same set of shape
functions; all the props use a different subset right now and
it's terrible.
... Spec's easy, I'm fine with it in level 1.
astearns: I think Ian said doing path() in shape-outside woudln't be trivial, but seems plausible to do.
eae: Yes.
astearns: So I propose adding
path() to Shapes 1. There's other things that need to be done
in the spec, we can get a draft out that everyone can refer to
with all the functions.
... Can deal with how that slows down Shapes 1 from PR as we
find impls to try it out.
... Objections?
<AmeliaBR> The problem with adding path() to shapes 1 is that, as currently defined, it can't be used everywhere a shape is. It only defines the outline, not the fill area.
heycam: Any objection to shipping path() in things like offset-path - do they need to ship together?
TabAtkins: [reads Amelia's IRC comment]
astearns: Yeah that's a bit of th
eproblem, some properties don't need fill-rule at all.
... So I'm imagining it's an optional param to the function.
But I haven't thought about how it's specified yet.
heycam: Would that block Motion Path?
astearns: My proposal is just to put it in Shapes 1. It shoudl improve the Process situation for Motion Path; it can then refer to a CR-level spec instead of a FPWD diff spec.
<AmeliaBR> Motion path would just ignore the fill rule. But for the SVG `d` property, allowing fill-rule in the path() function is possibly confusing, since there's a separate fill-rule property that applies.
astearns: This is really all
about Process.
... Tab, you mentioned Chris Coyier's annoyance with the shapes
being different everywhere.
... There's the path attribute in SVG; it's possible we won't
get all the way to SVG syntax in CSS.
[discussion about CSS tokenization not being compatible with SVG]
myles: Does that mean you can't build up paths from varia les?
TabAtkins: Not without defining a new syntax that's CSS compatible.
AmeliaBR: Or doing the string-concat function.
myles: Didn't we resolve to add that?
AmeliaBR: Yeah, but no one's
written it yet.
... wrt it being a Process issue; if we want to put path() in
Shapes 1, we have to figure out these issues before Shapes 1
can move forward in the process.
... I'm not sure who's responsible for Shapes's progress, I
think Alan; at this point is it best ot clean up and stabilize,
or are we fine to take on this new work? Becaus eit's also
abuot impls.
astearns: I think my strat will
be to add it to the spec as an at-risk feature, so that we can
punt it if we need to move Shapes 1 forward, but I'm perfectly
happy with it sitting at CR for a while, or even going back ot
WD if there are enough changes.
... I'm not that concerned with getting it to Rec real
quick.
AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature?
florian: Nah it's fine.
... Patent Policy will handle it fine; as long as you've got
wide review and what not is fine.
AmeliaBR: It's been reviewed in Motion Path, but review there...
florian: The easier it is to demonstrate review, the easier time you'll have.
astearns: And if we have to bounce to WD, that's fine.
AmeliaBR: So long term, is our goal that shapes should be shapes, and you should be able to specify motion-path with circle(), etc?
TabAtkins: Yeah, a circle is a path, whatever.
astearns: So any objection to adding path() to Shapes 1?
RESOLUTION: Move path() down to Shapes 1, adding it to <basic-shape>.
krit: I missed - are impls willing to support path() in shape-outside?
astearns: Missing a few people that would answer that.
TabAtkins: Ian says it's non-trivial, but doable.
astearns: So yeah that might slow us down, but getting things consistent and well-explained is more useful than a quick Rec for Shapes.
krit: Would it be good to add a note about precision in paths? A very complex path might get transformed to a polygon, maybe have a lot of points, etc. So can we add a note that impls can decide on how precise it wants to be?
AmeliaBR: I don't know if we currently have text to that effect with polygons...
astearns: We do have text for
some degenerate/difficult situations, saying you do have to do
the difficult stuff.
... I'm not sure we need to define that; precision's going to
be an impl detail. Tests will have to be fairly coarse anyway
to avoid being flaky.
... So I think it's just a QoI detail they can live with.
krit: So if we agree it's just QoI, it's probably fine.
AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths.
krit: Ok.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4270
AmeliaBR: This has already been decided, but there's been no volunteer to do the work.
TabAtkins: I can do it.
plinss: We'll need to add some redirects to the draft server, since the URLs will change. Coordinate with me.
<heycam> ScribeNick: heycam
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4244
emilio: the CSS Lists spec says
that ol and ul (should also include menu!) should have a
counter-reset: list-item in the UA sheet
... we've had 2 regression reports, people overriding
counter-reset
... the fix on the author side is trivial, adding list-item to
the value
... afaik, the 2 regressions are fixed that way
... but we may want to think about whether we should make this
reset magical
... the issue with making it magical, is that there's no way to
override it to none
TabAtkins: at the previous meeting, didn't we resolve to do the thing where if you don't mention list-item?
emilio: that's for
counter-increment
... should we do the same for counter-reset?
... the reason I didn't want to jump to do that, there's no way
to override it to none
... could say you add the counter-reset, unless you explicitly
set it to none
... so it's tricky
... not totally convinced we need to change it for compat, but
I'd like to know if we do need it
TabAtkins: if we wanted to
express the reverse mbehavior, in non magical ways, you'd need
something special for counter-reset
... the only way to do that within the syntax of counter-reset
would be to add a function
... because there's no comma, must be an ident and possibly a
number. if you add a number ident, that's just another
counter
... if you wanted to change hte behavior, like with reversed
lists, synatx would be to use a function rather than an
ident
... could have a dont-reset(...) when you explicitly need
to
... then if it's not explicitly mentioned in this way, it gets
reset in this way
emilio: not a fan
AmeliaBR: counter-reset: dont-reset(list-item), xxx
emilio: just looking for ideas if
we needed to tackle this
... for now this is fine I think
... a more web compatible solution would be to always reset it,
but then it's annoying you can't override it
TabAtkins: you can override the
use of it
... the browser's doing some extra accounting in the
background, but the author just wouldn't use it
fremy: what happens if you don't reset, and you have a reversed list inside another reversed list?
AmeliaBR: it's a nested counter
fremy: if you're not resetting th
ecounter, you have to consider the nested child as part of the
main list
... does anyone want to implement that?
emilio: I think it would work right now
AmeliaBR: the list items handle if you're incrementing up or down
emilio: we do the counting on the
counter nodes, so we count the number of counter nodes that are
in the same list
... I think it would work. mixing reversed and non-reversed
lists would be fun...
fremy: not sure it's a big problem if we cannot
AmeliaBR: any interested in supporting reversed counters in general? counter-reset and reset it to the max value the counter would have?
TabAtkins: so far no, since that's not what reversed counters actually do in HTML
<TabAtkins> ScribeNick: TabAtkins
florian: In langs like English, word-break:keep-all is same as normal
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4286
florian: In Japanese, it
suppresses a lot of wrapping opportunities. (Not quite all, but
most.)
... So if you have a very short measure of text, you might have
a small sequence of text without break opportunities.
... Currently ther'es a provisio in the spec that the UA may
reproduce the suppressed wrapping oppo to reduce
overflow.
... I think this is good, but the "may" isn't. We should
harmonize on should or must if we want to do this.
... An example of this is a title or figcaption, a short piece
of text.
... People tend to like it not breaking anywhere in
Japanese.
... But if the amount of space is small enough that it woudl
cause overflow, they'll prefer it to break anyway.
myles: This value is for Korean, right?
florian: It's frequently used for
Korean, but it's also useful for other CJK langs.
... Any lang that allows breaking at syllable/char boundaries
can use this to opt into a less free-form style.
myles: Right, just if Korean use is most common for this, we should see what Korean native speakers prefer.
koji: I'd prefer this be
explicit, so it happens only when authors opt in, like
overflow-wrap.
... If you want overflow-wrap to not break at specific points,
that might be the feature you want. I don't see much different
from keep-all in English case.
... If it's useful for Korean it's probably useful for
English.
florian: Difference between
like-English and break-all is that in English, there's no real
context where breaking anywhere is acceptable. But other langs,
that is the default.
... So falling back to that behavior in those langs that opt
into keep-all is possibly reasonable, while it's not in
English.
myles: What about overflow-wrap:anywhere?
florian: This isn't actually anywhere, tho.
myles: Maybe break-word?
florian: break-word and anywhere
are identical except for intrinsic sizes.
... But maybe we could have a fourth value, that says that if
keep-all, it still falls back to breaking anywhere if
necessary.
myles: Right, my question is just if we need a new value, or if the existing values are enough and we just specify their interactions a little different.
koji: In my mind, the two
variants of Korean linebreaking are just variants; keep-all is
normal behavior.
... Even in English or German, if you have a tiny space to lay
out in, you might still want a break going anywhere.
florian: My proposal is *not* to allow breaks before commas, etc. Those are disallowed in 'normal'. My proposal is that, in these restrained-size situations, revert keep-all to acting like normal.
koji: I understand. but this value is already to suppress this situation from happening in Korean. But I think we want to fix all languages.
florian: We have this in german/english/etc by using hyphenation, with "" for the hyphenation character.
koji: Ok, so say English text has
a very long word, and the author uses overflow-wrap:break-all
to allow it to break. In that case it can break before a comma,
which isn't ideal.
... I don't think we can change that, so we might want to add
the fourth value.
myles: That's what break-word was supposed to do way back when Hyatt implemented it...
koji: word-break can be commonly used in an issue tracker, for example. But using it on English text is troublesome. overflow-wrap is more useful, but can do bad breaking.
myles: My overall point is that the linebreaking properties in the Text spec are already so complex and there are so many of them, that it will be hard to justify another one.
koji: Ok, well, I think this is basically the same as modifying keep-all.
florian: One action item is to
ask Korean speakers, since they're a frequent user of this
value, if it would be generally acceptable or if it would be
weird.
... There seems to be a use-case to have it either way, but
you're right, there is a big cost to adding new properties in
this space.
... So we could defer the always-prevent value if it's going to
be rare.
... It's just having the "may" that I think isn't terribly
useful.
myles: Right, making a resolution now seems premature.
florian: Sure. That's enough feedback fo rnow.
florian: this has evolved over time; they're a strange kind of space, like figure spaces, ideographic spaces, etc
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4180
florian: These now have the
treatment that they'r enot collapsible, that hasn't changed, bu
tthey're discarded at the end of the line (assuming
white-space:normal)
... Unfortunate consequence: if the line is *only* these
spaces, they're not discarded for being at the beginning of the
line, but they're also at the end of the line and need to be
discarded. That leaves an empty line, which is weird.
... We coul dinsted hang them.
... Diff is you could still see them if you underline or
background them.
... But from layout, it would be the same as an empty
line.
... This was found by Igalia when implementing the spec as
written, and it seemed weird to them.
... I think there's no real author preference between
discarding and hanging. So since hanging is simpler for impls,
would be preferable.
... I made a PR for this, I know fantasai is okay with
this.
stantonm: Is there precedence fo rhaving that many hanging spaces?
florian: Yes, we have some other
situations like white-space:pre-wrap.
... There's an open issue for some variant situations,
but...
stantonm: The inline border does
seem strange.
... An inline with a border would project off the edge of the
element.
florian: Like any overflowing
content, es.
... Example: "<span>a b </span>". If the spaces can
hang, these can stay on one line. If they can't and must
overflow, instead you must break before b, then let that second
line overflow anyway. So not hanging isn't avoiding overflow at
all, just introducing extra linebreaks that shouldn't be
necessary.
koji: Hanging would require changes to our whitespace code that we'd like to avoid if possible.
myles: there are like 5000 ways to make text look bad on the web already
stantonm: Is there a way to avoid this?
florian: Yes, text-underline-skip for example.
astearns: So proposed resolution
is to accept the PR, which states that the spaces will
hang.
... Objections?
RESOLUTION: Trailing "other-separator spaces" will hang, accepting fremy's PR.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4271
astearns: There was a second gh
issue we didn't send the comments to
... An impl was asking if it was okay to ship
clip-path:path()
... Because they needed to point to an official draft that had
this path() thing specified, and all they had was the diff
spec
... So in my mind the intent of moving this to level 1 is to
let impls ship it.
heycam: clip-path:path() is
already shipping in WK, I believe. Not in Chrome yet. Ready in
firefox for a while.
... Just wanted to make sure nothing drastic would happen to
the syntax.
krit: CSS Masking is already in CR, so implementing clip-path is fine; this is specifically about the path() function.
astearns: Does anyone think Gecko should *not* ship the syntax?
RESOLUTION: Impls can ship clip-path:path()
github-bot: end topic
heycam: What's the policy on this sort of "blessing"?
<fantasai> we put it into the Snapshot
astearns: In general, CR means definitely fine to ship; before is usually behind a flag. But it's fine for there to be situations where people need to ship before CR, just check with the group that it's in a stable situation.
myles: People like to view websites on their phones.
[general astonishment]
myles: But phones ar esmall. So
the text is usually too small
... So way back in 2007, iPhone 1 implemented a feature to
automatically increase the text size without increasing page
size.
... We've been shipping this for a very long time.
<tantek> FYI some old writing on this here: https://wiki.mozilla.org/CSS/text-size-adjust
myles: This is controllable with
a CSS property called -webkit-text-size-adjust
... Three values: none, which means "don't mess with my sizes";
auto, the default "mess with them it's fine"; and a %, which
means the browser's default method of messing with sizes
doesn't work well for a particular element, so they site
provides its own % boost for the element.
... So if font-size is 10px, and wtsa is 130%, you'd see a 13px
size.
... So a bit later we shipped the iPad, also a small
screen.
... This wasn't a problem; we made the iPad view the same
content the iPHone viewed; it pretended to be a big iPhone for
the web.
... So it also got the text-size-adjust behavior.
... This past year we've changed iPad behavior.
... Now iPads get desktop content.
... So this means that sites which said -wtsa, we don't get
that behavior anymore.
... But ipads are still small, so we have to do
something.
... After research, turns out the method we need to increase
font-sizes is different between ipad and iphone
... In iphone, the goal is to make text readable when you
double-tap an element; we'll zoom in so the text fills the
width of the screen, so you avoid scrolling.
... In ipad, people don't usually double-tap on elements, so
the goal was to make it readable by default.
... So the heuristics are pretty different.
... No problem so far.
... This year we started accepting desktop content. That often
has -wtsa property, because desktops don't honor it, so it just
kinda sticks around without doing anything.
... But when we flipped the switch, ipads were honoring the
property, and everything got messed up.
... AFter investigation, we discovered that most of the sites
that were setting wtsa were using 100%, which is the same as
turning it off.
... Correlation between sites that did that, and sites that
*needed* wtsa to work well on the ipad, unfortunately.
... So what we now have implemented in ToT is...
... none still means none. auto still means magic; different
than phone, but still magic.
... But %, we found that if treated %s as auto, it made the web
look better than honoring the %s.
... Way more sites were using %s to turn wtsa off, than were
using it correctly to specify good sizing. In fact, *zero*
sites were using it correctly.
... So it would be good to write that down.
... There is a spec covering this feature, CSS Text Size
Adjust.
<drott> https://drafts.csswg.org/css-size-adjust/#adjustment-control
myles: I have a bunch of edits
I'd like to make to that spec.
... Mostly of the form that %s will be used as a hint. On
iPHones they'll be honored; on iPads they'll be a suggestion
(currently ignored, might change later if sites start using it
correctly).
<karl> https://github.com/whatwg/compat/issues/18
myles: And I'd also like to
generalize the inputs/outputs for the "auto" behavior to make
it encompass both the iphone and ipad behavior.
... And I'd like to add a section about how authors should use
the property to control this behavior; you can look at computed
value to see what the brwoser did to your text, and you can use
"none" to reset if it you don't like it.
... So want to know what wg thinks.
astearns: How are you speccing this behavior? UAs may do this, may do that...?
myles: Strat we thought best was
to keep things general. Two behavior on two platforms, browsers
might have other behaviors, etc.
... As long as the author can know what was done and fix it,
should be fine.
... So strategy is to make it very general and have a list of
things that may be considered when the browser does auto
sizing.
heycam: seems like you want the
author to be able to tell what auto adjust the UA has made for
an element
... Exposed thru the computed style.
myles: Already how iphone works
heycam: looking at the old spec for the moment; initial value is auto, and it's inherited. so if it computes down to the actual %, wouldn't that be inherited to the children?
myles: In webkit I think we don't
follow the inheritance rules to the letter for this
property.
... If you stack a bunch of %s, they don't multiply.
dbaron: I heard you saying look at computed value of font-size, not text-size-adjust.
myles: Right!
... So you look at font-size and line-height; i think it's
important that the spec explicitly says only those two
properties will be modified.
... S'o they know what to consult and fix.
dbaron: I think most of this
sounds fantastic.
... A little nervous about generalization.
... Would be nice to have a good description if someone wants
to implement this...
myles: So over the past long time
we wanted to change how ipad viewed the web
... but text was too small
<emilio> karl: aliases are cheap
myles: the iphone's model isn't
really what we want
... want different behavior, and faster (iphone behavior is
slow), looks at viewport, style of nearby elements, out-of-flow
vs in-flow, etc
... Tried to come up with an algo for the ipad, and we
implemented it, and it wasn't good
... Cycled for a while.
... so instead is we got a lot of humans to visit websites, and
tap on the things that were too small. custom webkit build that
would log this
... Adn then did the same to tap on the thins that weren't too
msall
... Then used ML to predict too-small vs ok-size.
... So we have a decision tree, but...
... it's not intentional. It just gives good results on a lot
of pages.
... So I think it would be a bad idea to put those results into
a spec. Plus it can change later.
dbaron: I think it would b euseful to have it in the spec even if it's not required to be followed.
myles: Maybe as a non-normative
impl guide?
... That's fine.
florian: If I'm an author and your algo gets it wrong, that seems unpredictable to me.
myles: We try our best to make the heuristic good, and you can use "none" to fix it.
tantek: You specifically gave
examples of authors trying to shut off the bheavior, but
accidentally messing the pages up on other devices, and then
you having to figure out what they really intended and
correcting things for them.
... So that lack of predictability caused authors to misuse the
property.
TabAtkins: That's not right. When authors used wtsa on mobile devices, they did it reasonably right. The problem is that wtsa wasn't honored on desktop, but authors were still using (useless, ignored) declarations in their desktop-only code. As soon as ipad starting requesting desktop versions and honoring those declarations, it messed up.
fremy: Ultimately if the heuristic isn't understandable/predictable, Stack Overflow will just recommend swapping 100% to "none".
myles: And that's fine.
emilio: So wk exposes the used
font size...
... Your text adust used to be layout time, right?
myles: Yes. But on both iphone and ipad, if you say gCS().fontSize, you'll get the used style.
emilio: Okay, that's not what Firefox does. But maybe we shoudl change it.
myles: Yeah, I think it's
important.
... So if the group thinks this is okay, I'll make a PR for
these changes. They're pretty substantial, so maybe I could be
added as a coeditor?
tantek: I'm okay with that.
<dbaron> +1 to myles as a coeditor
SimonSapin: You said computed value of font-size is affected; does that mean that other lengths using em are affected
myles: Yes
emilio: It didn't used to be the case, right? If you did adjustment at layout time, you can't.
myles: Hm, maybe I"m wrong.
<Zakim> SimonSapin, you wanted to ask if em units are affected
tantek: We neve rpublished a
fpwd, we had too many issues and didn't understand how to get
it ood enough to publish.
... So maybe that's a good goal.
myles: I think that's a reasonable goal.
fremy: do you apply the sam ehueristic for all ipads?
myles: No, depends on screen size
and viewport size and specified style
... This is listed in the proposed changes
fremy: So if there's a new version of the ipad, are these rules something that'll scale, or is it arbitrary? Do you have to do more tap testing?
myles: I don't htink i can answer that.
astearns: So let's get edits into the draft and raise issues as needed.
myles: The algo intentionally doesn't describe an algo currently, but it does describe things the browser can consider, and that it only affects two proeprties
plinss: Do you turn these heuristics off when MQs are involved?
myles: no
... But <meta viewport> does interact with this
... So if you have a webpage that is mobile-ready, that'll
affect this algo
... So the algo is only strong on webpages that are getting
shrunk; if they fit well it has minimal effects
plinss: Overall concern is just that we should be encouraging authors to just make pages in general and use MQs .
myles: The overall purpose of tsa
is to make things look good on small devices, so it's driving
us toward that goal.
... Philosophy maybe isn't productive, but generally: a
solution in the UA works on every page, and doesn't rely on the
author getting it right.
<Zakim> tantek, you wanted to express concerns with changing algorithms based on hardware releases
myles: Users don't say "gee I wish this page used MQs" they say "I can't read NYT, this sucks"
tantek: So a few time syou
mention hw releases meaning new algos.
... I'm uncomfortable with algo changing with hw releases.
That's not a standard.
... I'd prefer something tha tusrvives hw releases.
myles: First, if we release a new
device, we're gonna have to tweak it. The web'll look bad, we
have to make it look good.
... Second, restricting this to exactly two props, and telling
authors how to change it, goes as far as we can to that
goal.
... So the most future-proof we can do is to say that tsa can
only affect font-size and line-length; no matter how the
browser changes things, the author can alway slook at those
properties, and disable tsa if they want.
TabAtkins: and note that myles wasn't originally intending to publish the algo at all, that was a dbaron request
tantek: I'm concerned that this'll be continuous reverse engineering.
myles: Yeah, when android ships another phone, they'll have to do the same sort of engineering.
hober: This is just acknolwedging reality
dbaron: And realizing that the
web's behavior will juts change over time. Maybe that means the
spec will need to change over time too.
... In a world where devs test on these N devices and not every
possible-in-theory form factor, there will be things that break
when a new device comes out. That'll always be the case, and
the impl might need to do new things.
... so I'd rather have a spec that evolves over time to reflect
that
myles: So the alternatives.
... One is a spec that changes all the time and is only good on
one device, not great.
... Another is don't spec it at all, and have i tjust be
magic.
... I think I've described a good middle ground.
dbaron: Commenting back on the
plinss/myles convo
... I think using MQ as a signal is a bad idea.
... It's a passive mechanism. One random stylesheet might use
MQs, and if that changes the behavior, it can be a
disincentive.
... So for this sort of thing, I think meta-viewport is a
better signal.
<fantasai> I would prefer to not put more and more rendering instructions into HTML?
tantek: I think I need to see the PR to make more comments, so I'd like to make you a coeditor, make the edits, and have continuing discussion
myles: Yeah, not asking for you to pre-approve things you havne't seen.
RESOLUTION: Add Myles as co-editor to CSS Size Adjust.
<karl> \o/ yeah!
astearns: And I think we have a general agreement ot specify text-size-adjust. Objedtions?
RESOLUTION: Specify text-size-adjust more fully.
<foolip> こんにちはCSSWG! If you're wondering whether to come up the joint session with WPT tomorrow, here's a preview of our short intro: https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing
<foolip> fantasai florian TabAtkins ^
<foolip> Great, see you in the morning :)
<SimonSapin> foolip: in what room is that?
<astearns> SimonSapin: we'll be in the CSS room (Navis-C)
<astearns> trackbot, start meeting
<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
<trackbot> Date: 16 September 2019
<astearns> presenting https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing
<birtles> scribenick: birtles
<astearns> +1 to wpt documentation improvements. It's much much better!
fantasai: thank you for updating
the docs
... it's great to have everything up front
... it would be nice to have a navigation system like a tab bar
or footer
... to connect them all
... it would be easier to get from wpt.fyi to the docs and
back
... second comment: do we have any plans for testing printing?
and paginated modes?
jgraham: we have talked about it a bit
fantasai: do we have any way of
helping people find and run and report results for manual
tests
... there are some things that are not automated and are
unlikely to be automated in the near future
foolip: I know Florian does a lot
of manual tests
... the answer is no
... there is a manual runner on w3test.org but it doesn't work
so well
... and it doesn't report results in the right format
... there are not so many building blocks missing
fantasai: that helps close the
gaps for the types of the tests for which we don't have
infrastructure
... e.g. printing and media queries
... I don't know how we'll test media queries
... someone should run those
... e.g. plugging in a monitor
... if we only run it once, the data will be old
... we need to be able to run it more frequently
foolip: would it be acceptable if
you have to use wpt to run the test?
... locally wpt run
... ./wpt run --manual would be less work than a website
approach
fantasai: it would be nice if you
can load the test on a website
... but the important thing would be to find the manual tests
and then compile a result
... if you can accept data from Peter's system into wpt
reporting system
... that might be a way
foolip: just converting them
would be straightforward I guess
... but do you want to keep maintaining that?
plinss: I would be happy for it
to be replaced
... once its functions are covered
... it tracks what git revision of each test is used
jgraham: perhaps we can follow up later
fantasai: minimum requirement is to get a list of manual tests then provide a report of results
foolip: would it be fine to get all the manual tests in a specific directory?
fantasai: yes
florian: if the system is
designed so that you have to run all of them, that wouldn't be
so convenient
... there are thousands of tests in writing-modes for
example
foolip: if there's no subdirectories then we can maybe use chunking
jgraham: the requirements to run
this probably need to be considered in more depth
... there are data model considerations with regards to
wpt.fyi
... there are lots of technical details
florian: I think it helps
breaking the problem down because eventually we want to replace
and retire Peter's system
... even working out how to display manual tests is an
interesting problem
... there might be conflicting reports
... using an existing data source and then working out how to
display them later
astearns: we do need to work out
how to fix this
... I want to second the joy at the improved
documentation
... I went through the docs to submit a reftest recently and
everything was there
... when I submitted a PR, however, something broken and I
didn't know what to do
... I could see the test results, I submitted another patch and
it passed
... but I don't know how to fix it the first time
... the first two checks were red and I didn't know what to do
about it
... I didn't want to bother anyone
foolip: please bother us
... we need to fix this
jgraham: some of this have failed
for reasons out of our control
... e.g. GitHub actions being beta
... sometimes it takes quite a bit of experience to work out
what went wrong
... there are infrastructure problems but there are also things
we can do better
dbaron: is pinging you on #testing the way to reach you?
jgraham: yes
foolip: or on the PR
jgraham: IRC is generally more
likely to get attention
... can get lots on GitHub email
zcorpan: it depends a bit on what
it is
... if it's something you see repeatedly
... it might be a system bug we need to fix
... otherwise ping one of us on the PR / IRC
florian: in addition to the
manual testing, we need 2 more things to retire Peter's
tool
... one is MUST tests vs SHOULD/MAY
... important for exiting CR
... the other is that wpt.fyi groups report by directory
... but using the metadata pulling results by spec not
directory would be helpful
... then we can retire Peter's tool
jgraham: we are working on
associating labels with tests
... I think that would cover these cases
... if you want that information to be in the test files rather
than in metadata
... then you could have a bot to check they are in sync
florian: currently that data is
in the data, the flags meta
... so we need to sync that with labels
jgraham: that labelling system is
quite limited but it is being worked on
... we could have a script to check they are synced
foolip: if you can search for not labeled tests is that fine?
florian: if there is a button to
click that's better, but as long as it's do-able
... one more question about fuzzy tests
... for non-fuzzy reftests we often have problems where one
side is don't with Ahem and one is not
... but the box is quite large...
... is that covered by fuzzy
jgraham: there are two parameters
in fuzzy reftests -- one is the total number of pixels you
allow to difffer
... one is the amount of you allow in difference per color
channel
... so in this case you would allow a very small range in
difference per color channel
... if you specify one number it means exactly this number must
be difference, but you can specify a range, e.g. from 0
... the other thing is that in Gecko we can have meta files
that layer over the wpt tests so we can apply different fuzzy
parameter for Gecko only
... e.g. we know our form controls differ
florian: for the color channel
parameter, it sounds like what I want to do
... but getting the right numbers might be difficult
... if we can find a way to make that easier that would be
good
jgraham: the screenshot tool could do that
dbaron: the gecko reftest failure
tells you that -- the failure range
... makes it easy to know what numbers to use
AmeliaBR: for SVG I have been
planning to work around this for SVG reftests
... by adding a stroke overline to cover the anti-aliased
part
... not the ideal solution
... but you can block off the regions where you don't care
about differences
emilio: thank you for all your
work
... the tests that keep going to Gecko's internal test suite
are crashtests
... is there any way we can convert them to wpt in the
future
jgraham: I think for crashtests
the thinking is that it's normally a very browser-specific
thing
... there might be cases where that's not true
... if we think it's worth doing it's quite do-able
emilio: I can try to see how many of the Gecko crashtests affect other browsers
smfr: thanks for all your hard
work
... getting Safari's stuff working right is great
... I want to confirm that if a run fails in the middle there's
a clear differentiation between failed tests and not run
foolip: if it fails in the middle we don't get results...
smfr: I'm interested in cases where a test doesn't not run... it should show up as a fail
foolip: a missing test is better than a fail
smfr: just following up on
AmeliaBR's point
... sometimes there are differences we do care about in a test
with fuzzy parts
... a number is not sufficient, sometimes you want to obscure
the irrelevant part
jgraham: the fuzzy thing is a
useful thing, it works in Gecko
... and when running it locally it will spit out the numbers
you need to annotate them
dbaron: the fuzzy number notation
is very useful when they are exact numbers
... since if you get any other kind of number you get an
unexpected pass
<Zakim> majidvp, you wanted to discuss scrolling test automation
majidvp: thank you for adding
testdriver annotation
... for writing scrolling tests, we often need to inject
input
... you support pointer actions, what about mouse
foolip: if pointer actions supports it we can do it
jgraham: if it's not in webdriver we can add a feature request for that
nigel: Hi, I'm Nigel
... part of this group and the timed text group
... there are other members of the timed text group here
<florian> https://github.com/w3c/ttwg/issues/52
<nigel> Joint TTWG/CSS issues
nigel: I want to go through the issues in the order they're listed
<nigel> https://github.com/w3c/tt-module-cjk-ext-1/issues/1
nigel: This is about
text-combine-upright, tatechuuyoko / 縦中横
... the request was to say not to put it in 1em
... to take up more than 1em
nmccully: the normal way of
spacing these characters is that the first two kanji should be
flush
... in the example on the screen, when the characters can't be
included in the line height, they might be allow to intrude
into the sides of the line without making the line any
taller
... then the line won't be any further away than it is
... the other way is to scale the glyphs
koji: this feature is being considered in writing modes level 3
koji: but we didn't include it
because it makes it more complicated particularly when ruby is
included
... it complicates the spec and it's not clear how it should
work
... and the author can work around using inline blocks
... the layout is slightly different from the optimized
text-combine-upright but it's almost the same using an
alternate flow
nmccully: this is a common thing
though so to reject it for the case of decoration being
difficult
... makes it difficult for the 80~90% case
... by requiring authors to do a workaround
... it seems like a lot to ask for the non-decorated case
myles: ruby has this concept over overhang too
<dbaron> I'd note 民國108年 is a good real example (and common in Taiwan) for the 3-digit case.
myles: and that's not
controllable by css
... is this a similar thing that the browser should just
do?
fantasai: it's not a new CSS property, it's just a different way of doing text-combine
florian: is this an author choice? Or the browser does the right thing thing?
fantasai: an author choice
AmeliaBR: the current spec gives a limit for how many characters to compress, but then beyond that it goes to vertical, not horizontal overflow
glenn: the question was "how does the author express a preference"?
koji: they can use a line block to do this
nmccully: can you still get the
same width of the line block doing that?
... or will there be some small space that messes up the
layout?
stantonm: there are two ways you could do it.. you could compress the font size
myles: my question is this additive or a bug we're fixing?
nmccully: the scaling is a less
desired behavior from a typographer's point of view
... we've also tried to work out what the default should be
<fantasai> testcase:
nmccully: most of the time you
see this in dates
... and dates often use scaled glyphs
... with variables going forward we hope font designers can be
more involved with scaling glyphs so they scale well and don't
disturb the line height
<fantasai> updated testcase:
nmccully: for the Web the
preference you currently have--biasing to make everything
fit--it fine
... overhang is more of a print thing
AmeliaBR: this suggested layout is going to affect your line-spacing?
fantasai: because it's an inline block it doesn't include the extra line-spacing so it might fit within the line height
nmccully: so this shows it is possible in the browser
florian: this example doesn't show where ruby goes
pal: not scaling is very common
practice
... in 100% of Japanese subtitles it doesn't scale
fantasai: one of the bad things about this is text-emphasis doesn't work how you would want with the inline-block approach
koji: this is not too rare in
publishing
... compression doesn't give good glyph shapes
... some authors prefer not to compress
... in a single page, authors don't compress
<dbaron> I wonder if that underline behavior is just the result of text-decoration-skip-inc
<dbaron> -ink
koji: but when the text has ruby or decorations, that do compress
<heycam> with text-emphasis and text-decoration: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E
koji: if they don't have decorations, they use inline-block, otherwise they use text-combine
pal: I'd like an action item / next steps
AmeliaBR: file an issue on the CSS repo
fantasai: against writing modes level 4
nigel: also an action to go back to reporter and suggest the best practice we discussed
pal: text combine covers 0% of use cases within the domain of subtitling
florian: an inline block it's a reasonable thing to use when you don't need emphasis, but if we put something in the spec, we need it to work in all cases
AmeliaBR: if you can get pictures of actual typography that does those things, that would be wonderful
pal: so ruby, emphasis on both sides
florian: maybe background colors
iank_: does it contribute to the scrollable overflow?
myles: I think CSS should have facilities for this
nigel: moving on to issue 2983
<AmeliaBR> Agree that the basic feature request, for a new text-combine-upright value for a common typographic pattern, is strong
<fantasai> github:
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2983
nigel: this is about CJK and supporting shearing
<nigel> github: https://github.com/w3c/csswg-drafts/issues/2983
<fantasai> github: none
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2983
pal: today there's the ability to
specify slant on individual characters using oblique
... or italic
... sometimes it's useful to apply shear not on
character-by-character but entire line
... that's desirable to apply alignment between ruby and base
text
... it's subtle but really matters to folks that care
... separate issue about whether or not we should be able to
specify the angle of shear per-character
... issue here is applying by the whole line
nmccully: in print, it's not
keeping the height/width of the line when you shear it
... you change the shape of the box of each character to a
diamond
... it's call shatai in Japanese
<myles> https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html
<myles> this is what Nat is talking about
nmccully: in subtitles has it become just a shear?
pal: it seems to be just a
one-dimensional thing in subtitles
... not sure if it's an artistic desire or technical
limitation
koji: the difference here is a position of the ruby, right?
pal: yes
koji: I'm not sure about this use
case, but for me changing the position of the ruby looks to
me
... shearing the individual characters looks better to me
pal: on the thread some others seem to prefer shearing the whole line
fantasai: for print we know they
want the per-character approach
... so I suggest we propose that and take that to the subtitle
group and see if that is acceptable
... it's possible that the request here for shearing the whole
inline-block is just coming from technical limitations
pal: I like the idea of going
back and asking questions
... but the issue opened against ttml was specifically about
not being able to shear the whole block
fantasai: I thought the problem was that italics shears in the wrong direction
koji: can you point to specific
individual / issue so I can follow up
... I can't see any ruby in that issue
<Rossen__> https://w3c.github.io/ttml2/index.html#style-attribute-shear
<AmeliaBR> text-combine-upright does look bad with individual character shear: https://github.com/w3c/ttml2/issues/784#issuecomment-390856934
<fantasai> https://github.com/w3c/ttml2/issues/784
florian: you said we want to
shear the entire line OR paragraph
... these are two things
... for the second option, CSS transforms will do it
pal: ttml can do all three: character, line, paragraph
florian: the difference with ruby
is more subtle
... but the text combine upright case is more obviously
different
pal: the issue in 2983 shows a
good example
... 2983 ends with a question I asked
myles: any proposal for how the author would describe to the browser the effect they desire
pal: yes there is a proposal there
myles: so a new property?
... has anyone considered re-purposing the new syntax for
font-style to describe the shearing?
glenn: no I have not
... we introduced three new properties: shear (block),
line-shear (per-line including tatechuuyoko), font-shear (glyph
box by glyph box)
myles: one option would be to
have font-style: oblique -14deg does shear
... and if it looks bad it's a browser bug
fantasai: I don't think it will look good if there is latin text involved
myles: there's an issue in the agenda for that later today
fantasai: I don't think we can mix this with the oblique/italic feature
nmccully: It's complicated to
have these different properties, but I agree with fantasai's
desire to have a separate feature for this
... to say I want to shear these things correctly, and provide
an angle, and let the UA decide how to do it (especially for
mixed text)
koji: I agree with myles and don't understand why specifying an angle doesn't work
nigel: you're asking a lot of the implementation and reducing authoring flexibility
koji: what exactly doesn't work?
myles: my proposal is that the
font-style property does more than just font selection
... it does font selection as it does today and also does the
transform as necessary
pal: the way this was explained to me is that the desired effect was literally just shearing
koji: we understand, but the
point is there are other glyph shearing use cases
... that is what myles is proposing
pal: we need to understand three distinct use cases: per block, per line, per character
koji: we have per block already,
myles is proposing per-character
... we are wondering what is needed for line shearing
fantasai: this example on the
screen shows why we can't cover the line case with the same
per-glyph approach
... the characters all shear in different directions when using
font-style: oblique
(example includes mixed CJK and vertical and horizontal latin)
myles: yes, we want to discuss this later today
<AmeliaBR> +1 for keeping this logically separate; too confusing when mixing latin and upright scripts
nigel: I think we've understood the use case better, any proposal action?
fantasai: CSS definitely needs to
solve the per-character shearing
... block shearing is solved
... open question about if more is needed for line-shearing
pal: for block shearing, transform shears the background too. Is that ok?
AmeliaBR: you need a wrapper element if you want to avoid that
pal: does the size change too for
the block too?
... it doesn't so it extends beyond the background
... any chance of a shear property that affects block size?
myles: transforms that affect layout?
pal: yes
AmeliaBR: it could be a dedicated block shear property
florian: the general solution for
transforms that affect layout is hard
... a limited use case could be ok
pal: just reacting to the idea that block shearing is solved
https://github.com/w3c/csswg-drafts/issues/1975
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1975
nigel: action was with us to check that the draft spec text was ok
<AmeliaBR> draft spec: https://drafts.csswg.org/css-text-4/#text-group-align-property
pal: I haven't had a chance to look. What's the right way to test it?
nigel: there's draft spec, but no
tests
... what is the best thing is to do to create those tests
... we don't have any perspective on implementation
florian: it's not implemented
fantasai: to get it implemented, write tests, convince browsers to implement it, hire Igalia, implement it yourself
florian: as far as the WG is concerned, if the spec is done, there's not much more we can do
AmeliaBR: it would be great to
have pictures in the spec
... if you are keen on the feature, adding pictures and use
cases would help
pal: so create a new PR with examples?
all: yes
github: https://github.com/w3c/csswg-drafts/issues/4116
myles: when we discussed this, we
talked about annotating images with baseline information
... is there an image format for subtitles?
nigel: same image format as elsewhere
github: https://github.com/w3c/csswg-drafts/issues/560
nigel: this comes up a lot in
subtitles and captions
... the desire to be able to make text available to the
screenreader while not visually displaying it
... this is particularly important for subtitles because there
is a video behind it which might be showing text, for
example
... so we don't need a subtitle necessarily but we want to
expose it to a screenreader
... there are hacks to do this
... perhaps a display property value
fantasai: this exists in the
speech module level 1
... property is speak
... initial is 'auto' which defers to display
... but not implemented it
... 'never' and 'always'
AmeliaBR: display: none has so many other affects other than just hiding
fantasai: we have a spec but no one is interested in implementing it
nigel: the request is not to
speak it
... it is to make it visible to the screenreader
... it might be presenting it in some other way
AmeliaBR: braille display etc.
Rossen__: you can use visibility:
hidden
... and refer to it via aria-description etc.
AmeliaBR: as the label of a different element
nigel: if you're just labeling an
element then the screenreader might just read that once
... but this is an element whose contents is live
... it needs to read it when it changes
AmeliaBR: there are many demands
this feature beyond the captioning use case
... I'm sure the accessibility people who come in after the
break would be happy to talk about it
nigel: perhaps we can cover it in that session
github: end topic
github-bot: end topic
<fantasai> ScribeNick: fantasai
Janina: FYI but need support from
CSS
... We have a lto of user requirements about using better for
user style sheet things
... Controlling animations was a need, can do , wasn't aware
but that's great
... But need to be able to control spacing between words and
between punctuation
... Can be done on user side, I believe?
... Seems youhave to be an expert user, invoke the htings
... Make that more usable, would appreciate CSSWG support on
that
... WCAG guidelines are quite regulatory
... help to get technological solutions sorted
... and built into browsers
<AmeliaBR> (Better browser support for user style overrides would be wonderful, but yes, probably outside of our realm to specify.)
Janina: Cognitive and learnign
disabilitys and low-vision requirements
... Would it be reasonable to control flashing?
florian: There was a long list of
things you might want to control in your requirements
... not sure we have solution for every single one, but many
are things that authors can control
... and we do have notion of user style sheets
... this is a notion, doesn't have to be a style sheet written
in CSS by programmers
... perfectly OK for User Agent to have a UI that sets these
rules
... cascade then says how the user prefs and author prefs
interact
... but usability of making settings is a UA issue
jcraig: For motion, have
prefers-reduced-motion implemented across browses now
... media features and web pages can adapt to them
... that seems to be solved wrt CSSWG, but usabitiliy can
improve
Janina: Audio, killing all sounds. Part of browser config
jcraig: want sounds on device but not pages?
janina: bubbling up out of COGA (cognitive)
florian: we don't generate sounds in CSS generally, so don't have a way to turn off
myles: desktop browsers have ability to shut off sounds per tab
janina: spacing: interlinear, inter-word, punctuation
jcraig: letter-spacing available
since CSS2.1
... not easy for users to define, but outside scope of CSSWG to
solve
florian: spacing after punctuation specifically is not something we can control on author and user side
janina: request to have more space around punctuation
<tantek> sounds like a feature request
fantasai: We do have word-spacing property, but nothing for spacing around punctuation
janina: can add?
fantasai: depends, do you want different spacing at end of sentence vs after abbreviation? We don't know where the end of the sentence is
florian: spacing requirements are
also quite dependent on language
... various conventions, requirements per
language/writing-system
... so hard to make that work globally
<heycam> fantasai: that's typographic mainly
<heycam> ... a lot of the learning dsiabilityies require -- I would require more spacing after phrases, or sentences, things that need linguistic analysis
<heycam> ... it's a bit difficult to solve on the CSS side
<jcraig> Myles mentioned text-spacing: punctuation
<heycam> ... but could be solved with CSS and a browwser extension maybe
dauwhe_: there's a weird property by Prince called text-replace, we can replace certain characters with e.g. space-punctuation sequence
Rossen__: We have one issue remaining from TTML
astearns: will cover after
janina: next issue, we agreed to do an Accessibility API Mappings with CSS
<dauwhe_> prince-text-replace: https://www.princexml.com/doc-refs/#prop-prince-text-replace
janina: some people volunteered
to edit
... so will be sending a draft
<jcraig> Zoe Bijl and Joanie Diggs
janina: Joanie will bring a11y
expertise
... Zoe will bring CSS knowledge
... Will specify how to standardize across OSes
... Unless questions about that, move on to next issues
jcraig: had issue about dynamic text size, which is CSS issue 3708
astearns: ok next issue...
<jcraig> issue-3708
<trackbot> Sorry, but issue-3708 does not exist.
astearns: brought up by TTML also
<jcraig> https://github.com/w3c/csswg-drafts/issues/3708
astearns: question is how to move forward on this capability
<heycam> github: https://github.com/w3c/csswg-drafts/issues/3708
AmeliaBR: The general use case is when you have text that adds a little extra information for assitive technology but either repeats something already visually on the page
<astearns> github: https://github.com/w3c/csswg-drafts/issues/560
AmeliaBR: or is text that is
already obvious because of other visual cues
... so don't want to print the text, but want available to
a11y
... there are methods used by authors using absolute
positioning or clip
... intentionally picked by authors because not currently used
as cues to screen readers to hide the text
... so feature requests coming to ARIA and CSS
... is to have a simple one property one attribute way to do
this
... there are ways in specs defined to do this
<jcraig> Example of what AmeliaBR is referencing: <p>Read <a href=“#”>more <span class=“a11y”>About widgets</span></a></p>
AmeliaBR: there's
aria-hidden=false, originally specified to do this
... there is the 'speak' property in CSS Speech module
https://www.w3.org/TR/css-speech/#speaking-props-speak
<jcraig> hidden=true aria-hidden=false
AmeliaBR: neither of these is implemented because in reality the visual display property has all sorts of side-effects in how elements are processed
<jcraig> aria-hidden=false was problematic for a variety of reasons
AmeliaBR: and saying 'display:
none' or visually hidden but still available to AT
... has never happened in borwsers
... so feature request is for specific way to do things
... in ARIA yesterday had a talk about, is this really use case
pattern we want to encourage by making it easier to do?
... visually-hidden styles can be misused by developers
... who are only thinking about visually-able vs. blind
users
... missing a huge swath of people usign both AT and visual
rendering
... so argument that this is a hacky approach for a reason,
shouldn't make it easier
... but it is widely-used on the Web anyway, so argument for
paving that cowpath
... my recommendation is to go ahead with this
... and do it in CSS
... because sometimes visually-hidden content depends on
MQ
... e.g. button might have icon and text on big screen
... but on small screen only the icon
... but want AT to be able to see that text
<Zakim> jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind...
jcraig: I think this is valuable
and needed
... but remind group that most screen reader users are not
blind
... there are a lot of low-vision users
... ~ 1/5 are actually blind
astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage
florian: the reason why neither
ARIA attr or speak has been easy to implement
... is because AT works by reading plain text off the render
tree
... this is the reality today
... can't ignore it
... but causes many problems
... exposing info to AT
... I hope this is merely current reality
... and not long-term goal we want to maintain
... because in that case many limitations
... there are many cases where we would want to work from DOM,
not render tree
... because render tree has lost information that's in the
DOM\
... I think we will see that problem in a number of use
cases
... I would like us to not abandon idea that aria / display
proposals
<Zakim> nigel, you wanted to point out that for text to describe media content the solution has to work in an ARIA live context
florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved
nigel: Some of the proposed
solutions/hacks might not work for ARIA live regions
... for ? put forward this morning, want something that
describes content in a video
... gets read out during playback of video
... want to use ARIA live region approach
... and have AT notice that
<florian> s$that aria / display proposals$that aria / speak proposals$
nigel: biggest gap we have is
something that, following from florian's point, here is some
text from render tree
... don't actually paint pixesl for it, leave layout
alone
... atm visibility: hidden has effect that some screen readers
don't read it out
... I would separate visibilty from display
... I would expect display: none to never feature in a
display
... but visibilty is not rich enough
<florian> fantasai: visibility hidden currently leave things in the layout tree
<florian> fantasai: so they take up space
<florian> fantasai: we probably want a variant that doesn't
jcraig: technique used is positionign off-screen and clipping
nigel: want something more proper
astearns: and more simple
tink: I'm really strongly in
favor of this proposal
... than existing methods, which cause alls orts of
problems
... can confirm that visibility: hidden does get hidden from
screen readers
... if we go ahead with an idea like this attribute
... what will we do with tab focus?
... techniqe that jcraig describes
... tab focus disappears off screen
... some renderers will screw up rendering as a result
... would there be some mechanism to get around that
problem?
AmeliaBR: that's a very good
argument for a proper bult-in feature
... then browser knows to override hiding and make things
visible
... with current techniques, up to author to have a special
focus rule
... to handle that case
... strong argument to have dedicated feature so browser knows
why this style is being set, and to override
tink: so if was focusable content
hidden, once it got focus would become visible
... makes visible, but if contents appear from off-screen, that
would be quite disruptive
... is there a possibility to do it the other way around, take
things outside of focusability?
AmeliaBR: that wouldn't help with skip links
tink: screenreaders have much
better ways to navigate content
... skip links are mainly useful for sighted keyboard users
florian: would be problem to make
things visible without author expecting it
... likely to break things
... would rather make it not visible, invoke HTML inert
behavior
... author can pop things into visual space if they want
AmeliaBR: or maybe two different
values of a property, recognize different use cases
... standard skip link that should become visible
... and extra information for screen readers
<Zakim> jcraig, you wanted to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details
jcraig: couple techniques
mentioned, one seemed reasonable was HTML hidden=false
... aria-hidden=true
... or reverse of that rather
... webkit was the only browser to implement
... was very tricky, because webkit builds accessibiltiy tree
off of render tree
... this was after fork from blink, so blink doesn't have
... firefox same thing
... so very challenging
... after noticing bugs
... decided to only allow this if every ancestor above was
displayed
... so child node could be hidden, but not descendant
... not sure that's the right path, but is the one available
atm
... technique in the ARIA spec, aria-hidden=false not
recommended
<Zakim> nigel, you wanted to reply
jcraig: hidden=true aria-hidden=false
nigel: interaction between
attributes and CSS properties not clear in spec, and varies in
implementations
... there some weird stuff going on there
... my conclusion was to ignore HTML hidden
jcraig: on WebKit side, implementation was hidden=true { display: none; }
Rossen__: Edge actually supports
everything you said about computing aria and various
permutations
... there is an effort that was in EdgeHTML
... have ongoing work in Chromium to add additional
capabilities to handle that n Chromium-based browsers
... not sure where Mozilla is
jcraig: no plans last I heard
<Zakim> ZoeBijl, you wanted to say that there are more assistive technologies than screen readers
ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff
?: displaying something ...
jamesn: Issue of deliberately
making things visible
... another use case is when you have native HTML control that
you do not want to display but you want to use all of the
properties that you get for free
... e.g. range control, can't increment/decrement unless
native
... but can't sytle it properly
... so hide it, and display your own control over it
... common authoring technique right now, because can't make
controls accessible on moble
... is one custom control for visual, and one hiden native
control for interaction
... hidden using very low opacity so stll there
... you wnat it to not be inert in this case
<nigel> scribe: nigel
fantasai: we've heard a lot of new info in this meeting
<florian> fantasai: we've heard a lot of new information
fantasai: next step is someone to
draft a proposal for a new CSS property or value
... probably a property
<jcraig> display value?
fantasai: that takes into account
the use cases here and the various limitations
... I haven't heard a proposal yet.
<fantasai> astearns: https://github.com/w3c/csswg-drafts/issues/560
astearns: Is there a specific CSS issue for this?
fantasai: We definitely don't
want to use the display property for this.
... too many other effects.
... There is an existing property in the speech module called
speak
... which was intended for this use case but it doesn't address
the issues of the render tree and focusability
jcraig: I've evidence that it was
never intended to address this
... it's well specced for DAISY
<fantasai> jcraig: css-speech is very well-specced for DAISY use case, not for screenreader
<scribe> scribe: fantasai
astearns: need a volunteer
... lacking a volunteer, keep the issue open and periodically
ping people
tink: can try to put words together but need someone on CSS side
AmeliaBR: I can help
<scribe> ACTION: Amelia and tink to draft a proposal
<trackbot> Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24].
<IanPouncey> I can also help.
astearns: and bkardell_
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3870
krit: To summarize issue here, we
ahve a spec where animations are appleid to transforms in the
transforms spec with combination of SMIL
... but I think this entire section shoudl be removed
... section introduces transform to the animate and set
elements, both SMIL elements that refer to svg aniamtions
... in addition to what is in SVG already
... but there is no ? and no interest to implement
... so request to either defer or remove entirely
... if section gets removed, then there's nothing about motion
in the spec anymore
AmeliaBR: issue is just asking you to add an accessibiltiy section?
krit: issue was about adding
section about accessibility
... but we removed the section reference to motion, so no need
for adding an accessibility section
AmeliaBR: one paragraph of animating transforms can be bad ?
fantasai: anything can be
animated, width, margins, etc. do we add to every layout
feature of CSS?
... I think better to keep in the animation section
AmeliaBR: so requesting to clsoe this issue as wontfix and follow up with getting it addressed in CSS Animations
krit: yes, but request woudl be
to defer the entire feature
... if we want to do that, would suggest to try with SVGWG or
SVGCG first
AmeliaBR: so other feature request is adding way to pause CSS Animations, which we don't currently have
krit: right
AmeliaBR: Dont' see why this should be deferred to SVG, CSS Animations has ...
fantasai: do we need to discuss all this with A11y?
krit: need to close issue no change beause moving teh section
IanPouncey: comment about
documenting a11y concerns
... while I don't have a particular problem in this case
... just want to say the wya ppl use these documents is to find
example they need and copy it directly
<tantek> I'm wondering if the request for the ability to "pause animation" also includes the ability to slow down the animation
IanPouncey: not going to look at
different document
... in some cases we might want to have notes in multiple
locations therefore
krit: would maybe put in boilerplate to add to every single module
<heycam> fantasai: if you put it in the boilerplate, it'll be at the top of the spec, and someone linking into the middle of the spec won't see it. maybe in the animation type definition?
fantasai: which is linked from propdef table
IanPouncey: happy to draft that note
AmeliaBR: I like fantasai's
point, we do have a link from every CSS property definition
"Animation Type", can put the note there
... each spec item in the spec would be connected to the
warning
... Proposal is wontfix on request to add a11y consideration
section to css-transforms
... for the remainder of the issue, request for
pausing/stopping
... that will be opened as new issue on Animations or
Transitoins
krit: can only wontfix if remove
the animation section
... so request is to remove animation section
... since feature that is added on top of SMIL and no interest
form impelmenters and from community
astearns: so proposed to remove the section and wontfix the issue
AmeliaBR: can be moved to SVG
Animations Level 2 which may or may not ever go anywhere
... but that's where the text is lived
astearns: open a separate issue
on that
... for this particular issue, remove section and wontfix
RESOLUTION: Remove section on animation and wontfix issue about paragraph about accessibility because no longer relevant
astearns: out of time
<br type=lunch>
<heycam> ScribeNick: heycam
<astearns> https://wiki.csswg.org/planning/tpac-2019#tuesday
github: https://github.com/w3c/csswg-drafts/issues/4154
florian: the :lang selector lets
you select pieces of the DOM for styling based on the
language
... it's alreay somehat smart, since lang tags are
structured
... selecting zh, and the document saing zh-Hant, it will do
the right thing and match it
... that logic is already built in
... the IANA maintains a registry of the langauges that exist
and what they mean
... tags and subtags
... and in addition to just listing them, there is logic in
that registry. some languages are a deprecated version of some
other languages
... Cantonese used to be zh-yue. that is deprecated and
replaced with yue
... the lang selector does not take that logic into
account
... so if you have a document marked as lang="yue", and you are
matching :lang(zh) or :lang(zh-yue), it won't match
... we may want to use the registry definitions of how to
match
... I propose we do that
addison: some tag
canonicalization is defined by BCP 47 to consume some of the
information in the registry
... you've been corresponding on the IETF langauges list and I
think some of your questions have been about handling
macro-languages -- zh-yue is a macro language
florian: zh-yue is a macro language, zh is a macro language
addison: there's a separate
thing. previous to the current BCP 47, there was a mechanism
for regsitring whole tags
... that's grandfathered now
... some of them match subtags, some don't
... [...] is replaced by xtg
... ignoring grandfathered tags, they all map to something. the
ones you're referring to are structurally identical, the tags
are composed of subtags
... like zh-yue
florian: the way I'm looking at
this, there are variety of reasons for why certain langauges
might be the same
... there is a defined canonicalization that handles some of
them
addison: for the BCP 47 canonicalization, that will do awy with the grandfathered ones and other strucutral weirdness
florian: it won't deal with the
two types of norwegian
... this is a complicated topic with many weird variants
addison: there's a subset there
that's well defined
... there's a second set of rules, which are in CLDR
... UTR 35
... for handling some additional cases around Chinese, where
you have different script subtags that you want to appear or
not in some circurmstances
... some of those may be of interest, but it's more
complicated
... I don't want to pretend that doesn't exist, but they do
florian: if you have a link, please drop it
addison: defining matching, if you're just using BCP 47 "lookup" IINM
florian: extended filtering
... the text for extended filtering says you should
canonicalize
addison: yes you should
florian: thanks for bringing up that the topic is broader
addison: if you do the minimum
set, it'll make it the most predictable. the other aspects are
worth studying
... there are some annoying corner cases in Chinese
florian: I hear support for the current proposal, and complicatd problems to think about in addition to that
addison: yes I agree with your current proposal and then do further study, and track the other standards happening in that space
florian: there is a PR for this
addison: should we review that?
<fantasai> https://github.com/frivoal/csswg-drafts/commit/3cff5d844b6415ef30d3e2dac221f9479e0ec7aa
florian: if you haven't I suggest you do
AmeliaBR: the other question on the topic, do we have implementor commitments?
r12a: the current text I'm
looking at says "... must be converetd to x-lang form"
... that's a slightly different discussion from what you
canonicalize it as
... zh-yue would become yue
florian: I had that discussion on
the list as well
... this is the right direction
... zh doens't match yue. so if you canonicalize both to x-lang
format, it'll match
... I raised this on the mailing list, and they agreed it was
the right form to canonicalize it to
addison: some people on the list
did
... the challenge is taht this will bring you more promiscuous
matching than the author may have intended
... it'll make Canontese match Mandarin Chinese in some
cases
florian: if you want to match Mandarin specifically that's also possible
addison: normally Mandarin is tagged just as zh
r12a: for all the macro languages there's usually a preferred language
fantasai: if the author cares that much, they can put the information there
addison: that's right
... you don't want to have them with a correctly tagged
document, have the :lang match things they were [...]
duerst: that mailing list is no longer a WG
<addison> http://www.unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers
duerst: so people can give you opinions and background knowledge, but no formal resolutions
<AmeliaBR> So, to cases: (A) author used zh in stylesheet and yue in HTML; doesn't expect a match. (B) author used zh in stylesheet and zh-yue in HTML; does expect a match. Canonicalizing both yue and zh-yue to the same value will break one or the other.
florian: I agree that the problem can exist in both directions, too much or not enough, I think since we're doing it for typographical purposes, and the languages are realted, most of the time if you have zh styles you want it to match Cantonese too
<addison> http://www.unicode.org/reports/tr35/#Likely_Subtags
florian: it's possible to style Mandarin differently from Cantonese, Hakka, etc., but that's rare
r12a: it's not just Chinese we're
talking about
... there are other languages that have much more
differentiation between the language depending on which of the
subtags you choose
... the point I watned to make was that we said that let's go
ahead with the proposal at the moment
... looking at the issue, there was a proposal you wrote, I
responded saying you had to modify that
... the PR doesn't say much
... not sure what the exact proposal is
... I think this information we're talking about now should
also be part of that
florian: the earlier proposal
that you rightfully pointed out I wrote too much, including
making zh-HK match yue and things like this, that's not defined
in the repo I'm referring to
... I'm just saying, just the canonicalization to x-lang form
as defined by BCP 47
... and as supported by the mailing list that used to be the WG
that used to define that document
... btu whichever way we go, including no change at all, has a
risk of mismatching things in some cases
addison: not all tags match all
values, otherwise what's the point
... the problem is to arrive at something that authors
understand how to get the results they want
... we'll make some compromises, the question in which ones
fantasai: based on the
conversation so far, it seems like I don't think canonicalizing
yue to zh-yue is going to be good. either we don't canonicilze,
or in a direction where zh encompasses Cantonese
... I am sure there are style sheets that just use :lang(zh),
and they'll expect it to match
addison: the other possibility is
that the inclusion or non-inclusion of the enclosing subtag --
in this case zh -- is a choice the author is making
deliberately. if they've made that choice deliberately, if we
mess eith their tags when doing matching it may produce results
they don't expect
... most of the matching algorithms are strict "remove from
right" subtag matching
... to make it obvious what's happening
... what's you start adding or subtracting subtags in ways
other than the deprecation/renaming, I think that has more risk
to it in your space
... since it's not obvious what's going to happen
... I would support doing the mappings that's in the registry,
since that's where if you have mlutiple variations, because
people have older documents and style sheets, they'll get the
right answer
... that's different than adding or subtracting subtags
<Zakim> AmeliaBR, you wanted to suggest that this is better dealt with in the user agent stylesheet
AmeliaBR: we covered a lot of
what I was going to say, but witha different conclusion
... it's important that when matching a style sheet and a
document that we respect the way that the author matched it,
don't want to introduce spurious matching from
canonicalization
... also don't want to break matching
... from the examples brought up, it's obvious that any
canoniclization may end up breaking one site or the other
... the question is then how do we make it easier in the
general case for having new style sheets or new UA style rules
deal with all these deprecated synonyms
... at the UA style sheet, that can just be an advice to UAs to
look up the BCP deprecation list
... then also included the deprecated synonmous
... that doesn't work for things like a style sheet that is
coming from a library or CSS reset
... or the case of newer code, writing a new new style sheet,
but still apply to the old pages with the older language
tags
... one approach that might address that use case is something
like what we do with case insensitive selector matching
... a flag in the selector that means "this value or any
synonms"
florian: so an opt in for canonicalization
addison: there are three
sets
... the grandfathered list is permanently fixed and has been
for 10 years
... all those tags have explicit mappings, you can safely map
them to modern equivalents or vv
... individual subtags that ahve mappings, it's mostly about
countries going out of business
... yiddish has two subtags, hebrew has two subtags, there's a
canonical one
... the third thing is the x-lang thing, which is
inconvenient
... because there's two ways to say things. with or without the
enclosing subtag
... the canonicalization rule in BCP 47 says you can drop the
primary langauge subtag and use the x-lang by itself
... it's permissible for implementations to do that
... I don't recall it says you can put it back
florian: there are 2 sets of
rules
... one that just strips it off. the other says when you're
done stripping it off, put it back
r12a: it says you could consider doing that
addison: the first two are
completely safe
... you want to do those
... for interop
... the x-lang thing, I think you can choose
... whether to put the enclosing subtag on
... the challenge is that Chinese you'd want to do that, but
some of the other macro languages are not as crisp. Arabic is
one of these, Malaysian
<r12a> https://r12a.github.io/app-subtags/
r12a: Omani Arabic and Moroccan
Arabic, which treat certain things differently, may have
different font requirements
... but they both resolve to "ar" if we follow this PR
... but that's used for standard Arabic
florian: I think we're not ready
to merge the PR
... action items: the safe subset of canonicalization, I don't
think it's defined as a canonicalizing operation separately
from the x-lang thing
... action on me to find out if we can
addison: this is an area that
probably deserves better documentation from us
... we can go offline and make sure we get the right
answer
... we can go back and talk to the locale folks at UNicode and
the languages list and make sure we're capturing the sense of
this
florian: one, figure it ouf if
the safe subset exists as a standard operation
... two, if we do what I'm proposing, look at the affected
languages and see if it's good for them
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3897
fantasai: there was an issue
raised about what happens when you have two inline elements
that have different ine breaking rules
... 3 props control this. white-space, word-break,
line-break
... looking at an example (in the GitHub issue)
... at the boundaries of the span, which line breaking rules
applies when it has a different word-break prop value to the
rest of the text
... for white-space, the nearest common ancestor is used
... the complication for word-break and line-break is that the
determining rules for where you're allowed to break requires
running an analysis on a lot of text
... and every time that value changes you have to do another
run, so impl wise it's a bit awkward
... there's been some discussion about what's the best behavior
here
... I wanted to ask i18n if you have feedback on this
issue
... and ask the WG if this proposal to leave this undefined for
L3, give impl time to experiment
... doesn't seem to be a terribly high importance case to solve
at the moment
florian: I think one of the more
interesting cases -- and I suppose making it undefined -- is if
the aprent div allows a break between every latter, and two
spans next to each other which don't
... can you break between the spans or not
... current spec says yes, but it's hard-ish to implement
... if we need time to think about this, undefine it for a
while, seems reasonable
... but that's the kind of case this brings to the surface
Rossen: any objections to leaving it undefined?
r12a: we should look at it as a
group offline
... it's quite a long thread. I seem to remember someone
brought up an example that didn't work
nmccully: are there layout engines working on this that would benefit from the extra time?
fantasai: part of the issue is
part of the ICU APIs make it awkward for the rules to change in
the middle of the line
... so impl wise it's awkward
... could be factorial if you're changing it every other letter
in the line
... so there's some hesistancy to impl that given the current
infrastructure
... but there doesn't seem to be great solutions
... some of the behaviours you'd get from doing an easy thing
would be non-symmetrics
... you'd be switching slightly less if you use the current
rule in the spec
... there's not a high pressure to solve this and get
interop
... look at it again in L4
myles: tangential comment, the
general thing we're discussin is styling element
boundaries
... this is something letter-spacing also does
... the spec says something that all browsers diagree ith
... with we do come up with a good way to describe boundary
behavior, we should try to use this system to describe
letter-spacing too
fantasai: I think the spec is right on letter-spacing
nigel: I think it would be good to have a general way to handle this
florian: we have a current generalized rule, that is general, and does the right thing, and is painful to impl
RESOLUTION: It's undefined
<fantasai> https://github.com/w3c/csswg-drafts/issues/3481
<fantasai> https://github.com/w3c/csswg-drafts/issues/337
RESOLUTION: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined
github: https://github.com/w3c/csswg-drafts/issues/3481
fantasai: we generally have this
concept in CSS and HTML that you can use white space to format
your source, and we collapse white space down to a single
space
... including line breaks
... for Chinese and Japanese which don't use spaces, we have
some rules to remove the space otherwise you will be forced to
put all paras on one line
... there are some rules for doing that based on character
classes
... what we didn't consider thoroughly is languages that use a
word separator that's not a space
... we do special case ZWSP, for Thai and other languages
... but we don't have something similar for Ethiopic word
space
... probably don't also want a regular space there
... proposal is when there's a word separator character
adjacent to a line break, the line break just goes away
... I think the characters that are affected here are Ogham
space mark and Ethiopic word space and the Tibetan tsek
AmeliaBR: does this map to something in Unicode? or do we need to maintain this list?
<koji> https://drafts.csswg.org/css-text-3/#word-separator
r12a: I think there is something,
not sure if it's fit for this purpose
... archaic scripts have other examples
y
fantasai: [reads definition in the spec right now for word-spacing]
florian: we need to maintain a list
myles: let's ask Unicode to do
it
... if there is such a facility for these character lists, hard
to believe it's specific for the web platform
... and not needed in text editors for example
... I don't think the web specs should maintain this list
florian: I agree with part of
your statement, should try to work this out with Unicode
... this one specifically maybe, but some are specifically web
platform relatively
... since this is relevant to turning HTML markup into text
myles: there are many different markup languages...
fantasai: there are 2
questions
... if we want to do this, and then whether we maintain the
list of if Unicode should
addison: i think we want to do
some research
... space or no space is a classic problem
... I would be surprised if there weren't something, but don't
know off the top of my head
... would be happy to engage
myles: if this is a classical problem, it's been solved, and we should figure out how it's been solved in the past and re-use that solution
fantasai: looking at some of the
stuff in css-text, weh ave a concept of word separateors
... and it includes a set of code points
... it excludes Ogham space mark
... since it would cause text to not join any more
... so general usage in UNicode is text processing segmentation
is not going to account ofr that concern, since they don't deal
with typesetting
... so there's gonna be some aspects of how we're using Unicode
codepoints with sepecific requirements that haven't come up in
Unicode's context so far
... unbreaking lines is something that's been hard to explain
to them
myles: maybe we shouldn't be unbreaking them?
fantasai: too late for that!
addison: fwiw I've had to write
this code in the past, and it's not any fun
... it maye have been individually solved but not written
down
<fantasai> fantasai: HTML has been unbreaking lines for as long as it has existed, we want to make that ability available to more languages
r12a: like with the other issues,
we need to look in more detail
... the Tsek is a syllable separator, not the same as a word
joiner
... you could end a line with a Tsek, then start with more
Tibetan on the next line, with indentation, and no real reason
to join those together necessarily
fantasai: you wouldn't make the Tsek go away, just avoid the extra space going in there
<scribe> ACTION: i18n to look this issue of word separators next to newlines
<trackbot> Error finding 'i18n'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.
<addison> ACTION: addison: ensure we respond to css 3481
<trackbot> Error finding 'addison'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.
<fantasai> ScribeNick: fantasai
chrishtr: device-pixel-border-box
is the actual device pixel bounds of a canvas element
... including pixel-snapping feature which is ued by browsers
to avoid blurriness by snapping to pixel grid
... fundamental problem with no complete solution
... authors that use canvas
... have no reliable method to determine on-screen pixel size
of the canvase
... if off by one pixel due to pixel-snapping, rounding, or
other issue
... will end up with wrong or blurry results
... pixel-snapping is intentionally not specced to allow UAs to
do their best
... acocunt for varying rendering architecture
... and evolution
... so no way to reliably find this size
... proposal is to add a box that observes device pixel border
box
... to ResizeObserver
... which will notify if that box changes
... will happen at similar timing as other ResizeObserver
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3554
chrishtr: there were two main
objections to adding this
... one was raised by Jeff Gilbert
... had a long discussion with him and Ken Russell, our WebGL
expert (?)
... have a compromise proposal that both of us agree to
... objection he raised was that if you have a WebGL-centric
application
... e.g. full-screen game that uses WebAssembly and only DOM in
minimal way
... want to have a continuous requestAnimationFrame loop
... drawing the canvas
... in that model where you are canvas-centric
... it still lives in a DOM shell or browser window that has a
size
... need to observe that size
... where pixel snapping will work
... but in Web Assembly not in JS
... most convenient to query device border box directly from
canvas during rAF loop
... rather than by observer
... if layout was dirty at the time during making the query, it
will force layout and other things in order to compute pixel
snapping
... in taht use case maybe it's OK
... other use case, which I was most focused on
... you have canvas element embedded in a DOM-centric
website
... maybe photo-app or ad or widget,
... potential multi-actor scenario
... want to avoid layout thrashing
... cases for which ResizeObserver was designed
... this makes most sense
... compromise proposal is that we just have both APIs
... The End! :D
jeff: ....
jgilbert: ... moving forward with
both propsoals works out
... having it be in ResizeObserver also makes sense
... like you went over, there was some concerns about it
covering espeically more easily some more trivial cases
... having both lets people pick and choose appropriate
API
... default should be to use ResizeObserver, most
reliable
... kindof like getClientBOundingRect() , need to be careful if
calling that often
... maybe warn in UA
... if called too often
... but getDeviceClientRect() API alone ...
chrishtr: 2nd objection smfr
raised
... pixel-snapping requires more information than just layout
in today's engines
... in Chrome requires pre-paint step
... in Safari requires paint
... don't have solution to that problem
... just note readback method for rAF
... canvas.getThing
... also has to run the same steps
Rossen_: but that's not blocking to accept the proposla
smfr: in some ways make sit
worse
... because 2 places we have to do this painting
calculation
Rossen_: was asking if this second objection is blocking accepting the proposal
smfr: so to clarify the proposal
is having API to return the box on canvas and also in
ResizeObserver
... I'm not a fan of doing partial paitn to get this info
... I would expect for games , especially in full-screen, to
position on ? boundaries
... surprised if using fractional pixel positioning
jgilbert: for full-screen,
unlikely, but for partial screen almost always get this
... both on Windows and on Android, I believe, Windows will
happily give you 1.6574 device pixel ratio
... you just have to deal with it
... you end up trying to reverse-engineer what pixel-snapping
is to figure that out
... pre-snap a rect to a non-integre CSS size , if that works
out to integer pixels... then no artifacts? but it's a huge
mess
smfr: other case that's confusing
is on our iPhone's that have retina displays
... already 2.7? scaling factors
... so can cause hairlines to disappear aetc.
... seems like also on windows, too
... getting pixel perfection, seems like OS is doing scaling
behind your back, how can you expect it to work?
jgilbert: out of the box cases
where if you play around with virtual scaling
... on a Mac and play with scaling on a retina screen
... no way to get 1-1 device pixel
myles: even worse, the default ratio is not 1-1 or 2-1
jgilbert: it really depends on
how the OS is doing this sort of scaling
... I'll add that what you end up with, for instance in Mac,
when you have this OS-level virtual resolution scaling
... can't get one to one
... if can't get 1-1 in application, can still get moire
effects
... can't entirely eliminate scaling artifacts, but can do
better
... than naively try to grid on the screen and hope it looks
good
mattwoodrow: difference is on
Windows the scaling isn't hidden
... can attempt to match
jgilbert: windows 10 implements
scaling that llows 1-1 rendering, not virtual scaling as
default
... Mac doesn't expose effective scaling, just says 2x all the
time
... Android says 3x all the time
??: regarldess of what operating systems do, if application renders pixel -perfect
??: Result will be better than if it wasn't
??: I think we agree on that
myles: if goal is to get hairlines, even if you get a little closer to hairline, can still disappear
??: Display scaling might give you smoother color if checkerboard is pixel-perfect before the scaling
mstange: and if you have
checkerboard before scaling, then less smooth design
... still discussing value of getting an accurate box? what's
status?
jgilbert: if we decide that we
don't want to give ppl this box, then ?
... do we want to get into that? or do we want to take it as a
given that we're trying to give ppl most correct idea of device
pixel than we can?
mstange: what we would need to do
in Firefox to get this result
... Firefox takes into account the full zoom, and takes into
account CSS Transforms
... space in which we snap is established by the closest
animated ancestor transform or the root
... we only know this info during painting
... so would need to run more steps before giving info
smfr: this device border box
would not be affected by transforms
... so would have to do *special* calculation
jgilbert: 3D transforms no idea
what to fee dback
... pixel-snapped bounding box?
atotic: if you're doing
transforms won't be pixel-perfect anyway, so don't worry about
it
... your'e also talking about implementation that you need to
get this nformation during pre-painting
... remember you had this information ??
... Might be ok to deliver incorrect information and not have
to paint
myles: there's a chance of you never get correct info
atotic: I think you want, once
things have settled down want accurate box size
... if animating, don't care so much
jgilbert: deliver informmation
lately
... would be nice if we could try so that you could do 1-1
perfect every time within certain set of constraints
... be nice if we didn't immediately settle on a 1 frame late
policy
... matching what native APIs are able to do
... don't want to suffer if dont' have to suffer on native
myles: if it is one frame late
then the exact timeline that we drop frames is exposed to the
Web so don't think we want
... similarly, worried that we'd have to reverse-engineer
chrome's pixel-snapping strategy
jgilbert: shouldn't have to do
more normalziation than you do today, I think
... if trying to use this to get anti-moire, in order to do
this today have to ??
smfr: one frame late version also problem of which rectangle to trust
chrishtr: not late if layout
occured
... only late if you have a threaded animation
smfr: thought it would be late because we woudl collect info at paint time
chrishtr: I don't think we shoudl
do that, disagree with atotic
... think we can do it therefore we should
... in cases where layout has occured
... agree with point about threaded animations and not syncing
with JS thread
smfr: want to tie together two of
previous points, first that if we implement this paint day
device pxel border box, will be more expensive for us
... secondly because of physical mismatch, wouldn't have some
user benefit
... display is scaling anyway
... can we get examples?
... want to try on Apple devices, see what would happen if
looks right
atotic: moire patter
... if you're moving canvas around the screen, the moire is
animated. looks really bad
smfr: please give us some tests
chrishtr: I think time is
up?
... propose to add the feature?
Rossen_: does the group feel
there's enough merit to add this?
... would be adding both APIs
... is there any objection?
smfr: I dont' think we can accept new API without evidence that it's so much better that it's worth the extra cost
fremy: you can agree with the API and just return some approximate result if you feel it's good enough
myles: your'e saying implement the API without implementing teh API
fremy: might not be useful on
your device
... but might be useful on Android
... so just return the result
AmeliaBR: Not having an API is
better than having API with bad results
... if a particular browser has particular concerns about
implementing the particular API
<jgilbert> fantasai: in this case it would be, if you as an author were trying to do this thing, and you had this browser gives me the actual DPR, and this one gives me some approximation of the size
<jgilbert> ... I still need to size my box either way
<jgilbert> ... if my choice is I can get teh actual device pixel size from Chrome, but calcaulate it myself from widht/height props in WebKit, and get an approx result, then I don't know it might be better to have an API that does that calculation for me
<jgilbert> ... then I only need to write one code flow
AmeliaBR: might make sense, but have existing cases where you can't trust the API
florian: In general I agree with your statement, this doesn't seem to be such a case
Rossen_: I woudld like to end
this topic
... going to call for objections to adding the API, if we have
objections we'll deal with them and have additional
conversatiosn with the TAG and whatnot
... any objections to having these APIs?
smfr: Can we wait until we ahve the examples?
astearns: I might object because
seems like we need more data
... so I will object on Safari's behalf
Rossen_: so back to you to get test cases, we'll discuss again on telecon
<florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
<mstange> ScribeNick: mstange
florian: We've been working on
the writing mode spec for some time. I've updated it since I've
showed it last month.
... Out of about 1000 tests, about 14 failed and 24 others
failed. (?)
... There will always be some tests that fail. We'll be fixing
things forever.
... Have we done enough fixing already to move on?
... There is a number of issues that are marked in yellow,
which are a not insignificant part of the remaining
tests.
... They have some patches which are about to land in Gecko so
that they will pass.
... Some tests could be split up into two tests, both of which
will each pass in different browsers.
... There are a couple legitimate failures as well.
iank_: Please don't remove tests that test intersections of features. Those tests are useful.
florian: In this particular test,
the two features are independent. The intersection is not
tested.
... The test results are from current Chrome Canary.
... We have not done enough work on writing modes to never
think about it again.
... But I don't think any problems are in areas we believe to
be wrong in the spec.
... It's my opinion that we can move on despite those
failures.
<xfq> Current open issues (for L3): https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3
<Rossen_> https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3
fantasai: There are some issues about things where the spec is unclear, and we should just do those clarifications.
florian: All issues are about things that ought to be better defined. But we need help.
fantasai: I think it would be better to address these issues before saying that writing mode L3 is done.
dbaron: I've been uncomfortable
with some of the things about intrinsic sizing.
... I think the third issue is more on the material and sizing
than on the material and writing modes.
... In response to being asked to implement something in
Firefox, I ran into a list of conditions that was unclear.
florian: Was this not partly answered by text that was restored?
dbaron: I think this was after it was being restored.
florian: fantasai discovered that some section had been lost and it was recovered in late August.
dbaron: This is a specification
pattern that is difficult for authors. Rather than saying "You
want to compute X", it says "You calculate in the following
terms".
... It is very hard to know what some of the terms mean in a
specific context.
florian: I agree that this
specific text should be tweaked. But the level of writing in L3
is higher than in L2. Raising the bar of writing is good, but
gating specs on that bar might not be necessary.
... Can we address this in L4?
dbaron: I guess. L2.2 probably did not have backward references to things that were poorly defined to the degree that L3 does.
Rossen_: How do we move writing
modes forward?
... Do we actually want to hold off and resolve on these issues
with additional spec works and re-enter PR at a later time?
fantasai: With the exception of
some tweaks, Gecko seems to have implemented this just
fine.
... We are basically rewriting all of CSS 2, but we need to do
it in pieces. The current writing is not ideal, but it is the
best I could do without rewriting chapter 10.
AmeliaBR: Given that fantasai has said that Gecko is right, could dbaron suggest new text that describes that & addresses his issues (in time for publication)
dbaron: The hard part is the edge cases. The question is not, "Do we follow this list of things in simple case X which is being tested", it's "what is the exact list of cases where we need to do this list of things"
Rossen_: We almost went into Rec two or three years ago. I think the level of the spec is fairly high at this point.
dbaron: I'm ok moving forward if you want, but there are cases that are not defined enough to be implementable in an interoperable way.
fantasai: This spec was written assuming grid and flexbox do not exist. We can't make this gate on defining exactly how things work in grid and flexbox.
dbaron: It would be nice to give an example where this list doesn't apply.
fantasai: I don't know of one.
dbaron: That's why I suggested stating in the spec that it always applies.
<astearns> +1 koji
Rossen_: The proposal was not to
resolve the issues, it was to move them and retag them for
L4.
... Any objects to retagging the three issues to level 4? Those
are 4026 3095 and 2890.
<astearns> and they will need to be added/updated in the DOC
Rossen_: No objections. We will
move these issues to be tracked under L4.
... Are there any objections to move CSS writing mode Level 3
to PR?
... No objections, resolved.
<fantasai> fantasai: Ah, the case was about computing max-content inline-size vs auto block box inline size: in latter case, it's not well-defined what max-content computation is in CSS2, so could be conceptually that available size is infinite, and it's OK. But auto width computation needs definite length to subtract margin/padding/border from and result in non-infinite content-box width, so can't use infinity, so
RESOLUTION: Move CSS Writing Modes L3 to PR.
<fantasai> have to use fallback size
github: https://github.com/w3c/csswg-drafts/issues/2531
myles: We have two text paths. In
WebKit. The distinction which path to go to has to happen
before font fallback.
... Sometimes we detect something too late and can't go back
and re-do everything, so we just do our best.
... If this is not necessary for the web platform, let's remove
it.
fantasai: It does look like there
is an implementation (faceless2 says it in the issue)
... If the feature doesn't have a problem, we should leave it.
We do not need implementations to move this spec at the
moment.
myles: When is the deadline? It's been years.
Rossen_: This is a non-verifiable implementation. How do we evaluate it?
drott: We would support removing it because the semantics are unclear in some cases.
heycam: We would also be fine
with removing it. We haven't heard much demand from
authors.
... In principle it seems like a useful thing, but we would be
fine with removing it.
Rossen_: Any objections to
removing it?
... No objections.
RESOLUTION: Remove font-variant @font-face descriptor from Fonts 3
github: https://github.com/w3c/csswg-drafts/issues/4055
chris: The issue is that you can
pretty much identify individuals based on the set of installed
fonts.
... For example, I have all CSS test fonts installed and some
fonts for languages I don't speak, and that identifies me
uniquely.
<foolip> fantasai, florian, TabAtkins: we're in the #testing meeting debating what your requirements actually are. can we interview you later?
chris: One proposal was to only
report fonts that are the standard fonts for that
platform.
... But this would cause you to re-download fonts you already
have.
... This consumes unnecessary bandwidth.
florian: On some OSes, even the set of default fonts can almost uniquely identify you.
myles: It is impossible for the
spec to describe the set of default fonts.
... The proposal is to say in the spec that browsers must have
some affordances to protect user privacy by having some sort of
(?)
florian: On the performance vs privacy question, I lean towards privacy. On performance vs internationalization, it's less clear: If you don't have the font for a particular language and can't read the text, that's bad.
chris: There is a strong web compat problem here. Things that used to work should not break.
florian: When working means look pretty, there's a trade-off. When it means you cannot read it, it's different.
myles: WebKit has been doing this for over a year. We discard user-installed fonts.
florian: Mongolian without fonts
is unreadable.
... When it is readable, removing the fonts breaks it.
myles: It's a trade-off.
thomas: How did you choose that list of fonts?
myles: I commented on the issue.
<fantasai> It was also pointed out that downloading fonts can cost money in some areas, and this is more likely to be the case in areas which are more likely to use minority languages
thomas: Rather than a bespoce list, could we come up with a list that can be updated periodically? Some list that covers languages for i18n use cases, as well as some fonts that are installed on machines.
<fantasai> and which have less money to spend
iank_: The information about fonts is queriable by measuring the bounds of boxes, without getting the list of fonts from an API.
Rossen_: We will pause the discussion of this issue and unpause it after the break.
<heycam> github: https://github.com/w3c/csswg-drafts/issues/3708
jcraig: For a long time we've had
scalable fonts that are based on the Desktop Web.
... It took us a while to make it work on all extreme
cases.
... We would like to support low vision users who have
extremely large text sizes.
... Forcing such giant font sizes on web pages would make most
web pages unreadable.
... We would like to have a way to opt in to larger font
sizes.
... as an author.
... We would also like to propose a feature that allows web
pages to detect large font sizes and adjust the sizes of other
elements.
... We have some aspects of this that are available today: You
could detect based on min-width in ems, but that does not work
consistently.
... Right now there is no standard way to opt in to this that
works across all browsers.
... Most browsers on mobile systems don't want to break their
users' layout.
... We have examples where it would be very difficult or even
impossible to achieve the intended layouts today.
... [demo]
... I have applied iOS settings that render text extremely
large and bold.
... I can show how different apps deal with this setting.
... Calendar switches to 3 or 2 column layouts.
... The Books app switches from a 2 column layout to a single
column layout.
<fantasai> These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units
<fantasai> or ch units
jcraig: In Mail, with larger font sizes, the title gets clipped but the email's time is preserved.
fantasai: Is the problem that we
can't actually implement media queries with em and ch units
because the web would break, but you want to have media queries
with em and ch units?
... Everything you've demonstrated here is totally possible
with em and ch units in media queries.
... On mobile you're not returning the correct values because
that would break. So what you're saying is you want real
units?
jcraig: What we want is an ability for an author to say "I can handle any font size you throw at me."
florian: How possible is that this signal becomes worthless over time as it gets copied around, and we need to add still another signal?
chris: People are rapidly going to find out that just copying this around will break them.
jcraig: The reason we don't turn
this on by default is that web developers *don't* find out that
it breaks them.
... They haven't turned on these large fonts on their
system.
<chris> fair point, retracted
jcraig: The first part of what we need is the opt in to the higher font sizes. The second part is the media query part.
fantasai: In order to do the kind of layout transformations you want, you also have to know how many letters fit on the screen. You'd use the min-width query.
jcraig: That would get us some of the way.
fantasai: Having just the media query for the font size is not enough if you can't relate it to the size of the viewport.
florian: You can't compare the
font size and the viewport because the lengths have different
units.
... The thing you call an opt in would also opt in the media
queries to behave properly.
... Whichever opt-in we have needs to opt in both to behave how
things were originally intended.
<AmeliaBR> `@media (min-height: 10em)` only works if the window root em size is accurate. So if we don't reveal the accurate preferred em value except in an environment value, you'd need to use `@media (min-height: calc(10*env(user-font-size)) )`
fremy: If you have a user font size variable, you can use calc to obtain the right answer.
fantasai: As an environment
variable, it would work out.
... But Firefox uses different font-sizes for different
languages, so it would be multiple variables, not one
variable.
... The size of ch is dependent on the initial font, not on the
font that is used.
florian: There is a number of
ways you can use environment variables to do what you want, but
if the opt-in mechanism opted in everything, it would also
work.
... Is there reason to exclude media queries from the opt
in?
jcraig: It should not be excluded.
fremy: You want to be able to opt
in only parts of a web site.
... If the developer in the iframe did the work to deal with
large fonts, if it is embedded in another website that does not
handle them, all the work is for nothing.
jcraig: The reverse is also true.
fantasai: If the widget is inheriting the font from the parent document, then it's going to have problems if the parent document picks a larger font, regardless.
fremy: You cannot say media queries behave differently for different parts of the same document.
florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted.
jcraig: It sounds like we're agreeing that it would be useful to have an opt-in for websites to express that they can handle large font sizes.
florian: And we do not agree on
the media query part - depending on how we do the opt-in
switch, that switch may also opt in media queries
automatically.
... If we can't make the existing media queries work, we maybe
need to add more media queries.
jcraig: That sounds reasonable. Once we have an opt-in we can experiment and see in what cases it's not good enough.
AmeliaBR: Having it in CSS would
be better than having it in markup because you can put it into
one shared stylesheet.
... In order to get useful media queries, the opt in has to be
outside of a property.
... If somebody has explicitly set this opt in value, then the
existing font-size keywords that were supposed to be relative
to the user-chosen default font size can actually do
that.
... Otherwise, the default size will be the legacy 16px.
jcraig: I think that sounds ok.
But a new media query would be clearer in terms of what we want
to communicate to authors.
... Without that, the complexity of doing layouts based on
width and layouts based on font-size is going to result in lots
of media query blocks. (?)
Rossen_: We need to work towards a resolution.
plinss: I'm concerned about adding yet another mode switch. Mode switches are bad. Can we do the right thing without a switch?
fantasai: I hate meta tags
because you can't put them in a stylesheet and link them from
everywhere.
... However, it seems to make the most sense to add this as a
meta tag because it affects media queries and the initial
containing block size.
<gsnedders> RRSAgent: make the minutes
fantasai: And once the mode has
been switched, font sizes and everything else can start working
the way initially intended.
... These things all belong together so we should just tack on
a meta tag.
Rossen_: I do not hear agreement
on exact technicalities.
... Let's have a resolution on having a way to opt in, even if
we don't have the exact way of doing it.
... Objections on opting in to true user font sizes?
jcraig: We (Apple) tried to do
this without a mode switch, by default, and all 200 000 apps
broke.
... Even with an opt-in switch, it took years for all first
party apps to support this mode.
fantasai: I don't like mode switches either, but the alternative is to add an entire set of units. A mode switch is a lot simpler.
AmeliaBR: I came in with the same
concerns as plinss, but one thing I did bring up was that, at
the user agent level, there should be reflection of the fact
that there are two cclasses of users.
... Some users want fonts that don't want broken web pages, and
some users want readable fonts even if pages are broken.
... It seems that most users will accept smaller fonts if it
means that pages are not broken.
plinss: I have no concerns with a
user switch. I have concerns with adding a switch to the web
platform.
... If we have to commit the sin again of adding another mode
switch, let's add it in a way that it can fade away in the
future, and not such that content will break if authors don't
anticipate the switch.
... There is real costs to adding mode switches.
myles: The resolution seems to be about intention, not implementation. Let's try to agree on that.
Rossen_: Objections to having the option to have true font sizes?
RESOLUTION: There should be a way to have true font sizes.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Not in April/Not in Spain, in April there will be one/ Succeeded: s/idea/ideal time/ Succeeded: s/Contain Size/content-size/ Succeeded: s/???/cbiesinger/ Succeeded: s/??/element upgrades/ Succeeded: s/addd 'rendersutreeinvisble'/add `rendersubtree="invisible"`/ Succeeded: s/non-/none-/ Succeeded: s/amelia/AmeliaBR/ Succeeded: s/?/SpeechSynthesis/ Succeeded: s/in email/in gmail/ Succeeded: s/Scopes/Skobes/ Succeeded: s/Ian Skobes/Steve Kobes/ FAILED: s/Ian Skobes/Steve Kobes/ Succeeded: s/kanbun/kaiji/ Succeeded: s/kaiji/gaiji/ Succeeded: s/alone/and such/ Succeeded: s/not/smfr: did not/ Succeeded: s/[...]/overflow:hidden/ Succeeded: s/it/doing path() in shape-outside/ Succeeded: s/astearns/AmeliaBR/ Succeeded: s/emilio/TabAtkins/ Succeeded: s/that's not/that's not what/ Succeeded: s/that's what/that's not what/ Succeeded: s/???/stantonm/ Succeeded: s/double-text/double-tap/ Succeeded: s/Florian/fremy/ Succeeded: s/anytone/anyone/ Succeeded: s/we don't care about/we do care about in a test with fuzzy parts/ Succeeded: s/Nigeal/Nigel/ Succeeded: s/isses/issues/ Succeeded: s/to compress/but then beyond that it goes to vertical, not horizontal overflow/ Succeeded: s/but then beyond that it goes to vertical, not horizontal overflow/to compress, but then beyond that it goes to vertical, not horizontal overflow/ Succeeded: s/advanced/against/ Succeeded: s/???: because the fonts/nigel: you're asking a lot of the implementation and reducing authoring flexibility/ Succeeded: s/?/COGA (cognitive)/ Succeeded: s/language specific/typographic mainly/ Succeeded: s/??08/3708/ Succeeded: s/cuse/cues/ Succeeded: s/=true/=false/ Succeeded: s/live environment/live regions/ Succeeded: s/variant/a variant/ Succeeded: s/sighted suers/sighted keyboard users/ Succeeded: s/?/jamesn/ Succeeded: s/spec/issue/ Succeeded: s/???/accessibility section in transforms/ Succeeded: s/UTF/UTR/ Succeeded: s/WG defining/WG that used to define/ Succeeded: s/???/nigel/ Succeeded: s/Kem Russel/Ken Russell/ Succeeded: s/.../in Web Assembly/ Succeeded: s/??/mstage/ Succeeded: s/mstage/mstange/ Succeeded: s/closest non-animated transform/closest animated ancestor transform/ Succeeded: s/astearns/Rossen_ / Succeeded: s/are we ok with (?)/could dbaron suggest new text that describes that & addresses his issues (in time for publication)/ Succeeded: s/2819/2890/ Succeeded: s/No objections. We will move these issues to be tracked under L4./Rossen_: No objections. We will move these issues to be tracked under L4./ Succeeded: s/spec/speak/ Succeeded: s/heycam/thomas/ Succeeded: s/???/jcraig/ Succeeded: s/???/fremy/ Succeeded: s/(?)/Firefox uses different font-sizes for different languages, so/ Succeeded: s/two/true/ Present: Aleks_Totic AmeliaBR Brian_Kardell Florian_Rivoal Fronteers Google Igalia_and_Open_JS_Foundation Invited_Expert Mozilla Nigel_Megitt Rachel_Andrew Rossen_ Simon_Sapin birtles cam cbiesinger chris chrishtr dbaron drott drousso eae emilio futhark iank_ jihye krit leaverou majidvp mattwoodrow mstange myles oriol plinss prushforth skk smfr stantonm tantek xfq_ yigu zcorpan xfq TabAtkins SimonSapin heycam jgraham Léonie (tink) ZoeBijl mck dauwhe_ bkardell_ IanPouncey Irfan achraf aboxhall_ Roy Judy DavidClarke Found ScribeNick: fantasai Found ScribeNick: myles Found ScribeNick: emilio Found ScribeNick: heycam Found ScribeNick: TabAtkins Found ScribeNick: heycam Found ScribeNick: TabAtkins Found ScribeNick: birtles Found ScribeNick: fantasai Found Scribe: nigel Inferring ScribeNick: nigel Found Scribe: fantasai Inferring ScribeNick: fantasai Found ScribeNick: heycam Found ScribeNick: fantasai Found ScribeNick: mstange Scribes: nigel, fantasai ScribeNicks: fantasai, myles, emilio, heycam, TabAtkins, birtles, nigel, mstange WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Sep 2019 People with action items: addison amelia ensure i18n respond tink we WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]