- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Apr 2015 05:14:17 -0400
- To: www-style@w3.org
Loading Fonts and Changes in Status
-----------------------------------
- There was disagreement as to if the specific order of state
changes is needed to prevent bugs or if it's an unnecessary
step that slows performance.
- TabAtkins will gather more cases and the e-mails that lead him
to make the language more strict in order to further the
conversation.
Media Queries
-------------
- RESOLVED: Change the appropriate sentence in MQ to "User agents
must re-evaluate <a>media queries</a> in response to
changes in the user environment that they're aware
of"
Font Loading Control
--------------------
- RESOLVED: Remove the timeout portions from the proposed font
loading control spec.
- RESOLVED: Move Font Loading Control to the Font Loading spec.
Cursor Image Formats
--------------------
- RESOLVED: We are recommending informatively .cur support.
Normatively must support PNG and SVG and saying should
support animated formats too.
text-combine-upright (TCY) on ::marker
--------------------------------------
- RESOLVED: Accept fantasai's proposal to add text-combine-upright
to ::marker.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Sanja Bonic
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
John Daggett
Elika Etemad
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Toru Kawakubo
Brad Kemper
Chris Lilley
Peter Linss
Edward O'Connor
Florian Rivoal
Simon Sapin
Alan Stearns
Greg Whitworth
Johannes Wilm
Steve Zilles
Regrets:
Simon Fraser
Michael Miller
Simon Pieters
Anton Prowse
Mike Sherov
Lea Verou
Scribe: dael
glazou: Let's start.
glazou: Any extra items?
jdaggett: The font rendering proposal is something I'd like to
discuss.
glazou: We'll put that after item #1 since you're far away and
time zones.
jdaggett: We can hold off until TabAtkins is on the call.
glazou: No problem. Anything else?
Loading Fonts and Changes in Status
-----------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0536.html
jdaggett: We should wait for TabAtkins.
TabAtkins: Let's do this.
jdaggett: The first item is, basically, the way the CSS Font
Loading spec is written it sort of requires certain
state changes to occur in a certain order.
TabAtkins: Yes.
jdaggett: It seems that's unnecessary.
TabAtkins: We want to ensure state changes happen in a specific
order. Otherwise people get bugs.
jdaggett: The ordering is fine. If there's a guarantee at a
certain point we should be careful. In this case a font
could end up being loaded trivially.
TabAtkins: Yeah. Let me link the e-mail. In these examples in the
e-mail I think they're Chrome bugs. We shouldn't have
behavior depending on implementation concerns. People
depend on sync behavior in one browser and it doesn't
work in another.
<tantek> TabAtkins++ depending on implementation details of
async/sync is a huge recipe for bugs
jdaggett: You're forcing slow.
TabAtkins: Forcing consistent.
jdaggett: Consistent but slower.
TabAtkins: Yes. I am requiring that because it's required for
several cases. It's not obvious to me which should be
sync. I don't think we should have an API that
sometimes makes sync changes and sometimes makes async.
jdaggett: I think when we implemented this in Gecko you have to
introduce artificial states where you can load this and
it's in a cache, whatever the reason is you end up
having to put it into an extra state and spin the event
loop and then set up something where it comes out at the
next spin so you're doing the right thing.
jdaggett: It seems like a lot of additional that's not that
necessary.
TabAtkins: I think having an API that can do sync or async
depending, I think that's bad for browsers. They have
to do odd things for some cases anyway. It requires you
to say even though we're capable of doing it fast,
we're going to wait for the next event loop.
jdaggett: Maybe we need to hear back from the Chrome implementors
because for us it creates artificial states.
TabAtkins: That's, yes, if you do a URL and sometimes it's sync
and sometimes async because sometimes it got loaded
somewhere else, that will be a source of bugs for
authors. This kind of unpredictably is always a problem.
TabAtkins: It might happen because they've loaded in their test
environment, but once you're public it won't be loaded
yet.
jdaggett: I think it's an artificial simplification of something
that's already complex. I don't think you're introducing
bugs when you say if it's simple if can change.
Introducing artificial boundaries...this thing happens,
then this etc. in all cases, you end up with sync cycles
that aren't great for authors.
TabAtkins: But doing anything else creates unpredictability. I'm
going to object that to something that allows sync or
async.
jdaggett: Talking this over with Cameron, this doesn't make sense,
but we need to talk to others. There's two
implementations that feel like the right way, but the
spec says something else.
TabAtkins: I think that might be because I set status to loading
and that's really bad. It might be we're taking
advantage of that at the time of implementation, but
we're being stricter because of feedback that I should
be strict in async.
jdaggett: It would help if you can post the downsides of changing
this? I think examples of bad would be helpful.
TabAtkins: And I can link back to the e-mails that caused me to
change the text.
dbaron: Also, when there's a callback there's a risk of authors
expecting async and having that be a problem when it syncs.
TabAtkins: Anything that keys off will be promise based. I'm
worrying that authors will expect it to change sync-ly
and it not changing sync-ly in other cases.
glazou: So TabAtkins you'll accept an action to provide more
information?
jdaggett: And it might be useful to hear from other members of the
Chrome team.
ACTION TabAtkins to provide more info to jdaggett
<trackbot> Created ACTION-679
Media Queries
-------------
glazou: So back to Microsoft. I think, gregwhitworth, you posted?
gregwhitworth: I expressed our desire for it to be 'should' for
the pointer. I read Florian's feedback and I still
think it should be a 'should'. Especially for the
future because we don't know about MQ down the road.
gregwhitworth: I've laid it out in the e-mails so I don't know if
you want to talk about this on the call.
Florian: I'm not sure if it's on the call, but I don't understand
your point. When it comes to future-proofing I think
that's erroneous. If we find something that should be
'should', we can change that. I don't think we should
take future needs as a reason to not have it strict.
Florian: As to pointers, If you disagree with my example I'd like
to understand what I'm missing.
gregwhitworth: Your scenario where we have a continuum model. The
surface where 90% of the time they're using in a
touch format. Then they take it to work and dock it
they have a mouse. So what you're saying the
primary is touch, but now it's mouse. So that's why
I think it should be a 'should'.
TabAtkins: That seems irrelevant.
Florian: So you're saying you don't think the primary pointer has
changed. So you don't change it. But if it has changed,
let the author know.
TabAtkins: I don't see why if you think the pointer has changed
you shouldn't change it.
gregwhitworth: So I don't see why the OS...
TabAtkins: Then you don't know it's changed. This is saying if you
know the value has changed, let the browser know and
that you must do that.
Florian: So whatever happens in the environment causes it to
change, then the browser should match. And I think it's
straight forward for Windows because you have that in the
OS.
gregwhitworth: For example we have plug and play on the OS so we
know when something changes. But with a device that
doesn't have plug and play that's not possible.
gregwhitworth: If we have a device that doesn't have the
capability, I'm questioning if we're talking about
a must or the end author. They're going to think I
said pointer is fine and they must reevaluate,
they're not going to take that browsers will change.
Florian: But if you have a device that's not plug and play it
wouldn't be primary.
TabAtkins: Would it help if we add "that they're aware of"
<ChrisL> +1
gregwhitworth: That feels like a 'should'.
Florian: What we want to avoid is UA knowing and not changing.
dbaron: If you want exceptions for certain MQ characteristics, we
should make those exceptions for just those. Don't weaken
the spec for things like width.
<fantasai> dbaron++
<Florian> +1 to dbaron
gregwhitworth: That's what I said in my e-mail. If we take MQ at a
granular level and things where there's
interoperability make it a 'must'. But I think for
pointer...TabAtkins, I think it's a good idea to
add that. But I'd rather get more granular. So
these 5 are 'must' and this one is 'should'.
<ChrisL> let's go for the more granular and the "that they are
aware of"
Florian: So when a browser knows about the luminosity MQ, but the
device doesn't actually have a light sensor... no author
will expect it to change if the UA can not know about the
change in the environment. I think we can add the
phrasing, but I don't think it's significant. The other
changes go under deciding what is the primary device.
Florian: I'm okay with granular, but I'd want 'must' on everything
we have.
gregwhitworth: What's the point of granular then?
Florian: Well, exactly.
gregwhitworth: So we're at an impasse. I understand your point,
but if I'm Photoshop and I have a UI for touch and
one for website and have it where if you have a
pointer fine, they plug in the mouse and expect the
UA to adjust they should expect that. Then I see
that pop up and expect the mouse, but the UA thinks
the most used is touch.
TabAtkins: You're still talking about the definition of the
pointer MQ, not if you know it's changed. Let's not
talk about if it should change. I haven't heard
arguments for if the browser knows the MQ has changed
it should change. I haven't heard any reason not to
change to a 'must'.
TabAtkins: I'm okay with the one change to make it clearer that it
only expects to change things when it knows about it.
I'm fine with that.
gregwhitworth: Ultimately I'm fine with it being a must as long as
it's stated for authors to be aware of. I did get
hung up on the definition of a pointer, but that's
the one we worried about.
TabAtkins: Okay, I'm making the change now.
<TabAtkins> proposed resolution: Change the appropriate sentence
in MQ to "User agents must re-evaluate <a>media queries
</a> in response to changes in the user environment
that they're aware of,"
* fantasai suggests putting "that they're aware of" in parens
* Florian fantasai: not sure it matters, why would you want
parens?
glazou: gregwhitworth are you okay with that?
gregwhitworth: Yes.
glazou: Objections?
RESOLVED: Change the appropriate sentence in MQ to "User agents
must re-evaluate <a>media queries</a> in response to
changes in the user environment that they're aware of,"
Font Loading Control
--------------------
<jdaggett> http://tabatkins.github.io/specs/css-font-rendering/
jdaggett: Back in March TabAtkins put together a better version of
the old proposals for what's being called the font
rendering property but it's more like a font load
control property. It's giving the author control over
the intermediate presentation when downloadable fonts
are used. Different browsers have different behaviors
around what's displayed when the pages loads and the
font is available.
jdaggett: Some display nothing, some do a fallback, for Chrome and
FF they do a bit of both. Nothing at first, fallback if
it takes too long. IE always does fallback, Safari will
always show a blank page until the font loads.
jdaggett: The proposal is for a property that lets you set the
timeout. I don't think this is a great idea. I'm not
sure what the right way to put a handle on this, but I
think the idea of a low-level timeout is a bad thing to
give to an author.
jdaggett: It's going to be variable, what you give them. The way
fonts are downloaded is via the content of the page and
when exactly that mode starts will vary from
implementation to implementation and how long it takes
will depend on what else is loading at the same time. So
a 2 sec timeout you set may have no relation to the same
timeout on another browser.
jdaggett: I also don't feel like authors should be able to say I
never want to show content until this font loads. I
think that's poor design. A lot of people complain about
where you're looking at a page and the content has
loaded, but you won't see anything.
glazou: I received a lot of complaints asking if it's a CSS
problem.
jdaggett: I can see that it's reasonable to say let's have a hint
like this font is important and load it first, but
explicit timeouts isn't interoperable.
Florian: I'm not entirely sure the current design is right, but
having the property is a good idea. Both users and
authors have preferences, but there are disagreements as
to if you should have fallback or just wait, so this is
something where people like the control.
Florian: If this should be expressed in terms of timeout, I have
less of an opinion, but having a way for authors and
users to switch between behaviors is something I'm in
favor of.
jdaggett: User and author wants can be conflicting.
jdaggett: It's primarily a mobile problem, so there's no user
stylesheet.
dbaron: I don't htink it's a problem of lousy UAs, I think we want
to find a solution for all users, not the small number of
users that can edit their stylesheet.
<dbaron> ... or go in to the preferences ui
<glazou> dbaron++
TabAtkins: The big issue is most browsers do the block for a
couple seconds and then show the fallback. The fact
that it's uncontrollable is what I'm trying to address.
The point is to let authors control if you swap in at
some point. So discussion on allowing people to block
seems backwards because today everyone blocks. So
unless we're saying UAs can't ever block, saying we
don't want to let authors control blocking isn't
relevant.
jdaggett: But people are fiddling around to finagle around that.
TabAtkins: I don't want hacks around to be a fix for a thing. This
property might not be ideal, but I'm trying to make the
crazy hacks not be necessary.
<Florian> Totally agree with Tab
glazou: Most people that complained about Safari don't know what
local storage is. This kind of work around, they just
don't know.
jdaggett: I'm fine with wording saying don't do what Safari is
doing, but I do think the way the property is structured
with explicit timeouts, you allow authors to say never
display until it's pure. That's a problem for someone
that makes a UA. I want to be able to give the users
something they want so I don't think respecting a
forever timeout is good.
glazou: You're trying to move the responsibility for showing
things to the UA. This will be self-controlled; users will
go away if it's mis-used.
TabAtkins: I do think it's bad if people are doing heavy blocking
and I'd be okay with allowing UA to have a max timeout.
That could be user controlled or set as a default.
jdaggett: This may seem orthogonal but I think it's important to
put in hints to initiate to load ASAP because that's the
underlying reason.
TabAtkins: It is orthogonal. If you're using the font right away
you still have to deal with the download times. That
still needs to be controlled.
jdaggett: The reason you get that is the font load is initiated
late. If you have something initiate the font load
you're less likely to get the behavior.
TabAtkins: I can get the font information in the first network
packet and still have to wait the few seconds due to UA
behavior. This is to let that be fixed and have better
rendering.
Florian: There's 3 useful values. Auto is the browser does
whatever it wants to do. Another is show it immediately
even if you don't have the font and refresh when you get
it. The third is show the content immediately and don't
refresh when you get the font, but still initiate the
download, so you can use it next time you reload. If
it's useful to be able to set explicit times I'm not
convinced of, but being able to say show immediately
is important.
<fantasai> Florian++
jdaggett: I'd have less problem with that.
TabAtkins: Those are the three planned values. If we want to allow
the explicit timeouts on the keywords, we can do that
later.
jdaggett: The keywords are different. The property is much finer
grained.
TabAtkins: No.
TabAtkins: They are they same three keywords.
<tantek> do we have any examples of *good* behavior with non-
blocking webfont loading?
Florian: I think those three are sufficient. What jdaggett objects
to is the timeout.
glazou: This is only a draft. We can keep stuff people disagree
with and it will be eventually removed if we don't get the
2 implementations.
dbaron: I don't think that's a reason to put things in we don't
want.
glazou: So we have two options. Keep stuff and remove later or if
we have a compromise, get rid of it.
fantasai: I think if we don't agree on something and we don't have
a clear path of working on it towards consensus it
should be dropped and keep what we have consensus on.
Florian: I think the property is important and I would suggest
removing the parts jdaggett objects to and putting them
back later.
TabAtkins: I'm okay with moving them from the main spec and
discussing it later.
glazou: So the parts of having a duration?
jdaggett: It's the timeout aspect of it.
glazou: So are there objections to removing the timeout portions
from the font loading?
<ChrisL> yes
<fantasai> fantasai: I agree with John, I'm in favor of dropping
timeout and keeping the rest
RESOLVED: Remove the timeout portions from the proposed font
loading control spec.
TabAtkins: So can I put it as an ED?
<astearns> +1 to publish as a font loading spec
jdaggett: We can, but we need to have an issue that it needs
another name.
<ChrisL> yeah the name is poor
glazou: Okay, so we need to change the name and we need a short
name.
fantasai: Font Loading
TabAtkins: We have it. The Font Loading API
<ChrisL> font-loading-declarative
glazou: font loading control
<astearns> font loading level 2?
<BradK> Font-not-loading
jdaggett: font loading control isn't bad.
<ChrisL> font-ld
glazou: Okay. Font Loading Control. Done.
<fantasai> Can we just add it to the font loading module???
* fantasai thinks font-loading property should either be in
css-font-loading or css-fonts
* fantasai thought we had an outstanding action to create Fonts
Level 4??
* fantasai jdaggett ^
<jdaggett> fantasai: yes, back in the oct f2f i asked permission
to start one
<fantasai> jdaggett, Could we put font-loading in that?
<fantasai> I feel like having a pile of one-property specs isn't
really helpful to people trying to find things and
understand how they fit together
<jdaggett> fantasai: i think font loading spec would be better
<fantasai> :)
<fantasai> jdaggett: http://www.w3.org/TR/css-font-loading/ ?
<jdaggett> yes
<fantasai> That works for me, too
<jdaggett> fantasai: font loading is more about the font loading
algorithm, since script is involved
* fantasai nods
<jdaggett> so having a property in there isn't bad
<fantasai> I'm okay with either
Cursor Image Formats
--------------------
Florian: So there were two different issues on this.
Rossen: The first issue, like gregwhitworth pointed out, we're
still waiting. On the technical side as to if we can
support other image formats, we should be able to. If
we'll do it is a different question. Technically there are
no limitations.
Rossen: Obviously if other browsers support the different cursor
formats, there's nothing holding us back.
Rossen: It has to be differentiated in impl follow-up. But we
should be able to support it.
ChrisL: If it helps I made some tests. It was one test for each
format that was proposed. That's sitting there.
Rossen: Sorry, you were breaking up, were you asking if we should
review all the different formats?
ChrisL: No, I'm saying I've got some tests that lets us see what
browsers support it. I've also got tests for PNG.
Rossen: So the low-level cursor API supports a bitmap and an alpha
channel map. Anything can become a bitmap and then used as
a cursor. Besides performance I don't think there will be
technical reasons. This is about the can we, we can, there
are no implementations promises.
<tantek> I'd like to move forward with: Informative note that
browsers support .cur, and Normative must requirement of
PNG / SVG
<ChrisL> plus one to what tantek just typed
Florian: tantek I agree with your point. [reads from IRC]
glazou: That was the original proposal.
Florian: It went a bit further. It was you must support anything
you do through the image value type.
glazou: Anyway, the proposal is an informative note about support
for .cur and normative for PNG/SVG
tantek: More than that.
Florian: There was a should where if you support something
animated you should support it in the cursor as well.
<ChrisL> yes, should is appropriate for animated at this time
glazou: So opinions and objections please?
tantek: This is one of the two outstanding issues on CSS3 UI so
I'd really like it resolved.
<ChrisL> (no objections)
glazou: There seems to be consensus.
Rossen: I wouldn't object to this. I'm not sure about the animated
part.
Florian: That's why it is 'should'. And IE supports animated. It
does it though .ani
Rossen: Yes. The usefulness if questionable.
fantasai: Recommend or require?
Florian: Recommend.
fantasai: I'm okay with that,
tantek: So Microsoft, any objections?
Rossen: No.
RESOLVED: We are recommending informatively .cur support.
Normatively must support PNG and SVG and saying should
support animated formats too.
Florian: And the <image> will normatively require SVG and PNG
glazou: Okay.
<tantek> RESOLVED: Informative note about browsers .cur support.
Normatively MUST support PNG, SVG, and any other static
<image> formats your UA supports elsewhere. SHOULD
support any other animated <image> formats your UA
supports elsewhere.
<tantek> ^^^ all, please double-check that resolution.
<tantek> the details are important
<ChrisL> tantek yes that is what we agreed
<tantek> Thanks ChrisL, I wanted to get the exact thing in the
minutes.
<Florian> tantek: Almost. change second sentence to: Normatively
require any supported static <image> formats, and
normatively required that <image> supports at least PNG
and static secure SVG.
<tantek> what is static secure SVG?
<Florian> (this makes no difference to cursor, but it makes PNG
and SVG mandatory for <images> in general as well)
<Florian> tantek: https://svgwg.org/specs/integration/#secure-static-mode
<tantek> svgwg.org?!?
<tantek> ok I'll find a normative w3.org ref
Font Loading Control
--------------------
fantasai: jdaggett and I were discussing the font loading and
we're suggesting it moves to the font loading spec
instead of being on it's own. Is that okay?
fantasai: It would be nice to have it with the font loading API.
glazou: Objections?
RESOLVED: Move Font Loading Control to the Font Loading spec.
text-combine-upright (TCY) on ::marker
--------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0043.html
fantasai: It's a text level property and I was suggesting we
include it in ::marker because that's common and not a
layout thing.
fantasai: So it should be okay to add and we can mark as at risk,
but it's an important use case.
Rossen: Is this level 3?
<jdaggett> really?!? hmmm
fantasai: pseudo-elements level 3 for ::marker
glazou: What do you think?
Rossen: I don't have an objection. You mentioned it's common?
fantasai: It's for when you have upright and vertical text. I
don't have an example off the top of my head. Let me see
if I have any scans I can find quickly.
<jdaggett> i'm skeptical that TCY is used in ::marker
<dbaron> koji asked if writing-mode is ignored in ::marker
fantasai: Right now ::marker doesn't accept writing mode or any
other layout.
koji: Having the numbers in writing mode is often used. So I
question if it's common.
Rossen: It's fine as long as there's a good use case for it.
Rossen: Would also that apply to content?
fantasai: It already does.
Rossen: Okay, then I believe ::marker should be the same.
glazou: Is there any objections against fantasai proposal?
jdaggett: I'm skeptical, but if there's an example to demonstrate
it's useful, okay.
fantasai: Any case where the entire number is a single unit.
fantasai: There's a lot of cases where twelve is written 1 2 with
both upright.
Rossen: I'm fine with adding this as at risk and then moving on.
glazou: Objections?
RESOLVED: Accept fantasai proposal to add text-combine-upright to
::marker
glazou: It's the top of the hour. Thank you very much and talk to
you next week.
Received on Thursday, 9 April 2015 09:14:51 UTC