Re: WebFonts WG Kick-off (was RE: WOFF submission published)

On Tuesday, April 20, 2010, 11:00:36 PM, Vladimir wrote:

LV> First of all, I would like to thank the authors of the WOFF
LV> Submission for completing this major and very important milestone,
LV> which enables us to proceed with technical work according the
LV> group charter [1]. 

Yes, its great to see this submitted and published. Personally its been a bit of a nerve wracking wait to get the submission (and the submitters) lined up, for each organization to make the requisite Royalty Free commitment, and to then get the Submission accepted.

A somewhat arcane aspect of W3C process is that, in between a submission being sent to W3C and the decision to publish it (or reject it or to send it to a WG without publication) the submission can't be discussed in public. 

There are good reasons for this, mainly to cover the case where a WG has a particular direction and some W3C Member wants to make it go off a different way and (mis)uses the Submission process to do so rather than making the proposal in a WG and using the consensus approach. That is not at all the case here, the submission is exactly what we wanted to work on, but the rules still applied.

I'm glad that the "know but can't tell" part is now over.


LV> I also would like to thank John Hudson for
LV> initiating the discussion on the Typophile blog [2], and I have to
LV> say that I certainly share his sentiment about those rare
LV> circumstances when using bold typeface is totally appropriate ;)

Yes. The current charter has a single format deliverable, WOFF, while the draft charter had two,  CWT (EOT Lite) and WOFF; and the uncomfortable partitioning of the supporters of those two - basically "Microsoft" and "everyone but Microsoft" respectively. As several people pointed out, that was a recipie for a standoff in the WG and for confusion and uncertainty in the typography and web design communities.

I was pleased when discussions allowed the charter to be streamlined to just WOFF, shortly before the charter went to the W3C Advisory Council (AC) for review. That increased the chance of success greatly. And I was pleased when that shift of support at Microsoft also manifested as an interest in being a co-submitter of WOFF. Naturally the legal review required gave some additional delay, but that was I think well worth it.

The Submission sends a strong signal of political will to work together, which is valuable.

LV> Now that we have the WG fully formed (with Christopher Slye from
LV> Adobe being the newest member of the group, welcome) we should
LV> start thinking of the many tasks we have to accomplish. 

We may still get a member or two, but there is no reason for delay now that we have the WOFF spec.

LV> To start
LV> the creative thinking process, I would like to suggest a list of
LV> items for consideration, and I would encourage all of you to add
LV> items to the list as you see appropriate. In no particular order,
LV> other than maybe the complexity of things we need to address, I believe we should:

LV> 1) Discuss and finalize the WOFF specification

I would like to see us walk through the spec, as a group. Either in email or on a call. Partly to ensure we are all up to speed, partly to look for ambiguous wording, and partly to look for missing, essential features if there are any.

LV>    - are there any features that we believe may be missing, or
LV> would be useful to add in order to make WOFF "future-proof"?
LV>    - what is the metadata information that we believe would be
LV> good for browsers to expose to users, and whether the existing
LV> metadata fields would be sufficient to convey the information we want to see exposed?

I would certainly like to see some examples of metadata statements. We could collect these on the wiki, for example. Its much easier to copy an example; good examples help adoption.

LV> 2) Decide on the conformance requirements:
LV>    - whether any references to same-origin restrictions and the
LV> CORS mechanism to relax them should be part of the WOFF spec, or 
LV>    - whether it should be a separate deliverable from the group, and
LV>    - whether this should be part of the conformance requirements.

Yes, we need to decide that.

In my opinion, regardless of where that aspect of conformance goes, it should not be optional. Same-origin (as a default, with CORS to relax it) only really works if its required.

LV> 3) Develop Web Font conformance spec (see details in the WG charter [1])

LV> 4) Develop test cases for web fonts:
LV>    - develop test methodology and decide whether it is
LV> appropriate to require the presence of human observer, at least for some test cases;

We will probably need both sorts of test.

Automated tests, whether they use the DOM or use XSLT or whatever, comparing some output to the desired output, are great because there can be a lot of them and they can be run frequently without requiring much human time; excellent for creating an implementation test report and for checking an evolving implementation for regressions.

Some tests are hard to automate, either because they require human interaction or because the conformance requirements are complex and hard to express in a machine-discoverable way. We should not shy away from such tests, but in my view we should prefer automatable ones where possible.

LV>    - develop the test cases and design / collect / donate /
LV> acquire (as we see appropriate) the necessary resources for web
LV> font test suite (e.g. fonts, etc.).

LV> For the time being, I intentionally omitted items related to
LV> implementations from this initial list - I believe that the fact
LV> that WOFF submission has originated from three major browser
LV> vendors speaks for itself, and will allow us to address the
LV> implementation requirements later as part of our work.

I agree that we are in good shape for implementation experience at this early stage, but we should not rest on our laurels here.

For now I think its sufficient to maintain a list of known implementation (I will do that) and to continue to build contacts with those development teams. In my experience, good contacts really help in terms of bug reporting and fixing in response to changes in the test suite, for example. Its also a form of outreach, and good contact with the developer community is part of our charter.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 21 April 2010 10:45:48 UTC