Re: Changing definition of "Large text" to use px rather than pt

I think we are using points was because LARGE TEXT applied only to text.  And all current regulations for LARGE TEXT are specified in points.  
Also for most authors, font sizes are specified in Pts not pixels. 

But as long as there is a conversion back and forth - there is no substantial problem.  no? 

gregg

> On Apr 26, 2016, at 12:46 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> On 26/04/2016 16:19, Gregg Vanderheiden wrote:
> >>> pts are defined in inches — so they are an absolute number.
> >>>
> >>> pixels are not — or do you have some absolute definition of px meaning a
> >>> fraction of an inch (or mm)?
> 
>> read the definition in the Glossary
>> 
>> it explains it there
> 
> Gregg, not sure if you've actually read any of this thread, or the discussion on the relevant github issue, but - as Alastair pointed out - even in Note 3 of the actual glossary definition it clearly says that no, it's NOT an "absolute number" as you said when you joined this thread, but that in fact it's anchored on CSS pixels, which granted do have an idealised relationship to inches (as per https://drafts.csswg.org/css-values/#absolute-lengths <https://drafts.csswg.org/css-values/#absolute-lengths> "1px = 1/96th of 1in" - then again, inches are then defined in relation to pixels, in a wondefully cyclical reference "1in = 2.54cm = 96px") ... but also clearly is anchored on the reference pixel (or the browser's approximation thereof) and bears no relation to real-world inches.
> 
> "Note: If the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels" - https://drafts.csswg.org/css-values/#absolute-lengths <https://drafts.csswg.org/css-values/#absolute-lengths>
> 
> As this is the case in all screen based user agents past and present (and there's no indication future UAs will change this, for fear of breaking backwards compatibility with content that does rely on this fact), we can conclude that: points are anchored on CSS pixels, so why are we defining sizes in points - a unit of measure which practically no web author actually uses - when the most logical unit of measure for screen-based authors is px? Since the relationship between pt and px is always 1pt = 1.3333333px (96/72), it makes no substantive difference, but avoids this entire conversation we've now been having trying to explain what's mean by points.
> 
> P
> 
>> 
>>> On Apr 26, 2016, at 2:49 AM, Patrick H. Lauke <redux@splintered.co.uk <mailto:redux@splintered.co.uk>
>>> <mailto:redux@splintered.co.uk <mailto:redux@splintered.co.uk>>> wrote:
>>> 
>>> On 26/04/2016 01:42, Gregg Vanderheiden wrote:
>>>> Notes are NOT normative.
>>>> You are correct
>>>> 
>>>> but in definitions…  hmmmm..
>>>> 
>>>> pts are defined in inches — so they are an absolute number.
>>>> 
>>>> pixels are not — or do you have some absolute definition of px meaning a
>>>> fraction of an inch (or mm)?
>>> 
>>> Gregg, are you seriously suggesting that WCAG 2.0 actually meant "14pt
>>> bold / 18pt" *as measured on the screen with a ruler* all along?
>>> Rather than CSS "pt", which are by definition 1.333px (see
>>> http://codepen.io/patrickhlauke/pen/zqabMR) ?
>>> 
>>> What did the actual testing procedure for "large text" look like then?
>>> "Open the page on your browser, take a ruler, and measure the size of
>>> the text as rendered on the screen"?
>>> 
>>> If you *are* meaning that WCAG 2.0 meant actual physical sizes all
>>> along, then...I'm sorry, but we're back to the problem that it is
>>> impossible for an author to actually guarantee at what physical size
>>> anything is rendered on every user's screen. So the normative language
>>> for WCAG 2.0 includes a requirement that cannot be absolutely tested,
>>> as it depends on each individual user's physical screen size,
>>> resolution, zoom factor, dpi, etc.
>>> 
>>> Or are there any techniques that you can point to on how an author can
>>> guarantee, on every device, in every browser, that something will
>>> render at a particular size? I'd love to see them - but suspect they
>>> do not exist, as this is an impossibility, since it varies so heavily
>>> across devices. Is WCAG 2.0 requiring a magic pony?
>>> 
>>> P
>>> --
>>> Patrick H. Lauke
>>> 
>>> www.splintered.co.uk <http://www.splintered.co.uk/> <http://www.splintered.co.uk <http://www.splintered.co.uk/>> |
>>> https://github.com/patrickhlauke <https://github.com/patrickhlauke>
>>> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>> 
>> 
> 
> 
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke