Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Christoph Päper]

> "Tab Atkins Jr." :
> On Sun, Nov 26, 2017 at 8:59 AM, GevCbmlGM  wrote:
> >
> > Is there any recommend standard HTML tags for POEM and MUSIC LYRICS?
> 
> Poems and lyrics are, generally, just text that has significant
> line-breaks. Thus,  and are the correct markup for them.

As with  and , HTML could also add  or something similar to 
embed MusicXML. Lyrics are a subset of musical notation and poems are, 
arguably, a special kind of lyrics (or the other way around).

[whatwg] Moving PNG Extensions to WhatWG

[Christoph Päper]

 lists APNG as a possible 
specification to take under WhatWG wings. It currently lives dormant at 
. What would be needed to get this 
and other extensions to PNG that have not or will not get the okay from 
W3C/ISO/IEC and PNG DG documented and maintained at WhatWG?

- [W3C REC](https://www.w3.org/TR/PNG/)
- [ISO/IEC 15948:2003](http://png-mng.sourceforge.net/pub/png/spec/iso/)
- [PNG Development Group](http://www.libpng.org/pub/png/)
- [PNG Register and 
Extensions](http://png-mng.sourceforge.net/pub/png/spec/register/)

Re: [whatwg] Typed numeric 'input'

[Christoph Päper]

Jukka K. Korpela :
> 2014-08-04 20:06, Christoph Päper wrote:
> 
>> Imagine a text layout GUI made with HTML.
>> It would probably feature a font size selection control.
>> There are different ways to do such a thing:
> 
> There are, and they are preferred in different ways by different people, as 
> programmers or as end users. This is why any solution, in addition to 
> introducing considerable complexity into HTML, would be used for a small 
> fraction of potential use cases only.

You do realize that font size control was just an example? A combined widget 
for number and unit would be useful in many places. Although most of us use 
metric units exclusively for almost all applications, there are still a lot of 
scenarios where two or more units are commonly used – even with the SI some may 
prefer centimetres over millimetres sometimes (or vice versa). Not to mention 
US localisation.

> An addition to the ways mentioned, the font size control could be simply two 
> buttons, one for increasing and one for decreasing the size, (…)

This seems like a special cased ‘numeric’ or ‘range’ widget and is agnostic of 
units.

> The designer needs to decide the internal representation of the font size and 
> to map the alternatives in the UI to that. I don’t see how additions to HTML 
> would significantly help here, even if they happened to match the approach 
> that is selected by the designer.

The point is that some such approaches are possible already, but not all. The 
simple possible solutions are rather clumsy and not very user-friendly.

Every author could, of course, just parse all free user input from a ‘text’ 
input server-side, but why shouldn’t browsers sanitize such input like they do 
for other form controls?

[whatwg] Typed numeric 'input'

[Christoph Päper]

Imagine a text layout GUI made with HTML. It would probably feature a font size 
selection control. There are different ways to do such a thing:

1
  

2
  

3
  
  

4
  
  ptpxmm

There are, of course, more possible units and one might want to supply a 
‘datalist’ with suggested predefined values, e.g.

  










  

Most desktop word processor GUIs use something like option 2, by the way, some 
always expect points and hence only provide solution 1 or just a drop-down list 
of predefined values.

It’s not possible, however, at least as far as I know, to strongly associate 
the two controls in options 3 and 4 (i.e. for number and unit) with each other, 
so UAs could employ a native widget for typed values. When the user changes the 
unit, such a widget could either keep the numeric value or convert it 
accordingly. This is what I’d like to propose, but am not sure yet how.

Although it makes sense to store value and unit together and convert on demand, 
they are more often converted into a purely numeric format, which usually will 
result in rounding errors (e.g. all those A4 PDFs that claim a page size of 
close to but not exactly 210 mm × 297 mm) unless a very small base unit is 
chosen. For length units used with font sizes, this might be EMU, half-point, 
twentieth-point etc. – let’s assume EMUs with 12700 emu/pt and 36 emu/µm. Since 
TeX uses the classic pica point (0.166 in/pc) instead of the simple DTP point 
(12 pc/in) the above ‘datalist’ would look like this (if striving for 
unnecessary precision)

  










  

But how could the accompanied ‘input’ support multiple views (i.e. conversions) 
onto this unified representation, and without exposing it to the user? The 
first solution I came up with is a ‘units’ attribute as follows:

  

The HTML4 fallback, however, would be horrible, because users would be exposed 
to EMU, which they absolutely must not be. Therefore one of the units would 
have to be selected as a default.

  

This could be done with a more verbose, but reusable ‘datalist’ instead:

  
  



  

‘units’ could also be called ‘scale’.

If, however, we would prefer a variant with 2 form elements that may be joined 
(option 3, 4) instead of a single complex one (based on 2) as shown above, we’d 
need a way of associating them with each other.

  
  

  
  

  


  

  


  

These lack a possibility to specify conversion factors. That might be achieved 
by

  


  
  
  

  

As I’m said, I’m not sure what’s the best solution, but HTML should have a 
typed numeric input element with conversion capabilities.

Re: [whatwg] Sortable Tables

[Christoph Päper]

Ian Hickson:
> On Thu, 1 Jul 2010, Christoph Päper wrote:

Darn, my reply from yesterday got lost in data nirvana. This is a slightly 
shorter version thereof.

>> So sortable tables should be marked as such.

Opt-in:

  

“sortable=auto” should be the default and resolve to ‘sortable’ if at least one 
column has a sort key assigned, and to ‘fixed’ (or the like) otherwise.

(Row and column collapsing is a related, but different beast. Let’s deal with 
that separately, later.)

>> Note that ‘col’ and ‘colgroup’ elements are hardly supported.

Nevertheless, it’s usually sufficient to mark one column as containing values 
to use as sort key. 

  
  

Columns inherit the key from their group, but may override it.

>> non-sortable columns inside sortable tables should be marked as such.

  key=none

Not to be confused with fixed columns.

>> There are different ways to sort, eg. numeric, temporal or alphabetic 

  key=numeric 1 < 2 < 10
  key=alpha   Ä = ä = Ä (= a?), 1 < 10 < 2
  key=date2012-11-08 = 2012-W45-4
  key=value   1000 g = 1 kg = 0.001 t > 1 lb

  key=style   although Excel can do this to some degree, it’s hardly useful
  key=class   slightly more useful
  key=id  ditto

>> and ascending or descending.

That’s better left to the UI: switch order when sorting for the second time.

>> Several columns may be used for sorting by some kind of priority.

Also primarily a UI question: use previously sorted column as secondary key.

  key=1   primary key for heuristic sorting algorithm

>> The original order must be restorable.

UI again, e.g. tristate column sort: ascending, descending, original, …

>> Cells should have an optional attribute indicating their sort key.

  1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

  key=fixed

The sorting algorithm should not work on cells, but on slots (or slot values 
rather). 

Cells spanning multiple rows or columns may have to be split into one cell per 
slot and should be rejoined afterwards if possible. Note that ‘rowspan’ itself 
is safe for vertical sorting, unless it spans a ‘fixed’ column. Also, ‘colspan‘ 
is safe when it appears in the column to be sorted by.

  td {color: green}
  [rowspan] {color: red}

  1 red  1  red
  3 =sort=col1=>   2  green
  2 green  3  red

The text reads its color! A cell at (1,1) – counting starts from 0 – never 
exists, the slot at the same position changes its value from ‘red’ to ‘green’.

Re: [whatwg] Sortable Tables

[Christoph Päper]

Ian Hickson (2012-11-06):
> On Thu, 1 Jul 2010, Christoph Päper wrote:
>> 
>> For starters, only rows inside ‘tbody’s shall be reordered.

That means every row groupp shall be sorted independently from others, while 
‘thead’ and ‘tfoot’ remain unsorted, possibly bearing sort widgets.

>> Not every table has content that makes sense to be sorted in a different 
>> order.
>> So sortable tables should be marked as such.

We shall use opt-in, obviously. It’s not strictly necessary to mark ‘table’ as 
sortable, if at least one of its rows is marked as such, but it would be handy 
for “autosort” where the author just wants to enable sorting without specifying 
the details.

  

(Table collapsing is a slightly different beast, but related. Let’s deal with 
that separately later, though.)

>> Note that ‘col’ and ‘colgroup’ elements are hardly supported.

But they’re essential for assigning sort properties.

  
  

A ‘col’ inherits the ‘key’ from a parent ‘colgroup’, but may override it.

>> Not every column has content that makes sense to be sorted in a different 
>> order. So non-sortable columns inside sortable tables should be marked as 
>> such.

Here, I’m talking about columns that should be sorted, but not act as sort 
keys. See below for fixed columns.

  
  

>> There are different ways to sort, eg. numeric, temporal or alphabetic 

This easily gets more complex than you wish.

 = 
  1 = 100% = 1.0 = 1e0 = 2/2 …
 Ä = ä = Ä …
 2012-11-06 = 2012-W45-2 …
1000 g = 1 kg = 0.001 t > 1 lb

can of worms
hardly better

The default ‘key’ is ‘auto’ for explicit columns and ‘none’ for implicit 
columns. 

>> and ascending or descending.

It’s probably overkill to give authors the means to specify the preferred 
direction. It’s certainly not sane to let them exclude one or the other.

>> Therefore columns should bear (…) what kind of content their cells have.

Authors will mess this up of course, but then it’s their fault. Let’s not 
overload ‘title’ or ‘abbr’.

>> Several columns may be used for sorting by some kind of priority.

This is a UI question, though.

>> The original order must be restorable.

Also mostly a UI issue, although if authors could describe how they initially 
sorted the data, that could also be used. They would err and lie more often 
than not, though.

>> Cell content may not consist of the string that should be used verbatim (…).
>> Cells should have an optional attribute indicating their sort key.

  The Rolling Stones
  1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

  

> This is a very interesting idea.

It was in 2010 and still is.

Pitfall: ‘rowspan’ and ‘colspan’

Cells may span several rows or columns or both, and are always rectangular. 
Therefore, we should not sort cells! We should sort slots instead, as defined 
in 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#table-model>.

A slot is uniquely identified by its row and column numbers and itself is not 
represented in markup, i.e. in CSS, it cannot be selected by element or other 
generic selectors, but a pseudo-element like ‘::slot(row,column)’ would be 
possible, and is as desirable as something like ‘getSlotValue(x,y)’, possibly 
cf. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19051>. 

Assuming current attributes and elements, a ‘td’ or ‘th’ cell covers 
‘rowspan’בcolspan’ slots and each of these has the same value. The slot value 
is that of its cell, and dynamically changes with it. The cell value is either 
its content normalized to a string or, if present, the value of its ‘value’ 
attribute. Sorting is done by first evaluating the slot values as suggested by 
the ‘key’ attribute value valid for their column, and by second sorting rows 
using the slot values in the user selected (or default first) column as primary 
key accordingly. If the same column has been used for the previous sort, the 
order is reversed (ascending ↔ descending). If a different column has been used 
before, it’s used as secondary key, and so on.

Cells spanning several columns (only) will usually remain intact for normal, 
vertical sorting, unless an affected sort key is set to ‘fixed’ in exceptional 
cases. Cells spanning multiple rows in the column to be sorted by, usually 
remain intact, too. Other cells spanning multiple rows (and possibly columns) 
need to be split into slots for sorting and (optionally) should be rejoined as 
far as possible afterwards.

To support this, cells must be splittable!

  td {color: green;}
  #split {color: red;}

  3  red
  1
  2  green

after sorting by the first column should look like

  1  red
  2  green
  3  red

would if duplicate IDs were legal. The DOM tree, however, would not change! The 
value of the cell at position (1,1), i.e. second row and column since we count 

Re: [whatwg] Geographic hyperlinks

[Christoph Päper]

Bjoern Hoehrmann:
> * Christoph Päper wrote:
>> geo:13.4125,103.8667@mars
> 
> You can specify the coordinate reference system with the crs paramameter

Yes, but I don’t think it’s a good design to select the astronomic body with 
the same property that you use to switch between different CRSs for a given 
spheroid. Nevermind.

Re: [whatwg] Geographic hyperlinks

[Christoph Päper]

Tantek Çelik:

> See RFC 5870[1] for a proposed standard geo URI scheme for "geo:" hyperlinks.

I wonder whether this scheme, someday, will be extended to include a domain 
part, e.g. geo:13.4125,103.8667@mars, or whether we’ll rather get a ‘astro:’ 
scheme.

Re: [whatwg] [Selectors4] case-insensitive attribute value matching (in XML)

[Christoph Päper]

Anne van Kesteren:
> I'm still trying to get HTML and browsers to change so that attribute values 
> always match case-sensitively, irrespective of markup language. The current 
> magic attribute list in HTML whose values needs to be matched ASCII 
> case-insensitively is just ugly.

Can’t that be changed to something like the following?

  When an attribute takes as a value
  – a single keyword or
  – a whitespace-separated list of keywords,
  where all valid keywords are defined in this spexcification,
  these keywords are ASCII case-insensitive.
  All other attribute values are case-sensitive.

or just

  All element names, attribute names and attribute value keywords
  defined in this specification are ASCII case-insensitive.
  All other attribute values are case-sensitive.

Re: [whatwg] Physical quantities: or ?

[Christoph Päper]

Jukka K. Korpela:

> c would be odd, wouldn't it, since the symbol denotes a universal 
> constant of nature.

It would not, ‘c’ is merely a variable with constant value.

  E = m·c2

Or , eventually.

Re: [whatwg] Why is @scoped required for

[Christoph Päper]

Jukka K. Korpela:

> Yet another reason for dropping  in favor of an attribute 
> referring to an external stylesheet.

I’m not sure which of these I would hate the least:

  
…

  
…