W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[CSSWG] San Francisco F2F 2016-05-10 Part II: CSS tables status update, CSS 4 UI, Page Media Query, Generated Content Spec [css-ui] [mediaqueries] [css-page] [css-content]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 May 2016 20:04:21 -0400
Message-ID: <CADhPm3tGrt655LwoCwSUuAgMm=W_VKjJ5rhBNn_LA6kA6u4anA@mail.gmail.com>
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.

CSS tables status update

  - gregwhitworth updated the group on his progress with the tables
  - It's not ready for FPWD, but he's looking for feedback from
    anyone interested in reviewing their work.


  - Florian will look through UA stylesheets to list explicitly what
      user-select:none applies to.
  - RESOLVED: appearance: none for checkbox and radio become
              non-replaced elements.
  - There was a proposed set of principles for 'appearance'
      1) it shouldn't change what you can do with it
      2) you can't break web compat
      3) should not prevent improvements in the UI
      4) It might as well be useful so long as it doesn't violate
            the other three principles.
  - RESOLVED: add :playing and :paused pseudo-classes

Page Media Query

  - RESOLVED: Apply the same logic as @viewport has for @page size
              for viewport size.

Generated Content Spec

  - RESOLVED: Content property applies to all elements, but only
              lone <url> values apply to real elements--other
              values will be ignored.
  - RESOLVED: Add trailing-slash alt-text to content property.
  - RESOLVED: Replace <url> with <image>|<url>
  - This spec still isn't friendly for accessibility, but would be a
      good guinea pig for doing accessibility mapping.
      - dauwhe and Rossen will work with the editing task force and
          dauwhe will add a note to the spec.
  - RESOLVED: Drop <datetime>
  - RESOLVED: Drop document-url
  - RESOLVED: Publish new WD of Generated Content (possibly FPWD
              depending on patent policy needs).


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

Scribe: zcorpan

CSS tables status update

  <gregwhitworth> https://drafts.csswg.org/css-tables-3/
  gregwhitworth: In Sydney we asked for the opportunity to work on
                 the tables spec:
  gregwhitworth: we've made good progress.
  gregwhitworth: The blink team reached out regarding height
  gregwhitworth: We handle border painting.
  gregwhitworth: html5 says you can have empty tables, we need to
                 figure out how to lay that out.
  gregwhitworth: We were asked for the tests. we've begun putting
                 them into a branch.
  gregwhitworth: As you can tell we have a ton of investigations.
  gregwhitworth: We'll continue to port those over into the test area.
  gregwhitworth: The goal is what the test represents and you can
                 match the test against the spec text, should be
                 straightforward what is tested.
  gregwhitworth: Other browsers to review height distribution etc.
  gregwhitworth: Things we've ported over from 2.1 that were
                 previously undefined.
  gregwhitworth: If you can review it, we're not at FPWD right yet
                 but review is welcome.

  Florian: Comment on the methodology:
  Florian: If browsers do the same you spec that...
  Florian: If nobody makes sense and everyone is different, spec
           something that does make sense.
  Florian: With regard to table topics that relate to fragmentation
  Florian: page UAs have considered this more than browsers.
  Florian: Please consider such UAs also.
  Rossen: There's no fragmentation definition...
  fantasai: For tables there is, in css-break
  Rossen: The majority is in css fragmentation.
  Florian: Table headers and footers, whether they fragment or not,
           browsers are not the primary things to look at.
  TabAtkins: Let's describe compat right now.
  gregwhitworth: I said slot is not defined, it's an issue.
  gregwhitworth: We're early on on this, we are not going to tackle
                 this in this level.
  Florian: 2.1 says it's undefined, now you're removing it.
  Florian: I'd rather not say print UAs are irrelevant.
  gregwhitworth: Hopefully the next time we talk, we can present
  gregwhitworth: We don't need to handle this now. We haven't begun
                 to investigate it yet.

  Rossen: Is that everything you have?
  gregwhitworth: One more link.
  <gregwhitworth> table issues readme:
  gregwhitworth: If you go to the github repo you can see the issues.
  gregwhitworth: External people having input and we're working on
                 addressing that.
  Rossen: Thanks Greg.


