Re: Prioritisation

Forgive me for a very basic question, but it is a devil's advocate type of
question. And if this is not the place to ask this perhaps you can direct
me to any relevant discussions.

My very basic question is, why do we need to "paginate" in the browser in
the first place? Why not keep the browser for reflowing and interactive
text, which is what it is good at, and use a standard mark-up pagination
system (TeX/LaTeX would be my choice) to do what that is good at. If
another system has already solved problems like footnotes and floating
figures, what exactly is the drive to reinvent that in the browser?

Again, apologies if the answer is really obvious!!

Regards
Kaveh

On 4 August 2015 at 16:03, Dave Cramer <dauwhe@gmail.com> wrote:

> On Tue, Aug 4, 2015 at 12:07 AM, Richard Ishida <ishida@w3.org> wrote:
>
>> looking at the prioritisation at
>>
>>
>> https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9xh7K8anmJ5c0-OFEG7w0LHYM/edit?usp=sharing
>>
>> i found myself  wondering what the priorities mean, and how they were
>> arrived at.
>>
>
> Hi Richard,
>
> The spreadsheet was used to gather information as this work was being
> started. The main effort is now directed towards this HTML document:
>
> http://w3c.github.io/dpub-pagination/priorities.html
>
>
>> what they mean: could a low priority mean that work is under way to
>> provide the functionality in question, and that therefore additional work
>> is a low priority? Or does it mean that it is felt that this is a less
>> important feature to have than others.  Presumably the latter would imply
>> that, when bandwidth is limited, work should be directed elsewhere first;
>> but once that high priority work is completed, does the priority change for
>> the low priority features?  In other words, are all the features really
>> important, but just less urgent than others?  Or are the low priority
>> features really not terribly important?
>>
>
> The new document has divided the features into three categories:
>
> 1. Well-defined features with multiple implementations, but that are not
> yet available in all browsers.
> 2. Features requiring further spec work
> 3. Features requiring design and architectural decisions before specs can
> even be written.
>
> This informs what sort of action we need to take--for #1, we need to lobby
> Safari to implement font-feature-setting!
>
>
>>
>> how arrived at: who decided on the prioritisation, how was it done, and
>> what communities do they represent? Some features are presumably likely to
>> be of higher priority to certain subgroups – an easy example being vertical
>> text, which got a high priority rating during the workshop in Japan, which
>> was mostly attended by CJK folks, but is perhaps not so urgent in the
>> West.  How is that factored into the prioritisation?
>>
>
> I made the initial decisions about priority, with some input from other
> members of DPUB, as well as asking everyone I know on Twitter :). In
> general, the highest priority things are either widely applicable
> (font-feature-settings can be used in so many ways by many different
> communities) or are absolutely fundamental to specific communities (like
> vertical text). Some of the lower-priority features are either incremental
> improvements (better control over hyphenation) or things that only affect
> smaller communities (merging page number ranges in indexes).
>
> But further input both on priorities and what should be listed is welcome!
>
>
>>
>> i suspect it would be useful to point to or include some text to describe
>> these things for people looking at the spreadsheet.
>>
>
> Agreed. Thanks so much for bringing this up!
>
>
>> Dave
>



-- 
Kaveh Bazargan
Director
River Valley Technologies
@kaveh1000
+44 7771 824 111
www.rivervalleytechnologies.com
www.bazargan.org