RE: css3-fonts: should not dictate usage policy with respect to origin


 
> * Sylvain Galineau wrote:
> >You’ve formally objected before making any substantial attempt to
> >present a coherent point of view and obtain a group consensus for or
> >against your preferred course of action. Negotiating after preemptively
> >slamming the biggest door in the room is no easier than building
> >consensus under threat. Attempting both at the same time was a
> >significant tactical blunder on your part. Your mistake.
> 
> Glenn Adams presented an entirely coherent point of view right at the
> beginning of this thread and indicated that he wishes the decision to
> include the requirements as they are currently proposed to be reviewed by
> an independent third party should it stand. That is entirely reason- able
> and appropriate; there was no threat, no slamming of doors, quite the
> contrary as far as I can tell from reading the thread.

Our definitions of coherence differ hugely. First it was backward compatibility
and the conformance of existing devices with a new draft, in complete conflict
with WG process and the explicit disclaimers present in every single CSS spec.

Then it was forward compatibility. In the middle it was css3-fonts should not
define fetching semantics but that should be in HTML5. 

The only thing that was coherent was that either the WG changed this requirement
in a manner allowing Glenn to ignore it or he would formally object. As the latter
can block publication, as much of his contribution demonstrates he does not understand
the scope of the requirement being objected to, bringing up a formal objection 
was premature, unnecessary and inappropriate. A formal objection is a last resort, 
not something you do to get attention because your first attempt is not going anywhere. 
I don't believe it is unreasonable for people to at least wait until they have 
discussed their issue several times over the phone before taking that step. You're 
of course welcome to disagree. 

> 
> There is nothing unusual about the concern raised either, you seem to be
> arguing for "interoperability" among of handful of web browsers 

Yes, a handful, with about 1+ billon users total. What most people call
the web, roughly.

> in what
> restrictions they implement and what related technologies they im- plement,
> while Glenn Adams seems to be arguing that others should not be bound to
> such agreements between a few web browser vendors by way of css3-fonts
> compliance. 

As explained by Liam and others, there is no binding agreement on anyone since 
css3-fonts is a draft. It does seem as if other organizations have chosen to
create a binding agreement on *themselves* and, as a result, it is now demanded 
of this WG to honor them i.e. third parties are formally objecting to us ignoring 
their own chosen dependencies, which we had no knowledge of. Is it so
unreasonable to expect that someone who chooses to reference a draft normatively 
at least contact the editor of said draft vs. notifying an entire WG that such a 
dependency exists by formally objecting out of the blue ? Is the latter the best
way to proceed and achieve positive progress ?

>That's a rather common theme and usually re- resolved by
> separating concerns appropriately.

Sometimes it can be. It doesn't follow that it is best to do so. And if it won't 
prevent others from taking a premature dependency on the newly separated concern 
we may find ourselves back in the same corner anyway. Creating more sources of 
possible interrupts does not seem productive or helpful. 

> 
> As far as I am aware CSS 2.0 and implementations of it support using fonts
> across "origins" without "CORS", and there are implementations that do not
> support using fonts across "origins" and they do not have "CORS" support
> either. I have not seen a coherent argument why such im- plementations
> must be non-compliant with css3-fonts beyond that some web browser vendors
> want their competitors to do nothing differently.

You do not need full CORS support to interop with Firefox and IE. Only a small
subset is required. Moreover, a separate dedicated mechanism is being discussed.
I do not think the issue debated here has anything to do with the name of the
header used to enforce the restriction. The request is to make the behavior 
optional, period.
 
> So, so far I would certainly agree that whether some product supports
> "CORS" or supports using fonts across "origins" should not affect con-
> formance of that product to "css3-fonts", just as whether it supports EOT
> fonts or the "data" URL scheme should not affect conformance to "css3-
> fonts", just as cross-origin background-image support should not affect
> CSS 2.1 compliance.

This has been discussed at length. Whether the font resource specified by
the author does or doesn't load has a significant impact on content. This 
impact is *not* a separate concern to authors, users, web sites, font makers
 and UA implementors. Some people prefer the requirements needed to implement 
a feature completely and successfully should be spread across several documents 
according to neat architectural diagrams. Others prefer to maximize the odds 
of achieving interoperable implementations. HTML5 sets a precedent for the latter. 

But if separation of concerns were in fact the issue, it yet has to be 
explained why this so obviously belongs to HTML. It seems the latter is
mostly a convenience i.e. since HTML5 doesn't separate those concerns let's
dump it there. This would indicate the goal has little to do with sound 
architecture and more with moving the requirement where it can be ignored. 
(At least until some other profile who has a dependency on the current HTML5
draft objects....)

Last, I still don't understand how or why a FO to this group is the way
to reach consensus on requiring anything in HTML. That's the HTML WG's
decision. Glenn should ask them and needs no approval from anyone here
to do so.

> 
> Look, the "user agent profile" crowd always clashes with the "indepen-
> dent technologies" crowd like this and it's very easy to avoid simply by
> keeping the profiles separate from the independent technology specs.
> We do that all the time precisely to avoid wasting so much time and
> goodwill for what is ultimately a non-issue because the profile crowd is
> so small and already in agreement that they do not need this in any
> specification at all; it's more of a reading aid for web authors, and I am
> quite sure they would prefer if the thousands of dollars that have been
> lost on this 120+ thread would have been spent on more test cases.

Since the 'profile crowd' in question is in full control of what their 
profile depends on, why can't they pick a specific draft version ? If
the issue is the length of the process then choose a static target. That 
seems far more reasonable than wasting the time of those who have no need 
or knowledge of for their profile with unwarranted threats that mostly 
reflect the flaws of their own decisions. I'm happy to discuss the latter 
and suggest possible workarounds. I'm not fine with people using our process 
to cause a group-wide interrupt and force the resolution to a self-inflicted 
problem this group has done nothing to create. (This is the Fonts WG mailing 
list btw; we don't own css3-fonts anymore than we own HTML5). As things stand 
this process could well re-occur every time we update a draft listed in that 
conveniently hidden profile and that is simply unacceptable.

> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de

> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de

> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 29 June 2011 14:51:56 UTC