Variants of <input> for user-select:none (Issue 22)

  <Florian> https://drafts.csswg.org/css-ui-4/#issue-2e1305f8
  Florian: user-select: none should be applies to button...
  Florian: Should the spec say anything about that?
  Florian: Should it list which elements it applies?
  Florian: What do you think?
  Florian: Should it say which elements explicitly?
  TabAtkins: Yes. it should say what UAs do.

  Florian: Is any browser interested in helping with this?
  dbaron: I can tell you what we have in our UA stylesheet.
  dbaron: Marker, canvas are none,
  dbaron: input and textarea have text,
  dbaron: select has none,
  dbaron: option has none,
  dbaron: optgroup has none,
  Florian: Can you dump this?
  <hober> search for user-select in
  dbaron: Things that look like buttons.
  Florian: I can read the UA stylesheets myself but there may be
           knowledge about things that are known bugs etc.
  tantek: We can dig into the implementations.
  Florian: ok, I'll do that.
  <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/ua.css
  <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/html.css
  <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

Allowing pseudo-elements on form controls when appearance:none

  <Florian> https://lists.w3.org/Archives/Public/www-style/2016Mar/0190.html
  Florian: This was a question from TabAtkins
  TabAtkins: As I said in the email, safari and chrome allow
             pseudo-elements on form inputs.
  TabAtkins: It's used on more than our removal threshold allows,
             about 20x more.
  TabAtkins: There's a handful that are possible to describe.
  TabAtkins: We'd like to allow them when appearance is none
  TabAtkins: and make that interoperable with other stylesheets.

  hober: This is allowing ::before / ::after?
  TabAtkins: Yes.

  dbaron: Text input?
  dholbert: A non-themed box.
  dbaron: There's also a complex structure for scrolling.
  dbaron: If you type enough such that the text needs scrolling,
          does that work with appearance: none ?
  TabAtkins: Whatever element you have that is user editable, the
             before/after would be children of that.
  TabAtkins: It becomes an ordinary box that is user editable.
  dbaron: It's -webkit-appearance in chrome?
  TabAtkins: Yes.
  dbaron: Which type of input? Not text inputs for me.
  TabAtkins: checkboxes and radio buttons.
  TabAtkins: I thought text inputs as well.
  dbaron: I see it on checkboxes, not text inputs.
  [room is testing]
  <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%22%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr%3E%0A%3Cinput%20type%3D%22checkbox%22%3E

  TabAtkins: Hum.
  TabAtkins: Checkbox and radio are the big ones.
  dbaron: If the idea is that appearance: none on checkbox and radio
          means all styling goes away.
  TabAtkins: Still atomic inlines, just empty, 0x0.
  bradk: For search? placeholders?
  <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%3B%20border%3A%20medium%20solid%20green%3B%20display%3Ainline%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%5Ca%20world%22%3B%20white-space%3A%20pre%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr
  <dbaron> %3E%0A%3Cinput%20type%3D%22checkbox%22%3E
  dbaron: An appearance: none checkbox is display: inline-block.

  TabAtkins: Can you implement this? appearance: none and
             before/after on checkbox and radio
  dbaron: Yeah, basically that appearance:none checkboxes and radios
          are no longer replaced elements.
  dbaron: Ok with that.
  TabAtkins: Happy to explore more, but start with this.
  <fantasai> +1
  Florian: The generalization is the next topic.

  Rossen: Anyone against this resolution?
  Rossen: Proposed Resolution: appearance: none for checkbox and
          radio become non-replaced elements

  RESOLVED: appearance: none for checkbox and radio become
            non-replaced elements.

