- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 14 Sep 2015 13:59:00 -0400
- To: www-style@w3.org
- Cc: public-fx@w3.org
FXTF Meeting (part 2)
=====================
glyph-orientation
-----------------
- RESOLVED: Drop glyph-orientation-vertical values 270 and 180.
Drop glyph-orientation-horizontal entirely.
Drop text-orientation: use-glyph-orientation value.
Treat glyph-orientation 0, auto, and 90 as aliases
of the corresponding values of text-orientation.
writing-mode Values from SVG 1.1
--------------------------------
- Add RFC2119 optional wording to svg writing-modes keywords.
getTransformToElement
---------------------
- The group felt this needs to be defined better.
Path Animation
--------------
- It was agreed that Shapes level 2 should add motion path so that
it's all defined in the same places.
Zoom Features for Media Queries
-------------------------------
- KDDI presented a proposal for a zoom features property to be
added to media queries.
- It was thought that these use cases were best addressed by a
JavaScript API rather than a CSS property.
- The breakdown of the various types of zoom that may need to be
supported was helpful and sparked renewed interest in creating
a more generalized spec involving zoom.
===== FULL MINUTES BELOW ======
scribe: dael
FXTF Meeting (con't)
====================
glyph-orientation
-----------------
heycam: There were two things in writing-modes.
heycam: One was the values for compatible with SVG 1.1 for
text-orientation. We've discussed this before but there
had been holdouts on our side, but we now all agree that
we don't need them. They're not compatibly implemented
everywhere.
heycam: I'd like to propose removing.
fantasai: I think there's probably some implementation that needs
some values to work. Last time we discussed maybe 0deg
needed to work in glyph-orientation-vertical.
fantasai: I think 270deg doesn't have use cases. If exact
compatibility isn't an issue, we can treat
glyph-orientation-vertical as an alias.
krit: Since they're different properties, I'd prefer to deprecate
them.
fantasai: We shouldn't change in the new property. You can't
support two things that control the same behavior
without defining how they interact. How it's defined
currently is text-orientation has a special keyword. I
suggest we drop the keyword and have the three values
that are used map as aliases to the text-orientation
properties.
fantasai: We did this with page break. The technical way we did
this is we defined page-break-inside as a shorthand of
break-inside. This would be the proper approach to
aliasing for the implementations that need to support
glyph-orientation. If no one needs it we could drop.
heycam: I thought we might be there.
krit: I'd rather the text-orientation. I was verifying that what
the new property supports is things that make sense.
<fantasai> Proposal would be that 'glyph-orientation-vertical:
0deg' is shorthand for 'text-orientation: upright',
'glyph-orientation-vertical: auto' is shorthand for
'text-orientation: mixed', and 'glyph-orientation-
vertical: 90deg' is shorthand for 'text-orientation:
sideways-right'
<fantasai> And glyph-orientation-vertical is not a real property,
only a shorthand
<fantasai> And the other values of glyph-orientation-vertical are
dropped
heycam: The day before we were talking about support for
glyph-orientation-vertical itself. Do you think we can
drop that whole property?
krit: One moment.
krit: It only has upright, sideways-right and sideways-left. So as
an alternative to 0deg, 180 deg and 270deg.
jdaggett: We've been talking about a proposal for sideways-lr and
sideways-rl going into the writing of shorthand which
would necessary to making sideways be sideways right.
fantasai: I don't think that affects too much what we're doing
here. It might effect the mapping of 90deg.
jdaggett: Is anyone in the room talking about implementing this
value? glyph-orientation?
fantasai: I'm proposing we drop. If there is no implementations,
if everyone will drop their existing implementation and
not be able to read glyph-orientation then we can drop
it from the spec and define that glyph-orientation-
vertical isn't valid.
krit: I'd rather if we add text-orientation support and you
ignored glyph-orientation when it was present.
fantasai: That's not a great interaction between properties. I'd
rather we define the interaction as aliasing because that
gets everything to work correctly. You implement it as a
shorthand and glyph-orientation: 0, auto, and 90 are
'upright', 'mixed' and 'sideways'. So it only needs
text-orientation plus this shorthand.
krit: It sounds complex. It's backwards-compatible and specify how
it works with the new, but it seems a lot of work.
fantasai: It's less work because no where in your code base is
checking two properties. You only support glyph-
orientation when you're doing the parsing stage because
it will map directly into the text-orientation. It saves
you data.
krit: Maybe not in Firefox, but having a new structure for a
shorthand property is a lot of work.
Florian: It's not a lot. Engines support shorthands already.
heycam: To get back to implementation. For webkit and blink, do
you support glyph-orientation-vertical: 0 now?
krit: Just for SVG.
heycam: Do you plan to remove?
krit: The problem with removal is we have content out there.
fantasai: If you're going to remove it, we'll remove the mention
from all spec. If you're not, we need to define it, and
this is a better definition.
jdaggett: Do we know there's content using this?
krit: It was used, yes. Illustrator does.
jdaggett: Illustrator is ancient.
fantasai: But Illustrator is an implementation. If they want to be
able to implement that we need to support it. If any SVG
reader needs it we have to define how to handle it in
the new world in a way they can read their old content.
This solves their problem.
fantasai: We try and avoid situations with two properties that
control the same thing. But when that happens, in CSS
the override mechanism is the cascade.
fantasai: This mechanism lets us use the cascade and that's the
same thing we've done in equivalent situations like
page-break-inside/break-inside, where we've had legacy
syntax we needed to map over. If we don't have to
support 180 and 270, which have no equivalent in text-
orientation, this is the best way.
<jdaggett> um, if no user agent implements this value I think we
should drop it
<jdaggett> legacy relationships do exist but if there's not a lot
of content that uses this
<fantasai> jdaggett, the issue is non-Web content. We need to
define how it works for those implementations, even if
no browser ever needs to implement it
Florian: We spent a bunch of time looking at mechanisms to handle
aliasing and this was best.
heycam: Okay, in the case that we're not as close to removing,
this keyword is a smart way to do it.
krit: I disagree shorthands are easier to handle. Illustrator is
interested in the new text-orientation property.
fantasai: Proposal is drop glyph-orientation vertical, drop 270
and 180, drop glyph-orientation-horizontal entirely.
Drop text-orientation use glyph-orientation value. Treat
glyph-orientation 0, auto, and 90 as aliases of the
corresponding values of text-orientation
heycam: I agree with that concept.
krit: I agree with the first points. You know my opinion on the
last, but I'm not going to object.
fantasai: If we're doing mapping, this is the way we should do it.
RESOLVED: drop glyph-orientation vertical, drop 270 and 180, drop
glyph-orientation-horizontal entirely. Drop
text-orientation use glyph-orientation value. Treat
glyph-orientation 0, auto, and 90 as aliases of the
corresponding values of text-orientation
<Florian> Here is a page on the csswg wiki exploring different
aliasing mechanism: https://wiki.csswg.org/ideas/aliasing
writing-mode Values from SVG 1.1
--------------------------------
heycam: I was initially opposed to including the old keywords as
aliases but my objection wasn't particularly strong. I
tried to e-mail Jonathan Kew, but I didn't get a reply.
fantasai: I think the spec needs that table. I don't think we need
to require that every implementation includes it. We
need that mapping for those that support the values. I
think IE does.
heycam: Unless anybody remains objecting, that's fine.
krit: So what elements would be supported for SVG?
fantasai: You either support the values or you don't. If you don't
support SVG you need to support those values.
krit: You suggested there's an ability to write it to the UA
Stylesheet.
fantasai: If you only need to support the presentation attr syntax
you can do that. If you need CSS values you'll end up
parsing in all contexts.
krit: Will that be required for all UA that support SVG?
fantasai: That's up to SVG group.
heycam: I would say yes. Given that IE has the old values and
others do, we might as well have unconditional support.
heycam: What does it say in the spec re: required?
<fantasai> "Implementations that wish to support these values in
the context of CSS must treat them as follows: "
fantasai: I should qualify that for writing modes conformance it's
optional and SVG can say it's required.
Tav: I think it should be required for SVG.
fantasai: It's required in CSS in general if you don't support SVG
you might not need to, but most UA will.
heycam: I'm fine with it.
ed_paris: Do we need a resolution?
heycam: If that's the current state, then I guess it's fine to
leave as-is.
<fantasai> ACTION fantasai add RFC2119 optional wording to svg
writing-modes keywords
<trackbot> Created ACTION-716
getTransformToElement
---------------------
<heycam> http://dev.w3.org/fxtf/geometry/
heycam: In the SVG WG we just removed some method that was under
defined that was getTransformToElement. The intention
was to give you a matrix that transforms between one
element in a system to another. One undefined piece was
what happens when you have two SVG fragments.
heycam: If you're going to support anything like that it should be
more general than SVG elements. We wanted to find out if
that's something people wanted to see. It's not urgent,
but to see if people were opposed.
smfr: It would work across 3D transforms? There are problems
computing matrices with flattened. I'd like to see points
and rectangular between coordinate systems which I think is
geometry.
heycam: Converting points and things is usually what you'll want.
shane: So this returns a matrix, is that right?
heycam: The old does a matrix. It was a SVGMatrix and recently
changed to the added DOMMatrix. What's the actual method
that does the transform.
smfr: Do you have a link?
<zcorpan> https://drafts.csswg.org/cssom-view/#the-geometryutils-interface
heycam: So that relates to take a point, interpolate and take it
to a point in another one.
zcorpan: I don't really remember.
krit: If you have a transform you can apply it to a point. You
can't take it from one point to another point in a different
coordinate system.
heycam: The main definition seems to be missing.
heycam: The answer is probably that these methods will do what
they need to or that's an obvious place to put something.
Path Animation
--------------
Tav: One piece that's missing is path animation. I think there's a
lot of interest in it. I'd like to see it be implemented
somehow. If you can just use a string or not and how you do
that, I think birtles might know more.
birtles: I'm not sure how much more. We discussed the other day
and more or less agree on the attr on a property so that
we can animate CSS transitions and animations. The part
we need is the syntax for that. Having looked at what we
have in motion path that could be more consistent to wrap
up the SVG path function and allow using the shape
functions.
birtles: We haven't quite resolved it. We also talked about making
it easier to interpolate. I wanted to try and solve that
problem, but I want to adjust to the same thing SVG does.
I think that's the state at the moment. I'm not sure
there's anything to discuss.
heycam: It got on the agenda to discuss the syntax issues. It's in
the motion path animation and it's clear we should do that.
Not sure who would be driving this.
TabAtkins: Do we have a spec for the SVG stuff as properties?
heycam: In the SVG 2 spec, yeah.
TabAtkins: So put it there. It's a paragraph for the simplest form.
I nominate heycam to write it.
heycam: Okay.
heycam: We'll discuss further in SVG.
krit: We have CSS shapes split to different specs. Level 1 had
circle, ellipse and polygon. Motion path has the path. Can
we combine so future spec would reference this one?
heycam: You want to move all the shape definitions into a single
spec?
krit: I'm asking if that would make sense.
Tav: Where?
TabAtkins: Shapes.
astearns: I have an issue in Shapes level 2 to add path.
astearns: We can add it there.
krit: Sure, that would work for me.
krit: I want to have it in one spec, I don't care where.
Tav: Animation between path and shapes is non-trivial. I don't
want to create something very complicated.
heycam: I think that's a separate decision as to if the new CSS
shapes will be used in this.
krit: The motion spec defines the start point of the motion of the
shape.
Zoom Features for Media Queries
-------------------------------
<tkonno> https://lists.w3.org/Archives/Public/www-style/2015Aug/0224.html
<tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html
<tkonno> http://svg2.mbsrv.net/devinfo/devstd/css-mediaquery-zoom/20150825_zoom_media_features.pdf
tkonno: Today for the presentation we have the proposal for media
features for MQ. The two topics are the basic
functionality and features.
tkonno: First is overview of zoom media features. First the e-mail
above has a draft spec. This is an overview.
tkonno: I proposal a new feature to control the styles or content
to zoom. We prepared this to confirm the concept. The goal
of my presentation is to get approval to proceed to an ED.
tkonno: The use cases, we are interested in the mapping using SVG.
For mapping, the map is zoomed out and the user wants the
overview. On the other hand when the map is zoomed in they
want the details such as landmarks.
tkonno: The generated map consists of the marker areas so if the
content switched according to zoom the user can get the
appropriate information. It is essential for mapping to
switch the content radius according to zoom.
tkonno: Also zoomable high resolution features. This diagram is
zoomable. In this case the user the feels that low
resolution is enough when zoomed out. Then the diagram is
zoomed in and they want high resolution images. These use
cases are realized by JS or other than web standard. We'd
like to recognize this with web standards.
tkonno: Assuming these use cases are good, how can we do them?
min-zoom is the new feature. In this example, if the
ZoomRatio is <2.0 the content would be displayed.
tkonno: The details. I explained the overview, but it is unclear
how can we define zoom.
tkonno: We think zoom is in two types. One is UA zoom, which is
page and pinch zoom.
tkonno: The pinch zoom is controlled by the user pinch zoom
gesture and it doesn't effect the viewport.
tkonno: Second is webapps control. They control the scale of the
contents. So ZoomRatio should be represented as these
parameters [page 8 of slide show]
tkonno: This formula indicates the relationship between the device
size and the content size.
tkonno: This chart [slide 9] corresponds to the previous formula.
There are 6 types of zoom type. I'm not sure all are
needed or should be prescribed. From the viewpoint of
mapping we need to prescribe #3.
tkonno: As for the other types of the document zoom, it depends on
the use case. So we'd like to propose the document zoom
feature. Imagine the use case, the web page has a map in
an iframe. The user might zoom the map content, but the
user might zoom all content. It can be realized by the CSS
transform.
tkonno: When the webpage is zoomed in using pinch zoom it's the
transform. In the case of the map, that should be changed
with the pinch zoom.
<dbaron> the term "zoom" seems quite overloaded
<dbaron> and I'm not sure what some of these numbers in the slide
actually mean
tkonno: As we look back, if you agree with us we'd like to proceed
to ED. Thank you.
Florian: I read the mail, sorry I didn't reply on the list. I
think you did a through job of describing how zoom can
interact. There's one thing. Can you put back on screen
slide 9?
Florian: Just to be clear, when you're talking about document
scale this is when the iframe is being engaged by a
document around it. All the zoom you're talking about
here is pinch zoom or transforms. That's the major
difficulty. Having a MQ on pinch zoom changes the game.
Normally pinch zoom is magnifying glass and not an
opportunity for re-layout.
Florian: I don't think this is compatible with how browsers do
zoom. It's also not clear this is user friendly. Your
cases are places that it can be done for a user in a
friendly way, but there are ways that can not be. Though
the model makes sense, in your examples you had pinch
zoom or transforms it makes me think this might not work.
Florian: What we can use in MQ is custom MQ. That way the
application is in control of what it's doing. If you have
the +/- it wouldn't be browser supported, but browser
assisted. This wouldn't natively interact with pinch
zoom, but you can hook events into doing this. You get
less help from the browser, but you get some. It would be
interesting to hear from browser vendors.
tkonno: It's different than people with implementation need.
Florian: From the user's PoV there are many bad ways of doing this.
If you do what you had with the map that's fine, but if
you re-layout while you pinch that is a bad interaction.
TabAtkins: We can expose some events, but doing it directly is
weird interaction with the compositor.
smfr: We agree. We have a policy of not exposing pinch zoom for
that reason. I think the map examples are deceptive. You
could end up devoting too many resources. The author would
think you could load high resolution as you zoom in, but it
would be for the whole page. In the map example the author
needs more control than responding to a zoom MQ. I don't
think this is something we would be interested in.
dino: It would be difficult to spec what would be used. What
labels would intersect etc. You can't do a staticDOM on a
pinch zoom level. There would be a lot of code on every
frame.
Florian: Even though in the general case this doesn't work, but in
some specialized cases you can have this. You can have a
custom MQ with JS that could work.
dino: It could be a case where it makes sense in a containment
element that would never re-layout.
Florian: For some simple examples it might work out.
dino: You can think of it as another way to do it where instead of
different resources you're swapping.
tantek: Can you get the zoom level in JS?
dino: Sometimes, depending on the browser.
tantek: Well what the MQ would be relying on.
Florian: In a mapping situation with just pinch, you don't
intercept a touch event.
tantek: That's not the question. In maps today they do take over
all the mouse events and don't let the browser zoom. What
I'm talking about is there a way for a web page to just
query.
iank: Some Google apps do this, but it's horrible.
tantek: I'd argue that if you're interested in this we should do
that first and before that a MQ is premature.
MaRakow: This is, it seems you're trying to have a MQ that's the
ratio of CSS pixels to screen pixels. I would echo the
same concern that this isn't going to be 1:1 with real
map scenarios in reality. Trying to do this as a MQ
implies the switch would be immediate upon crossing that
threshold. I think some browsers defer that activity to a
later point.
MaRakow: I think to emulate a native pinch zoom by increasing
fidelity I think needs to be more sophisticated. I do
think there might be a good case to detect your screen to
local CSS pixel ratio. I can see that, though maybe not
as a MQ.
liam: There's also an interaction with a11y issues. When I zoom in
on a map I do it because I can't see the details. If the
details change I'm going to be frustrated. There's a
difference between zooming in for details and for what's
there.
tantek: Talking about this in theory is pointless. The wide
variety you could do is incredible. All the parallax stuff
added to scroll, for example. We don't have a MQ for
scrolling either. I want to keep pushing back and saying
no this is premature. Let's start with a simple JS DOM API
and see what people build and we can see if there's a
pattern in what people build.
<tantek> e.g. http://www.sbs.com.au/theboat/ (parallax example)
dbaron: It also focuses most on the most global zoom. Many things
want to be just this local document zooms and not say
someone is in the middle of zooming your be app. Some
browsers might use zoom to show it, not the webpage
reacting to that.
Florian: This is an interface that happened in old Opera where you
have a zoom out preview of your content and MQ starts
making things strange, that doesn't quite work.
Florian: Being liam's reasons, I'm not even sure the API from
tantek is right because even the magnifying glass is just
to make things bigger. I'm reluctant to hijack things.
There are good things to do here, but I'm hesitant to
have the problems.
liam: There is an analogy to open type fonts. They can remove
detail when the font is rendered small. There's precedent
for this kind of behavior. But you don't change E to W as
you zoom, but you can change serif to be flat instead of
curved. I could see merit in that for SVG, but the set of
use cases is different. That's done partly for making
rendering fast. Fetching a network resource would slow
things down.
tantek: Thats' what Google maps do.
Rossen: This is almost like saying you shouldn't do xhr based on
user interaction. It's overstating.
tantek: Authors can do stupid thing, that's not a for or against.
zcorpan: For the high resolution use case, there's srcset for the
x descriptor. When the user zooms in the browser can load
high resolution?
Florian: And that works better than MQ. The trigger points for MQ
are basic. The logic for SourceSet approach is left to
the browser and it can be smart.
zcorpan: So if you start zoom in and you load the high image,
there's no reason to download the low resolution.
Florian: And in MQ if you go up and down it reloads every time.
ed_paris: It seems the group doesn't agree with publishing. Do we
want to resolve?
heycam: It sounds like starting with JS API to expose zoom levels
and events when zoom level changes.
Rossen: Yes. That is an old discussion we had in Shenzhen where
there was a spec that was supposed to be written by
various members of the group and this didn't go well.
Rossen: I think this is something that comes up more and more. We
better get this spec done and document the different zoom
types and then expose some minimal OM hooks so that people
who care can build.
dino: One thing that put me off it is any time the topic was
brought up the response was we agree and you should do it
our way. So maybe we should agree that we should come up
with a new way.
Rossen: I think there's a strong signal that we need something.
Florian: In terms of exploring the different types, today's
proposal does a good job of looking at the different
types of zoom and how they interact.
tantek: Rossen I'm not seeing the strong signal that you are.
tantek: Which is why I'm advocating for the JS API for people to
experiment and develop use cases.
<tantek> also, zoom property?
<tantek> are you (Rossen) going to drop that?
Rossen: JS API is fine, I wasn't suggesting anything.
dbaron: What Rossen is saying is before we have the API we should
have a list of what the different types of zoom are and we
don't have it.
Rossen: In our implementation we've been trying to reduce the
crazy things we were trying to do before.
Rossen: I proposed a spec in the NY F2F on the zoom property.
smfr: I was waiting on you for sites that do that.
shane: I've collected data.
Rossen: There were very few sites using zoom. There was one site
trying to use zoom for some really weird reason and
getting lucky, but as soon as you throw in different API
and other user settings, it was a mess.
birtles: Before we get on the zoom property, can we tie up the
previous conversation?
birtles: What is lacking in the current analysis of the zoom types?
dbaron: In that document? I couldn't understand the types so I
couldn't map.
birtles: So we need more data?
tantek: Is that document in IRC?
several: yes
birtles: I wasn't sure what use cases are lacking? The property
isn't abstract, it is for maps they want to use it for.
dbaron: I think a lot of people are saying this is not a good way
to do maps.
birtles: I'd be curious for a way ahead. KDDI was looking at
pictures with media attr and I think that's where MQ
entered the equation. I think it's clear that MQ in the
general case isn't for this. I think high resolution
photography use case isn't clear. You have low and high
resolution and want to break up the tiles so just source
doesn't address that.
hober: Once you start talking tiles it's custom.
tantek: Tiling is the abstraction that covers maps and these
photos.
birtles: They had some use cases covering this type of feature. I
think it's clear that MQ isn't the way forward. There's
more forward and for the tiles which is the way forward.
ed_paris: Do we need a formal conclusion?
ed_paris: I think that was the last FX topic?
<break=15min(ish)>
<fantasai> ACTION fantasai to add note about baseline-table property
<trackbot> Created ACTION-717
Received on Monday, 14 September 2015 18:00:00 UTC