Re: [dpub] CSS Priorities Spreadsheet

> On 25 Jun 2015, at 18:11 , Dave Cramer <dauwhe@gmail.com> wrote:
> 
> On Thu, Jun 25, 2015 at 1:01 AM, Ivan Herman <ivan@w3.org> wrote:
> Thanks Dave,
> 
> I had a chat with some of the Interaction Domain people lately. Some takeaway message:
> 
> - This sort of information (as well as the pagination use cases) are very important for planning and feedback for the team. Specifically, Chris Lilley will dive into the pagination use cases and, once he has digested them, he is happy to come to one of our calls to discuss the various approaches (Houdini or not Houdini, for example) with us.
> 
> I owe the Houdini ML an email to start a discussion. I've added a discussion of the building blocks for pagination to the F2F agenda.
> 
> - Many of the notes in the table (and also in the remarks below) are around the fact that a specific browser does not implement a specific feature. The experience is that submitting bug reports on missing feature, if coming from major operators/users/institutions/communities, is useful in getting things moving. It is a bit of a pain to find the right bugzilla/github/whatever instance that they listen to (if any:-) but it is worth the trouble.
> 
> Once we agree on priorities, and identify which bugs we need to file or comment on, can we have *The Director* file the bugs?

:-) That would be nice...

> More seriously, how do we communicate the fact that these issues have been prioritized by a significant W3C community?

Well… we may ask Mike or Robin for advice; from the top of my head I would say that referring to the Digital Publishing IG may already count for something. Alternatively, we co-sign the issue in a way that it makes it clear there Hachette, Wiley, and Pearson on the line, too, as members of the IG, and as relatively large companies:-)

> 
> I've added a new column to the spreadsheet with links to a few browser bugs.
> 
> 
> - On the specific issue of hyphenation and chrome, it seems that there is process: [1] seems to suggest that it is on its way now. :-)
> 
> I read that bug much more pessimistically, given that I don't think anyone is working on it, and a bunch of hyphenation code was removed from Blink a few years ago.
> 
> 
> - Some of the issues are related to I18N activities. Note that they maintain a kind of 'meta' document[2] on typography issues, referring to other documents. Maybe checking those to see if features are in line with those we have would be a good idea.
> 
> General experience: we should publish/update our documents in a visible manner more often. The fact that we have not republished latinreq for a long time led them to believe that there are no outstanding issues with CSS… We should find a way to make updates more often and actively notify whomever we want to notify.
> 
> I agree that we should update the documents more often, but I'm a bit puzzled by the perception that frequency of publication sends such a strong message. This isn't a spec, but a requirements document.  JLREQ hasn't been updated in three years, but there are still issues with setting Japanese text in browsers. I've been thinking how to integrate some discussion of the status of each feature into Latinreq; perhaps that would help.

Yes, I think it would.

> 
> By the way, I've converted Latinreq to Bikeshed locally. Would you have a strong objection to my pushing that version to Github?

Absolutely none. Except that I have never used bikeshed, so if there is a problem I cannot really help:-(


> I feel that as we mention CSS more explicitly in the document, being able to easily link to CSS property definitions would be useful, and I've now had much more experience with Bikeshed than ReSpec (and on my terrible internet connection, it takes up to 30sec for ReSpec to add content to a doc).
> 
> 
> B.t.w. [3] and [4] seems to be the right bug report areas for Firefox and Chrome, respectively. I do not know what the rules are to submit new reports…
> 
> Generally there are detailed guidelines provided. For example, [A] provides guidance on writing bugs on WebKit, [B] for Mozilla, [C] for Blink, and [D] for IE.
> 
> Note that filing a bug on a browser is even scarier than sending an email to www-style! I've only done one [E], and it was an adventure.

Sigh. I must admit I was afraid of that…

Thanks

ivan

> 
> Cheers,
> 
> Dave
> 
> 
> [A] http://www.webkit.org/quality/bugwriting.html
> [B] https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
> [C] https://www.chromium.org/for-testers/bug-reporting-guidelines
> [D] http://blog.reybango.com/2013/02/28/submitting-an-internet-explorer-bug-to-microsoft/
> [E] https://bugs.webkit.org/show_bug.cgi?id=139667
> 
> 
> [1] http://j.mp/1IzWL5D
> [2] http://w3c.github.io/typography/
> [3] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=addHitRegion
> [4] http://j.mp/1RxQZ9c
> 
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704