Generalization of previous topic

  Florian: We're going to have this discussion for lots of topics.
  Florian: Form controls are full of quirks, need to look at each
           one by one.
  Florian: Some are easy like checkboxes.
  Florian: Some where you can do that but you need to keep some UA
  Florian: For compat reasons some things need to remain, like range
           you need the knob.
  Florian: We need to do this at some point, but not right now.

  fantasai: Who's not interested?
  dbaron: The spec needs an editor.
  Florian: I'm editor but I don't want to do it alone.
  Florian: OK with an co-editor, also OK staying alone as editor if
           nobody steps up.
  dbaron: The spec needs an editor who does the work, not in a WG
  Florian: I have a google engineer who can help me, maybe that's
  gregwhitworth: It would be good to have other vendors also.
  gregwhitworth: I can't commit editor time but I want to help.
  want to make sure it's not just Google defining things on their own

  gregwhitworth: Does anyone have an issue with propagating
                 appearance: none to the controls?
  gregwhitworth: There's an endless cycle.
  gregwhitworth: This just exists because webkit compat.
  Florian: No....

  Florian: I have some general principles that google engineers have
           agreed with.
  Rossen: Seems like more work is necessary before this is actionable.
  Florian: This is an appearance property, not a behavior property.
  Florian: It shouldn't change what you can do with it.
  Florian: The other principle is you can't break web compat.
  Florian: It might as well be useful so long as it doesn't violate
           the above 2 principles.
  fantasai: The other one is also, maintain the ability to improve
            the UI.
  fantasai: Whatever we do here should not prevent improvements in
            the UI, to adapt to new platforms
  Florian: Ok I agree with that?
  fantasai: We should adopt the principles, sounds great.
  Rossen: Anything else?

  <tantek> I like things with URLs.
  <hober> https://wiki.csswg.org/spec/css4-ui
  <fantasai> tantek, here's a URL

  <zcorpan> Proposed Resolution: principles for 'appearance' (1) it
            shouldn't change what you can do with it (2) you can't
            break web compat (3) should not prevent improvements in
            the UI (4) ???
  <fantasai> (4) It might as well be useful so long as it doesn't
             violate the other three principles

  <tantek> fantasai, those principles sound vaguely ok, but too
           ambiguous to actually +1. Needs a more precise writeup,
           e.g. "it shouldn't change what you can do with it" is so
           ambiguous as it could be used to justify anything
  <fantasai> tantek, it's not a spec, it's guidance for the spec
             writers. It's fine as such imho
  <tantek> so yeah, I guess as written up on the JS-dependent URL of
           I would -1 as is
  <tantek> guidance which can be used to justify anything is useless
           and not worth giving
  <fantasai> tantek, suggest improvements?
  <fantasai> tantek, I have no idea what you're objecting to
  <tantek> I did, "Needs a more precise writeup"
  <fantasai> tantek, that's not a suggestion for improvement, that's
             a complaint
  <tantek> fantasai, how about dereference the pronouns in "it
           shouldn't change what you can do with it" to more precise

Potential features for CSS4-UI

  hober: :playing and :paused pseudo-elements for media elements
  <tantek> per: https://wiki.csswg.org/spec/css4-ui
  hober: Last time we got side-tracked and it got hairy.
  hober: Does anyone object to :playing/:paused pseudo-classes?
  TabAtkins: We existence proofed for a button that morphs on those
             two categories so I agree.
  Florian: Putting things into the UI spec or selectors spec....

  RESOLVED: add :playing and :paused pseudo-classes

Page MQ

  Florian: The size property inside @page should relate to MQ in the
           same way as viewport.
  Florian: I've written an email with use cases.
  <fantasai> Florian's proposal:
  Florian: The viewport should respond and influence the MQs in the
           same way.
  TabAtkins: Page size seems like the same thing as viewport.
  Rossen: Sounds reasonable.

  dbaron: Do we have impls of what @viewport says to do?
  Florian: Edge does it.

  dauwhe: [asks about bleeds]
  Florian: The size that you query.

  Rossen: Any objections?
  dauwhe: Do the keywords cause problems?
  Florian: Don't think so.
  <zcorpan> Proposed Resolution: apply the same logic as @viewport
            has for @page size for viewport size
  * fantasai agrees with that

  RESOLVED: Apply the same logic as @viewport has for @page size for
            viewport size.

  <break type=lunch>

  [Return to Round Display discussion - see part 1]

