Re: [dpub] CSS Priorities Spreadsheet

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? More seriously, how
do we communicate the fact that these issues have been prioritized by a
significant W3C community?

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.

By the way, I've converted Latinreq to Bikeshed locally. Would you have a
strong objection to my pushing that version to Github? 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.

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
>
>