- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 20 Mar 2015 02:43:28 -0400
- To: www-style@w3.org
ID-less Referencing
-------------------
- RESOLVED: Accept the 'child' keyword in all referencing
properties.
Referencing Properties
----------------------
- The group discussed what level properties need to be at to be
referenced in SVG 2
- RESOLVED: CSS WG agrees to publish Shapes 2 as a FPWD
Text In A Shape
---------------
- Tav requested that he'd like to retain a property that allows
you to wrap into a shape.
- There was discussion on if that's still possible. Regions was
one option, but it was complex for the use-case. Floats and
exclusions seemed to offer the correct behavior, though having
a child keyword for positioning was also a possibility.
Flexbox
-------
- RESOLVED: Publish flexbox CR under the new process
::selection
-----------
- RESOLVED: add ::inactive-selection to Pseudo Element Level 4
===== FULL MINUTES BELOW ======
Scribe: Cyril
ID-less Referencing
-------------------
<birtles> http://people.mozilla.org/~bbirtles/pres/referencing-proposal-2015/
birtles: Quick proposal about referencing elements from CSS
properties without using ID.
birtles: The motivation is masking for example.
birtles: You want to point to another element
birtles: but mash-ups can have conflicts.
birtles: Unique IDs is a solution but that's a bit too much:
birtles: readability, file size,
birtles: and a pain to generate from JS.
birtles: Semantically not great.
birtles: It'd be better if we could nest mask in path.
ChrisLilley: The downside is you can only have one child in some
cases.
birtles: We could try nesting,
birtles: but that's not good for backward compatibility.
birtles: I proposed a keyword:
birtles: 'child' to say the first descendant.
birtles: If you have multiple masks, child would mean the last one.
birtles: It would work for paint servers.
birtles: The one issue is both fill and stroke refer to the
children.
birtles: The proposal is to use a select syntax.
Tav: You could also need a list: gradient and pattern as a fill.
birtles: The proposal is to use selectors scoped to the subtree.
birtles: That was removed from CSS masking to find a more generic
solution.
ChrisLilley: I don't see how it could be more generic than
selector.
ChrisLilley: The only constraint is the fact that it selects
amongst the children.
heycam: Using selectors you could have things depending on
attribute values, structure of the tree
heycam: making it difficult to watch mutations in the tree.
heycam: If the selector would be limited to children or element
names
heycam: it'd make it easier to track.
fantasai: We have an outstanding issue in GCPM
fantasai: that the element function in GCPM and CSS 4 don't agree.
fantasai: Changing syntax is on the table.
birtles: element() with an ID doesn't help.
heycam: Concerns are different with navigation
heycam: where you don't watch for changes.
ChrisLilley: Previously it was not enough generic, now it is too
generic.
cyril: Why don't we restrict selectors to nth-child?
TabAtkins: We could add full selectors in the future.
ChrisLilley: I would rather use selectors and constrain it.
TabAtkins: select(nth-child(2)) is longer than child(2).
TabAtkins: What if you want the 2nd linearGradient here and not
the 2nd child?
birtles: If you allow element name and child
birtles: we could disambiguate by giving the element name.
TabAtkins: I don't like remembering what arbitrary things I'm
allowed to use.
heycam: I don't see use cases for selecting things other than
children.
heycam: I don't like to write mask="select(mask)".
heycam: The GCPM function takes a custom identifier.
krit: Do we care if we have a different solution for both?
ed: We could restrict the order in which you put children elements
for fill and stroke.
krit: You can have fill with multiple layers.
TabAtkins: the child keyword does not allow that.
krit: That's why it's not useful.
TabAtkins: Is that a huge deal if we restrict selectors to
matching children?
heycam: You'd still have to watch for class changes...
heycam: it's unlikely I'd be able to reuse the existing machinery
for style changes.
heycam: I'd like to see if Erik's model could work,
heycam: it needs more thoughts.
ed: Do we expect that it will be common for people to use multiple
fill and strokes?
TabAtkins: We could solve the common case now (1 child per paint
server) and expand later.
TabAtkins: fill="child child child" could be use the 3 first
children to use for fill.
heycam: We could use that for markers
heycam: but markers have zillions of properties.
TabAtkins: I don't think we want to use paint order.
TabAtkins: The mental model isn't as intuitive.
RESOLVED: Accept the 'child' keyword in all referencing properties.
krit: Do we define in it in the common spec?
heycam: Yes, in the SVG 2 spec.
ed: The order is we consume children for fill first and then for
stroke.
cyril: What if the same paint server is used for fill and stroke?
TabAtkins: You have to repeat it.
Tav: Or give an ID.
Referencing Properties
----------------------
<Tav> http://tavmjong.free.fr/SVG/PROPERTIES/index.html
Tav: I've been working on the text part of SVG
Tav: and one of the problems is that it references so many
properties.
Tav: The modules are in various stages of preparation.
Tav: What do we allow to reference?
Tav: For example writing modes redefines writing-mode a little bit
differently.
fantasai: text-decoration-fill would go in Level 4 of Text
Decoration.
krit: So you could put it in SVG.
Tav: Are we allowed to reference a WD?
ChrisLilley: Yes, but you can't go past CR.
Tav: Shapes 2 is needed but it's in ED.
astearns: But it's ready to be in WD.
heycam: What's new?
astearns: shape-margin, shape-inside, referencing SVG shapes ...
ed: Can we have a resolution to publish WD?
fantasai: We probably have quorum for publishing.
fantasai: Adobe is ok with publishing, Google is.
dbaron: That seems fine.
dino: I'm ok.
RESOLVED: CSS WG agrees to publish Shapes 2 as a FPWD
tav: I'm happy to have a agreement that I can reference those
specs.
fantasai: About baseline-shift
fantasai: Do you output it in the CSS form or SVG form?
Tav: In the CSS form.
heycam: I have a separate topic on that.
Tav: How soon can it be done?
fantasai: I can get you a very rough draft today.
<fantasai> Plan is to have a dominant-baseline property
<fantasai> and then a vertical-align property with longhands
alignment-baseline and baseline-shift
Tav: We need to do that in the SVG 2.
heycam: You have a future model in mind, reducing the number of
properties by half, simplifying the model.
heycam: In Firefox we implement only dominant-baseline.
heycam: People have content that uses it to position text.
heycam: Webkit supports alignment-baseline, dominant-baseline and
baseline-shift.
heycam: The effect if you specify alignment-baseline and
dominant-baseline is unclear.
fantasai: The initial value of alignment-baseline should be auto
and auto should look at the dominant-baseline property
of the parent.
dbaron: Not alignment-baseline?
heycam: baseline-shift has length + keywords: superscript ...
heycam: My overriding concern is to make sure we just have what
SVG needs without constraining your model.
heycam: If you're happy to write a minimal document that we can
reference then we're fine.
fantasai: I can have a document in a year.
heycam: Ok.
heycam: That has 4 properties instead of 3.
heycam: The XSL properties were used at some point in the SVG spec
and then tweaked.
fantasai: What is in the SVG spec is what I might put in the CSS
spec.
<dbaron> There are some useful definitions in
http://www.w3.org/TR/xsl/#vertical-align and
http://www.w3.org/TR/xsl/#area-alignment
[discussing new process]
<liam> [The XSL-FO properties were in turn supposed to be aligned
with CSS 2 where possible, modulo the evolving box model.
http://www.w3.org/TR/xslfo20/#vertical-align was the most
recent/final draft before we stopped working on it, but I
think it unchanged from 1.1 ]
heycam: The other part is what to do about the old writing-mode
values and glyph orientation vertical stuff.
heycam: fantasai seems to be of the opinion that there are
interesting things even if not in the open web.
heycam: krit showed some output of Photoshop for vertical text
using writing mode TB.
<heycam> In SVG there are old keyword values for writing-mode, and
an old glyph-orientation-vertical property that lets you
control how Latin glyphs are oriented in vertical text.
<heycam> In writing modes spec, there are new keywords for
writing-mode, and a text-orientation property for
controlling glyph orientation.
krit: Glyph orientation horizontal and vertical have the same
usage statistics.
krit: I would suggest we deprecate them but not remove them.
heycam: I haven't seen bug reports about them, but I have about
alignment-baseline.
ChrisLilley: Some people said that most fonts don't give that
information.
heycam: I have enough information about the plan for those
properties.
text-orientation keywords
-------------------------
Chrisl pokes fantasai to explain random side comment to everyone
fantasai: On previous topic, I was just commenting that I should
have named sideways-left and sideways-right as
sideways-lr and sideways-rl, but it's probably too late
to change that.
fantasai: writing-mode has values that are horizontal-tb and
vertical-lr and text-orientation: sideways-left,
sideways-right
fantasai: text-orientation could change from sideways-left and
sideways-right... could change to sideways-lr and
sideways-rl
heycam: Why not sideways-tb etc.?
fantasai: text-orientation talks about orientation of glyphs --
where is top/bottom of line -- not where is start/end of
line.
fantasai: The correct text-orientation:sideways-* for horizontal
scripts is the one that matches the writing-mode:
vertical-*
heycam: Question.
fantasai: [diagram that's hard to minute because it's in vertical
writing]
fantasai: Might be deployed content in Japan that relies on these
things, is why we probably can't change.
Text In A Shape
---------------
<Tav> http://tavmjong.free.fr/SVG/TEXT_FLOWED/index.html
Tav: SVG 2 reintroduces text flow in a shape,
Tav: The initial version 1.2 got supported only by Batik and
Inkscape.
<liam> [ Tav -- http://www.w3.org/TR/xslfo20/#fo_extension-region
and scroll up to figure 50 with the yellow hexagons ]
Tav: Back to the text in shape topic.
Tav: In SVG1.2Tiny you could wrap into one box and another and
another.
Tav: Could we retain that property?
astearns: We've proposed several ways.
astearns: Florian also proposed another method.
Tav: I looked at regions and it seemed complicated for that.
astearns: Overflow fragments have to be siblings
astearns: not regions.
astearns: I don't now what your requirements are.
Tav: 3 references comma separated.
heycam: In the old way, you had SVG shapes in the document, child
of some special flow document
heycam: and the text flows in then one by one, no automatic
generation of shape.
heycam: Do you want that behavior?
Tav: No, I don't want automatic generation of shapes.
astearns: And if it overflows ?
Tav: It goes nowhere.
Rossen: You need regions then.
astearns: The concepts are in the regions spec.
Tav: A simple comma separated list of shapes would not work?
astearns: We did not want to add that syntax in shape-inside
astearns: that would need to be something for SVG to define.
heycam: That goes on the text element.
astearns: I don't know if it needs to extend shape-inside or have
a new shape-inside-list.
* ed <text shape-inside="child">foobar<path .../></text>?
Tav: In SVG there would be two ways to get the content region:
width for horizontal text and height for vertical text or by
giving the shape in which it will wrap.
Tav: I wanted to check the syntax.
Rossen: The behavior in SVG 2 seems to combine 2 or 3 specs.
Tav: The text doesn't flow in the 2 rectangles.
Rossen: So you don't need regions
Rossen: but you need exclusion.
Tav: Two separate text elements both shape-inside (different) but
one has a shape-outside.
<heycam> [this is pointing to the "An example of using
'shape-outside'" example currently in the spec]
astearns: shape-outside only apply to floats.
Rossen: Or exclusions.
astearns: You'd need wrap flow too.
astearns: In CSS to get wrapping behavior you need floats or
exclusions.
astearns: It's adding one more property.
astearns: It adds the ability to have the content overlapping or
wrapping.
Tav: I'm wondering if SVG needs that level of complexity.
Rossen: But you are positioning with x and y.
astearns: I think you need it.
ed: Have you considered having a child keyword for this as well to
keep the shape inside the text?
Tav: possible.
<heycam> <text shape-inside="child">ABC DEF <circle .../></text>
ed: I don't think a rectangle (or shape) is rendered currently in
a text.
Tav: And also having a text inside a rectangle.
heycam: You think the syntax is more natural to have the text
inside the rectangle?
Tav: Yes.
<AndreyR> Another topic from CSS agenda can we discuss issues?
http://dev.w3.org/CSSwg/CSS-pseudo/#highlight-pseudos
Flexbox
-------
fantasai: Can we go to CR ?
Florian: What do we do about the order issue?
fantasai: So far there are several proposals:
a) don't change anything
b) make order affect all things and extend later
with longhands that affect one thing or another
c) and drop the order property
Florian: I'm not excited about opening new things
Florian: but the shorthand longhand thing made sense to me.
fantasai: We don't have the person to discuss this
fantasai: but I would like to publish things, because we're out of
date.
Florian: I'm happy with publishing.
Rossen: Any objection?
[silence]
dbaron: Are there any big things that don't match what it used to
do?
fantasai: No.
dbaron: Sounds good then.
RESOLVED: Publish flexbox CR under the new process
::selection
-----------
<AndreyR> http://dev.w3.org/CSSwg/CSS-pseudo/#highlight-pseudos
fantasai: There is an issue in the spec on how to select inactive
selections.
fantasai: Do we want to add another pseudo for that?
fantasai: I don't think that's a good idea.
Florian: Inactive selection?
fantasai: Select and then focus another window.
Florian: That does not match selection, but nothing selects it.
RESOLVED: add ::inactive-selection to Pseudo Element Level 4
-- meeting adjourned --
Received on Friday, 20 March 2015 06:43:55 UTC