Scribe: ChrisL

Generated Content Spec

Content Property

  <dauwhe> https://drafts.csswg.org/css-content/
  dauwhe: It has been less than 13 years since my last confession...

  dauwhe: Pending pseudo class,
  ChrisL: handwaving,
  dauwhe: have solidly reworked this spec and removed all the cruft.
  dauwhe: Some migration from GCPM also.

  dauwhe: Content property applies to elements as well as pseudos.
  (discussion on which browsers do this already)
                  Pri M Stars ReleaseBlock Component Status Owner
Summary OS Modified
  <gregwhitworth> https://bugs.chromium.org/p/chromium/issues/detail?id=597466
  TabAtkins: If we have exactly one image in the content property it
             is replaced.
  Florian: Content property on elements in Presto - was removed.
           Everything turns into periods because of mistyped
           clearfix rules.

  dauwhe: Also added a mechanism for alt text for generated content:
          at the end of the content value there is a slash and then
          the alt text.
  fantasai: example of alt text need is three stars for an HR but
             don't want that as alt text
  Florian: Or use the image() function and have the fallback inside
  fantasai: Disadvantage - its more complex, and you don't want alt
            text for other image uses. Just for content.
  fantasai: Want it to cascade with the content
  fantasai: so put togeter the syntax for the alt and the content it
            is replacing.
  dauwhe: Should be the value of the string by default.
  Florian: OK

  TabAtkins: Remember when we wanted to replace arbitrary elements
             with arbitrary strings ....
  TabAtkins: with images is fine.
  Florian: Do we need an extra keyword to opt-in?
  fantasai: In general, make it work and find a workaround if it
  TabAtkins: Prefer we don't do it, only as an image replacement.
             Replacing arbitrary elements with arbitrary text has no
             good use cases.
  astearns: Would it make sense to have a replace() function where
            this is wanted?
  Florian: Shortening for small screens.
  ChrisL: As long as the text is coming from an attr like data-
          whatevs in the content, so available to AT
  ChrisL: not replacing with random stuff from a stylesheet.
  TabAtkins: If it is decorative, still don't like it. there is
             already replacement with alt if img doesn't load.
  Florian: With cross references, may be easier to write the markup,
           but you need more functions than this.
  fantasai: There is a content keyword to do this.
  dbaron: At some point you are reinventing web components in css
  dbaron: One of the reasons this got abandoned was hixie went to
          work on XBL2 instead which eventually became web components.

  TabAtkins: No difference between a literal string and an attr
  fantasai: You might want to get title of an abbr and replace with
            the title. A11y folks want this.
  fantasai: Should not need javascript to use this.
  fantasai: Alternate ways to express same concept, selection
            between them inline. Needed in publishing.
  Florian: Non-metaphor substitutions for people confused with
  TabAtkins: Don't put text in attr, you need markup for lang etc.

  Florian: So only for images, then?
  dbaron: What do you use this for?
  TabAtkins: It is one way to do an image replacement.
  gregwhitworth: I posted the bug earlier
  hober: Custom image replacement.

  Florian: Prince, Antenna House and pdfreactor all do text
           replacement on arbitrary elements.
  ChrisL: For a pdf output, the user sees the output only. so
          different from the web browser case where the content, not
          the output of rendering, is used.
  Florian: Maybe vivliostyle too, need to check.
  <Florian> I just checked, and Vivliostyle does not apply the
            content property to ordinary elements. (neither for
            strings or for images)
  Florian: It is proven to be web compatible
  Florian: and may be web required. Chrome does it.
  <dbaron> it's pretty weird

  RESOLVED: Content property applies to all elements, only URL
            values apply to real elements. other values will be
  RESOLVED: Add trailing-slash alt-text to content property.

  Scribe: fantasai

  ChrisL: It's relatively easy to explain, at least.
  ChrisL: Certainly there are a11y concerns with replacing the
          document content, so it's reasonable.
  gregwhitworth: I'd prefer we didn't do this, but if rest of WG
                feels it's worth going after, not going to push back
                too hard.
  astearns: In some ways doing something a little weird in order to
            reflect reality, but also have this mechanism by which
            some browser shave implemented some things that have not
            been specced with prefixes.
  astearns: Others are implementing just to be web compatible.
  astearns: We could wait to put this in, until such a time that
            other browsers find it necessary to implement for web
  gregwhitworth: We could also suggest that said browsers remove it
                 to be compatible with the spec.
  Rossen: Do we have any kind of usage data?
  TabAtkins: No.
  fantasai: I'm okay with either way, really want to update the rest
            of the spec.
  fantasai: Can always revisit this.

  plinss: Why url() and not image()?
  fantasai: In theory, you can insert an mp3 into the speech output.
  fantasai: Be cool if you can do image replacement on text, could
            do audio replacement on it too.
  plinss: Should be an <image>
  fantasai: I think it should be <image> or <uri>

  RESOLVED: Replace <url> with <image>|<url>

  * plinss notes that <image> already includes <url>
  * fantasai notes that <image> is implied to be an image


  dauwhe: Had some general questions about a11y.
  dauwhe: Existing bugs about generated content not being searchable,
          selectable, etc.
  dauwhe: I think it should be.
  dauwhe: Can we just say that in the spec.

  Florian: These various things are related.
  Florian: Tricky for selectable, because APIs for selection are in
           JS/DOM world.
  hober: Need to ask editing TF to improve their APIs.
  Florian: ...
  hober: Let's just ask them to do it.
  Florian: Do we ask them to do it, and then do our thing in the
  fantasai: I think we put how we think it should work in the spec,
            and then have them figure it out.
  dbaron: Shouldn't assume they'll do it.
  hober: Hence why I suggest we ask them to do it.

  <gregwhitworth> ^^ Is not in Chrome/FF
  <gregwhitworth> not sure if it works in webkit or not
  <gsnedders> gregwhitworth: I don't think it ever has been
              elsewhere. Including (Zombie)Presto.
  <gregwhitworth> gsnedders: what?
  <gsnedders> gregwhitworth: It's not ever been selectable anywhere
              except Edge, not in Chrome/FF/ not even in Presto with
              it's general content: support
  <gregwhitworth> gsnedders: so what you're saying is we're awesome
  <gsnedders> gregwhitworth: yeah, you're the best <3

  Rossen: A couple months ago, had a conversation with Richard ???.
  Rossen: As well as Michael Cooper.
  Rossen: Their request was to create a spec which is similar to the
          other accessibility mapping specs, but for CSS.
  Rossen: What you're describing would be a perfect fit for that spec.
  dauwhe: That was my next question...
  dauwhe: Whose responsibility is this?

  Rossen: There are two types of things that we do in CSS that make
          a11y harder.
  Rossen: One is generated content, which adds more visible content,
          which is not accessible through the DOM.
  Rossen: We also create box structure that is not backed up by
  Rossen: e.g. anonymous boxes.
  Rossen: Not something that OM can query. Nor AT should care about.
  Rossen: Point of that spec was to define all of the different ways
          that we are affecting accessibility, and specify what the
          UA is supposed to provide so that a11y doesn't suffer.
  Rossen: Other one was 'order' property, which we partially address
          with prose in the spec.
  Rossen: But still on the hook for that.
  Rossen: My feedback would be to start focusing on that spec.
  Rossen: Maybe point CG to that spec.

  fantasai: While I think it's fine to point to that spec for more
            details, I think we should be very clear in this spec
            that generated content is to be accessible.

  Florian: Is visibility of a piece of content in the a11y tree and
           select-ability of a piece of content, and search-ability
           of a piece of content the same thing, or is it not?
  ChrisL: It should not be.
  ChrisL: They're not orthogonal, but not completely independent
  Rossen: You're describing different views of a document.
  Rossen: You're describing views for presentation on screen.
  Rossen: And view for an editor.
  Rossen: And view for an AT.
  Rossen: Editor being selection.
  Florian: I disagree that editing and selection are the same.
  Rossen: Then your engine is weird.

  Florian: If these things are not the same, which are affected by
           'user-select: none'?
  Florian: If you 'user-select: none' is it searchable? Is it in the
           a11y tree? Obviously it's not selectable.
  Florian: One suggestion has been, make ::before/::after as
           'user-select: none' by default, can be overridden, would
           get you current behavior.
  fantasai: ..... no, I don't think that's a good idea. That's just
            a bug.
  <dbaron> I think these are just explaining why generated content
           is a bad idea.

  dauwhe: Would this be a good guinea pig for starting work on AT
          type things?
  Rossen: Totally.
  Rossen: Sounds like we should start a spec for this, would you
          co-edit with me?
  dauwhe: Sure.

  astearns: So we should go back to the editing task force.
  astearns: And then put a note that we want to do that.
  fantasai: I think we should just have the spec require it, and
            then add more details and better improvements to make it
            easier to implement elsewhere.
  dbaron: I think generated content is a feature of the Web platform
          that doesn't get along with a lot of other features of the
          Web platform, and we can try to make a bunch of things
          work, but we're going around the way it works.
  plinss: But there's lots of uses for GC in publishing.
  TabAtkins: Printing doesn't have the same weaknesses as an active
  plinss: Replacing content has been a thing in word preprocessors
          for a long time.
  dbaron: But CSS is probably the wrong layer to do it.
  dauwhe: Yeah, but this is the world we're in.
  dbaron: I'm not happy about expanding it. Also should not have to
          tell other group to fix our problems.
  fantasai: Well, we can't not fix the problem, or pretend it
            doesn't exist.
  hober: The Editing TF is where the expertise is for this.
  [discussion about accessibility mapping specs]

  Florian: UI question, but related,
  Florian: Not speaking about search-ability, but select-ability.
  Florian: We previously resolved that 'user-select' property
           applies to ::before/::after and if it does, it's
           defaulted to none.
  Florian: Do we go away from that ?
  Florian: Edge makes it selectable.
  Florian: Or do we discuss this some other day.
  dauwhe: Why did the spec say it shouldn't be selectable?
  Florian: Because a lot of time it's decorative.
  Florian: Should be able to flip it.
  Florian: What's the default?
  gregwhitworth: There are far more people using it for
                 non-decorative uses than you think.
  fantasai: I would prefer if the spec didn't say "go this
            direction" when we actually want to go in a different
  TabAtkins: Then make it an issue in the spec.

