- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 3 Apr 2019 22:16:38 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Easing functions to CR
----------------------
- RESOLVED: Ask to take Easing Functions to CR once these editorial
changes [for Issue #3205] are made.
CSS Environments
----------------
- The proposal to get document title using css env() (Issue #3685)
met with skepticism from the working group. In order to proceed
with this approach the group needed to see more evidence that
this would solve most of the potential use cases either as is or
as an enhancement to the original proposal or that there are
other document properties that would want to have the same
functionality as proposed for document title. Interested parties
will continue to investigate the use cases.
High Contrast Spec
------------------
- Rossen wrote up a proposal to bring the Edge high contrast
behavior into CSS specifications. There was debate on where this
work should go so the group will review it this week and then
decide where this should be put in the official CSS repo.
CSS Text
--------
- When looking into a new property for MathML a larger question was
raised concerning if the stated design of text-transform when
applied to something like a screen reader needed to change in
order to align with current implementations (Issue #3775:
text-transform's design, intent and reality resolution)
- It was questioned if the difference is actually as large as the
issue indicated since the text-transform is not changing the
fundamental structure of the document and cannot be treated as a
core part of the document since some view modes remove the CSS.
- text-transform contains many possible values so there will be a
need to either split this into more than one property or spec
how the properties differ as there are different solutions per
property.
- Other groups will need to be brought into this conversation to
ensure that the decision reached is correct for a wide audience.
CSSAAM was specifically called out at a task force which should
discuss this.
- A possible way forward is to expose detail of transform and
original content at the same time instead of only exposing the
transformed content so that screen readers can make a smarter
decision then they can today.
- Discussion will continue on the issue.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0000.html
Present:
Rossen Atanassov
Amelia Bellamy-Royds
Brian Birtles
Oriol Brufau
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Cameron McCormack
Ian Pouncey
François Remy
Melanie Richards
Florian Rivoal
Alan Stearns
Greg Whitworth
Regrets:
Tab Atkins
David Baron
Scribe: dael
astearns: We should get started
astearns: We will skip item #7 and add Rossen's addition after
item #2
<Rossen> Thank you!
astearns: Anything else people would like to change?
Easing functions to CR
======================
birtles: I don't have anything that needs to be added. Ready to go.
astearns: No more edits?
birtles: Not that I'm aware of
astearns: This isn't the first time to CR so there's not much
besides deciding to
birtles: Good point
<fantasai> only open issue is https://github.com/w3c/csswg-drafts/issues/3205
<fantasai> which is editorial
<fantasai> significantly editorial, but still editorial :)
birtles: That's [the open issue] probably worth doing
fantasai: Worth doing but not block CR. Nothing technically wrong
with document and won't effect impl. Editorial that can be
done during CR. We should signal this spec is done and
people should impl and deploy
astearns: Not concerned with review before this change?
fantasai: This change is about making spec easier to reuse in area
that need timing mapping but aren't animations and
transitions so I don't think that will make a difference
to implementations. I don't think it needs to prevent CR
astearns: birtles what do you think? Change in first or CR update?
birtles: Can I do the change today and get a resolution?
fantasai: Sure. I just didn't want to wait for some indefinite years
AmeliaBR: We're agreeing to change words timing function to easing
function and relating edits? That's all you're changing?
birtles: Yeah and all the descriptions that say these can be applied
to animations to say things like animations
florian: But it's a generalization of sentences, not a deep re-write
birtles: Yep
florian: Then I see no problem resolving before edits
<Rossen> Ship it!
astearns: Objections to Take Easing Functions to CR once these
editorial changes are made?
RESOLVED: Ask to take Easing Functions to CR once these editorial
changes are made
astearns: Thanks birtles to getting to those edits
CSS Environments
================
Getting access to the document title
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3685
astearns: This was introduced last week, discussion of scope and
that it's not useful in all situations. What else did you
want on this florian?
florian: Not much to add, just cut by clock. I think it would be
useful to be able to access doc title from env. tantek
pointed out this is not powerful enough for general problem
florian: The generic solution pretty much calls for regions, though.
This is much simpler and solves some cases so I think it's
good to do. I recognize it's not a full solution
AmeliaBR: One thing is that CSS has a mechanism for what florian
wants in GCPM module. That is a much more complex and
nuanced system of pulling bits of text from a heading and
reusing in other parts of layout.
AmeliaBR: I don't know if there's any interest in getting that
cleaned and into browsers or if we want the quick win
florian: I think we should do this regardless. Other is slightly
more powerful, but it's still plaintext only and only works
in paged margin boxes so if you don't paginate you get
nothing. So this is less expressive but more applicable and
simpler
florian: I was discussing in context of Viviostyle and there were
cases to not invoke the whole complex process, just I want
the title and put it there.
florian: I don't think I wouldn't be pushing if we didn't have nth
function. We have the mechanism so this is exposing a value
through it
Rossen: Main motivation is in paginated scenarios?
florian: Commonly seen in paginated but this doesn't have to be
restricted. With nth works everywhere. If you want
something pagination-like you can invoke things like this
Rossen: Just curious use cases
florian: Same type of layout as paginated media but actual
pagination with css level of page is one thing, but
something that visually looks like pages is another. I'm
aware of wanting to do things that look page-like is a use
case
fantasai: Concern is this is too simple for what's wanted. If we go
in this direction we'll be too limited. Don't know how
urgent this is. If it's not something we have to do really
soon might be worth trying to sort out more generic that
solves this class of problems rather then special casing
this
<bkardell> it seems like we have maybe a lot of things that are
almost related to this
florian: Don't think particularly urgent. In that sense okay with
punting. More generic is way more complicated. I don't see
this as trying to solve whole problem. If want to expose
more through nth it seems reasonable.
fantasai: If it would solve 80% use cases it's worth, but seems
closer to 20% so I don't know it's worth introducing a new
pattern if we're not planning to pursue patterns
florian: I think for ebook this would solve most of the problems.
Depends on how you say 100%
fantasai: But they also want page number and chapter
florian: But in ebooks, chapters are HTML files, so, it is
sufficient for that case. It is simple
bkardell: I'm interested in this use case. I feel like I would like
to talk to florian a bit to understand more off call. If
it only can give you the plain text would you not be able
to achieve most by setting a custom prop for now? I think
we said it's just plain text so the 20% of use cases
wouldn't they be served equally as well with a css custom
property?
astearns: It's content duplication and you run the risk of out of
sync. This is slightly better then duplicating in custom
properties
florian: ebook with 25 chapters if you use nth you pull from doc,
custom prop you have it for each chapter
bkardell: That's what I'd like to understand more. They're not input
manually, they're built.
bkardell: Would mean multiple rules
astearns: Prob enough for now. Not hearing enough to pursue for now.
Maybe if we saw use of custom properties for this could
make better solution
florian: I'm hearing sufficient skepticism we're punting
AmeliaBR: florian worth looking if there are similar doc properties
where worth a common mechanism. Doc URL or parts of URL
might be similarly useful. Have permalink on a file. I
haven't looked and it's a matter of looking at what people
are actually using to insert into the generated content
florian: We can think of a few more, but that's enough for the topic
today. We can go offline
High contrast spec
==================
link: http://htmlpreview.github.io/?https://github.com/atanassov/css-high-contrast/blob/master/Overview.html
Rossen: I don't have a github issue for this
Rossen: I had an action after the F2F to go and put what we had in
an explainer and add more spec text to introduce high
contrast feature as is defined and working inside of edge
and IE
Rossen: The pretty print of the HTML is linked above
Rossen: Request is to move this out of my github and into CSSWG repo
as one venue or pursuing this. Or identify parts of spec
that will go to currently worked on specs. I can see a MQ go
to MQ spec, cascade going to cascade. That's what I wanted
to get from WG and figure out next steps
Rossen: Not sure if anyone had a chance to review, it's fairly short
fantasai: I haven't but TabAtkins and I plan to tomorrow. I can get
review by next week
Rossen: Sounds great. I just want to take it out of private repo and
get it into CSS
Rossen: I'm okay breaking this apart into appropriate specs or keep
as one until it solidifies more and then break. Either is
okay
fantasai: Ultimately want all MQ to go int MQ5. High contrast props
should go together, don't know spec
<fantasai> there was a printer color adjust control as well that
should go together with this
Rossen: This is something...this is why I wanted to keep it as one
spec to begin so it brings whole picture together in terms
of what the high contrast feature does. Once this is better
understood we can break apart into appropriate modules
florian: Depends how many we want to break into. Mostly together
makes sense. I'm interested in splitting MQ early because
the whole thing is interaction between that MQ and others
in that domain. I'd hate to go too far and it doesn't mesh
Rossen: You suggesting break MQ out now and add to MQ5?
florian: And the rest in the stand alone ED and work on that
AmeliaBR: Looking at Rossen's draft there isn't a lot of the rest.
Any problem with all into MQ5 for now and maybe we find a
better place for the extra property later?
Rossen: Not opposed
fantasai: Makes sense. Not stay indefinitely but for current state
of discussion makes sense to have a section that deals
with color adjust stuff
florian: Rossen do you want to be a coeditor of MQ5?
Rossen: Sure
astearns: Do we want to resolve to add this to MQ5 now or give a
week for review?
<fantasai> MQ is re-used outside of CSS, so definitely shouldn't
stay there :) But fine to be there for a few months while
we figure out where things should go
<heycam> +1 to move it all into MQ5 for now
Rossen: Comfortable with either. If people feel this is better in
MQ5 and this is where we're going to go let's just go. We
can always make changes
fremy: Agree with Rossen. We can start to files issues against it
which is better then filing issues when it's not official. If
we all agree it's in MQ5 let's agree on it
fantasai: I'd say wait a week. I can do a review and maybe we have
clearer idea of what we want to assign
fremy: I have issues I'd like to file but I don't know where
fantasai: We do have a single repo so you can file and tag later
Rossen: If it's okay with WG I cam move spec as-is right now knowing
it's unofficial into CSS Repo. I'm attending blink-con next
week during call so I'm not going to be present. I would be
happier if people started shooting issues into a repo and
tag against spec
florian: Okay with that
astearns: I'd rather not put it in repo as-is if going to put it
into MQ. Rather open issues on repo and tag later. Just @
Rossen and melanierichards
<AmeliaBR> We also have another proposal for a "media-query
adjacent" CSS property in `supported-color-schemes`,
which should probably go in the same place as this
high-contrast override property.
florian: There's 2 parts in this to me. MQ and high-contrast-adjust.
high-contrast-adjust is a pattern I think we'll see so it
belongs. The new cascading border doesn't belong. It's got
the backdrop in there?
Rossen: It's not there. It's not currently expressed as a reachable
entity through style layer. If you recall the discussion I
did point out to be successful for impl. There was some
interest this could apply to things like captions. In event
that we believe this new feature should surface on CSS layer
I can add the spec text. For now not exposed because can't
be reached by author
florian: That part just doesn't feel like it should be in MQ
Rossen: Agree, totally different. Maybe it's B&B if anything
astearns: Let's keep in Rossen's repo for now. Please review doc and
open issues on our repo and we'll descide after a bit of
review what we'll do
CSS Text
========
text-transform's design, intent and reality resolution
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3775
astearns: Wanted to have this introduced so can make a bit of
progress before bringing in more people
bkardell: I don't see where this was spec originally in the design,
but at some point it became a stated thing we have talked
about about the intent of text-transform and what it
exposes to screen readers and why
bkardell: Feel like I dropped the ball a bit on kana discussions
because I know it wasn't reality and assumed other people
did too. Some of the text stuff I don't feel I can comment
so wasn't paying close attention
bkardell: Opened a different issue requesting something that is
inline with how screen readers work. That changes to how
we have designed to not expose text to screen readers.
It's come up that it does not match reality
bkardell: AT and browsers have chosen universally to expose
transform text. I'd like to consider that so that we can
properly discuss the other issue
bkardell: My position is that the ones that exist and in wide use
are stated design principle is out of touch with reality.
It's a conscious choice that's what users want. At a
minimum our principle needs some finesse
florian: The discussion is a bit long winded, I'll jump to where we
are. I don't see the same contradiction as bkardell if we
look a little deeper. Don't think it's interesting to
debate what screen reader users what, the experts have
said. Screen readers do not give access to raw doc, they
present it. It's easier to include the transform. I don't
think that makes semantics change
florian: I don't think we could do that. There are places where we
don't present CSS so we can't say that text-transforms are
an intrinsic part of doc that can't be removed. If screen
readers as one UA think best way to present is to apply the
text-transform, great. But I don't think we can go from
there to never not allow them to be applied. If you
introduce a new text-transform old browsers won't know
florian: I think we have to recognize that the doc is the doc and
the text-transforms need to be allowed to apply. I think
the claim that case transforms are desirable is credible,
but I don't want to generalize to say all transforms always
must be preserved. I think cjk and i18n transforms you want
the other way.
florian: I think we need to discuss transform by transforms, but
can't say all must be preserved
fantasai: I agree with florian that text-transform can't be
intrinsic part of doc semantics. They were designed as a
way to have this distinction partly. If we don't have them
to different doc and visual rendering we'll have to find a
way to do it.
fantasai: Someone suggested creating a custom font, I don't want to
get into that arms race
fantasai: I'm not sure how deeply this was investigated in the past.
I don't see anything in bugzilla. Chrome issues had people
arguing on both sides. I don't know if this has been
investigated deeply enough. We need to talk to the people
we need to talk to and figure out what to do. It's
possible the current situation is what fell out of
original implementations, and screen readers just dealt
with it but it's not ideal. If no discussion on Gecko it's
probably what's convenient
IanPouncey: Few points, to reiterate bkardell's point it seemed to
those of us who work with screen readers that this was
common knowledge, that's on us. For what florian said I
think misconception about where problem lies. It's not
screen readers doing transform, it's the browser and
a11y tree exposing it
IanPouncey: It's not screen reader doing anything in most modern
browsers. Any of the ideas of a screen reader making a
decision about what to present is problematic because
you cannot reverse a transform to uppercase because you
don't know what char were uppercase
IanPouncey: Speculating on this, I wonder if there's a similar issue
for content on the radar. I think there was an
assumption when property introduced that it's not
exposed to screen readers and it is now. I wonder if
there's a similar problem there
<fantasai> Point about delivering transformed text through AT
meaning screenreaders can't access original text even if
they want to is imho important
Rossen: Way screen readers work is a long discussion. How text is
represented also heavily depends on current platform support
and AT consuming that information. nvbia on windows will
have different characteristics to express richness of text
compared to narrator using ui automation
Rossen: One thing I know from interacting with the community and
a11y wgs and impl a11y the thing I can tell you is a lot of
people think of screen readers for the blind. It's part of
the users but not all. Most people are those with low
vision. They can see parts of the screen. So when you start
producing disparity between rendered results and what screen
reader represents it becomes confusing
Rossen: Consider editing scenarios- most people will navigate text
by character to check spelling. If at that time you have
text-transform that caps for example for them to not know
it's upper case will be confusing. Same reason why we map
ital to em, lots of font features that map to a11y prop I
don't see why this should be unique
Rossen: Other thing I want to give a big shout out, CSSAAM would be
ideal place to continue this discussion
<fantasai> wrt checking spelling in editing environment... ideally
you want to know what text you're actually typing, for
when the text-transform goes away -- source text should
be following standard capitalization rules, would be
problematic if ::first-line { text-transform: uppercase;}
led someone to type in all-caps when replacing one word
with another in the first phrase of a para
<fantasai> generally, editing text with text-transform turned on is
going to be very confusing regardless...
AmeliaBR: There's 2 aspects to the discussion. What should happen,
how is best way to expose full information. Then specific
practical issue in that we have recently added values of
text-transform with some impl and this new prop for math
variants
AmeliaBR: By putting it all in text-transform it forces us to treat
them the same for exposing before or after transform values
AmeliaBR: Even if not complete agree on optimal for exposing case
changes I'm trusting florian that exposing CJK
typographical is a problematic situation from a11y.
AmeliaBR: If mathML comes through it's very important to expose
transformation.
AmeliaBR: With these different semantic impacts it might be worth
discussing if these should be split up, even if it's
transform to long hands that could all reset by a
shorthand but there is a text-transform case that's
different then CJK text-transform. If we separate to
different properties we can start talking semantics and
what strange transformations happen
AmeliaBR: Especially in terms of what's exposed to a11y, innerText,
copy/paste APIs, lots of places where people use
text-transform and if they're not all equal maybe use
different properties
<fantasai> reason to have separate longhands is needing them to
cascade separately... if the only concern is what impacts
they have, we can categorize within the spec
florian: I am aware about difference IanPouncey mentioned between
what screen readers do and what's in at. Idea is that text
in AT would be end transformed text and have the original
information so screen readers can make decision. In case of
case transforms if every screen reader wants to do the same
thing with it and the current AT does the transform already
it will be uphill to un-transform. For case transforms if
it's a standard today fine let's leave it
florian: But that's what I want to Japanese which is keep
untransformed text and keep information about transforms so
that screen readers can add extra information if they want.
The Math case I think is kind of related. I don't think we
can rely on the transforms to change document semantics.
florian: If we want to introduce a new semantic differences we have
to introduce it in the document and that can impact the AT
tree. We can't just change the font and claim it lets us
introduce semantic differences that would change the
meaning of the document. Upper case is useful but not
changing doc meanings. If we want to introduce math it will
fail in all cases
astearns: To respond to AmeliaBR- I think the idea of separating
properties is interesting but maybe not entirely
necessary. If we want we can spec what happens to values
or properties and they can differ.
astearns: To respond to florian I think there is prob a fallback
that can work for new math transforms. If you see support
you get fractor, if you don't you do extra styling
florian: And it disappears in reader modes
astearns: Fair
florian: If you want to style that's fine. Introducing fundamentally
different semantics won't work.
IanPouncey: Cautious +1 to expose detail of transform and original
content. I can see if there's any appetite for that.
Hopefully we can get idea if that's possible. Also
acknowledging the prompt to add CSSAAM to this discussion
AmeliaBR: Follow up on florian's concern about semantics in
document. The request for math transforms is from MathML
as a way to describe behavior of MathML attribute in a way
that can be consistently impl. That is something where
there is semantics in doc level but nice to be able to
describe it. Maybe also use same effects in more
decorative cases
florian: Fair and useful so thing into a11y tree is the transformed
and may be useful
astearns: We're at time. The call bridge will stay open if people
want to chat and then put the discussion in the issue
astearns: Thank you all very much
Received on Thursday, 4 April 2019 02:17:33 UTC