datetime() and document-url()

  dauwhe: There's a bunch of old stuff about datetime() and
  dauwhe: I would have use cases for this, but do we think this
          stuff should be in there?
  <dauwhe> https://drafts.csswg.org/css-content/#content-datetime
  <dauwhe> https://drafts.csswg.org/css-content/#content-document-url
  dauwhe: These are really useful things in my world.
  dauwhe: Left them in.
  dauwhe: Wanted to hear from CSSWG.
  dauwhe: Prince does not have these. Don't know AH status.
  TabAtkins: Without any real definition, not very useful to have in
             the spec :-)
  dbaron: I'm going to suggest that they be removed.
  TabAtkins: One good reason to remove is to just establish them as
  TabAtkins: Use cases are obvious.
  TabAtkins: Show up in footer of everything you print off the Web.

  fantasai: You could write a whole book about formatting dates and
            times. Think we should drop.
  RESOLVED: Drop <datetime>

  ekimber: Should be call it document-uri
  plinss: No.
  ekimber: No?
  plinss: No.
  TabAtkins: Could also get this from a variable.
  RESOLVED: Drop document-url


  Rossen: Anything else?
  fantasai: Can we publish a new WD?
  TabAtkins: There's a ton of new stuff here.
  fantasai: Was copied over from GCPM, per WG resolution on GCPM
  hober: I'm in favor of publish an update to this.

  RESOLVED: Publish new WD of Generated Content

  dbaron: And do various shortnaming dances.

  ChrisL: If not yet published under patent policy, then FPWD from
          patent policy
  Florian: Some parts were published under GCPM FPWD.
  [basically, deferring FPWD/WD distinction to staff contacts]

Received on Thursday, 26 May 2016 00:05:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC